I come to you with a dilemma that I think is most closely identified with 'user experience.' I'm wireframing a web application, yet this "free form" user area has posed a few interesting challenges.

My apologies for such a long question.

The "free form" user area is an empty canvas, where users can create "nodes." The nodes created however, should not be allowed to overlap... which begs the question: How will prohibited overlaps affect the UX of node creation, and what methods are best?

. . .

Edit: Single click 'n drag is already tied to dragging the canvas (think google maps,) so the closest available command is a "long click".

1.double click method, and problem:

node creation diagram

My initial idea was to have a double click event trigger the node creation (Fig 1.) The problem I see with this method is outlined above (Fig 2)--without some form of restriction, the user would be able to double click close to preexisting nodes... thus illustrating the problem with this approach.

. . .

2:drag 'n drop method:

alternate node creation diagram

An alternative method I thought of, would be to have a source node in the toolbar (not pictured.) The user would grab this source node from the toolbar, and drag it onto the canvas--allowing for a color change when the node was being held in an invalid position.

The problem with this approach is a reduction in UX value--dragging from the toolbar every time you want to create a node seems unrefined... so I merged the two:

3: Doubleclick 'n drop:

alternate node creation diagram

As much as I like this approach, I'm still not confident I'm accounting for all the factors; I'm a little hesitant to pull the trigger in any one direction.

I'm wondering if it's just best to develop 2 or 3 different interfaces, and split test them... does anyone have any ideas for how to handle the prohibited behavior, and more specifically, what approach (especially ones I haven't described here) will maintain the best UX?

Notes: The user will be creating numerous nodes (upwards of 20 per page,) and editing/moving them frequently; this page is the heart of the application.

6 Answers 6


In many cases editors that prevent you doing things are harder to use than editors that allow 'errors' and flag issues to be corrected. One company I know of spent two man years writing a sophisticated editor designed to prevent errors. They later replaced it on usability grounds with an editor that flagged the errors.

Translating that to your node editor, you can allow the user to have overlapping nodes. Just don't let them leave the page and save the results until they have corrected the problems. When they place one node overlapping another, you can't know if the new node is right and the old one wrong, or the old one is right and the new one wrong. Leave it to them to decide.

Changing the color of the overlapping nodes, and increasing the thickness of the node border is enough to flag where the problem overlaps are. They can drag the nodes to fix. As a convenience, also show a text message with a button like:

Nodes Overlap

The code behind the 'Fix' button can be simple, e.g. it can enlarge the diagram from the center, whilst not enlarging the size of the nodes.

It is counterintuitive, but allowing users to go through an invalid intermediate state can dramatically improve usability.


You may keep the double-click behavior but clearly notifies the user when the mouse is too close to another node to allow creation, with some kind of visual cue (for example changing the cursor or highlighting the closest node).
Alternatively, you can implement a method which finds the nearest valid location to add a new node given any screen location. This way you won't have to prohibit anything: all locations will be a valid double-click location. You can also use a visual cue to notify the user that the created node won't be located exactly under the mouse. To reduce confusion you can create the node at the click location and move it to the valid location in a short animation.

  • Avoiding prohibition is good, but nearest available space will not work well on large dense diagrams, as the node could drift off in any direction. Apr 13, 2011 at 23:04

I think the best solution would be to allow all the methods you mentioned above: Double click would be a hidden feature (not all users would think of creating a new node like that), while dragging a node from the toolbar would be more obvious.

About the position, can't you just force an "align to grid" function? Look at the OS X finder, for example, where no matter where on the screen you drag an item, it will adjust itself and reposition on the nearest "spot" available...

Like this, a double click on the canvas would create a new node on the nearest spot available, a double click on a node would edit it. This functions could be also accessible through right click + options...

By forcing a "snap to grid", users would never be worried about doing it right or wrong, it would be the system taking care of it

  • Strangely enough, I hadn't considered utilizing multiple methods. I'm not sure I like the "snap to grid" idea, as it undermines some of the application's brand/purpose... but good advice none the less.
    – jlmakes
    Apr 12, 2011 at 6:26
  • 1
    Dragging from a toolbar has never been obvious to me. Selecting something on a toolbar then (single-)clicking where I want it to appear is. Seems more point and shoot to me than dragging. It just never occurs to me to drag until the select and click doesn't work. Apr 12, 2011 at 7:14
  • @Marjan - I actually agree with you... yet I'd still be posed with the same problem of the user "shooting" in a place where the node would overlap :P
    – jlmakes
    Apr 12, 2011 at 17:28
  • @Shango: of course, but then you just ignore the shot... If you want to give them a hint where they can and can't shoot: change the cursor? Normal cursor for when the shot is allowed, the "forbidden" or "no entry" sign when a shot is not allowed? (No idea how easy/difficult this would be to achieve in a webapp) Apr 12, 2011 at 18:35

If a user wants to put a node at point X, then let them.

Don't try and second guess what they are trying to achive (cause you can't do it well), and don't make it harder for them to get their goal achieved. Software should mould to the user, not the other way around.

