I'm thinking of making an editor and how it should differ against other editors. One of those points are promoting the work area over GUI buttons and information fields. Tool bars, menu bars, scroll bars; I want it all to go away and be replaced by something not taking any space on display. That "something" is irrelevant for my question.

As an example there is MS Word. More or less every command can be found in menu bars, tool bars, some more bars in the bottom with "good to have" stuff, context menus in the workspace and as dialogs. Many actions also have keyboard shortcuts. Everything everywere. I mean just look at the new, open, save buttons. They are literaly neighbours to the menu bar variant! (I know this changed a long time ago for MS Word but I see the same pattern for other editors. I also happen work in a secret bunker still using Office from 2003 to 2016)

Because I plan on removing most of it I must first ask: Why all this redundancy? What purpose does it serve? Is it all about legacy and familiarity with previous systems? Targeting a broad and diverse user base? Am I missing an important point in not having "everything everywere"?

A more modern UI worth mentioning with this issue is Visual Studio 2015, although actual redundancy is percieved lower and my biggest problem being "stuff, stuff everywere".

As contrast, I find UMLet being a breeze to work with from UI perspective. I do realize how unfair it is comparing tools performing different tasks, but I hope you get the idea anyway.

  • 10
    It's probably worthwhile to take a look at more modern document creation applications before taking up such a question. UX has evolved quite a lot in the past 13 years. There's still redundancy in modern applications (for example, needed functionality should never only have a keyboard shortcut as its entry point), and you'll be able to see one potential solution in both reducing redundancy and improving discoverability in the differences between Word 2003 and Word 2016.
    – nadyne
    Commented May 30, 2016 at 21:40
  • 48
    This question is not complete without mentioning ed, the standard editor. Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
    – pipe
    Commented May 31, 2016 at 0:41
  • 9
    You are confusing terminology. "MS Word" is not an editor, it is a word processor. An editor is meant to edit plain text files, while a word processor is aimed at editing marked-up text which is typically stored in a much more complicated and often non-interchangable format. See wikipedia. Commented May 31, 2016 at 10:22
  • 35
    Your thinking killed plenty of competitors to Word :) While it's true that 90% of users use 10% of the features (and UI elements), it doesn't mean that keeping just 10% of features will let you keep those 90% users - they don't all use the same 10%. Ctrl-Insert no longer works as "copy to clipboard" in your application? Too bad, you just lost all those old-school MS-DOS users. F2 no longer saves the file? No button to save the current document? No quick way to open a "Find and Replace" dialog? They may seem like clutter, but you need them if you want to get your competitor's customers :)
    – Luaan
    Commented May 31, 2016 at 12:34
  • 6
    Distraction-Free writing tools can be seen as a reaction against the visual aspects of the redundancy you describe. Commented Jun 1, 2016 at 14:32

10 Answers 10


If a user can't find an option or feature, then it doesn't exist

There has to be some means by which a user who is looking for a feature can reasonably expect to find it, and by which users can browse features to learn what is available.

Well-designed menus are really good at this. Clusters of related buttons and displays too, especially with tool tips.

Keyboard shortcuts and gestures are terrible at this.

Easy things should be easy

Little is more frustrating to a user when a simple task is tedious or complicated to execute.

Navigating menus, especially hierarchical ones, is bad at this.

Buttons are pretty good. Displays that already show the information you're looking for without any action on your part are great! Easily remembered keyboard shortcuts are good too.

Often used things should be quick

This is much like the above. Optimize various interfaces so that the more frequently used things take less interaction.

Ribbons are pretty good at this if it's easy for the user to customize.

Keyboard shortcuts are essential

Good keyboard shortcuts save a vast amount of effort on the part of the user, and let them carry out tasks without breaking their flow. Triply so in applications (like a text editor!) where a user is expected to be providing keyboard input anyways.

I imagine people who aren't used to them don't really appreciate this, but for people fluent in such, a lack of keyboard access can be crippling to an interface. Even a clunky keyboard interface does terrible harm to usability.

