
Open Letter to sites with annoying interfaces - Queue29
http://bitonic.org/blog/?p=176
======
droithomme
Thanks so much for this article. Hidden interface elements that only appear
when hovering over a secret spot like it's some kind of easter egg is one of
the most frustrating things I have seen. It's not really user interface
_design_ so much as it is user interface _abject failure and total ignorance
of how interfaces work_. I refuse to call anything so dysfunctional design!

This has been sneaking into desktop application interfaces also for about 5
years now.

There's no problem with it in a video game where you are finding a secret
passage, or it is an easter egg that is of absolutely no consequence whether
anyone finds or not.

But for critical functionality it is inexcusably and is so offensive to
concepts of usability that any "designer" using this technique in software for
basic functions should be identified and blacklisted from industry.

What is the affordance of invisibility? There isn't one.

~~~
stephth
My work involves designing interfaces and this discussion could help me
understand this topic better; but like the author of the article, your post
shows some intense frustration towards rollover-only elements, but none made
it very evident to me as to why it's so frustrating and why it's so "stupid".
We all experience things differently, and I'd love to picture a perspective
where it's so frustrating.

Here's how I see it (and as you'll see, I'll be taking various assumptions.
Please feel free to tell me I'm wrong (but make a case)):

We like to have everything at hand, but we also like (it's more like a need
actually) to _focus_. Too many elements are a distraction. That's basically
why we put things in boxes even if we don't intend to transport them anywhere:
out of our sight. Our brains want/need to focus. That would be my answer to
your question "What is the affordance of invisibility?".

The example of Google - if that really is a delete contact button, I don't use
that app - I would agree is bad design, because its effort to find it
outweights the benefits of having it hidden (partly because its placement is
not apparently logical and that makes it extra hard to find).

In the first example in the article (github) however, I would tend to think
that that specific solution is OK. The author of the article forgot to explain
what that button does. A quick look at github, a rollover and a click (three
actions) shows me that its function is it edits _the description of the
repository_. How often do you edit the description of a repository? Not that
often. Probably very rarely. And the more you use github, the smaller its
usage gets proportionally to the rest of the app. The day you need it, you'll
find it relatively quickly. Because you've experienced this practice for a
while in other sites, and even more so because you've seen github act like
that every now and then. Your brain is able to predict that if you don't see
it, it might very well be rollover-only. The first logical place you try is
the _within the repository dashboard, over the description of the repository_.
Not too hard. I think in this case the benefits of _every time I read that
page not having that element there and not having to neutralize it myself with
my brain by ignoring it_ vastly outshine the effort of _looking for it when I
rarely need it_. It's a good deal. [1]

I would love to understand a little more about why this concept didn't work
out for you.

 _edit: typos, formatting and deleted some unneeded parts_

\--

