Feature Exposure vs. UI bloating

Question

When developing my web applications, I usually tend to have an icon/button per feature/function and place it in a way that it is easily accessible without distracting the user during his usual work. However, I often have confrontations with part of management because they feel certain buttons should be on multiple places and be as visible as possible.

What is your take on this? Should buttons/functionality within the same context have one place were the user should always look for it (my approach), or should buttons be duplicated to all places were the user might need them (management's approach).

Examples:
- Put another edit button right beside the tabs of a config-screen to get to the edit-mode to the app because the edit option is inside a toolbar-menu and not visible right away
- Put a save button above and below a textarea because the user could either be finishing typing (lower save is close) or finishing reading the preview (upper save is close)

Our reasoning behind the debate:

my approach:
+ slick design
+ unused icons stay hidden
+ structure
- user's without prior exposure to the software might need to look up the features/search

management's approach
+ functions are visible where they are needed
- redundant UI-components for the very same function
- disorganized look and feel
- UI bloat

I reckon that the reasoning seems biased, but that's why I am asking. What approach results in a better UI?

Answer 1

Duplicating actions isn't always bad in my opinion. Especially not if they are not exactly the same from the users perspective.

I think in the end, there is not one way to follow for everything. It is not do-not-duplicate versus duplicate-as-much-as-possible. Look at the case at hand and decide what the user might think here, what is their usual pattern, what would they do if it was not an application but a paper thing, how would they think. And based on that, decide where you want to provide what kind of actions.

---

Going into your first example:

Put another edit button right beside the tabs of a config-screen to get to the edit-mode to the app because the edit option is inside a toolbar-menu and not visible right away

I think this is what you say:

If so, then the two actions have different meanings for the user. The first 'edit-mode' puts them in an editorial/redactional modus (also inside their own minds) and makes everything editable. The second 'change these settings' only does that with this page.

---

Your second example:

Put a save button above and below a textarea because the user could either be finishing typing (lower save is close) or finishing reading the preview (upper save is close)

I had a similar situation lately:

In this case the first save button provides a quick way to make changes; an [ edit - change something - save ] is easily done and the user doesn't have to scroll down the whole form. And when the user does need to set the advanced options they can just follow the form and save at the bottom.

(One can argue to put the advanced settings under a link above the first save button and let it fold out when clicking the link. This is not always wanted though.)

Answer 2

Who says redundancy is always bad? It's common to have menus, toolbars, and keyboard shortcuts that all do the same thing. If the duplicates don't each add something (i.e. they really are completely redundant), then it's time to remove something, but it might not be the bits you first think.

In Gmail, reply is available above and below a message, because the user is likely to have scrolled either to the top or bottom of the page, making it hard to find a button at the other end. This problem doesn't exist for desktop apps, so they wouldn't have a good reason to include a button in both locations.

The trick is to stay balanced and avoid putting everything everywhere. The principle of grouping related functionality helps in both directions -- don't hide stuff out of the way if it really is related to localized functionality, but don't throw stuff into the middle of the main UI unless it is useful for doing the task the user is there to do. The latter case covers options and settings that the user will set once and forget about -- don't put an Options button in their way if they're only going to click it once.

Figure out what the most common use cases are for each part of your app, and optimize the UI for those use cases. It's ok if this adds a little redundancy.

Answer 3

Many web applications have Save / Submit buttons both above and below the content (especially shopping carts).

As long as the buttons look identical and are aligned with each-other, there's nothing wrong with that.

Contextual buttons (such as an edit button for a row) should be associated with their rows; it would probably be better to put an edit button in the row (perhaps on hover) than in a toolbar (unless you support multi-selection)

Answer 4

Microsoft's Ribbon provides the user the ability to add various commands to the "Quick Access" toolbar. You could extend that idea and just add those commands initially, while allowing the user to remove the ones they don't want.

Answer 5

I've seen many websites with a floating bar or widget, staying in sight regardless of the scrolling. Couldn't such a bar not be used to keep the “Edit”, “Save” or other commands in sight? This would obviously only work when the page as a whole would be saved, I guess.

Answer 6

Well, what do the actual users say about it? And how do they respond to both implementations when put to a user test? I think those are deciding factors. I think applications should be mainly easy to use, so avoiding UI bloat is not a goal in itself, but a means to keep it usable. If the extra button helps users (by making a much-used function more easily accessible) more than it hinders them (by presenting them with a confusing interface) I think it should be done.

(And note that most GUIs already have redundancy in them. Certain options are listed in the menu items at the top, the toolbar, the context menu and have a keyboard shortcut.)

I think that if the edit-mode is used much, it deserves a direct button.