GDS Design Principles and “Digital Services”

Posted by Mike Brittain on May 02, 2013
Mobile, WWW / Comments Off on GDS Design Principles and “Digital Services”

The UK Government Digital Services has published their Design Principles last summer. It’s a great read. And if you’ve already read it, it’s still a great resource to reflect on. These are principles that would resonate with most of the technical teams I’ve worked on over the past years, though they often fail to appear in the products that are created.

Two principles stand out:

1. Start with (user) needs

8. Build digital services, not websites

The products we build need to solve real needs, rather than expose the organizational concerns or bureaucracies. This is more intuitive for new product start-ups, and less so for legacy institutions who are trying to increase their online presence.

And the products we build need to make sense within the current digital landscape—which is to say, outside (complementary?) services and the wide variety of devices in use by consumers of these services. Form factors—both existing and emerging—and usage context play roles in how we design products.

How do we get to mobile web applications?

Posted by Mike Brittain on December 20, 2012
Mobile / Comments Off on How do we get to mobile web applications?

Anyone who has had a conversation with me for more that 3 minutes about mobile knows that I’ve been a big proponent for the mobile web for years. I believe that mobile web apps have been held back by the proliferation of native app marketplaces, which are highly attractive to developers due to:

– Solid SDKs, some standardized UI components
– Better UI performance, for now
– Marketplaces with integrated payment systems
– Ease of discovery, installation
– Heavy advertising and promotion by carriers and OS creators

After reading Fred Wilson’s post, The Mobile Web, yesterday I finally wrote up a response in the comments. And since it’s surely lost amongst 285+ responses, I’m reposting it here. For context, be sure to read the post.

I’ll preface this response, however, by mentioning that these are pretty big hurdles and it’s going to be a while before we get to the place where the decision to build a mobile web app over a native app is obvious and accepted. There’s technical progress being made, but there is still a vicious consumer awareness and advertising cycle built to prop up the native app marketplaces. That will take more time to unwind.

* Developer Tools and Frameworks. There are a lot of individual pieces, but no single, obvious, and popular framework for building what feels more like an “app” rather than a collection of pages on the web (an earlier comment use the term “card”). We’re competing against the very obvious native SDKs. It *is* possible to write “installable,” offline web applications for mobile browsers, but you still have to cobble together much of the application framework yourself — it’s not yet a well-understood pattern. The HTML5 app cache is not the most wonderful thing to work with, either.

Latency is brought up as an advantage of native over web, I think that’s a fallacy. The tools are just not here to help manage the perception of speed for users. An API call from a native app over HTTP is the same thing as requesting an HTML page — only the page refresh and (re-)loading of resources gives the perception that “the web” is a slow medium.

* Payments. Less a matter of payment at time of download (e.g. App Store) than it is having a single, trusted digital wallet that you can pay from. Tapping out a 16-digit card number, name, expiry, etc. on a handset is a huge barrier.

Try-before-you-buy would be far better to consumers than the proliferation of $0.99 and $1.99 apps that are so cheap that it doesn’t matter if you’ve wasted your money on junk a few times.

* Improved Platform (i.e. Browsers). You can argue that the browser is at a disadvantage from native apps because it is an abstraction from the OS. This is hampered further by lower CPU, memory, battery power — all of which will continue to improve over time. But while SDKs and native apps continue to rule and have an obvious, and working, payment model the innovation in mobile browsers will be slower.

Browsers will need API parity with native SDKs — i.e. access to cameras, audio, location, file storage, wallets/NFC, preferences, notifications, running in background, network detection, etc.. I would expect you’ll see more innovation here within Chrome OS than on the more mainstream mobile OSes.

* Discovery. There’s not a one-stop-shop for native and web apps. The Chrome Web Store is actually decent and provides ties to in-app payments via Google Wallet. Same with Mozilla’s new store, though I’m unaware of any payment service there.

Consumers have been well conditioned by handset makers and carriers that they will get their apps from the major native app stores. We have yet to see marketing like that for mobile web apps. And most consumers will use what is put right in front of them, and what they’re hearing in commercials.


Mobile Sites Proliferate by Category

Posted by Mike Brittain on April 21, 2010
Mobile / Comments Off on Mobile Sites Proliferate by Category

