Issue 89140

Summary: [notes2] make notes position dragable via mouse
Product: Writer Reporter: andreschnabel <andre.schnabel>
Component: editingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: christoph, issues, max.odendahl, tj
Version: BEA300m2   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description andreschnabel 2008-05-07 21:08:12 UTC
Looking at the new notes implementation, esp. the triangle anchor, it was a good
idea to make this anchor dragable via mouse.

This is not covered by the current specification

If considered for implemetation we need to take into account, that notes can be
anchored on a text range in future versions of OOo. Such notes should not be
dragable.
Comment 1 max.odendahl 2008-05-07 22:13:33 UTC
>>text range......Such notes should not be dragable.

you could of course also change start/end of a range with this, see also
http://wiki.services.openoffice.org/wiki/Notes2_Design_NoteAnchor#Proposal_.22Resizing_.28Note_Anchor_Area.29.22
(make only sense at left and right, not at top and bottom, as the range must be
continuous)
Comment 2 christoph 2008-05-08 20:41:34 UTC
Hi André, thanks for your idea! We considered it some time ago - unfortunately -
came to the conclusion to reject it. The main reason is, that we did not find a
use case (or some use cases) that would justify the increased complexity for the
user. Please refer to StR22 at
<http://wiki.services.openoffice.org/wiki/Notes2_RequirementsFromUseCases>
(Sorry, it has not been translated. But it should not be a problem for you, I
think.)

If you have something in mind that we may have missed, then please explain it -
maybe we have been wrong.

The main reasons for our decision are:
* A Note belongs to content in the text. Moving the reference point (Anchor)
does only make sense if the content in the Note is not dependent on the Anchor -
that should be a rare case. (The Note is different to e.g. a frame or a graphic)
* If the document text is changed, then the Anchor will moved according to the
text (so the manual re-positioning of the Note is not necessary)
* The reference position can changed by copy and paste of the Note or the Note
content (with some manual effort) - so it is possible at all.

I would like to close this issue, but before I would like to have your comment
on that. Thanks a lot! Christoph
Comment 3 andreschnabel 2008-05-08 21:49:55 UTC
some use cases:

- a note is attached to the wrong context (e.g. the note has been anchored at
paragraph A but the information rather belongs to paragraph B) the Author /
reviewer jut likes to corect this mistake (this is what is written in StR22)

- Author needs to rewrite a paragraph completely but wants to keep the note.
This can easily be achived by dragging the note to another parapragh, rewrite
the paragraph (what would delete the note at the old position), then drag the
note back to the now new paragraph

- reorder notes so that they are in a logical sequence (usefull for display in
side pane and navigator)

Dragging with the mouse is the more obvious way to the user for following reasons:
- the anchor (triangle) and connection line is a good visible elemnt of the UI
it is very similar to grafical elements, that are usually draggable
- the reference position is invisible to the user (actually it is a zero-width
character). The user is not able to identify this position (al lons as she does
not knowabout the implementation). Without further explanation the user will not
be able to copy and paste the note

so we would even reduce complexityfor the user (she needsonly to know about the
visible elements and not about the invisible notes position)
Comment 4 max.odendahl 2008-05-09 14:38:16 UTC
Thinking about it and reading at users@de it makes really sense IMHO in the
following situation:

- note refers to e.g. a complete paragraph
- note is inserted *somewhere* inside this paragraph (note: we do not have note
ranges)
- now I e.g delete the sentence inside this paragraph, in which the note was
randomly inserted, this would kill the note as well
- so I want to move the note to some other location in this paragraph first
before deleting the sentence

Now I could copy the note with 

- Ctrl - Alt - Page Down/Up
- Ctrl - Right
- Ctrl - X
- move cursor 
- Ctrl - V

if I actually know that a note is only a character inside the text. 

Just moving the anchor with the mouse to some other place sounds a lot cooler
and easier, so I don't think this includes increased complexity

