There’s been a fair amount of criticism regarding the poor discoverability of UI elements and interactions in recent iOS versions and especially iPadOS. Of course, sooner or later in the debate, comparisons with Mac OS had to be drawn. I’m not entirely sure whether it’s even the right comparison to draw, because a multi-touch interface and a traditional mouse+keyboard interface lacking direct manipulation are bound to have different paradigms and affordances. A better idea would be to compare, say, iPadOS with Android on tablets, or with Windows 10 on a Microsoft Surface device. But here we are.
In his recent Undiscoverable UI Madness, Matt Birchler writes:
We have a couple Mac users in the office so I went around and asked them how to do some things on macOS, which as we all know, is much better than iPadOS at making important, useful UI elements easily discoverable. I talked to 3 people who have been using Macs for years at work and home.
Basically, Matt performed a quick test of these people’s knowledge of parts of Mac OS’s interface and user interaction. The idea, I guess, was to see whether Mac OS’s user interface could have its areas of undiscoverability or poor discoverability.
By Matt’s own admission, this was just an informal thing, but I have issues with his conclusions all the same. After the examples, he writes:
I stopped there because we had to get back to work, but without even leaving the Finder and Desktop I was able to find a bunch of things that long-time Mac users had never known about because they never discovered them in their daily use.
Perhaps they never discovered them because they never use menus on a Mac. But let’s analyse Matt’s examples.
First test — A Finder window with several items displayed, but a hidden scroll bar.
Result (quoting Matt): 3 out of 3 knew they could scroll, so good so far. I asked how they would know if they could scroll in another window, and they said you basically just try to scroll, and that’s how they find out.
The removal of persistent scroll bars in the Finder is a personal pet peeve. Removing them was a silly decision, usability-wise. Still, if you’re presented with a Finder window and don’t know whether there are more elements than those displayed, another quick way to check is to change the window’s view. You could switch to List view, for example, and that would reveal that the folder contains more elements than what you could see in Icon view.
And you can switch view in at least two ways, both discoverable: by clicking the relevant toolbar icons (which are visible by default), or by going to the Finder’s View menu and select as List. Using the menu, you also find out there are keyboard shortcuts to switch icon view: ⌘-1 (View as Icons), ⌘-2 (as List), ⌘-3 (as Columns), and ⌘-4 (as Cover Flow). I’m still on Mac OS 10.13 High Sierra, maybe the shortcuts are different under 10.15 Catalina.
Second test — Previewing an image without using the Preview app.
Result: 1 of 3 could do it, with the others really impressed that Quick Look was a thing and said they never would have guessed to hit space to do it.
I honestly have a hard time believing that people who “have been using Macs for years at work and home” didn’t know about the spacebar shortcut for Quick Look. But anyway. Suppose you don’t know that either, and you’re given this test. How could you find a way to do what’s asked? Well, by exploring the interface before you. You’re in the Finder. The image is in a Finder window. The default toolbar of a Finder window has an Action button (the gear icon). You click on it and a pop-up menu appears. One of the menu items is Quick Look “[file name]”. There you have it.
Is the image (or other kind of file) on the Desktop? You go to the Finder File menu and, again, one of the menu items is Quick Look “[file name]”. There you have it.
Third test — How to right-click on a folder.
Result: One knew how with the Magic Mouse, but the other 2 agreed they needed to do it on their trackpad because Apple’s mouse only has a single click. None knew you could also Ctrl+Click to bring this up.
While not knowing that Ctrl-click is the historical Mac shortcut equivalent to PC’s right button mouse click seems to me even more incredible than not knowing about Quick Look’s spacebar shortcut (simply because Ctrl-click is a shortcut that’s almost as old as the Mac itself), I’d like to point out that even without knowing you can right-click (or Ctrl-click) on UI elements, you can achieve the same effect in another way. Again, you either use the Action button in a Finder window’s toolbar, or the Finder’s File menu. Again, familiarising with the Finder’s menus is a double discovery: you find out all the actions you can perform on an item, and you find out that most of these actions have a keyboard shortcut assigned to them.
Fourth test — Matt writes: While here, I right clicked on a PNG file and asked how to make that file type always open on Photoshop instead of Preview. None knew you had to hold Option while using the “open in” option.
Again, holding the Option key while using the Open in command is not the only way to do this. This can be discovered, for example, by opening the Info panel of the file (File → Get Info) and looking at the Open with section. The pull-down menu clearly tells which application will always open this file by default, but by using that same menu you can change such application and select another to open that file — and you can also specify that your choice will be the new default for opening all the files of the same type.
Is this alternative as direct and straightforward as holding the Option key while selecting Open in? No, but it is discoverable by exploring the user interface.
Fifth test — Enabling the Do Not Disturb feature.
Result: None were able to do it, even when I said it was in the notification panel. Hint: you need to scroll down to see it and night shift.
My wife is a long-time Windows user. She’s not very familiar with Mac OS’s user interface. I asked her to do the same. She clicked on the Spotlight icon and typed Do Not Disturb in the search field. The top hit was the Notifications preference pane. She selected it, System Preferences opened and the Notifications pane came up:
At this point, she clicked on the icon next to Turn on Do Not Disturb in Notification Centre. This opened the Notifications pane and both Do Not Disturb and Night Shift were visible. When I asked her why she thought that the icon was clickable, she said that she recognised the shape of the switch in the icon, and clicked on it believing that it was the actual switch to turn on Do Not Disturb. This is definitely not a very well-designed user interaction, and is perhaps one of the best examples of poor discoverability in Mac OS. But still, it remains discoverable by exploring the interface.
Sixth test — How to navigate to the folder above the one you are in.
Result: No one was able to, and telling them that they could by hitting Cmd+up arrow or Cmd+clicking on the directory name in the title bar was deemed the most hidden thing thus far.
I don’t know why people don’t use the thing they have in front of their noses. When I read this example, I confess I did not remember an alternative way of achieving the same result. I’ve been having the ⌘-↑ keyboard shortcut in my muscle memory for so long. But a brief exploration of the Finder menus led me to discover that if you select the Go menu, there’s the Enclosing folder command right there, and with the relative keyboard shortcut of course.
The important point about discoverability
Matt writes:
None of this is meant to say macOS is garbage or anything like that. It’s just interesting to see when people who love the Mac and are so critical of “discoverability” on the iPad. I’m not even saying the iPad is better than the Mac here, I’m just saying that “discoverability” is one of the big things that has people in a tizzy right now about the iPad, but I think some are laying into the iPad harder than is warranted.
The term discoverability applied to a user interface refers to something that can be discovered within the interface. A UI element or interaction may not be immediately evident. If it can be found within the interface through exploration, then it is discoverable. If it can be found through knowledge only, and such knowledge lies outside the interface, then by definition it is not discoverable.
The problem with the iPad (and to a certain extent with the iPhone) is that certain gestures, controls, and operations, are essentially undiscoverable. You can stumble onto them by chance, but I hesitate to call this discoverability.
On the Mac, a user may not know about a certain keyboard shortcut or mouse/trackpad gesture to execute an operation, but that’s just a shortcut for the default way to do such operation, which in most cases simply involves pointing and clicking on a button or application menu, as we’ve seen in my counterexamples above. The default way can be explicitly found within the interface. It’s not something you can only find in a user’s guide, instructions manual, or Apple’s KnowledgeBase.
If the only way to Quick Look a file on the Mac were the spacebar shortcut, and you couldn’t find any hint in the whole user interface telling you about that, then yes, I would say that such feature is undiscoverable without external knowledge. But it’s not the only way. And the traditional way — using the mouse or trackpad and invoking a menu — can definitely be found; it’s not that complicated or obscure.
Now think again about multitasking on the iPad. Imagine you don’t know how to do that. Where do you find how to do it within the user interface? Is there an element of the user interface of iPadOS you can use to perform the necessary multitasking gestures without failing? There is not. I would really love to conduct some user testing and ask someone who has no idea how to do multitasking on the iPad if they can find out even by simply messing around in the interface and stumble onto it by chance. (Is there even a mention of multitasking in the Tips app, by the way?)
Different interfaces, different ways to approach discoverability
Designing for point-and-click interfaces and designing for multi-touch interfaces involves different ways in how elements and possible actions are presented to the user. In traditional point-and-click interfaces, due to the inherent precision of the pointing device, you typically have smaller UI targets, and you can have a lot of them displayed in a single window or desktop. This allows you to delegate several functions to menus and toolbars, for example. Not to mention the fact that you can have more than one way to execute an action, given the additional help of keyboard shortcuts.
With touch-based interfaces, designing user interaction is trickier. You don’t have a desktop metaphor where you can freely move different application windows around. You don’t have menus. You don’t have small targets. You can’t rely on keyboard shortcuts as backup because a physical keyboard is an optional accessory for a tablet. And if your user interface is not designed for a stylus as primary input device, you can’t place small buttons and UI elements as additional tools to add functionality or help discoverability. (Well, you can, but that would have other repercussions usability-wise).
You have to design for the finger: targets need to be big enough to be easily tappable. You have app icons, buttons, switches, sliders, you have big lists of tappable items, you have panes, you have gestures. Little else. Making an element or action discoverable is more difficult, but not impossible. One of the side effects of the post-iOS 7 flattening of the UI is that it has also become terser. With touch-based interfaces in particular, it’s important to offer visual cues that effectively give little nudges to the user, as in: you can move this pane out of the way; you can swipe in this direction to reveal more contents or more of the app’s interface; you can drag your finger from the bottom upwards to invoke a secondary, overlapping pane; you can see at a glance that this UI element is in an active state or is in the foreground via the use of colours and shading. And so on.
These are just a few examples of affordances. If you remove them because you give more prominence to gestures — which are ’invisible actions’ — then you also make things less discoverable, or not discoverable at all. In the early versions of iOS there were fewer gestures and more actions based on buttons. This might look ‘inelegant’ today, but it was also a less ambiguous approach than what we have now. Especially when today we’re given a more complex gesture vocabulary that differentiates between, say, a flick-style swipe and a slower finger-drag.
Here’s a small example of how BlackBerry 10 OS handles a case of potential ambiguity when it’s time to perform a gesture. Say you wake your BlackBerry device and you don’t remember the correct way to unlock the screen and enter your home screen. After tapping two or three times on the display, a helpful tooltip appears for a few seconds:
Is this an easy way out, design-wise? Perhaps. Could this have been designed in a subtler, sleeker way? Perhaps. But it’s so much better than leaving the user guessing and feeling stupid. It’s also an effective reminder for people like me, who handle different devices from different platforms and sometimes lose track of which gesture does what on which device.
Closing thoughts
Discoverability is important and is one of the things that help make an interface and a device more intuitive, usable, and user-friendly. It’s certainly harder to make elements and actions discoverable or more discoverable in a touch-based interface than in a traditional computer’s user interface which is historically and inherently more fine-grained.
Harder, but possible. You have to keep feature creep in check, and you have to always keep the whole system in mind when you ‘grow’ new features or iterate on previous ones. Otherwise you risk burying something beneath UI layers or beneath other stuff you, as a designer, are now taking for granted. Which is what I feel has happened in certain areas of iOS and iPadOS.
The criticism towards discoverability in iPadOS is not unwarranted, in my opinion. No user interface is perfect. But one tends to be more forgiving when the undiscoverable UI element, action, command is tied to some minor system feature or infrequent operation. The keyboard shortcut for turning off your Mac’s screen (Shift-Ctrl-Eject or Shift-Ctrl-Power button) is virtually undiscoverable. I myself found it out by chance when I reached this Apple support page while looking for something else entirely. But not finding it, not knowing about it — you’ll agree — is not a big deal.
However, for something as essential to the productive use of an iPad as how to handle multitasking and interoperation between running apps, its poor (or rather, nonexistent) discoverability is unforgivable. Especially, as I already said elsewhere, because it’s Apple we’re talking about. The company that made user interface, user experience, and usability fundamental parts of their DNA. The company that seems to overlook these fundamentals a bit too often, lately.
