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.

Bug 83210 - HIE feedback on sticky palette
Summary: HIE feedback on sticky palette
Status: NEW
Alias: None
Product: xml
Classification: Unclassified
Component: Schema Tools (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Chris Webster
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-22 15:52 UTC by Chris Webster
Modified: 2008-12-05 17:47 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Webster 2006-08-22 15:52:01 UTC
The following feedback was given at the end of a demo. Please provide feedback
considering the overall Enterprise Pack user experience.

One thing I think would really make the user experience better is a "sticky
tool" feature. This would mean that if you click the element tool, you could
click on the design area multiple times to create many elements without going
back to the palette.

UML works like this by default and you right click the diagram area or Esc to
get back to the default pointer.

I think the best of both worlds would be single click a palette tool for single
element creation, and double click for sticky, multiple element creation.
Comment 1 Jiri Kopsa 2006-08-22 16:44:07 UTC
Ultimately all the palettes in NetBeans IDE should follow the common pallete UI
specification:
http://ui.netbeans.org/docs/ui/palette/index.html

This specification actually defines three mouse manipulation styles:
1. Pick and drop: A single-click on item in the Palette selects it. Selected
item remains active and user can use it more then once by dropping multiply in
the editor or unselect it back by another single-click.
2. Drag and drop: User can drag&drop items from the Palette into the editor
surface and then the palette doesn't remember the selected item.
3. A double-click on a Palette item creates a new item in the editor at the
default location. The location depends on type of editor. It should be position
of a text cursor for text editors and for the visual editor the location depends
on logic in that editor.

However, it's up to individual feature owners which of the style they implement.

I think that for most of the visual editors style #3 does not make much sense,
#2 is a must and #1 is optional (a productivity enhancement).
Comment 2 Chris Webster 2006-08-23 17:03:50 UTC
The Schema design view editor currently implements #2. We had a suggestion to
implement #1, my question would be how to handle selection. In #1 if you select
something from the palette, then how would the selection work in the design view. 
Is the following Scenario correct?

* User single clicks element in the palette
* User selects an element in the design view - a sub element is created. If the
user wanted to expand that element, they would need to delete all the child
elements created in the tree. 
* Once they get to the right level in the tree, then clicking multiple times
would add that many of the selected items. 

Is this a reasonable approach. For the design view, I don't see that #3 is
really useful and #2 is implemented. I do want to make sure we have an easy way
of creating lots of elements and attributes quickly without having to go to the
palette multiple times. 
Comment 3 Jiri Kopsa 2006-08-23 18:32:11 UTC
It seems, that what Chris describes is appropriate, let me put it more clearly:

Scenario for Palette interaction #1 (Pick and Drop) in the Design View of XSD
Editor:
1. User single clicks an artifact in the palette.
2. IDE switches to "drop mode", i.e. it starts giving visual feedback as if the
user were dragging. (Look into Matisse.)
3. This way the user can add a child or a sibling.
4. After adding an artifact on the canvas (with a single click) the IDE remains
in the "drop mode" (This is broken in Matisse, it exists the drop mode after
adding a single component.)
5. User can exit the "drop mode" by unselecting the artifact in the palette
(another single click on the selected artifact), or with an ESC key press.

This scenario implies that once the IDE is in "drop mode", elements cannot be
expanded or collapsed. This could be achieved by adding expand/collapse action
into contextual menus as the "drop mode" does not affect right mouse clicks.

As a side note - let me say that a productivity enhancement (being able to add
multiple artifacts quickly) could be also achieved by keyboard navigation (key
arrow press should navigate in the tree of elements) and insert short cuts.
Comment 4 Chris Webster 2006-08-25 23:19:08 UTC
Currently, in the design view when adding a new element or attribute the element
or attribute is immediately placed into edit mode. The element is selected and
the name can be changed. If we continue with this approach seems like an issue
will occur with selection. If the newly added item is selected then it will
become difficult to rapidly add a bunch of new things. 

Should the item just be editable but not selected if we use a key board
accelerator approach? This would allow me to add 10 child elements using the
keyboard accelerator, then go to each one and rename it? 
Comment 5 Samaresh Panda 2008-12-05 17:47:45 UTC
Chris, can you please update this?