Notes2 Design NoteWindowDistribution

< Back to the Notes2 main page

Summary

This section covers the distribution of the Notes Windows in the Note Side Pane area during showing or editing Notes.

Rationale

In the best of all worlds, the note information will be placed in the direct neighborhood of the document text it refers to. It has been decided to use the Note Side Pane which does contain all Note Windows. To prevent overlaying the Note Windows or manual positioning of them, there is a need for an algorithm that distributes the Note Windows with respect to the user's needs.

Assumptions

• Use of the Note Side Pane Notes2_Design_NotesSidePane
• The Notes functionality is limited to "static" layout, that means no smooth animation and re-position is possible. (If animations were supported this would solve some problems and the described behavior should be revised.)
• The document provides a clear information flow direction (OpenOffice.org Writer text flow).

Proposed Designs

Proposal "Simple Static Note Window Distribution"

General goals for the distribution of Note Windows:

• Don't bother the user and let him concentrate on his work on the Writer document (e.g. prevent jumping windows, blinking, flickering)!
• Show him/her as much information in the Note Windows as possible.
• If the user moves or edits the Writer document (e.g. scrolling, inserting characters), try to keep the relative position of notes anchor and notes windows.
• If necessary, move Note Windows if the text is moved too (e.g. inserting characters or scrolling the document).
• If possible, minimize the distance between Note Anchor and corresponding Notes Window.
• If it's necessary to ellipse the text or to show scrollbars, use a smart logic to minimize further user interaction (by e.g. manual scrolling in too many notes)!

Algorithm

• Note Windows have a maximum size that can't be exceeded, of course they can be smaller if there content fits into the smaller size.
• In case Note Windows overlap if they get their default positions and maximum size they will be moved downwards or upwards to avoid overlapping. All Notes anchored to a page should be evenly distributed on the page.
• The layout algorithm is iterative and always starts with all Notes Windows on their default position. In case of conflicts (overlap) it should try to resolve them, starting with the top most of them:
  • move the upper Note Window upwards until the conflict is resolved, but not more than a maximum distance (maximum distance won't be an issue in the first iteration) and not above the page border
  • if this creates a new conflict move this Note Window down again until the new conflict is resolved again; now move the lower note of the former conflict downwards until the conflict is resolved, but not more than a maximum distance and not below the current page border (this can create a new conflict)
  • in case conflicts still exists repeat these steps
• If not all conflicts can be resolved try to repeat this with a reduced maximum height for the Note Windows.

Proposal "Reduce Maximum Height of Note Window"

This proposal extends the proposal "Simple Static Note Window Distribution".

Some of our competitors just ignore the fact that the number of notes can exceed the available height of the document page (and therefore their implementation of the notes side pane.) The Note Windows simply disappear - an easy, but no robust design ;-)

It may be necessary to reduce the height of the Note Window to provide maximum space efficiency in the Side Pane. Therefore the size of the Note Windows could be reduced:

• Use scrollbars inside the Notes Windows to access the complete Notes User Data: The intention is to reduce the size of the Notes Windows, so it will be possible to keep the smaller Notes Windows together and to minimize the distance to the Notes Anchors. It is assumed that the user will remember important Notes if e.g. only the first 3 lines of Notes User Data are shown due to space restrictions.
• If the height of the Notes Windows falls below a defined minimum, then the Note Side Pane has to provide a mechanism that ensures sufficient space to show all Note Windows (e.g. expansion of the Note Side Pane).

=== Proposal "Window Distribution when Open Points:

• What to do with notes bigger (e.g. higher) than the current viewport? I propose to not do any scrolling/panning if those Note Windows get the focus (e.g. by viewing/editing). Then, the text cursor inside the Note Window should affect the scrolling behavior of the Document text and simultaneously the Notes Side Pane.
• Answer the question if the panning does annoy the user.

" ===

This proposal extends the proposal "Simple Static Note Window Distribution".

This section contains the description of how the Notes Window distribution behaves if Notes are inserted or edited. Maybe there is some better place for this kind of specification, but - however - there will be the need of redistribution of Note Windows.

