UI Design Dos and Don'ts
developer.apple.com
developer.apple.com
I find sometimes I have difficulty understanding where the bounds of the control actually are. That's not good design, and it seems far from obvious.
I find it's familiarity calendar display coupled with iphone friendly format strikes a good balance.
The time is a clock where you're able to select the hour first and minutes thereafter. This is the most intuitive mobile touch interface I have seen so far, any other is really small, awkward or not mentally easy to comprehend.
Image: https://raw.githubusercontent.com/CiTuX/datetimepicker/maste...
Really? This is incredibly unintuitive in my opinion. That clock was my biggest annoyance with Android and I always selected the wrong time first go round.
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.
But I guess there is no easy way to accommodate for both those that do need 1-minute intervals and those who would rather have 5-minute intervals (without adding yet another UI element or yet another setting to toggle).
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.
Good design is a form of engineering. You have a set of principles and successful patterns– such as the ones on the linked page– but your job is adapting to real world constraints. In this case, the challenge is making a headline look like a headline only relative to the example, not the page.
As far as the Safari tab shortcut, that's consistent with the rest of OS X. How did they originally arrive at that shortcut? They probably tried several combination, all within reach of the home keys, and that felt most right.
Why include the power switch on the keyboard? I know every user's first question is "where is the on switch?" and that position seems highly visible, and it can be consistent across all macs. In my entire history of using Macs, I've never had an issue cleaning the power key.
No idea why they made the displays more reflective. But given their overall attention to detail, a lot of thought probably went into it.
That font, in the section that talks about the importance of larger fonts, is fucking tiny.
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.
Both their recent releases result in more eye strain for me looking for a way to fix their messed up ideas of contrast.
Low contrast may be pleasing to twenty-something year old eyes, but unreadable to fifty-something year old eyes, and, if I consider my own attitudes and thinking at a younger age, I would almost certainly not have been considering how UI design choices would impact people with less-than optimal vision but for a mother-in-law with severe vision limitations.
Low contrast works especially well with the retina and above screens we currently on everything nowadays.
I have always made sure to design with disabilities in mind.(Section 508 government work.) There was a previous designer I worked with a couple years ago that came from the Silicon Valley area that would require a weekly reminder that low contrast designs would not be acceptable.
The rest of your points get top marks and I hope to Cod that someone at Apple is listening. The power button on the keyboard is retarded (no other word for it, sorry), super glossy screens so you can't even see it in your own house.
As for Apple shortcuts, well, many make perfect sense and this isn't something anyone else does better. MS Word even changes them depending upon system language, so Word in Norwegian uses Ctrl+F for "fett" or bold. Imagine how annoying that is when someone asks you for help. It happens at application level too, especially with non-US keyboards, just press ctrl+[ to access this feature, and no you cannot remap the shortcuts. Well, dandy, I can't access [ without pressing 2 other keys already. So I'll just press the X in the corner instead.
That may the single most propagated unfounded myth in UI design this decade. [1] While it's true that pure black on pure white causes problems for some dyslexic users, there is also a _minimum_ required contrast [2], which is routileny ignored by many "stylish" web sites.
The plague of contrast-less "light grey on white" have been adopted by plenty of "web 3.0" sites out of following fashionable trends, to the point of making them unreadable.
I've been forced to place a "Contrast" bookmarklet on the toolbar of all my browsers to fix all those terrible contrast-less pages I found everywhere, and I'm forced to use it dozens of times a day to alleviate my aching eyes. (Hexadecimal #333 is my personal upper level of comfort on white backgrounds, anything above that begins physically hurting my eyes when reading any kind of long text).
Could you please share these? I'm not web-programming-savvy enough to make anything that'd be generally useful.
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.
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 could make a website with focus on a single design error like that.
The W3 link doesn't support your argument either, as all they are saying is to make sure there is enough contrast, not that grey text is wrong. They also include "provide sufficient contrast when viewed by someone having color deficits" in the title, which I took to mean people with impaired sight. IF you want to go down the rabbit hole that's is more than 1% of the www friendly toward people with accessibility problems you will be lost in there until rabbits evolve to live in houses.
Think of the kindle, is that black text on a white page? Now search for why people like e-readers over tablets, you will see that black on white is not good for the eyes.
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 over whiter background as a selling point, and the early grey-on-grey was touted as a huge limitation of the format. I've tried both and I clearly prefer the high-contrast versions.
Also, people prefer e-readers because they are based on reflective light instead of emiting LEDs - it has nothing to do with them having grey text.
I think we can end this debate here.
We could have done that when you said "why people like e-readers over tablets" :-P
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?
One of the web's greatest problems has been defining itself in relation to printed media. From use of font types, colour and page layout, margins and line spacing, the web is not on printed paper. Why do you think the two are the same?
I am not disputing that there is a lot of bad design out there, one of my personal peeves is tiny text. I've seen real UX people use a 9pt font because it looks good on their screen, but is impossible to read on anything else and when you don't hold your face 4 inches from the glass.
I've said this before and I'll say it again, one of the problems with UX is the number of "experts" who are self-taught. It's like web-design/development circa 2001, everyone was claiming to be a "web-dev" but in practice hardly any could do more than basic html & tables. UX, imo, is like that now.
I do not. I was asking a question that if we have become enlightened because of digital media why hasn't some of those best practices translated back to traditional media? Maybe they have, I don't know, I can't recall noticing. If off-black is done well it isn't noticed because it doesn't look jarring anyways so perhaps we are all reading off black books. Not really sure. It was just an inquiry.
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.
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...
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...
I say it's due to laziness because if the developers had the time, they would adjust the text and scrollbars for a better experience.
On the bright side, that means if you are willing to set ego aside, you gain an immediate and substantial advantage over the competition.
You can watch my talk from MidwestUX last year that gives some practical tips too: https://vimeo.com/110260257
The early release eBook is available now. The print version will be available in August.
Time is limited and traffic is limited. You simply cannot test everything, in fact, the amount of variants you can actually test during, say, a year may be shockingly low compared to the amount of variants possible (at least if you are not Google – but most aren’t).
Without a strong sense of direction and discerning eyes and hands that provide plausible variants to test, AB testing can be quite useless. AB testing is a great tool to verify hypotheses (and those may well be competing hypotheses), but I really question its usefulness as a creative tool.
If you can plausibly only do a couple of AB tests a year (the possibility of running an AB test being a function of traffic and time) you better not waste that opportunity on button colors or some similar nonsense.
Sure, evolution through natural selection produced some awesome designs and is basically a completely blind process based purely on testing of different variants with only slight and random differences with no involvement of any designer at all (sound familiar?) – but it also took billions of years. Most designers just don’t have that kind of time …
To more directly answer your question, AB tests can certainly be used to defend against bad hypotheses. If there is a culture of testing and new designs have to be battle tested then that’s less of an opportunity for someone in a position of power to screw things up by fiat. However, that’s also a tremendous waste of time and efficiency if bad designs that could be sieved out quickly by simple heuristics have to also first be tested, which is just a slow process and a wasted opportunity to test something better.
Maybe think of AB testing as a last line of defense, but be careful, AB tests can be paralyzing. (Or rather, first AB tests paralyze everything, then the boss is annoyed by how slow everything is going and changes everything by fiat and immediately without any testing at all. From one extreme to the other …)
In the realm of modern-day web-design, most bad design is because the website was built before a lot of these good design principles and conventions were invented (e.g. responsive grids, tons of padding, flex-direction(column), etc.). Next followed by prideful "designers" who steadfastly refuse to use a design framework because the site they're building must be a special snowflake. Next followed by the missing-the-point-followers of RMS (that is, they're not following RMS for the free software philosophy) who plainly look down on CSS and design as something that is beneath them. Finally, I'll give you laziness.
Or more likely time constraints.
http://dropbox.scripting.com/dave/misc/appleHumanInterfaceGu...
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.
https://developer.apple.com/library/ios/documentation/UserEx...
(eg. @eli_schiff - he's been ranting about them today).
(I also saw irony in a page with poor color contrast telling you to avoid poor color contrast)
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.
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.
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.
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.
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.
https://developer.apple.com/library/ios/documentation/UserEx...
[1] https://www.google.com/design/spec/material-design/introduct...
http://lifehacker.com/5879239/all-the-awesome-things-you-can...
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.