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

UI Design Dos and Don'ts

developer.apple.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: UI Design Dos and Don'ts

#101

Post by tacone »

kagamine wrote: post #83
b15h0p wrote: post #81

Earlier quoted context omitted.

A double tap on the minute picker switches between 1- and 5-minute increments, afaik.

That's a perfect example of "Apple thought of everything" except how well that feature is hidden from the user. I mean, who was the first person to discover that? And I'll bet money it was by accident.

To get simplicity sometimes you have to remove features, sometimes there's no way around it.

When you face the choice, to hide a feature instead of removing it altogether can be a good compromise. So it can be still discovered casually, it can spread by the word of mouth, blog posts, and of course the user manual.

When selecting text, would you, for example, put select-word/select-line buttons everywhere a text can be selected or just let people discover what triple click does?

The topic is debatable, I just wanted to say that this kind of choice does make sense to me, and probably many others.

Re: UI Design Dos and Don'ts

#102

Post by coldpie »

kagamine wrote: post #97
coldpie wrote: post #88

Earlier quoted context omitted.

> Grey text on a white background is generally accepted as easier on the eye/mind when reading sentences This sounds like wives-tale baloney. Please disregard this "advice" and make your text readable. The text on this page from Apple is too low contrast.

Feeling a bit confrontational today are we? Call it what you will, but this is "generally accepted" which means exactly what it says. You seem to have confused "this user's opinion" with "what the textbooks say". Still, I'm open to hear about all the UX books you have read.

You don't need to read a textbook to see users complain about it, or to know that I go out of my way to fix low-contrast webpages to make them easier to read. Poke around elsewhere in this thread. Check out http://contrastrebellion.com/ >.

Re: UI Design Dos and Don'ts

#103

Post by coldpie »

TuringTest wrote: post #94
coldpie wrote: post #89

Earlier quoted context omitted.

> I've been forced to place a "Contrast" bookmarklet on the toolbar of all my browsers Could you please share these? I'm not web-programming-savvy enough to make anything that'd be generally useful.

I didn't make it myself, I found it here: http://megpickard.com/2011/06/nifty-bookmarklet-to-make-web-... This reminds me that I didn't thank the author enough, I'll have to drop her a line.

That is wonderful, thanks for the link!

Re: UI Design Dos and Don'ts

#104

Post by sandofsky »

exodust wrote: post #77
sandofsky wrote: post #52

Earlier quoted context omitted.

What advantage is there to shipping a single asset? On the web, use the "srcset" attribute on img tags. If the device supports @2x, it'll fetch the right version. On an iPhone app, any advantages are far outweighed by the headaches of resizing "@1.5x" assets for each device resolution. Now consider the iPhone 6+, which has @3x resolution. At 1.5x it feels blurry. But forgetting that, would @2x users notice? They won'…

I suppose this article is about iOS apps, so I should stay away. Nobody is "shipping" anything on the web. I've never understood the use of the word, even for apps. Something that is shipped cannot be touched or modified after release. This isn't the case on the internet. For the normal operation of a website, needing to make only one image per product item is obviously more economical for whoever is making the conte…

> Nobody is "shipping" anything on the web. I've never understood the use of the word, even for apps. Something that is shipped cannot be touched or modified after release. This isn't the case on the internet.

At minimum, expect one week of review time before you can release an app on the App Store.

As far as web apps, every line of code that makes it to production has consequences. If you make a catastrophic mistake, like leaking user data, how long does it take to 1) discover the mistake, and 2) deploy an update? If you're dealing with thousands of servers and multiple data centers, it can take an eternity.

> Making the image slightly more hi-res, say 1.5x, and then compressing it more aggressively has the benefit of satisfactory sharpness and quality on high density displays, while compressing to a size similar to the low res. I've confirmed this and use this technique, as others have.

Did you perform user research? Are you a designer? Or does "confirm" mean, "my opinion"?

> For the normal operation of a website, needing to make only one image per product item is obviously more economical for whoever is making the content,

Whoever is making the content should have this automated. If they can't, your job as an engineer is to automate it.

> not to mention the technical hassle faced depending on your CMS and how it handles image assets.

