All posts tagged ‘Mobile’

File Under: Browsers, Mobile, Web Basics

Support Versus Optimization: Dealing With Mobile Web Browsers

Just a few of the many screens on the web

Last time we sent you over to Brad Frost’s blog it was for a slideshow about building a future-friendly web. Now Frost is back with some more tips for web developers in a post entitled Support vs Optimization, which tackles the thorny subject of what to do about the wide range of mobile browsers on the web.

As Frost points out the mobile world is more than just the WebKit-based iOS and Android browsers that often grab all the headlines. In fact the most widely used mobile browser is not even a WebKit browser (it’s Opera) and there are dozens of other mobile browsers out there as well. And, as the tablet market begins to expand beyond the iPad, there will likely be dozens more coming in the near future.

Faced with the diversity of the mobile browser market developers can either stick their heads in the sand and develop exclusively for WebKit browsers, or, as Frost suggests, we can be more considerate to other browsers. It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers? (For a more far-future look, check out Scott Jenson’s The Coming Zombie Apocalypse).

The solution, according to Frost, is to recognize the difference between supporting a browser and optimizing specifically for it.

The typical argument against supporting older BlackBerry browsers or Nokia’s WebKit fork, for example, is that these browsers don’t support nearly the number of features that iOS and Android browser’s offer. While that’s true, as with most things on the web, it doesn’t have to be an either/or choice. It can actually be both. That’s what Frost means be the difference between support and optimization:

You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.

For some practical advice on how you can take a more supportive approach to the wide range of mobile browsers on the market, head over to Frost’s site and read through the post. Be sure to check out the links to the various mobile emulators and brush up on the ideas behind progressive enhancement.

It’s a big web out there, with dozens of browsers and an ever-increasing number of devices connecting to it. If you want your site to be part of the future it’s going to have to work everywhere — perhaps not perfectly optimized, but at least working.

[Photo by Jeremy Keith/Flickr/CC]

File Under: Mobile, UI/UX, Web Basics

‘WTF Mobile Web’ Tracks Terrible Mobile Web Design

Sometimes the best way to figure out what works is to see what doesn’t. That’s the thinking behind WTF Mobile Web, a new site that tracks examples of terrible mobile web design and user experience. Whether it’s a “native look” that inevitably looks wrong on all but one platform or simply treating the iPad as a mobile browser, WTF Mobile has plenty of examples of what not to do when developing a mobile site.

WTF Mobile Web is the brainchild of developers Jen Simmons and Brad Frost who are careful to note that the point isn’t to be mean or pick on specific sites. In fact, perhaps the best part about the site is that, as people were quick to point out, it’s guilty of some of the very same things it’s calling out in other sites. Hypocrisy? Sure, but it also illustrates just how hard it is to get mobile right.

As Simmons and Frost write:

The problem is that we’ve all been doing this thing called Making a Website for a long time in a particular way. And now everything is changing. Sure some developers are resistant to learning new things, but most developers are interested, excited and willing. But this isn’t a problem that you can fix by just switching out which bit of code to use. It’s bigger than that. Content strategy, design, business all have to change. The fundamental way in which people work together to plan and coordinate the creation of a website has to change.

Perhaps the most important thing to keep in mind is that, to paraphrase developer Steven Hay, there is no mobile web, no desktop web, no tablet web. There is just The Web, which we view in different ways. Design for The Web, avoid assumptions about devices (like assuming the iPad is a mobile device) and please, stop with the “native” designs.

If you run across an example of bad mobile design you can submit it to WTF Mobile Web.

So how do you build better mobile sites? Well, WTF Mobile Web has a few links to get you started, including one to Frost’s Building a Future Friendly Web slideshow, which we’ve covered before. Webmonkey has also been covering mobile and responsive design for some time so be sure to read through our archives.

WTF? photo by Daniel Lobo/Flickr/CC

See Also:

File Under: Mobile, Programming, Web Basics

Build Faster Mobile Websites With ‘Adaptive Images’

Responsive design is no longer just something you’ll find on the portfolio websites of the designers and developers who pioneered the idea. These days using media queries to adapt to varying screen sizes is well on its way to being a mainstream design goal.

Head over to a responsive design showcase like Media Queries and you’ll find plenty of “real world” websites — like Opera or Arizona State University — using media queries to build responsive websites.

But while media queries are a big part of responsive design, they don’t solve every challenge the small screen presents. For example, many otherwise great responsive websites still serve full size images to mobile browsers. Many responsive sites use the max-width image scaling technique which dynamically re-sizes your image to fit the screen, but sadly that doesn’t downsize the actual image file.

Using the max-width trick neatly handles images on varying screen sizes, but, by itself, it doesn’t address the bandwidth issue. In fact, loading big images and forcing mobile browsers to scale them is the worst of both worlds — large image downloads and processor-intensive downscaling. And, not only are large images a waste of bandwidth for mobile users, with mobile data caps becoming more common, you may well be costing your visitors money.

