1

The context for this question is a web application. Let's say we've got 400-500 widgets. Users can create an unlimited number of sets to group related widgets in ways that make sense to them. Each set might have 40-70 widgets, and a widget can appear in multiple sets. So, the question is...

What's the most efficient way to allow users to add widgets to a set?

As I've though about it, there are two main viewpoints to approach this from:

  1. The widget-centric view of the world. The user creates a new widget or edits an existing one. Within that screen, a list of sets is displayed with a checkbox next to each one. The user ticks off which sets the widget belongs in.
  2. The set-centric view of the world. The user creates a new set or edits an existing one. Within that screen, there is some selection mechanism (to be determined) for finding widgets. The user searches/browses widgets and adds them to the set.

I'm leaning towards #2 with some kind of browsing capability along with an autocomplete text box. There are cases where the user will know the exact name of a widget (or some substring) and should be able to add it quickly, but there are also cases where the user doesn't know exactly what he's looking for and browsing would be helpful.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Thoughts? Am I on the right path?

3 Answers 3

2

I think either viewpoint would be needed, depending on your context. For example if you're browsing sets (sets index page), you'd want to see things from a set point of view. In other words, you can assume that the set is the starting point and not the widget: You select a set, then add widgets to it. The other way around would be true if you're browsing widgets instead: You select the widget, then the sets it belongs to.

That said, a great pattern that (I think) applies here is the Google+ circles/people page. That page shows both users and circles (sets and widgets) in a way that makes relationships between the two pools very clear. You have main/atomic objects (users) and buckets that you can drop these object in (circles). You can create/remove buckets, and drop an object in more that one bucket.

1

I am not sure about your workflow but from your description, it look both views will be helpful. Users having clear idea of the kind of widgets he will be creating can start with the set approach. Users intending to create only one widget for the time being may use the Widget approach. Having both views will add to the flexibility, ofcourse may also add to your dev effort. May be your user base (personas) and the scenarios that addresses their needs will through some light into the approach you should adopt.

0

It seems the typical shopping interaction pattern with some modification is suitable for the case.
The difference is the cart should be constantly displayed while searching and picking widgets.

It allows to implement feedback, to reflect sysytem state, and to perform some actions (like removing widget, etc.) with cart contents.

enter image description here

Argument for this approach is the widgets are atomic objects in this interaction. So a user constructs sets by manipulating with atomic objects.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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