• Creation of Notes
  • If a Note is created, the Notes Functionality must insert the newly created Note Window at a position given by the rules of “Distribution of Notes Windows in the Side Pane”.

    Example: refer to the graphic below, Example D, Step 1.2

  • If a Note is created, the Notes Functionality must sets the height of the newly created Note Window to a value that makes it possible to insert three lines of Notes User Data without resizing the Notes Window. (newly created Note Window: does not contain any Note User Data)

    Rationale: If there is few space available (e.g. for one line of text), some users “fear” that this will not be enough and will initially entering some blank lines to get some more room. We prevent this by providing enough space right from the start.

    Example: refer to the graphic below, Example A, Step 1.2

  • If a Note is created and the Note Window is not completely visible on the screen, the Notes Functionality must pan the view port area to completely show the Note Window inside the Writer Document window.

    Rationale: The user wants to see the newly created object.

  • If a Note is created, the Notes Functionality must set the focus to the newly created Note Window and places the cursor inside the Note Window. (inside: the area reserved for the Notes User Data)

    Rationale: The user may want to just start typing.

  • If a Note is created, the Notes Functionality must create the Notes Window with the obligatory elements shown in “Structure of the Notes Window”. (elements: e.g. Notes Property Data, option button)
  • If the keyboard button ESC is pressed directly after creating a Note, the Notes Functionality must reverse the action of creating the Note. (directly after creating a note: e.g. the user did not leave the note or added any information; reverse: the state of the Document before creating the Note is restored)

    Rationale: The user may want to revert the action of an accidentally inserted Note.

    Please note: The reversion should be undo-able with the function Undo.

• Inserting or Editing Notes User Data
  • If the user inserts Notes User Data in a Note Window and there is enough both free and visible space below the Notes Window, the Notes Functionality must expand the Notes Window to fit to the amount of Notes User Data. (visible: the space visible for the user; space: space in the Notes Side Pane; expands: expands the height downwards)

    Example: refer to the graphic below, Example B, Step 1.3

  • If the user inserts Notes User Data in a small Note Window and there is neither enough and/or visible space available, then the Notes Functionality must... (small: the height of the Notes is adjusted for less than three lines of Notes User Data; visible: the space visible for the user; space: space in the Notes Side Pane)
    • expand the Notes Window to fit to the amount of Notes User Data.

      Example: refer to the graphic below, Example C, Step 2.1

    • pan the view port area to completely show the Note Window inside the Writer Document Window.
    • Rationale: This is a very special case. If we want to keep the position of the other Notes Windows stable during editing, we have to chose this kind of implementation (overlap parts of the subsequent note). Anyway, we should wait for some feedback from the user base.
  • If less space is available for the Notes Window than it is required to completely display the Notes User Data and the Notes Window has normal size, the Notes Functionality must provide scrollbar functionality inside the Note Window. (space: space in the Notes Side Pane; normal size: the height of the Note Window fits to three lines of Notes User Data; scrollbar functionality: refer to “Design of the Scrollbars”)

    Example: refer to the graphic below, Example C, Step 2.3

Inserting and Editing Notes

The graphic shows: The insertion of Notes (Step 1.1 to Step 1.4) and the editing of Notes (Step 2.1 to Step 2.4) in different situations. The situations show different amount of Notes User Data and different count of already shown Note Windows. Please note: The intention of this graphic is to start a discussion of the Notes behavior. Hopefully, the graphic is self-explanatory. If not, then more detailed information can be found in the text above this graphic. The situation in Step 2.4 of Example D is a bit simplified. Here, the size of the yellow note is the same like in the previous step although there is some more text in it. The real size is based on the amount of Notes User Data there and in the other notes.

Open Point: What to do with notes bigger (e.g. higher) than the current Document viewport? I propose to not do any scrolling/panning if those Note Windows get the focus (e.g. by viewing/editing). So, the text cursor inside the Note Window should affect the scrolling behavior of the Document text and simultaneously the Notes Side Pane.

Please note: The subsequent text refers to the number of text lines representing the Notes User Data. This is a bit unspecific, because the inserted text may be formatted in (e.g.) a larger font size and therefore lead to a bigger Note Window. For this first version of the specification, the focus is on Notes User Data text in standard formatting.

Selected Design

• The proposal "Simple Static Note Window Distribution" has been selected for implementation.
• The proposal "Reduce Maximum Height of Note Window" will be used if there is a need to show a large number of Note Windows in the Notes Side Pane.
• The proposal "Window Distribution when Inserting/Editing Notes" will be used for inserting/editing of Notes.

The Future: Instead of showing all the Notes, future implementations of the Notes functionality will make it possible to select the ones to be shown. Then, the user may be able to select "show all notes since my last editing" to get only those Notes Windows which were created, modified or which have a reply. This will improve the situation for the user.

Implementation

tbd

Code Changes

tbd

Outstanding Issues

tbd