A far better approach is to use the max-width trick, but also serve smaller images to smaller screens — that means less bandwidth and little or no downscaling. Mobile platform consultant Peter-Paul Koch has a nice overview of how JavaScript can be combined with media queries to swap out your mobile-size images for larger ones on larger screens. The developers at Filament Group refined this approach with the Responsive Images project.

However, as nice as the Responsive Images approach is, it requires maintaining two sets of images on your server. For existing websites with content management systems already up and running, and tons of images tied to existing content, it can be difficult and time consuming to go through and create a second set of smaller images.

The burden of an existing CMS led developer Matt Wilcox to take a different approach to the mobile image problem. The result is what Wilcox recently decided to call Adaptive Images. The Adaptive Images script works much like the Filament Group’s Responsive Images code, but Adaptive-Images manages its own image resizing so there’s no need to do anything to your existing website — just drop in the Adaptive Images code and you’re done.

There is, however, one other big difference between the two that’s worth noting — the Filament Group’s Responsive Images takes a mobile first approach while Wilcox’s Adaptive Images does not.

That is, if JavaScript is disabled, Responsive Images falls back to using only the small image. Adaptive Images on the other hand will fall back to the large image. While we generally suggest taking a mobile first approach, in this case the convenience of slipping Adaptive Images into an existing site outweighs the advantages of a mobile first approach. However, if you’re building a new site from scratch and your CMS can’t handle tracking separate image sizes, chances are you’re using the wrong CMS.

To get Adaptive Images up and running on your website you’ll need to have an Apache 2 server with PHP 5.x installed. For more info, head on over to the Adaptive Images website or you can grab the code from GitHub.

See Also:

File Under: Browsers, Mobile, Programming

Speed Up Your Mobile Site With the ‘Mobile Perf’ Bookmarklet

Speed is the most important element of your website. The best designed, most informative site in the world is useless if it doesn’t load fast enough for people to stick around. Nowhere is this more true than on mobile websites.

Testing mobile websites is something of a headache — there is no Firebug for mobile browsers, which means no YSlow or other profiling tools. True, you can load the site in desktop browser and profile it that way, but sometimes what works on the desktop isn’t necessarily working the same way in a mobile browser.

That’s why Google developer Steve Souders’ created the Mobile Perf bookmarklet, a handy javascript bookmarklet that you can use to test sites on your mobile devices. The bookmarklet is really just a set of links to other bookmarklets, but combining them all in one place makes life a bit easier.

The Mobile Perf bookmarklet contains links to Firebug Lite, the awesome DOM Monster, CSSess, Zoompf and Souders’ own SpriteMe and Page Resources. If you’ve been looking for an easy way to test website performance on the small screen, grab a copy of the Mobile Perf bookmarklet.

See Also:

File Under: HTML5, Mobile, Web Standards

W3C Offers a Guide to Building Mobile Web Apps

If you’ve been wanting to start development on a web-based mobile app, but don’t know where to begin, the W3C has you covered. The web’s governing body has released a set of guidelines and best practices for developing mobile web applications.

If you’ve already been keeping up with the latest in mobile web technologies, the guidelines probably won’t have too much new information for you. But if you haven’t already explored the rapidly growing mobile web apps scene, the W3C’s guide makes a good starting place.

The guide covers everything from the (hopefully) obvious, like minimizing the number of cookies, compressing your files and using CSS sprites, to less-well-known tips like using Fragment IDs or caching resources by fingerprinting resource references.

One thing to keep in mind is that this overview is intended for web apps, not just websites. If you just want to develop a mobile-optimized version of your website, check out our earlier post on the best practices for mobile websites.

If you’re building something much more complex and application-like, the W3C’s guidelines make a great starting point to get up to speed.

See Also:

File Under: CSS, Mobile

Slide Show Time: Rethinking the Mobile Web

 

Embedded above is an excellent presentation by Bryan Rieger.

It argues for a mobile-first approach to web development — by building for small screens first, then using @media queries to “size up” the experience and adapt your content on the fly, you can make sure people see the best version of your site for their particular device. It makes the most sense on the mobile web, where viewports and browser capabilities vary widely, and where (as Rieger points out) our definition of what exactly is a mobile device remains open. It’s an extension of the old “progressive enhancement” approach from the first decade of the web.

There are also some great data breakdowns about devices and browsers at the beginning. The takeaway: We’re all developing for Mobile Safari and Android, but most of the world is still using something far less advanced to visit your site.

Of course, the browser audience will vary based on the content — here at Wired, most of our mobile visitors use iOS devices, and the bulk of the rest use Android. But for a non-geeky site, things will skew more towards mobiles with clunky browsers.

140 slides, takes 10-20 minutes to flip through. Best viewed in Fullscreen mode.

See Also:

File Under: Mobile, Multimedia

TinySrc Shrinks Your Images for Mobile Browsers

If you’ve played around with optimizing your website for small screens, you know one of the big headaches is resizing images. You can set the viewport in your head tags to make sure your main content is the focus on mobile devices, but you can’t easily shrink images.

