Here's the scenario:

You have a (hierarchical) catalogue of information about products. Some product information is local and the rest is remote. There could be upto 1000 distributed in some way - all local - or all remote - or mixed.

You have lots of information about local products, but nothing about the remote products.

You want to present this catalogue (tree + item view) to the user quickly so they can at least choose a local product, but you also want to populate the catalogue as you download information about the remote products.

You can't even include a category until you've downloaded the product information to find out what category it's in.


  • Jumpy structures which update real-time are not good UX as they flicker and the user can't use them. Witness: trying to browse email while the inbox is updating with lots of new email.

  • Structures which update themselves when they're complete still 'surprise' the user. The 'what changed' syndrome.

  • The list of remote products can change at any time, so 'do it once and take the hit' doesn't work.

Possible options:

  • Provide a refresh button to put the user in control of when to update the list (perhaps with a count of the number of products available so far) - but then the user wonders 'so whats new here then'.

  • Provide two structures - one for the local content and one for the remote content. The local one shows immediately and can be interacted with; the other indicates progress and then enables itself when fully loaded - perhaps with notification to that effect.

Are there patterns/examples for presenting data in a part now, part later fashion?

  • From a technical point of view, you're talking about the "Lazy Loading" design pattern (bit.ly/auZr7r, bit.ly/aiPtMP). In short, this technique shows all items equally to the user, but the system holds a "proxy" (a simplified representation of the data) until all the data is loaded. Eg, some media player that shows a dummy image as album cover image until the real album cover image is ready and loaded. The user doesn't need to wait for the real image to load. In your case, you could show the available info immediately, and update the details when needed. Nov 14 '11 at 23:36

I assume for it to be useful to show the local categories first, your users are browsing for a sufficing category, rather than the optimal category. Otherwise, given “the list of remote products can change at any time,” users will never know when to stop browsing. The task is basically impossible.

Search Instead? If users are looking for a specific category rather than browsing for a sufficing one, then maybe you need to provide a Search feature, rather than a tree, which first searches locally and, if nothing close is found, then searches remotely.

Manual Refresh. I’m skeptical that the refresh idea would work because it seems users won’t know how often they need to click refresh. It seems like a lot of extra learning and effort. Manual refresh only prevents the user from being interrupted while they looking at a category or when they’re about to select a category (by it scrolling away spontaneously). Maybe you can mostly prevent that problem by keeping the currently selected category fixed in the pane and adding new categories above and below it as they arrive. Manual refresh doesn’t help the “what changed?” problem or the “where did that other old item go?” problem.

Two Trees. Two trees sounds fine if Local and Remote is meaningful to the users, especially if users have a sense when their target is likely to be Local or Remote (so they can ignore the Local tree and wait for the Remote tree). Perhaps you can make the distinction meaningful to your users by doing something like labeling the Local tree “Quick Search” and the Remote tree “Exhaustive Search.” However, given remote products can change at any time, this doesn’t solve the problem of jumpiness within the remote list.

Append to Tree. If there is no particularly meaningful sort order to the categories (i.e., users are going to have to scan from the top down, like done with Search results), then show the local categories at the top and append the remote categories as they arrive to the bottom of the list. This keeps the list stable preventing old categories from getting lost among new categories, and users will learn that whatever changed will be at the bottom of the tree. If they can’t find anything sufficing at first, they scroll down and wait for more to appear.

Animation on Insert. If it’s necessary to maintain the sort order, one solution may be to address the jumpiness rather than the update part of the problem. Have a single tree and, when a new category arrives slide (over a period of about 500ms) the old categories apart to make room for it. Again, keep the currently selected category still and slide the others around it so what users are looking at is least likely to move. Assuming users have already scrolled to the point in the sort order where the sufficing category will likely be, they see any new category worth considering, and, thanks to the smooth animation, not lose any old category they’re still considering. This could mean making your own tree or list box control.

Placeholders. Perhaps there is some way to make a reasonable guess of the remote categories before they arrive, maybe based on previous sessions. If the app is used frequently or if multiple users use the same local storage, I’d think this would be quite accurate. Load the tree with the local categories and inert placeholders for the remote categories (perhaps labeled “searching…”). If a remote category is determined to be empty, change the placeholder to indicate zero items, but don’t remove it. This limits the jumpiness to only new categories that were not in the original guess. A statistical analysis of the category changes will tell you if this happens at an acceptably low frequency.

  • Good considered thoughts - thanks Michael. I will consider these and update the question at some point with direction taken, and results. Nov 15 '11 at 14:14
  • What I did was to display all local items in the item view and add a manual refresh button ('look for more online...') in the last spot whatever category the user was currently looking at. So while the user has focus/interest on a given category, the list of items gets extended and the category structure is updated, but the category selection is retained so there's little disruption at the actual point of interest - other than the addition of new items to the list. Once online check has been made, the 'more' button is removed. Dec 9 '12 at 19:53

UI controls that update themselves don't have to be jumpy, it's a matter of technology. For example, I believe you won't encounter this problem when using WPF controls correctly.

As for notifying the user, you could display a notification that says "Click here to see 10 more products" (and the number increases with every new product that is loaded). The three icons at the top of Facebook (Friend Requests, Messages, Notifications) are a good example.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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