
Recognising a Bad User Interface at First Glance - amberes
http://www.hadermann.be/blog/134/recognising-a-bad-user-interface-at-first-glance/
======
userbinator
I agree with some of the points (like ambiguous icons and vague error
messages), but not all of them.

 _‘If you are an X, then you have to fill in Y and Z. If you are not an X,
please only fill in Z, unless Z=1, then you should fill Y too.’_

This could be simplified considerably: "Fill in Z. If you are X or Z=1, fill
in Y." Although I'm not surprised that refactoring boolean expressions is
something that a lot of people seem to have trouble with.

 _In some cases it can be better to have a more human, relative notation, e.g.
‘within the last hour’, ‘yesterday’, ‘next week’…_

Actually I really, _really_ abhor this style of date formatting since e.g.
seeing events all dated "yesterday" \- possibly on different sites - make
ordering/comparing them nearly impossible. Is ISO 8601 really beyond
comprehension for most of the population?

 _The user interface is totally empty when starting out_

Unless you mean _completely empty_ (as in devoid of any buttons or other
widgets), I don't think that's a bad thing. It's funny that it mentions adding
an explicit instruction "Click ‘add contact’ to add your first contact." when
the next point is "Visual clutter", since it could very well be the case that
the users are confused because after removing that "Visual clutter", "add
contact" doesn't even look like a button anymore! Incidentally, this trend of
"flat" UI designs is another thing I loathe.

Am I the only one who thinks it's rather sad that, despite society spending
great effort over the last few hundred years to improve literacy (which was
quite successful), we're now dumbing-down software to encourage basically the
opposite?

~~~
vitd
"Is ISO 8601 really beyond comprehension for most of the population?"

Absolutely! I have had to program date-related code, and I am familiar with
the differences between US and European date formats, and I have never heard
of ISO 8601 before today.

The average person from the US will assume that 2015-04-03 is March 4th, 2015,
while a typical person from Europe will assume it's April 3rd, 2015. You're
still thinking in the context of a computer programmer, not the context of a
user.

~~~
ryukafalz
I'm in the US and I've never heard of 2015-04-03 being interpreted as March 4.
I just see the standard interpretation as logical, since it's coarse (year) to
fine (day).

~~~
icegreentea
Well, on the other hand, 'customary' US order is MM-DD-YYYY based on how we
normally (verbally) say dates.

Honestly, its perfectly ok for an application to use whatever standard date
format - as long as its clear and consistent within the application - at least
in the context of North America, where everything is a mishmash of whatever
standards you can imagine.

Hell, .Net datetimes specifically allow you to output in whatever format the
current OS default is set to (or you can choose your own).

~~~
UnoriginalGuy
> Well, on the other hand, 'customary' US order is MM-DD-YYYY based on how we
> normally (verbally) say dates.

Like the 4th of July?

~~~
ycombobreaker
No, like July 4th. Or July 5th. Or October 31st. The 4th of July is a notable
exception, and the GP's point of how we "normally (verbally) say dates"
stands.

------
kazinator
Recent stupidity: UI asked for postal code (knowing the address being entered
was Canadian.) Without thinking, the user (not me) put it in as L6A 3Z3. When
the form was submitted, it was rejected with the field flagged in Red. the
error message said like "please enter the Canadian postal code in the correct
format, AnAnAn with no spaces." (AnAnAn? Cryptic to non-coders; the user was
baffled.)

Postal codes _are_ written with the space:

[https://en.wikipedia.org/wiki/Postal_codes_in_Canada](https://en.wikipedia.org/wiki/Postal_codes_in_Canada)

If you're already validating the format, how much effort would it take to
recognize and accept the common variant which has the space in it? A [ ]? in
the regex, and a strip spaces function call.

~~~
vitd
This causes me no end of grief. Credit card fields where you can't enter
spaces, phone number fields where you can't format the numbers like a phone
number. It's literally a few lines of code to pull out just the numbers! So
infuriating.

~~~
mgkimsal
we get store survey codes on receipts from a local store. "please go fill this
out online". OK.

On the receipt: 9873-435-289-6372-9983

Go to their survey page

"Please enter the survey code without the dashes".

WTF? Left hand, please meet the right hand.

~~~
kanche
Or when putting serial numbers: some show the input box separated by
dashes(maybe so that we put it correctly while typing.) But, when I try to
paste it in, either it just rejects or simply fills the first block making me
copy the sn block by block. If I could, I would have beaten those dialogue
boxes with a baseball bat.

------
andygmb
>Use of image-only icons/buttons that have no distinctive meaning

There's nothing worse than this, along with no alt-text on web pages. With
font-icons being so common nowadays, designers want to remove all text and
revert back to hieroglyphics.

~~~
userbinator
I've heard it expressed this way: "A picture is worth a thousand words, but
there are times when a single word will do."

~~~
woofyman
You don't have to localize icons which is a feature.

~~~
TheLoneWolfling
People think, naively, that you don't need to localize icons. And yet a lot of
the time icons _should_ be localized.

Or rather:

You can design an icon that doesn't need to be localized. But unless you
design for it, it very well may need to be localized.

Things like thumbs-up/down, any sort of animal icon... Even trash cans.

~~~
thaumasiotes
Do you have any examples of animal icons that should have been localized? I'm
intrigued.

~~~
NinoScript
🐉. (Dragons)

[http://utkin1.ru/sites/default/files/dragons.jpg](http://utkin1.ru/sites/default/files/dragons.jpg)

------
DanBC
EDIT: disabled zoom?

It's weird to me that Google fails, hard, on so many ui things.

Here's one example from the Gmail app on iOS, from the feedback screen.

[http://imgur.com/a/koKRb](http://imgur.com/a/koKRb)

The [done] button is where the [return] button usually is; and it's directly
over the [send] button. So if you don't notice that return is now done, and
tap it twice to get a new paragraph, you just sent your unfinished feedback.

I blame Google, but it could be Apple being stupid with the dreadful iOS
keyboard.

> possible to get a pretty good impression of whether the user interface was
> thought about or rather just an afterthought.

I'm sure Google spends a lot of time and money on the UI. Which just makes it
more frustrating to me. EG Chrome's (on iOS) address bar does not let you
select and copy an address until the page has nearly finished loading. And to
paste an url into the bar you don't tap the cursor but some mid-point of the
address box - except it's flat UI so you just guess where to tap. Items in the
burger menu take five seconds to become clickable.

~~~
kylebrown
> EDIT: disabled zoom?

Hah, the OP article does disable zoom. Disabled zoom is one of the frustrating
things lately about iOS apps. Every time I try to show someone older than me
something in a Skype chat, or (speaking of google) in a hangouts chat on the
iPad... they cant read it - "Hang on... let me find my glasses."

------
vincentbarr
> "Too much text/instructions"

I disagree that too many characters or too much instruction is a sign of a bad
interface.

For users trying to complete their desired task, an interface lacking
instruction/explanation will often cause lower task completion rates and
longer average task completion times than an interface with verbose
instructions. This is especially true for new users.

Don't get me wrong: I dislike wordiness and consider myself an advocate for
simplicity, minimalism, and concision – and that might be the author's
sentiment. However, while bloated instruction may hinder task completion and
user engagement, incomplete instruction will prevent it.

I believe more useful measures of good instruction are when it is presented,
where it is presented, and how well it is understood by users.

For example, a well-designed mobile app avoids a text-heavy interface by
disclosing the appropriate amount of instruction at the appropriate time.
Limited screen real estate happens to be a handy constraint in this case, and
transfers more instruction responsibility onto a well-designed onboarding
wizard. That wizard will really only get one shot to educate users, usher them
to their 'aha' moment as quickly as possible, and hold their hand through the
few actions that strongly influence successful user engagement and retention.

~~~
asdfas123414
You are absolutely correct with your description of the user interface
principles you espouse. Provide the right help information at the right time
but otherwise stay out of the way.

However, I believe the author's sentiment was more focused on situations where
programmers use instructions to avoid more complex display or validation
logic. IE, less work to add some text than to properly display/hide form
sections based on skip patterns.

"If you are an X, then you have to fill in Y and Z. If you are not an X,
please only fill in Z, unless Z=1, then you should fill Y too." This is
typical of programmers being ‘smart’ by avoiding some extra steps/code...

------
thoman23
These are always useful reminders. It's easy to get so lost in designing a
system that you forget the perspective of the user, which is what really
matters.

One of my current favorites is Rocksmith (guitar learning software), where
upon exiting you are prompted with "Do you wish to continue? Yes/No". You as
the user need to essentially state, "Yes, I would like to continue...exiting
the program". This is right next to another menu option that I sometimes
accidentally select which prompts me to "Quit", which in fact just brings up
the "select profile" screen. It does boggle the mind how some things like this
get all the way to production.

~~~
reagency
Apple's HIG from THIRTY years ago say to not use Yes/No in dialogs.

~~~
dragonwriter
The real problem wasn't just Yes/No, it was "Continue" to mean Exit (Continue
exiting). Which would have been just as bad if the verb from the question were
pushed into the options, as "Do you want to continue? <Continue> <Stop>",
where "Continue" still means, as in the question, "continue exiting" and
"Stop" means "stop exiting".

"Do you want to exit? <Yes> <No>" would improve what was presented, though,
yes, "Do you want to exit? <Exit> <Don't Exit>" would be better. But it was
the _question_ more than the manner that the _responses_ were presented that
was the problem.

------
zamalek
I mostly agree, however one point I disagree very strongly with is the first:
_An Excel /development IDE – like user interface_

IDEs are horrible, horrible examples of interface design I can easily agree
with that. However,

> Excel is the most unconstrained application most people know, and a lot of
> software starts out as an Excel sheet before growing up into ‘real’
> software.

Usability comes first and foremost. If most people are familiar with Excel
that means that the Excel interface language is a good language (if not the
best). I don't care if it doesn't sate the desire for an "elegant" user
interface. The fact is that nearly all users already know how to use the
interface and are extremely proficient with it: what more could you possibly
want out of an interface? Scrolly fiver-finger gestures and other complete
shit that you don't need? YAGNI.

We make huge sales based on usability. Our bigger customers have historically
placed us into a competition during our initial sales pitch. If the sale ends
up in that situation _we always win._ Why? Because by the time customers are
using our software to build toy/test solutions our competitors are still
training the customer. Why? Because usability comes first and foremost,
because our UX guys don't let pet peeves about Excel get in the way of making
great and usable interfaces.

If you can "unconstrain" your solution enough to make it fit into a
spreadsheet then I say, "go for it."

------
nathan-muir
The Design of everyday things [1] (Found on Coding Horror's recommended
reading [2]) was crucial in understanding how people intuitively interact with
the world around them - including your web application - based on the visual
cue's you provide.

While this article provides some metaphorical fish - I found the Design of
everyday things helps you become a fisherman.

EDIT: Swapped the order of references.

[1] [http://www.amazon.com/Design-Everyday-Things-Revised-
Expande...](http://www.amazon.com/Design-Everyday-Things-Revised-Expanded-
ebook/dp/B00E257T6C)

[2] [http://blog.codinghorror.com/recommended-reading-for-
develop...](http://blog.codinghorror.com/recommended-reading-for-developers/)

~~~
kylebrown
Your reference [1] confused me because most of the books I saw were about code
and design patterns, or books by Tufte. I also didn't realize what DoET meant,
on first glance.

~~~
nathan-muir
Fair enough. I've reworded that part.

------
paulojreis
Well, this is nothing new. It's called heuristic evaluation and it's been
around at least since 1990 [1]. Almost every item in the article's list maps
to a simple and well known heuristic.

It's very strange (or sad) that the author doesn't mention heuristics in his
post and talks about his conclusion as something "new": "it dawned on me that
a trained eye can often spot unfriendly software a mile away." It may have
"dawned on you", but it's nothing new.

It never ceases to amaze me, how oblivious of basic usability the people in IT
are.

[1] Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user
interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April), 249-256.

------
dogweather
This feels like one of those articles that the people who need to read it
never will; developers who don't care to improve their craft, and are churning
out software to check off some box in a list of features demanded by
management.

------
mikehawkins
I agree... especially with the comment about terse and unclear error messages.
I recently got lured into the customer-facing side of things, and nothing
annoys me (or our new users) than a message like "Incorrect syntax" when I
used a unsupported symbol for my password.

First, be clear with your design and instructions. In my hasty password
example - "Please create your password (6 or more characters, letters and
numbers only)"

Then - if the user messes up, explain a bit... "Whoops, please only use
letters and numbers"

So, so much nicer. :)