An article on RWW about mobile apps and browser-based sites highlights the different concentrations in categories between native apps and mobile sites.  Native apps are heavily weighted toward games and entertainment.  Mobile web sites are heavily weighted toward shopping and social categories:

… 19% of the mobile sites measured were Shopping & Services sites; compared to 3.6% in the same category in the App Store. Content in the ‘Social’ category also has a higher chance of being a browser-based mobile site, rather than an app (12.9% to 1.7%).

Additionally, Taptu estimates that mobile site growth far outpaces the growth of native apps on any other platform, including the iPhone and App Store.

My position for a long while has been that mobile sites have much better reach due to the ability to access them from any mobile device with a decent browser, without having to download an app.  This makes cross-platform development much easier for existing web teams.  As more mobile platforms take up the WebKit rendering engine, including this week’s report that BlackBerry 6.0 will include a touch browser backed by WebKit, the baseline for development across the myriad of mobile devices is actually much better than what we had with the first web browsers in the late ’90s.

Still, the perception by consumers that apps are hip, as well as aggressive app-centric marketing by carriers, sets a higher barrier for consumers to understand the wealth of mobile sites available to them on their existing handsets.  Visibility is still an issue here.

Tags: , , , ,

Reaction to PPK’s “The iPhone obsession”

Posted by Mike Brittain on February 08, 2010
Mobile / Comments Off on Reaction to PPK’s “The iPhone obsession”

PPK wrote a thought provoking post drawing a parallel between iPhone-specific mobile development and IE6-specific development we saw begin a decade ago and is still, somewhat surprisingly, biting us in the ass.  It’s an important warning to heed, but I think he misses some critical points about mobile web usage trends and dwells too much on a snapshot of current statistics about mobile handset market share.

Why are developers obsessed with the iPhone?

Let’s not mince words.  Mobile web browsing has traditionally been a horrible experience.  I’ve had a couple of what seemed like great smartphones (a BlackBerry 8700 and a Palm Treo 550).  They made me feel like I could use the web, and were better than nothing, but they were still a terrible experience when compared with today’s mobile web.  To deal with the fact that these handsets couldn’t consume all of the image formats, plugins, or even standard HTML produced for the web, the browsers either munged their rendering or made use of proxies that would reformat a web site’s HTML content to be more WAP-ready.  Transfer speeds were also doggedly slow.  It made much of the web accessible, but was a rough ride.

It’s not even worth talking about the people who were making mobile-friendly sites three years ago.  It’s not to say they didn’t exist, but the number of sites customized for mobile browsers at that point is negligible.

The iPhone coming to market changed the game.  Why?  Because Mobile Safari allowed users to see real web sites and not dumbed down version of web pages (well, except for Flash).  Additionally, AT&T contracts for iPhones require data plans.  Most smartphones on the market can be purchased with a contract that doesn’t include web data usage.   I just priced out BlackBerry Tour and Droid Eris (HTC) phones on Verizon and their base package includes no data usage.  You pay an additional $1.99/MB for data transfer.  BlackBerry handsets are huge in the U.S., but they’re simply not for web usage, they’re purchase primarily for email and texting.  (I believe this will change, but RIM needs to massively overhaul their browser architecture to catch up to the current state of mobile browsers being released on other phones.)

The graph below demonstrates the effect of the iPhone on mobile web usage (global).  Click for full size.

Source: Quantcast 2009 Mobile Web Trends Report

I am not advocating that we only design for the iPhone.  Newer mobile operating systems are incorporating WebKit into their default offerings.  Even though the versions of WebKit released on iPhone, Android, Symbian, Palm, etc. differ, they are all starting miles ahead of the mobile browsers from two or three years ago.  If PPK is concerned about developers favoring a technology (as they did IE6), should we be concerned about a dominance of WebKit and an ignorance of everything else?

Trends for mobile web usage

Another problem I have with the article is the statistics that were chosen.  There is too much focus on mobile handset/OS market share and not on mobile web usage.  All of the statistics that PPK chose to show are a snapshot of the current market.  If a web developer took this sort of approach to their web development strategy, they may have concluded in April 2009 that “Internet Explorer 8 only has 3.6% market share, let’s not worry too much about it.” (Source: Net Applications)

Mobile handset/OS market share has no correlation to mobile web usage.  Looking at the stats presented in PPK’s post, Symbian commands 45% of the smartphone market share (I’m fairly sure this is global market share, he made a point of not allowing developers to focus on the U.S. alone).  Contrast that with Quantcast’s 2009 Mobile Web Usage Report which shows that Symbian makes up just over 3% of global mobile web usage (all handsets included).

This graph, again from Quantcast’s 2009 report, demonstrates the mobile web market share (global) of the top handset operating systems. Click to enlarge.

Source: Quantcast 2009 Mobile Web Trends Report

Bottom line: The mobile web is tiny

There’s one more point I want to make, also supported by Quantcast’s report.  Statistics on mobile phone usage and mobile web penetration by market can get pretty heady.  It’s exciting to see all of this growth in mobile.  But the fact is that despite all of the people in the world walking around with their mobile phones, they’re not yet consuming very much of the web.  According to Quantcast, by the end of 2009 mobile web usage accounts for just 0.95% of total web usage worldwide.

Much respect

To be clear, my intention is not to bash PPK. His research, code samples, and compatibility tables are invaluable to the web development community.  I know I’ve used them countless times.  Many thanks!

I also agree with his overall rant, which is that building iPhone-specific sites is a dumb approach.  I hope to write more on that soon.

Additional resources and data

I’ve put a lot of emphasis on numbers I found in a Quantcast report.  Their findings are based on a pixel-based measurement of web usage and report only from sites where their instrumentation is deployed. Concerns I have are whether their measurements are effective on all mobile browsers (including those using transcoding proxies), and whether their measurements would be skewed by higher deployment of their pixels on sites in one global region over others.  It seems, however, that most of the best known operating systems are represented.

I didn’t call out any of the numbers from the AdMob report (listed below) because I don’t believe an ad serving network would have solid coverage of the mobile web, especially not on a global scale.

Below are some additional resources worth reviewing which I read while researching these trends.

Mobile Metrics Report, Dec 2009 – AdMob

State of the Mobile Web, Sept 2009 – Opera

The Mobile Internet Report, Dec 2009 – Morgan Stanley

Tags: , , , , , , , , , ,

Mobile Sites Outpace Native Apps… But What About Web Apps?

Posted by Mike Brittain on February 05, 2010
Mobile / Comments Off on Mobile Sites Outpace Native Apps… But What About Web Apps?

I was excited to read this article about mobile web sites growing faster than native apps, a trend I believe will continue in the future.

Taptu estimates that there are 326,000 Mobile Touch Web sites worldwide, which they say compares to 148,000 iPhone apps in the App Store and 24,000 apps in the Android market. Taptu expects the browser-based mobile web market to grow much faster than the app market.

I’m excited about browser-based apps and the potential of HTML5 as a platform for cross-platform app development.  It’s too bad there’s not a distinction in these numbers between web applications and content sites that simply have layouts customized for display on mobile devices.

Mobile-Friendly, Web Apps, and Native Apps

When the iPhone was launched, Safari became the first mobile browser to really represent web sites as you would see them on a desktop browser.  Before then, surfing from your phone’s browser was a clunky experience with unsupported HTML and CSS features, and web proxies that would reformat or strip out content deemed unfriendly for the mobile browser.  On rare occasions, you might stumble into a site that would push your phone’s browser to a version of the site formatted specifically for display on a small screen.  Today, the term “web app” gets confused with “mobile-friendly” web sites.  I say they are wholly different products.

Native apps are touted for their advantages over web-based apps, which include: 1. better exposure to hardware- or platform-specific APIs, 2. potential for instant revenue streams (payment via app stores), and 3. ability to operate in an offline capacity.

It’s difficult to argue against native apps and games that tie into platform-specific APIs unavailable to web apps.  However, there are plenty of services available for making payments to web sites, but developers need to keep in mind their competition in native apps.  You can’t charge $5/month for access to your web app when a similar app sells for a one-time $0.99 fee through an app store.  Finally, the point of offline access is fairly ironic given that so many native apps are simply wrappers for network APIs and cannot run without a network connection.

So when I talk about web apps, I don’t just mean a mobile-friendly web site.  Rather, I’m talking about the potential to build rich applications that can run in a browser.  Using HTML5 capabilities like offline data storage and object caches, web apps can mimic many of the same features built in native apps but have the ability to reach across platforms and devices.

My own definition of web app an application that:

  1. Is written with core web technologies and runs in a browser,
  2. Provides more utility than simply reading pages of content,
  3. Is responsive to user interaction and gives the same impression that an installed app gives, and
  4. Is device and platform independent, indeed it should be irrelevant whether it is displayed on a mobile phone, a desktop computer, or any other device.

The Web App Findability Problem

Platform-specific app stores have risen up as clearing houses for apps. Users are being conditioned that the term “app” means something you download and install on your phone.  App stores are backed by big marketing dollars and ad campaigns because they provide a competitive advantage for their platform and create new revenue streams.  Web apps, on the other hand, provide neither.

There are online directories of web apps to solve this problem, but these don’t have nearly the visibility or marketing of today’s app stores.  It would be difficult for consumers to even consider web apps when they have a nice, easy shortcut to their platform’s app store built right into their phone. Even Apple, who claimed at the release of the first iPhone that web applications were enough, do not provide a means for finding web apps from their phone.  Indeed, their own web app directory doesn’t render in a mobile-friendly format.

Visibility is a key barrier for web apps.

Where Will Web Apps Get Their Exposure?

I’ve thought over a few possibilities for building the web app market, which are outlined here.

First, app stores could expand their listings to include web apps. There are already plenty of free apps in the stores.  Web apps would not create any new low price points.  I see business concerns with this direction, though.  App stores have their own services to charge for paid apps at the point of purchase.  A web app is never downloaded, so it is difficult to charge a toll for access.  Furthermore, web apps might require subscriptions or usage fees, but would be open to choose from a variety of payment gateways.  Owners of app stores would likely see this as losing out.

Search engines could provide niche listings for web applications in the same manner that news, shopping and image search reasults are handled by Google.  Search engines are supposed to provide unbiased rankings and could probably fit an app directory well.

The last idea would be to identify web applications using a new “.app” top-level domain, similar to the .mobi TLD used for mobile compatible sites.  The term “app” has already become part of the vernacular and its use as a TLD could easily identify a URL as a pointer to an application (desktop or mobile) as opposed to just mobile-friendly web pages.

Tags: , , , , , ,

Leaner iPhone Interfaces with CSS Gradients

Posted by Mike Brittain on July 05, 2009
Mobile / Comments Off on Leaner iPhone Interfaces with CSS Gradients

I started playing around with Safari’s CSS gradients yesterday to see whether they would be usable on One tsp.’s mobile interface.  Looks like there has been support in WebKit for about a year now, but I don’t know specifics about how that translates to versions of Safari and other browsers built on top of WebKit.

The demos seemed to work for me in Safari 4 and in the latest version of mobile Safari built into the iPhone 3.0 OS.  I tested the 2.0 OS and it did not support gradients. I don’t know what support the Palm Pre browser has available.

This looked good enough for me, through.  Much of the interface for One tsp. is already taking advantage of a few CSS extensions with varying support.  The interface looks its best on modern browsers (IE excluded) but is still totally usable everywhere else.

So what’s the difference?

I’ve only replaced one gradient background so far, but I’m stunned.  By defining the gradient in CSS, I’ve added just 92 bytes to my style sheet.  This allowed me to remove the background-image rule I had in place to load an image file, which was 50 bytes.  The image file that is no longer needed was pretty small (635 bytes) but also meant another external request that needed to be made.  When we’re talking about a mobile device, extra requests can have a high latency — worse than what we typically think of for the web.

These are pretty small numbers, I’ll admit.  But assuming I have six gradients defined per page, the net savings would be trading around 4 KB and six additional requests for about 260 bytes and no additional requests.  That’s pretty cool.

Faster Mobile Interfaces

Successful mobile web applications need to be super fast. Users trading a native app for a web app will expect it to be responsive. Speed can be improved through faster server responses, low mobile network latency (which we have little control over), fewer and smaller requests to the server, and cacheability on as much content as possible.

Rounded corners and background gradients are two frequently used interface styles that can now be achieved directly in the browser using CSS, eliminating the need for many additional image requests.

Tags: , , , , , ,

Mobile OS Upgrades and Web Applications

Posted by Mike Brittain on March 19, 2009
Mobile / Comments Off on Mobile OS Upgrades and Web Applications

PC Magazine has an article on how mobile upgrades should be done (how Apple is getting it right).  This is something that has really ticked me off about other mobile operating systems, and why I think a lot of web application developers will tend to choose the iPhone as a platform of choice.  With Apple/iPhone, I can develop using (desktop) Safari as a test environment and open up the SDK to test mobile Safari with faith that my app is going to run well on any of the millions of iPhones in the wild.  That’s because the “wild” for iPhones is not all that wild.  It’s actually pretty standard.

Compare that to BlackBerry.  When someone asks me, “does One tsp. (my recipe app) work on a BlackBerry,” I have to say, “well, that depends.”  I’ve basically given BlackBerry users the stripped-down version of my mobile site because to support BlackBerry means supporting a whole range of BlackBerry web browsers that have been created over the last three years, or so.  If RIM upgraded their browsers on each of their mobile devices when new versions became available, then maybe we’d have a platform I could support.

If anyone has tips or suggestions for testing web applications across different versions of BlackBerry browsers, I would love to hear from you in the comments, or find me on twitter at @mikebrittain.


How to Improve JavaScript Latency in Mobile Browsers

Posted by Mike Brittain on January 20, 2009
Mobile / 2 Comments

Mobile browsers are really coming along.  Mobile Safari is built on top of WebKit and has just as much capability as the desktop version.  Same with Android’s browser.  Blackberry’s browser, I understand, has improved tremendously over previous versions.  The new offering from Palm centers application development around web technologies HTML, CSS, and JavaScript.

As more applications and data grow to live in the cloud, then access to them via a browser must be easy and fast, which is often not the case with data on mobile devices.  A web site can take many seconds to several minutes to load all of the content required.  And at the heart of many sites these days lie some common elements — JavaScript libraries.

Personally, I have avoided heavy-weight libraries for mobile application development, because I know that they are a burden to the end-user.  This is less often the case for desktop users, who typically have broadband connections at home or at work.  So what do we do to improve this situation?

I propose that the mobile browser makers (or OS makers, in most cases) embed standard versions of common JavaScript libraries within their browsers.  Google already makes a number of these available as a hosted solution for web application developers: jQuery, YUI, Prototype,, etc.  Other players, particularly in the CDN space, could also become involved in hosting these frameworks.  Nearly half of the libraries that Google hosts are larger than the 25 KB cache limit in mobile Safari (for example).  By embedding a handful of these libraries, mobile browsers could speed up some of the overhead of mobile applications that rely on Ajax or heavy DOM manipulation.

How would you do this?  Likely by inspecting HTTP requests by URL.  Google’s hosted libraries include version numbers, which allows developers to peg their work to a specific version, not having to worry about quirks in future versions that could upset their apps.  When an application makes use of one of these embedded libraries, the browser can simply execute the JavaScript library without having to make an external request.  If the application uses a newer version that is not embedded in the browser, the HTTP request would proceed as normal.  End users would get a slower experience than with an embedded framework, but that experience would be no worse than we have now.

I’m interested in hearing others’ thoughts about this idea.

Tags: , , , , , , , , , , , ,

Why Android is Important

Posted by Mike Brittain on January 20, 2009
Google, Mobile / 2 Comments

I was in a conversation the other day about mobile platforms and the topic of Android, Google’s mobile OS, came up.  The general outlook was: new, interesting, but too few devices to be concerned about.

I’ve read a modest amount of material about Android, but the sense I have is that Google is at the tip of the iceberg right now.  Sure, only one device has been rolled out to date, and only through T-Mobile (bleegch).  But more devices seem to be in the works, currently abroad, but certainly more in the United States soon.

The thing that is interesting, however, is that this is an OS that is (or can be) geared for devices other than cell phones, including netbooks, TVs, and kitchen appliances.  It has great reach potential, which has not been demonstrated (yet) by other players.  That is something to be considered by developers who are thinking about the next big mobile application to develop — because you might just find yourself playing Scrabble on your fridge while you’re waiting for the water to boil.

Tags: ,

Mobile Connect: Call for Speakers

Posted by Mike Brittain on January 14, 2009
Mobile / Comments Off on Mobile Connect: Call for Speakers

TechWeb announced their Mobile Connect conference, which I’m playing a very small part in helping to organize.  The call for speakers is currently open through Jan 31 if you’re interested in being a part.

Tags: , ,