Suppose we have two data trees A and B visualized in the UI along these lines:

The user wants to copy the highlighted subtree nodes from A to B. The two trees have some shared nodes as indicated by the id's.

How would you design the interaction for this scenario? One possible approach would be to place checkboxes next to the non-shared nodes and an "execute"/"copy" button in-between the two trees, but is this the best solution when opting out on drag'n'drop?

An object-selection-action syntax like you suggest is a common standard GUI approach that good to use if you'll be extending it to commands other than copying (e.g., deleting, moving, properties). This makes for a simple, consistent, yet powerful UI. I’m not so sure I’d recommend checkboxes for selection, however. Assuming users typically only copy one upper-level node at a time, I’d imitate the behavior in file managers like Windows Explorer and use icons that are single-selected by default, but support multi-selection via metakeys (Shift and Ctrl) and drag-selection. Selecting a node should highlight that node and all its sub-nodes to help make it clear what the user is selecting. OTOH, checkboxes may be preferred if users usually need to copy multiple unassociated nodes, especially if you can’t be sure they’re familiar with standard multi-selection methods.

The alternative to the object-selection-action syntax is the object-dedicated-control approach where you include a small Copy control for each node. One click and it’s copied. This may be preferred if copying is the only thing the user can do with the nodes. In contrast, having separate Copy, Move, Delete, Properties, etc. controls for each node would likely be too cluttering. If you go with object-dedicated-control, you can present a Copy control only for the nodes in A that have shared nodes in B, providing a clear indication on what may be copied.

In your example, it looks like your Copy feature is limited to copying to shared nodes between the trees. Is that indeed all that can be allowed? Is there always no more than one destination tree? If so, your single Copy button is probably best, and you’re right to stay away from drag and drop. Drag and drop has poor discoverability and is harder to do than simply clicking a Copy button. Drag and drop may also make users think they can perform arbitrary copying (e.g., put Node 4 in Tree A under Node 18 in Tree B, or even move nodes around within Tree B).

If, however, it’s possible and advantageous to supporting arbitrary copying, then consider having two buttons to employ the Copy and Paste idiom (add a third Cut button to support moving). If you support arbitrary copying, then it’s worth considering also having drag and drop as an expert shortcut to Copy and Paste.

Thank you for the detailed answer. The UI is intended for users not very likely to be familiar with the use of metakeys. I think a global copy button/the like is more appropriate compared to objected-dedicated-controls. The copy feature is limited to copying non-shared nodes, and most often a top-level node and all it's children are selected collectively for copying.
–
agibOct 18 '10 at 16:54