Live data from Hacker News

Recognising a Bad User Interface at First Glance

hadermann.be

41–50 of 95 posts

Re: Recognising a Bad User Interface at First Glance

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

Re: Recognising a Bad User Interface at First Glance

#42

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…

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

Re: Recognising a Bad User Interface at First Glance

#43

A bit dated, but relevant: http://interfacehallofshame.eu/www.iarchitect.com/lotus.htm And its complement: http://hallofshame.gp.co.at/fame.htm

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

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

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

Re: Recognising a Bad User Interface at First Glance

#44

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…

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

No. It's the _only_ representation that makes sense and is easy to read everywhere. (Assuming you show it into the user timezone.)

Year -> Month -> Day -> Hour...

BIG -> Medium -> small -> smaller...

And because the year has 4 digits, you instantly know it's a year value.

There is nothing more infuriating than those silly "yesterday" "a week ago" and other cute time formatting. What if I wanted to know the precise hour, instead of a vague "yesterday"?

And don't get me started on the completely, utterly stupid "11/09/14". I'm French Canadian with many software configured halfway between US, Canadian and European standards. So when a software/website tries to be a smart-ass and gives me "11/09/14", It might be day-month-year, or year-month-day, or month-day-year. Yeah, fun times.

Re: Recognising a Bad User Interface at First Glance

#45
post #32

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Recognising a Bad User Interface at First Glance

#46
post #32

Earlier quoted context omitted.

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.

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.

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.

Re: Recognising a Bad User Interface at First Glance

#47
post #42

Earlier quoted context omitted.

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…

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 "2600". This comes from a strange combination of military time plus a historical tradition that days start at dawn. At least it's unambiguous.

Re: Recognising a Bad User Interface at First Glance

#48

Earlier quoted context omitted.

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…

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

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.

Re: Recognising a Bad User Interface at First Glance

#49

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…

I have a constant low-level battle in my company (not DHL) to try to folks to understand that we are an international company... and therefore their fields like "completed on" need a time-component, because not everyone has the same workday.

These are "product owners" who are themselves in satellite offices in other timezones...

Re: Recognising a Bad User Interface at First Glance

#50
post #42

Earlier quoted context omitted.

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…

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

I'd be a lot more OK if all "humanized" dates could be toggled to an ISO date with a button click.

It's so true though, if trying to scrutinize the history of a repo I find I frequently need to clone it locally just to access the info I need in any kind of decent interface.

Post reply on HN