Let's talk about language, context, Apple vs Apple, why having a button marked "cancel" in your software might not always be a good idea, and... exploding pie?
Dunno man, seems fine to me. I'm using a headset tho, Fiio k3 DAC to a beyerdynamic dt 700 pro x, your audio is at "regular conversation" level and is fine.
@@kevinscalesI mean, the only reason it crashed is cuz it did something bad so the OS stopped it, so technically u can modify the OS to ask you before it crashes an app if u want it to crash or do something weird that is likely to corrupt stuff
For the financial "cancel" example, i can understand that this is what that term means in finance. But also, when putting it on a UI, especially a button on a dialog box, that word is reserved and should take higher presedence, and clearly this program calls it the *wrong thing*. They should use a synonym, right? "Revert transaction", "Refund transaction". i suppose refund should mean two separate transactions took place? i'm no accountant. But i do know that, at least in software, it's okay to call a thing by multiple names depending on context. For example, discord has a concept of a shared space with multiple channels you can talk in and invite your friends to. What is that called? Ask most users or read on their website, and it's called a server. If you dig into their API documentation and endpoints, or any client library, or if you ask someone who works with discord bots, and you will learn that they are called guilds. Because, in that context, "server" is already reserved for the other end of this connection. You are the client talking to the server, not about a server, but about a guild. For end users (originally, gamers) they are much more likely to want to disambiguate this name from their guilds in WoW or other MMOs. The same philosophy should apply to financial applications. You are writing it for a system where "Cancel" means a specific thing, so either use it as intended, or avoid that name altogether. At the very least, "cancel transaction", but preferably to avoid ambiguity it should be something like "revert" and "back".
I work with ERP systems. We have many dialog boxes that have Yes/No/Cancel buttons, just like other computer systems. We would never just use the word "Cancel" meaning cancelling a financial document. We'd use "Cancel document" or "Cancel transaction". In addition to avoiding ambiguity, these systems are usually translated to multiple languages. And good luck translating "Cancel" out of context.
The more successful companies I worked for had UI experience people. Not technical, but they designed and test the UI in ways that most developers would have not thot about as developers come from a different world. I used to not think too much of them at first, but they saved us from many pitfalls, and working but poor clarity UIs. For many end users if the first experience is not good , they will not come back. They are done. Like art, there is a talent there. The best were UI testers with domain experience for the target application audience.
I sadly have seen more of the opposite: The developers got a request and the specifications are vague or seems stupid. The dev creates a concept and a first mockup to show so they can talk about the various scenarios. When it comes to the questions "What happens if there is a problem?" "how to cancel that?" they get answers like "that does not happen", "just ignore it" or "we already sold it without the option to go back or cancel".
can you mention a specific example? some early Airbus A320 crashes come to mind, where pilots confused the autopilot altitude and vertical speed controls
@@RoamingAdhocratThe Airbus dual input issue comes to mind, where both pilots can think they're in control while they're actually fighting each other, because the sticks have no feedback, but add inputs together.
@@RoamingAdhocrat there were some famous ones where controls had the same feel, or were placed poorly, so pilots actuated the wrong control at a critical moment. John Denver crashed his Long-EZ because the fuel tank selector ended up positioned in an inaccessible place by the person who built the kit, and the sight glasses that acted as the fuel tank gauges did not make it easy to distinguish how much fuel was actually in the tanks, so he did not refuel before he left the airport.
@@RoamingAdhocrat early B-17s had a problem where they would frequently crash on landing. It turned out that the switches for the landing gear and the flaps were right next to each other, and of the same design, so exhausted pilots would often mix them up after returning from missions. They were redesigned to be far apart and different shapes (the landing gear lever shaped like a wheel, the flaps lever large and square).
The Dutch have taken the concept and applied it to road design. If a vehicle hits a building, part of the investigation is figuring out what changes to the road design could prevent it happening again.
So I got a notification from "Rob" asking "why aren't my comments appearing?" Rob, I have no idea... because I can see the notification telling me you posted that, but I can't see the actual comment; when I click the notification it doesn't do anything, and now the notification has vanished. And since all I know about you is you're called Rob and your UA-cam avatar is an EU flag, I can't think of any better way to reply to your question than just posting this here and hoping you see it. But there are no hidden/deleted comments on this video, so whatever's happening it's down to UA-cam misbehaving. Sorry.
"But there are no hidden/deleted comments on this video, so whatever's happening it's down to UA-cam misbehaving. " They can be hidden/deleted - by UA-cam. and sadly that isn't even all that uncommon.
Hah, that's funny. I work for a tech company in the finance industry, and as soon as you mentioned 'Cancel' in the context of Windows dialogue boxes and what its meaning was, I was like 'Huh, I wonder if anyone has ever made that mistake with our software'... then immediately you switched to talking about some finance software and how it led people to make this mistake :D
We have a trademark conflict which will cause customer confusion. But we can come to a settlement where we both still use the trademark at issue, which will magically no longer cause customer confusion.
They don't care about customers being confused. They care about not being able to make money due to customers being confused. The settlement is more like "we are okay with customers confusing our brand for yours, as long as you're paying us money".
I like the Gimp dialog box that you get as you close the program on a new, unsaved file. There's an OK button for saving the file with the name you gave it. There's a Cancel button to just stop this whole sequence of events. And there's a Delete button with red text, that makes it clear that you're deleting the file that you just spent 10 seconds on.
On the other hand: GIMP has an option called "save as", which is exclusively for saving the same file under a different name or in a different location, and another called "export as", which is for converting the file to a different format. Not once in my life have I needed the action found under "save as", and yet I click it every single time before remembering that I want "export as". And GIMP _knows_ that users mix these up, because if you change the file extension under "save as" it tells you to use "export as" instead. GIMP. Buddy. If you know what I'm trying to do and you can do it, how about you just _do it_ instead of going "ah ah, what's the magic word"?
Save As vs Export As is conventional across several domains of software. You're saving the project, or Exporting the final result @@HeadsFullOfEyeballs
7:30 I hope these guys at the airport discover the white upwards pointing arrow on a blue circle background, and use it instead of the white line on a green circle.
That’s me too. And every time the moro… clients complain, I obsessively add to the fine manual refining the language, adding explanations to it and hoping that eventually, people will be able to read and understand. Actually, I’m hoping that AI ingesting the docs will help answering the moro… client questions.
I ended up with this problem last Wednesday. I needed emergency health care, and at first I tried to use a well-known "modern" provider, but in my state of pain I couldn't work out whether my request had been accepted or if they expected more information....So I called 112 since I was too confused and too scared to bet that I had overcome their too complex website. Turned out I had, and they tried to call back while I was on the 112 call. But afterwards I was thinking; How stupid are they not to test on people in extreme pain, inability to move properly, can't see clearly and so on?
I once expressed my annoyance with handles on push doors to a marketing bigwig who fired back: "That's an 'affordance' called a 'Norman Door', you need to read Don Norman "; so I did, as should anyone who cares about UX/UI.
Fun fact: this is even the case with the term "backup." It use to be that backing up the computer meant restoring an archival copy you made earlier, back in the days of punched cards and core memory. Makes sense, right? Then you went from archival copy to making a backup copy, to backing up being the act of *not* losing recent data on the computer.
I expect the backup term far predates computers, e.g. the role of "understudy" is a backup plan. Webster's lists backup 3 "A substitute held in readiness for contingent use", with examples "a backup plan" and "a backup quarterback". Etymonline dated it to 1767.
@@0LoneTech I'm not surprised. I was merely speaking of the computer usage. And of course there's "backup singers" and such as well. I wonder if it is related to a "backstop" holding up a facade or something.
I went from military in a non-tech role to software via a bootcamp (this was in 2014). Everyone wore flip flops. I thought deployments were when your company sends you out of town to work onsite with a client for a period of time. The thing that really threw me off though was Agile. The agile I was accustomed to was a polar opposite of Agile, which seemed to be an intentional hamstringing of developers ability to accomplish anything. The more appropriate term, if appropriation were unavoidable, was FUBAR. It still is
Really interesting and useful video. I'm probably going to pinch some ideas/concepts from this and incorporate it into my teaching for CompSci students. Should help greatly with game/web dev units.
The absolutely stupidest thing I've ever seen in UI design was, I think, on a button on my late, lamented Newton 2000. Some app required manual save, and this was accomplished by pressing a button with the outline of Texas and a question mark. Why? According to the manual, this is the “remember state” button. I absolutely kid you not. A close second was a bug, a requester on an Amiga that said “Are you absolutely sure you want to IRRETRIEVABLY DELETE all frbtnh;zfn;vjknfbsblfg7&%%$#-(((((~` THIS CANNOT BE UNDONE” followed by _seventeen_ [OK] buttons, not all of them placed within the window. Amazing what an Amiga could do with a stray pointer, it really was.
If I recall correctly, xfm had an absolutely excellent example of failing to consider this concern. As I remember it, it had a modal popup simply labelled "Quit?" with three buttons: Continue, Abort, Cancel. What's your guess of what each button meant?
the c# language design team has the concept of "pit of success" - if you try something the obvious way, that should be the way that doesn't have the pitfalls in it. They have eg: refused to implement shortcuts for nested yielding iterators despite repeated requests, because accidently hiding a quadratic performance penalty is not something that the language should do
An example of the principle of least surprise. Do something obvious and the outcome should be the most obvious and least surprising of potentially many other possible outcomes. 25 years ago the software tools I worked with - libraries, frameworks, etc, adhered to this as a guiding principle. Today it's all Russian roulette.
"the c# language design team has the concept of "pit of success"" And the libraries and everything else around it try their darn hardest to invert that: doing the correct thing is neigh impossible to do by accident. You have to know everything to not fall victim to one of the thousands of traps they have layed out. And even C# it self has many, refuses to add useful safety features and even refuses to acknowledge that problems exist (say no 'const' for local variables - that is a dangerous source of bugs).
A big issue with "cancel" buttons is Microsoft Windows' (now mostly historical) overuse of plain "Ok/Cancel" dialogs, and still today 3rd parties making Windows software is often over using it too. Not only were they using too many generic confirm dialogs without custom text on the buttons, but they were all using _way_ too many confirm dialogs on really unimportant stuff in general, which have trained a whole generation of users to reflexively click buttons in confirm dialogs without reading them properly. The problem with excessive confirm dialogs has improved somewhat in later years, being largely made redundant with autosaving and multiple levels of undo; but the fact that we still occasionally need to warn about drastic changes that cannot be undone it's still a big problem that there's millions of users who now instinctively dismiss confirm dialogs as an annoyance often not even caring which button they press.
This is especially bad with the those who are 10-15 years younger than me (those born in the earyly to late 90s); who grew up using computers with terrible software with too many redundant confirm dialogs often filled with technical language (which quite often wasn't even a language they could read at all, if their first language wasn't English); maybe they hadn't even learned to read yet so for them the dialogs was entirely an annoying distraction to be dismissed one way or the other. And since they probably rarely were actually using software that could do something really bad to your system (like disk formatting etc.), and since 99% of these dialogs were completely redundant "Are you sure you want to do the mostly harmless action of the button you just pressed" they probably almost never had anything bad happening whenever they just "dismissed" the dialog by pressing the "Ok" button. So many times I've seen people in this generation just reflexively hitting enter or clicking whatever button on a dialog so quickly the text didn't really have time to render much less time enough to be able to read it. And then complain why the software isn't doing what they wanted, or complaining why their document was deleted (or rather not save). And I'm not actually blaming them; they have been trained extensively every day by bad software for a more than a decade to do so. Of course they do what they were trained to do! At least older nerds like me who _did_ play around in disc format dialogs, and did completely break one or two systems back in the mean old days when OS'es was really unforgiving, at least have learned to read the dialog before clicking an option. Though we still reflexively choose an option, we usually realise how and why we messed up just after we click the wrong option, because we at least half-read the message.
Agree that 'moron in a hurry' is the wrong way to phrase it. End users just shouldn't need to think hard to use your application if that is actually possible. And if it IS and you DON'T DESIGN IT THUS, who is the moron?
"Agree that 'moron in a hurry' is the wrong way to phrase it." Why? "End users just shouldn't need to think hard to use your application if that is actually possible." Yes - and that is specifically the reason why it is called that: Cause things should be made in such a way that you'd need to actually be a moron in a hurry to not know what it is. "And if it IS and you DON'T DESIGN IT THUS, who is the moron?" So - you are explicitly telling us that such a designed FAILED the moron-in-a-hurry test................
You better start running you videos through some kind of "Volume normalization in a Hurry" tests. My volume is at 100% on each side and I still can't hear a thing over my background noise
And the you then with "look out for context switches". Usually I don't have to, my computer is perfectly able to handle that on it's own. Oh, you didn't mean computing context switching...
I, too, don’t particularly like the phrase ‘moron in a hurry’ . let’s not call someone a moron if he choose simply to give as little attention as possible to the app or website he is using what other phrase might we use? . maybe ‘low-cognitive load user’? . I’m sure we can come up with something better . but essentially, the phrase we are looking for describes someone who refuses to give an app or website the amount of attention which is considered ‘reasonable’ . maybe ‘minimally-engaging user’? . idunno; ideas?
"Moron in a hurry" passes the "moron in a hurry" test for explaining that UI concept! 😂 Really though, if you have people getting stuck in a UI, you can either moralize their attention span or preempt the problem. A lot fewer people's time gets wasted if you do the latter.
"let’s not call someone a moron if he choose simply to give as little attention as possible to the app or website he is using" You failed to understand what the term actually means despite it being so simple that it would pass the moron-in-a-hurry criteria........... "maybe ‘minimally-engaging user’? . idunno; ideas?" Yes - such a term already exists. it is called MORON.
5:44 I love that the "Cancel" on the Password dialog probably means "OK". And that there's no real way out except the X to close - which is a Windows convention, afaik
Dylan: "What is the capital of Norway?" My Brain: "Holy f'ing epiphany!" Language learning models. From toddlers to Terminators in a mere blink of an eye.
@@bobweiram6321 wrong. The Amiga was a company. The company was initially called Hi-Torro, and was later renamed to Amiga Corporation. They raised a bunch of money from some Dentists to work on the Lorraine (which later became the Amiga). This was before Commodore acquired the Amiga computer. Please go read the history of the Amiga - or ask those engineers who worked on the Amiga… I know a few of them (sadly several have died).
@Bobweiram6321 - you're wrong. "A final significant event that took place during 1982 is the company's' name change. In an attempt to distinguish itself from the Japanese lawnmower firm 'Toro', the company name is changed to 'Amiga Incorporated'. The reason for the choice of Amiga has become legendary - Miner wanted a 'friendly' name that would dispel the air of confusion that surrounds most computers. As the Spanish word for female friend, Amiga fitted this profile. The fact that it came before Apple and Atari in listings also helped. Although Miner was unhappy with the name initially, he soon realized the impact that it could have." This all happened before Commodore stepped in and acquired the Amiga computer (the Amiga computer had a few names before it was called an Amiga... but that's a longer story)
Yep, the audio on this one came out too quiet. I'll turn it up to 11 next time. Promise. ❤
Dunno man, seems fine to me. I'm using a headset tho, Fiio k3 DAC to a beyerdynamic dt 700 pro x, your audio is at "regular conversation" level and is fine.
I always love dialog boxes like: "Are you sure you want to cancel? [OK] [Cancel]"
Also, I'm loving these videos, thanks!
Cancel that cancelation!
Cancelception!
The program has crashed [OK][Cancel]
Wait, I can uncrash the program?
@@kevinscalesI mean, the only reason it crashed is cuz it did something bad so the OS stopped it, so technically u can modify the OS to ask you before it crashes an app if u want it to crash or do something weird that is likely to corrupt stuff
Still better than VSCode that once presented me with a choice between normal "Cancel" and blue-background "Cancel"
Yes means no. No means yes. Delete all data? [YES|NO]
For the financial "cancel" example, i can understand that this is what that term means in finance. But also, when putting it on a UI, especially a button on a dialog box, that word is reserved and should take higher presedence, and clearly this program calls it the *wrong thing*. They should use a synonym, right? "Revert transaction", "Refund transaction". i suppose refund should mean two separate transactions took place? i'm no accountant.
But i do know that, at least in software, it's okay to call a thing by multiple names depending on context. For example, discord has a concept of a shared space with multiple channels you can talk in and invite your friends to. What is that called? Ask most users or read on their website, and it's called a server. If you dig into their API documentation and endpoints, or any client library, or if you ask someone who works with discord bots, and you will learn that they are called guilds. Because, in that context, "server" is already reserved for the other end of this connection. You are the client talking to the server, not about a server, but about a guild. For end users (originally, gamers) they are much more likely to want to disambiguate this name from their guilds in WoW or other MMOs.
The same philosophy should apply to financial applications. You are writing it for a system where "Cancel" means a specific thing, so either use it as intended, or avoid that name altogether. At the very least, "cancel transaction", but preferably to avoid ambiguity it should be something like "revert" and "back".
It would take up more room, but "Cancel Transaction" would be much clearer.
I work with ERP systems. We have many dialog boxes that have Yes/No/Cancel buttons, just like other computer systems. We would never just use the word "Cancel" meaning cancelling a financial document. We'd use "Cancel document" or "Cancel transaction". In addition to avoiding ambiguity, these systems are usually translated to multiple languages. And good luck translating "Cancel" out of context.
The more successful companies I worked for had UI experience people. Not technical, but they designed and test the UI in ways that most developers would have not thot about as developers come from a different world. I used to not think too much of them at first, but they saved us from many pitfalls, and working but poor clarity UIs. For many end users if the first experience is not good , they will not come back. They are done. Like art, there is a talent there. The best were UI testers with domain experience for the target application audience.
I sadly have seen more of the opposite:
The developers got a request and the specifications are vague or seems stupid. The dev creates a concept and a first mockup to show so they can talk about the various scenarios. When it comes to the questions "What happens if there is a problem?" "how to cancel that?" they get answers like "that does not happen", "just ignore it" or "we already sold it without the option to go back or cancel".
Re: moron in a hurry and design induced errors, there is a class of aviation incident that is "design induced pilot error"
can you mention a specific example? some early Airbus A320 crashes come to mind, where pilots confused the autopilot altitude and vertical speed controls
@@RoamingAdhocratThe Airbus dual input issue comes to mind, where both pilots can think they're in control while they're actually fighting each other, because the sticks have no feedback, but add inputs together.
@@RoamingAdhocrat there were some famous ones where controls had the same feel, or were placed poorly, so pilots actuated the wrong control at a critical moment.
John Denver crashed his Long-EZ because the fuel tank selector ended up positioned in an inaccessible place by the person who built the kit, and the sight glasses that acted as the fuel tank gauges did not make it easy to distinguish how much fuel was actually in the tanks, so he did not refuel before he left the airport.
@@RoamingAdhocrat early B-17s had a problem where they would frequently crash on landing. It turned out that the switches for the landing gear and the flaps were right next to each other, and of the same design, so exhausted pilots would often mix them up after returning from missions. They were redesigned to be far apart and different shapes (the landing gear lever shaped like a wheel, the flaps lever large and square).
The Dutch have taken the concept and applied it to road design. If a vehicle hits a building, part of the investigation is figuring out what changes to the road design could prevent it happening again.
So I got a notification from "Rob" asking "why aren't my comments appearing?"
Rob, I have no idea... because I can see the notification telling me you posted that, but I can't see the actual comment; when I click the notification it doesn't do anything, and now the notification has vanished. And since all I know about you is you're called Rob and your UA-cam avatar is an EU flag, I can't think of any better way to reply to your question than just posting this here and hoping you see it. But there are no hidden/deleted comments on this video, so whatever's happening it's down to UA-cam misbehaving. Sorry.
"But there are no hidden/deleted comments on this video, so whatever's happening it's down to UA-cam misbehaving. "
They can be hidden/deleted - by UA-cam. and sadly that isn't even all that uncommon.
Hah, that's funny. I work for a tech company in the finance industry, and as soon as you mentioned 'Cancel' in the context of Windows dialogue boxes and what its meaning was, I was like 'Huh, I wonder if anyone has ever made that mistake with our software'... then immediately you switched to talking about some finance software and how it led people to make this mistake :D
We have a trademark conflict which will cause customer confusion. But we can come to a settlement where we both still use the trademark at issue, which will magically no longer cause customer confusion.
They don't care about customers being confused. They care about not being able to make money due to customers being confused. The settlement is more like "we are okay with customers confusing our brand for yours, as long as you're paying us money".
@@letao12 Entirely true!, but not a thing you can argue in court under the law. Which is why we get settlements.
I like the Gimp dialog box that you get as you close the program on a new, unsaved file. There's an OK button for saving the file with the name you gave it. There's a Cancel button to just stop this whole sequence of events. And there's a Delete button with red text, that makes it clear that you're deleting the file that you just spent 10 seconds on.
Oh good we’re taking gimp as an example of good UI
On the other hand: GIMP has an option called "save as", which is exclusively for saving the same file under a different name or in a different location, and another called "export as", which is for converting the file to a different format. Not once in my life have I needed the action found under "save as", and yet I click it every single time before remembering that I want "export as".
And GIMP _knows_ that users mix these up, because if you change the file extension under "save as" it tells you to use "export as" instead. GIMP. Buddy. If you know what I'm trying to do and you can do it, how about you just _do it_ instead of going "ah ah, what's the magic word"?
@@HeadsFullOfEyeballstbh, I never use eithet button as I just use the shortcuts.
OK is a terrible name. Should be named Save
Save As vs Export As is conventional across several domains of software. You're saving the project, or Exporting the final result
@@HeadsFullOfEyeballs
Wow that finance program dialog box is asking for problems. "Cancel transaction" and center it, then it at least can't be confused with close popup.
Also add a button labelled “Abort Cancellation” or “Close without Cancelling” or something. Relying on the tiny x is part of the problem here.
Still remember having a wrong-ends-of-the-stick conversation about "strings" with my wife
Try searching for something like "how does c string look like" on a fresh browser and switch to pictures for better results 😄
7:30 I hope these guys at the airport discover the white upwards pointing arrow on a blue circle background, and use it instead of the white line on a green circle.
Being the RTFM guy in our company, I’m surrounded by many “morons in a hurry”.
That’s me too.
And every time the moro… clients complain, I obsessively add to the fine manual refining the language, adding explanations to it and hoping that eventually, people will be able to read and understand.
Actually, I’m hoping that AI ingesting the docs will help answering the moro… client questions.
Whenever I'll see a pie explosion IRL (as in eatable pie) it will not be the same ever again.
I ended up with this problem last Wednesday. I needed emergency health care, and at first I tried to use a well-known "modern" provider, but in my state of pain I couldn't work out whether my request had been accepted or if they expected more information....So I called 112 since I was too confused and too scared to bet that I had overcome their too complex website. Turned out I had, and they tried to call back while I was on the 112 call. But afterwards I was thinking; How stupid are they not to test on people in extreme pain, inability to move properly, can't see clearly and so on?
I once expressed my annoyance with handles on push doors to a marketing bigwig who fired back: "That's an 'affordance' called a 'Norman Door', you need to read Don Norman "; so I did, as should anyone who cares about UX/UI.
It's all good until you hit UI strings translated automatically or without context.
Fun fact: this is even the case with the term "backup." It use to be that backing up the computer meant restoring an archival copy you made earlier, back in the days of punched cards and core memory. Makes sense, right? Then you went from archival copy to making a backup copy, to backing up being the act of *not* losing recent data on the computer.
I expect the backup term far predates computers, e.g. the role of "understudy" is a backup plan. Webster's lists backup 3 "A substitute held in readiness for contingent use", with examples "a backup plan" and "a backup quarterback". Etymonline dated it to 1767.
@@0LoneTech I'm not surprised. I was merely speaking of the computer usage. And of course there's "backup singers" and such as well. I wonder if it is related to a "backstop" holding up a facade or something.
Casting. That one was so obvious we all missed it.
1:26 What about "casting"?
I went from military in a non-tech role to software via a bootcamp (this was in 2014). Everyone wore flip flops. I thought deployments were when your company sends you out of town to work onsite with a client for a period of time. The thing that really threw me off though was Agile. The agile I was accustomed to was a polar opposite of Agile, which seemed to be an intentional hamstringing of developers ability to accomplish anything. The more appropriate term, if appropriation were unavoidable, was FUBAR. It still is
Really interesting and useful video. I'm probably going to pinch some ideas/concepts from this and incorporate it into my teaching for CompSci students. Should help greatly with game/web dev units.
The absolutely stupidest thing I've ever seen in UI design was, I think, on a button on my late, lamented Newton 2000. Some app required manual save, and this was accomplished by pressing a button with the outline of Texas and a question mark. Why? According to the manual, this is the “remember state” button.
I absolutely kid you not.
A close second was a bug, a requester on an Amiga that said “Are you absolutely sure you want to IRRETRIEVABLY DELETE all frbtnh;zfn;vjknfbsblfg7&%%$#-(((((~` THIS CANNOT BE UNDONE” followed by _seventeen_ [OK] buttons, not all of them placed within the window. Amazing what an Amiga could do with a stray pointer, it really was.
If I recall correctly, xfm had an absolutely excellent example of failing to consider this concern. As I remember it, it had a modal popup simply labelled "Quit?" with three buttons: Continue, Abort, Cancel. What's your guess of what each button meant?
the c# language design team has the concept of "pit of success" - if you try something the obvious way, that should be the way that doesn't have the pitfalls in it.
They have eg: refused to implement shortcuts for nested yielding iterators despite repeated requests, because accidently hiding a quadratic performance penalty is not something that the language should do
An example of the principle of least surprise. Do something obvious and the outcome should be the most obvious and least surprising of potentially many other possible outcomes. 25 years ago the software tools I worked with - libraries, frameworks, etc, adhered to this as a guiding principle. Today it's all Russian roulette.
"the c# language design team has the concept of "pit of success""
And the libraries and everything else around it try their darn hardest to invert that: doing the correct thing is neigh impossible to do by accident. You have to know everything to not fall victim to one of the thousands of traps they have layed out.
And even C# it self has many, refuses to add useful safety features and even refuses to acknowledge that problems exist (say no 'const' for local variables - that is a dangerous source of bugs).
Thank you. Your video put a smile on my face after a rather trying day.
A day after watching the video i really got one of those prompts where I didn't understand if cancel cancelled the prompt or the entire process
I learned covariance and contravariance in the context of tensors!
A big issue with "cancel" buttons is Microsoft Windows' (now mostly historical) overuse of plain "Ok/Cancel" dialogs, and still today 3rd parties making Windows software is often over using it too. Not only were they using too many generic confirm dialogs without custom text on the buttons, but they were all using _way_ too many confirm dialogs on really unimportant stuff in general, which have trained a whole generation of users to reflexively click buttons in confirm dialogs without reading them properly.
The problem with excessive confirm dialogs has improved somewhat in later years, being largely made redundant with autosaving and multiple levels of undo; but the fact that we still occasionally need to warn about drastic changes that cannot be undone it's still a big problem that there's millions of users who now instinctively dismiss confirm dialogs as an annoyance often not even caring which button they press.
This is especially bad with the those who are 10-15 years younger than me (those born in the earyly to late 90s); who grew up using computers with terrible software with too many redundant confirm dialogs often filled with technical language (which quite often wasn't even a language they could read at all, if their first language wasn't English); maybe they hadn't even learned to read yet so for them the dialogs was entirely an annoying distraction to be dismissed one way or the other. And since they probably rarely were actually using software that could do something really bad to your system (like disk formatting etc.), and since 99% of these dialogs were completely redundant "Are you sure you want to do the mostly harmless action of the button you just pressed" they probably almost never had anything bad happening whenever they just "dismissed" the dialog by pressing the "Ok" button.
So many times I've seen people in this generation just reflexively hitting enter or clicking whatever button on a dialog so quickly the text didn't really have time to render much less time enough to be able to read it. And then complain why the software isn't doing what they wanted, or complaining why their document was deleted (or rather not save). And I'm not actually blaming them; they have been trained extensively every day by bad software for a more than a decade to do so. Of course they do what they were trained to do!
At least older nerds like me who _did_ play around in disc format dialogs, and did completely break one or two systems back in the mean old days when OS'es was really unforgiving, at least have learned to read the dialog before clicking an option. Though we still reflexively choose an option, we usually realise how and why we messed up just after we click the wrong option, because we at least half-read the message.
I live by this concept. Software UI should be usable with limited or no tutorials where possible. If my mom can use it, it is probably OK
For those whose mothers are rather too good at figuring out inscrutable software, imagine she is using it and you want to avoid her swearing at it.
Agree that 'moron in a hurry' is the wrong way to phrase it. End users just shouldn't need to think hard to use your application if that is actually possible. And if it IS and you DON'T DESIGN IT THUS, who is the moron?
"Agree that 'moron in a hurry' is the wrong way to phrase it."
Why?
"End users just shouldn't need to think hard to use your application if that is actually possible."
Yes - and that is specifically the reason why it is called that: Cause things should be made in such a way that you'd need to actually be a moron in a hurry to not know what it is.
"And if it IS and you DON'T DESIGN IT THUS, who is the moron?"
So - you are explicitly telling us that such a designed FAILED the moron-in-a-hurry test................
So was that cancel button renamed to something more clear like "Cancel Transaction"?
🤣💚
“Idempotent”
Wot no Weebl reference?
Couldn't find my "We Am De Best" foam hat...
I think the test also applies to security matters sometimes, too. PKI fails, for example.
You better start running you videos through some kind of "Volume normalization in a Hurry" tests. My volume is at 100% on each side and I still can't hear a thing over my background noise
And the you then with "look out for context switches". Usually I don't have to, my computer is perfectly able to handle that on it's own.
Oh, you didn't mean computing context switching...
Audio is a little low in this. Useful otherwise!
What an amazing video! I'm surprised you don't have more subscribers.
Thank you! ❤️ As for subscribers - although I've had a UA-cam account for ages, posting these weekly videos is a new thing. We'll see how it goes. 🤠
I AM THE MORON IN A HURRY!!! ;)
Came here to say this
I, too, don’t particularly like the phrase ‘moron in a hurry’ . let’s not call someone a moron if he choose simply to give as little attention as possible to the app or website he is using
what other phrase might we use? . maybe ‘low-cognitive load user’? . I’m sure we can come up with something better . but essentially, the phrase we are looking for describes someone who refuses to give an app or website the amount of attention which is considered ‘reasonable’ . maybe ‘minimally-engaging user’? . idunno; ideas?
Just stick to moron and get on with your life...
"Moron in a hurry" passes the "moron in a hurry" test for explaining that UI concept! 😂 Really though, if you have people getting stuck in a UI, you can either moralize their attention span or preempt the problem. A lot fewer people's time gets wasted if you do the latter.
"let’s not call someone a moron if he choose simply to give as little attention as possible to the app or website he is using"
You failed to understand what the term actually means despite it being so simple that it would pass the moron-in-a-hurry criteria...........
"maybe ‘minimally-engaging user’? . idunno; ideas?"
Yes - such a term already exists. it is called MORON.
I got a good one: monad
...you mean a monoid in the category of endofunctors? What's the problem?
😉
exactly
5:44 I love that the "Cancel" on the Password dialog probably means "OK". And that there's no real way out except the X to close - which is a Windows convention, afaik
put a red circle on a white rectangle in portrait format and you have a British Rail stop board
Put a red circle on a white rectangle in fast forward mode and you have a beautiful splodge of red color. 😉
Sound is too low.
Dylan: "What is the capital of Norway?"
My Brain: "Holy f'ing epiphany!"
Language learning models. From toddlers to Terminators in a mere blink of an eye.
lmao, the pie explosion, thanks for making my day!
Little know fact - Amiga went with Amiga because it was ahead of Atari in the phone book 😁
That's an old joke told by Steve Jobs on why he chose the name Apple not Amiga. Besides Amiga was a computer, not the name of a company.
I'm told that this is also how Acclaim Entertainment picked their name: they wanted to appear before Accolade.
@@bobweiram6321 wrong. The Amiga was a company. The company was initially called Hi-Torro, and was later renamed to Amiga Corporation. They raised a bunch of money from some Dentists to work on the Lorraine (which later became the Amiga).
This was before Commodore acquired the Amiga computer.
Please go read the history of the Amiga - or ask those engineers who worked on the Amiga… I know a few of them (sadly several have died).
@@bobweiram6321 Joke? Why do you think their stock symbol is AAPL?
@Bobweiram6321 - you're wrong. "A final significant event that took place during 1982 is the company's' name change. In an attempt to distinguish itself from the Japanese lawnmower firm 'Toro', the company name is changed to 'Amiga Incorporated'. The reason for the choice of Amiga has become legendary - Miner wanted a 'friendly' name that would dispel the air of confusion that surrounds most computers. As the Spanish word for female friend, Amiga fitted this profile. The fact that it came before Apple and Atari in listings also helped. Although Miner was unhappy with the name initially, he soon realized the impact that it could have."
This all happened before Commodore stepped in and acquired the Amiga computer (the Amiga computer had a few names before it was called an Amiga... but that's a longer story)