The words you choose within an app are an essential part of its user experience
developer.apple.com
developer.apple.com
The correct way to do it is:
(Attention sound)
Did you just fall?
((SOS) swipe for help)
[I’m okay]
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.
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.
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?
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.
"Call emergency services?"
"Yes" "No"
Although it removes the context of the watch' reasoning.
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.
Reminder that the screen is a false positive protection mechanism and will only ever be seen in a specific context.
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.
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).
“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 didn’t fall, then you know it’s wrong.
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”
Apple's version is better. It's more accurate of what the feature does (guessing based on factors), and it's more human.
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!
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.
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.
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).
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.
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.
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.
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.
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?
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...
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.
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...
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.
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.
For kids, a kid sized phone would seemingly work better. 1/3 the size, weight, and theoretically with a smaller font and display.
Stop mentally enslaving yourself.
Thankfully most people have four backup fingers on the same hand..
try to do what you do every day without using a thumb and tell me how good it is to have 4 "backup" fingers.
I 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.
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?
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.
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.
You would be correct if it was a game.
Though a return to a little bit of depth in interface design would help. Even plain tappable buttons often have zero affordance these days.
I agree with you more than the GP, but this isn't a good way to structure a rebuttal.
People can’t interpret that kind of nonverbal/abstract cues. It’s quite an inner circle thing of nerds that those seem ultra obvious.
Nerds would type SOS at a command prompt.
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.
Might want to run it by the ethics board, though, before subjecting 50 people to traumatic events.
> ((SOS) swipe for help)
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.
"Fall detected"
"Sudden motion - Injury suspected".
"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.
The actual message includes a countdown which automatically makes an SOS call if you do nothing.
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..
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.
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.
Don't do: <h1><img src alt="ACME logo">ACME</h1>.
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).
<h1><img src alt="ACME logo">ACME</h1>
ACME logoACME
<h1><img src alt="ACME"></h1>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.
[0] https://developer.apple.com/design/human-interface-guideline...
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.
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...
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!'"
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).
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".
In fact, I use this style of "snooze" quite often as a user.
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.
https://superuser.com/questions/1617750/how-to-restore-remot...
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!
I'd argue the user must feel in control, as you say, but not necessarily _be_ in control.
But yes, as long as these decisions are made consciously by a team, it’s get the attention it deserves.
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.
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).
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.
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.
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.
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.
https://www.goodreads.com/quotes/119463-that-we-occasionally...
>"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.
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.
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.
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.”
The technical meaning is very similar to the non-technical one.
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).
> 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
No, thank you
EDIT: also, being bothered by it is maybe more the case for people who understand computers (at least somewhat).
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.
We have everything under control, you do not need to know. Are you happy with the experience we are providing you?
– Yes
– Yes, thank you> Be clear. Choose words that are easily understood and convey the right thing. Check each word to be sure it needs to be there.
[ 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 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.
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.
I'm wondering if GPT3 + a set of copyrighting instructions + your draft can generate a list of suggestions for improvement.
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!
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.
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.)
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.
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.
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.
If it successfully adds to library, it doesn’t just do nothing, it gives you a “Added to Library” thing
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.
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.)“
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.)
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.
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.
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..
No, Support won't know, but they can pass the information on.
So usually it's up to the reviewer to notice and guide the author to that improvement.
No need to blame interns or junior coders, this is done by big corporations after going through reviews and design iterations too.
Guru Meditation!
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)
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."
but since the whole point is for Apple↔Apple communication, shouldn't the devices talk to each other directly first?
"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.
[ Dismiss ]
[ Got it ]
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?
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.
Engaging software is successful software. Engagement is also just a metric of 'user attention' I guess, which is a bit insidious...
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've found it at least to be another useful starting point for things to consider.
Or more generally, are Apple's apps as good or better than what is out in the industry?
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.
Hiring an actual translation team solves this problem.
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.
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.
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.
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.
Windows has no such equivalent; event viewer is incredibly clunky
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.
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.
Sure, be kind to your users once you have some traction but I think nice UX or even words isn’t hugely important.
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
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'".
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
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.