Managing CRUD operations in a tree

Question

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:

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?

Answer 1

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.

Answer 2

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.

Answer 3

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}