15

I'm developing a brand new user interface for an old (20+-year) desktop application.

Commands have several ways that they can be accessed — main menu, context menu, keyboard shortcut, and a compatibility mode that allows four-letter command aliases (used in versions of the product to this day) to be used to run commands.

I would really prefer to not have to spend the development time designing (or finding open-source) toolbar icons, provide a structure for users to turn them off, and provide a way for users to customize them.

The old application had toolbars, but they were so badly implemented that if I did develop modern toolbars, they wouldn't resemble what the old application had.

Can I get away without toolbars? Screen space is at a premium, and I'd prefer not to spend any real estate on them. There are already 4-5 ways to access each command.

8
  • 6
    Do you know which one(s) of these 4-6 ways to access commands are the most used by your existing users?
    – SuperFluxx
    Mar 27, 2013 at 19:16
  • 6
    Have you done any research to find out how much your users utilize the existing toolbars? If it is one of the primary ways users have interacted with the application and you remove them entirely, then it might be worse than a badly designed toolbar system. Mar 27, 2013 at 19:16
  • 2
    Not to be self-promoting, but this is very similar to the following question, and similar methods could be applied: ux.stackexchange.com/questions/36927/…
    – Josh Bruce
    Mar 27, 2013 at 19:16
  • 1
    If the users are all pro-users of this domain(application), you can do away with toolbar and make the settings available from the menu. If not, you need the toolbar to make the application easy to use for the entry level users. For detailed answers look at the post Josh Bruce linked.
    – rk.
    Mar 27, 2013 at 20:33
  • 1
    @Tenner As roger points out below, toolbars are great discovery tools. I think that if you found that the toolbars were necessary and the UI is being re-designed, it might be a good time for updating them, sorry! :)
    – SuperFluxx
    Mar 27, 2013 at 21:22

3 Answers 3

11

One consideration to be aware of is that users can be strongly averse to change. You're fighting against that no matter how improved you make things.

Aaron Sedley (the author of the above article) and Hendrik Müller from Google did a presentation on the topic of change aversion at UX Australia 2012, specifically in relation to the transition from Google Docs to Google Drive (that link contains the audio of the presentation and a link to the slides). As an aside, notable UXer Jared Spool has rejected their claims, and his take should be factored into your decision-making.

Specifically on the topic of changing toolbars, Microsoft has seen a lot of criticism in response to their change from a conventional toolbar to their so-called "ribbon" UI, despite some compelling usability research being applied in their design:

An online survey conducted by ExcelUser reports that a majority of respondents had a negative opinion of the change, with advanced users being "somewhat more negative" than intermediate users; the self-estimated reduction in productivity was an average of about 20%, and "about 35%" for people with a negative opinion.

They've experienced similar complaints in Internet Explorer 9 when they moved to a more minimalistic toolbar. Here's an indicative one from the blog comments when Microsoft first announced the changes:

And in general, I'm more and more bothered by this trend going on for the past several years of dumbing every program down to the lowest common denominator. I think that if a program is not specifically designed to help/teach people with little to know computer knowledge, it should strive to make it ever easier for power users (so not "experts", who don't mind command-line stuff and editing configuration files and registry entries, or even mod code, at any moment of the day or night - those will always find a way to get what they want :)) to make the most of it (while of course not making the basic tasks noticeably more difficult for the average user), not just focus on "average and less" and setting the rest aside because they're too few to matter in the numbers game.

In general, expert users are more resistant to significant changes, for the reason Spool gives in his article linked above:

In most cases, people hate change because they don’t like to suddenly become stupid. Think about it. Let’s say you’re a day-in-day-out GMail user. You’ve mastered the menus and commands. You have everything set up exactly like you want it.

Now, suddenly, one day, you arrive at the design and it’s different. All the familiar commands have shifted around. Several are gone. Several are new. Doing those routine, simple acts are no longer routine or simple.

Because of the changes, you suddenly find yourself unable to do the things you once did. While some are smart enough to blame the designers, most will blame themselves. And those people hate feeling stupid, just like everyone else.

