This post requires that users ignore the most prominent and longstanding discoverability feature of the Mac: the omnipresent top menubar.
1. Scrollable windows flash their scrollbars when focused. This bit of bad UI was imported from iOS. Unlike iOS, it can still be turned off: Click the Apple menu -> System Preferences -> General -> Show scroll bars.
2. File menu -> Quick Look.
3. Every action in that context menu is available in the File menu.
3a. Holding the Option key works in the File menu as well, but this change can also be made from File menu -> Get Info -> Open with.
4. This actually bad UI was, again, taken from iOS.
5. Go menu -> Enclosing Folder.
Nearly every example is solvable with single clicks in the always-visible, literally spelled-out menubar, as they have been for 30+ years. They are therefore eminently discoverable, contingent on a user giving a thought to trying in the first place to discover them. The one or two examples where this is not true are direct iOS tack-ons that do not respect the platform.
What this post is doing is mendaciously pretending that power-user shortcuts, some more or less discoverable than others, are the only way to perform these operations which can actually be accomplished by reading and clicking. The attempt to equate the Mac's discoverability with iOS fails once that is pointed out, since in the latter those mystery-meat gestures truly are the only way to execute them.
The menubar doesn't make it more discoverable. If it did, the users in the article would have thought to look there, but they didn't. Nobody bothers with that anymore. This was not obvious to me until I saw people getting used to iOS programs where menus don't exist. The menubar is good at showing you a soup of options but is really bad at contextualizing it. The problem shows up in MacOS programs where they stuff all the contents of every context menu into the menubar just so they can say that it's usable with one mouse button. Well if you do that, the context behind all these actions and the locality of information goes away!
Even in simple programs like the finder there is global application state that can cause some menu items to arbitrarily become inactive. The action itself might be discoverable, but the state that it relies on isn't discoverable at all. Take a more complex application with massive 50-item-long menus and it gets ridiculous. The menu doesn't communicate at all what an action means or when it should be used. In that situation the only thing the menus realistically exist for anymore is a learning tool to help memorize keyboard shortcuts.
Side note: I didn't think I would be approving of Microsoft designers on something like this, but I think their "ribbon" UI has been a good step away from giant crazy menus.
> The menubar doesn't make it more discoverable. If it did, the users in the article would have thought to look there, but they didn't. Nobody bothers with that anymore.
I do it, almost without planning to, with most new software I encounter. Perhaps because I learned computing in the WIMP days. To say "no-one" does it, is false.
The overall argument you're trying to counter is that the menubar doesn't aid usability and thus discounts itself from arguments of iOS vs Mac usability. This is also ridiculous. Everyone uses menubar all the time - sometimes they're more icon-y, sometimes more text-y... but they're everywhere and to say people don't look across them is to deny the existence of vision.
> I think their "ribbon" UI has been a good step away from giant crazy menus.
When you discuss UX you always have to be aware that you have two very distinctive populations with very different expectations: new users and old users.
Everyone I've ever seen trying to find something in new Office apps (myself included) was bitching about ribbon menus and how much they suck. It's 100% biased because we all were used to the old UI, but since I use Office and Windows only occasionally, to this day I still didn't get used to it fully.
For new users who grew up on Win10 and this type of UI I'm sure it works great.
The Ribbon’s terrible because there’s no regularity in its structure. The eye can’t scan quickly: sometimes controls go horizontally, then they go vertically, then they run horizontally again.
Old-school Apple menubar; yeah, that’s not exactly cutting-edge UX any more. Scrubbing through fixed hierarchical menus spatially disconnected from the data they operate on is crude and pretty tedious. And Apple’s never really made much effort on the (adaptive) contextual menu front; macOS has them, but they’re more like a resentful afterthought.
Alas, blue-sky R&D into new, novel, cutting-edge UI/UX hasn’t been a thing at Apple for over a decade. Well, except maybe Siri, but even that was bought off the shelf and they’ve hardly put their backs into making it any more than mediocre. Amazon and Google care more(!).
> The Ribbon’s terrible because there’s no regularity in its structure. The eye can’t scan quickly: sometimes controls go horizontally, then they go vertically, then they run horizontally again.
Also some things are hidden in a dialog box which becomes available when you press the little arrow in the corner of the ribbon element. Good luck!
“Mendaciously pretending,” is over the top. Even if you don’t agree with the author’s point, even if you think the tested users are idiots or unrepresentative, there’s simply no justification for calling the author a liar or suggesting he’s anything less than earnest.
It’s entirely possible that none of these users thought to use the menu bar for these tasks. I, for one, have never thought to use the “Go” menu to get to the enclosing folder. Why? I don’t know. Maybe I’m dumb. I guess it didn’t occur to me that such a frequently needed action would be provided and yet not given dedicated UI in the window frame.
Similarly, I “know” how to set the default program to open a file from the info pane, but I always end up re-discovering it because I do it so infrequently, and it’s not intuitive to me to find it under “Get Info.” I always doubt it until I find it there.
Nor does it matter where macOS inherited usability issues from: they still exist in macOS, they still affect macOS users.
I also think you’ve taken the wrong point. I don’t read the post as arguing that macOS has just as many discoverability issues as iOS or that it’s not in better in some ways. Instead, it seems to me the author is clearly arguing that macOS also has discoverability issues even for daily and power users, and thus we should re-evaluate both how good macOS’s discoverability is and how bad iOS’s is.
Scrollable windows flash their scrollbars when focused.
No doubt there's a setting for this somewhere in OSX, but that isn't happening for me in Chrome, and it doesn't happen in the notifications panel where the Do Not Disturb toggle is either. What's worse, I set scrollbars to "Always show" in preferences it still doesn't show me that there are hidden options at the top of the notifications panel. There is nothing in the UI to indicate that those are there.
I've talked with perfectly otherwise intelligent friends who didn't know that on Facebook Messenger, clicking the Phone icon on the top-right of the screen that's present in every single chat view allows you to have a voice call with the person in the chat.
It could not get more obvious than this. Some people just need to be taught. They will never discover on their own.
This is why manuals and help pages along with just one or two good UI abstractions (a la readline with tab completion) will almost always be superior to poking at pictograms.
Snapchat style GUIs will probably remain sexy on the other hand.
> I've talked with perfectly otherwise intelligent friends who didn't know that on Facebook Messenger, clicking the Phone icon on the top-right of the screen that's present in every single chat view allows you to have a voice call with the person in the chat.
My friend, there are a lot of icons in every program. When the smart developer relies on the stupid user (emphasis mine) to guess what he wants without bothering to put a text label or a tooltip describing the role of the button don't expect wonders. And since "material design" it is really difficult to say if an UI element is a button, or a label or just a decoration without clicking on it and opening the Gates of hell.
> It could not get more obvious than this. Some people just need to be taught. They will never discover on their own.
There was a saying "The only intuitive interface is the nipple". Some people with children say it's an overstatement.
> My friend, there are a lot of icons in every program. When the smart developer relies on the stupid user (emphasis mine) to guess what he wants without bothering to put a text label or a tooltip describing the role of the button don't expect wonders. And since "material design" it is really difficult to say if an UI element is a button, or a label or just a decoration without clicking on it and opening the Gates of hell.
I'm loathe to disagree but at this point, the phone icon is like the icons for designating Men and Women's restrooms. It's practically universal. It's the icon you use to open your phone app on your phone.
I'd say that is intentional, though. The second phrasing won't give you any good results if you're trying to determine the usability of a UI design.
Normal users do not hunt for hidden options the moment they encounter a use case for them. In fact, most would probably assume the feature isn't there even if they realized they had a need for a somewhat generic functionality such as moving to ../
If you offer someone money for finding out about something they don't know about, you change their motivation, which is thus completely different from what they encounter in their day to day use of that software. And the latter is the thing you want to improve in the end.
Being humble and being observant are both important but in most interesting design challenges the data is sparse relative to the space of possible design solutions. Heuristics and opinions are a necessary part of the process.
Good designers listen and inject well formed options into the product.
While 3 is a bit on the low end, user studies are not required to have large sample sizes. You're not trying to estimate what percentage of users are running into a particular issue, but only which issues many users run into. Whether it affects 10% or 30% of users does not really influence whether it should be fixed.
And this is why the field of design gets shit on so much. Jakob Nielsen might have a PhD, but he’s much better at PR than he is at conducting actual research. It’s mind boggling to me that people will still quote his opinion pieces 20 years later as if there was any actual science behind them.
There’s a few other fields that happen to conduct a lot of studies around human behavior. It turns out, there’s actually an established process for calculating the confidence level of your findings:
Is 3 or 5 better than nothing? Sure! But don’t trick yourself into thinking your findings actually mean anything because a Danish dude drew a graph 20 years ago.
So again, a large margin of error and a low confidence level are fine, because it doesn't matter if in reality, 80% of your users run into something rather than the 60% that came out of user testing. In fact, we don't care about the specific numbers at all. All we want to know is what things are unclear to many users. Often, you test a design on five users, and all five of them miss the same thing - that gives you plenty of confidence that you'll want to try something else there.
User testing is not a statistical test, and it's not a way to learn about human behaviour (so indeed, in that sense it doesn't "mean" anything); it's to give insight into your designs. I'd highly recommend everyone to take part in conducting user research sometime, as it will quickly become obvious just how easy it is to miss "obvious" things in something you're closely involved with, and how you need to have just few people interact with it to find out which.
Anecdotal, but I've observed quite a few in-person usability studies. After the the third or fourth person you've usually discovered all your're going to with your current test script and stimuli.
You probably could design a study that would continue to uncover new issues after many tens of people, but the test would probably be two hours long and would be unreliable based on that fact alone.
The NN Group article linked by the sibling comment holds true in my experience.
if, as a UX designer, you don't have opinions, then all you're doing is blindly optimising for metrics that may have nothing to do with actually good experiences. This is why platforms like twitter and facebook are such cacophonous trashfires: UX "Designers" chasing "engagement", and holding no opinions. you might as well just hand your job over to an AI, you're contributing nothing to the process.
The difference between macOS and iOS isn't about discoverability (although, in one important area macOS far more discoverable that iOS: multi-tasking). The problem with iPadOS is that since all the expert controls are hidden, and there's no such thing as shortcuts or right-clicking on iPadOS, it means doing anything useful with iPadOS requires using many slow gestures in succession.
macOS, with a combination of Bash, AppleScripts, and system-wide third-party utilities like Keyboard Maestro and LaunchBar, provides extraordinarily efficient ways to do powerful things, whereas doing anything on iPadOS is like being stuck in quicksand. Just the minutia of navigating the OS with only Apple's provided gestures is so slow and clumsy that I wouldn't bother to do anything complicated with it. It just takes so much effort, it's exhausting. So neither OS is great at discoverability, but only one OS can be used efficiently by a proficient user.
I'll say it again and again: The measure of a platform is not how easy it is to use for it's weakest users, it's what it's more proficient users are able to accomplish with it. Until Apple takes proficient users seriously, iPadOS will be nothing but a side dish, because no one will use it to make anything that anyone else would ever want to emulate.
I'll add the best thing Apple could do to fix iPadOS is make the developers working on it bootstrap[0] it. E.g., by running some version of Xcode on it (or CLI tools until they have Xcode working). Those developer would then fix it right up.
I contend that iPadOS is so sluggish to use because it's a compile target from a real machine that developers respect and work on, not a machine that those developers take seriously itself. That Apple is pushing a platform so hard that their own developers would never use for their work is everything you need to know about using an iPad for productivity. Sure, there are other tasks you can use a computer for besides programming, but sorry, programming is the task for computers, everything else stems from it.
I think of the iPad like a car. It does a few things well... but I would never use one car as the means to build another. My computer(s) function much better in those roles.
Porting the toolchain is arguably trivial, but making a pleasant developer experience on a computing platform that may or may not have a keyboard is another concern entirely.
Making a pleasant developer experience is a lot easier than getting iPad to load your compiled code at the moment, and the current state of developer tools reflects this.
Easier for everyone other than Apple itself. But GP was suggesting that Apple build it, and Apple can easily modify their own code signing restrictions.
Sure you can. With a developer account nothing is stopping you from running a compiler on your device. You don’t need root or jailbreak to run a compiler.
As other poster alluded to. It’s not the difficulty, it’s that given the environment of the iPad, there isn’t a compelling use case.
> Sure you can. With a developer account nothing is stopping you from running a compiler on your device. You don’t need root or jailbreak to run a compiler.
You can run a compiler, but you cannot run the generated code.
My iPad is probably my most-used device, but it is also the device that I most often feel like throwing at a wall. Wading through quicksand is exactly how it feels like to do anything "advanced".
Not to mention the madness that is the Files interface. Far too often I find myself selecting a file, wanting to do something simple with it (like move it to a a location managed by another app) and just being stuck. Again, the quicksand feeling. I just want to get to that place right over there a few steps away, but there is no obvious way of getting there.
> Far too often I find myself selecting a file, wanting to do something simple with it (like move it to a a location managed by another app) and just being stuck
Have you tried drag and drop? You can still navigate between folders while one finger is dragging the file.
Alternately you could open two instances of Files at the two locations and drag it straight there, but that approach means sorting out how the multitasking works.
Almost nobody takes proficient users seriously, because there aren't enough of us. Only one demographic gets design priority nowadays, it seems, and it's definitely not power users.
(This message brought to you by UX designers declining your feature request because, "you think you want it, but our testing shows that you really don't")
> The measure of a platform is not how easy it is to use for it's weakest users, it's what it's more proficient users are able to accomplish with it.
It depends on who the target users are and what the platform's trying to do. An OS like iOS which is designed for complete novices should be judged on how easy it is for them to use (and it does this reasonably well, or at least it did until they started getting silly with the undiscoverable multitouch stuff.)
I don't think it does, but if it did, we have an answer. Yes, Apple implements ideas they did not originate. Right-click is sort of the canonical example, because they fought it for a long time. Tool Tips is one I wish they hadn't, I hate them. Tabs. Unix. Enterprise management. The command line(!)
If there’s one area where macOS has lagged behind Windows for decades, it’s in making all menu items accessible using the keyboard by default (not forcing the user to go to Settings and setup a shortcut, which is very nice). In Windows, pressing Alt and then the underlined character in a menu name and then a submenu name would be the easiest way to get to things without even knowing any other shortcuts. On the Mac, many menu items don’t have shortcuts attached to them. To get to the menu bar using the keyboard, you have to hit Cmd+F2 and then use arrow keys to navigate — it’s useful when you can’t use the mouse or trackpad, but it’s highly inefficient.
I’ll list just one example of not having default keys for menu options. In Preview, you can adjust the size of an image from a menu option. But that specific menu option, among others, does not have any shortcut. If you need to access it via the keyboard, your choices are to use Cmd+F2 and then crawl around or go to Settings and setup a shortcut for it (playing around to avoid conflicts with any system wide shortcuts).
Late reply, but that's still very slow and cumbersome compared to hitting Alt and then a couple of keys on Windows.
I can give more examples. The default on Mac, for a very long time, has been to not allow tab to navigate all controls in windows and dialogs (the default is only text boxes and lists). This has to be changed by the user in System Preferences.
Another point on keyboard support is how it's missing on macOS in certain places. An example: Download a DMG file of an app that's already installed (say you're doing a manual upgrade), open it using Cmd+Down Arrow, and then copy the app into /Applications (let's assume the keyboard is used for this entire flow). If your user account is not an administrator, you'd get a dialog to authenticate first, and then another dialog in response to the fact that an app with the same name is already there in /Applications, with options to Keep both versions, Stop the operation or Delete the older version. On macOS Mojave, I find that this dialog cannot be navigated using the keyboard at all (hitting tab or space or Enter does nothing)! The trackpad is the only way to respond to it. I have never seen this kind of behavior on Windows dialogs, whether they're from an application or from the OS (for UAC or other permissions).
If I go by my family, I don't think using purely keyboard is something normal users would be doing anyway. So it is possible that they simply have not found it necessary to add as default (I say this as someone who uses a lot of keyboard, and custom shortcuts).
Not to me, what I got from the article is that most people can't use basic functionality that macOS hides by default.
The vast majority will not learn that ctrl + click does right-click, and that you can enable scrollbars again to actually see if there is more content to view.
> The vast majority will not learn that ctrl + click does right-click, and that you can enable scrollbars again to actually see if there is more content to view.
How are they suppose to learn that ? Is it described in a help text somewhere ? How about Shift + Click ? Or Caps Lock + Click ? Will this destroy my document ?
Now seriously. People (except children) have a lot of other things to do instead of doing detective work.
Late reply. I know that developers assign the specific key for each option on Windows, but the fact is that if you take a bunch of commonly used Windows programs and compare them with a bunch of commonly used Mac programs, you'd find the Windows ones a lot easier to use with a keyboard. I have been using both Windows and macOS (and its earlier versions) everyday for a long time, and I see the keyboard accessibility as a comparative deficiency on macOS (though I like how easy it is to assign custom shortcuts from System Preferences).
One of the long-standing problems with Windows is that, despite the existence of fairly detailed UX guidelines for the platform, they are routinely ignored by developers targeting it. Worse yet, many aren't even aware that those guidelines exist.
Decades long user of Apple devices, and a long time developer, and I learned a few things from that article. Have designers lost sight of the fact that 99% of people use their eyes when working with an interface? You cannot simply hide the simplest visual cues and expect people to find out about them accidentally, or via a video or article like this.
My biggest gripe at the moment is the photo sharing option in the latest iOS. The 'Copy' or 'Send To' options used to be immediately in front of you as buttons. Now, they are hidden below a 'swipe up' menu that resides off screen. There is not even the simplest hint that you can swipe up, and it took me literally weeks of using the new iOS update to discover that purely by accident.
Why not have the visual clue by having the top bit of the first menu option just showing at the bottom of the screen? That at least gives me as the user looking at the screen the idea that "Hey, there's something that goes off screen here - maybe I can swipe up a little to see it better...Ooooh - there is a whole menu hidden down there!".
UI/UX Designers - STOP designing screens that look cool on your Dribbble, UpLabs and Behance portfolios and start designing screens that give people hints as to how the interface is to be used. Please.
I'm with you, as far as wanting visual affordances for functionality, but I think it's a generational thing. Teenagers have no problem navigating Snapchat, and it allows for gross gestures like a swipe, which can be faster to apply than looking and aiming for an icon.
Good post - these features are quite undiscoverable, and I only figured them out because I did them accidentally one day or someone showed me.
Someone at Apple made the determination that "looking simpler" was more important that UX discoverability, and so hid some features under Ctrl/Command clicks.
A worse offender is "Command+Shift+." for showing hidden files - they don't even have a menu item anywhere for it, it's either you know that hidden files is a thing or you don't, and there's no way to discover it by clicking around and paying attention.
While I still prefer macOS to Windows, I agree that Apple could do a bit more to make these hidden features more exposable. E.g. why not let a click on the folder name show you the folder path, why require a "Command"?
That's one thing that baffles me about MacOS. There is a lot of powerful stuff hidden behind keyboard shortcuts but there is almost no way to find them. It seems a colossal waste of energy to first implement them but then making it very hard to find them.
On iPadOS it's very similar. Sometimes I get two apps on the screen by accident but I have no idea how I did it and there is no way to find out how to do it if you don't do an online search. Good old drop down menus were actually good for something.
While it doesn’t solve the issue of not knowing a feature is there in the first place, if there’s something you’d like to do in an app, you can get a long way by hitting “Help” in the menu bar and typing it into the search field. If there are any matches for it you’ll immediately know you can do it, and it will open up the menu and show you exactly where it is (and the keyboard shortcut, if there is one).
This is the primary way I look for power-user or other non-obvious features in new Mac apps.
Menus are still superior to help search for feature discovery because they are an explicit navigable enumeration of the feature set surface; if help doesn't have the right synonyms, you'll be stuck, whereas menu item listing might hint at different ways to accomplish the same end goal.
FYI the search box in the help menu searches the rest of the menu bar. It's great for feature discovery if you think something might exist but don't know where it is.
My point is that menus work as a way of exposing functionality and making it discoverable through enumeration in a way that contextual UIs and fashionable techniques of the day don't.
This is in addition to access keys (also explained in the document above), underlined letters you can type to instantly navigate the menus and select even the items for which no shortcut is defined.
Hidden files are hidden on purpose, because most users have no reason to see them. Arguably, it’s not a good idea to make them more discoverable. Power users will learn about them the first time they try to do a task that requires working with hidden files.
I think most people would agree with that. But I think the point being made is that there should be a better way of figuring out how to do these hidden things if you know they exist, without the use of an internet search.
I thought for sure that holding some combination of option, shift, and control would reveal the command to show all hidden files, and...nope. It’s truly only available as a key command. Wow.
A good UI can only ever have a limited number of discoverable actions. You can try to make a button for everything, but no one is going to try all the buttons, much less remember what they mean.
So you have to pick which actions are most important, and make those easy to discover. QuickLook is a wholly essential feature. So is navigating up a level—it's very useful in some instances, but the back button does the same thing 90% of the time.
For the rest, what matters most is that the actions are never activated accidentally†. This last point is, IMO, where iPadOS fails the most.
*
However: it is worth noting how far the Mac has fallen in the past decade. Snow Leopard had persistent scrollbars, that were big and blue so you couldn't miss them. Finder's toolbar had a button for activating QuickLook. And of course, the notification center didn't exist yet.
There's a pattern behind all these changes. Scrollbars were modified to match iOS. The QuickLook icon was removed to make room for a share button that mimics iOS. The design of notification center was basically ripped from iOS wholesale.
So yes, I agree that iOS has UI problems.
——————————
† Unless the user can instantly parse how they accidentally triggered the action. If you can turn the accident into a learning experience, that's fantastic.
‡ It's still there, but disabled by default. So in terms of discoverability, it might as well not exist.
> A good UI can only ever have a limited number of discoverable actions.
Edit: FTR, this comment is kind of hyperbolic. I do not think I can outsmart all UX designers alone or that all UX designers are dumb or that those who designed Ribbon are dumb. I'm just pointing out that 1. I think there was a golden age of discoverability in UX where everything could be discovered and 2. It is over now.
Unless I misunderstand something here this should be plain demonstrably wrong (and note for context that I'm not exactly a Windows and Office enthusiast, quite the contrary):
In Microsoft Office (and a good number of other application) everything was available through the menus.
Toolbar buttons were just shortcuts fot the more important ones.
Then "UX" happened on Windows and today we've suffered through
- Office automatically hiding half the menus (late pre-Ribbon)
- early (but released, not Beta) Ribbon versions where File and Save was hidden behind a round flag that turned out to be a button.
- now: Ribbon is actually usable. Nice looking, still less predictable and more visual noise in addition to the leftmost menu (File...?) behaving in a (weirdly IMO) different way.
- now: menus are gone in many applications. I belive Chrome is the culprit here. Designers like Chrome it seems and for a number of UX-designers the idea seems to be that whatever Chrome and Mac OS does has to be copied across OS and domain boundaries.
If it wasn't clear:
UX on Windows used to be great. The OS was closed, slow, annoyingly limited etc, the UI was kind of ugly and business-focused but the UX was discoverable and usable.
What should have been done? I don't know but here are a couple of ideas:
- search in menus (as implemented in IDE settings, Visual Studio palette etc)?
- add fallback with synonyms and slight fuzzing to the search index so you get can the correct tool even if you misspelled it or if you are stuck on a Norwegian or French version.
- make enthusiastic videos about how it is best (I'm only half joking here, it seems to have worked for the vim crowd, - a number of people spend weeks learning a decades old editor whos discoverability is so bad no one knows how to even exit it the first time they open it.)
> You can try to make a button for everything, but no one is going to try all the buttons, much less remember what they mean.
That's where old-fashioned hierarchial menus are good. They're categorized lists of actions, where most of the actions are hidden most of the time, but can be read (and ideally have descriptive names). Typically there are also toolbars with buttons for the most commonly used actions.
These days it's become popular to hide all the menus behind a "hamburger" icon, which does satisfy the design types without harming usability all that much.
The other option is to have a gigantic button for everything, with tabs of buttons, and call it a "ribbon". The more cryptic the icons the better, you've made the decision to go to a ribbon so you wouldn't want to make things easy.
Practically speaking, Notification Center already existed, it was just called Growl. Everyone I knew with a Mac had it loaded, and Apple adopted the API whole-cloth for Notification Center, for compatibility reasons.
By now, yes, this is true. When it was first released it was just Apple-flavored Growl.
I don't find myself using most of what's been added. I routinely forget that there's a drop-down with all the stale Notifications in it, and other than the evening Do Not Disturb which turns on automatically, I forget (sometimes to my detriment) that I can activate it manually.
I just remember switching over at some point and not really noticing. Messages still made a small noise and slid in from the top right; some would disappear, some wanted me to click on them.
Like I said, I barely use the panel, and thought (thank you for the correction) that it was a later addition.
Ah, you may be thinking of Lion, which had notifications but not Notification Center. Notification Center is the name of the panel specifically, and that came one version later in Mountain Lion.
> There's a reason people pay lots of money for Bloomberg terminals, with their zillion labeled physical keys.
And a reason that type of design is only used in specialized, targeted scenarios. They have their place for sure, but it's pretty narrow.
> On the other hand, if there's no other way for people to discover them than accident ..
If it's a nonessential feature, I don't think that's a problem. You're allowing people to learn the system at a gradual pace.
The best interfaces are ones which are accessible to newcomers, but slowly train you to become a power user just via incidental use. OS X used to be very, very good at this, and still does an above average job in many respects.
> None of this is meant to say macOS is garbage or anything like that.
I think an OS as prolific as macOS having such shit UX kind of implies it is garbage though.
The year is 2020 and macOS still doesn't have a location/address bar in Finder.
Basic native UI interfaces still completely lack keyboard controls.
Window snapping is still non-existent.
I understand Apple strive to be different, but lacking these basic features (among many others) makes macOS have an arguably inferior workflow to Windows or Linux/BSD DEs.
Excluding these things are not unique and quirky subjective design choices Apple can continue get away with. They are baseline expectations for a workstation computing environment to meet, which macOS does not. The way I see it, macOS is increasingly falling behind in UX. Not only have Apple failed to make their own improvements and innovations; they've failed to keep pace with Microsoft and the Open Source community.
Those are breadcrumbs, not an address bar. Note the fact you cannot type or paste a path into it, as is a core feature in practically every file manager in every other OS. There is no apparent difference to breaking this convention, beyond impairing users' workflows. Finder also has the "Go to" dialogue, but again, it is a functionally inferior solution.
There is absolutely no good reason for these design choices other than to "be different for the sake of it" at the expense of good UX
Unlike address bars in other OS file managers:
- Finder Go To does not provide suggestions/completions (unless there is only one single match in the current folder, it'll complete the name of that)
- Finder Go To does not respect the current directory (it always uses `~/Library`) making relative navigation tedious
- It's an entirely separate action and UX flow for absolutely no good reason
In any other OS one can open the file manager, press Ctrl+L and start typing a path, pressing tab at any point to get contextual completion suggestions.
I'm not sure what you're using (⇧⌘G, right?) but mine does all of those things. It gives me multiple suggestions if there is more than one match, and it lets you enter a directory in your current path if you just type that folder's name.
IMO Apple has really lost its way in terms of genuinely good UX. The UI might be “pretty” but in terms of actual usability it’s gotten just frustrating at this point. The amount of complexity they require from their users now, memorizing swipe gestures, complex keyboard shortcuts, and strange incarnations is just sad. Good design is simple!
These things have been in Apple ever since the original Macintosh. In that case it was 'one mouse button, so simple'. Except to make the system usable as other systems with multiple button mice, they added a whole load of keyboard shortcuts mimiced how the multibutton mice worked, which ended up being far more complicated than just adding another button to the mouse.
I’m fairly sure they got rid of all those other buttons because for the majority of customers they created more confusion than power back then.
Also, speaking as a power user who’s also a southpaw, I’ve got more than a few choice words for many of the multibutton mice I’ve had to use over the years. Apple’s late ADB mice were lovely in the hand and completely unprejudiced.
None of that is required! In fact this article begins with people who are happily using MacOS despite not knowing all the features.
Truly simple design would not have these features at all; that’s where Mac started. The mouse had one button, period. There was no contextual click option at all. And MacOS can still be used productively that way today. Adding power features without disturbing the original usability is strictly positive IMO.
It’s incredibly easy to pick a power feature and demonstrate that some users don’t know it. The more capable a system is, the more likely this becomes. Might as well write an article demonstrating that some users don’t know how to use Terminal, so obviously Mac must have slipped in usability since the original Mac did not have a CLI.
Having visible scrollbars is not a power feature. Crippling a system because you don't want to ruin your "minimalist" aesthetic is always a bad choice.
The author is conflating discoverability of features, with discoverability of different ways to activate certain features.
So, for example, everyone knew how to view a PDF. It's just that the author disallowed the most discoverable method.
They all knew how to right click, in the most discoverable way (trackpad), it's just that the author insisted they use the magic mouse instead, or know about ctrl+click which no one ever uses. That the magic mouse is a usability disaster is a whole other issue, but that's unrelated to OS X.
I havent used OSX in a bit, but the default app thing should be something that you can do through settings (at least Windows 10 makes it very easily discoverable that way). Apple, however, has always done a terrible job with default apps (for example, requiring users to change their default Browser, Mail app, etc through Safari, Mail.app and so on).
The Do Not disturb thing is ironically an iOS UI pattern that Apple has completely unnecessarily brought to the mac.
So are the invisible scroll bars. Mac OS X's scroll bars used to be easily visible (and more functional, because it immediately gave you an idea of the size of the view as well as allowed you to click anywhere on the bar and jump there directly).
Fundamentally, OS X has well described, discoverable and recommended UI patterns that cover all these cases. iOS and iPad OS don't. It's unfortunate that Apple has decided the HIG isn't needed anymore, but that's more of an Apple thing, than an OS X capability thing.
This is disabled by default, you need to go into System Preferences to enable it.
I work in an office where everyone has an iMac and a Magic Mouse, and this is a common annoyance when coworkers ask me to come over and help them with something. I'm so used to being able to right click, and I can't on (many of) their machines.
So, one coworker in particular tried enabling right click after watching me always attempt to use it on her machine. She turned it off a few weeks later.
She couldn't get the hang of right click on the magic mouse. She would right click when she meant to left click, and be unable to right click when she did want to. Despite watching her, I wasn't able to figure out what she was doing wrong. The gesture works perfectly for me.
Of course, Apple could resolve all of this by putting two buttons on their mice...
I personally find the magic mouse to be the most frustratingly annoying Apple device ever made. I want to love it. Functionality wise, I think it's fantastic. I even agree with the charging port on the bottom in the latest iterations.
I just find the shape and form of it to be so horrible to use for any period time, that no matter how much I try to love it and use it, it just ends up giving me physical pain in my hand and I revert back to my 10 year old Microsoft mouse. I don't understand how anyone can use it for any reasonable length of time.
For me it's just the opposite – it's the one mouse that seems to fit my hand and my anatomy just right. Feels as natural to me as using a mouse can possibly be. Other mice force my hand into this typical holding-a-mouse gesture that gets crampy and exhausting pretty quickly. I don't really know what exactly makes the difference for me, but my hand posture looks completely different when using a Magic Mouse, in a way that (most?) other mice would be to irregularly shaped, thick, large for. No definite idea, but it's a great reminder of how much such things can vary between individuals.
Yeah, that's what I thought the problem was to, but it looked like she was lifting her finger. I legitimately don't understand why the gesture wasn't being recognized consistently.
Now for bonus points, install VNC, connect to a linux session, and try to get a middle-click without installing sketchy a 3rd-party macOS mouse app. Been using VNC on macOS for 8 years and still haven't solved this natively.
I have been observing something similar recently, but related to other technologies. People claiming they are good at Excel, but can't do a vlookup or a pivot table. People using 5% of the power of an IDE. People not realizing that if they are able to use a web-based tool at work, they could (probably) also access it remotely.
And these are just the things I have noticed in the past week.
We utilize just a tiny percentage of options that are available to us, barely enough to get the basics of out tasks done. But we are completely oblivious that there are probably better/hidden/power tools available in the software we are already using that could help us achieve our tasks much more efficiently.
Interestingly, most people probably don't care about it, or are so oblivious of their lack of knowledge that they don't even search for better ways to do things.
It's hard to blame thought. Improving this state requires a mentality of continuous active learning, where you don't just wait for someone to show you how to do your task better, but to constantly expand your knowledge into areas you don't even think you need to improve. However, most of us usually have "better things to do" than reading software manuals.
I think part of this was that in the past, computers and software were new and novel. People had no comparative experience, so training had to be provided to fully explain what you could do & how you could do it.
Compare to today where most people "learn" by immersion - you have to use Google Docs or Excel for your school work, so you adsorb just enough to get your work done without really understanding the fundamentals or the more complex or non-obvious features, since you weren't taught systematically or comprehensively.
Then you "know" Excel, or Word well enough to get by - but don't know that you are barely scratching the surface of it's capabilities, or don't realize that being more competent with the tool will make you more capable and productive. And thus the motivation/opportunity isn't there to invest that time and effort.
The obvious observation about Excel: spreadsheets are a highly specialized expert tool for highly specialized expert users (accountants).
Most Excel users aren’t; and most don’t even use it for its designed purpose, i.e. user-programmable parallel calculations, but rather for ad-hoc ersatz databases.
Of course, said users are rarely any better at designing and using databases than they are at bookkeeping.
It's a shame there's no standard contextual key one can hold that overlays all the keyboard shortcuts, swipes, clicks, scrolls, etc that are available in the currently displayed UI. Ideally, every window that has hidden UI stuff would have a little indicator in the corner that means "hey, there's something weird you can do here, hold down the 'explain-o-tron 3000 key' to get a hint".
While one can argue that UIs should be immediately understandable, it doesn't seem possible to pull off such a feat in many cases. Keyboard shortcuts are particularly problematic, as an always-visible list would take up too much space in most cases.
What I like about GNOME apps is that they usually have a "Keyboard Shortcuts" entry in their hamburger menu, which shows you all, or at least the most important, shortcuts you can use in the app.
On the other hand it took me a bit to first find this option because it is hidden in the aforementioned hamburger menu.
Android had this "Option" key until Google decided to blindly follow Apple.
Today, an artifact of this feature is still accessible by holding the Back button for a long time, but it is set to simply show the Overflow menu (if the App has one).
I wish so much that Android would have sticked with it. Similarly, many Windows notebooks swap the right Ctrl with a "Context Menu" key. It basically lets you right click with the mouse, but it could have had so much more potential ...
Windows used to be very systematic about putting an underscore on letters that could be used with alt accelerator key; but this seems to have been phased out.
I think the only thing I've seen with a "hold key for instructions on everything" was strategy game Rise of Nations.
It's a thing mostly for languages in which typing a single character takes more than a single keypress, such as Chinese.
Accelerators themselves work for every language, provided that the input method has a way to actually enter the Alt + character combo. So it works fine for e.g. Cyrillic, Greek etc.
I don't get why there's not continuous validation from apple for UX. Can't they just pay random users to do some tasks and continuously monitor whether they are able to do it?
Something like: how satisfied are you with x,y,z and then let them try to do task 1, task 2, task 3.
Just track these metrics and try to improve the UI according to this. It seems like the designers just live in a bubble without feedback from the users, this seems especially crucial during and after a redesign.
Maybe a small popup in apples own apps, like music. Something like: Want to use apple music for free for one month? Just answer these short questions and complete a few tasks! These things don't need to take longer than 10 minutes.
Even a small sample size could provide meaningful and statistically significant results.
The hidden scrollbar trend is maddening to me, why hide such an important element? I just tried one of the latest Ubuntu Unity/Gnome/whatever it is versions (I normally use XUbuntu) and saw that the scrollbars are hidden there too, which is crazy. How is the user supposed to know whether they can scroll?
I love using MacOS now that I'm used to it, but it really is a disaster from a basic UX point of view. Even just installing applications on MacOS is wacky, and it makes me wonder how Macs got their reputation of being easier to use than Windows computers.
Surely using the app store, or dragging an app to the applications folder is more sane than every program needing a installer program to put all the files in the right places?
> Surely [...] dragging an app to the applications folder is more sane than every program needing a installer program to put all the files in the right places?
Yes. It was more sane, when:
1. The Applications folder lived on the Dock, so users actually knew it was there.
2. Many applications (much more than today) were distributed via DMG's with instructions that an app should be dragged to the Applications folder.
Without either of these things, a lot of users end up just running an application from their Downloads folder.
Worse, doing it the right way involves on a non-trivial number of steps. You have to (1) open the Finder, (2) navigate to the Applications folder, and (3) then drag the app from Downloads into Applications.
Of all the numerous and growing usability problems with macOS, this isn't one that's ever occurred to me.
Applications is, by default, in the Favorites bar of Finder. Which is where a user would find the Download folder, granted that Applications is lower in the list, but...
Second, a significant number of programs are installed from the App Store now. Of those that aren't, it's still quite normal to open up a DMG and have two icons: the application, and a link to the Applications folder. Often with a bit of icon magic so the application points at the folder.
Some applications still use an installer, in which case the app lands in the Applications folder, again.
Is this really a problem? I've been using OSX for far too long to be in a position to tell...
Off-topic, but is it really common to confuse the difference between UX and UI? (I think "love using MacOS" implies good UX, and doesn't imply a UX "disaster": maybe I'm wrong or I'm misreading the comment?).
Professionally, I can't see how I could ever use "UX" without being confusing, either because I'm using the concept poorly or because I'd expect my audience to misunderstand my meaning.
Disclaimer: I've spent years working on UI (even developing controls, caring deeply about usability) but I've never spent much time specifically working on UX.
i've taken three university courses on user interface design and human-computer interactions. i still don't know the difference between UI and UX except in a vague sense.
You're not alone. Authors in the field aren't always consistent either, to the point where people have written academic papers trying to sort through the various definitions of what "UX" is, trying to give it some kind of clear scope, e.g. [1].
> It makes me wonder how Macs got their reputation of being easier to use than Windows computers.
Because they used to be easier. I made a post on this elsewhere in this thread.
For installing applications: Apple used to place a stack for the Applications folder in your Dock by default, and you'd use that stack to launch any applications that weren't already in your Dock. It was natural that you'd install new applications by dragging them to the same place you launched them.
Let's be fair, that's not the same thing. Apple purposefully made this behavior obtuse to stop users who don't know better from running TotallyLegitAdobeFlashUpdater.app
I think the current behavior is a fine compromise.
The party line at Apple is that right click (and everything in there) is for power users only, and that you should be able to do everything a user reasonably needs with only one button. I think this is a reasonable approach, but it seems that it's breaking peoples' ability to transition from user to power user.
The other Finder issues, however... well, it's become clear that Finder has become simpler and simpler in an attempt to make the computers more accessible.
Did you know: you can turn scrolbars on by default? A lot of common macos/finder complaints can be addressed by toggling settings, but it'd be nice if there was a single "pro mode" button, or something.
I've been using macOS for about 10 years after 20 on the nameless platform.
1. Get KeyCue or something like it that tells you (almost) every keyboard shortcut within any application by using the accessibility API.
2. Turn on that accessibility mode option where it makes it possible to cursor through multiple-choice modal dialogs.
3. What I find maddening is AppleScript. It's incredibly powerful except for three deficiencies a) an inability to introspect applications to find their nouns and verbs b) the lack of complete AppleScript documentation c) they fired the AppleScript guy. You could do a lot in it if you only knew the syntax and how to call things. AppleScript needs a minor UI overall to show what possible keywords, operators, nouns or verbs could be used during contextual code-completion.
4. macOS (and iOS/iPadOS) support most *NIX Ctrl- shortcuts within text fields. Ctrl-k to kill to EOL, Ctrl-a go to beginning, Ctrl-e go to EOL, etc.
5. Assign keyboard shortcuts to speed-up common actions (both system-wide and within particular apps) that don't have hotkeys by default, like Command-Shift-, to open Settings.
6. Get BlueToggle & AirToggle to bounce BT and WiFi.
Bonus for iPad/iOS: use the triple-click accessibility feature set to only the Magnifier (with no zooming) with the darkening filter to get a darker display at night.
Dude got sacked because he was WORSE than useless. I mean, they gave him JavaScriptCore to turn into a full user product, right at the time Node.js was gaining desktop JavaScript a million-plus users, and he ran it straight into the ground.
Never mind AppleScript; Mac Automation should’ve had MILLIONS of new Python, Ruby, ObjC, JavaScript, and Swift users by now. The problems were solved, the pieces were there—all Soghoian had to do was put them together in Mac OS X and take all the credit. (I know this: I was the one that solved it.) And App Developers would be falling over themselves to provide great scripting interfaces, because they’d all be huge Automation fans too. All that idiot did was UNsolve it again; and then—to slap insult on injury—immediately abandoned his half-baked products and hapless users to fail all by themselves.
“AppleScript needs a minor UI overall”
Oh bless. Look, AppleScript’s dead already. Any future Mac Automation has lies in [Conversational] Shortcuts… assuming Apple bother to put in the mass marketing and support resources it so urgently now needs. Though given their curret quality of management, I’m not making bets.
That’s static documentation, aka “AppleScript dictionaries”, which isn’t quite the same thing as true introspection. In combination with Script Debugger’s live object model browser it’s pretty powerful, but also all the more frustrating as you run into common limitations: missing or incompete details, ambiguous definitions, incorrect information, and so on.
Unfortunately the original designers left Apple before the whole system was adequately specced and documented or thoroughly field-trialed, leaving both app developers and users to make blind guesses as to how things should work, and duct-tape over the shortcomings as best they can.
I've been using Mac OS, Windows and Linux (multiple distros) for over 20 years.
To me Mac OS always had the worst UI experience. I can understand why people like it: it is clean and looks good. But clean and good looks doesn't make it good.
Windows has been good on average.
On Linux it depends on the distro and the version of the distro a lot.
Overall I think Ubuntu has the best UI experience at the moment.
By right-clicking the document, and seeing "Rotate clockwise" and "Rotate counterclockwise" in the context menu, along with their corresponding shortcuts?
That's actually a good example of a traditional UI that is designed around a few basic patterns (right click -> context menu, here) that enable discoverability.
As a user mostly use windows. I always find the ui discoverable of mac problematic. I really have no idea why do they like to hide most used things like move file, show hidden under keyboard shortcuts and don't have a option to force them permanently show up. As in windows, they are either already show up or exist in some obvious item like `setting` and you can toggle things here. You rarely need google to find out what's going on. But has in mac you need to press random keys here and there is no obvious visual indications that you can do so. I really curious about how mac user before google exists find them out. Or they simply not?
> I really curious about how mac user before google exists find them out.
Before Google existed, software came with manuals. You buy software in a fancy box, but within the box there's not just a CD/floppy disks, there's also a large tome of written material teaching you how to use it. You would sit down, read through it, and learn to use the software.
It is more of a testament to humanity's decreasing attention span that users now demand UIs to be discoverable without reading anything.
Here's the thing: you can't have 1000 "discoverable" actions, there's no place for it.
Correction: you do have 1000 discoverable actions, but you discover them in the menu bar.
What you found out with this article is that users are bad at knowing things, because there are too many things to know. I know all of those actions and their keyboard shortcuts, but I still have to occasionally "google it."
Either you have iOS 1.0 where everything is clear and easy to do — because there's very little to do — or macOS, where each app has dozens of features but can only surface some of them.
As I’m not much of an iPad user, I’m not sure how well I’ve understood the recent onslaught of criticism it has seen, but I thought it was more about gestures that are hard to execute even if you know them, and UI modes that you accidentally can get yourself into with no clear way to exit?
Most of these examples seem like things that are nice to be able to do if you know about them, easy to execute, but not much of a problem if you are oblivious to them?
Good test and I think the results would also apply for most people dealing with Finder. I'd like to add that the right click context menu on any file or folder is huge, I can't imagine that from the 20 entries (on my machine) more than 4 are used by 95% of all users.
So here is a poll: What are the entries you use commonly from the context menu and more interesting which of them haven't you used once?
The single click mouse is the dumbest peripheral to have ever been invented, and I'm literally using right now (at work). They say less is more but this unnecessarily forces you to use a keyboard, and at times I've had to unplug the keyboard just to find myself in bad situation needing to right click.
Pretty sure clicking on the right-side of the mouse has activated secondary click by default all the way back to the Mighty Mouse (2005), no?
Even if not, it's one checkbox to enable it. You don't need a keyboard to right-click, that's absurd.
Not this one. It does have a pseudo touchpad on top to use certain gesture commands but sacrifices the second click. Maybe the decision was to prioritize the touchpad on top, but alas bad decision although not unusable.
The magic mouse can right click without a keyboard, you click with your finger on the top right corner of the mouse. The top of the mouse is a touch surface so it knows when your finger is on the left or right side.
1. Needing to hold the option key when right-clicking in order to even see an option for moving a copied item. I don't mind the use of copy->move instead of Windows's cut->paste but why does it have to be hidden? This is surely one of the basic operations you want to perform in a file manager!
2. Needing to right click and select "open" in order to run an unsigned app for the first time. This is a counter-intuitive and pointless ritual - there should be no difference between double-clicking and selecting "open" from the context menu. If Apple wants to ban unsigned apps they should just do it, instead of hiding a workaround behind a trivial trick that the unsophisticated users Apple is ostensibly trying to protect can easily discover by accident.
As for 1, I imagine it's because Apple doesn't want the destructive actions front-and-centre. Not only that, but macOS has always encouraged/preferred the drag-and-drop pattern for file management — it might be something with which you or others agree but that's the paradigm they're backing, for better or worse.
Copying-and-moving might be a basic operation if it's something to which you're accustomed, but it's such second nature for me, and I'm sure others, to just open a new Finder window or drag to a Stack.
I agree with 2. The way they do it now is far too heavy handed; give us a prompt to choose to run the app for the first time, possibly with an administrator password prompt. I haven't really had a problem with Apple introducing restrictions with Gatekeeper but that one is simply annoying.
I've been a (generally) happy Mac user for more than 25 years, but I am still of the opinion that the command line is more discoverable. At least man -k will surface all sorts of commands whose own man pages may suggest other search keys. The mac's "Help" menu bar item is much less useful in this regard (of course it will surface menu commands and highlight them when you mouse over the response). And even then it is mostly only an interface to the menu bar options themselves -- vague questions like "how do I X", much less "click on a pixel in you image to Y" are pretty much unanswerable through this interface.
And despite what I said about man -k, let's not get into the parlous state of Apple's man files.
> and telling them that they could by hitting Cmd+up arrow ... was deemed the most hidden thing thus far.
That's one of the oldest and most uniform/predictable ones, though—Cmd+up means "navigate out"; Cmd+down means "navigate in" (which translates to "open" for documents and "launch" for apps.) It perfectly lines up with movement within the (implicit) tree that backs the spatial-navigation metaphor.
When Safari was introduced, we also gained Cmd+[ to universally mean "navigate Back" and Cmd+] to mean "navigate Forward." These tend to be recapitulated lately by left/right swipe gestures, but not all the time. You can't swipe in Preferences.app, but you can Cmd+[. (And you can Cmd+up, too!)
For anyone else who wondered what DND stood for: it's "Do Not Disturb".
Now that I know that, I see there is a subthread about it elsewhere in this HN page - but I couldn't find an expansion when searching either this HN thread or the linked article for the string "DND". Had to go and follow the instructions on a Mac, to find out what it was that lay hidden in the Notifications window.
Really? Cmd left and right are built into my muscle memory at this point. I'm pretty good with vim but not a day goes by that I don't try this by accident and end up in the next terminal over...
I have been saying for years (since OS 9) that Apple UIs are nowhere near as intuitive as their reputation would have you believe. The worst part is, because Apple does this bad stuff, everyone else thinks it must be a good idea and copies it.
Some of these are esoteric keyboard shortcuts for things that are possible to do in a less-undiscoverable way. Others, like right-clicking on the trackpad and scrolling without a visible scroll bar very quickly become second-nature when you start using a Mac, because it's impossible to navigate otherwise. Only the "Open With" case is really valid, because even the non-keyboard way of doing it (again, not mentioned in the article) is really fairly esoteric: [right-click] > "Get Info" > [select application for this file] > "Change All..." to apply to all files with this extension.
Years ago Macs used to all come with a cheatsheet of keyboard shortcuts and other hints. Before that there was a guide program with every Mac showing how to interact with the OS. Now you get nothing, nada, bubkes.
The Finder in particular has been neglected for so long. Many of these “features” are artifacts that are indicative of a long-standing need to rethink the Mac OS user’s relationship to the file system. The problem is that Apple’s instinct is to eliminate complexity, which is why iOS lacked any file system in user space until the Files app was added as a kind of begrudging concession.
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.
Probably because there's a selection drop down and a big button in the Get Info window with a label that tells you it does this exact thing
I did not know holding option in a right click menu had so many useful features!
Also, on command clicking the title bar to go a folder above: my memory is probably failing me but I seem to recall when this was announced there was an arrow or some such, or highlighting.
It works on almost any menu; not just right click context menu. XCode for example, is much more useful when you realize you learn that half of the menu options you really want are hidden by holding down the option key.
The WiFi icon has an insane amount of information if you option click it for example... (most of the system ones do)
Holding option in menus, settings, or while clicking the status bar is easily the most underused and under-documented feature of MacOS... (maybe after removing annoying shit with launchctrl).
Edit: totally didn't see the two other posts with exactly the same tip, ha. Maybe not so underused -_-;
On command clickng the window title: this feature has been around since classic Mac OS (I believe, it had been introduced in one of the many iterations of System 7) – there was definitely no indicator or hint. But the functionality was about the same as the location drop-down at top center of the file dialogs and was anchored in about the same position. It may have been one of the first hidden features, apart from the easter egg in the Finder's about box.
Holding option and clicking on a lot of things will unlock advanced entries. For instance, hold option and click your WiFi button in the top menubar to see advanced WiFi stats like channel, speed, etc... same goes for Bluetooth device menu and others.
Nice! I have used MacOS for years and had no idea that this exists. Tooltips would be perfect use for this. Hover over the Wifi icon and the tooltip tells you that option will show you more.
The common element in design trends is to minimize analogies that were previously made really obvious because users already know them by now. This has resulted in a constant iterative design that's led to the flattening and hiding of every major UI element. It's not because of malice or anything, it's just that for designers who already know and are familiar with the system, it's redundant to keep displaying things users already know.
In general, it's fine for users that are already familiar with the system. If you've been using macOS since it was Mac OS X (or even earlier), and you used every version from then to now, then the system is probably totally obvious. The catch is that we stopped "teaching" users things from scratch. So there's a ton of users who feel like the current user interfaces are totally obvious, while users who are just now entering an ecosystem find themselves completely lost.
I've advocated for this a lot privately, but I think it needs to be said more prominently: interfaces need to grow with the users on an individual level. Maybe you want to reach some kind of eden where no control is highlighted and the entire interface is flat -- so be it. Just make sure that you start users off with a very 3D interface with obvious affordances before you start changing things up. Maybe this sounds ridiculous, but it's basically the only way to teach a brand new user how to use a computer system from scratch.
I help my mom and grandparents out all the time when it comes to technology. They aren't dumb. They just don't follow every design change, take every OS update, or buy new devices every year. They know how to close windows, resize windows, and deal with windows. But when the iPad ships things like three and four finger gesture systems that have no obvious way to discover them, of course they look clueless. Similarly, when a button doesn't look like a button (but it did in three design languages ago and has just slowly removed all of the button-like features), they don't know that it's a button. Again, it's not their fault: they just haven't followed every iteration of the design language to know why or how things have changed.
The key UI element that Superhuman gets right that everyone talks about is its ridiculous obsession with teaching keyboard shortcuts. Every time you click a button instead of using a shortcut, the confirmation tells you "yes, that worked, but also here's the keyboard shortcut to do it faster next time." Maybe something like this would help?
Whatever the case may be, users who don't know things make the industry look inscrutable and unfriendly. Heck, it makes people leave platforms because they think they're unfriendly, when they've actually just been optimizing away all of the affordances.
It wasn't always like this. MacOS about circa system 7 through 9 were excellent UX-wise. OSX has been a slow, gradual degradation of UX over the past decade or so.
macOS is bad in terms of discoverability, but iOS or whatever they call it nowadays is ridiculous.
I have a brand-new iPhone I bought for testing websites, and I use a beat-up Motorola just because iOS is so frustrating to use.
Apple needs some design lessons, Microsoft has been doing such a great job with Surface devices that if they could make Windows just a tiny bit better people I bet a huge percentage will switch.
1. Scrollable windows flash their scrollbars when focused. This bit of bad UI was imported from iOS. Unlike iOS, it can still be turned off: Click the Apple menu -> System Preferences -> General -> Show scroll bars.
2. File menu -> Quick Look.
3. Every action in that context menu is available in the File menu.
3a. Holding the Option key works in the File menu as well, but this change can also be made from File menu -> Get Info -> Open with.
4. This actually bad UI was, again, taken from iOS.
5. Go menu -> Enclosing Folder.
Nearly every example is solvable with single clicks in the always-visible, literally spelled-out menubar, as they have been for 30+ years. They are therefore eminently discoverable, contingent on a user giving a thought to trying in the first place to discover them. The one or two examples where this is not true are direct iOS tack-ons that do not respect the platform.
What this post is doing is mendaciously pretending that power-user shortcuts, some more or less discoverable than others, are the only way to perform these operations which can actually be accomplished by reading and clicking. The attempt to equate the Mac's discoverability with iOS fails once that is pointed out, since in the latter those mystery-meat gestures truly are the only way to execute them.