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.

Suppose we perform a search on an object name and get this results list:

enter image description here

From this list exactly one element can be selected in order to perform an action on that element. An element can be either:

  • An object itself
  • OR an item connected to an object
  • OR a part connected to an object

An object can have zero or more items and zero or more parts. Items (of which there may be many) is listed in a separate dialog. Parts (of which, often there is only a few) could be listed on inline expansion. The following image shows this setup:

enter image description here

My question is this:

  • How to best indicate a selected element if the list in which it appears is not always visible?

I know a general solution to showing a selection in a list would be a dropdown/combobox. However, I think this kind of control bloats the UI in this case and has an affordance more like "required" than "optional". Also, it's not very good in terms of interaction in case of long lists (with a lot of scrolling).

My best bet at the moment would be to use color if one of the items or one of the parts is selected. For parts it would look something like this:

enter image description here

This, however, is an inconcise and not so elegant solution. Do you have any better suggestions?

share|improve this question

3 Answers 3

Whatever you do, you need to show the specific entity so users know what they performing the action on. That’s important enough to be worth whatever bloat it creates, especially if the effects of the action are shown on the entity in the same page. Here’re some options:

  • Support the action on any drill-down pages. If the user wants to perform the action on an object’s item, then they must do it from the page listing the items related to the chosen object. This, of course, won’t work if you need to allow the action to be performed simultaneously on items from a mix of objects. It works best if the user typically performs the action on only one entity –why make the users select an item, then navigate back to the parent page before they can perform the action?

  • Only maintain selection while an expander is open. If the user closes a Part expander, the selected part become deselected. You might think this would confuse the user, but it’s common practice in GUIs (e.g., MS Windows Explorer). It’s actually helpful if the context around the entity (e.g., the surround parts) is important for verifying one has selected the right entity. This approach won’t work if users typically open so many expanders to select multiple parts that scanning and scrolling becomes unwieldy. This one also works best if the users typically perform the action on only one entity –they’ll naturally select a part then perform the action, not select a part, close the expander, then perform the action.

  • Echo identity in object image. Show the selected item or part next to the controls for showing the entire lot. In effect, your expanders are sort of like combo boxes now, but without the “must select one” implications –and the selection clears automatically if the user selects a different entity from the object. Looks something like this:

enter image description here

  • Selection list. List all selected entities at the bottom next to the Perform Action button. That is, essentially you’ve a shopping cart from an ecommerce site or To list from a email app. List each entity’s full path (Object Name – Item/Part Name) to provide some context and cue the user that selecting a different entity for a given object replaces an entity on the list. This provides a single convenient place for the users to verify their selections before performing the action (although it looses some the context), which is especially helpful if there are a lot of objects in the search results.
share|improve this answer
    
I agree that it would be expedient to show the (name of the) selected element upfront - and that is probably more relevant than showing the number of elements available. On our team we have discussed a "Selection list" as you call it - although, if the selection is properly indicated in the listing, such a list shouldn't be necessary. –  agib May 30 '11 at 14:06
    
You're right concerning the back navigation. There is really no need for user to manually collapse an expandable section before the action can be carried out. –  agib May 30 '11 at 14:10

"My best bet at the moment would be to use color if one of the items or one of the parts is selected.... This, however, is an inconcise and not so elegant solution"

I'm not understanding because to me it seems overly concise. We should at least see the element currently selected.

The underlying problem is that three levels of selection are being confused.

  • The result set (Alpha, Beta, Gamma or Delta)
  • The type (Object, Item or Part)
  • The specific Item or Part (if item or part were selected)

The 'off the shelf' solution is to have a tree, or rather a tree table since you have additional information (the meta info) you want to display. How about this as the starting point for a custom solution:

enter image description here

The point is that it is clear that Beta->Part->A-really-really-really-long-part has been selected for action.

share|improve this answer
    
My point concerning the inconcise was that the number of parts (and items for that matter) perhaps isn't that relevant. A kind of tabbed interface (as I interpret your image) may make it more clear in terms of expressing that items and parts are different aspects of the same thing, e.g. object Beta. However, the radio button-like behaviour when selecting (either object Beta itself OR one of the items OR one the parts) is still not very well communicated. Also, a tabbed interface is rather heavy visually. –  agib May 30 '11 at 13:49

The only things that comes to my mind on existing solutions, is the office installer and hierarchical check lists/todolists:

enter image description here
enter image description here

For more inspiration:
- Google "hierarchical todo"
- Google "hierarchical checklist"
- Google "office installer"

share|improve this answer
    
Thank you for your answer. So, if I understand your Paris Trip Packlist example correctly, the numbers in the parenthesis are the (number of selected/total number of children)? In my case a number representing the selections might be redundant since only one element can be selected at a time. So really what I'm looking for is a way to indicate that one (perhaps even which one) is selected in this "category" - not all 5 parts - as my lower-most mockup might be interpreted (by those not completely familiar with the concept of a single selected item). –  agib May 27 '11 at 11:59
    
Regarding the Office installer screenshot, I'm not sure I'm able to decipher their approach from the static image. Do you know the details? –  agib May 27 '11 at 12:00
    
@agib, perhaps I chose a poor screen shot for the office installer, I'll update it. The point here is that the root icon illustrates if none, some or all of the sub items are selected. In the updated image you'll see that the white nodes are fully installed and the gray icon is only partly installed. I'm sure if this is a good solution to your issue, but the concept of indicating the status with the root/node icon was the point I tried to make. –  Jørn E. Angeltveit May 27 '11 at 12:46

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.