1. Are you writing this from 1992? What modern software can't handle images at 1600 resolution? 2. Your CMS shouldn't have any load. Your assets should be delivered by CDN.

> iPhone 6 has 3x res? So what?

Users feel something is off, whether or not they'll articulate it. All these little things, together, make your website look amateur.

Re: UI Design Dos and Don'ts

#105

Post by __z »

TuringTest wrote: post #96
kagamine wrote: post #93

Earlier quoted context omitted.

Notice I said grey, not light grey. Good designers will understand that there has to be a contrast between the background and the foreground. There will always be some who misinterpret the rules. The first site you linked could exist for any design principle found on the web, just change the pattern to fit. The example they give also has negative text-shadow (engraved effect). That is not evidence of anything. Anyone…

> There will always be some who misinterpret the rules. Right, though the problem is when the misinterpretation takes on a life of its own and it's propagated as a good practice, as it happened with light grey and its purported benefits to dyslexic readers. This practice is too widespread to be left unadressed without correction. As for e-readers, the newer models of the Kindle and other competitors have darker text…

I, too, have problems reading many websites that insist on using light grey. Perhaps off black would be better to read but the misuse of grey text has a real world effect on people who are older and/or people with bad eyesight. Off black and grey aren't the same thing. I am baffled by designers coming in and discounting the people who say "this is hard to read for me" with "no it isn't."

For me, I open up firebug and change the text to black. It is amazing how often I can't read something some "designer" thought looked good with a complete disregard for functionality.

I am wondering (serious question) if grey on white is so easy on the eyes why are all books (as far as I'm aware) published with black text?

Re: UI Design Dos and Don'ts

#106

Post by TuringTest »

kagamine wrote: post #98
TuringTest wrote: post #96

Earlier quoted context omitted.

> There will always be some who misinterpret the rules. Right, though the problem is when the misinterpretation takes on a life of its own and it's propagated as a good practice, as it happened with light grey and its purported benefits to dyslexic readers. This practice is too widespread to be left unadressed without correction. As for e-readers, the newer models of the Kindle and other competitors have darker text…

> I've tried both and I clearly prefer I think we can end this debate here.

> I think we can end this debate here.

We could have done that when you said "why people like e-readers over tablets" :-P

Re: UI Design Dos and Don'ts

#107

Post by BillinghamJ »

beloch wrote: post #47
johnnyo wrote: post #22

Agree with these, but in my opinion, the date selector wheels in iOS are a terrible design. Three rolling wheels just doesn't map to most people's concept of a calendar

This is a great example of when it's more important to stick with a familiar interface (i.e. the calendar) than to go with something that is "designed for touch".

I would wholeheartedly disagree - I think this is a great example of where you should break from common desktop norms and provide something which is easier for a big stubby thumb to use.

Re: UI Design Dos and Don'ts

#108

Post by mhomde »

sandofsky wrote: post #99
mhomde wrote: post #75

Earlier quoted context omitted.

"a foolish consistency is the hobgoblin of little minds"

"Read a book." http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d... Consistency is an important tool. In the absence of obvious visual affordances, it's even more important.

Agreed, but its as important to know when to break consistency as to follow it, but the former requires more experience.

Re: UI Design Dos and Don'ts

#109

Post by aesthetics1 »

I feel like this is a poor attempt to try and craft some cohesion in the app store. Google has done a much better job of writing guidelines with their Google.com/design site, specifically the Material Design Guidelines[1]. In my opinion, Google has really shown that it has a stronger design sense than people give them credit for.

[1] https://www.google.com/design/spec/material-design/introduct...

Re: UI Design Dos and Don'ts

#110

Post by vbezhenar »

b15h0p wrote: post #81
vbezhenar wrote: post #78

Earlier quoted context omitted.

What I absolutely hate is minute picker. 60 items is just too much to scroll. For most usages 5 minutes step is enough and 12 items much better. As for calendar, I never had any problems with it. Of course it's not standard way that most people get used to, but I think any person will understand what to do.

A double tap on the minute picker switches between 1- and 5-minute increments, afaik.

Works in Calendar but does not work in Alarm clock, so it's not a default behaviour and probably hard-coded into Calendar app.
Post reply on HN