Live data from Hacker News

Recognising a Bad User Interface at First Glance

hadermann.be

31–40 of 95 posts

Re: Recognising a Bad User Interface at First Glance

#31

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

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.

Re: Recognising a Bad User Interface at First Glance

#32

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…

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.

Re: Recognising a Bad User Interface at First Glance

#33

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

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.

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.

Re: Recognising a Bad User Interface at First Glance

#34
post #32

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…

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.

Re: Recognising a Bad User Interface at First Glance

#35
post #31

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

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

Re: Recognising a Bad User Interface at First Glance

#36
post #31

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

The average person from the US will assume that 2015-04-03 is March 4th, 2015

No country, including the US, uses YYYY-DD-MM:

https://en.wikipedia.org/wiki/Date_format_by_country

I'm a bit surprised that you "have had to program date-related code" and "have never heard of ISO 8601", because it is practically the standard for date formatting. I know non-programmers from different countries including US/UK/EU, and although they probably haven't heard of ISO 8601 either, they have absolutely no trouble understanding YYYY-MM-DD HH:MM:SS. This is a very small sample size and probably not representative, but I doubt many people would attempt to parse it as YYYY-DD-MM.

Re: Recognising a Bad User Interface at First Glance

#37
post #31

Earlier quoted context omitted.

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

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 in whatever format the current OS default is set to (or you can choose your own).

Re: Recognising a Bad User Interface at First Glance

#38
post #31

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

I'm not sure I can really speak to how the "average person from the US" would deal with 2015-04-03, but two data points:

1. Everyone I personally know would know that that meant 4/3.

2. 4/3 in US usage is April 3rd. As I understand it, it's March 4th in European usage, but you say they have no problem with YYYY-MM-DD. I tend to suspect that you sort of half-learned that "US dates are backwards from European dates" and then misapplied that lesson here.

Re: Recognising a Bad User Interface at First Glance

#39

Earlier quoted context omitted.

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

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.

Re: Recognising a Bad User Interface at First Glance

#40

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…

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

Post reply on HN