Conclusion: +1, would be cool to have
Comment 5 christoph 2008-05-09 23:55:33 UTC
Hi André, thanks for the reply. Before I start I just want to add that I
understand the demand itself. Every added feature does not only provide added
value to some user, it also provides effort for other users (more learning,
added complexity, ...). So it's important to balance added value and added effort. 

> a note is attached to the wrong context (e.g. the note has been anchored at
> paragraph A but the information rather belongs to paragraph B) the Author /
> reviewer jut likes to corect this mistake (this is what is written in StR22)
... which can easily be solved with the current functionality. It creates manual
effort, but seems a rare case. If a user adds the Note to the wrong context, we
should first focus on our usability before the Note is inserted.

- Author needs to rewrite a paragraph completely but wants to keep the note.
This can easily be achived by dragging the note to another parapragh, rewrite
the paragraph (what would delete the note at the old position), then drag the
note back to the now new paragraph
... here, the user would move the right Notes information to the wrong context
(in document text). And we don't help much if the Note accidentally stays there.
Technically, it is possible to let the user edit the text without deleting the
Note (if the Notes are shown). 

> - reorder notes so that they are in a logical sequence (usefull for display in
> side pane and navigator)
Here, the problem is the Navigator, not the Notes itself. I hope it will be
possible to extend the capabilities of the Navigator. Some ideas have been
collected at "Sort and filter notes" at
http://wiki.services.openoffice.org/wiki/Notes2_OtherIdeas

> Dragging with the mouse is the more obvious way to the user for following >
reasons:
> - the anchor (triangle) and connection line is a good visible elemnt of the UI
> it is very similar to grafical elements, that are usually draggable
> - the reference position is invisible to the user (actually it is a zero-width
> character). The user is not able to identify this position (al lons as she does
> not knowabout the implementation). Without further explanation the user will not
> be able to copy and paste the note

Why should a Note be copied if it refers to a dedicated text block which itself
could be copied (and then should keep the Notes information)?

Here the assumption is, that the people think in "anchors" and not in Notes.
Many other people will just 

You are right with the visible elements - but I assume that many people will
also think in "Notes Windows" instead of "Note Anchors" to sort them. That was
the reason to not use anything that could look like "draggable" elements in the
Notes Windows.

> so we would even reduce complexityfor the user (she needsonly to know about the
> visible elements and not about the invisible notes position)

If the core requirement is to add additional information (Notes) to certain
sections of text (and both do have a strong link in terms of content), then
there is still no need for this kind of feature.

Maybe we should this discuss that in another place but the Issue Tracker.

Bye, Christoph
Comment 6 christoph 2008-05-20 23:19:49 UTC
@all: Started discussion on the User Experience mailing list [1]. The goal is to
collect use cases to better judge that request.

[1] http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1759
Comment 7 max.odendahl 2008-07-21 18:46:20 UTC
copied from issue 91889:



There are times, after editing a document and adding/removing a significant
amount of text, when a preexisting note no longer is in an appropriate location
in a Writer document and should be moved.

Right now, the only way to move a note is to select the character immediately
after the note's triangle insertion point/sub-caret (I don't know what the
proper term for it is) and then dragging that character to the spot you want the
note relocated to.

If the character cannot be used in the place you want to relocate the note to
(because it is not in a word in that vicinity) you must edit the note, copy the
contents to the clipboard, delete the note, create a new note in the desired
location, and paste the clipboard back into the note.

Having the ability to drag and drop the note's attached/insertion point without
affecting the text in the document would be a wonderful feature.
Comment 8 max.odendahl 2008-07-21 18:46:26 UTC
*** Issue 91889 has been marked as a duplicate of this issue. ***
Comment 9 max.odendahl 2009-04-23 06:10:11 UTC
one more from issue 101275:

"It would be great if the insertion point of a note in the text could be moved by
dragging the small triangle to a different position in the text. 
Often in text that is heavily edited, notes can end up in wrong positions. So,
instead of having to create a new note, copying its content and deleting the old
note, it would be great if the insertion point could just be dragged with the
mouse to the new position"