</rant>

------
vlad
A great user interface is dangerous when it's disconnected from the internals
of the software, because the user starts to feel the software "is only
pretending to be nice" and is fighting against them.

When an app loses hours of your work, you start to wish you used an app that
took more clicks to use but actually focused on the internals.

I'm making daily videos at Rate My App (.com) and the latest version of
ScreenFlow 5 (screen capture software) is known for the best user interface,
but in fact impossible to feel safe recording even the most basic videos with.

\- Forces you to delete your videos with endless prompts or forcefully shut
down the app if you do a File -> Rename...

\- Let's you record a new project but will not actually save it if it recently
had an issue (above), so you lose that one, as well

\- Does not explain that clicking Remove in the infinite prompt actually
deletes all the video content. Does not backup for you, either

\- Doesn’t always show YouTube categories, but allows you to click Start
Upload, in which case the uploads remain in the upload queue forever. Issues
or errors with video sites are not mentioned, the upload just stays in the
queue.

\- Warns about uploading videos greater than 15 minutes long on YouTube even
though you’re exporting a 5 second range

\- Their most important feature, video actions (keyframes) don't work.
Modifying one randomly modifies another one, so I stopped using it. This was a
major bug until it deleted a 1.5 hour project of mine. Now, it seems minor.

------
TheLoneWolfling
> Unneeded use of separating lines, grouping boxes,.. less of these = easier
> on the eye.