Since you have a rule that nodes can't overlap, make existing nodes get out of the way of the new node - move them a minimim distance away from the new node, so that there is space for the new one. Yes, this might result in a cascade of small movements, but only rarely.

  • I like your thought process... but what about a node near the edge of the canvas--the user could feasibly "lose" a node off the side and be unable to grab it. I've contemplated new node pushing the old node as you suggest, but I'm not sure how to make the "momentum" shift so it would slide up/down the boundary of the canvas ... nor how to account for other nodes it may collide with during "moving out of the way."
    – jlmakes
    Apr 12, 2011 at 22:47
  • 1
    Handling a node at the edge of the canvas is just a special (ie more constrained) case of handling a node that is bounded by multiple existing nodes. As to specific algorithms, I found several with a naiive Google search, including one stackoverflow question: stackoverflow.com/questions/2751377/…
    – Bevan
    Apr 13, 2011 at 2:06

Double click for node creation seems counter-intuitive to me and complicates node creation especially with input devices other than the mouse (i.e. touch screens, graphics tablets). Why not just use a single click for both node creation and selection? If you click near a node it will be selected, if further away a new node will be created. Problem solved :-) Enhancement: use also click-drag-release to create/select and position nodes with one fluent movement.

  • @Sascha - I didn't mention, but single click 'n dragging on the canvas will allow you to drag the canvas around (similar to google maps)... so single click for node creation isn't an option. Each node needs to be "named" by the user, so 1 fluid movement will still be accompanied by a pause to at the very least name the node.
    – jlmakes
    Apr 12, 2011 at 17:25
  • @Sascha - Maybe a "long press" or "long click" instead of a double click?
    – jlmakes
    Apr 12, 2011 at 17:31
  • @Shango: 1) Could the positioning of the canvas be handled any differently? Does it actually need to be dragged/scrolled actively? Maybe use Shift/Alt or the Spacebar as a modifier for the less important action or switch between them on the desktop. Click-and-hold for dragging seems more reasonable to me, BTW. For multitouch, I would use two-finger-drag for positioning the canvas. 2) Do the nodes need to be named immediately? Apr 12, 2011 at 18:20
  • @Sascha - Also, could you elaborate on why double click for node creation disagrees with you? Double click "selects" or "activates" in traditional operating systems, which I equated to "activating" the relevant portion of the canvas with a node.
    – jlmakes
    Apr 12, 2011 at 19:13
  • @Shango: Node naming: You could automatically generate preliminary node names (maybe you may i.e. infer something from the node's position, making the automatism more descriptive) and let the user tab through them afterwards for naming them properly. This would at least relieve them from alternating between pointing device and keyboard all the time. — Double click: Any software known to me that lets me create nodes on a canvas does it by single click. :) Apr 18, 2011 at 12:03

I wouldn't expect to click on an object and have the canvas move. You mentioned Google maps. When you click and drag a direction path line to change your route, the canvas doesn't move.

I'm all for simplicity, but too often design puts too much focus on beginners and the users who are going to gain experience. Keyboard commands may not be intuitive, but once you get the hang of it, you can be much more productive. You mentioned there could be 20 nodes. This doesn't seem like an app where new users make a few entries and rarely use the site again.

Something like double-click would make new node creation pretty efficient. Again, if someone is going to use this often, they'll want short-cuts that a beginner would not use to their advantage.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.