This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Improve UI when reordering tabs using mouse | ||
|---|---|---|---|
| Product: | platform | Reporter: | _ gtzabari <gtzabari> |
| Component: | Window System | Assignee: | Stanislav Aubrecht <saubrecht> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 70468 | ||
|
Description
_ gtzabari
2013-04-16 20:19:58 UTC
Is this issue being considered for 7.4 (as the original issue was)? (In reply to comment #1) > Is this issue being considered for 7.4 (as the original issue was)? No, it isn't Btw, it is possible to turn the drag window image off in Options window. The more I look at this, the more I think we have a bigger a usability problem. It is true that excessive repaints can be disabled by disabling that feature, but the bigger elephant in the room is that the drag-n-drop interface isn't intuitive.
1. Drop targets should be highlighted up-front! Because drop targets are not highlighted, users are forced to the slide mouse across the entire screen to discover possible options. When I say highlighted I don't necessarily mean by color. I mean we need visual cues to make drop targets more obvious up-front.
2. Different drop targets must lead to different results! For example, drag a window to the right border of the Projects tab. You will get two possible drop targets: one is a narrow vertical bar, the other is a wider vertical bar. When you drop the window, they yield the same result. You should ensure that every drop target will yield a different result, otherwise remove the duplicates.
3. Only highlight the differences! When I attempt to reposition an editor window from one tab position to another, the entire window border is highlighted. The user is looking for changes ("what will change if I drop the window here?") and instead of showing him only the difference, you're showing him *everything* (the border). This is overwhelming and confusing.
4. Add meaningful animations! When I insert a tab between two other tabs in Chrome, the tabs "slide" out of the way. If you do this right (only repaint the tabs, not the entire window) then Remote Desktop users will be able to appreciate it as well.
(In reply to comment #4) > > 1. Drop targets should be highlighted up-front! Because drop targets are not > highlighted, users are forced to the slide mouse across the entire screen to > discover possible options. When I say highlighted I don't necessarily mean by > color. I mean we need visual cues to make drop targets more obvious up-front. Not a good idea. With the default layout (Editor/Projects/Navigator/Palette/Properties) you'd get almost 30 different possible drop locations. Visualizing this would be quite a mess. > > 2. Different drop targets must lead to different results! For example, drag a > window to the right border of the Projects tab. You will get two possible drop > targets: one is a narrow vertical bar, the other is a wider vertical bar. When > you drop the window, they yield the same result. You should ensure that every > drop target will yield a different result, otherwise remove the duplicates. They do, that's why there's a different drop feedback. One location turns non-editor window into editor window, the other creates a new non-editor mode. > > 3. Only highlight the differences! When I attempt to reposition an editor > window from one tab position to another, the entire window border is > highlighted. The user is looking for changes ("what will change if I drop the > window here?") and instead of showing him only the difference, you're showing > him *everything* (the border). This is overwhelming and confusing. Yes, this could be fine tuned. > > 4. Add meaningful animations! When I insert a tab between two other tabs in > Chrome, the tabs "slide" out of the way. If you do this right (only repaint the > tabs, not the entire window) then Remote Desktop users will be able to > appreciate it as well. A nice eye candy but no improvement from usability point of view. (In reply to comment #5) > Not a good idea. With the default layout > (Editor/Projects/Navigator/Palette/Properties) you'd get almost 30 different > possible drop locations. Visualizing this would be quite a mess. Perhaps show all drop targets in the current "zone" (e.g. editor) and only show one drop target per other zones. Meaning, when the mouse is dragging over the editor, you'd see all drop targets for the editor, but only one drop target for the project, navigator, etc. If you then slide the mouse into the project, its drop targets expand and the editor ones collapse into one drop target. > They do, that's why there's a different drop feedback. One location turns > non-editor window into editor window, the other creates a new non-editor mode. Visually, I see no difference. The committers might know the difference, but there are no visual cues for it which is a problem. > A nice eye candy but no improvement from usability point of view. Agreed, this is low priority. I agree with the necessity of the original idea. There is no need for the whole window to redock if you only want to change the position of the tab using a mouse - like in firefox. Also it is currently not possible to drag a tab close to another tab that is currently not visible. *** This bug has been marked as a duplicate of bug 208921 *** |