Having them, however, pretty much requires features to appear elsewhere so they can be discovered; e.g. showing the shortcuts in menus.

  • 11
    Easy calculation: How much does it cost to have another button doing the exact same thing? Almost nothing, but it can increase usability/productivity a lot - so if you can prevent cognitive overload, give the user 4 ways to access every feature!
    – Falco
    Commented May 31, 2016 at 11:08
  • 24
    Don't forget about familiarity - if you're trying to pull over customers from a competitor, you better make sure they can use your application without making a learning investment. This also applies to updated versions of your own software. Microsoft understanding this very well was one of the biggest reasons they got so close to a monopoly - it's hard to believe, but almost noöne else bothered to cater to how people actually used their applications (and long after Office became dominant, their competitors still wouldn't get it).
    – Luaan
    Commented May 31, 2016 at 12:27
  • 1
    @Luaan - exactly what I was thinking. Even if your application is the best thing ever, if the user doesn't know a feature exists (which includes if being able to do it in whatever way they are used to doing it), then they will stick with the one they are used to -- there has to be a tangible benefit and no loss [that they are bothered about]. MS Office is where it is, because Microsoft get that completely. Commented Jun 1, 2016 at 10:13

You'd probably need someone who works at Microsoft to answer this one, but from the outside observer, there are a number of reasons why this might be the case:

  • They cater for a very diverse group of users: think about the audience and users of Microsoft products and perhaps this is a way to accommodate all the different ways that people might use the product. They do allow you to also customize the ribbons and various toolbars, which is a further proof of this.
  • There are legacy code or modules that are difficult to remove entirely: sometimes it is too hard to simply remove something completely if it has been there for a while, or if there are dependencies of other features on this component.
  • There are different contexts for using the same features for different tasks or during different stages of the workflow: say for example, it might be more convenient to access the feature at the beginning of a task compared to the middle of a task
  • They have to cater for different versions of the product and it is to try and keep some level of consistency between them: the change to ribbon design was a big jump for many users, so to allow people who are making a switch rather than completely new to the software, it creates a bridge for them to gradually move into the new UI design (or not).

There are probably other reasons, or maybe all of the reasons combined together makes it difficult to do away with redundancies (or make it necessary).

  • 1
    MS Word was an example. Matlab, Dymola and Bridgepoint are also on my hit list. And not in a good way ;-) Many good points though.
    – Andreas
    Commented May 30, 2016 at 21:52
  • @Andreas you pretty much answered your own question, so it was just adding a little bit more detail to what you have already suspected, but we'll see if other people have more to contribute.
    – Michael Lai
    Commented May 30, 2016 at 22:35
  • +1 I know a person who still right clicks a file to open the context menu then clicks open. Commented Jun 2, 2016 at 14:45

Often this can be summed up with 2 words.

Backwards Compatibility

The original Word users likely migrated from WordPerfect.. Which was very keyboard focused cause when you type that's where your hands are.

Thus when Word first had its menus and toolbars they had to support hot keys too. When they came out with "personalized menus" where options not used frequently would disappear users revolted and forced them back to the way they were via a config setting (PS users hate change!) When they came out with "The Ribbon" to heavily mixed reactions they had yet another paradigm for users yet they tried to ensure most of the functionality under the hood was still accessible in all the ways they could.

Long story short, if you gave a user an option previously... You will struggle to remove it later (user backlash) if the users are passionate/vocal enough it can negatively affect your product positioning and brand.

Plan your UI carefully from day one... Once you get market adoption it may be quite hard to change it.

Case in point for me, I have used AutoCAD since version 9 on DOS... and have mastered "near blindfold-able" use of it via the keyboard. If Autodesk releases a version without the command line... I will never upgrade again.

  • 22
    This answer appears to imply that keyboard shortcuts are only for backward compatibility, when they are actually essential for power users. Also, I hated the "personalized menus" not because I hate change but because they were bad UX: common tasks appeared in an unpredictable order in the menu, making it take longer to find them, and uncommon tasks were not discoverable.
    – user31143
    Commented May 31, 2016 at 6:39
  • 1
    @dan1111 quite true. for accessibility reasons any UI should respond to all input types (keyboard, mouse, tapping, etc.) regardless. I agree on the personalized menus too... the fact that things were not in a predictable order was the main issue.
    – scunliffe
    Commented May 31, 2016 at 13:14
  • 2
    @dan1111 Indeed, mouse menu interfaces are great for making things discoverable to new users, allowing people to quickly use the program at all, but then they hit a plateau beyond which more progress becomes quite difficult. With keyboard shortcuts displayed in the menus, people will soon learn to use the ones they use the most often, and pick up productivity. If you try to take those shortcuts away from experienced users, expect an angry mob with torches and pitchforks at your door. Commented Jun 1, 2016 at 21:30

Keyboard shortcuts

The fastest.

Tool bars

It's the fastest if it is impractical to set a keyboard shortcut for everything. And if it wasn't an editor, people sometimes just don't want to use a keyboard for whatever reasons.

