Imagine a list (A) of items i.e. rectangles with fixed width but flexible height each of which contains a string. What I want the user to be able to do is to select multiple items from this list and then based on a (non-fixed) set of rules gets a list (B) of recommendations (that looks like the items in the list A, but with possible different content) of which she can chose which ones to import to list A.

(it's quite important for the user to see on which items the recommendations are based on)

Question: How to represent which items (from A) were selected?

  1. simply put a checkbox on the items?
  2. clone them to a separate list (which is possibly next to list A) above|below which the recommendations appear?
  3. checkbox, but anchor the selected ones to the visible area, so when she would scroll past them they stick to the top or bottom (but this would put a limit on the number of selectable items)

Use case modelling

I'd probably just create a flow-chart with see/do analysis for each node. To elaborate:

  • We want to model a use case, so long it involves a single user such model will be classified as dynamic model (a model that involves time, as opposed to a static model, like an entity-relationship one).
  • The two main constructs in use case modelling is either states or actions.
  • In models based on graph (network) syntax/arrangement (like the one discussed here), you can normally included more information on nodes than their relationships.
  • Sometimes your model will have states as nodes and actions as relationships (a state diagram essentially), this allows you to present/analyse more information related to state.
  • Sometimes it is the other way around - when you want to say/analyse more about actions.
  • The see/do analysis provides a simple mapping to what users need to perceive (see) in order to take an action, and what actions they might need to be taking (do) to move between states.

So let's try this:


  1. The ultimate goal (business or user) is to see a list of relevant recommendations.

  2. It is implied by your question that it is important for users to see the selection that yielded the current recommendation.

  3. While not explicitly stated, I can only infer that there are some iterations involved - users may wish to modify their selection after seeing the recommendations (the design could change if this assumption is incorrect).


A few things that could affect the design:

  • How many items are on the original list? Do they fit into a view or require a scroll? (You kind of answered this by suggesting anchoring - meaning some item may be 'off-viewport'.
  • Are users required to take an action to see recommendations, or are the recommendation shown with each new selection?
  • Do the original items / selection /recommendation share the same view? It appears by your question that they would but have you considered mobile devices?


Given the problem is still not completely understood. I can just give some feedback on the current proposal:

Simply put a checkbox on the items?

Well, one way or another users are required to select items. Checkbox seems reasonable here so long there isn't a separate list for selection.

You may also want to change the background for more apparent visual feedback.

Clone them to a separate list (which is possibly next to list A) above|below which the recommendations appear?

The possible issue with this is that you keep 2 representations of the same data - whether it is the selection or the items involved, there are going to be two of them on the view. This can be seen as extra noise and redundancy.

Checkbox, but anchor the selected ones to the visible area, so when she would scroll past them they stick to the top or bottom (but this would put a limit on the number of selectable items)

That's a sound idea, but the one thing you should consider is that you may be making decisions on behalf of the users, rather than keeping them in control. You'd normally need some really good argument or user data to do such a thing, and I can't see it here.

The decision you make is that the users want to see the items clustered rather than seeing the selection in the original list.

First, by anchoring things you will lose any sort order (which could be important).

Second, you change your view (different sorting again) which at a deep level contributes to loss of orientation, small as it may be (our brain maintains the position of various items in the spatial field for a while, which enables quicker recognition; so moving things about reduces such ability).

Third, you can run into all sorts of interactive troubles here - if the first selected item was below the fold, once selected it goes to top. You can either scroll there (users lose where they were), or not (the item will disappear but users may not be able to tell where or why?)

Perhaps having a control (switch, checkbox, whatever) allowing seeing the selected items only will be a better option here? This will leave the control in the hands of the users and should make everything much clearer.


So provisionally, I'd vote for checkboxes with background and a 'selected only' control.

Again, without knowing more on your problem this may or may not be an optimal solution.

  • this is hell of a detailed answer thank you very much, the other possibility that came to my mind is a fusion of "anchor" and your "selected only" option, the user selects them with a checkbox, then when a selected one is about to scroll off-screen a thin (relative to the height of the items) placeholder is anchored to the bottom or top indicating that there is one (or the number of such placeholders) selected item(s) off-screen in that direction(when it gets into view it expands); the user may hover over them to glance at the item it represents or click on it to scroll that element into view – Adam Aug 7 '16 at 13:22

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.