As a qualified graphic designer I would consider myself and most of my colleagues expert users in Adobe Photoshop. Personally, I almost never use the mouse to change tools, preferring to use the keyboard shortcuts almost exclusively. One of the most capable visual designers I've ever had the privilege to work with, however, knows almost none of the keyboard shortcuts, and targets everything with the mouse, despite having used Photoshop every day of his professional life over the last 10 or so years at least. While watching him take three times longer to perform some tasks than I would is absolutely infuriating, I wouldn't dare claim he was any less of an expert in the use of the application to achieve a result; he simply isn't as confident with a keyboard as with a mouse.


The conclusion, then, is that you should assess the realistic usage of the toolbars as they exist in the application today. If the people who are currently dependent on the toolbar form a significant or even just vocal part of your user group, you might find it more trouble than it's worth removing the toolbar.

Whatever outcome you choose, you're unlikely to get much of a UX consensus that it's worth eliminating the toolbar merely on the grounds of it being a lot of work to redesign the icons. We're kind of duty-bound to tell you to do what's best by your users, regardless of if it's what's best by your organisation or yourself. Only you can weigh up the relative benefit of good-for-your-users vs. good-for-the-project's-budget, since only you know your users.

1
  • 1
    And assessing realistic usage probably means porting over old and hideous toolbars, as repulsive an idea as that is. Thanks, you made me swallow my pride, and that's probably a good thing. Mar 29, 2013 at 14:57
10

I sympathize, having worked in various similar situations and applications. Typically this scenario crops up in mathematical, scientific, and engineering (my case) applications.

The problems lie in the fact that different people get very set in their ways about how they interact with the software. The keyboard shortcuts, hotkeys, mnemonics, accelerators and commands (and there can be thousands!) are the biggest thing that need to be retained and I've seen what happens when users who are used to these lose access to them - it's like learning to use the software all over again. The same thing can happen with loss of toolbars.

Toolbars also help new users discover, visualise and progressively learn the functionality of an application, and that includes during an evaluation or pitching phase. Your marketing people may have something to say about not having the toolbars.

The first thing I would do is discuss the strategy with the stakeholders and domain experts who can tell you much more than we can here. If it's still a possibility, find a way to hide the toolbars in the current version and try it out on people who actually use them.

2
  • Yep, this is an engineering application. Mar 27, 2013 at 21:13
  • 2
    +1 on representing new users and discovery. Expert users are always new users at first.
    – Mark D
    Mar 27, 2013 at 21:20
4

I'm developing a brand new user interface for an old (20+-year) desktop application.

Few presumptions

  • Your applciation is being used from the last 20 years and it has active users
  • Application despite of its bad UI (as you describe it) is able to keep its users because of the functionality it offers
  • Interface, though it is bad, has still served the users and they are now accustomed to it.
  • The purpose of your whole effort is to improve user-interface so that existing users will have ease of use and new users could start using it.

Now there is a term in Graphic Design (Branding in particular) this sort of change is common. You need to improve your impression but at the same time need connection between improved and previous image. They use a term "Moving Chi" which indicates how quickly a change is brought from a point which was previously acceptable to the new state which needs its time to be acceptable. The faster (with more changes) you move, the harder it becomes for people to connect between two states.

Now your question of keeping or removing the toolbars. Your interface is going to change in lots of ways already including styles, technology, the way some sections look and(possibly) menu groupings . In this scenario, if you take the Tool-bars out then your "rate of change" could be overwhelming. Even if you keep toolbar, interface will be receiving lots of changes in it which again could be overwhelming.

As Roger has mentioned, test your current interface (and navigation) with the actual users to learn their usage patterns. You cannot fix what you cannot measure. If your users are primary relying on badly designed Main Navigation (Toolbar), you got to keep it there and improve it but if they are using alternate approaches most of the time, only then you can afford to remove it from your new interface.

1
  • 1
    It's good to write out the assumptions like this. Many of us probably thought of them, but the explicitness is valuable in an answer Mar 28, 2013 at 13:20

Your Answer

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

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