Everyone I talk to about the notes tell me that is missing, so we should really
do this...
Comment 10 max.odendahl 2009-04-23 06:10:43 UTC
*** Issue 101275 has been marked as a duplicate of this issue. ***
Comment 11 christoph 2009-04-26 12:37:48 UTC
@brendel, es: I guess that a feature which supports direct dragging of the Note
Anchor would make working with the document content rather hard.

I thought a bit about the request and added two more design proposals to the
"Notes2 Other Ideas" section. One of the ideas would solve several requests at
once: copying, moving and re-sizing of Notes Anchors. I don't know if it is
technically feasible.

Please have a look at "Move the Position/Range of the Notes Anchor" on the page:
http://wiki.services.openoffice.org/wiki/Notes2_OtherIdeas
Comment 12 max.odendahl 2009-04-26 14:58:20 UTC
why not just moving it with the mouse as well, this is what users expect as a
first possibility! I am not guessing here, I was told by several ones directly.

This does not mean of course that we should not have additional helpers in the
drop down menu for people who do not expect the simple mouse drag behaviour.
Comment 13 T. J. Frazier 2009-04-27 06:00:02 UTC
UX has really blown it on this one. In their preoccupation with user cases, they
have neglected user /expectations/. Even for us programmers, who are not always
the most aware people in the world, ignoring user expectations is a fairly
serious transgression. In UX, this is very disappointing, indeed.

In the hierarchy of design principles, user expectations stands higher than case
analysis. They should have taken one look at that beautiful graphic triangle,
and said, "Oh, that's /obviously/ drag-able, make it so," and approved the
issue. They should have approved it even if nobody could think of a single case
where a user would want to do it.

Instead, they cavil about user complexity! Apparently, they have also forgotten
the fundamental principle of a GUI: its use is supposed to be /intuitively
obvious/. Users might ask themselves, "How do I--" and stop right there: "Oh,
all I need to do is click and drag." Learning time: zero. Execution time (user
time spent on the task): two seconds or less. None of the proposed alternatives
approach this efficiency.

I hope they get their heads on straight, and approve this issue. I'd like to
drag notes, myself--out of the construction zone!  /tj/
Comment 14 christoph 2009-04-27 20:06:31 UTC
@tj:
Sorry that you think UX missed the point here, since we are required to include
future functionality in our analysis. So what about Note Anchor Areas, which can
span several paragraphs? I'm open for a concept which is easy to understand and
don't hinder people to work with the document text (primary goal and also an
user expectation). Even if a document contains many Note Anchor Points, it may
be hard for users to place the cursor in the near of a desired text area (using
the mouse).

There might be another approach - selecting the Notes (like usual frames) might
activate this mode. But, there still has to be a more accessible alternative,
e.g. via keyboard.

If you want to discuss this in detail, I would like to invite you to continue
the thread on ux-discuss (link in comment 2008-05-20).
Comment 15 T. J. Frazier 2009-04-29 20:26:35 UTC
Reading all of the pages in Category:Notes2 (except the bits in German: "Ich bin
Ausländer und spreche nicht gut Deutsch."), and following most of the links, I
find much excellent design work to praise and admire. Perhaps the problem is
that, in looking at all those lovely trees, someone has lost sight of the
forest: the basic GUI design integrity.

UX's involvement in future functionality is both laudable and essential. It
allows you to say, with basic principles sorted out, "This drag ability is a
fundamental part of the GUI design, and *shall* be implemented. Therefore,
future planned extensions *shall* accommodate this, and *should* provide similar
functionality."

I will provide design suggestions on the Wiki. My criticisms here are
architectural in nature; paraphrasing Brooks, an architect *shall* be able to
offer architecturally-compliant design suggestions, if asked. I presume that
applies to architectural critics, too. :-) /tj/
Comment 16 Rob Weir 2013-07-30 02:42:56 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.