Hidden commands of Windows 8
One of the more “interesting” facts about the new Metro style UI in Windows 8 is how much of it remains hidden from the user until it’s needed.
This is one of the core design principles of Metro style apps, that the application’s content shall be king, and so all its UI chrome – which means buttons, textboxes and other widgets that make the app work – aren’t visible most of the time.
You may tap or click on anything you can see, but this will represent only a fraction of what you can actually do with that particular app. To discover most commands, you’ll have to learn how to swipe, flick or make various other new gestures to uncover the Charms, tabs and the App Bar that hide them from view.
This is a fairly radical departure for most users who have been brought up on Windows, with its multitude of menus, tabs, buttons and other visual cues that are always on show
This is a fairly radical departure for most users who have been brought up on Windows, with its multitude of menus, tabs, buttons and other visual cues that are always on show.
It’s even further from the principles of Microsoft’s previous Fluent UI – otherwise known as the ribbon – which was a model that strove to ensure every possible command and action had a visible cue that made it discoverable, and so ensured the user could get the most out of that application.
Hence Microsoft’s decision to hide most of the UI commands in Windows 8 Metro style apps, while simultaneously introducing the ribbon to other Windows 8 applications such as Windows Explorer, feels strangely contradictory and is difficult to explain.
I know that many users, even quite experienced ones, won’t even think to right-click on an object to discover what they can do with it. If they can’t see the command needed somewhere on the screen immediately, then they just assume the software can’t do it.
This user inertia or myopia was one of Microsoft’s main justifications for developing the ribbon interface, because the majority of “enhancement requests” it received for Microsoft Office were for functions that Office already had, but which users couldn’t find. Users might scan a couple of toolbars and drop down the one or two menus where they thought the command might live, but they gave up looking very quickly.
If you can remember as far back as Office 2003, you’ll be aware that its UI was pretty much a total mess. Items and buttons on its menus and toolbars would hide themselves if you didn’t use them for a while, causing panic and confusion among users.
Toolbars might appear on the side or bottom of a window, and right-click menus would cascade three-levels deep or more, vastly exceeding the mouse dexterity of most users. Lots of unrelated commands were all lumped into the “Tools” menu merely because they didn’t fit in anywhere else. Users who’d been using Office for several versions mostly knew what they were doing – but only if they stuck with the things they did most often, and if they strayed outside their comfort zone they’d probably struggle to make sense of this UI as much as any novice.
Microsoft decided the way to address all of these deficiencies was by making all of the commands visible, all in the same place – and so the ribbon was born. With more logical function grouping and fewer places to look, users ought to find out how to do what they wanted faster, while at the same time discovering what else the application was capable of.
Some, rather vocal, internet critics didn’t like the ribbon interface; many more were very happy with it. Yes, it certainly does take a couple of clicks more to do some things than it used to, and not all the commands are in completely logical places (for example, to insert a section break in Word you must go to Page Layout | Page Setup | Breaks, rather than the Insert tab where you might expect).