
UI Design Dos and Don'ts - medyo
https://developer.apple.com/design/tips/
======
johnnyo
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

~~~
Mandatum
Do you have a better example? I don't find the select diag's like in Desktop
Chrome easier to use especially on a mobile. I think what they've done is
better than anything else I've seen. With enough following it'd become the
norm like anything else.

~~~
ilovecomputers
Cultured Code's date picker for Things has been my favorite:
[http://culturedcode.cachefly.net/things/videos/things-
iphone...](http://culturedcode.cachefly.net/things/videos/things-iphone-
scrolling-datepicker-20120809/video.m4v)

~~~
afro88
How do I choose a date that's 30 odd years ago - a birthdate for example.

~~~
kaolinite
You wouldn't want to do that in Things (it's a todo app) - you're most likely
not going past next month, at the most. You're right though - this wouldn't be
a good replacement calendar picker for every app.

------
wampus
Apple has been a driving force for better UI in a number of areas, but some of
their choices are baffling. Even in this page, the "Contrast" section uses a
large black header, but a small grey font on a white background for the
content. Who chose Shift-Command-] for switching tabs in Safari? Why include
the power switch in the keyboard, which makes it challenging to clean? Could
their glossy displays be any more reflective?

~~~
bananaboy
I also feel like iOS has gone downhill. I know they were trying to get away
from skeuomorphic design, but I feel they went too far in the opposite
direction. Everything is flat, it's hard to tell what is a button that can be
clicked on sometimes (usually it's just a blue label with no distinguishing
background), and there seems to be a frequent lack of contrast generally.

~~~
batiudrami
Yeah, also I feel the rainbow colours with a Gaussian blur looks pretty dated
too - reminds me of Aero Glass. Android at its best looks much nicer, though
it can be very inconsistent, even within Google-developed apps.

~~~
frik
AeroGlass looks still very nice and fresh in Windows 7. Windows 8x/10 theme is
too flat for a desktop OS and the color choices imo plain ugly. Microsoft
removed most of the complex transparent effects because the Nokia/MS WinPhones
7-8 devices were too slow to handle them, that's why the desktop has to suffer
as well. The iOS 7-9 and OSX themes have a lot better colors.

