“DOJO does not always make it exactly like a desktop application”

Climbing … We’re practicing how to haul something heavy up a cliff.  It’s a rescue technique; critical to know when it’s needed but, thankfully, it almost never happens. The problem with this array of rope,  pulleys, carabiners and  barrel-shaped knots that give me leverage to lift 200 pounds is that for every foot I want to lift the weight, I have to pull three times that much rope.  It’s slow work!

There’s a great UI used in windows explorer.  The view flows great for the user: whatever is selected at the top is shown in a tree view on the left, whatever is selected in the left tree is displayed in the details list on the right.  It’s easy and it works in Windows because disk directory lookups are quick.   

 

DOJO is great for making web UIs that look like desktop applications, however for a DOJO UI, this three tiered UI requires careful design to make it perform well.   

One thing that really slows down a web UI multiple XHR requests that must be done sequentially.  For instance:    

 

 

In this case, the XHR requests cannot be done in parallel because the second and third requests depend upon the previous responses.  The web page TTI is greater than the sum of all three XHR times.  Usually, this kind of view always has a default selection for the top and left parts of the view so nothing is initially empty.  The default selection makes UI initialization the worst case  for this sequential XHR problem as in the table below:

 

Action	Number of sequential XHR requests
Select a new item in the left tree view	2
Select a new category at the top	2
Initialize the view	3

 

The initial page load can require three sequential round trips to the server.   

The view can still be used, but it requires some design thought.  Some options:

 

1)       Have no default selections.  This is not a great option because people are accustomed to Windows which does have initial selections.

2)      Choose default selections that are easy to calculate.  Some XHR requests are faster than others; choose defaults that use faster XHR requests.  If the XHR requests are fast enough in the worst-case then the UI will be OK.

3)      Calculate the default selections on the server and return all the data for the initial tree view in one XHR request.  This eliminates the extra network delays.

4)      Avoid this cascading view in web applications unless the XHR requests are all guaranteed to be lightning fast.   If the XHR has any chance of being slow because the UI will be over 3X as slow and the best option is to design a different UI.