Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recognising a Bad User Interface at First Glance

hadermann.be

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Recognising a Bad User Interface at First Glance

#81

Post by 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."

Re: Recognising a Bad User Interface at First Glance

#82

Post by Flimm »

icegreentea wrote: post #37
ryukafalz wrote: post #35

Earlier quoted context omitted.

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).

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

Don't they use slashes MM/DD/YYYY rather than dashes in the US?

Re: Recognising a Bad User Interface at First Glance

#83

Post by paulojreis »

TimFogarty wrote: post #19
userbinator wrote: post #9

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…

Yes I'm shocked by how UIs dealing with very precise things sometimes use imprecise dating like "tomorrow". On the DHL website, if I am ordering a collection for a certain time, I have to choose if I want it for "tomorrow". If it's 23:00 BST from where I am accessing the website and I'm ordering the collection from a country in EEST, am I ordering the collection for one or two days from now? This kind of sloppy UI fr…

> This kind of sloppy UI from a company that does logistics (which is supposedly quite a precise thing) is utterly unacceptable.

Big corp's UX approach is almost always buzzword-driven, not customer-driven. :)

Re: Recognising a Bad User Interface at First Glance

#84

Post by dragop »

DanBC wrote: post #10

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

The web interface login page recently changed so first you type in your username, then have to switch to the mouse to click "next", then type in your password. (Perhaps not as bad as one website I know that disables tabbing between the two fields!)

Anyone know if there's a reason behind such a clunky interface change?

Re: Recognising a Bad User Interface at First Glance

#85

Post by 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.

Re: Recognising a Bad User Interface at First Glance

#86

Post by tectec »

Animats wrote: post #47
steveax wrote: post #42

Earlier quoted context omitted.

I really hate the "humanized" dates in the github website interface. "3 days ago" is not useful to me when I'm comparing dates.

Yes. Worst case is not printing the year, even for items which are from a previous year. ISO 8601 is the international standard on how to write dates and times. Get used to it. XKCD: https://xkcd.com/1179/ Japan has a strange tradition of dates and times such as 7-3 2530. Tokyo TV schedules have values like that. "2530" means 0130 on the next day. Businesses that close after midnight may give their closing time as "2…

I really like this idea. In fact just yesterday I was thinking about it makes much more sense to group activities that happen after midnight with the "previous" day.

Re: Recognising a Bad User Interface at First Glance

#87

Post by wongarsu »

dghf wrote: post #78
Aoyagi wrote: post #76

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

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

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).

Re: Recognising a Bad User Interface at First Glance

#88

Post by dghf »

wongarsu wrote: post #87
dghf wrote: post #78

Earlier quoted context omitted.

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

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…

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).

Re: Recognising a Bad User Interface at First Glance

#89

Post by 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. :)

Re: Recognising a Bad User Interface at First Glance

#90

Post by TheLoneWolfling »

thaumasiotes wrote: post #39
TheLoneWolfling wrote: post #27

Earlier quoted context omitted.

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.

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

For a quick example:

An owl connotates wisdom in many places - but in some parts of Asia it connotates stupidity instead.

Post reply on HN