The “it looks like you’ve blah blah” example is terrible, imo. The last thing I’d want to deal with after a hard fall is this chatter.
The correct way to do it is:
(Attention sound)
Did you just fall?
((SOS) swipe for help)
[I’m okay]
The original message doesn’t even mention it’s a swipe. I can imagine a stressed person trying to tap that message or icon without realizing it doesn’t work. Targeting at eldery you must be crystal clear, not subtle-UX-clear.
Your prompt doesn’t take into account what this feature actually does.
Asking whether you did fall is not really the right question in that situation.
For example: I did have a serious fall (that hurt a lot) with my bike that triggered this feature – but I was conscious afterwards and seemed somewhat ok. As such I didn’t want my watch to make an SOS call (dialing emergency services and contacting my emergency contacts). I wanted to give myself time to assess the situation first.
However, I did fall and the Watch correctly detected that fall. So to this yes/no question I would have to technically answer yes.
In that context the “I’m OK” button is actually pretty great. It works both if you didn’t actually fall (a false positive) and also if you did fall but it’s not serious enough to call an ambulance. (If you say I’m OK it actually asks follow up questions to determine whether it was a false positive or whether you did actually fall.)
When the watch detects a fall there is a countdown and noise and vibration and after that the watch will make an SOS call automatically. As such it‘s not so important to make it super clear and easy to make that SOS call manually. In that context it seems like a fine tradeoff to me to prevent accidentally making that SOS call.
I think it‘s exactly right for the watch to put front and center why it’s doing what it‘s doing in those situations, while also making it very clear that there can be false positives.
Strong disagree. “Did you just fall?” is more confusing: in that case, the watch is not directly telling you what it thinks happened; instead, it is asking a leading question.
It’s way less clear. You’re relying on implication to convey the fact that the watch thinks you’ve fallen, rather than just saying it.
If you’ve hit your head and are concussed, that extra level of indirection and confusion that your question introduces could have a significant effect on the outcome of the situation.
But what is it going to do if I answer yes? If I did fall but don't need medical attention, is answering "yes" going call emergency services anyway? I don't want that. But if I lie and answer "no", is it going to somehow modify its detection criteria and not work the next time I fall and really do need help? I don't know, I have no idea what it will do.
Besides, it's all a moot point because it's the wrong question to ask. It doesn't really matter if you actually fell or not. It detected what it "thinks" was likely a fall and the real question to ask is: do you need help?
If you turn the corner and see someone laying on the ground, do you ask them if they they just fell, or do you ask them if they need help?
It’s entirely unclear to me what the consequences of the yes/no choice would be.
Furthermore, falling is not binary, so there’s the question about where the boundary is. In an emergency situation, I don’t want to have to deal with any of this. It’s terrible UX.
I wrote a Fall Detector app for Android, ten years ago.
When a fall was detected the sample played: "A fall has been detected"
When the caretaker was alerted: "The caretaker has been alerted"
When the caretaker acknowledged: "The caretaker is on their way"
..
I dunno why its so hard. Talk to the user, re-assure them that the app is doing its job.
Again "fall detected" is quite un-human and mechanical. Is this a technical term? Who/what fell? Are you talking about the season? I think the existing Apple language is good and has clearly been through a lot of discussion!
Given the consensus understanding of physics and gravity, it did. It just so happened that it was attached to a larger thing that also fell, and the larger thing likely either knows it and can comprehend this message trivially, or does not and summoning help is the proper action to take.
Reminder that the screen is a false positive protection mechanism and will only ever be seen in a specific context.
> the larger thing likely either knows [about the fall] and can comprehend this message trivially, or does not and summoning help is the proper action to take.
You did say "likely" but to provide an example: skiers who know they fell cannot comprehend the message trivially (not having noticed it's existence) and summoning help is often not the proper action to take. Call centers serving ski towns are swamped with false positives due to this issue.
Sorry, but that's just a pedantic take when we're discussing what is the best UI /UX for wearers to know how to instinctively react in a possibly stressful moment.
You have to solve for the lowest common denominator, not the hacker's technically correct preference.
This ain't about the watch falling, it's about someone possibly needing to call emergency services and contacts when they're hurt. "I'm OK" is a great prompt in that context, even if it's not an explicitly accurate response to whether the watch or wearer fell (which in turn is why the focus is not on the fall but on their need for help).
Are you imagining someone who, having just fallen while wearing their Apple Watch, wondering whether they or their watch fell when their watch says, “fall detected” While they lay on the floor?
I'm imagining a scenario in which someone who, having just fallen while wearing their Apple Watch, concludes the watch is talking about itself when it says "fall detected" and they will have to have it repaired
But the watch didn't detect a fall. The watch saw signals and data points and thinks it could be a fall. Saying "Fall detected" is too confident and not a reflection of the feature.
I mostly agree with you on this one. But regarding “swipe for help”: typically I avoid UI labels that reference the action to be taken (“tap”, “swipe”, etc).
Good UI design should render the action obvious - a button should look tappable, a slider slidable and so on. That way the label can use its minimal estate to focus on describing the action instead.
“Swipe for help” might also be suitably ambiguous that some users think it means “get help” in the sense of an info page, or assistance.
I’d go with something like “(SOS) Make emergency call” or regional equivalent. Combined with a more obviously swipable UI design.
Ideally then usability test on 50 people to seen if it works!
The original iPhone UI had “slide to unlock” written on the lock screen slider, because it’s not obvious until you learn it. On the emergency/power-off screen, there’s still “slide to power off” written on the slider. Recently I tried to explain to my father remotely how to restart his iPad. However, in his local language, there is only the equivalent of “power off” written on the slider (possibly due to space constraints, as the language is more verbose than English), and so he was at a loss of what to do, since he didn’t recognize that it was a slider.
Looking at the screenshot of the SOS slider, I would have a hard time recognizing it as a slider myself, when seeing it for the first time.
> Good UI design should render the action obvious - a button should look tappable, a slider slidable and so on
That's basically what every designer says. What these people usually forget is that these intuitive Interfaces are only intuitive for people that think like them.
Nothing about that screenshot indicates that I'd have to swipe to take action. There is a very high chance I'd be unable to figure it out in a stressful situation while hurting... Unless I've already encountered the same interface in a less stressful environment.
The SOS could just be a button with the label to the right.
That swipeable element is standard in the Apple Watch UI vocabulary. It only needs to be intuitive for Apple Watch users.
It’s not a button to avoid an accidental press, because the false positive means emergency services are dispatched… and with enough false positives, the service stops being useful (wolf crying).
On a related note, I wish there was a swipeable element in the flow to prevent a Watch™ falsely entering PINs in your pocket until it locks permanently and needs to be completely reset. It can happen in minutes.
It's pretty crazy that people might be depending* on an Ultra model doing some extreme outdoors activity, and it turns itself into a little brick because it's tapping against something slightly conductive.
A button would mean I'd answer endless calls by accident, in my pocket. No, sensors don't prevent this. Yes, my leg, through my pocket fabric, can push buttons.
Did you test all of this, before deciding a button is better?
Anyway, I've never said to use a button, I said "swiping is a terrible gesture"
My parents have enormous issues swiping to answer phone calls. So they answer by accident to a lot more calls than they did when the phone had buttons, because they answer while trying to hung up. It's not clear at all that they could not do anything and the call will automatically end after a while. It's not clear at all that they could silence that phone call, without silencing all phone calls.
It's even worse than that: most of the times they call me back because they could not swipe "the right way" and were unable to answer.
But they are not stupid, they've gone through life pretty well, they worked with precision instruments in health care, where people lives were at stake, it's the interface design that is stupid!
There was a time when things were designed to be used by people leveraging human natural abilities, not forced onto people because they look cool in ADS.
> Yes, my leg, through my pocket fabric, can push buttons
on
Don't keep your phone in you front pocket then!
Anyway, I don't know how big you are, but the pockets of my jeans can't handle more than half a smartphone.
And previous generations of phone never activated on their own while in my pockets (yes, they could fit, because they were sized to be handhelds not small tablets)
But, more importantly, you're not considering more ergonomic gestures than swiping, like a long press.
You are assuming that your habits are the best possible implementation.
EDIT: there's also this: swiping can reveal physical characteristics of the user which could be considered not exactly a good thing, in this era of data harvesting and targetization.
Side note, while I don’t know the trends in Ibiza, in the USA pants marketed to men usually have pockets that can hold a smartphone (and often wallet too, though mine gets a separate pocket).
It’s not really a matter of personal size so the unsubtle body-shaming “I don’t know how big you are, but” is an irrelevant ad-hominem here, which weakens your comment. There’s no need to bring yourself so low in an internet conversation about buttons and sliders.
Thanks for the clarification but I meant big as in a big person (think about Shaquille O'Neal), not a fat person.
I'm not a native English speaker, sorry, big for me means big as per dictionary definition, not large or fat or "you should be ashamed of your body".
Anyway, a search for "jeans pockets smartphone" produces the following results, which is exactly what I meant, pants here have the same pocket size you can see in the following pictures.
No offense at the 'big' thing here, I'm 190cm. But amusingly, I have grey hair, which means I am, by the laws of the universe, no longer allowed to wear jeans.
I think looser pants are why ginormous phones fit, although I am sure upthread's comment about many pants being tailored differently now, is probably true too.
My own usage case is, as with anyone, unique. The real problem is, singular thought in design.
Look at chrome, and how google removed pinch zoom and reflow, to "force" websites to update for mobile.
Thanks google, clearly you could care less about older eyes. About older websites.
> No offense at the 'big' thing here, I'm 190cm. But amusingly, I have grey hair, which means I am, by the laws of the universe, no longer allowed to wear jeans.
ehehe I have grey hair and grey beard too.
I still wear jeans when nobody watches, but in all honesty when I wear classic suit pants to go to the office, the pockets are even smaller than the jeans ones, so my phone stays in the pocket of my (suit) jacket.
My issue with swiping is that when phones fitted entirely in one hand, for example the Samsung Galaxy SII or the iPhone 4, swiping made sense, everything was close enough and you never lost grip.
Now that they are so big, there's a lot of lateral movement to cover and it's becoming to be nonsensical. I usually drop my phone 2/3 times a day because of needing to swipe, it never happened so often before.
I have also started to suffer from joint pain on my right thumb due to phone gestures.
I've watched my parents trying to do it with both hands - with one hand they keep the phone, with the other hand they try to swipe-up to answer using their index finger - and the movement 90% of the time falls too short and the swipe fails.
It's painful to watch, I think we should rethink gestures or phones' dimensions.
Actually, the emergency services are called automatically after a timer countdown. Purpose of the dialog is to check if you are okay and NOT call the emergency services. The slider skips the countdown and calls immediately.
All my fingers work fine on a touch screen. If your thumb was injured and you needed emergency assistance, would you really give up instead of trying to use your index finger? Really? You would just lay there and die because you can't or won't use your index finger instead of your thumb to call for help? Really?!?
I hope this isn't true and you've merely lost track of the context of this discussion.
Cars are already removing them because they are a distraction and don't work!
Mazda to remove touch screens from all new cars - June 2021
Top Stellantis Designer Wants to Remove All Touch Screens - June 2022
Shocker! Test Shows Physical Buttons Are Less Time-Consuming in Cars Than Touchscreens - Aug 2022
Are Car Touch Screens Getting Out of Control? - Feb 2023
You know ironically what the real reasoning behind it also is?
Touch screens are cheap, why should I buy a luxury car to watch a black piece of glass in my car when it's turned off? It doesn't feel luxury, it feels identical to the cheap car of everybody else, it looks identical to induction burners. And why is the manufacturer saving on costs if the car costed me a premium price, because it's nominally a top brand?
Would you buy a Prada bag made of cheap plastic in China?
So you're going to give up and die because you have a broken finger. Got it. If I believed you I'd call you pathetic, but I know you're almost certainly bullshitting because you lost the context of the conversation, made a stupid argument, and are now trying to save face by doubling down.
Nobody rolls over and dies because of a broken finger. People regularly walk around with broken limbs after accidents, oblivious to their injuries because adrenaline has that effect to keep people alive. But you're here arguing that a broken thumb will render you unable or unwilling to call for help? As if you don't have two hands. As if you don't have 9 other fingers. As if you couldn't use your broken thumb to lightly touch a touchscreen if your life depended on it. Give me a break dude! If you die because of a broken thumb, your will to live must be completely nonexistent and you should go talk to a therapist because there is a real risk that you might starve to death after neglecting to eat out of apathy.
> wall of text of other irrelevant bullshit
What even was your point in posting that? I don't like touchscreens in cars either but that has nothing to do with this conversation and you know it. Stop bullshitting.
>Nothing about that screenshot indicates that I'd have to swipe to take action.
Users are not interacting with a screenshot. If you try to tap the slider it will slide a little to the right and fall back to indicate it’s a slider. There are also other actions on the watch that use this kind of interaction. And if you fail to either call ems or confirm you’re OK, it will call them for you.
Yes, they are. You seem want a distressed user to aimlessly wonder though the UI trying to learn how every object behaves. That's not only unreasonable, on this case it's mean.
That's why Jobs-era iPhone always visually AND verbally instructed "[→] slide to unlock", where nowadays it's just a ───── at the bottom that are supposed to be extremely discoverable and immediately obvious and magnificently intuitive.
> What these people usually forget is that these intuitive Interfaces are only intuitive for people that think like them.
Which is why a successful interface designer understands who will be using the interface. There's nothing natural about any touch interface. It's all learned. When designers say "a button should look tappable", that's a design requirement, not a design solution. What solution achieves that requirement will depend on the audience the interface is intended for.
When the user is wearing the device (dedicated Android phone), a 'chain' of protection is rendered (3D) which indicates the state of the Fall Detection algorithm. When the algorithm detects a fall, the chain is broken.
During the fall, the app indicates whats happening with audio prompts - caretaker alerted, acknolwedged, etc. - and then in order for the app to be changed from "Alert all caretaker" state back to 'ring of safety' mode, the user has to swipe the alert icon. The purpose for this is to ensure that in the case of fall, the app persists until the caretaker acks the app, physically.
This proved to be quite workable and fit with multiple users - the 3D "chains" were easy for the frail user to see, while wearing the device - then in case of falls, audio and vibration was used to let the user know help is on its way - and then, to acknowledge, the alert caretaker gets a separate UI that makes accidental de-activation (during an actual fall) impossible.
I'm guessing that a great deal of this warning is false positive. Thus, using "Did you fall?" when a false positive occurs doesn't provide enough context for the alert.
Remember that the Apple Watch is just guessing. Hence, using "It looks like" is more appropriate. Otherwise, a tech illiterate senior might not understand why the Apple is suddenly asking if he/she fell so directly when there is a false positive.
"I think you fell". --> The Watch is an "I" now? Creepy.
"Fall detected" --> which is not technically correct. The watch didn't detect a fall. The watch is only seeing signals that suggest you might have fallen.
"Sudden motion - Injury suspected". --> There are probably many data points fed into an algorithm that detects falling so saying one of those factors, "sudden motion" is not accurate. "Injury suspected" is vague. Who did the Watch suspected had an injury? And not every fall results in an injury. The watch shouldn't be suspecting an injury unless it uses its sensors to detect an injury.
I still think Apple's version is the best out of any of the alternatives suggested here. I guess that's why most people here are developers - not HCI/UX people.
No first person language please. My iDevice shouldn't be saying "I think..." about anything. This is both a personal preference and, I suspect, better "design"/language.
A yes or no question doesn’t make much sense when there isn’t a way to respond to that question. And even if there was, perhaps to help train Apple’s detection algorithm, that really shouldn’t be the main call to action. The point of the feature isn’t to impress you with how accurately it detected falls. It’s to get you help if you need it.
I agree that the “It looks like you’ve…” informal-chatty style is terrible. It’s hilarious that they describe it as “straightforward and direct”. It should rather be something short and matter-of-fact like “Hard fall detected.”
The tone of "Hard fall detected" is good if you're developing a product where precision and accuracy matters most such as in the military or in some high stake business situations. But the Apple Watch is a consumer product.
Also, the watch did not detect a hard fall. It merely saw signals that suggests it could be a fall.
So "It looks like you've" is more accurate and friendly to consumers..
The images don't load for me for whatever reason, but the alt text is set up nicely, which is great to see!
Image: /design/human-interface-guidelines/foundations/writing/images/fall-detection-message.png
Alt: A screenshot of a Fall Detection message that reads: it looks like you've taken a hard fall.
Image: /design/human-interface-guidelines/foundations/writing/images/move-streak-message.png
Alt: A screenshot of an Activity message that reads: you set a personal record for your longest daily Move streak, 35 days!
Image: /design/human-interface-guidelines/foundations/writing/images/handwashing-settings.png
Alt: A screenshot showing the Handwashing Timer description, which reads: Apple Watch can detect when you're washing your hands and start a 20-second timer.
These are pretty useful for not just when using a screen reader or maybe a text based browser or something, but also when the images themselves break.
Well the logo might not be a great example, as it is often clickable to the home page and should have alt text so people know what it is.
A better example is when a site has little stock photo thumbnails with article titles on a navigational page. The screen reader can read the title text; knowing what’s in the thumbnail adds nothing.
Images should only have alt text when they contain “real” content (for example if it is an original photo that is relevant to the associated story).
Huh, this is a good tip. I've always provided a rich description of decorative images, because I didn't want screen readers to "miss out," but apparently that was a bad idea!
Is the fall detection alt-text actually that good here? There were more elements in that image, which I assume people who use screen readers or are reading the alt-text for broken images would want to know.
The "EMERGENCY SOS" slider and "I'm OK" button give more examples of the "straightforward and direct" language that the article text references. I also learned something about that feature itself (besides that it existed in the first place) - Apple's design choices to make the "SOS" a slider, followed by a larger/easier to press button for "I'm OK". Even though it wasn't related to the point of the article, it was information that I wouldn't have learned had I just read that alt-text.
Is this part of accessibility guidelines for alt-text? Shouldn't they convey the same information, whether it's in image or text form, even if it's not directly relevant to the point of an article?
I can also imagine that people have different preferences - maybe some want all the information like I mentioned, whereas others don't want to distract from the point of what they're reading. I wonder which way the alt-text guidelines lean in practice.
> Interjections like “oops!” or “uh-oh” are typically unnecessary and can sound insincere.
This is a good observation.
I'd also avoid stuff like "Maybe Later" buttons, instead of allowing the user to just say "No".
I believe the idea is to gently inform the user that they can perform the action later but it comes across as a passive aggressive way of removing control.
i.e. the user wants to say no, full stop, but the app/website is telling them that they'll just nag them again until they accept regardless.
> > Interjections like “oops!” or “uh-oh” are typically unnecessary and can sound insincere.
>
> This is a good observation.
I agree. That reminds me:
> Imagine a doctor performing a procedure and then suddenly saying “Oops! Something went wrong…” That is the last thing anyone wants to hear when the stakes are high, whether it’s surgery or someone’s source of income. That is not the time to be cutesy or fluffy.
> —https://wix-ux.com/when-life-gives-you-lemons-write-better-e...
Not sure this point applies to software, but I find a doctor saying oops to be very comforting. If I know when he screws up I don't have to be suspicious of him the rest of the time.
True story from my rotation on General Surgery during my third year of medical school (UCLA; 1973):
I'm in the O.R. doing what 3rd year med students do, namely holding a retractor to help keep the operative site open and perfectly exposed.
The attending, a very senior surgeon, vice-chair of the department, tells the senior resident, "When you accidentally nick a big blood vessel, instead of saying 'Oops," say "There!'"
My father is a retired surgeon, and has told me he was trained the same way — to say “there” rather than “oops”. The rest of the OR staff know what you mean, and it doesn’t spook a patient or other people who might overhear.
“Maybe later” or “Not now” can be useful to indicate that this isn’t a permanent decision. The situation where it’s bad is when it’s the only option next to an “Always allow” option (or similar), which is just a dark pattern to prevent the user from permanently disabling something.
When there is a choice between applying a decision once vs. permanently, then that should rather be made using a separate “remember my decision” checkbox or a “No, and don’t ask me again” option (or similar).
> “Maybe later” or “Not now” can be useful to indicate that this isn’t a permanent decision.
Useful for who? When was the last time you hit "Maybe Later" and meant it? To a consumer, that message just means "this annoying popup will be back later".
I have a beef with these and not really any place to complain, so here it is: I hate apps that provide this functionality but have no way for you to reach into the app and undo it. Sometimes I want to be reminded of something and I accidentally check this thing (or click "No, and stop reminding me") and either the app doesn't provide a way for you to undo the permanence of your choice or it's hidden somewhere that I have no possible way to find.
My favorite example of this: by default, the Windows remote desktop client will present an "are you sure" dialog when closing a connection… If just once you check the "don't remind me" box, there is literally no way of undoing that preference except for manual registry hacking. If only Microsoft were so respectful of their users preferences in all other cases!
I've no problem with "yes / maybe later". To me, "maybe later" implies "no" is also a possibility. I don't read passive/aggressiveness into it, and I don't need a separate "no" option which would add nothing.
Why do I like seeing the "maybe later" option? Because the app's devs are telling me "this is possible to configure later; we thought about this flow, and you won't be locked out of this option if you skip it now".
If they don't show this wording, maybe they thought about it, maybe not. Maybe I'll be forced to reinstall the app from scratch. Who knows!
So very true. Atlassian were the worst at this; their laggy software would error out, filling you with rage, and you'd be faced with a dialog titled something utterly insincere like "Whoops!".
The user must be and feel in control at all times. Taking away agency in most cases is unwarranted. Exceptions may be with children or special needs groups.
While I agree with this as a general rule, it ignores an entire class of problem. I work in a data preservation space - if we let people delete things every time they wanted to, it'd be a disaster. Instead we 'tombstone' it (hide from everyone but admin), then let someone with some space from the process confirm it actually should be deleted. We've averted dozens of disasters this way.
I'd argue the user must feel in control, as you say, but not necessarily _be_ in control.
Same here. We implemented a “soft delete” in a system I worked on recently, as actually deleting something could have legal implications. We just have a table column where we mark it as deleted and then exclude those from any retrieval queries. If we ever need to undelete, someone can manually update the database.
Well, it ties in with another rule I have, don’t allow for stupidity. If a user can do some stupid things, it’s not designed well. (Say your deletion problem)
But yes, as long as these decisions are made consciously by a team, it’s get the attention it deserves.
I don’t know—this kind of deception is how the industry attracts more regulation. Delete needs to go back to meaning delete, and the user should be in actual control.
No. I frequently undelete or unsend. Others do too. Removing the Windows Recycle Bin or its equivalent would not make my life better by "giving me agency".
Apple’s Human Interface Guidelines are a wonderful set of documents. Apple doesn’t always live up to them and sometimes egregiously violates them, but I take a Stephensonian view of this hypocrisy (“That we occasionally violate our own stated moral code … does not imply that we are insincere in espousing that code. … No one ever said that it was easy to hew to a strict code of conduct”). I prefer that the document exists and they fail to live up to it, rather than the document be changed to reflect how they do operate.
I remember when I got my first Mac (right around the time Snow Leopard got released) and all the programs looked and felt so consistent. Not just those made by apple, but also third party applications downloaded from some random corner of the internet.
What really blew me away (and still does) is that apple somehow got people to care about their Human Interface Guidelines. At the time this was an entirely foreign concept to me. All the windows applications I used had very inconsistent behaviour, even though all the ui elements came from the same native toolkit.
There wasn't even an App Store or a centralised repository to enforce this, and yet people thought it important to adhere to those guidelines.
I think this is the reason why even today iOS apps feel like they have a slight advantage in quality.
All of this comes with significant disadvantages, but there are upsides that are seemingly impossible to achieve otherwise.
Exactly, the Mac/iOS UX is coherent on a level that nothing else even comes close to. It’s a great example of doing many small things correctly, and the experience overall coming together as a result.
Going back to using Windows or Android afterwards is painful. (Windows especially now that they insult their users with advertisements within their operating system by default, something Apple would never do in a million years).
The settings app on iOS is full with prompts to subscribe to iCloud and appletv (even showing you a red alert, which makes it looks like there is something wrong with your phone).
They only go away if you subscribe. I still get the prompt for 1 year free appletv, although I already used that. When I click on it gets stuck on an infinite loading screen.
Oh, and apple care prompts on new phones until your device is not eligible for that anymore.
a) Apple TV is not necessarily a service I use. Neither is Apple News.
b) Why does the ads being first-party suddenly make it more acceptable? Ads are ads, and I don't want them on my device, even if they are ads for my computer manufacturer's services.
Windows/Microsoft in $lang != en_US is also degrading constantly for some years to add salt to the wound. These days I see more and more of what are essentially adversarial examples that "compile" into English through machine translations.
> advertisements within their operating system by default, something Apple would never do in a million years
That's outright not true. MacOS (by default) gives you pop-ups asking you to try the new Safari, and when you put on your headphones it launches Apple Music with a pop-up asking you to try their subscription. The settings app begs you to sign in and pay for iCloud storage. The default dock is loaded with useless SaaS that would be better-off uninstalled. I still have the friggin U2 promo!
That's just MacOS. The water started to rise on iOS years ago, and it all contributed to me leaving Apple's ecosystem for good. This "premium" experience is meaningless if you just use it as premium ad space for your premium products. I'm going to pass on being a premium customer.
And this existed long before Mac OS X, too - it goes pretty much all the way back to the inception of the Mac. Even back with MacOS 6 vs Windows 95 when I was a child, I could easily see the difference.
I generally agree, though with a huge exception for iTunes back in the day. The baffling changes from version to version were frustrating and the UI seemed to hide obvious functionality, causing me to constantly ask “why can’t I <do X>?”. IMO Apple really struggled with iTunes’ identity for the past 22 years as it split off into other independent apps.
They've alway been included in the pages describing how to prepare your app for submission, I always thought they were almost part of the review process, but they're mostly just good advice and worth following, and won't hurt your submission
>That we occasionally violate our own stated moral code … does not imply that we are insincere in espousing that code. … No one ever said that it was easy to hew to a strict code of conduct
Interesting point. I think the statement miss an important additional point: it’s hard to come upfront with a rule set that is reality proof. More than the rules, what matter is why the rules was first uttered. To my mind, provided you agree with the underlying spirit, it’s better to break the exact rule and keep its purpose guidance in mind than strictly and blindly apply the literal interpretation of the rule and sap its genius.
Microsoft's UI guidelines were good too in the Windows 95-98 era before they went downhill. Their problem was that they didn't follow them in their own major applications like Office.
Here's a favorite UX error message of mine from chase.com
>"Your session is about to end. You've been inactive for a while. For your security, we'll automatically sign you out in approximately 1 minute. You may choose "Stay signed in" to continue or sign out if you're done."
No stress put on the user with a timer (e.g. "You will be logged out in 3...2...1"). Instead, they simply state the facts in a calm way. "For your security" tells me why they're logging me out. Perfect voice for a bank. I want that level of simplicity in all my financial apps.
I would personally go with a much shorter "Are you still there? If you're not, we'll log you out to protect your account." The buttons speak for themselves and the more words you add to a message, the less of it people will read.
Hell, if one button says "stay signed in" and the other says "log out", I don't even know if I'd go with a message that long. Just "are you still there" may be enough, with a redirect to the "why did I get logged out" page if you let the timer lapse.
On the other hand, I want error messages to be as descriptive as possible, with a short summary for normal users perhaps. Operational messages may be short and sweet, but if I need to solve a problem, I've had it with the "oopsie whoopsie we made a mistakey wakey" messages apps produce these days.
I don't like being asked something if the question/answer does clearly communicate what the consequences are.
Either the broad question is patronizing, suggesting the program makes decisions over my head without even informing me what about, or it is superfluous since the explanation+action is all I want or need.
I really do not enjoy programs behaving like they have intelligence by being vague or leading, but really never are, since their logic only covers the common case.
text below: You’ve been inactive for a while. For your security, we’ll automatically sign you out in approximately 1 minute.
action button: Stay signed in
action button: Sign out
Maybe the text could be reworded a bit. “Automatically” is redundant, everyone knows websites are automatic. “About” can do the work of “approximately”. I like how friendly they are when telling you the time limit but it may not be necessary to give a time at all. So you end up with: “For your security, we sign out sessions that have been inactive for a while.”
It seems inferrable, at least in broad strokes, from the other, non-technical meanings of the word. See for example "the court is now in session" or "I had a physical therapy session this morning".
Isn't it used the same way in English? When you go to a therapist, you have a therapy session. When some musicians get together, they may have a jam session.
The technical meaning is very similar to the non-technical one.
I agree it's similar, though there's one difference: on many websites a session can have an arbitrary duration. If you log in to Google or Amazon once you can stay logged in on that device for months.
Using that snippet as an example, I wonder if I'm in the minority in that I would rather have more generic and impersonal explanations whenever possible, avoiding you·s and we·s. I find it somewhat grating to have what I know are software environments taking automated decisions and describing abstract concepts trying to pretend this is a personal relationship or interaction. This is not a terrible annoyance for me, just a very minor pet peeve, but I would much prefer the app/website to say for instance:
> This session is about to end due to inactivity. For security reasons it will be automatically signed out in approximately 1 minute. You may choose "Stay signed in" to continue or sign out if you're done.
Note that I don't mind the you in the last sentence, as it is truly referring to the personal me.
Yes, that also annoys me! Especially when it's not even my phone but for example a third party service that is asking me to do something in their interest and not mine. Every time I click on one of those "No, thank you" buttons I mumble to myself a correction of "No, fuck you".
I think it was originally used because A/B testing said there's a 1% increased "Yes" conversion rate when having to thank the company while declining, and then everyone started to copy Bigtech as always.
YMMY it seems overly wordy for me, and makes the bank seem amateurish and that they don't respect their users' time. Which would dissuade me from a banking app
I could see that POV. If it helps, they use effective visual formatting. The first sentence is an enlarged heading, and the rest of the text is smaller underneath.
This thread is full of great discussion. Writing clearly can clearly be hard. It takes practice and skill.
This is why technology programs in schools require (or should require) technical writing courses. It might not seem important to know how to write for humans when you’re learning to write for machines, but writing for humans is one of the most important things you can learn, in any discipline.
As an engineer, I hate writing. That being said, one of the best classes I took during my undergraduate studies was a class called “Technical Communication.” We learned how to write a good email, memo, and even technical instructions.
For one of our big projects, we were given a box of Dots (gummy candy) and a box of toothpicks. We had to create a structure and then write instructions for another group of students to recreate said structure.
Many students did poorly because they would simply write out their instructions like “put a toothpick in the side of the dot.” What does that even mean? They never established top or bottom, so side could be anything.
And yet so often UX Writing is distained as an unecessary job that can be handled by designers or PMs instead of recognising the verbs and nouns of your product are its fundamental architecture to users. And that's before you get to voice & tone.
Hmm, I think this just might be a situation of our own making. When we assign a title to a person, we draw imaginariy mental lines and we hold an implicit bias that says only they are capable of doing that thing, rather than, it's their primary goal to be doing that thing. Similarly, others outside that title will hold a prejudice thinking, what is the big deal with what they are doing, what's taking so long, couldn't someone else do it?
The question can easily be shifted to ask, why only devs doing development, couldn't PMs and designers do it too? Well, yes they can. At least parts of it. HTML, CSS, definitely, maybe some basic JS too. Could devs do PM work, I think so, at least little bits!
For the same reason a writer is not and cannot be expected to become a designer within just one week. In the case of shoddy visuals, it's just much more obvious to even laymen if something's off.
Totally. So often, the message that comes out on a "this should never happen" branch of the code is a random invention of a junior coder, and never reviewed by anyone.
Many of Apple’s own apps are egregiously bad at reporting errors — as in, they don’t report them at all.
When Airdrop doesn’t work, it just gets stuck. No timeout, no nothing. I guess that’s very clean from a UX writing perspective because you don’t even need an error message. But it’s extremely frustrating to the user.
The iOS Family features suffer a similar lack of feedback. I toggle an app limit for my child and sometimes it just secretly doesn’t register on the server. I navigate back and forth to see the UI action hasn’t taken effect.
(Often I wonder if anybody at Apple actually has kids because Family works incredibly poorly. 30-second delays are common. Notifications don’t come through. User flows go through confusing incorrect states. Etc. Feels like it’s maintained on leftover MobileMe infra by junior developers who have no idea why anyone would even use this product.)
>When Airdrop doesn’t work, it just gets stuck. No timeout, no nothing.
Even when Airdrop works, it doesn't work. One "feature" of Airdrop is that if you try to airdrop something from your iPhone to your iPad, for example, but you had already airdropped it earlier, it won't give you ANY indication. It will make a nice ping sound, and just do nothing. This is so infuriating.
Apple's policy has been to show error messages when the user can do something with the information. And in most cases trying again is the only thing they can do so it tends to be minimal.
Also I suspect many of those issues you're seeing involve asynchronous behaviour which is a hard UX challenge to solve. You could send a push notification that an update has failed on the server but often the user has moved onto something else.
Even returning the most bog-standard message like "Try again (Error #12345)" would be immensely more helpful than having the UI simply do nothing, unclear on whether it's still working or not.
Sure, async UI is hard, but the world's richest corporation with a reputation for UX excellence could afford to try at least.
And why does Support and Marketing push back on that idea? Because they don't like when a customer reaches Support and says "I got error #12345! What should I do?" They'd much rather the customer just shut up and go away
however, the programmer who put 12345 in the code would dearly love to know that it was hit.
When you have an error message you don't understand, at least you can google for it.
If something simply doesn't work, there could be many possible underlying causes, and finding a list of possible errors and going through all of them is much more frustrating.
An infinite loading animation and similar things are very ambiguous. Is my wifi connection bad right now? Is the OS acting up because I haven't rebooted the device in two months? Is a server down/unreachable? This wide range of possibilities is very frustrating because it often means you have a long, unsuccessful troubleshooting session ahead.
AirDrop is a particularly egregious outlier. It’s clear that something has gone very, very wrong with that feature. Not only with how unreliable it is, which is already bad enough, but with how clearly broken that basic state machine driving the UI is. Once it has gotten into a bad state, from my experience there’s no way to get it to succeed without restarting one or both iPhones.
Apple Music too is awful with error messages. There's one time I wanted to add a song to my library, I clicked the button and nothing happened. Which is the exact behaviour you get when it succeeds. Except it didn't work and my song wasn't added to my library. I tried a few more times and it just didn't work for this particular song. Thinking I maybe "lost" dozens of songs because they weren't added to my library is one of the reasons I went back to Spotify
I bet Apple Subscriptions is a popular product and makes them tons of money. Yet their admin UX is just as poor, I got instantly tiggered by your description.
Including arbitrary error codes in error messages is a good idea because it creates virtual gathering points for users searching for answers.
From a comment I’ve made about errors in the past:
“You should probably include the error code in the message (ERR0231), because that helps make the error message unique to this specific error situation and thus makes it functional as a “gathering point”. If you Google the error message and find others talking about the same error you experienced, that’s useful; if you Google the error message and find others talking about different errors on the same site, that is useless at best and could be harmful. (Concrete example: a multiplayer gaming platform reports a checksum of game files to a remote server to ensure all players are using the same version of the game. Scenario 1: The files are corrupt, the checksum is wrong, the error message is “Unable to validate game files”, the fix is to reinstall the game. Scenario 2: The user’s internet connection is temporarily degraded, the game is unable to get a response from the remote server, the error message is “Unable to validate game files”, the fix is to wait until connection improves. The unfortunate user from Scenario 2 is going to google their error message and get told to try the fix from Scenario 1. Now they’re re-downloading the game on their spotty connection.)“
Error codes are far better than lack of error codes. I was once involved in a large project to add unique, Googleable codes to all errors that could happen with $POPULAR_API, and support tickets dropped considerably after they were added.
At least if there's an error code, I can search for that specific error code and see if anybody else has run into it. Seeing "Error 3bad617a" means that somebody else may have copy-pasted that same error message, and it might show up in search for "$PROGRAM_NAME 3bad617a". This is best if every location that can give an error has a unique code, but can be useful even if it is just parroting some low-level code.
In other cases, an error code may be a standard value, and indicate that something is wrong with the inputs I provided as a user. If I see "Error saving file: 13", I may guess that the "13" was returned by some system call and is the error code EACCES or "Permission denied". I could test this by saving the file in another directory. The specific error code is useful for knowing what to do next, as error code 28 would be ENOSPC or "No space left on device", and I'd instead check if I ran out of disk space. (It would have been better if the error number had been passed through strerror() before display, but having the numeric code is still better than nothing.)
For messages you don't expect mere mortals to solve, error codes may be useful as a filter. Some Windows Update errors can't be fixed without a reboot (or a debugger and the Windows source code) so 0xdead1337 is a fine code. You can Google it if you want to try anyway.
Sometimes, errors happen because a whole chain of behaviour failed. The program is in a bad, irrecoverable state or contains a bug. The user can't fix it and the programmer that made the method may not even know the state can be impossible (i.e. code has been refactored).
Sometimes, error codes are more about helping the developers pinpoint a bug than they're about helping the user.
That said, things like "database corrupt" or "no connection to API server" should just be displayed rather than muffled away.
In my opinion, these impossible error codes should be accompanied with a support phone number or email address.
Numeric error codes are useful for troubleshooting, e.g. you can google “<program> error <code>”, or its developer can find where or around what exactly it’s localized.
The “something happened” part usually comes from a generic error handler that reports surprising errors. E.g. your current graphics card driver messes with directx internals in a way that the game couldn’t foresee this sort of exception in that code path. So here you go, “unknown error 0x8000abcd”. Google it -> update your driver.
Sometimes they're unavoidable, when you simply have no idea, or can't think of all the things that could go wrong, it's better to give an error code than a generic, something went wrong, message.
I've had worse though, when a UX design specified a specific error message and a developer blindly followed it and simply remapped errors to the given message, ignoring what the actual error was, misleading the users and the developers.
I've told UX to never include error messages again..
Error messages are one of the items on my mental code review checklist that gets very often excersized, since going from terrible to OK is usually pretty easy, but it's often a very different mindset from the actual programming task that introduced that error pathway.
So usually it's up to the reviewer to notice and guide the author to that improvement.
Yes! I've always found Microsoft's "welcome" messages in Windows installation to be extremely condescending and obnoxious (something they have an history of, even if unintentionally, going back to Clippy and beyond)
On the other hand, Apple is guilty of sparse and vague error messages, or not giving any messages at all and letting things fail silently (like when AirDrop or Personal Hotspot magically just not work)
Airdrop fails randomly at least 50% of the time I use it. And this experience is pretty consistent across over a decade of use with macbooks, mac minis, iphones (right up to the current 14) and tablets for an entire family.
It's just garbage 50% of the time, and you end up trying random things...
"restart your bluetooth"
"ok that didn't work, now I'll restart mine."
"ok still not working, lets both restart our bluetooth at the same time while chanting Jobs Jobs Jobs"
I don't see it, it's sparse yes, but condescending and obnoxious is an excessive description. It might be that you're going in to Windows installation with a preset prejudice.
"Hello"
"Step back while we take care of things for you"
"Just a few minutes longer"
I don't know the script verbatim, but it always read as very creepy and "This isn't your computer, it's Microsoft's." I would Ctrl-Alt-Delete just to have the pleasure of not seeing those messages.
A tiny UX tidbit I like, is the "close dialog" buttons in some products, consider the following 2 buttons:
[ Dismiss ]
"Dismiss" is self-deprecating and is an implicit admission that the warning is annoying, which makes the user less engaged.
[ Got it ]
"Got it" or similar phrasing subconsciously encourages the user that they understand the message and can continue. Even if they don't care about the message at all, at least the message doesn't consider itself "Dismissable" and unimportant... it's a subtle UX change, but makes dialogs are bit more tolerable...
“Got it” buttons fill me with rage in a way I can’t really articulate well. It’s probably due to the mental association at this point, but they always come up in ridiculous first-run tutorials that block me from using their product until I read and acknowledge some inane UI feature like “you can drag your finger to swipe!” or something equally obvious.
A “got it!” button (especially with the stupid fucking exclamation point) makes the software feel like the overly enthusiastic waiter from the restaurant in Office Space who is just nauseatingly upbeat. Fuck off and get me my coffee.
I’d love an OS-wide extension that would take replace the text on every “Got It!” button with “Fuck Off”. I know it would accomplish nothing but it would make me feel so much better using my phone.
> which makes the user less engaged
I don’t want to be “engaged” using your software. I want to accomplish my task and move on with my life. Why must every single aspect of software try to be my buddy nowadays? Why do I need to be “engaged” with it?
The UX that I like best is the one that provides the opt-out at the point where it would be an annoyance. Whenever there's a pop-up, I want an option to say "Don't show me notices of this kind again.". This requires a measure of humility on the part of developers, to acknowledge that learning about the feature they just added may not be the top priority of all users at all times, and an alternative way to learn about the UI.
Start-up tips that have options of "Close this tip", "Never show tips again", and "Next tip" are the best example, because they account both for users who want to learn more about the program and users who already know how to use the program.
> I don’t want to be “engaged” using your software. I want to accomplish my task and move on with my life. Why must every single aspect of software try to be my buddy nowadays? Why do I need to be “engaged” with it?
Engaging software is successful software. Engagement is also just a metric of 'user attention' I guess, which is a bit insidious...
I find the familiarity that modern software assumes unnerving. Everything has a time and place, I wouldn’t want a Got It button while filling out an official form.
> subconsciously encourages the user that they understand the message
One of the problems with these friendlier messaging is, they are friendlier because they are more often only relevant to en_US(2023) linguistic, visual and societal context, and they are often in fact out of context by the time they are dissected into language resources, passed to (human or machine) translators, and executed on user terminals.
[Dismiss] is blunt, cold, harsh, "disrespectful", unnegotiable, but it virtually has no invalid translation candidates. [Got it], [Go ahead], [Fine], those can be anything.
I would like to take a moment to appreciate also the localization of the words. I deal with technical English my whole life, so I have no problem understanding computer terminology, but using Mac UI in my native language is quite beautiful experience. (Compared to Windows, Android or Linux.) I can't really wait when Siri will speak every language. (ChatGPT is pretty great at this, so my hope is that Apple will take notice.)
It's a nice set of guidelines but does Apple have credibility in this area? Specifically, does Apple actually follow what they preach (looking at you 'Write clear error messages')?
Or more generally, are Apple's apps as good or better than what is out in the industry?
Something I’ve always found interesting is wording in 1st person vs 2nd person. For example a link to “your orders” vs “my orders”. They’re both legit, but feel totally different. And I guess there’s a third, neutral option: just “orders”. The article mentions this very briefly, but this difference has a pretty profound effect on how the relation between the site and myself feels, that it doesn’t go into. I wonder how deliberate this decision (1st or 2nd person) is on most sites.
It seems to me that most apps choose the "my orders" approach, but I prefer to use an app that uses the "your orders" approach. It feels more professional to me and less like I'm being conned into something.
Apple makes great hardware, good OSs, horrible apps, indecent websites. Also, they use a very preechy way of advising, which for me means they think they are right, instead of looking at the market to tell us what works or not.
So you spend a lot of time and effort choosing terminology and phrasing these messages, then you need to translate it to N languages, and you are mostly out of luck. I tried to translate back one (of several thousand) of carefully phrased messages from a third party translation into English, and it was nowhere close. Was this a problem with google translate? Is it some limitation in the language? Who knows.
In the end I realized that the product has a consistent and well thought out language only for the languages the development team speaks, and that will never be very many.
I guess the takeaways is this: If you can, an application in the language it was developed in, even if there is a translation to a language you master better. Because after a certain limit the importance is how well the developers master the language, not you.
No, I am not google translating. I was just doing that as a "reverse test" to see what the translators had actually written. We are using translators who are proficient in the domain and speak 2 languages at least (English plus the target language). But they are still "external" to the team. They have some domain knowledge, but they don't have the true conceptual knowledge about what things are called in the program. Translators inside the development team (for the couple of languages covered by the developers) don't make the mistake of picking an incorrect synonym. The external translators might, despite good domain knowledge. The problem with it is: We don't notice. Because we don't speak the language!
E.g. if you make an architectural program, you might call things "floor", "level", or "storey". In an editor you might have "object", "entity" and so on) and all of these might exist and mean different things in the program. Language wise they may well be synonymous, but in the "domain language" of the program they might be very different.
As a frustrated non-English user of recent widespread degradation in software translations, I can verify that you're completely correct in your observations. Recent advents of "I give you lists of short gibberish to make guesses on but I don't listen for excuses because they're short" platforms like Crowdin are starting to put toils on i18n users, just as you have been finding out from the other side.
Basically it has to be bunch of screenshots or has to be tweet-long sentences, and it always had been, until someone ignorant in power started forcing that naivety.
Google translate is garbage level quality and can not be relied upon for any task. You should use DeepL for translation and you will be fine. Contract professionals to double check.
Google Translate is unreliable for that use. You'll need another professional translator to check that with certainty. DeepL is much better than Google translate, and also free.
I know. So it's just a creeping suspicion. But the "need a different translator" still doesn't help. Because of the same reason the first one didn't help. Unless the person knows the semantics of the program, and not just the domain and the languages involved, we can't be sure they are making the right translation. It doesn't matter how many translators you throw at it (or how many tools). The closest thing would be to simply sit down with translators+developers and go through it. But that's also prohibitively expensive for specialist software (I.e. software where the number of languages times the number of translated texts is easily 100x the total number of users).
> It’s always best to help people avoid errors. When an error message is necessary, it should appear as close to the problem as possible, avoid blame, and be clear about what someone can do to fix it.
Try designing with the idea in mind that the user will never see an error. First, instead of coming at it from the point of view "the user made an error", start from "the program was not useable enough". Much like a door with handle that cannot be pulled, but must be pushed, a program with a UI that appears to allow an action but really doesn't, the issue is not the person's fault. Respond to failures to complete the action the user attempted with alternates. Imagine how frustrating it would be if you went to buy coffee and the person working there simply said, "no, you've made an error" when you tried to order something they're out of. You'd right avoid doing business there ever again.
More generally, the UI is just as important as the algorithm behind it. We see social networks doing all sorts of UI shenanigans to trick users into doing their bidding. It's not enough to allow customisation of our algorithmic feeds, we need to have a level of control over the UI as well.
I'd rather read overly technical language that assumes intelligence or curiosity on the part of the reader, rather than comforting euphemisms. When I was a kid I thought SimCity1993 really was "reticulating splines" during the loading screen and it didn't scare me off. Now Windows (which ought to be a lot less cheeky than Maxis) will print something like "We (who?) are just (just?) finishing some things (things?!) up for you"
I've long thought that it would be really great to have log/internals viewing be a first class citizen of an OS.
Windows has a variety of tools that let you see debug message and trace events but they're not really useful for casual perusal. I don't know what the ecosystem looks like on Linux.
I suppose I'm not sure what I'm asking for. But in the aforementioned example (Window's post update/install OOBE with "We are just finishing some things for you") it would be nice to press something like Shift+F11 and open up a log viewer that knows you're interested in the main thing on screen to see what it's actually doing.
Linux is quite nice actually, getting a broad overview of "what the system is doing" is as easy as opening a text file or running a command. If you have a single app misbehaving, you can often run it from a terminal to see extra debugging information. (This trick usually works on Mac OS as well)
Windows has no such equivalent; event viewer is incredibly clunky
Of course not, but I see that fact as an indicator of the collateral damage in the continued "War on General Computing" more than anything else. The customer is not always right - what they may want is to be infantilized, but what they need is to be educated.
I've been witness to this "War on General Computing", being a 31 year old human who's used computers for the better part of 28-29 years of that time.
I'm not convinced the shift you're describing as far as UX writing is anywhere near as concerning as the actual war on general computing with respect to running the OS you want, the software you want, with restrictions as necessary for security but not for vendor lock-in.
UX writing tone, of course, is only a tiny piece of the overall foreclosure of customization that the current era of UX designers is complicit in. I see a continuum between cutesy UX writing and reduced ability to customize any and all settings by the end user; You think there is an "actual war" separate from the propaganda used to manufacture consent for it. Gilded cages need gilt - that gold leaf takes the form of emojis etc.
maybe they should try to improve user experience with their own applications before telling others what to do?
Finder on MacOS: probably should be renamed to Hider. Just a horrible file explorer interface. I couldn’t imagine something worst. I ended up training my family on how to use the Terminal and mdfind command instead.
Apple Photos and the shared album interface is such a pain to work with as a user. I hope it’s not just me!
I’m skeptical UI matters and I sometimes think if you get traction with extremely poor UI (as is often the case) it implies you’re solving something people need and people are willing to circumvent your bad design yet still find value you’re probably onto a winner.
Sure, be kind to your users once you have some traction but I think nice UX or even words isn’t hugely important.
I'd ignore advice from Apple or Big Tech about how to use words. They are not language experts. They are not content experts.
They are infected with the same over-sensitive "inclusivity" reaction that has spread far and wide like a virus. Apple has adopted the widely criticised Stanford harmful words list.
At bottom of this article are link to another page which has the following advice:
"Avoid 'Peanut gallery' and 'grandfathered'". Because they arose from oppressive contexts.
People are not "grandfathers" at their core. Nobody becomes a grandfather because they had an accident and woke up with the unwanted new identity. Grandfathers won't protest in the street about the term used in tech circles. Grandfather is a name describing their relative position in a family tree.
"master", "slave", "sanity check", "kill"... Apple says no to all the usual copy and paste words from the list. The viral nature of these lists spreading around is of concern.
"Fall through the cracks", "on the same page", and "backseat driver"... Apple says no.
Without your '/s' I'd be lost in the rough seas of your intended meaning.
Feeling the need to copy a list of words is not the same as feeling the need to be inclusive.
Besides, using those words and phrases isn't offensive to anyone other than a small minority of... "language activists" for want of a better description. The same people modifying books down to story elements like what jobs the characters have.
"Check the history of words" is not a UX concern, and shouldn't be in style guides alongside "avoid 'click here'".
Nice, valuable resource here for anyone in any position in a business. Apple is one of the best with user experience so having a laid out guidelines like this is a public service. Thanks for sharing
I'm curious if anyone here has links to a pdf/printable version of these docs by Apple? Or even if anyone knows anyone compiling an archive of diff. versions?
I’ve always thought of users as guests, and your website/app acts as the concierge for various services. They speak clearly, consistently, are helpful, and act according to the situation at hand.
Shameless plug: if you want to empower your team to iterate your UX text in web apps (React, Angular, Vue, etc) FlyCode lets non-technical teammates make changes to UX texts and send a PR to GitHub with the text changes: https://www.flycode.com/developers
If we're fully committing to the new and improved culture, then logically we need to ditch the word "write".
The root word of write, is a proto-indo-european word that means 'to cut, mark'. Writing grew out of making permanent cuts on stone and permanent marks on paper. The culture of the writing era exemplified cut earthwork and decorative marks.
We don't do that verb anymore, we type. We push buttons and symbolize words in binary streams. Our culture celebrates games, software and movies that are pushed out into the world and symbolize something.
We can't keep overloading the meaning of the word 'write' and expect people to understand what's going on.
The “it looks like you’ve blah blah” example is terrible, imo. The last thing I’d want to deal with after a hard fall is this chatter.
The correct way to do it is:
The original message doesn’t even mention it’s a swipe. I can imagine a stressed person trying to tap that message or icon without realizing it doesn’t work. Targeting at eldery you must be crystal clear, not subtle-UX-clear.Your prompt doesn’t take into account what this feature actually does.
Asking whether you did fall is not really the right question in that situation.
For example: I did have a serious fall (that hurt a lot) with my bike that triggered this feature – but I was conscious afterwards and seemed somewhat ok. As such I didn’t want my watch to make an SOS call (dialing emergency services and contacting my emergency contacts). I wanted to give myself time to assess the situation first.
However, I did fall and the Watch correctly detected that fall. So to this yes/no question I would have to technically answer yes.
In that context the “I’m OK” button is actually pretty great. It works both if you didn’t actually fall (a false positive) and also if you did fall but it’s not serious enough to call an ambulance. (If you say I’m OK it actually asks follow up questions to determine whether it was a false positive or whether you did actually fall.)
When the watch detects a fall there is a countdown and noise and vibration and after that the watch will make an SOS call automatically. As such it‘s not so important to make it super clear and easy to make that SOS call manually. In that context it seems like a fine tradeoff to me to prevent accidentally making that SOS call.
I think it‘s exactly right for the watch to put front and center why it’s doing what it‘s doing in those situations, while also making it very clear that there can be false positives.
Strong disagree. “Did you just fall?” is more confusing: in that case, the watch is not directly telling you what it thinks happened; instead, it is asking a leading question.
It’s way less clear. You’re relying on implication to convey the fact that the watch thinks you’ve fallen, rather than just saying it.
If you’ve hit your head and are concussed, that extra level of indirection and confusion that your question introduces could have a significant effect on the outcome of the situation.
I don't understand your point of view. There is no indirection. It's just a simple question, yes or no, did you just fall?
But what is it going to do if I answer yes? If I did fall but don't need medical attention, is answering "yes" going call emergency services anyway? I don't want that. But if I lie and answer "no", is it going to somehow modify its detection criteria and not work the next time I fall and really do need help? I don't know, I have no idea what it will do.
Besides, it's all a moot point because it's the wrong question to ask. It doesn't really matter if you actually fell or not. It detected what it "thinks" was likely a fall and the real question to ask is: do you need help?
If you turn the corner and see someone laying on the ground, do you ask them if they they just fell, or do you ask them if they need help?
It’s entirely unclear to me what the consequences of the yes/no choice would be.
Furthermore, falling is not binary, so there’s the question about where the boundary is. In an emergency situation, I don’t want to have to deal with any of this. It’s terrible UX.
So maybe a message like
"Call emergency services?"
"Yes" "No"
Although it removes the context of the watch' reasoning.
I wrote a Fall Detector app for Android, ten years ago.
When a fall was detected the sample played: "A fall has been detected" When the caretaker was alerted: "The caretaker has been alerted" When the caretaker acknowledged: "The caretaker is on their way" ..
I dunno why its so hard. Talk to the user, re-assure them that the app is doing its job.
"Fall detected. Call {911 || regionally appropriate number/name}?"
Again "fall detected" is quite un-human and mechanical. Is this a technical term? Who/what fell? Are you talking about the season? I think the existing Apple language is good and has clearly been through a lot of discussion!
As befits a nonhuman, mechanical device like a watch.
Which makes it sound like the watch fell, not me
Given the consensus understanding of physics and gravity, it did. It just so happened that it was attached to a larger thing that also fell, and the larger thing likely either knows it and can comprehend this message trivially, or does not and summoning help is the proper action to take.
Reminder that the screen is a false positive protection mechanism and will only ever be seen in a specific context.
> the larger thing likely either knows [about the fall] and can comprehend this message trivially, or does not and summoning help is the proper action to take.
You did say "likely" but to provide an example: skiers who know they fell cannot comprehend the message trivially (not having noticed it's existence) and summoning help is often not the proper action to take. Call centers serving ski towns are swamped with false positives due to this issue.
Sorry, but that's just a pedantic take when we're discussing what is the best UI /UX for wearers to know how to instinctively react in a possibly stressful moment.
You have to solve for the lowest common denominator, not the hacker's technically correct preference.
This ain't about the watch falling, it's about someone possibly needing to call emergency services and contacts when they're hurt. "I'm OK" is a great prompt in that context, even if it's not an explicitly accurate response to whether the watch or wearer fell (which in turn is why the focus is not on the fall but on their need for help).
There also must be some joke about special relativity hidden in that wearer-and-their-watch-falling incident.
Are you imagining someone who, having just fallen while wearing their Apple Watch, wondering whether they or their watch fell when their watch says, “fall detected” While they lay on the floor?
I'm imagining a scenario in which someone who, having just fallen while wearing their Apple Watch, concludes the watch is talking about itself when it says "fall detected" and they will have to have it repaired
"Fall detected. Call 911?"
“Why is my watching asking me to call 911 to get it repaired? My hip is broken!”
I can’t tell if you’re trolling me or not but I’ll assume you’re not.
If you’re laying on the floor I think you’ll know who fell.
If you didn’t fall, then you know it’s wrong.
But the watch didn't detect a fall. The watch saw signals and data points and thinks it could be a fall. Saying "Fall detected" is too confident and not a reflection of the feature.
You’re right. Better explain all that to the user of the watch who is laying on the floor.
If they are not laying in the floor then they already know it’s wrong.
"Fall detected. Call 911?"
“Huh? No, I didn’t fall. Don’t call 911”
Or
“I did fall, but I’m fine. Don’t call 911”
Maybe you can explain to the user of the watch who didn't fall but the Watch suddenly says "Fall detected".
Apple's version is better. It's more accurate of what the feature does (guessing based on factors), and it's more human.
Exactly.
I mostly agree with you on this one. But regarding “swipe for help”: typically I avoid UI labels that reference the action to be taken (“tap”, “swipe”, etc).
Good UI design should render the action obvious - a button should look tappable, a slider slidable and so on. That way the label can use its minimal estate to focus on describing the action instead.
“Swipe for help” might also be suitably ambiguous that some users think it means “get help” in the sense of an info page, or assistance.
I’d go with something like “(SOS) Make emergency call” or regional equivalent. Combined with a more obviously swipable UI design.
Ideally then usability test on 50 people to seen if it works!
The original iPhone UI had “slide to unlock” written on the lock screen slider, because it’s not obvious until you learn it. On the emergency/power-off screen, there’s still “slide to power off” written on the slider. Recently I tried to explain to my father remotely how to restart his iPad. However, in his local language, there is only the equivalent of “power off” written on the slider (possibly due to space constraints, as the language is more verbose than English), and so he was at a loss of what to do, since he didn’t recognize that it was a slider.
Looking at the screenshot of the SOS slider, I would have a hard time recognizing it as a slider myself, when seeing it for the first time.
> Good UI design should render the action obvious - a button should look tappable, a slider slidable and so on
That's basically what every designer says. What these people usually forget is that these intuitive Interfaces are only intuitive for people that think like them.
Nothing about that screenshot indicates that I'd have to swipe to take action. There is a very high chance I'd be unable to figure it out in a stressful situation while hurting... Unless I've already encountered the same interface in a less stressful environment.
The SOS could just be a button with the label to the right.
That swipeable element is standard in the Apple Watch UI vocabulary. It only needs to be intuitive for Apple Watch users.
It’s not a button to avoid an accidental press, because the false positive means emergency services are dispatched… and with enough false positives, the service stops being useful (wolf crying).
On a related note, I wish there was a swipeable element in the flow to prevent a Watch™ falsely entering PINs in your pocket until it locks permanently and needs to be completely reset. It can happen in minutes.
It's pretty crazy that people might be depending* on an Ultra model doing some extreme outdoors activity, and it turns itself into a little brick because it's tapping against something slightly conductive.
*—Don't do this with any tech.
> It’s not a button to avoid an accidental press
so if I actually fell and broke my thumb, I won't be able to easily activate it.
Swiping is a terrible gesture, nothing related to "emergency" should be linked to swiping.
It's much better to put there a "DID NOT FALL" button than a swipable element to avoid false positives.
False positives are still better than false negatives, in these circumstances.
I suspect you don’t actually own an apple watch, because you’re really reaching here. First of all, SOS is dispatched after a period of inactivity.
Otherwise, you can use your remaining four fingers to swipe. Or your nose. Or Siri. Or remove the watch with your teeth and use the other hand.
But more obviously, broken thumbs still swipe too.
not contesting the Apple watch, but the claim that swiping should be used to avoid false positives.
Swiping should be used for low priority confirmations, like confirming you want to buy a subscription or pay for some in-game addon.
In my opinion it shouldn't be used to answer phone calls either.
Please never design any interface I have to use.
A button would mean I'd answer endless calls by accident, in my pocket. No, sensors don't prevent this. Yes, my leg, through my pocket fabric, can push buttons.
Did you test all of this, before deciding a button is better?
> A button would mean I'd answer endless calls by accident
That's honestly not a design issue.
The design of the following device was never criticized because answering a phone call was "too easy"
https://en.wikipedia.org/wiki/Nokia_3310
Anyway, I've never said to use a button, I said "swiping is a terrible gesture"
My parents have enormous issues swiping to answer phone calls. So they answer by accident to a lot more calls than they did when the phone had buttons, because they answer while trying to hung up. It's not clear at all that they could not do anything and the call will automatically end after a while. It's not clear at all that they could silence that phone call, without silencing all phone calls.
It's even worse than that: most of the times they call me back because they could not swipe "the right way" and were unable to answer.
But they are not stupid, they've gone through life pretty well, they worked with precision instruments in health care, where people lives were at stake, it's the interface design that is stupid!
There was a time when things were designed to be used by people leveraging human natural abilities, not forced onto people because they look cool in ADS.
> Yes, my leg, through my pocket fabric, can push buttons on
Don't keep your phone in you front pocket then!
Anyway, I don't know how big you are, but the pockets of my jeans can't handle more than half a smartphone.
And previous generations of phone never activated on their own while in my pockets (yes, they could fit, because they were sized to be handhelds not small tablets)
But, more importantly, you're not considering more ergonomic gestures than swiping, like a long press.
You are assuming that your habits are the best possible implementation.
EDIT: there's also this: swiping can reveal physical characteristics of the user which could be considered not exactly a good thing, in this era of data harvesting and targetization.
https://www.sciencedirect.com/science/article/pii/S107158191...
Side note, while I don’t know the trends in Ibiza, in the USA pants marketed to men usually have pockets that can hold a smartphone (and often wallet too, though mine gets a separate pocket).
It’s not really a matter of personal size so the unsubtle body-shaming “I don’t know how big you are, but” is an irrelevant ad-hominem here, which weakens your comment. There’s no need to bring yourself so low in an internet conversation about buttons and sliders.
Thanks for the clarification but I meant big as in a big person (think about Shaquille O'Neal), not a fat person.
I'm not a native English speaker, sorry, big for me means big as per dictionary definition, not large or fat or "you should be ashamed of your body".
Anyway, a search for "jeans pockets smartphone" produces the following results, which is exactly what I meant, pants here have the same pocket size you can see in the following pictures.
https://previews.123rf.com/images/bacho12345/bacho123451508/...
https://previews.123rf.com/images/wisawa222/wisawa2221707/wi...
https://previews.123rf.com/images/aquapictures/aquapictures1...
https://images2.minutemediacdn.com/image/upload/c_fill,w_144...
No offense at the 'big' thing here, I'm 190cm. But amusingly, I have grey hair, which means I am, by the laws of the universe, no longer allowed to wear jeans.
I think looser pants are why ginormous phones fit, although I am sure upthread's comment about many pants being tailored differently now, is probably true too.
My own usage case is, as with anyone, unique. The real problem is, singular thought in design.
Look at chrome, and how google removed pinch zoom and reflow, to "force" websites to update for mobile.
Thanks google, clearly you could care less about older eyes. About older websites.
> No offense at the 'big' thing here, I'm 190cm. But amusingly, I have grey hair, which means I am, by the laws of the universe, no longer allowed to wear jeans.
ehehe I have grey hair and grey beard too.
I still wear jeans when nobody watches, but in all honesty when I wear classic suit pants to go to the office, the pockets are even smaller than the jeans ones, so my phone stays in the pocket of my (suit) jacket.
My issue with swiping is that when phones fitted entirely in one hand, for example the Samsung Galaxy SII or the iPhone 4, swiping made sense, everything was close enough and you never lost grip.
Now that they are so big, there's a lot of lateral movement to cover and it's becoming to be nonsensical. I usually drop my phone 2/3 times a day because of needing to swipe, it never happened so often before. I have also started to suffer from joint pain on my right thumb due to phone gestures.
I've watched my parents trying to do it with both hands - with one hand they keep the phone, with the other hand they try to swipe-up to answer using their index finger - and the movement 90% of the time falls too short and the swipe fails.
It's painful to watch, I think we should rethink gestures or phones' dimensions.
Well, the swipe width thing is a different conversation. I bet it is far worse for children, which makes me think...
For kids, a kid sized phone would seemingly work better. 1/3 the size, weight, and theoretically with a smaller font and display.
> I have grey hair, which means I am, by the laws of the universe, no longer allowed to wear jeans
Stop mentally enslaving yourself.
Taking a joke too seriously is a form of mental self-enslavement.
Actually, the emergency services are called automatically after a timer countdown. Purpose of the dialog is to check if you are okay and NOT call the emergency services. The slider skips the countdown and calls immediately.
> so if I actually fell and broke my thumb,
Thankfully most people have four backup fingers on the same hand..
yeah but it's called opposable thumb for a reason.
try to do what you do every day without using a thumb and tell me how good it is to have 4 "backup" fingers.
All my fingers work fine on a touch screen. If your thumb was injured and you needed emergency assistance, would you really give up instead of trying to use your index finger? Really? You would just lay there and die because you can't or won't use your index finger instead of your thumb to call for help? Really?!?
I hope this isn't true and you've merely lost track of the context of this discussion.
> hope this isn't true and you've merely lost track of the context of this discussion
On a smartphone it's hard to keep track of a long thread if I have a broken thumb.
> All my fingers work fine on a touch screen
Good.
Now watch these images and tell me how these people are holding the devices in their hands (hint: watch their thumbs).
Unfortunately for you, you're still a primate with opposable thumbs.
https://static.vecteezy.com/system/resources/previews/002/88...
https://t4.ftcdn.net/jpg/03/31/88/03/360_F_331880337_DmRJT2I...
https://c8.alamy.com/comp/FXTP62/holding-generic-smart-phone...
> If your thumb was injured and you needed emergency assistance, would you really give up instead of trying to use your index finger?
it's obvious you never saw an emergency situation or never lived one.
You still think it's a matter of will.
People give up and die, of course, that's the problem!
Meanwhile a better gesture would be long press the screen with the palm if you need help.
Bad ergonomics is bad, regardless of how much people love feeling cool with their touch screens, it won't last.
In 10 years people playing with pocket sized touch screens will look like this photo.
http://i2.cdn.turner.com/cnn/2010/TECH/mobile/07/09/cooper.c...
Cars are already removing them because they are a distraction and don't work!
Mazda to remove touch screens from all new cars - June 2021
Top Stellantis Designer Wants to Remove All Touch Screens - June 2022
Shocker! Test Shows Physical Buttons Are Less Time-Consuming in Cars Than Touchscreens - Aug 2022
Are Car Touch Screens Getting Out of Control? - Feb 2023
You know ironically what the real reasoning behind it also is?
Touch screens are cheap, why should I buy a luxury car to watch a black piece of glass in my car when it's turned off? It doesn't feel luxury, it feels identical to the cheap car of everybody else, it looks identical to induction burners. And why is the manufacturer saving on costs if the car costed me a premium price, because it's nominally a top brand?
Would you buy a Prada bag made of cheap plastic in China?
So you're going to give up and die because you have a broken finger. Got it. If I believed you I'd call you pathetic, but I know you're almost certainly bullshitting because you lost the context of the conversation, made a stupid argument, and are now trying to save face by doubling down.
Nobody rolls over and dies because of a broken finger. People regularly walk around with broken limbs after accidents, oblivious to their injuries because adrenaline has that effect to keep people alive. But you're here arguing that a broken thumb will render you unable or unwilling to call for help? As if you don't have two hands. As if you don't have 9 other fingers. As if you couldn't use your broken thumb to lightly touch a touchscreen if your life depended on it. Give me a break dude! If you die because of a broken thumb, your will to live must be completely nonexistent and you should go talk to a therapist because there is a real risk that you might starve to death after neglecting to eat out of apathy.
> wall of text of other irrelevant bullshit
What even was your point in posting that? I don't like touchscreens in cars either but that has nothing to do with this conversation and you know it. Stop bullshitting.
>Nothing about that screenshot indicates that I'd have to swipe to take action.
Users are not interacting with a screenshot. If you try to tap the slider it will slide a little to the right and fall back to indicate it’s a slider. There are also other actions on the watch that use this kind of interaction. And if you fail to either call ems or confirm you’re OK, it will call them for you.
> Users are not interacting with a screenshot.
Yes, they are. You seem want a distressed user to aimlessly wonder though the UI trying to learn how every object behaves. That's not only unreasonable, on this case it's mean.
You would be correct if it was a game.
Only if you assume a fall would be the first encounter with this UI element on an Apple device, that is extremely unlikely.
Though a return to a little bit of depth in interface design would help. Even plain tappable buttons often have zero affordance these days.
> You seem want ...
I agree with you more than the GP, but this isn't a good way to structure a rebuttal.
> If you try to tap the slider it will slide a little to the right and fall back to indicate it’s a slider.
People can’t interpret that kind of nonverbal/abstract cues. It’s quite an inner circle thing of nerds that those seem ultra obvious.
Apple's whole thing is "computers for non nerds".
Nerds would type SOS at a command prompt.
That's why Jobs-era iPhone always visually AND verbally instructed "[→] slide to unlock", where nowadays it's just a ───── at the bottom that are supposed to be extremely discoverable and immediately obvious and magnificently intuitive.
> What these people usually forget is that these intuitive Interfaces are only intuitive for people that think like them.
Which is why a successful interface designer understands who will be using the interface. There's nothing natural about any touch interface. It's all learned. When designers say "a button should look tappable", that's a design requirement, not a design solution. What solution achieves that requirement will depend on the audience the interface is intended for.
I wrote a Fall Detector app once.
When the user is wearing the device (dedicated Android phone), a 'chain' of protection is rendered (3D) which indicates the state of the Fall Detection algorithm. When the algorithm detects a fall, the chain is broken.
During the fall, the app indicates whats happening with audio prompts - caretaker alerted, acknolwedged, etc. - and then in order for the app to be changed from "Alert all caretaker" state back to 'ring of safety' mode, the user has to swipe the alert icon. The purpose for this is to ensure that in the case of fall, the app persists until the caretaker acks the app, physically.
This proved to be quite workable and fit with multiple users - the 3D "chains" were easy for the frail user to see, while wearing the device - then in case of falls, audio and vibration was used to let the user know help is on its way - and then, to acknowledge, the alert caretaker gets a separate UI that makes accidental de-activation (during an actual fall) impossible.
Ideally then usability test on 50 people to seen if it works!
Might want to run it by the ethics board, though, before subjecting 50 people to traumatic events.
To be fair to the parent the label was:
> ((SOS) swipe for help)
I'm guessing that a great deal of this warning is false positive. Thus, using "Did you fall?" when a false positive occurs doesn't provide enough context for the alert.
Remember that the Apple Watch is just guessing. Hence, using "It looks like" is more appropriate. Otherwise, a tech illiterate senior might not understand why the Apple is suddenly asking if he/she fell so directly when there is a false positive.
I like Apple's version more.
"I think you fell".
"Fall detected"
"Sudden motion - Injury suspected".
"I think you fell". --> The Watch is an "I" now? Creepy.
"Fall detected" --> which is not technically correct. The watch didn't detect a fall. The watch is only seeing signals that suggest you might have fallen.
"Sudden motion - Injury suspected". --> There are probably many data points fed into an algorithm that detects falling so saying one of those factors, "sudden motion" is not accurate. "Injury suspected" is vague. Who did the Watch suspected had an injury? And not every fall results in an injury. The watch shouldn't be suspecting an injury unless it uses its sensors to detect an injury.
I still think Apple's version is the best out of any of the alternatives suggested here. I guess that's why most people here are developers - not HCI/UX people.
No first person language please. My iDevice shouldn't be saying "I think..." about anything. This is both a personal preference and, I suspect, better "design"/language.
Don’t anthropomorphize computers. They hate that.
> The original message doesn’t even mention it’s a swipe.
The actual message includes a countdown which automatically makes an SOS call if you do nothing.
Don’t worry, this setting is so sensitive that you’ve likely seen the screen a few tens of times before you are actually in a hard fall.
A yes or no question doesn’t make much sense when there isn’t a way to respond to that question. And even if there was, perhaps to help train Apple’s detection algorithm, that really shouldn’t be the main call to action. The point of the feature isn’t to impress you with how accurately it detected falls. It’s to get you help if you need it.
I agree that the “It looks like you’ve…” informal-chatty style is terrible. It’s hilarious that they describe it as “straightforward and direct”. It should rather be something short and matter-of-fact like “Hard fall detected.”
The tone of "Hard fall detected" is good if you're developing a product where precision and accuracy matters most such as in the military or in some high stake business situations. But the Apple Watch is a consumer product.
Also, the watch did not detect a hard fall. It merely saw signals that suggests it could be a fall.
So "It looks like you've" is more accurate and friendly to consumers..
I only got as far as the distracting needlessly too-small corner margins. Is everything on Apple Watch that ugly?
On Swiping, though, it's kind of a lost cause on iOS/WatchOS. If you don't know to do the goofy swipes everywhere, your experience is miserable.
It isn't static. It jiggles a bit to show it's moving.
Asking a yes or no after you hit your head may get confusing and dismiss a quick call
The images don't load for me for whatever reason, but the alt text is set up nicely, which is great to see!
These are pretty useful for not just when using a screen reader or maybe a text based browser or something, but also when the images themselves break.Just as important of a side note for supporting text-based browsers and screen readers: if the images are purely decorative, you should make it alt="". https://www.w3.org/WAI/tutorials/images/decorative/
Don't do: <h1><img src alt="ACME logo">ACME</h1>.
Well the logo might not be a great example, as it is often clickable to the home page and should have alt text so people know what it is.
A better example is when a site has little stock photo thumbnails with article titles on a navigational page. The screen reader can read the title text; knowing what’s in the thumbnail adds nothing.
Images should only have alt text when they contain “real” content (for example if it is an original photo that is relevant to the associated story).
A logo is a perfect example because so many sites are failing to do it correctly. When you do
What gets rendered and read is what you would never want If you don't have or use actual text nearby then you just do this:Got it, thanks for following up
Huh, this is a good tip. I've always provided a rich description of decorative images, because I didn't want screen readers to "miss out," but apparently that was a bad idea!
Is the fall detection alt-text actually that good here? There were more elements in that image, which I assume people who use screen readers or are reading the alt-text for broken images would want to know.
The "EMERGENCY SOS" slider and "I'm OK" button give more examples of the "straightforward and direct" language that the article text references. I also learned something about that feature itself (besides that it existed in the first place) - Apple's design choices to make the "SOS" a slider, followed by a larger/easier to press button for "I'm OK". Even though it wasn't related to the point of the article, it was information that I wouldn't have learned had I just read that alt-text.
Is this part of accessibility guidelines for alt-text? Shouldn't they convey the same information, whether it's in image or text form, even if it's not directly relevant to the point of an article?
I can also imagine that people have different preferences - maybe some want all the information like I mentioned, whereas others don't want to distract from the point of what they're reading. I wonder which way the alt-text guidelines lean in practice.
Same. Getting 403 Forbidden.
I'm getting a 404, at least for one of the images [0].
[0] https://developer.apple.com/design/human-interface-guideline...
> Interjections like “oops!” or “uh-oh” are typically unnecessary and can sound insincere.
This is a good observation.
I'd also avoid stuff like "Maybe Later" buttons, instead of allowing the user to just say "No".
I believe the idea is to gently inform the user that they can perform the action later but it comes across as a passive aggressive way of removing control.
i.e. the user wants to say no, full stop, but the app/website is telling them that they'll just nag them again until they accept regardless.
> > Interjections like “oops!” or “uh-oh” are typically unnecessary and can sound insincere. > > This is a good observation.
I agree. That reminds me: > Imagine a doctor performing a procedure and then suddenly saying “Oops! Something went wrong…” That is the last thing anyone wants to hear when the stakes are high, whether it’s surgery or someone’s source of income. That is not the time to be cutesy or fluffy. > —https://wix-ux.com/when-life-gives-you-lemons-write-better-e...
Not sure this point applies to software, but I find a doctor saying oops to be very comforting. If I know when he screws up I don't have to be suspicious of him the rest of the time.
True story from my rotation on General Surgery during my third year of medical school (UCLA; 1973):
I'm in the O.R. doing what 3rd year med students do, namely holding a retractor to help keep the operative site open and perfectly exposed.
The attending, a very senior surgeon, vice-chair of the department, tells the senior resident, "When you accidentally nick a big blood vessel, instead of saying 'Oops," say "There!'"
My father is a retired surgeon, and has told me he was trained the same way — to say “there” rather than “oops”. The rest of the OR staff know what you mean, and it doesn’t spook a patient or other people who might overhear.
“Maybe later” or “Not now” can be useful to indicate that this isn’t a permanent decision. The situation where it’s bad is when it’s the only option next to an “Always allow” option (or similar), which is just a dark pattern to prevent the user from permanently disabling something.
When there is a choice between applying a decision once vs. permanently, then that should rather be made using a separate “remember my decision” checkbox or a “No, and don’t ask me again” option (or similar).
> “Maybe later” or “Not now” can be useful to indicate that this isn’t a permanent decision.
Useful for who? When was the last time you hit "Maybe Later" and meant it? To a consumer, that message just means "this annoying popup will be back later".
On system upgrade dialogs. I want to stay up to date and I won't remember to do it but usually I don't want to do it right now.
In fact, I use this style of "snooze" quite often as a user.
> separate “remember my decision” checkbox
I have a beef with these and not really any place to complain, so here it is: I hate apps that provide this functionality but have no way for you to reach into the app and undo it. Sometimes I want to be reminded of something and I accidentally check this thing (or click "No, and stop reminding me") and either the app doesn't provide a way for you to undo the permanence of your choice or it's hidden somewhere that I have no possible way to find.
My favorite example of this: by default, the Windows remote desktop client will present an "are you sure" dialog when closing a connection… If just once you check the "don't remind me" box, there is literally no way of undoing that preference except for manual registry hacking. If only Microsoft were so respectful of their users preferences in all other cases!
https://superuser.com/questions/1617750/how-to-restore-remot...
There should definitely a way to undo it. Traditionally there is at least a “reset all my decisions” button in the settings.
I actually like "maybe later". As soon as it's provided with "no" together (which IME usually is the case), I have no issue with it.
Indeed. But often I do see just the two options "Yes" / "Maybe later" and this is infuriating.
That's it in one. The cutesy "be kind" language does not hide the reality of the "heads I win, tails you loose" choice from the user.
I've no problem with "yes / maybe later". To me, "maybe later" implies "no" is also a possibility. I don't read passive/aggressiveness into it, and I don't need a separate "no" option which would add nothing.
Why do I like seeing the "maybe later" option? Because the app's devs are telling me "this is possible to configure later; we thought about this flow, and you won't be locked out of this option if you skip it now".
If they don't show this wording, maybe they thought about it, maybe not. Maybe I'll be forced to reinstall the app from scratch. Who knows!
So very true. Atlassian were the worst at this; their laggy software would error out, filling you with rage, and you'd be faced with a dialog titled something utterly insincere like "Whoops!".
I hate the "Maybe Later"/"Not Now" buttons. I take them as a signal that the software/website/whatever that does that is scammy and to be avoided.
The user must be and feel in control at all times. Taking away agency in most cases is unwarranted. Exceptions may be with children or special needs groups.
While I agree with this as a general rule, it ignores an entire class of problem. I work in a data preservation space - if we let people delete things every time they wanted to, it'd be a disaster. Instead we 'tombstone' it (hide from everyone but admin), then let someone with some space from the process confirm it actually should be deleted. We've averted dozens of disasters this way.
I'd argue the user must feel in control, as you say, but not necessarily _be_ in control.
Same here. We implemented a “soft delete” in a system I worked on recently, as actually deleting something could have legal implications. We just have a table column where we mark it as deleted and then exclude those from any retrieval queries. If we ever need to undelete, someone can manually update the database.
Well, it ties in with another rule I have, don’t allow for stupidity. If a user can do some stupid things, it’s not designed well. (Say your deletion problem)
But yes, as long as these decisions are made consciously by a team, it’s get the attention it deserves.
I don’t know—this kind of deception is how the industry attracts more regulation. Delete needs to go back to meaning delete, and the user should be in actual control.
No. I frequently undelete or unsend. Others do too. Removing the Windows Recycle Bin or its equivalent would not make my life better by "giving me agency".
One of the first things I do in any OS is disable the recycle bin or equivalent functionality. To each his own!
In my head I just replace "Maybe later" with "Maybe never".
Apple’s Human Interface Guidelines are a wonderful set of documents. Apple doesn’t always live up to them and sometimes egregiously violates them, but I take a Stephensonian view of this hypocrisy (“That we occasionally violate our own stated moral code … does not imply that we are insincere in espousing that code. … No one ever said that it was easy to hew to a strict code of conduct”). I prefer that the document exists and they fail to live up to it, rather than the document be changed to reflect how they do operate.
I remember when I got my first Mac (right around the time Snow Leopard got released) and all the programs looked and felt so consistent. Not just those made by apple, but also third party applications downloaded from some random corner of the internet.
What really blew me away (and still does) is that apple somehow got people to care about their Human Interface Guidelines. At the time this was an entirely foreign concept to me. All the windows applications I used had very inconsistent behaviour, even though all the ui elements came from the same native toolkit.
There wasn't even an App Store or a centralised repository to enforce this, and yet people thought it important to adhere to those guidelines.
I think this is the reason why even today iOS apps feel like they have a slight advantage in quality. All of this comes with significant disadvantages, but there are upsides that are seemingly impossible to achieve otherwise.
Exactly, the Mac/iOS UX is coherent on a level that nothing else even comes close to. It’s a great example of doing many small things correctly, and the experience overall coming together as a result.
Going back to using Windows or Android afterwards is painful. (Windows especially now that they insult their users with advertisements within their operating system by default, something Apple would never do in a million years).
The settings app on iOS is full with prompts to subscribe to iCloud and appletv (even showing you a red alert, which makes it looks like there is something wrong with your phone).
They only go away if you subscribe. I still get the prompt for 1 year free appletv, although I already used that. When I click on it gets stuck on an infinite loading screen.
Oh, and apple care prompts on new phones until your device is not eligible for that anymore.
They are first-party ads linked directly to the services you are already using at some level. Microsoft distributes third-party ads.
a) Apple TV is not necessarily a service I use. Neither is Apple News.
b) Why does the ads being first-party suddenly make it more acceptable? Ads are ads, and I don't want them on my device, even if they are ads for my computer manufacturer's services.
Windows/Microsoft in $lang != en_US is also degrading constantly for some years to add salt to the wound. These days I see more and more of what are essentially adversarial examples that "compile" into English through machine translations.
> advertisements within their operating system by default, something Apple would never do in a million years
That's outright not true. MacOS (by default) gives you pop-ups asking you to try the new Safari, and when you put on your headphones it launches Apple Music with a pop-up asking you to try their subscription. The settings app begs you to sign in and pay for iCloud storage. The default dock is loaded with useless SaaS that would be better-off uninstalled. I still have the friggin U2 promo!
That's just MacOS. The water started to rise on iOS years ago, and it all contributed to me leaving Apple's ecosystem for good. This "premium" experience is meaningless if you just use it as premium ad space for your premium products. I'm going to pass on being a premium customer.
And this existed long before Mac OS X, too - it goes pretty much all the way back to the inception of the Mac. Even back with MacOS 6 vs Windows 95 when I was a child, I could easily see the difference.
I generally agree, though with a huge exception for iTunes back in the day. The baffling changes from version to version were frustrating and the UI seemed to hide obvious functionality, causing me to constantly ask “why can’t I <do X>?”. IMO Apple really struggled with iTunes’ identity for the past 22 years as it split off into other independent apps.
They've alway been included in the pages describing how to prepare your app for submission, I always thought they were almost part of the review process, but they're mostly just good advice and worth following, and won't hurt your submission
>That we occasionally violate our own stated moral code … does not imply that we are insincere in espousing that code. … No one ever said that it was easy to hew to a strict code of conduct
Interesting point. I think the statement miss an important additional point: it’s hard to come upfront with a rule set that is reality proof. More than the rules, what matter is why the rules was first uttered. To my mind, provided you agree with the underlying spirit, it’s better to break the exact rule and keep its purpose guidance in mind than strictly and blindly apply the literal interpretation of the rule and sap its genius.
Microsoft's UI guidelines were good too in the Windows 95-98 era before they went downhill. Their problem was that they didn't follow them in their own major applications like Office.
who is the Stephenson whom you are quoting here and what was his context?
The one and only Neal Stephenson in The Diamond Age
https://www.goodreads.com/quotes/119463-that-we-occasionally...
Here's a favorite UX error message of mine from chase.com
>"Your session is about to end. You've been inactive for a while. For your security, we'll automatically sign you out in approximately 1 minute. You may choose "Stay signed in" to continue or sign out if you're done."
No stress put on the user with a timer (e.g. "You will be logged out in 3...2...1"). Instead, they simply state the facts in a calm way. "For your security" tells me why they're logging me out. Perfect voice for a bank. I want that level of simplicity in all my financial apps.
I would personally go with a much shorter "Are you still there? If you're not, we'll log you out to protect your account." The buttons speak for themselves and the more words you add to a message, the less of it people will read.
Hell, if one button says "stay signed in" and the other says "log out", I don't even know if I'd go with a message that long. Just "are you still there" may be enough, with a redirect to the "why did I get logged out" page if you let the timer lapse.
On the other hand, I want error messages to be as descriptive as possible, with a short summary for normal users perhaps. Operational messages may be short and sweet, but if I need to solve a problem, I've had it with the "oopsie whoopsie we made a mistakey wakey" messages apps produce these days.
I don't like being asked something if the question/answer does clearly communicate what the consequences are.
Either the broad question is patronizing, suggesting the program makes decisions over my head without even informing me what about, or it is superfluous since the explanation+action is all I want or need.
I really do not enjoy programs behaving like they have intelligence by being vague or leading, but really never are, since their logic only covers the common case.
Disagree, your suggestion sounds anything but calm. It's like the computer is angry at me and it's fed up of my inactivity.
The HIG can upgrade that message slightly:
title: Your session is about to end.
text below: You’ve been inactive for a while. For your security, we’ll automatically sign you out in approximately 1 minute.
action button: Stay signed in
action button: Sign out
Maybe the text could be reworded a bit. “Automatically” is redundant, everyone knows websites are automatic. “About” can do the work of “approximately”. I like how friendly they are when telling you the time limit but it may not be necessary to give a time at all. So you end up with: “For your security, we sign out sessions that have been inactive for a while.”
Does everyone actually know what a "session" is? That word must be so confusing to some people.
It seems inferrable, at least in broad strokes, from the other, non-technical meanings of the word. See for example "the court is now in session" or "I had a physical therapy session this morning".
Isn't it used the same way in English? When you go to a therapist, you have a therapy session. When some musicians get together, they may have a jam session.
The technical meaning is very similar to the non-technical one.
I agree it's similar, though there's one difference: on many websites a session can have an arbitrary duration. If you log in to Google or Amazon once you can stay logged in on that device for months.
I'm not sure. Everyone learns it quite quickly after they are logged-out, but I don't think people know beforehand.
It's certainly not an issue for returning users. But I don't know how to improve it for first time visitors either ("logout" has the same problem).
Yeah, it probably is confusing to some. You might be able to skip the title entirely.
"For your security" is a cliché, I don't feel like it explains anything.
Using that snippet as an example, I wonder if I'm in the minority in that I would rather have more generic and impersonal explanations whenever possible, avoiding you·s and we·s. I find it somewhat grating to have what I know are software environments taking automated decisions and describing abstract concepts trying to pretend this is a personal relationship or interaction. This is not a terrible annoyance for me, just a very minor pet peeve, but I would much prefer the app/website to say for instance:
> This session is about to end due to inactivity. For security reasons it will be automatically signed out in approximately 1 minute. You may choose "Stay signed in" to continue or sign out if you're done.
Note that I don't mind the you in the last sentence, as it is truly referring to the personal me.
How about when some annoying dialog box gives you the options:
I don't want to thank my phone for offering to set a battery saver. It's not a person and I didn't want it to offer.Yes, that also annoys me! Especially when it's not even my phone but for example a third party service that is asking me to do something in their interest and not mine. Every time I click on one of those "No, thank you" buttons I mumble to myself a correction of "No, fuck you".
I suppose there are more people bothered by having to click a rude 'no', maybe?
EDIT: also, being bothered by it is maybe more the case for people who understand computers (at least somewhat).
I think it was originally used because A/B testing said there's a 1% increased "Yes" conversion rate when having to thank the company while declining, and then everyone started to copy Bigtech as always.
Whilst I agree with you on the communication from you to your phone.
However the phone is never speaking to you. It’s the designer(s).
I’m not sure why the illusion of the technology speaking to us is so important. I guess because humans anthropomorphise everything.
Slightly ironic that this makes us loose sight of the fact that we are actually communicating with humans.
In this whole conversation it seems this point is lost.
I cringe every time Windows says "they" are doing something.
I found that disconcerting, my computer is singular, so who is helping it?
We have everything under control, you do not need to know.
Isn't this considered terrible UX nowadays? Shouldn't a button "Maybe stay signed in later" be the only option to continue the countdown? ;-)
YMMY it seems overly wordy for me, and makes the bank seem amateurish and that they don't respect their users' time. Which would dissuade me from a banking app
A banking app needs to be universal because of how essential it is to participate in society.
I could see that POV. If it helps, they use effective visual formatting. The first sentence is an enlarged heading, and the rest of the text is smaller underneath.
From the article
> Be clear. Choose words that are easily understood and convey the right thing. Check each word to be sure it needs to be there.
[ title: You have been inactive for a while ]
[ dialog: To help keep your account secure, you will be signed out in approximately 1 minute. ]
[ button: Keep me signed in] [ button: Sign out ]
[ maybe a link: Why am I seeing this? ]
This thread is full of great discussion. Writing clearly can clearly be hard. It takes practice and skill.
This is why technology programs in schools require (or should require) technical writing courses. It might not seem important to know how to write for humans when you’re learning to write for machines, but writing for humans is one of the most important things you can learn, in any discipline.
As an engineer, I hate writing. That being said, one of the best classes I took during my undergraduate studies was a class called “Technical Communication.” We learned how to write a good email, memo, and even technical instructions.
For one of our big projects, we were given a box of Dots (gummy candy) and a box of toothpicks. We had to create a structure and then write instructions for another group of students to recreate said structure.
Many students did poorly because they would simply write out their instructions like “put a toothpick in the side of the dot.” What does that even mean? They never established top or bottom, so side could be anything.
> Writing clearly can clearly be hard.
I'm wondering if GPT3 + a set of copyrighting instructions + your draft can generate a list of suggestions for improvement.
And yet so often UX Writing is distained as an unecessary job that can be handled by designers or PMs instead of recognising the verbs and nouns of your product are its fundamental architecture to users. And that's before you get to voice & tone.
[dead]
Why the supposition that PMs and designers cannot learn this within < a week? Driven by personal qualm or bias perhaps
Hmm, I think this just might be a situation of our own making. When we assign a title to a person, we draw imaginariy mental lines and we hold an implicit bias that says only they are capable of doing that thing, rather than, it's their primary goal to be doing that thing. Similarly, others outside that title will hold a prejudice thinking, what is the big deal with what they are doing, what's taking so long, couldn't someone else do it?
The question can easily be shifted to ask, why only devs doing development, couldn't PMs and designers do it too? Well, yes they can. At least parts of it. HTML, CSS, definitely, maybe some basic JS too. Could devs do PM work, I think so, at least little bits!
For the same reason a writer is not and cannot be expected to become a designer within just one week. In the case of shoddy visuals, it's just much more obvious to even laymen if something's off.
UX is an art and you can't learn art in a week.
[flagged]
This is unnecessarily condescending and doesn't actually answer the question.
[flagged]
Please leave such condescension and other toxic commenting behaviors on reddit where they belong.
I'm glad you got the message. Let's hope the person who really needs it gets it.
> Write clear error messages
Totally. So often, the message that comes out on a "this should never happen" branch of the code is a random invention of a junior coder, and never reviewed by anyone.
> be clear about what someone can do to fix it.
"Sorry, an error has occurred."
i.e. All hope abandon, ye who enter here.
Many of Apple’s own apps are egregiously bad at reporting errors — as in, they don’t report them at all.
When Airdrop doesn’t work, it just gets stuck. No timeout, no nothing. I guess that’s very clean from a UX writing perspective because you don’t even need an error message. But it’s extremely frustrating to the user.
The iOS Family features suffer a similar lack of feedback. I toggle an app limit for my child and sometimes it just secretly doesn’t register on the server. I navigate back and forth to see the UI action hasn’t taken effect.
(Often I wonder if anybody at Apple actually has kids because Family works incredibly poorly. 30-second delays are common. Notifications don’t come through. User flows go through confusing incorrect states. Etc. Feels like it’s maintained on leftover MobileMe infra by junior developers who have no idea why anyone would even use this product.)
>When Airdrop doesn’t work, it just gets stuck. No timeout, no nothing.
Even when Airdrop works, it doesn't work. One "feature" of Airdrop is that if you try to airdrop something from your iPhone to your iPad, for example, but you had already airdropped it earlier, it won't give you ANY indication. It will make a nice ping sound, and just do nothing. This is so infuriating.
Apple's policy has been to show error messages when the user can do something with the information. And in most cases trying again is the only thing they can do so it tends to be minimal.
Also I suspect many of those issues you're seeing involve asynchronous behaviour which is a hard UX challenge to solve. You could send a push notification that an update has failed on the server but often the user has moved onto something else.
Even returning the most bog-standard message like "Try again (Error #12345)" would be immensely more helpful than having the UI simply do nothing, unclear on whether it's still working or not.
Sure, async UI is hard, but the world's richest corporation with a reputation for UX excellence could afford to try at least.
This. You have nailed it.
And why does Support and Marketing push back on that idea? Because they don't like when a customer reaches Support and says "I got error #12345! What should I do?" They'd much rather the customer just shut up and go away
however, the programmer who put 12345 in the code would dearly love to know that it was hit.
When you have an error message you don't understand, at least you can google for it. If something simply doesn't work, there could be many possible underlying causes, and finding a list of possible errors and going through all of them is much more frustrating.
An infinite loading animation and similar things are very ambiguous. Is my wifi connection bad right now? Is the OS acting up because I haven't rebooted the device in two months? Is a server down/unreachable? This wide range of possibilities is very frustrating because it often means you have a long, unsuccessful troubleshooting session ahead.
AirDrop is a particularly egregious outlier. It’s clear that something has gone very, very wrong with that feature. Not only with how unreliable it is, which is already bad enough, but with how clearly broken that basic state machine driving the UI is. Once it has gotten into a bad state, from my experience there’s no way to get it to succeed without restarting one or both iPhones.
Apple Music too is awful with error messages. There's one time I wanted to add a song to my library, I clicked the button and nothing happened. Which is the exact behaviour you get when it succeeds. Except it didn't work and my song wasn't added to my library. I tried a few more times and it just didn't work for this particular song. Thinking I maybe "lost" dozens of songs because they weren't added to my library is one of the reasons I went back to Spotify
> Which is the exact behaviour you get when it succeeds.
If it successfully adds to library, it doesn’t just do nothing, it gives you a “Added to Library” thing
I bet Apple Subscriptions is a popular product and makes them tons of money. Yet their admin UX is just as poor, I got instantly tiggered by your description.
Preach. In the same vein, I hate when I get a random error code (e.g. "error 189") in an error message on the UI as a user.
Am I supposed to remember that as a user? Will support know what the error code means?
Genuinely curious why some generic error messages (e.g. "Something happened") include these error codes.
Including arbitrary error codes in error messages is a good idea because it creates virtual gathering points for users searching for answers.
From a comment I’ve made about errors in the past:
“You should probably include the error code in the message (ERR0231), because that helps make the error message unique to this specific error situation and thus makes it functional as a “gathering point”. If you Google the error message and find others talking about the same error you experienced, that’s useful; if you Google the error message and find others talking about different errors on the same site, that is useless at best and could be harmful. (Concrete example: a multiplayer gaming platform reports a checksum of game files to a remote server to ensure all players are using the same version of the game. Scenario 1: The files are corrupt, the checksum is wrong, the error message is “Unable to validate game files”, the fix is to reinstall the game. Scenario 2: The user’s internet connection is temporarily degraded, the game is unable to get a response from the remote server, the error message is “Unable to validate game files”, the fix is to wait until connection improves. The unfortunate user from Scenario 2 is going to google their error message and get told to try the fix from Scenario 1. Now they’re re-downloading the game on their spotty connection.)“
Error codes are far better than lack of error codes. I was once involved in a large project to add unique, Googleable codes to all errors that could happen with $POPULAR_API, and support tickets dropped considerably after they were added.
At least if there's an error code, I can search for that specific error code and see if anybody else has run into it. Seeing "Error 3bad617a" means that somebody else may have copy-pasted that same error message, and it might show up in search for "$PROGRAM_NAME 3bad617a". This is best if every location that can give an error has a unique code, but can be useful even if it is just parroting some low-level code.
In other cases, an error code may be a standard value, and indicate that something is wrong with the inputs I provided as a user. If I see "Error saving file: 13", I may guess that the "13" was returned by some system call and is the error code EACCES or "Permission denied". I could test this by saving the file in another directory. The specific error code is useful for knowing what to do next, as error code 28 would be ENOSPC or "No space left on device", and I'd instead check if I ran out of disk space. (It would have been better if the error number had been passed through strerror() before display, but having the numeric code is still better than nothing.)
For messages you don't expect mere mortals to solve, error codes may be useful as a filter. Some Windows Update errors can't be fixed without a reboot (or a debugger and the Windows source code) so 0xdead1337 is a fine code. You can Google it if you want to try anyway.
Sometimes, errors happen because a whole chain of behaviour failed. The program is in a bad, irrecoverable state or contains a bug. The user can't fix it and the programmer that made the method may not even know the state can be impossible (i.e. code has been refactored).
Sometimes, error codes are more about helping the developers pinpoint a bug than they're about helping the user.
That said, things like "database corrupt" or "no connection to API server" should just be displayed rather than muffled away.
In my opinion, these impossible error codes should be accompanied with a support phone number or email address.
Numeric error codes are useful for troubleshooting, e.g. you can google “<program> error <code>”, or its developer can find where or around what exactly it’s localized.
The “something happened” part usually comes from a generic error handler that reports surprising errors. E.g. your current graphics card driver messes with directx internals in a way that the game couldn’t foresee this sort of exception in that code path. So here you go, “unknown error 0x8000abcd”. Google it -> update your driver.
Sometimes they're unavoidable, when you simply have no idea, or can't think of all the things that could go wrong, it's better to give an error code than a generic, something went wrong, message.
I've had worse though, when a UX design specified a specific error message and a developer blindly followed it and simply remapped errors to the given message, ignoring what the actual error was, misleading the users and the developers. I've told UX to never include error messages again..
Because there's a programmer who knows what 189 means, and the fact that it happened out in the wild means he can potentially fix the problem.
No, Support won't know, but they can pass the information on.
Error messages are one of the items on my mental code review checklist that gets very often excersized, since going from terrible to OK is usually pretty easy, but it's often a very different mindset from the actual programming task that introduced that error pathway.
So usually it's up to the reviewer to notice and guide the author to that improvement.
> branch of the code is a random invention of a junior coder
No need to blame interns or junior coders, this is done by big corporations after going through reviews and design iterations too.
It can also be fun :)
Guru Meditation!
https://en.wikipedia.org/wiki/Guru_Meditation
Yes! I've always found Microsoft's "welcome" messages in Windows installation to be extremely condescending and obnoxious (something they have an history of, even if unintentionally, going back to Clippy and beyond)
On the other hand, Apple is guilty of sparse and vague error messages, or not giving any messages at all and letting things fail silently (like when AirDrop or Personal Hotspot magically just not work)
Airdrop fails randomly at least 50% of the time I use it. And this experience is pretty consistent across over a decade of use with macbooks, mac minis, iphones (right up to the current 14) and tablets for an entire family.
It's just garbage 50% of the time, and you end up trying random things...
"restart your bluetooth"
"ok that didn't work, now I'll restart mine."
"ok still not working, lets both restart our bluetooth at the same time while chanting Jobs Jobs Jobs"
"ok now let's try a restart of both devices."
"fuck it, just use viber or email."
The debugger in me wants to think that it tries the local WiFi network first and something in your router or whatever messes it up
but since the whole point is for Apple↔Apple communication, shouldn't the devices talk to each other directly first?
AFAIK they do, via Bluetooth to negotiate the connection. The actual payload is then transferred via WiFi.
I don't see it, it's sparse yes, but condescending and obnoxious is an excessive description. It might be that you're going in to Windows installation with a preset prejudice.
That's always been my read.
"Hello" "Step back while we take care of things for you" "Just a few minutes longer"
I don't know the script verbatim, but it always read as very creepy and "This isn't your computer, it's Microsoft's." I would Ctrl-Alt-Delete just to have the pleasure of not seeing those messages.
A tiny UX tidbit I like, is the "close dialog" buttons in some products, consider the following 2 buttons:
"Dismiss" is self-deprecating and is an implicit admission that the warning is annoying, which makes the user less engaged. "Got it" or similar phrasing subconsciously encourages the user that they understand the message and can continue. Even if they don't care about the message at all, at least the message doesn't consider itself "Dismissable" and unimportant... it's a subtle UX change, but makes dialogs are bit more tolerable...“Got it” buttons fill me with rage in a way I can’t really articulate well. It’s probably due to the mental association at this point, but they always come up in ridiculous first-run tutorials that block me from using their product until I read and acknowledge some inane UI feature like “you can drag your finger to swipe!” or something equally obvious.
A “got it!” button (especially with the stupid fucking exclamation point) makes the software feel like the overly enthusiastic waiter from the restaurant in Office Space who is just nauseatingly upbeat. Fuck off and get me my coffee.
I’d love an OS-wide extension that would take replace the text on every “Got It!” button with “Fuck Off”. I know it would accomplish nothing but it would make me feel so much better using my phone.
> which makes the user less engaged
I don’t want to be “engaged” using your software. I want to accomplish my task and move on with my life. Why must every single aspect of software try to be my buddy nowadays? Why do I need to be “engaged” with it?
The UX that I like best is the one that provides the opt-out at the point where it would be an annoyance. Whenever there's a pop-up, I want an option to say "Don't show me notices of this kind again.". This requires a measure of humility on the part of developers, to acknowledge that learning about the feature they just added may not be the top priority of all users at all times, and an alternative way to learn about the UI.
Start-up tips that have options of "Close this tip", "Never show tips again", and "Next tip" are the best example, because they account both for users who want to learn more about the program and users who already know how to use the program.
> I don’t want to be “engaged” using your software. I want to accomplish my task and move on with my life. Why must every single aspect of software try to be my buddy nowadays? Why do I need to be “engaged” with it?
Engaging software is successful software. Engagement is also just a metric of 'user attention' I guess, which is a bit insidious...
You're in the middle of something and the app (or OS) says: here is some info about a huge new change, Got it?!
I find the familiarity that modern software assumes unnerving. Everything has a time and place, I wouldn’t want a Got It button while filling out an official form.
> subconsciously encourages the user that they understand the message
One of the problems with these friendlier messaging is, they are friendlier because they are more often only relevant to en_US(2023) linguistic, visual and societal context, and they are often in fact out of context by the time they are dissected into language resources, passed to (human or machine) translators, and executed on user terminals.
[Dismiss] is blunt, cold, harsh, "disrespectful", unnegotiable, but it virtually has no invalid translation candidates. [Got it], [Go ahead], [Fine], those can be anything.
I would like to take a moment to appreciate also the localization of the words. I deal with technical English my whole life, so I have no problem understanding computer terminology, but using Mac UI in my native language is quite beautiful experience. (Compared to Windows, Android or Linux.) I can't really wait when Siri will speak every language. (ChatGPT is pretty great at this, so my hope is that Apple will take notice.)
There's a need for localisation of tone, too. Even if the language is common, culture is not.
Monzo have an interesting "tone of voice" guide that they've made public https://monzo.com/tone-of-voice/
I've found it at least to be another useful starting point for things to consider.
It's a nice set of guidelines but does Apple have credibility in this area? Specifically, does Apple actually follow what they preach (looking at you 'Write clear error messages')?
Or more generally, are Apple's apps as good or better than what is out in the industry?
This is one example; there are other examples of frameworks and term lists: https://pivic.blog/blog/technical-writing/#technical-style-g...
Something I’ve always found interesting is wording in 1st person vs 2nd person. For example a link to “your orders” vs “my orders”. They’re both legit, but feel totally different. And I guess there’s a third, neutral option: just “orders”. The article mentions this very briefly, but this difference has a pretty profound effect on how the relation between the site and myself feels, that it doesn’t go into. I wonder how deliberate this decision (1st or 2nd person) is on most sites.
It seems to me that most apps choose the "my orders" approach, but I prefer to use an app that uses the "your orders" approach. It feels more professional to me and less like I'm being conned into something.
Apple makes great hardware, good OSs, horrible apps, indecent websites. Also, they use a very preechy way of advising, which for me means they think they are right, instead of looking at the market to tell us what works or not.
So you spend a lot of time and effort choosing terminology and phrasing these messages, then you need to translate it to N languages, and you are mostly out of luck. I tried to translate back one (of several thousand) of carefully phrased messages from a third party translation into English, and it was nowhere close. Was this a problem with google translate? Is it some limitation in the language? Who knows.
In the end I realized that the product has a consistent and well thought out language only for the languages the development team speaks, and that will never be very many. I guess the takeaways is this: If you can, an application in the language it was developed in, even if there is a translation to a language you master better. Because after a certain limit the importance is how well the developers master the language, not you.
Hold up, are you really relying on Google Translate for that?
Hiring an actual translation team solves this problem.
No, I am not google translating. I was just doing that as a "reverse test" to see what the translators had actually written. We are using translators who are proficient in the domain and speak 2 languages at least (English plus the target language). But they are still "external" to the team. They have some domain knowledge, but they don't have the true conceptual knowledge about what things are called in the program. Translators inside the development team (for the couple of languages covered by the developers) don't make the mistake of picking an incorrect synonym. The external translators might, despite good domain knowledge. The problem with it is: We don't notice. Because we don't speak the language!
E.g. if you make an architectural program, you might call things "floor", "level", or "storey". In an editor you might have "object", "entity" and so on) and all of these might exist and mean different things in the program. Language wise they may well be synonymous, but in the "domain language" of the program they might be very different.
As a frustrated non-English user of recent widespread degradation in software translations, I can verify that you're completely correct in your observations. Recent advents of "I give you lists of short gibberish to make guesses on but I don't listen for excuses because they're short" platforms like Crowdin are starting to put toils on i18n users, just as you have been finding out from the other side.
Basically it has to be bunch of screenshots or has to be tweet-long sentences, and it always had been, until someone ignorant in power started forcing that naivety.
Google translate is garbage level quality and can not be relied upon for any task. You should use DeepL for translation and you will be fine. Contract professionals to double check.
Google translate was only used by me to try to check what the professional translators had done, and see whether the phrasing is what I expect.
Google Translate is unreliable for that use. You'll need another professional translator to check that with certainty. DeepL is much better than Google translate, and also free.
I know. So it's just a creeping suspicion. But the "need a different translator" still doesn't help. Because of the same reason the first one didn't help. Unless the person knows the semantics of the program, and not just the domain and the languages involved, we can't be sure they are making the right translation. It doesn't matter how many translators you throw at it (or how many tools). The closest thing would be to simply sit down with translators+developers and go through it. But that's also prohibitively expensive for specialist software (I.e. software where the number of languages times the number of translated texts is easily 100x the total number of users).
Looks like the screenshots on this page are dead, they're giving me 404s
Strange. Works for me. Maybe they can't handle the hn-induced traffic? ;)
Doesn't work for me either.
This thread is a great example of how subjective matters of design are.. ..and what a nightmare any sort of “design by committee” can become.
> It’s always best to help people avoid errors. When an error message is necessary, it should appear as close to the problem as possible, avoid blame, and be clear about what someone can do to fix it.
Try designing with the idea in mind that the user will never see an error. First, instead of coming at it from the point of view "the user made an error", start from "the program was not useable enough". Much like a door with handle that cannot be pulled, but must be pushed, a program with a UI that appears to allow an action but really doesn't, the issue is not the person's fault. Respond to failures to complete the action the user attempted with alternates. Imagine how frustrating it would be if you went to buy coffee and the person working there simply said, "no, you've made an error" when you tried to order something they're out of. You'd right avoid doing business there ever again.
More generally, the UI is just as important as the algorithm behind it. We see social networks doing all sorts of UI shenanigans to trick users into doing their bidding. It's not enough to allow customisation of our algorithmic feeds, we need to have a level of control over the UI as well.
I'd rather read overly technical language that assumes intelligence or curiosity on the part of the reader, rather than comforting euphemisms. When I was a kid I thought SimCity1993 really was "reticulating splines" during the loading screen and it didn't scare me off. Now Windows (which ought to be a lot less cheeky than Maxis) will print something like "We (who?) are just (just?) finishing some things (things?!) up for you"
I've long thought that it would be really great to have log/internals viewing be a first class citizen of an OS.
Windows has a variety of tools that let you see debug message and trace events but they're not really useful for casual perusal. I don't know what the ecosystem looks like on Linux.
I suppose I'm not sure what I'm asking for. But in the aforementioned example (Window's post update/install OOBE with "We are just finishing some things for you") it would be nice to press something like Shift+F11 and open up a log viewer that knows you're interested in the main thing on screen to see what it's actually doing.
Linux is quite nice actually, getting a broad overview of "what the system is doing" is as easy as opening a text file or running a command. If you have a single app misbehaving, you can often run it from a terminal to see extra debugging information. (This trick usually works on Mac OS as well)
Windows has no such equivalent; event viewer is incredibly clunky
Do you think your opinion is representative of the majority of folks who use technology?
Of course not, but I see that fact as an indicator of the collateral damage in the continued "War on General Computing" more than anything else. The customer is not always right - what they may want is to be infantilized, but what they need is to be educated.
I've been witness to this "War on General Computing", being a 31 year old human who's used computers for the better part of 28-29 years of that time.
I'm not convinced the shift you're describing as far as UX writing is anywhere near as concerning as the actual war on general computing with respect to running the OS you want, the software you want, with restrictions as necessary for security but not for vendor lock-in.
UX writing tone, of course, is only a tiny piece of the overall foreclosure of customization that the current era of UX designers is complicit in. I see a continuum between cutesy UX writing and reduced ability to customize any and all settings by the end user; You think there is an "actual war" separate from the propaganda used to manufacture consent for it. Gilded cages need gilt - that gold leaf takes the form of emojis etc.
maybe they should try to improve user experience with their own applications before telling others what to do?
Finder on MacOS: probably should be renamed to Hider. Just a horrible file explorer interface. I couldn’t imagine something worst. I ended up training my family on how to use the Terminal and mdfind command instead.
Apple Photos and the shared album interface is such a pain to work with as a user. I hope it’s not just me!
I could go on but I’ll stop here.
I’m skeptical UI matters and I sometimes think if you get traction with extremely poor UI (as is often the case) it implies you’re solving something people need and people are willing to circumvent your bad design yet still find value you’re probably onto a winner.
Sure, be kind to your users once you have some traction but I think nice UX or even words isn’t hugely important.
And then you have to translate it, which also is essential to UX. Reminds of of this 10 years-old article which is still relevant today: https://alistapart.com/article/translation-is-ux/
Instead of “It looks like you have fell, call 911?”, go “Oh no! You fell! Omg! Call an Ambulance, but not for me?”
I'd ignore advice from Apple or Big Tech about how to use words. They are not language experts. They are not content experts.
They are infected with the same over-sensitive "inclusivity" reaction that has spread far and wide like a virus. Apple has adopted the widely criticised Stanford harmful words list.
At bottom of this article are link to another page which has the following advice:
"Avoid 'Peanut gallery' and 'grandfathered'". Because they arose from oppressive contexts.
People are not "grandfathers" at their core. Nobody becomes a grandfather because they had an accident and woke up with the unwanted new identity. Grandfathers won't protest in the street about the term used in tech circles. Grandfather is a name describing their relative position in a family tree.
"master", "slave", "sanity check", "kill"... Apple says no to all the usual copy and paste words from the list. The viral nature of these lists spreading around is of concern.
"Fall through the cracks", "on the same page", and "backseat driver"... Apple says no.
- support.apple.com/en-gb/guide/applestyleguide/toc
Who would have thought that Apple, a niche brand known to so few, would feel the need to use inclusive language? Mac? More like PC gone mad! /s
Without your '/s' I'd be lost in the rough seas of your intended meaning.
Feeling the need to copy a list of words is not the same as feeling the need to be inclusive.
Besides, using those words and phrases isn't offensive to anyone other than a small minority of... "language activists" for want of a better description. The same people modifying books down to story elements like what jobs the characters have.
"Check the history of words" is not a UX concern, and shouldn't be in style guides alongside "avoid 'click here'".
Nice, valuable resource here for anyone in any position in a business. Apple is one of the best with user experience so having a laid out guidelines like this is a public service. Thanks for sharing
I'm curious if anyone here has links to a pdf/printable version of these docs by Apple? Or even if anyone knows anyone compiling an archive of diff. versions?
I’ve always thought of users as guests, and your website/app acts as the concierge for various services. They speak clearly, consistently, are helpful, and act according to the situation at hand.
Have anyone tried ChatGPT for this? It must be pretty good at following these guidelines.
I use GitHub CoPilot for this all the time!
And sane with the words you write while using it.
Looks like a guide to bland consistent mediocrity
Honestly, all I care about is speed. Couple of word swaps here and there using a thesaurus, who gives a shit.
A job for ChatGPT
Fire the copy team, and if you never had one now you dont need this skillset either
Enjoy coding in the building blocks together and compiling, peace
Shameless plug: if you want to empower your team to iterate your UX text in web apps (React, Angular, Vue, etc) FlyCode lets non-technical teammates make changes to UX texts and send a PR to GitHub with the text changes: https://www.flycode.com/developers
If we're fully committing to the new and improved culture, then logically we need to ditch the word "write".
The root word of write, is a proto-indo-european word that means 'to cut, mark'. Writing grew out of making permanent cuts on stone and permanent marks on paper. The culture of the writing era exemplified cut earthwork and decorative marks.
We don't do that verb anymore, we type. We push buttons and symbolize words in binary streams. Our culture celebrates games, software and movies that are pushed out into the world and symbolize something.
We can't keep overloading the meaning of the word 'write' and expect people to understand what's going on.
Bizarre take. Should people also not use the word write when referring to using a pen and paper? That’s also not cutting or marking.
It exactly is marking paper.
Wait until you find out how academics use the verb "to read".