Live data from Hacker News

Open Letter to sites with annoying interfaces

bitonic.org

11–20 of 79 posts

Re: Open Letter to sites with annoying interfaces

#11
post #2

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

Yes, absolutely so. Amazingly, iReader, from Apple, for the iPad, uses this antipattern in the critical main navigation bar! It disappears instantly and one has to click randomly at the top of the screen to get it to reappear, then try to press the tiny button that takes you back to the table of contents before the whole thing rolls up again after a delay of a second or two. Very frustrating. This sort of nonsense is bad enough when one has to hover with a mouse. But when there is no hovering available on a device and one finds key interface elements are invisible and must be unhidden by clicking randomly, one must wonder what sort of monkeys they got working there, or at least what their background in UI design is.

Re: Open Letter to sites with annoying interfaces

#12
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.

Re: Open Letter to sites with annoying interfaces

#18

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 applicati…

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.

Re: Open Letter to sites with annoying interfaces

#19
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?

Re: Open Letter to sites with annoying interfaces

#20
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.

Post reply on HN