------
julianozen
Interesting that Apple displays the hit targets of the buttons with a border
around it, despite the fact that standard iOS 7/8 UIButtons do not come with
button outlines/fills by default.
[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/UIKitUICatalog/UIButton.html#//apple_ref/doc/uid/TP40012857-UIButton)

I found this one of the more annoying changes in the iOS 7 redesign. Buttons
and tap targets are incredibly difficult to recognize in certain places.

For instance, it is very hard to discern which of these text labels are
buttons, and which are titles.
[http://images.techhive.com/images/article/2013/09/05-tell-
me...](http://images.techhive.com/images/article/2013/09/05-tell-me-a-
story-100054464-medium.png)

Or in the iOS start guide, several of the buttons, don't have large enough tap
targets behind them making them annoyingly difficult to press
[http://screenshots.en.sftcdn.net/blog/en/2013/09/ios-7-welco...](http://screenshots.en.sftcdn.net/blog/en/2013/09/ios-7-welcome-
start-screen-2.png)

------
shogun21
Many of these are blatantly obvious. Most bad design isn't because people
don't know better; it's due to laziness.

~~~
on_and_off
Most of the stupidly bad design decisions I have seen come from somebody high
in the hierarchy (product manager, CEO or founder) demanding a change, even if
both designers and developers rally on how awful it would be. I have not yet
found a solution to this problem.

~~~
jamesdelaneyie
would A/B testing, in some capacity, the decision in some form or another,
help with this?

~~~
psychometry
It could make it worse. Just look at Amazon's homepage.

------
scottfr
I was hoping for something like:

[http://dropbox.scripting.com/dave/misc/appleHumanInterfaceGu...](http://dropbox.scripting.com/dave/misc/appleHumanInterfaceGuidelines.pdf)

300 pages of detailed ui/ux guidelines and rationales. It honestly was a joy
to read when I first came across it 15 years ago.

~~~
jamesrom
The article links to the iOS HIG.

[https://developer.apple.com/library/ios/documentation/UserEx...](https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/)

~~~
rdsnsca
Its available on the iBook store too.

------
ehmorris
A page about mobile design dos and don'ts and it's not even mobile optimized!

~~~
rimantas
I build my apps in Xcode, and it does not even run on my phone!

------
erlkonig
Their "contrast" section belies their determination, since the text there is
grey on a white background, and true black on white would unquestionably be
more readable. (looking at UI designers more generally:) I'm so sick of UIs
that have repetitive, huge, contrasty, readable headings... only to have the
core useful text be grey-on-something, tiny, possibly italic, and so on.
Idiots, and they are legion. More subtle issues like older folks having lower
visual resolution, and many folks (men mostly) having significant color
blindness, never seem to occur to UI designers as a problem.

~~~
rimantas
Black on white is actually bad combination, it strains the eyes.

~~~
kagamine
Black on white is a hand-me-down from print that made it's way to web without
anyone giving it much thought. It is indeed too great a contrast for back-lit
screens. Google results also show the page descriptions using grey on white.
Surprising that so few people know of this.

------
Mandatum
These are common sense design "do's" and "don'ts". Most developers, and any
designer worth their salt should know these.

~~~
radley
Sadly, Apple is guilty of these often, with too many examples to list (but
particularly contrast).

(eg. @eli_schiff - he's been ranting about them today).

~~~
__z
Back in 1999 the Interface Hall of Shame did a takedown on the Quicktime 4.0's
interfact - and noted it violated Apple's own human interface standards. Worth
a read.
[http://hallofshame.gp.co.at/qtimeno.htm](http://hallofshame.gp.co.at/qtimeno.htm)

(I also saw irony in a page with poor color contrast telling you to avoid poor
color contrast)

------
exodust
"Images that are not @2x will appear blurry"

That's quite an exaggeration.

"Blurry" is not what most people would perceive. They won't perceive a problem
with the site at all and in most cases will never notice or care.

Sure it's nice to use hi-res images, but I prefer using just one image that is
slightly higher resolution than normal... maybe 1.5x and then increase
compression. The result is noticeably better, satisfying the perception of
"sharp" but still uses just one image and often only a very small increase in
file size.

Delivering two versions of the image for all your regularly produced content
is an inefficient practice relative to the benefits IMHO.

~~~
sandofsky
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't be able to articulate
something is wrong, much like if you pick a suboptimal line height, they won't
be able to articulate "it's less legible." It's all these little things,
combined, that make a project feel amateurish.

~~~
exodust
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 content,
not to mention the technical hassle faced depending on your CMS and how it
handles image assets.

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.

For example instead of the normal 800 pixel wide product image, you make it
1200 wide but compress it more when making the jpeg, say 55 instead of the
usual 70. The result is a nice lean and sharp image without the bloat of a
"2x" file size, and without any perceivable quality loss from increased
compression. The increase in resolution serves to hide the compression
artefacts surprisingly well.

I'm talking about responsive of course, so there is no fixed width specified
in the tag.

iPhone 6 has 3x res? So what? It's an iPhone with a physically small screen.
People hold those screens in their hand - arms length from their eyes. You
won't see any difference between a 1.5x 1200px wide jpeg photo and a 3x 2400px
wide image on that screen. Not until you get your magnifying glass out, or
pinch and zoom will you see a difference.

Not a fan of "srcset", it's not well supported and promotes a clumsy multi-res
production workflow, which isn't needed for regular jpeg content images on the
web - the point I'm getting at.

~~~
sandofsky
> 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.

~~~
exodust
> "Users feel something is off"

Do they? Because an image is 1.5x and not 2x on their phone? Mate, that's
nonsense.

Just do a comparison yourself and you'll see. I did, checked and confirmed
with the client (jewellery designer where the image quality was important) and
they were happy. On my iPad3 the 1.5 product images (at 1200 pixels wide
presented half width of screen) were MORE than adequate and very sharp on the
iPad. No "blurriness" at all. There is no way in the world you'd be able to
tell the images were not 2x when the screen is viewed at normal distance.

> "Are you writing this from 1992?"

I'm writing this from the real world. In your utopia it seems everyone has
unlimited bandwidth on their mobiles to download 1600px images for every
product listed, and can see the difference with their bionic vision. I prefer
to keep site weight down and enjoy the increased performance as a result.

Disagreeing is fine, but your argument amounts to "the site will look amateur
hmmkay", and I'm telling you now that the "amateur look" comes from poor UX or
clunky design and performance, not whether an image is 1.5x vs 2x.

Using a CDN for assets is good, but not always an option/need for a small
business website with minimal traffic (such as a jewellery designer's e-store)
and keeps the dev costs and complexity down if everything can be handled on
the one platform. But I don't disagree with you about using a CDN, it's just
that a CDN doesn't suddenly make the frontend more responsive or snappy. Those
images still need loading in the browser no matter where they come from.

I convince my clients to spend a little bit more on their web host account, to
get a bit more CPU performance and memory so that uploading images and so on
runs smoothly. Works for me, works for them. Whether it works for anyone else
is not my problem! I'm just sharing my approach. Ignore or disagree, it's all
good.

Good luck. Remember to do things because they work in practice, not because
Apple or Google or some random person on HN said to do it that way.

------
mlex
I thought they'd have a more detailed document like this:
[http://iosdesign.ivomynttinen.com/](http://iosdesign.ivomynttinen.com/)

~~~
rdsnsca
They do one the website and the iBook store.

------
cairx
Is it ment to be ironic? Considering that I'm reading this from a phone and
they don't even follow their own first point "Formatting Content".

------
gtirloni
Just sharing this link since a11y gets so little attention:

[https://developer.apple.com/library/ios/documentation/UserEx...](https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Introduction/Introduction.html)

------
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...](https://www.google.com/design/spec/material-
design/introduction.html)

------
Animats
Apple's watch UI document is there, too. That's interesting. Apple has very
tight control on the watch interface. Apple owns the knob and the button; you
can't use those. You must use white text on a black background. You can use
only one font other than Apple's "San Francisco". Voice input is not a watch
UI component; voice input appears to be reserved for talking to Apple's Siri.

~~~
kaolinite
With the launch of watchOS 2, developers are able to use voice input and the
digital crown. Don't _think_ they have access to the button.

------
yAnonymous
Design advice from Apple... no, thank you.

------
marvel_boy
I wish apps designers respect this simple dos and dont's.

------
enlightenedfool
FWIW Apple, Don't: Force the user to backspace all the way to the word to
correct in textbox Do: Focus the cursor on where I touch. Frustrating.

~~~
molecule
_> Tapping and holding anywhere there's editable text will engage the
magnifying glass mode so you can move the text cursor around._

[http://lifehacker.com/5879239/all-the-awesome-things-you-
can...](http://lifehacker.com/5879239/all-the-awesome-things-you-can-do-with-
a-long-press-on-your-iphone-ipad-or-ipad-touch)

------
alajarvela
Pretty basic stuff, although Apple's examples aren't exactly the greatest
ones. They break some of the rules themselves.

------
nielsbot
Surprising how many of these people get wrong. I think this page is for people
building apps without help from a designer.

------
thewhitetulip
Android be like: been there done that

~~~
kagamine
Android be like, press anywhere on the row to check the box on the right. And
anywhere on the row to go to the next page in the menu. And anywhere on the
row to do nothing, but press the arrow all the way to the right to go to the
next page. Android be liek: we didn't think this through. At all.

Not defending some of the choices Apple make, but if you want to get into an
old-style flame war of Apple UX versus Android / Win / Linux / anything, you
better come with a better argument than that.

