Chrome for Android. Photo: Ariel Zambelich/Wired.com
Google has released an upgrade for its new Chrome for Android web browser. Chrome for Android — which was released earlier this year — is still a beta release, but the latest version adds several nice new features, including a way to circumvent websites that try to force a mobile version on you.
This release fixes a number of bugs and adds some new features, like the ability to reload a site that has redirected you to a mobile page. Despite Jakob Nielsen’s recent pronouncement that users want to be auto-redirected to simplified mobile sites, Google’s Chrome for Android developers think otherwise.
Chrome for Android’s new feature subverts websites that automatically redirect you to a mobile version by spoofing Chrome for Android’s user agent string, in this case sending the string for the desktop version of Chrome instead of the mobile (which developers should note has been updated as well).
The new feature means that if a site offers a sub-par mobile experience by default, you can always reload the desktop version with the press of a button.
Also new in this release is the ability to add bookmarks to your home screen for fast access to your favorite sites and web apps.
In addition to the new features, Chrome for Android is now available in 31 more languages and in all countries where Google Play is supported. Chrome for Android is still a beta release and there are plenty of known issues, but the browser is getting closer to a finished product.
Make the logo smaller. Photo: Ariel Zambelich/Wired.com
Web usability guru Jakob Nielsen has come under fire for his latest suggestions on building mobile websites. Nielsen’s controversial advice can be distilled down to this nugget: “good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”
Among the many negative responses to Nielsen’s latest Alertbox post is that of web developer and mobile specialist Josh Clarke, who calls Nielsen’s questionable advice “180-degrees backward.”
Indeed, much of Nielsen’s advice may seem like a shockingly bad idea not just to developers, but to anyone who uses a mobile device to browse the web.
This isn’t the first time Nielsen has taken a contrarian stand about mobile websites. Last year he suggested that a mobile-first approach to design was wrong because “PCs will remain important,” which is, at best, a false dilemma since a mobile-first design doesn’t mean ignoring the desktop. Just because you’re focused on the future doesn’t mean you’re ignoring the past.
Nielsen’s latest advice has similar false dichotomies. For example much of Nielsen’s advice rests on the premise that a single site cannot serve the wants and needs of both mobile and desktop users. In fact you don’t need to choose between mobile and desktop, the page can adapt and serve the needs of both users. There are plenty of examples of sites that do just that with responsive designs. To be sure there are plenty of websites that claim to be mobile-friendly and obviously aren’t. But that doesn’t mean the solution is to toss out the whole idea of responsive design and go back to separate websites for every device.
In fact what Nielsen considers one of the “main guidelines” for a successful mobile website is something that many people would probably consider the most irritating thing about mobile sites: “If mobile users arrive at your full site’s URL, auto-redirect them to your mobile site” (emphasis in original).
The problem with this advice is that, as Clark puts it, “Nielsen is confusing device context with user intent.” In other words, just because someone visits your site on a small screen doesn’t mean they won’t want access to all the same things they would see on a slightly larger screen. It may be necessary to rearrange elements for smaller screens, but hiding them is a bad idea.
“All that we can really know about mobile users is that they’re on a small screen, and we can’t divine user intent from that,” writes Clark.
Nielsen, however, does just that, divining that — because a user has a small screen — they will want to do less on your site. He suggests you serve up a limited site and then offer a link to the full site “for those (few) users who need special features that are found only on the full site.”
We suggest you don’t do that. You can do better than that.
You can use responsive design patterns to make sure that the same content is always available, but that the experience is tailored to the device at hand. In other words, responsive design means your site works just as well on mobile as it does on the desktop. If it doesn’t that means something is wrong with your site, not the whole approach. Sure, there will be times when a separate mobile site is the right way to go, but those times will likely be few and far between.
Nielsen’s argument is based on copious research and we have no doubt he found plenty of horribly designed websites that completely fail on mobile devices to justify his recommendations. But just because Nielsen is finding a lot of poorly made mobile websites does not, as Clark writes, “mean we should punt on creating great, full-featured mobile experiences.”
Editing your Flickr photos in Aviary. Image: Aviary
Flickr is swapping out its existing Flash-based photo editor for a new HTML-based app that will work on any device.
Aviary, as the new editor is known, will start appearing as an editing option for your photos today, though some users may have to wait since Yahoo is staggering the rollout over the next few weeks.
Part of the change is out of necessity. Flickr’s previous photo editor was Picnik, which was purchased by Google in 2010. Google has since announced it will shut down the service Apr. 19 and roll its features into Google+.
To use Aviary to edit your Flickr photos, just head to the photo page, click the Actions tab and select the new “Edit photo in Aviary” option. That will open up the image in the Aviary window as an overlay. From there you can crop, rotate, add effects, adjust brightness and contrast and other editing basics.
Obviously Aviary is not aimed at people who takes their photo editing seriously, but for the casual user who just wants to crop an upload or add some punchier contrast, it works well. The learning curve is almost nil and it more than handles the 80 percent use case for casual Flickr users.
In that sense Aviary is a step up from Picnik, which was more of a Photoshop-inspired editor than an amateur-friendly option. However it’s surprising to see Flickr continue to ignore the Instagram-inspired trend of one-click image effects, which are not part of Aviary’s arsenal. Some may decry Instagram’s retro-inspired results, but there’s no denying the simplicity and popularity of its filters.
While Flickr obviously had to replace Picnik since Google is shutting the service down, Aviary offers another huge advantage over Picnik — it doesn’t use Flash. Dropping the Flash requirement means that Flickr users can now edit their photos on iOS devices and upcoming Windows Metro tablets, neither of which run the Flash plugin.
The high-resolution retina display iPad has one downside — normal resolution images look worse than on lower resolution displays. On the web that means that text looks just fine, as does any CSS-based art, but photographs look worse, sometimes even when they’re actually high-resolution images.
Pro photographer Duncan Davidson was experimenting with serving high-resolution images to the iPad 3 when he ran up against what seemed to be a limit to the resolution of JPG images in WebKit. Serving small high-resolution images — in the sub-2000px range — works great, but replacing 1000px wide photographs with 2000px wide photos actually looks worse due to downsampling.
The solution (turns out) is to go back to something you probably haven’t used in quite a while — progressive JPGs. It’s a clever solution to a little quirk in Mobile Safari’s resource limitations. Read Davidson’s follow-up post for more details, and be sure to look at the example image if you’ve got a new iPad because more than just a clever solution, this is what the future of images on web will look like.
As Davidson says:
For the first time, I’m looking at a photograph I’ve made on a screen that has the same sort of visceral appeal as a print. Or maybe a transparency laying on a lightbox. Ok, maybe not quite that good, but it’s pretty incredible. In fact, I really shouldn’t be comparing it to a print or a transparency at all. Really, it’s its own very unique experience.
To show off the sample on his site Davidson uses a bit of JavaScript to toggle the high- and low-res images, highlighting the difference.
But how could you go about serving the higher res image to just those screens with high enough resolution and fast enough connections to warrant it?
You can’t.
So what’s a web developer with high-res images to show off supposed to do? Well, right now you’re going to have to decide between all or nothing. Or you can use a hack like one of the less-than-ideal responsive image solutions we’ve covered before.
The high-res future is coming fast and the web needs to evolve just as fast.
In the long run that means the web is going to need a real responsive image solution; something that’s part of HTML itself. An new HTML element like the proposed <picture> tag is one possible solution. The picture element would work much like the video tag, with code that looks something like this:
The browser uses this code to choose which image to load based on the current screen width.
The picture element would solve one part of the larger problem, namely serving the appropriate image to the appropriate screen resolution. But screen size isn’t the only consideration; we also need a way to measure the bandwidth available.
At home on my Wi-Fi connection I’d love to get Davidson’s high-res images on my iPad. When I’m out and about using a 3G connection it would be better to skip that extra overhead in favor of faster page load times.
Ideally browsers would send more information about the user’s environment along with each HTTP request. Think screen size, pixel density and network connection speed. Developers could then use that information to make a better-informed guess about which images it to serve. Unfortunately, it seems unlikely we’ll get such tools standardized and widely supported before the high-res world overtakes the web. With any server-side solution to the bandwidth problem still far off on the horizon, navigator.connection will become even more valuable in the mean time.
Further complicating the problem are two additional factors, data caps on mobile connections and technologies like Apple’s AirPlay. The former means that even if I have a fast LTE connection and a high-resolution screen I still might not want to use my limited data allotment to download high-res images.
AirPlay means I can browse to a site with my phone — which would likely trigger smaller images and videos since it’s a smaller screen — but then project the result on a huge HD TV screen. This is not even a hypothetical problem, you can experience it today with PBS’s iPhone app and AirPlay.
Want to help figure out how the web needs to evolve and what new tools we’re going to need? Keep an eye on the W3C’s Responsive Images community group, join the mailing list and don’t be shy about contributing. Post your experiments on the web and document your findings like Davidson and countless others are already doing.
It’s not going to happen overnight, but eventually the standards bodies and the browser makers are going to start implementing solutions and the more test cases that are out there, the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.
The first of the new iPads will arrive in the hands of the public this Friday, March 16. Like the iPhone before it, and no doubt many more devices to come after it, the new iPad has four times the resolution of typical screens. That means your visitors will soon be looking at your site on a high-resolution screen with a whopping 3.1 million pixels.
The sharp, crystal-clear screens are awesome news for new iPad owners, but they create some new dilemmas for web developers who’d like to offer a better experience for high-resolution screens. Sure, increased pixel density means you can serve up sharper, better looking graphics, but there is a cost as well — bigger images mean more bandwidth and longer page loads.
This isn’t a new problem by any means and Webmonkey has looked at a variety of solutions in the past, including techniques like adaptive images and responsive images.
The problem is simple: you need to send smaller images to small screens and larger images to larger screens. Sending a huge iPad-optimized image to a device with a max resolution of 320×480 just doesn’t make sense. At the same time, when bandwidth isn’t an issue, most sites will want to serve high-resolution content to displays that can handle it.
The ideal solution would be to detect both the resolution of the screen and the available bandwidth. Then, based on the combination of those two factors, the server could offer up the appropriate image. Currently that’s not possible, though there are already proposals to extend HTML to handle that scenario.
The Responsive Image Working Group is a W3C community group hoping to solve some of these problems. The group is proposing a new HTML element, <picture>, which will take into account factors like network speed, device dimensions, screen pixel density and browser cache to figure out which image to serve up. Think of it as a much smarter version of the old lowsrc property. So far though it’s all hypothetical
Essentially Apple is serving up lower resolution images by default, then using JavaScript to send larger images on to iPads. That works, but it will definitely mean increased download times for new iPads since they have to download two files for every graphic. Apple’s approach will also up the number of HTTP requests, which will also slow down the page.
The slower page loads seem to be an acceptable trade off for Apple since the company no doubt wants to showcase the new iPad’s high resolution display with high resolution images. For other sites the bandwidth trade off may not be worth the gain in image resolution.
Still, screens are only going to continue getting better with ever-increasing pixel density. Now is the time, if you haven’t already, to start embracing CSS 3 (avoid images altogether with gradients, shadows and rounded corners in CSS 3), Scalable Vector Graphics (SVG) for resolution independent graphics and of course @media queries to serve high-res background images.
For more on detecting and developing for high resolution displays, check out these posts from around the web:
Media Query & Asset Downloading Tests — Want to know how you can avoid the double image load tax Apple is paying? Tim Kadlec has the tests and results for a variety of methods.
Notes on Adaptive Images (yet again!) — Opera’s Bruce Lawson rounds up problems and solutions facing anyone trying to serve up different images based on screen size.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code