0

What is the best place for interaction elements?

Here's the situation: In our software there is an object (in this case a list with several items) that a user wants to work on. A user could perform several actions on this object (e.g. add new item, edit existing item, delete existing item). Our approach, in general, is to have all actions placed within an action panel (placed on the right side of the screen). This panel is always visible and shows all actions that are available within the current screen but also actions that navigate to a new screen (visually different from the 'within screen actions').

Which would be the best approach:

  • Both, actions within the screen and actions that lead to another screen, placed in the action panel: enter image description here
  • Both, actions within the screen and actions that lead to another screen, placed in the action panel, and in addition duplicate the 'within screen actions' near the object (item list): enter image description here
  • 'within screen actions' near the object (item list), other actions in action panel: enter image description here

Which solution do you prefer and why?

Addendum: The action panel has the advantage that it answers the question: What can I do here? This is necessary, because within the application, there are many different entities that have different sets of actions. Some of these actions refer only to the entity that is at hand (on screen) and some actions take one entity as a starting point, then go to another area where this entity is used for a special task...

Improve this question

3 Answers 3

Reset to default
2

Users don't think in RESTful terms like this (Edit object, new object, delete object, etc.), developers do. So I'm not crazy about this interface in general. The better option would be to show the appropriate action on the "object" at just the right time in the workflow. But that's not your question :)

Here is how I would handle it. I would put the Edit, Delete and Add actions in the center panel. Each item in the list would have an Edit and Delete link and the table would have an Add button. When the user clicks Add, the user can either fill out a form (ideally displayed on the same page) or add a record to the table directly.

enter image description here

Improve this answer
4
  • I agree, this solution would be very nice and clear if we had only 3 options (edit, delete, add). Problem is how to handle different tasks, e.g. 'create a new order for item1' which refer to a list item. There could be many of these tasks an i think that it wouldn't fit at all or at least look very crowded if we placed every option on each item in the list...
    – Gabriele
    Commented Dec 3, 2012 at 16:09
  • Can you provide some context regarding what these items are?
    – kwh941
    Commented Dec 3, 2012 at 16:10
  • The list could be a list of health insurance funds or a list of patients or a list of doctors or a list of users or a list of pharmaceuticals... Very different entities and for each entity the user needs to be able to perform very different actions...
    – Gabriele
    Commented Dec 3, 2012 at 16:23
  • OK, if these are very different entities and actions then we shouldn't try and solve for them with a single set of UI elements.
    – kwh941
    Commented Dec 3, 2012 at 16:25
2

In option 1, they have to waste time by seeing options that are not related to the items whenever they want to manipulate an item, which results in slower scanning speeds.

In option 2, you are repeating yourself and forcing customers to scan options that they aren't interested in when they want to navigate away. Once again slower scanning.

Option 3 is clearer, as you are keeping the items your customers are using in the same section as the the actions that act on them. Navigation is also kept apart, so they can quickly scan that when they want to navigate away.

Improve this answer
3
  • OK, I see your point. The problem is that what looks like a navigation only element (the 'go to XYZ button') could also be an action that refers to a list item, e.g. 'create a new order for item1'. This action would use the data of item1 to open a new screen for creating an order.
    – Gabriele
    Commented Dec 3, 2012 at 16:04
  • If it refers to the list item, then include it with the list items.
    – JohnGB ♦
    Commented Dec 3, 2012 at 16:08
  • In our application we have actions that are related to the list or a single list item. So everything a user does has an effect on the current screen. And we have actions that are for navigation only and that lead to another screen. However, we also have actions that refer to a list item AND navigate to another screen (which means the user starts a new task based on the selected list item). I think it's important to differentiate (also visually) between actions that make the user stay in the current task and actions that lead to another task (=screen).
    – Gabriele
    Commented Dec 7, 2012 at 8:29
1

Personally I prefer 3rd one:

  1. It looks similar to Google mail with actions available at the top of the screen, are you planning to keep them visible at all the time?
  2. Clear separation, actions (add new, delete) and navigation (go to X,Y,Z)

Also are you considering using tick boxes for multiple delete? What are the Group 1,2 and 3 buttons do?

Improve this answer
2
  • 1
    If possible we will keep the options always visible, there will be some special lists where not all items are deletable, for these special items we will set the button disabled.
    – Gabriele
    Commented Dec 3, 2012 at 16:26
  • Also the possibility of multiple delete will depend on the kind of list. The group items are just tab items that open another list/view...
    – Gabriele
    Commented Dec 3, 2012 at 16:27

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.