Hacker News Reader

Comment by Lewisham | Hacker News Reader

One thing I have noticed is that there is a weird transitional period we are in with a number of major sites who have optimized for the iPhone and iPad already.

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.

View on HN

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.

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.

I've only been using 2x images for UI elements and logos. Photos still look fine at standard res (especially if 'Saved for Web' with a .25 blur). A recent project included a 25K 8-bit 2x sprite sheet, and a 13K 1x sprite sheet for LTE IE8. So not much of a difference if limited to elements that really need to be crisp.

Another good approach to small elements like these is using icon fonts. For example, GitHub recently changed all of their nav icons from sprites to a custom icon font called Octicons:

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.

Icon fonts just seem to like such a hack to me in a world where SVG exists. Is the entire idea behind using them just that IE 7/8 doesn't have SVG support? How did lack of SVG support even happen? SVG seems like something any modern browser should have had for years.

Android also lacked SVG support until 3.2. The justification I read was that they deliberately disabled it from their webkit build to save 1MB in the compiled binary. Sad, especially since pre-ICS phones are by far the most prevalent.

Although a low Res image fallback is OK there.

You can hint a font. You can't hint an SVG.

Huh, that is unfortunate. Is hinting still important on devices with such high DPI though?

It’s not usually the high-dpi devices that you’d be adding hints for. The point is that anything that is going to replace today’s pixel-perfect bitmap graphics still has to look pixel-perfect when rendered on lower-dpi devices, which is going to remain by far the majority of visitors to most sites for a while yet.

I would love to use SVG, but support just isn't robust enough. Hard to deal with hover/active states too. Icon fonts are one request and easy to style with CSS color and text-shadow (even simulating glows). I just wish there was an easy way to generate a small font set from a the handful of vector elements I need for a given website (custom elements, that is, not using a service like Pictos).

I believe IE was trying to push the roughly equivalent VML format.

Nice, I love that they created a large and small version so that the details weren't interpolated away when down sampled. The 'making of' is great, I'm going to forward this to our designers.

I've actually taken it even further and bumped up to 4x+ to account for zooming as well. Especially for charts.

Mobile bandwidth is somewhat of a red herring. While ubiquitous 4G isn't reality, most smartphones and networks are already capable of fairly high bandwidth.

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

It's neither bandwidth nor latency that I would be most concerned about (though I agree they are a problem) but the other point he raises:

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

Agreed it's an issue - considered including it but didn't.

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.

> It's fair to question how much developers should concern themselves with external costs for using their service.

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.

Just use SVG for logo's and icons. I use it all the time. They even render better than reduced PNG logo's.

They even render better than reduced PNG logo's.

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.

I had noticed that images in my news feed on the Facebook app on my iPad 2 were displaying weirdly, but it hadn't occurred to me that it was likely a HiDPI problem.

("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.

Reply on news.ycombinator.com