On many mobile devices, rendering the images is what slows down page load times. That’s where TinySrc comes in. It’s a clever service that parses your images and presents scaled-down versions to mobile devices.

Using tinySrc is pretty simple, all you need to do is prefix your image URLs with the tinySrc domain, something like:


http://i.tinysrc.mobi/http://foo.com/foo.png

TinySrc will then detect the device that’s visiting your site (tinySrc has partnered with Device Atlas so its device listings are extensive) and serve out an appropriately shrunken version of your image.

If you’d like complete control over the size of your images, you can specify parameters in the URL. For more details on all of tinySrc’s settings see the documentation.

While you are relying on a third party service — a choice which always carries the usual concerns about speed and reliability — tinySrc is definitely one of the fastest, easiest ways to shrink your images for the small screen.

[via Ajaxian]

See Also:

File Under: HTML5, Mobile, Web Apps

How Do Native Apps and Web Apps Compare?

Two roads diverge on a tablet screen. One is the path to the native app, the other leads to the open web.

Luckily, you can take both. The latest mobile devices ship with a thoroughly modern browser capable of handling emerging web standards. Beneath that is a modern operating system with access to the magic inside the hardware: the camera, GPS, gyroscope and compass. But if you had to pick one — native app or web app — which would you choose? Your decision will make all the difference in how you approach your design, development and distribution.

The Issues Native Apps Web Apps
Internet access Not required Required, except for rare apps with offline capability
Installation/updates Must be deployed or downloaded Hit refresh
User interface Native apps are responsive and functional Browsers can be clunky, but new advancements in JavaScript like jQuery Mobile are catching up fast
Device compatibility Platform-dependent, hardware-dependent Platform-agnostic, content can be reformatted with CSS to suit any device
Animation/Graphics Fast and responsive Web apps are getting closer, but will probably always lag
Streaming media Few problems with audio and video. Flash works, but only if the device supports it Flash works where supported. Browser-based audio and video are getting there, but still beset by compatibility headaches. Give it a year or two
Fonts Tight control over typefaces, layout Almost on par, thanks to advancements in web standards. Give it six months
Is my content searchable? Not on the web By default
Sharable/Tweetable? Only if you build it in Web links are shared freely. Social APIs and widgets allow easy one-click posting
Discussion and collaboration Only if you build it, and it’s more difficult if data is disparate Discussion is easy, all data is stored on a server
Access to hardware sensors Yes, all of them: camera, gyroscope, microphone, compass, accelerometer, GPS Access through the browser is limited, though geolocation is common
Development Specific tools required for some platforms (like Apple’s). You have to build a new app for each target platform Write once, publish once, view it anywhere. Multiple tools and libraries to choose from
Can I sell it? Charge whatever you want. Most app distributors take a slice, up to 30% Advertising is tolerated, subscriptions and paywalls less so. No distribution costs beyond server fees
Distribution Most app stores require approval. And you gotta wait No such hassle
Outside access to your content No, the reader must download your app Yep, just click a link
Advertising Control over design (though limited in iAds) and rate More choices for design, plus access to web analytics. Rates vary widely

See Also:

File Under: JavaScript, Mobile

iPhone ‘Pull To Refresh’ in JavaScript

When it first arrived in iPhone apps, the simple “pull to refresh” action was instantly hailed as a genius bit of user interaction engineering.

It’s an ultra-intuitive way of refreshing the displayed page content by simply pulling the page down with your thumb, then releasing it — sort of like pulling a lever on a slot machine. The official Foursquare and Twitter (nee Tweetie) apps use it, so if you’re into social networking, you’re already familiar. But so far, its use has been limited to native apps.

Now developer Wayne Pan has created the same behavior in JavaScript for use in web apps. It’s just a proof of concept implementation at this time, and he’s found some of the limitations.

Point your mobile browser at waynepan.com/s/pull to test it. It’s a little jerky, but it does work. And his code doesn’t rely on any JavaScript libraries, so with a little tweaking, this behavior can be integrated into any web app and will work on Android and iOS devices. Nice work!

[Hat tip to Dion]

See Also:

File Under: JavaScript

Video: jQuery Gurus Talk About Mobile, the Future

Here’s a short video about the future of jQuery, our favorite JavaScript library for creating rich, animated site interactions.

The interviewees are Mike Hostelter and Jonathan Stark, co-founders of appendTo, a consulting company that trains and supports jQuery programmers. The video was shot this week at O’Reilly OSCON 2010, taking place in Portland, Oregon through Friday.

In the interview, they talk a little bit about what’s next for the jQuery Core group — currently, jQuery creator John Resig is auditing mobile browsers to build more mobile features into jQuery, making it easier for JavaScript developers to make HTML5 iPad and smartphone web apps that are more “appy.” Also, there ultimately won’t be a separate pack for mobiles and desktops — the future of jQuery is one code library that works on all browsers and all devices.

See other OSCON 2010 videos on O’Reilly’s YouTube channel.

See Also: