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'm using a tree view in my web application to present the administrator a way of managing entities in the system.

So far I had to deal with simple entities that require only a name that is way i chose to use inline creation of a new node and then allowing the user to create, delete or rename different entities in the organizational tree as depicted in the following series of screenshots:

enter image description here

I am using a Right-Click context menu + Buttons on top that allow the same operations. Please ignore the graphics design i have yet reached that point I'm still struggling with the UX.

Now I want to manage users In that tree, but creating a user requires to know the username, password, first name, last name at least before i can actually create him. I thought of the following option:

make a po-up modal dialog that will handle the creation of the entity i.e. step 3 will not create a new node in Edit mode but open up a modal dialog with the required forms to input.

Pros: Gives me the flexibility of easily creating complex entities + managing validations.

Cons: A pop-up window usually takes time to load (I hate it) Simple entities will have one field in that form which will look very funny e.g. Division has only a name so i'll open a pop-up form for only one text field.

My question is: is there a best practice for creating a complex object in a tree interface like I have displayed in the screenshots above? Have any of you ever had the same interface to deal with and what was the choice of operation?

share|improve this question
What is your specific question? We're not really the place for general feedback on a design. –  dhmholley Sep 25 '12 at 13:21
The specific question is at the bottom. I would like to have other suggestion on creating complex object in a tree interface like I have displayed in the screenshots. Is there a best practice ? did any of you ever had the same interface to deal with and what was the choice of operation. –  Mortalus Sep 25 '12 at 13:38
I'll add that to the question body. :) –  dhmholley Sep 25 '12 at 13:43
One note: you should almost certainly not rely on right-click/contextual menus as the only way to access certain features—they have very poor discoverability and it fails to accommodate people who navigate with a keyboard. You should provide an alternate way of performing each action (one option that Apple encourages is an "Action" button that basically pops up the context menu for the currently selected item) –  Kit Grose Sep 26 '12 at 3:54
add comment

3 Answers

up vote 2 down vote accepted

A modal dialogue is probably correct to do this, as you say - since it's easily configurable and a straight forward approach. It’s becoming more and more popular and in that way more of a convention.

Loading time issues is a technical restriction, not a core UX problem. Are you sure that it’s not only your development environment having too little hardware resources? When deployed on a real web server with balanced hardware according to load – this shouldn’t be a problem. But if there are, you could use some standard waiting time animation, to let the user know the application is still operational.

Still, there is are guidelines on response time where users have to wait for an operation to finish before moving to the next one. These response times have been straighten out by Jakob Nielsen (UX Guru) in his article Response Times: The 3 Important Limits.

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

  • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

  • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

If you can pop up the dialogue within a second – you’re in good shape from a User Experience perspective.

share|improve this answer
Thank you, but what about the simple entities isn't it a bad practice to open a whole from just for a single text field ? –  Mortalus Sep 25 '12 at 13:39
@Mortalus You could use both techniques. User could first (if it suits your application) just add the name - and later on edit the post and get the full form. I think it would be quite nice to have this option. Right-click > Quick Add OR Right-click > Add... –  Benny Skogberg Sep 25 '12 at 13:43
Actually, in my personal experience (but perhaps it's also in the weinschenk book), you have to be a tad bit slower than 0.1 seconds to show cause-and-effect. An issue was that the users kept clicking a button even after it did its job (which had a subtle effect). By slowing it down to about 200-250msec, the problem didn't occur anymore. I guess the reason was, that when you press a button, for 0.1 sec, you're in "button pressing mode" and you don't care about the environment, you see what you see in your fovea. So if you need to change something further away from the cursor, wait a bit. –  Aadaam Sep 25 '12 at 23:19
add comment

As for the actual UX question: I'd use list inlays, and visible-on-hover buttons instead of context menus.

Applications are usually not right-clickable, and users don't expect them to be. instead, when the user goes over a row, I'd show a row of icons, like, pencil, plus sign, trashcan (edit, new, delete), with tooltips or even written-out labels.

As for performance issues: popups can be really quick. I'll depart a bit from UX.SE and give some tips which should probably belong to programmers.SE instead

  1. Standardize the organization on Chrome or Chromium
    currently, V8 is the fastest JavaScript VM on Earth, and it makes Chrome the fastest browser. Nitro (the engine of Safari) comes close, but it's not universally available.
    Intranets can be standardized.
  2. pre-load templates of popups
    You can use an age-old trick: it actually takes users 1 second to react to something which got suddenly visible. So you have one second to load anything which wasn't needed initially but is needed for your interactions.
  3. develop frontend code on the frontend, not on the backend
    While GWT and the various .NET AJAX technologies may be an engineering marvel, they don't reach the level of the code optimization of GCC or any code compiler for that matter. If you want a fast JavaScript application, write JavaScript yourself
  4. use type hinting in JavaScript
    V8 can understand type hinting. See a doc on how to achieve this
  5. compile/minify your resources You should compile and/or minify your JavaScript and CSS files. The Chrome + Closure compiler combo works really well together. It does help other browsers too, albeit not that effectively (that's why gmail is so slow in everything else I guess). Compiling also gives you the ability to add code quality checks.
  6. Use sprites for images
    In order to minimize requests, use a single, versioned image for all the buttons, icons, logos, etc which the browsers can cache
  7. Use and follow recommendations speed benchmark tools, like YSlow!, or Google PageSpeed
    I'm pretty sure you'll find some of my recommendations there.

There are many more tricks, but in general, browsers are not perfect, but today finally we're able to bring meaningful response times within them, including sub-0.1 answers on most actions.

share|improve this answer
add comment

For the situation you described, I would not use a pop-up dialog, but rather a mater-details pane (see below). To add a new node, the user would click the tree on the branch she would like to add the item to, and then click on the "Add" button (didn't understand why you used right-click when you have a gorgeous "Add" button there).

The details of the node (in this case a new user) would be edited through the form on the right. I know it demands a lot of space, but it's a lot more comfortable than using the intrusive pop-up. You might want to consider also adding Save/Cancel buttons to the details form.

In our system we have lots of tree, and many boast CRUD operations on them. Sometimes, when there is no room, the new node details would be inserted through a pop-up dialog, but I prefer this happening right next to the tree when possible. This also side-steps the loading time issue of the pop-up. Personally, I hate pop-ups because they are intrusive and modal.


download bmml source – Wireframes created with Balsamiq Mockups

share|improve this answer
add comment

Your Answer


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.