Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
add comment

6 Answers 6

up vote 5 down vote accepted

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.

share|improve this answer
    
Very well communicated. I think this question is a bit subjective for Stackexchange, and in spite of all the other great answers--I feel your answer is a great fit for a "preferred answer." –  J.L. Makes Apr 14 '11 at 2:16
    
+1 (generally speaking) –  Sascha Brossmann Apr 18 '11 at 12:22
add comment

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.

share|improve this answer
    
I was thinking about manually compensating for nodes too close together with a location fix... I'll definitely look into the possibility of this; I know detecting an overlap is simple--but detecting which object, and where it is may be a bit more involved. –  J.L. Makes Apr 12 '11 at 17:28
    
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. –  James Crook Apr 13 '11 at 23:04
add comment

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

share|improve this answer
    
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. –  J.L. Makes Apr 12 '11 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. –  Marjan Venema Apr 12 '11 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 –  J.L. Makes Apr 12 '11 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) –  Marjan Venema Apr 12 '11 at 18:35
    
@Marjan - Interesting--cursor feedback is easily implemented... so potentially for "beginning" users, I could use the toolbar click-to-canvas-click. I fear my question is too subjective for stackexchange lol, but I love the brainstorming! –  J.L. Makes Apr 12 '11 at 19:08
add comment

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.

share|improve this answer
    
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." –  J.L. Makes Apr 12 '11 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 '11 at 2:06
add comment

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.

share|improve this answer
    
@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. –  J.L. Makes Apr 12 '11 at 17:25
    
@Sascha - Maybe a "long press" or "long click" instead of a double click? –  J.L. Makes Apr 12 '11 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? –  Sascha Brossmann Apr 12 '11 at 18:20
    
@Sascha - 1) I'm actually not 100% on how the canvas will behave; I'm thinking that it may only need draggable behavior on smaller resolutions. People seem accustomed to single click-n-drag (google maps) so I'm not sure I want to get "fancy." 2) I suppose the nodes don't need to be named immediately, but the intent is that the user will arrange the nodes based on their name... so to arrange the nodes without explicitly defining their names, is possible--but someone would have to be "naming the nodes in their head" as they go. –  J.L. Makes Apr 12 '11 at 19:03
    
@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. –  J.L. Makes Apr 12 '11 at 19:13
show 2 more comments

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.

share|improve this answer
    
Clicking on a node would select the node--whereas clicking (and holding) the canvas would result in the draggable behavior... I think we're on the same page on that one. I read an article on Learnability vs. Usability (or something to that effect,) that explored something similar, where not all functionality needs to be immediately obvious--with "advanced functionality" available to accommodate the "power user." I'll have to explore the ramifications of implementing keyboard shortcuts (and the impact on mobile browsers,) but good idea! –  J.L. Makes Apr 12 '11 at 19:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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