I seriously disagree with this particular assertion. I find that "flat" design
trends make things much _less_ usable, and this is no exception. It is far
easier to group things with visual references than with lack-of-visual-
references. And it is far easier to find things like buttons if there are,
say, actual indications that they are buttons.

~~~
sopooneo
There's a balance to be struck. The pendulum may have swung too far towards
the minimalist, but it used to be much more common to have lines and boxes
around everything, where simply removing them and leaving open space made the
layout _easier_ to quickly grasp.

~~~
TheLoneWolfling
Maybe. But if so, this mythical "open space makes things easier to grasp"
unicorn has failed to show its face to me even once.

And, one other thing. Layouts that have too much delineation degrade _much_
more gracefully than layouts that have too little.

------
taspeotis
A bit dated, but relevant:
[http://interfacehallofshame.eu/www.iarchitect.com/lotus.htm](http://interfacehallofshame.eu/www.iarchitect.com/lotus.htm)

And its complement:
[http://hallofshame.gp.co.at/fame.htm](http://hallofshame.gp.co.at/fame.htm)

~~~
steveax
We really have gotten better (and expectations are higher). Remember the
abominable multi-row tab control dialogs common in Windows apps [1] shudder.
Does anyone remember Debabelizer? [2] Really amazing piece of software with an
interface that, ummm, well, here's the batch catalog setup dialog [3]

[1]:
[http://interfacehallofshame.eu/www.iarchitect.com/tabs.htm](http://interfacehallofshame.eu/www.iarchitect.com/tabs.htm)

[2]:
[https://en.wikipedia.org/wiki/Dave_Theurer](https://en.wikipedia.org/wiki/Dave_Theurer)

[3]:
[http://pangram.org/images/debab.gif](http://pangram.org/images/debab.gif)

~~~
reagency
What's wrong with 3? It has a lot of options because the user needs control.
They are well organized.

------
chatmasta
> The user interface is totally empty when starting out. When seeing a ‘clean’
> installation or account, there are no instructions to get you started.

This is such a big problem, and such low hanging fruit, it sucks to see
products fail to implement proper onboarding. I understand why... writing user
interfaces is a pain in the ass. Onboarding is usually done after "finishing"
the code (of course the code is never actually finished), so generally most
programmers are probably so exhausted after writing the code that implementing
an additional onboarding process seems like too much trouble, because "JUST
SHIP IT!"

It's like the programmers do 95% of the work, then stop caring about the last
5%. But it just means that the 95% goes to waste.

------
Aoyagi
What? Isn't "2015-06-29 15:44:21 EST" the ISO format? Can't think of anything
more relevant.

~~~
dghf
ISO 8601 format would be 2015-06-29T15:44:21-05:00.

~~~
wongarsu
Replacing the T with a space is explicitly allowed by ISO 8601 if context
makes it obvious that the date and time belong together. I prefer the version
with space for many purposes since it's easier for humans to parse at a
glance.

You are correct that time offsets are used instead of timezone names. The most
obvious reason for that is that many names are ambigious (EST is either UTC-5
or UTC+2, depending on whether you live around the US or around Egypt).

~~~
dghf
Point of pedantry: RFC 3339 allows replacement of the T with a space; ISO 8601
merely allows its omission (and that only by mutual agreement of all parties
to the information exchange).

------
baddox
I've never heard the term "hallway testing" before, and I'm assuming I'm
inferring its meaning correctly. I'll be using it in the future.

~~~
icebraining
Why assume when there's Wikipedia? :)

[https://en.wikipedia.org/wiki/Usability_testing#Hallway_test...](https://en.wikipedia.org/wiki/Usability_testing#Hallway_testing)

------
tinbad
Not saying this is a bad article but the 'first glance' part seems misleading.
There's lots more to read than the title suggests.

------
vixsomnis
As someone who hasn't worked in the software industry yet, stories like these
are beginning to horrify me. Is the bar really this low?

~~~
kazinator
Yes -- but only by default! If you go to Tools -> Page Setup -> Zoom ->
Sidebar -> Tweaks, and then click on [+] next to Polling Interval to expand
the box, a "Bar:" property appears, where you can enter a lower number to set
the bar lower. Or just use the arrow buttons next to the field to increase or
decrease it. (But note that if you already typed a number, and then use the
buttons, it increments from the old number that was overwritten, not from what
you typed. (Bugzilla item dating back to 2006, status UNCONFIRMED.))

------
anigbrowl
_On the other hand, developers have a knack of seeing everything as the user
interface they’re most familiar with: their development IDE._

Along with the bizarre idea that the best interface of all is one that forces
the user to write code of their own. Look folks, if everyone wanted to type
then text adventures would still be top of the video game charts.

~~~
icebraining
Yet text chats are much more popular than videochat. Typing makes sense in
some situations, and not in others. What works in videogames is not
necessarily adequate for other UIs.

------
elektromekatron
Shotgun full of buttons is your standard coder designed UI.

Many of the common alternatives are worse though, I prefer a shotgun full of
buttons to many of the supposedly simpler systems unless they are very well
thought out.

Good UI is very hard.

edit - to me, really good UI is simple shit like things that gather system
stuff, then install while gathering user stuff. When that started coming in as
standard with many linux installs, I almost wept ;)

