Editor shows plugins contributions in different orders at different times

[pombredanne]

This is weird...
This happens both with HEAD and with the version @ annotateit.org
The order of things being displayed in the editor popup seems to change based on how the selection was done
Say for simplification that only the Tags plugin is loaded...

1. I select text with double click, the editor has comments at the top, and the tags below.
2. I select another text with double click, the editor has comments at the bottom, and the tags input above

See this short screencast for a visual representation

[pombredanne]

This may have been introduced imho by this issue #28 and commit: 8523ab6

While I understand the need, changing the order of things is weird.

Another possibility is that the iteration order over the list of contributed editor fields is not stable

[aron]

When the editor cannot fit at the top of the screen it is inverted. As illustrated both in your video and the image below.

When flipped, the button bar remains closest to the highlighted text. The fields are reversed to maintain order, with the each field being in the same position relative to the submit/cancel buttons.

The main reason the comment box appears at the bottom is because it has a draggable handle to increase it's size. The widget itself is anchored to the highlighted text and user should drag away from the anchor in order to increase the size of the text area. Placing the textarea at the bottom and reversing the fields was the simplest way to achieve this.

Your video does highlight a couple of other issues, one that the comment box does not get focus when inverted (recently fixed by Nick) and that it's also missing it's styles (something I'll fix when I get a minute).

I hope this explains the reasoning behind the decision.

[nickstenning]

Hmmm. I think the inversion is fine, but a close viewing of @pombredanne's video shows that there's something else funky going on here. Every selection he makes is near enough the top of the viewport to trigger inversion, but the ordering still swaps (?) between activations. Perhaps the inversion state is toggling?

[pombredanne]

@aron :
While I understand the technical rationale and difficulties, I feel rather strongly that this is a bad surprise for a user (me in particular).

I need to adjust each time I do an annotation as the controls and fields in the viewport can move around. Each new annotation requires me to think about where I should click next or how many tabs will get me to the next field (based on the changed tab order) and to adjust my understanding of the application behavior accordingly (which means this is not a routine anymore): I cannot go into a groove, and this is going in the my way of being productive. I would strongly advocate for having stable UI behavior, so that what matters most after I made a few annotations and the UI became familiar is annotating, not the annotator UI changing.

That said, I think a solution would be to have always:

• the button bar at the bottom of the view port
• the resize handle at the lower right corner of the button bar in particular since even though it may affect the comment field size only, it does resize the whole viewport anyway
• always keep the order of the editor fields as they were contributed initially in the annotator configuration

[nickstenning]

Okay, I think a good solution would be:

• main textarea always on top
• plugins always in order loaded
• resize handles placed wherever needed in order to make the above two constraints work

[pombredanne]

@nickstenning your proposed approach makes best sense for me, though we could specify where the resize handle should be.

We could either :

1. put four resize handles, one on each corner, making the issue of position moot. This is the approach taken by gnome and windows for instance. You could provide no handle graphics and instead change the cursor when you hover over a resize handle corner hot area (the way gnome and windows do it), or just show the graphic when you hover the corner, or show it at all times
2. put only one resize handle always at the lower right corner, regardless of whether convenient or not for the user:. This is the macosx approach
3. move it around at one of the corners, based on the where the viewport is positioned relative to the page/div to annotate. The corner should then be the one pointing towards the "center" of the page or div or towards the biggest expanse of visible stuff . I am under the impression that this is the behavior we have today

My preference would be 1. and the simplest would be imho 2. .... 3. seems the most complicated and least common way of handling this

[nickstenning]

For reference, the solution (in fabb339) is to display the single resize handle in the top-right or bottom-right corner of the textarea, and not of the whole editor widget. Since the effect of the resize is primarily to resize the textarea anyway, I think this is a sensible solution.

[aron]

Just pulled this down. Looks like you're missing the top border on the button bar when displaying the editor below the selected text.

I think the solution, while closing this ticket, is a bit of a hack. Having the drag handle in the middle of the widget is a bit disconcerting to use. I'd have much rather fixed the css and tabbing issue and left the ticket open until we had more feedback from other users.

[nickstenning]

Ok, that's a fair point. I have some other stuff to push, but once that's done I'll back out this change and recommit it on a branch (fixing the missing border as I go). I'll leave this issue closed, but will file a pull request for this change and we can solicit feedback. Alright?

[aron]

@nickstenning that sounds perfect, I'll get a post up on the mailing lists this evening to let people know. I'm wondering if we can get a demo page up with the new code, perhaps on JSBin or something, for people to try out?

[bruml2]

I would suggest enlarging the textarea automatically (no user interaction) when it becomes three-quarters full. The button bar should always be at the bottom. And the icon which appears on highlighting should not disappear off the top of the viewport when dealing with the first line.