[1] The github element in the case of a touch interface is not great, I would
agree, because it's harder to _predict_ that by _touching_ the white area of
the description the button will show up. But it works (as in: you can still
access it). And you have to cut interface designers some slack (or instead
give us the strength we need): we're still trying to figure out what to do
exactly with the current mess of having two very different types of clients
(mouse and touch) accessing our web interfaces. After we figure out _if_ we
should unify, we need to figure out _how_. Killing rollover interactions might
be a necessary casualty in that road (but that would make part of me sad,
there are wonderful usages of rollover, see for example the custom sliders in
here: <http://worrydream.com/LadderOfAbstraction/>), either way I'd love to
understand a little more, and I assumed that in this discussion we're focusing
on rollover, not touch.

~~~
dvdhsu
I don't know anything about design. The solution that I propose seems obvious
though; am I missing something?

> _Too many elements are a distraction._

> _What is the affordance of invisibility?_

There is a middle though: instead of either making it invisible OR cluttered,
couldn't you just design it with a small clue, such as an arrow, which would
open a drop-down menu when rolled over (on a computer) or tapped on (on a
touch device)?

A drop-down menu with a small icon to prompt the user would hit the middle
between simplicity and obnoxious prompting.

~~~
ZenPsycho
That's just hiding functionality again. MS started doing this by hiding vital
functionality in a stupid looking windows logo jewel in the upper left hand
corner. I had to ask other experienced people where the file menu was- it was
not obvious that thing was anything more than decoration.

The solution to clutter isn't to hide functionality. It's to have your
software do /less things/. If you need it to do more things, make those few
things your software does a flexible set of tools that can be combined in
novel ways.

Update: (I got downvoted so I thought I'd modify the post a bit, hopefully
it's better?)

in any case, when it comes to software design, clutter isn't the worst thing
software can do. Hiding things is, however, pretty close to the worst thing
you can do. At least, without a consistent and obvious method of discovering
the hidden things.

~~~
droithomme
I liked the first post! The bit you removed: "Now you have two problems" I had
just pasted it into my quote file, so it's not gone. I'm going to bring it
back because it is a stylish way to say a lot. Ok I'll fiddle with it a bit
too, play at being an editor.

> When it comes to software design, clutter isn't the worst thing software can
> do. Hiding things is. So, to paraphrase JWZ: "You have a problem with
> clutter, so you hide it. Now you have two problems." Thus, the solution to
> clutter isn't to hide the functionality because that creates more problems
> not less. The solution to clutter is to have fewer functions.

That's really good. Some reading this might be confused by fewer functions as
meaning dumbing down and restricting the user, so let me expand that. That's
not what it is. Fewer functions means making things simpler to the point that
they are generic enough to have much more functionality, but with fewer
explicit functions. For example, the unix command line is pretty simple to
look it, but unlimited in what you can do. Type whatever you like there. The
pipe thing lets you stitch things together in combination.

~~~
thomaslangston
"Now you have two problems" is a common meme used to talk about a lot of
computer programming decisions. It appears to be originally meant as a comment
on regular expressions.

<http://regex.info/blog/2006-09-15/247>

------
modeless
That _isn't_ the "delete contact" button. Did he even try it? The "delete
contact" button is in the toolbar, which makes perfect sense. The trash can
next to the name field simply clears the name field. So why not always show
it? This is not just the "edit contact" screen, it's also the "view contact"
screen, and cluttering it up with trash cans next to every field would
absolutely detract from the scannability of the page when you're not editing.
Why not have separate pages for viewing and editing? That's bad for usability
too; it invites mode errors.

~~~
mitjak
And right there you define where you should and shouldn't use roll-over based
UI elements: if a UI element is only useful as part of interacting with
another, then hiding it in other situations makes sense (e.g., clearing a text
field as part of editing the text in the field).

------
po
I have always called these interfaces 'scrubbing interfaces' and I believe
it's a well known anti-pattern. It used to be popular with flash programming
and design-heavy sites that didn't want all of those 'ugly controls'.

Here is my rule of thumb: avoid attaching functionality to the hover event.
Visual effects/indications are fine.

~~~
droithomme
I agree. I hadn't heard that term. There's a related anti-pattern called
Mystery Meat Navigation.

<http://www.webpagesthatsuck.com/mysterymeatnavigation.html>
<http://en.wikipedia.org/wiki/Mystery_meat_navigation>

Mystery meat was weird looking inexplicable icons that you had to click to
find what they do or hover to get a description. Sometimes, including in both
those references, they extend it to be cases where the inexplicable icon
doesn't even exist and a description is invisible until hover. The hover
patter, what you call scrubbing, seems to me to be related to but different
from mystery meat, which is characterized by seeing a navigation element and
saying "What on earth is that supposed to be?"

------
marknutter
Putting hover-revealed controls on elements users interact with often is
perfectly acceptable. Throwing every single control on the interface,
regardless of how often they are used, is bad design and it overwhelms non-
techie users.

------
geuis
I'd like to add 2 other sites to this list with _horrible_ mobile interfaces
that frequently show up on HN.

extremetech.com and geek.com

Extreme Tech's mobile site is totally unusable. They have a very crummy
interface, instituted with javascript, that overrides the simple scrolling
ability built into the browser and overlay it with a system that tries pseudo-
pagination. If they would simply get rid of their attempt at a clever
interface and just display their actual site, there wouldn't be a problem. If
any Extreme Tech developers are reading this, please fix your mobile site.

The 2nd culprit, geek.com, crashes Mobile Safari. I'm on an iPhone 4. Because
of whatever you are loading on your mobile site, it freezes the browser for
upwards of a minute. Half the time the browser crashes before its done
loading. Please, fix that too.

I actively avoid reading any of those sites, since I read HN from my phone
about as often from a regular browser.

Another more generic complaint are to the people who use position:fixed on
their sites to create headers and side navigation. Guess what, on mobile
devices _these don't scale_. What ends up happening is that I need to zoom in
to read your text, but then 3/4 of the screen is covered with your nav menu.
Please, stop doing that.

Test your sites on mobile browsers. Its easy. Take the one in your pocket out
and try your site. I'm not even advocating extensive dedicated testing. Just
try it out like a normal user does and make sure it works most of the time.
These are things that are so horrendously, obviously bad that I don't know how
they _ever_ got through any reasonable kind of QA.

 __Edited for excessive usage of caps. Sorry.

~~~
radagaisus
position: fixed; is long as you use percents. Thing is position: fixed doesn't
even work on iOS: <https://gist.github.com/1196262>

~~~
geuis
position: fixed was added in iOS 5. However, it becomes unstuck when
pinch/zooming.

~~~
pferde
This kind of problems amazes me. It's year 2011, almost 2012 - we should have
had flying cars and forcefield doors by now. Yet we are still struggling with
getting a web page to work identically in different web browsers.

~~~
YuriNiyazov
I am willing to bet that when we have flying cars and forcefield doors, there
will still be problems of this kind in "information management", or whatever
name you want to give to the problem that the web tries to solve.

------
latchkey
I agree!

Here is another semi-close example. Not about hovering, but how about needless
hiding of important user experience?

<https://github.com/mozilla/browserid/issues/797>

I filed this super minor issue in the browserid issue tracker and it was
closed with 'as designed'. No feedback as to why it was designed this way, but
it sure seems silly to me to hide the 'remove' button under an 'edit' button.

I can understand this on a UI like an iPhone, but on a web page?

Oh well.

~~~
skore
Wow, that's just silly. I agree - "Delete" is simply not a subset of "Edit"ing
an option in a configuration. It may be a subset of editing the entire
configuration, but having a two-step process that makes a non-connected action
into a child action is mind boggling. People need to learn their CRUD/BREAD
better.

~~~
latchkey
Interesting that you write 'Edit' vs. 'edit'...

Here is another issue I just filed last night:

<https://github.com/mozilla/browserid/issues/809>

tl;dr: Super minor, but the case of buttons is actually important UX too.

I'm worried about BrowserID UX because we are implementing it on our site as
an additional login system along with Facebook Connect. I'd love to see
BrowserID become successful since we need an alternative to Facebook and
OpenID is a train wreck. But, I worry that with bad UX, it will remain just an
unused interesting idea.

~~~
skore
Yeah, but I'm probably just used to it and since I was referring to BREAD, it
kind of made sense. I guess it's one of those age old questions like "do we
say 'your' or 'my'?".

------
WhatsHisName
I agree. Google seems to have replaced the concept of "Simplicity is best"
with a misconceived notion about elegance. I don't want to search for hidden
buttons just to log off, or delete, or open, or save changes. I just want to
get things done and move on.

------
hub_
And good luck discovering these with a touch screen interface. People always
forget that one.

~~~
rwmj
HN isn't that great on a touch screen either. I guess pg doesn't use a tablet
because the comments link is too small and awkwardly placed for a finger.

~~~
omaranto
I've become very adept at zoom&tap. In fact I probably do it about as fast
postioning the pointer with my laptop's trackpad. I agree it'd be nice not to
have to zoom before tapping.

------
radagaisus
It made me both LOL and think. We are doing a snazzy crazy UI in the admin
panel. But the thing is, we don't want people to use it. That sounds strange,
but we optimized our convention, and we do allow people to configure stuff by
themselves, but we don't want to motivate them to do so. An input field is
crying for you to put something there. A little edit button in the corner not
so much. And the added bonus is that we can hide all those ugly forms until
they are really needed.

Also, think about an experience that was the exact opposite of this post. You
thought about something ('where is the delete button?') and you 'gambled'
where that button will show up, or what touch move you should use - think how
awesome the filling was when you were correct.

------
buster
Strongly disagree with the article. you have to ask yourself: How often are
you searching for a contact and want to edit it and not only view it? On
average, most people won't edit it, so it's useless to have an edit button 90%
of the time.

I think it's a pretty neat solution. The poster only has to get accustomed to
21st century technology, it's not 1990 anymore with textfields and buttons all
over the place. It's like the typical rant of an old grandfather, complaining
that something has changed and that everything was better decades ago.
Bullshit. Just be a bit more flexible.

The placement of the hidden edit button can be discussed though. I am
wondering why the github button is so far away from the content to edit...

Another example: The G+ profile editing is one of the best i have ever seen.
It's "this is how your profile looks like to another person, hover the field
and edit it". It's just easy and it's change something where it is shown, not
going to another page and edit some values and go back and forth to see the
changes.

------
phillco
The GitHub example used to be better designed in that the "edit" link would
appear right next to the text. So, you'd the see the repository title, move
your mouse over it, and hey! see how to change it.

With the button all the way to the right, that connection is somewhat lost.

------
jeffool
Tab. The tab key should first take me to the most important clickable (or
text-entry) part of your page. If you don't do this... It's not the "I'm not
angry, I'm just disappointed" routine. It's both. I'm both angry AND
disappointed.

------
bozho
This 'hiding' makes sense with lists of items, each of which has the same
options. You wouldn't want to see 30 identical delete icons, it would be ugly.
There are two important examples. Twitter hides the actions buttons and
facebook doesn't.

Twitter uses icons and media-poor tweets. So having the actions invisible is
the best way to go, otherwise the UI will be too cluttered with actions.

Facebook has wider spacing, more graphics in the post itself, and its actions
are text-only. That's why they can be visible - they don't distract you from
the content.

So I wouldn't say having invisible actions is bad. It's just not always good.

------
jmilloy
Please. The first example is for editing the repository description, and
becomes visibile when hovering over the description. The second is for
clearing the name field, and becomes visible as soon as you are actually
editing this field. I agree that hidden interface elements should be used
carefully, but if these really are the best examples you've encountered, then
it's not really a big problem. I wouldn't even consider the second "example" a
hidden interface element.

------
randall
Mystery meat nav (and bad design) is what I call it.

------
kjhughes
On the one hand, it's better to reduce clutter for the less common case of
editing rather than reading. On the other hand, it's better to indicate
availability of functionality without requiring hovering.

What do you think of a modal solution whereby individual editing interface
elements are shown collectively only when the user indicates editing intent
through a single, master control?

~~~
droithomme
Personally, I like those. I assume you are talking of the interface on some
sites with let's say a user profile and there is a visible [EDIT] button in
the upper right. Click on it, and all the nice formatted readable content is
replaced with editable text elements that can be tabbed through, and these
might have formatting bars in them or section delete buttons. Different from
the discussed scenarios where basic functions are hidden and one must move the
mouse around to different places to see if they may or may not exist, which is
bad and smacks of video game treasure finding design, which is fine for video
games and absolutely not fine for other applications. With the proposed [EDIT]
design it is quite clear what is going on by examining the page visually. A
related issue would be that the same profile viewed by other than the owner of
the profile would show no [EDIT] button at all, nor would such button appear
to them under any circumstances. No features hidden because for non-owners,
there is nothing to edit.

------
sunchild
I've always thought that reveal-on-hover controls makes perfect sense when you
present a list of similar things. In that case, showing one edit button, one
delete button, and possibly a detail button is too much noise.

My basic rule is, if there's more than one or two of the same control, then it
should be hidden.

~~~
pferde
Yes, hidden, but with a visual clue (small arrow, button with an ellipsis)
that clearly says: look, here are additional controls relevant to this part
you're looking at.

------
jv22222
The iOS interface is full of this behavior. I thought that was part the reason
why it was so clutter free and easy to use due to less clutter.

------
SquareWheel
I find the behavior can cut down on clutter when pulled off correctly, though.
Twitter offering context-based actions, for instance.

~~~
enjo
I'm not sure I agree. It completely breaks on tablets for one thing.

~~~
masklinn
Does not have to though, Tweetbot's UI behaves nicely in this regard. It does
not have hover, but its equivalent is to tap a tweet. This opens a small
"drawer" of 5 tweet-specific buttons (reply, retweet, favorite, detail and
"actions", which include posting a link to the tweet, copying the tweet's
content, emailing the tweet's content and translating the tweet's content).

------
lailsonbm
Users, always them… My reaction? Meh!

------
its_so_on
I didn't read this carefully, but it seems that "hidden" interfaces that pop
up during a mouse hover and so on are a main objection.

Well, I must say, that often when using a web app, I expect to have to wait 5
seconds for a reload as I am moving my mouse in for a click (for example,
imagine if there is a text link "Rate this page" under the current average
rating) -- when, instead, as I hover over it it turns to 5 empty stars
immediately, so that I have just saved 5 seconds for a page reload, I am
immensely delighted.

Basically, I do agree that hidden interface elements are awful. At the same
time, every "second page" that you would normally have to wait for is far
better as a 'hidden interface' that pops up right away!

I dare say that when you wireframe out the possible pages of your web app, the
_very best interface_ might be having most of those pages right in the main
page, just hidden. Report feedback, report a bug, reset your password, all
these things that would require a page reload and losing your scrolling in the
page and so on, can be brought 5000 ms closer to the user but putting them in
right at the point of the click.

So, I do agree that there is nothing as frustrating as a hidden user interface
element. However, you can also pleasantly delight your user by bring the 'next
page' right there.

------
funkah
"Open letter to sites with annoying interfaces"?!

Maybe I'll write an open letter to traffic. Or an open letter to waiting in
line at the post office. Or an open letter to humidity.

------
johndoe1234
This is so true. I look forward to Web3.0 through...

