Community
Participate
Working Groups
Sapphire diagram editor get the palette and its interaction from GEF/Graphiti, but after using the diagram editors for a while, I am not convinced that the palette creates good usability. I find that I am often in the wrong palette state from what I need to do and traversing the screen from the location on the canvas where i am working to the palette gets old in a hurry. I'd like to evaluate alternative diagram interactions that do not involve the palette. For instance... The default state can be selection/marquee. I see no sensible reason for those to be two separate states. Starting selection on canvas can activate marquee. To add a node, you right-click on canvas and pick the node type from the context menu. The node immediately appears at the location of the right-click. Connections require a bit more thought... Maybe context menu on the starting node to start the connection... I'd like to see some discussion happen here before choosing particular course of action...
Adding support for adding node types with the context menu on diagram makes really good sense regardless of the palette decision. While the palette may not be the best in terms of usability, it is a well worn pattern in Eclipse and I think Eclipse users who have used visual editors in the past are fairly familiar with it. What if you allowed for both, by default the palette could be collapsed, and some users who don't know about the palette will just use the default interaction available through context menu or whatever other patterns you decide on, but for those people who know about the palette and see it collapsed on the right hand side they could activate it and begin using it as per usual.
I agree we should be able to add new nodes from the context menu - it's a convenient and common approach. I wouldn't get rid of the palette though - some people prefer it and it's pretty much expected for a design view of this sort. The whole thing doesn't demo as well without it. I don't like the separate select/marquee/link drawing modes either. It's easy enough to accomplish all 3 gestures without the use of explicit modes, which are a pain and seem fairly antiquated. On the other hand, because these GEF components are used so much in Eclipse I'm not sure it's worth departing from a norm that's fairly well established - at least in this realm. It's at least a tradeoff that should be carefully considered.
My current proposal... 1. The palette remains, but is hidden by default. The palette only has items for nodes and connections. No item for cursor or marquee. 2. Nodes can also be added via context menu on canvas. 3. Connections can also be added via context menu on originating node. 4. The default state is selection. If clicking on canvas and dragging, we have the marquee effect. When node or connection is picked from palette, we momentarily enter node/connection state. The state exits when one node/connection is created or if canceled by ESC or right-click. This approach mostly retains the familiarity of the palette, which may be useful to some users, while largely eliminating stateful interactions.
Bulk deferral of diagram-related items to the 0.5 release.
Let's proceed with this using description in Comment #3. I am tentatively targeting this to Sapphire 8 release, but we will need to re-evaluate once we get a better handle on the implementation complexity.
In our adopter product where we use the diagram editor the most, we have implemented #2 and and alternate form of #3, so I'm glad to see these in the framework. What we did for #3 was we added an action to all nodes that says "start transition" and all it does is start the connection mode, so its like a shortcut to adding connections from that node as an starting point (see screenshot).
Created attachment 241247 [details] start_connection_action.png
Created attachment 241248 [details] start_connection_action2.png
I evaluated the state of this feature in topic-344027 branch and it's not bad overall, but there are a few items that I'd like to see addressed first before we merge and time is very short, so let's defer this to 8.1/9. 1. Need a better icon. I will see if I can find something suitable in Eclipse icons. 2. The labeling of the connect action needs to be adjusted. "Create Connection" should be "Connect"; "Create X" should be "Connect as X". 3. Probably should have a keyboard shortcut for initiating a connection, but not sure how you'd terminate the connection without a mouse. Troy? 4. The way that palette works is still not really stateless, even though it holds the state for less time. You click on an item. Then you can place. It would be better if the palette was something you dragged-n-dropped nodes, so that there is no concept of selection at all. 5. After playing around with this for some time, especially after we make changes for #4, I don't think that connections belong in the palette. Let's restrict the palette to nodes.
> 3. Probably should have a keyboard shortcut for initiating a connection, but > not sure how you'd terminate the connection without a mouse. Troy? What occurs to me is arrow keys for navigating to the target node and then Enter to commit/terminate the connection.
(In reply to Konstantin Komissarchik from comment #9) > > 3. Probably should have a keyboard shortcut for initiating a connection, but > not sure how you'd terminate the connection without a mouse. Troy? > We don't use keyboard shortcut for creating a new node. So not sure why we want keyboard shortcut for starting new connection? Using arrow keys for navigating to target node once in a connection creating mode can be problematic. Assuming "->" means moving to the node on the right, etc, what if you really want to establish connection between two nodes that are not adjacent to each other and are far apart? Using mouse to terminate connections seems more direct and easier... > 4. The way that palette works is still not really stateless, even though it > holds the state for less time. You click on an item. Then you can place. It > would be better if the palette was something you dragged-n-dropped nodes, so > that there is no concept of selection at all. > The palette is drag-n-droppable for nodes, e.g., you can click on a node and drag-drop onto the canvas to create and new node. You don't have to click on a node in palette and click again on the canvas to create new node.
> We don't use keyboard shortcut for creating a new node. So not sure why we want > keyboard shortcut for starting new connection? From basic accessibility standpoint, we need to ensure that all operations are keyboard accessible. > The palette is drag-n-droppable for nodes, e.g., you can click on a node and > drag-drop onto the canvas to create and new node. You don't have to click on > a node in palette and click again on the canvas to create new node. I see that I wasn't as clear as I could have been. I know that you can DND from palette today. My point is that the palette should only support DND instead of the current two modes.
(In reply to Konstantin Komissarchik from comment #12) > > We don't use keyboard shortcut for creating a new node. So not sure why we want > > keyboard shortcut for starting new connection? > > From basic accessibility standpoint, we need to ensure that all operations > are keyboard accessible. > First, I'm not sure whether a typical graphical editor can be 100% accessible using keyboard only. We don't have a keyboard shortcut for creating new nodes, we don't have one for moving nodes. Connection creating is probably the most complex operation. If want to achieve 100% accessibility using keyboard, we would need to take care of all these operations: node creation, node moving, zooming, etc. Say we want to achieve 100% accessibility using keyboard, what would be the keyboard shortcuts for all those operations? Especially connection creation in which we need to be able to identify source and target node?
We have a requirement that all UI must be accessible. You can handle keyboard accessibility of connection creation under this task or open another one. We will need to open similar bugs for other diagram actions that are not accessible.
Accessibility is tracked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=437974 This one deals with diagram stateful interaction.
> 4. The way that palette works is still not really stateless, even though it > holds the state for less time. You click on an item. Then you can place. It > would be better if the palette was something you dragged-n-dropped nodes, so > that there is no concept of selection at all. > > 5. After playing around with this for some time, especially after we make > changes for #4, I don't think that connections belong in the palette. Let's > restrict the palette to nodes. Shenxue and I discussed this on the phone and she pointed out that there are diagram editor scenarios, such as electrical circuit layout, that would call for a large number of connection types. Large number of connection types would benefit from palette placement, so we can't rule out connections in the palette (#5). Further, toggling a "starting connection" state in the palette is a reasonable and intuitive way to implement connections in the palette, so for consistency we need to support "about to place node" state as well, so that rules out #4. I am taking away these two requirements. We will likely need to make tool "stickiness" configurable as both behaviors can be desirable depending on the specifics of a particular editor, but we don't have to tackle that right now.
http://git.eclipse.org/c/sapphire/org.eclipse.sapphire.git/commit/?h=topic-344027&id=9c712ce3159f998e525a09413441b7da286baf91 takes care of escaping the node/connection creation state using escape key. It also fixes the wording for connection context menu. Please take a look. Other than the better icon issue, this bug should be considered "resolved". Thanks!
Verified the changes in the topic branch and merged the changes to master. 9 : http://git.eclipse.org/c/sapphire/org.eclipse.sapphire.git/commit/?id=5b3041d015d690a092944fc7427c462288be1272
