> This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke".
Technical language where it's appropriate is fine. For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful.
Actually, I forgot about double-clicking which was everywhere on Windows. People would be confused about if single or double-click would do something different and when to do which.
> For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful.
What exactly is the point of an error message being "friendly"?
Does a sad cartoon face with an "Oops" in a speech bubble make users feel better? No. Not really. Because the user wants the thing to function, and if it doesn't, the user may want someone to help him, and if all that someone gets to work with is a little cartoon picture, that's not going to result in a happier user.
If there is an error´ in my app, I make it EASY for the user to see, copy and send it. Yes, I have written apps where an exception results in the stacktrace to be displayed in the actual app.
You know what these "unfriendly" errors caused? Countless very happy users, whos problems were quickly solved by knowledgable stuff who got actual error messages and stacktraces to work with.
> People would be confused about if single or double-click would do something different and when to do which
And did double clicks go away as a result? No. No they did not.
And btw. neither did Menu bars. We still have them. Only now, we have them IN COMBINATION with ribbons etc. and they are sometimes themselves hidden behin dsome element.
I mean friendly in the sense "Use human-readable language. Error messages should be plainspoken using legible and readable text (many writing apps can give you feedback on a message's readability). Avoid technical jargon and use language familiar to your users instead. The Web's most common error message, the 404 page, violates this guideline. Hide or minimize the use of obscure error codes or abbreviations; show them for technical diagnostic purposes only.":
> And did double clicks go away as a result? No. No they did not.
Double click has largely went away, yes. I see double click in desktop file managers still but it's mostly gone elsewhere. It never became a thing on touch screens because it's not discoverable (which is why it's not great on desktop either) and it's very rare to see in web interfaces. Related:
> Avoid technical jargon and use language familiar to your users instead.
The problem with that: Such messages are rarely helpful in diagnosing and actually fixing the problem, which is the point of error messages in the first place.
The 404 Error message is short, precise, and (unless the server misuses HTTP codes), tells me EXACTLY what is wrong: 404: Resource not found. The thing that the URL I entered denotes, isn't there.
That is a helpful error message. "Oh dear, oh dear, it didn't work." however, is a crap error message, and the only thing it accomplishes, is enraging both users and technical support staff.
> Double click has largely went away, yes. I see double click in desktop file managers still but it's mostly gone elsewhere.
Please do tell, where else was it used to begin with, where it no longer is?
> It never became a thing on touch screens because it's not discoverable
a) It never became a thing on touchscreens because there is no mouse on touchscreens
b) There were, and still are, apps that use double taps
> which is why it's not great on desktop either
Please, do tell, how would you differentiate, in a file browser, between marking an item, and opening an item?
Besides hidden scrollbars, do you have examples of lack of discoverability on touch screen? Any specific apps?
I can't relate to this to be honest, I feel confident on my phone that main features are either right in front of me via a tap and less common features are behind a visible menu icon. Think how much worse it would be if double tap and long tap were required for common workflows. Some apps do require gestures but they either onboard you or the gestures are optional.
> I can't relate to this to be honest, I feel confident on my phone that main features are either right in front of me via a tap and less common features are behind a visible menu icon. Think how much worse it would be if double tap and long tap were required for common workflows. Some apps do require gestures but they either onboard you or the gestures are optional.
Not my experience at all. Snapchat famously made their UI deliberately undiscoverable so that only people who made an effort would find all their features; I don't know if Instagram deliberately copied that or not but a whole lot of its functionality requires blindly tapping somewhere that's not obvious to tap or dragging somewhere that's not obvious to drag (e.g. going backward or forward in a story, messaging someone).
My favourite example is pasting a phone number into the dialer on Android: you have to long press on the blank white input, and it will only even show the context menu if you've got a phone number on the clipboard already. A couple of versions back it was worse: you had to long press in the correct half of the featureless white rectangle, otherwise it would just silently not work.
Technical language where it's appropriate is fine. For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful.
Actually, I forgot about double-clicking which was everywhere on Windows. People would be confused about if single or double-click would do something different and when to do which.