Context menus

They are more likely showing what the users intended to do. Changing the tool bars too much on the fly may distract the user.

Dialog boxes

Useful for some one-time related tasks. You could also use a tool bar. But it may take too much space if other tool bars are all small in your program. If there are too many functionalities that it needs a dialog, of course you don't want to close the dialog to do something very relevant, just because that functionality is more commonly used. So the more easily accessible functionalities might be repeated there.

Menu bars

To allow the users to explore all the features. If there are enough things the user could do, it's usually not very helpful to make sure all the functionalities are listed in any other single places, or they just take much space unnecessarily. (This have exceptions. You could group things properly in other ways, but that's usually not expected in some old programs.) If you only list things in the help files, people rarely read them. Some menu items might be never used, but at least they are simpler than most help files.

For some features such as copy and paste, users may rarely click in the menu. They only tell newbies that Ctrl+C means to copy, etc, and they are supported by this program. (Personally I don't understand why Google Chrome listed them in a way unhelpful in this case.)

It could also contain many disabled options, which are probably inappropriate in most other places. For example, before adding an image, you may want to tell the users that they could edit the image in your program. Otherwise they would open another program, edit and resave the image, just finding they didn't need to.

And many buttons on the tool bars doesn't have a visible text description. If your program is complicated enough that, someone is phoning another person asking about how to do something, menus and dialogs would be more reliable.


They could be all helpful to the same user. You may not need the complicated way if the simpler way could contain everything (which is indeed becoming more likely considering the increasing screen resolution). But if you need both the complicated and the simpler, you may need to repeat things in the complicated for one reason or another.

Bad examples

I just realized there were many bad things I know according to my answer. I'm not pushing those changes (They may have other considerations) but only to demonstrate the idea.

  • Tool bars: The notification area items for only denoting a background service is running, which users aren't supposed to interact with often. Better there is another dedicated management window or menu for those services.
  • Context menus: I remember a version of KDE which mixes the context menu of desktop and taskbar (don't know whether it is still the case). It should only use a proper menu and no context menu if it insists that they should merge them together.
  • Menu bars: The Chrome way organizing edit options. A submenu with keyboard shortcuts displayed would be more helpful. Leaving most other items like normal menu items makes it look worse. And we know allowing strange things appear in the menu isn't invented by Google, as it was possible in old versions of Microsoft Office.

And a good example: There are many tabbed applications supporting moving a tab to a new window. But when there wasn't a menu option, some people (including me) got very annoyed by the "fact" it doesn't have such a functionality. But when there is the menu option, or we start to use a program that just doesn't work if there isn't this functionality, we realize the tabs could be dragged out quickly. And we then start trying this in other programs without this menu option.

  • "I remember a version of KDE which mixes the context menu of desktop and taskbar" I think that's only ever been an option, not a default. Even in GNOME, where it is a default, you can still turn it off. In Mac OS X, it is of course default and compulsory. And obviously, all of these depend on the program building its menu in a way that the DE can recognise and intercept at the point of theming and hoist out to its 'top bar'. Commented Jun 4, 2016 at 1:09

It's simply very painful to remove features from established software.

Featuritus is often a marketing advantage.

The initial redundancy of being able to invoke an action via menu or keyboard is proven useful pattern - some people prefer to use the mouse (menu) and some prefer the keyboard. The menus are more discoverable but the keyboard is faster. This was the way the original Mac UI was designed and it worked well.

The toolbar (or ribbon) came later and facilitated more actions, more features, aided discoverability, and once learned was faster than menus. Even though most users might use the ribbon, some might stick with the menus because that's what they were familiar with. This amount of redundancy is generally not a good thing, but it's better than forcing people to give up what they're used to, which can be disastrous from a marketing perspective (see Windows 8).

  • 2
    Typo in the link? It's featuritis on Wikipedia. Commented May 31, 2016 at 7:35

Microsoft's Jensen Harris wrote an extensive series of blog posts about the MS Office 2007 UI design as it evolved, which went into a great deal of detail about (what was then) the radical new ribbon design, why they kept what they kept, and why they changed what they changed.

Obviously a little dated now, but well worth a read.


scottishwildcat's answer already touched on Jensen Harris's excellent blog posts about the "new Office UI" (the Ribbon debuting in Office 2007), but there is one article which I think is particularly pertinent, titled "No Distaste for Paste":

Early on, we were toying with the idea of not having buttons for Cut/Copy/Paste in the Ribbon. Everyone “knew” that people mostly used CTRL+X/C/V to do most clipboard actions (which was true.) And that mouse users used the context menu to access these clipboard commands (which was also true.)

This, basically, is your logic: get rid of the redundancy and leave people with one way to do things. But...

What we didn’t know until we analyzed the data was that even though so many people do use CTRL+V and do use “Paste” on the context menu, the toolbar button for Paste still gets clicked more than any other button. The command is so incredibly popular that even though there are more efficient ways of using it, many people do prefer to click the toolbar button.

The result? The ribbon has a giant paste button!

The moral of the story is that different people prefer different ways of doing the same task, and a lot of the time won't even notice the "redundant" options they're not using.

Now, that doesn't stop you making an "opinionated" UI that says there is One True Way to interact with it; users who like that way will probably be happy with it, and you may not care that other users don't. If so, rather than "reducing redundancy", focus on "increasing consistency": don't say "I won't put that on a toolbar because it's in the menu", say "I'm going to try for a UI that has no menus, only toolbars".


Many ways to access functions are always good.

Take this text editor as example. You can write bold text at least in three different ways.

  1. Select the B icon on the toolbar.
  2. Type Ctrl+B.
  3. Write two asteriscs (*) before and after the text to be emphasized.


I recently had one of the worst user experiences using latest MS Word versions (2010 jumping from 2003). Not only I couldn't find the menu option, but keyboard shortcuts for that particular functions didn't work anymore. Why ?

  • 6
    You can also find the "Bold" option in the Fonts dialog, which although it may seem quaint nowadays, used to be an important teaching tool for users new to computer typography. That dialog listed all of the different styles that could be applied to text, and even let you preview them in a "safe" environment without affecting your document. Commented May 31, 2016 at 8:45
  • thanks for the correction... I'm new to this so I said "at least three" ;)
    – roetnig
    Commented May 31, 2016 at 11:44

If you look at it more closely, most of the redundancy consists of different "access vectors" to the same functionality. You may be able to achieve the same thing through the menu, through a context menu, a toolbar button or a hotkey – but you are unlikely to find multiple menu items or multiple hotkeys for the same thing.

These access vectors cater to different use cases:

  • Menus are great when you are searching for a feature ("how do I do X"), but they can slow you down on repetitive tasks.
  • Context menus work in a similar way, but only for operations clearly related to a particular item, and only for a limited set of operations (you don't want to overload the context menu). Tying them to an item makes them more intuitive than conventional menus (right-click an item and see what you can do with it).
  • Toolbar buttons may also be quicker than a menu for the "how do I do X" use case, as a picture is often worth more than a thousand words – but that varies. Some operations make for very descriptive icons while others don't.
  • Hotkeys are by far the fastest way to access a given functionality. However, you need to know them, making them poor candidates for the "how do I do X" use case. Therefore, they make sense for only the most frequently used commands (which vary from user to user). While it's good to have hotkeys for operations which are likely to be used frequently, they should never be the only access vector.

User preferences differ. As someone who has used computers in pre-GUI times, I am used to doing a lot over the keyboard. I use hotkeys and have occasionally surprised people by using Windows entirely without a mouse. On the other hand, I have seen other users who would type their user name into the logon screen, grab the mouse to click the password field, enter their password, then grab the mouse again to click OK. Unless an app is highly specialized, it needs to accommodate all.


Wordprocesors such as MS Word and text editors such as Notepad ++ have to cater for many different users. The extra functions to cater for all of those other users are comparatively cheap to implement, the extra features not needed by the majority is refereed to as software bloat. As someone above mentioned "normal" users only use something like 5% of the functionality.

I use Notepad++ for straight text, HTML and PHP. I don't need all of the other functions that it provides. But it is better for me to get one package that covers my needs, with a lot of stuff that I don't need, rather than 2 or 3 packages to meet my requirements.

Word has features that support very simple document creation. With the graphical interface my primary students can do basic text editing, formatting and inserting pictures. Way too expensive for them mind you. But I can use the same package to create all sorts of instructional documents for them with embedded hyperlinks and tables and "fancy" stuff. All of which they can open see and read with the same word processor.

I have worked with Legal departments that make extensive use of templates, form letters and mail merge capabilities. All the same package that my students use.

I grew up in the days of word processors for specific purposes, it was a nightmare to manage as an IT professional. Different people in the same department used different word processors to do different tasks, they could not share documents easily. Standardization gives you features that as an individual you may not use but in the business world makes it more cost effective overall and for the developers makes it easier to create and support.

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.