Project Liike (LEEE-keh)

Mobile Development: Detecting Devices & Features

2011-10-19T16:01:00-07:00

Take this post cum granlis salis. I’m trying to figure this stuff out and I’m thinking out loud.

Background

Whenever a browser makes a request, it includes a string identifying itself to the server. We commonly refer to this as the user agent string. This string identifies the browser and the platform and the version and a great deal more such nonsense.

This sounds great in theory. We should be able to use this data to optimize what’s being sent to the (mobile) browser. However, there’s been something of a sordid history for user agent strings. In retrospect, we’ve realized that user agent sniffing is a tool that has often hurt more than it has helped.

We’ve learned to favor feature detection over browser detection (or device detection). Take a look at modernizr and haz.io for more on the that front. The success of feature detection has also resulted in a shift from server logic to client logic. We detect features on the client but we detect user agent strings on the server, before we send anything to the client.

How does all this play into the mobile web? One of the key mobile features we are interested in is screen size. Luckily for us, the W3C has blessed us with media queries. In a nutshell, media queries allow you to conditionally apply CSS based properties of the display device. This has given rise to something known as Responsive Web Design. Responsive Web Design is about having a single set of markup whose layout can respond to the device’s display capabilities. Unfortunately, there are a few rough edges with this approach.

Moving Backwards…

In the mobile world, client-side feature detection has a few drawbacks. It requires extra code to be sent to the browsers and it takes additional processing on the client. It’s also likely that you’ll end up sending more than is really needed (or that you’ll need to make additional requests).

One solution to this conundrum is to use the open source “database” called WURLF. You can query WURL with a user agent string and it will return a set of capabilities. I think of it as feature detection on the server. Though admittedly it’s a bit misleading to call it that.

This means your server can ask questions like “Does this client support HTML5? If no, what do they support?” before the first response is even sent.

WURLF has commercial support and a C# API. For ASP.NET developers, 51Degrees has an open source project called Foundation that is built on top of WURL. It uses an HttpModule to automatically query WURL and populate the Request.Browser. Setting up WURLF without Foundation takes a little bit more work, but not too much. Both are available on Nuget: WURL and 51Degrees.

What should you do?

I don’t think that there is a cut and dry answer at the moment. What you do depends heavily on your target audience. If you are targeting the North American market there’s a good chance you’ll be okay with a single set of markup, going with a responsive mobile-first design. In other words, there would be no need for something like WURLF.

However, you might need a very broad reach or you might be targeting a market heavy in feature phones or something else that’s very different from North America. In those cases, it is good to understand your options.

Christopher Bennage, cross posted from dev.bennage.com.

The Doc Repo is Live

2011-10-03T13:53:00-07:00

As we begin our investigation into the specifics of tools, frameworks, and existing guidance, we’re capturing our learnings on our brand new docs repo. Over time we’ll be including small topics and other written content.

Don is also maintaining a delicious stack called Mobile Web Dev to keep track of good articles and links. If you have any choice links we should know about, throw them in the comments below.

We Liike Mobile Web Dev

2011-10-01T08:51:00-07:00

Over the past month I’ve had some conversations with some Microsoft customers, product teams, and some field consultants to help us decide if we should invest in producing guidance for building mobile web apps. Everyone agreed this would be useful to customers, useful to Microsoft, and it’s a space that actually warrants guidance. So it looks like we’re on!

The plan is for Chris to be the dev lead with me playing the PM role. Other team members will join us after we define more project specifics. So yesterday Chris and I arrived at what we think would be a reasonable scenario. Try this on for size:

Customer: We have an existing solution (content and application logic) built using web technologies and we’re considering an effort to explicitly expose it to mobile devices. What do we need to know to be successful?

Yes, this is still pretty broad, but it allows us to start small and pragmatic. Plus, the real specifics are in the questions we’ll be trying to answer. Maybe questions like:

Which existing assets can I reuse? And how?
How can I make the experience available offline?
Should we do device detection or feature detection? How?
How to accommodate for various screen sizes across devices?
When should I consider PhoneGap or a native solution?

Of course these are just examples. What we really want to hear are the questions YOU think are important, or were important when you did it. We’ll be posting a survey soon with some suggestions and a chance for you share so we’ll have a prioritized backlog to work from.

As far as deliverables go, we’re planning to produce two things: the source to a mobile web solution and a set of written content to describe what we learned along the way. The solution will likely be derived from Project Silk’s Mileage Stats reference implementation and the written content will either be a set of articles or chapters in a book depending on how far we decide to take it. Anything else you’d like to see?