Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344184

Summary:	[diagram] Link label highlight has various issues
Product:	z_Archived	Reporter:	Troy Beecroft <troy.beecroft>
Component:	Sapphire	Assignee:	Ling Hao <ling.hao>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	konstantin
Version:	unspecified	Keywords:	usability
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Troy Beecroft

2011-04-28 15:07:42 EDT

Build Identifier: 

When you select the label for a link you get a highlight with drag handles on it. There are various issues with the way this works right now.

1. The positioning of the highlight obscures the text at left and bottom.
2. The label doesn't actually appear to be resizable. Dragging handles on the right or the bottom appears to no-op. Dragging handles on the left or top actually repositions the label - which is clearly unexpected.
3. Also, the reposition pointer has a very small hot spot - apparently it's only when you hover over the highlight border, but not over any of the handles. This makes it very easy to miss - nearly impossible on small labels. It's more common that the reposition pointer appears whenever you hover over the object, rather than just the edge of the object.

If the label isn't going to be resizable (and I'm not sure there's a good reason for it to be) I don't think this is the right highlight to use at all. 

However, I do think it's important to give a clear indication that these labels can be repositioned, since it's often desirable to help graph readability and yet not a commonly supported capability, so I doubt many users would think to drag the label with showing the "reposition" pointer.

Reproducible: Always

Comment 1 Konstantin Komissarchik

2011-04-28 15:13:37 EDT

One of the difficulties here is editing the label. Since the label is editable, showing reposition pointer whenever one hovers anywhere on the label isn't going to work. Users aren't going to know that they can edit the label.

Comment 2 Troy Beecroft

2011-04-28 15:47:35 EDT

Yes.  Just having a slightly wider hot spot for that pointer might do the trick. 

There may be some little tradeoff in conveying what actions are possible. Between the two, I'd come in expecting the label is editable - and would try typical things get it into edit mode. On the other hand, I had no expectation that the label can be repositioned - which is a nice remedy for some situations - so it'd be good to make that more apparent somehow.

Comment 3 Konstantin Komissarchik

2011-04-28 15:55:30 EDT

> There may be some little tradeoff in conveying what actions are possible.
> Between the two, I'd come in expecting the label is editable - and would try 
> typical things get it into edit mode. 

I am not sure that you would expect to be able to get into edit state if hovering anywhere over the label displayed the reposition cursor...

Here is one possible approach for non-resizable labels... Once label is selected, there is a border and a single marker (square or whatever) in one of the corners (pick one). Hovering over or near the marker displays the reposition cursor and allows repositioning.

Comment 4 Troy Beecroft

2011-04-28 16:07:07 EDT

> I am not sure that you would expect to be able to get into edit state if
> hovering anywhere over the label displayed the reposition cursor...

I agree - it wasn't a very good idea. My point with the comment was just that I'm more inclined to explore how to make something editable, because I expect to be able to do that... moreso, than with reposition. 

But ideally we'd find a way to convey both affordances. I think your last suggestion does that nicely.

Comment 5 Konstantin Komissarchik

2011-04-28 21:51:06 EDT

Thinking about this some more... 

The label behavior is inconsistent with nodes. For nodes, you just get the selection outline, no handles and never see reposition cursor. The two should be consistent. I am inclined to drop all handles from non-resizable labels. Outlining label on selection should be enough affordance to queue someone that they can manipulate the label, even if there is no explicit reposition cursor.

We should only show handles if item is resizable. Handles should not be used for moving.

Comment 6 Troy Beecroft

2011-04-29 11:01:47 EDT

(In reply to comment #5)
> Thinking about this some more... 
> The label behavior is inconsistent with nodes. For nodes, you just get the
> selection outline, no handles and never see reposition cursor. The two should
> be consistent. I am inclined to drop all handles from non-resizable labels.
> Outlining label on selection should be enough affordance to queue someone that
> they can manipulate the label, even if there is no explicit reposition cursor.
> We should only show handles if item is resizable. Handles should not be used
> for moving.

Using the same highlighting as nodes had occurred to me too. I like that idea. 

I still think it's desirable however to convey the drag affordance.  It's not critical for nodes because it's a common expectation that they're draggable. I'm pretty sure this is the first time I've ever seen draggable link labels though. Activating the reposition pointer at the edge of the label - or some similar affordance - would still be a handy thing so users can take advantage of this feature.

Comment 7 Konstantin Komissarchik

2011-11-02 22:09:54 EDT

Bulk deferral of diagram-related items to the 0.5 release.

Comment 8 Konstantin Komissarchik

2012-05-17 17:37:55 EDT

I think we can consider this resolved. Likely happened as part of dropping Graphiti. The main points are addressed. There are no more handles. Just a thin outline. The entire thing is draggable. This addresses #1 through #3. The remaining question as to whether there is sufficient affordance of label's draggability and editability can be tracked separately if we get some indication from users that this is a confusing aspect.

Closing as verified.