Why do editors (such as MS Office apps) have so much redundancy?

Question

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.

Answer 1

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.

Answer 2

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).

Answer 3

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.

Answer 4

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.

Summary

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.

Answer 5

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).

Answer 6

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.

Answer 7

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".

Answer 8

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.

Nice....

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 ?

Answer 9

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.

Answer 10

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.