Documentation for a historical release of Infusion: 1.3
Please view the Infusion Documentation site for the latest documentation.
If you're looking for Fluid Project coordination, design, communication, etc, try the Fluid Project Wiki.

Comparison of Reorderer Keystrokes with DHTML Style Guide

Owned by Joseph Scheuhammer
Last updated: Jun 10, 2008Version comment
6 min read

Note: this discussion is relative to the current version of:

Anticipating the main conclusion, Fluid's Reorderer is specifically for reordering items within a container. Reordering is not a general context for drag-and drop (dnd); rather, it is an instance of dnd. In contrast, the ARIA best practices and the DHTML style guide are addressing the general case, or how to handle dnd in any/all cases. Nonetheless, there ought to be consistency between the general case and a specific instance thereof.

With that in mind, here is a blow-by-blow comparison.

1. Choose the items to drag.

DHTML style guide: use SPACE to mark an object or objects to be dragged. This implies that the user is in a "selection-mode" since SPACE is used for other operations in other contexts. For example, SPACE activates a menu item. (Note that there is no keystroke in the style guide for how the user gets into selection-mode).

Reorderer: the items to be dragged are confined to a container. When the container gains focus, one of the items within is selected. This is analogous to navigating to a menu or a toolbar - one of the menu items or tool bar buttons is "armed" upon the menu or toolbar gaining focus. Users can then arrow among menu items and tool buttons. Similarly, users arrow among the items within the Reorderer's container. There is no need to use the SPACE key to mark the item to move since, once it has been navigated to, it is selected.

At present, the Reorderer supports moving only a single item, although that item could contain a number of other things (e.g., the item is a list containing N list items; moving the list moves all the list items within at once). The Reorderer may well support multi-selection in the future. My intuition is that it will use shift-arrow for that; similar to what one would use on the desktop for lists, trees, table cells, and so on.

Conclusion: SPACE should be replaced with either no key or some other more natural keystroke, something along the lines of: If focus is moved to a container or contained item by some keystroke, then the focussed item is the selected object.

2. Indicate that selection is complete.

DHTML style guide: CONTROL+C indicates all the objects have been selected, and are ready to be moved.

Reorderer: the item is moved by using CONTROL+ARROW (ARROW to navigate/select, CONTROL+ARROW to move). In a sense, the press/release of the CONTROL key toggles between navigate-mode and move-mode.  (Aside:  testing with JAWS revealed that it already used ARROW keys.  The Reorderer also supports the keys I and M for vertical navigation, and J and K for horizontal, specifically for JAWS.  Again, the CONTROL modifier toggles between navigation-mode and move-mode). The Reorderer's default keystrokes can be configured or overridden as needed. All Fluid components provide fully customizable key bindings, which will be supported by a user preferences editor in the future.

3. Navigate to the drop target.

DHTML style guide: Use a combination of TAB and ARROW to navigate to a drop target. The intent here is that navigation is accomplished by the usual keystrokes for the web page/app, although, in addition, the system is in a drag-mode state. That is, something is remembering the items to be dragged while the user TAB/ARROW navigates among drop targets.

Reorderer: the item is moved by using CONTROL+ARROW (see above). An important aspect here is that the drop target is conceptually the container that the items are within. Thus, movement is confined to that container. (Recall what the Reorderer is for, namely, re-ordering items within a container).

Comment: The difference between the style guide and the Reorderer is pointing to a more general distinction, that between drag-and-drop within-a-container vs. between-containers. The Reorderer is specifically for the within case. ARIA and the style guide are addressing all dnd scenarios. It's possible that the Reorderer is showing that the keystrokes are different for the two scenarios; and, furthermore, that it's simpler for the within case.

4. Drop the dragged items onto the target.

DHTML style guide: one of two gestures:

a) CONTROL+V to drop and perform the most intuitive action ("copy", "move", or "create a shortcut"). Compare with dragging a file icon using the left mouse button. If the file is dragged to a location that is still within the same volume, then the operation is move. It's copied if it's dragged between volumes.

b) CONTROL+SHIFT+V to offer the user a set of options on how to complete the drop. The options are "move", "copy", or "create a shortcut". Compare this with dragging a file using the right mouse button in Windows where a menu pops up upon dropping the item. Upon selecting one of the options, the item is so dropped.

Reorderer: The Reorderer is limited to moving only (reordering, as it were). Steps two, three, and four are all accomplished by repeated CONTROL+ARROW keystrokes until the item is in its new location. The user ceases movement by releasing the CONTROL key.

5. Abandon the whole operation.

DHTML style guide: ESC abandons keyboard based dnd at any time.

Reorderer: nothing specific for abandoning; however, releasing the CONTROL key at the start amounts to abandonment. If the item has already been moved, the only way to put it back is to move it back.

What is missing from both the style guide/ARIA and the Reorderer is an undo operation, especially if a large number of items are involved. Even if moving a single item, the capability of quickly reverting is useful since it is relatively more work to undo each step as opposed to a single gesture meaning "undo".

Conclusion

Fluid's Reorderer has a set of intuitive, straight-forward keystrokes for moving items within a container. Its purpose is for a specific context where dnd is useful. It does not cover all dnd scenarios. Still, there are some lessons to learn:

  • use keystrokes for selecting items that would be used normally, such as ARROW and SHIFT+ARROW.
  • no need for a set of operations when the context determines that there is only one. That is, in a re-ordering context, users know that all they can do is move items; "copy" and "short-cuts" are not part of this context, and need not be offered to the user.
  • dnd-within a container is different from dnd-between containers, and may lead to a simpler set of keystrokes.  In other words, it may indicate that the set of keystrokes are context dependent.

That last point deserves some reflection. I suspect that different dnd contexts require different sets of keystrokes.  The keystrokes for the Reorderer were "obvious".  Why?  Because, initially, focus was on the overall function of re-orderering items within a container, and not on dnd per se.  Once that function had been established, then it made sense to ask what keystrokes to use.

Examination of other common use cases will lead to interactions that are measurably better, clearer, and more intuitive than trying to roll the entire realm of divergent activities into a single interaction.  That is, one starts by focusing on the user's underlying goal and then designs an interface that most directly enables it (aside:  yes, I'm advocating Fluid's approach here).

It doesn't have to be an either/or situation.  The general case, as documented in the DHTML style guide, may be useful as a fall back.  Common specific uses cases include reordering, free movement of items on the screen (e.g., windows, content layouts, etc.), cut/copy/paste, movement between containers, making references/short-cuts, and opening/launching items.  Each are very different and could be most intuitively accomplished with different keystrokes.

One final thought:  the style guide's recommendation are, for the most part, identical or similar to known UI's -- they are based on desktop applications.  That is, they have a precedent, and that precedent is decades old.  In contrast, dnd lacks that precedent.  There are (almost) no keyboard equivalents for dnd on the desktop.  The closest is cut/copy/paste, but not all dnd amounts to cut/copy/paste.  I suspect it will take time to come up with a set or sets of natural, intuitive keystrokes for the various forms of dnd.