Designing for A Retina Web
coding.smashingmagazine.com
coding.smashingmagazine.com
For example, photos in the News Feed on Facebook are HiDPI, as are some images on Google. My guess is these were already being used for places to be served for iOS and Android. However, it's hit and miss: the Google logo is never HiDPI.
Last time this came up was when Marco wrote a post saying "design for Retina" and a bunch of comments complained asking why people should design for just the Retina Macbook Pro. That's not just short-sighted, it's wrong now: the number of high density mobile platforms means designers should be very worried how their site looks.
And, for the most part, sites look terrible.
("weirdly" = some images are blown up 2x bigger than you'd expect them to be with the full vertical dimension showing, but the right half of the image being cut off by the instant messenger window)
Now it makes sense, assuming that in the iPad app the News Feed is just HTML and that they probably didn't test the new HiDPI News Feed on older, non-retina iPads. I make that assumption with a healthy dose of doubt because I have no way of knowing how the Facebook app is designed or tested.
The takeaway for me is that there is now an even larger pool of devices/browsers/resolutions for which we need to test our designs. Choosing to go the HiDPI route, a noble decision in my opinion, comes with an even greater testing burden.
And, for the most part, sites look terrible.
It’s not that simple, though. While mobile (a.k.a. small) devices have been leading the way in higher pixel densities, they also tend to have Internet access at speeds rivalling a carrier pigeon, and the amount of data included in their plans before insane pricing kicks in is frequently still measured in megabytes. All those double-resolution assets might look great, if (and only if) you have a screen that can render them, but they are also slowing things down and eating up people’s data allowance. Not everyone is going to thank you for that.
Say Hello to Octicons: https://github.com/blog/1106-say-hello-to-octicons
The Making of Octicons: https://github.com/blog/1135-the-making-of-octicons
Edit: I realize icon fonts are mentioned in the Smashing Mag article, but GitHub's articles are considerably more thorough.
Latency is the bottleneck you should tackle first when addressing mobile performance, not asset size - the world has already spent a lot of time optimizing asset size for web delivery. But phones are bad at handling lots of requests. Serving a single high-resolution graphic will have significantly less impact on page rendering speed (and even more important, perceived rendering speed) than a handful of smaller assets which add up to the same size.
For a real world example, a mobile phone can download and render a single large photo faster than the gaggle of javascript, css, and social network share icons typically presented next to it.
Many have examined and written about this. Here's a blog article that Google ranks on the subject: http://www.webperformancetoday.com/2012/04/02/mobile-versus-...
> ... the amount of data included in their plans before insane pricing kicks in is frequently still measured in megabytes.
Mobile data plans are a joke in my country[1].
1. http://blog.binarybalance.com.au/2012/05/12/internet-anemia-...
It's fair to question how much developers should concern themselves with external costs for using their service.
Do we have a responsibility to design for data caps to prevent unnecessary charges? Do we have a responsibility to do the opposite, as an industry exerting pressure on carriers to increase cap levels? Somewhere in between?
Honestly, I don't know. I'm inclined to design for a user's reality rather than a principle, but that "in the real world" thinking allowed the web to be dominated by "best viewed in IE6" sites.
I wouldn't go so far as to say we have a solemn duty to always take such issues into account. But as a designer/developer, it is certainly something I myself would spare a thought for because - putting on my consumer hat - I am directly affected by the problem of shitty data plans at present and I'd like to think it's something that designers/developers would be aware of, regardless of whether they then make an informed choice one way or the other.
> Do we have a responsibility to do the opposite, as an industry exerting pressure on carriers to increase cap levels?
I'd like to think this would work. But I really just can't see it.
I too would be leaning towards designing for ther reality. But it seems we're in the time of 'case by case basis' on this issue. I don't think there's a single correct answer.
Unfortunately, SVG hasn’t been well supported on Android until quite recently, and likewise for IE.
Also, you still have the problem that SVG doesn’t support hinting, so for small icons its value is limited.
http://www.pushing-pixels.org/2011/11/04/about-those-vector-...
device-pixel-ratio,
-o-device-pixel-ratio,
-moz-device-pixel-ratio,
-Webkit-device-pixel-ratio { … }
-o-device-pixel-ratio,
-moz-device-pixel-ratio,
-webkit-device-pixel-ratio,
device-pixel-ratio { … }As for capitalisation, it doesn't matter in a CSS stylesheet but it does matter if you work with styles in JavaScript, so it's better to keep them lowercase.
The fact that we have to worry about an implementation detail like pixels at this point means something's broken. Give us some points or viewing angle or something.
Also, I was hoping that they'd discourage people from using Photoshop to create assets; raster layers have never been a really good match for either illustrations or web layout design, and the mismatch between that model and SVG is going to mean either a slower uptake or some rube-goldberg accretion to the tooling (my money's on the later).
The site design I'm currently working on is entirely vector shapes with the exception of real world photographs. I can design great pixel-snapped icons and UI, and resize the document to 200% and instantly have crisp retina elements as well.
Photoshop can be fantastic for web layout design. It comes down to a matter of preference.
And you don't even have to resize.
Not really. Apple might market their 300+ dpi Retina displays on the basis that people can’t see the pixels any more, but in our experience working on a mobile-friendly site, that’s only true for some people and under some conditions.
Meanwhile, the majority of web browsing is still done using devices with much lower pixel densities anyway, and on these devices extensive hinting and fine tuning can be necessary to get good results.
We have a very long way to go before we can just describe an icon or font design in vector terms and have it appear correctly on every device. As supporting evidence, I observe that many web fonts look terrible on a typical desktop or laptop display, with quite a few being literally illegible on Windows XP. It’s trendy to blame that on Windows’ font rendering, and that is certainly a factor, but so is the reality that some of these fonts simply aren’t hinted and kerned very well at all.
Just serving high-dpi assets isn’t a great fix, either. Aside from increasing the size of the download unnecessarily for users with relatively low-dpi screens, the scaling process often leaves awkward artifacts that wouldn’t have been there in, say, an icon that was designed from scratch to target that sort of pixel density. That’s partly because of hinting, and it’s partly because you can completely change the design (simplifying it, for example) if the larger/higher-dpi version is too complicated to work well.
So for quite a while yet, we’re still going to have to produce and manually fine-tune assets at multiple sizes to get best results.
The long and the short is that I have a feeling that we are going to see more and more interesting tools popping up in the near future as more and more web designers purchase hidpi computers and decide to write up some library to make their life easier when they decide to retina-enable their websites because it looks horrible on their machine.
App: http://keyamoon.com/icomoon/#toHome
Sample library: https://github.com/Keyamoon/IcoMoon--limited-
<button aria-label="Close">X</button>
{speak: none;}
<aria-hidden="true">
For that three variables have to be taken into account: screen size, screen resulution and viewing distance. Actually, four: visual acuity, too (though it makes sense to just set that at 20/20).
That's the definition Apple repeadtedly gave in so many words. They were actually pretty explicit about that. Sure, it's their trademark. They are in no way obligated to respect that definition. They can turn around tomorrow and call every one of their screen a retina screen - but when people use the term retina they usually mean Apple's original definition.
It's a squishy term, sure, but I like it. It makes a ton of sense since it puts human perception on the center stage and that's what matters. Human perception is squishy, so it makes sense that the retina term would also be squishy.
The distance is also very squishy attribute. From my experience, people look at a 10 inch tablet from about the same distance than they look at a smartphone. Still, Apple gave the ipad a lower minimum requirement for the Retina label than the iphone 4.
And does this mean I can "retina" and "unretina" a screen by moving closer/away from the screen?
You have to ask yourself one thing: What actually matters when it comes to resolution? Human perception does, of course! Everything else is pointless. Human perception is inherently squishy, that's just how it is. There really is no way around that.
If you start talking resolutions without a more complete understanding of human perception giving you context your talk is just meaningless.
The retina term here provides an easy summary, nothing more. There are always edge cases, sure, but the retina term is both explicit and unspecific enough to work very well. That's why I like it so much.
Yes, distances are different - but not so different. Yes, visual acuity is different and that sucks - but the simple solution here is to just pick 20/20. Maybe a bit better.
There are no simple yes/no answers here - but I don't think there have to be.
They are all different and iOS/retina is taking smaller and smaller shares of it. Designing for that is designing for last generation platform-specific web and has little future.
More and more devices will be providing high resolution displays. Designing for low-resolution displays is designing for last generation devices and has little future.
Of course, designers should aim for a solution that is as device-agnostic as possible. The linked article provides designers with a number of alternative ways to support high resolution displays. Perhaps their use of Apple marketing speak ("Retina") is self-limiting, but to dismiss the article out-of-hand for using that term is no better.
Disabling Firefox's accelerated layer renderer is clearly a temporary workaround, but the improvement in text quality is awesome. To track Mozilla's progress on full support for HiDPI text, you can follow https://bugzil.la/674373
There is plenty of talk out there about how to display bg images but not much (none?) that I have found to address the use case I talked about above.
I’m working on a project that involves CGI animations, and we’ve had considerable debate about what resolution(s) to offer for the video files. On a desktop or laptop, a size similar to YouTube works fine. On an iPad with a Retina display, the videos can sometimes appear to be of a lower quality than they really are, because we’ve got sharper icons and text nearby.
Having said that, it’s not so much the video itself that can look awkward (since people are used to somewhat lossy video compression on the web anyway, and in motion you’re not really seeing the individual pixels) but rather the static poster image that displays until you start to play that video.
Why on earth would it look blurry? There is no interpolated upscaling needed.