Native apps Vs mobile web apps: confused?

I’ve recently been discussing a mobile web app module we have in development for our CMS with a number of existing clients and potential new ones and I’ve learnt a few things of late about peoples understanding of mobile applications; that is to say, as soon as I mention ‘native apps’ in the same breath as ‘mobile web apps’ I confuse at least 80% of my audience. It has been an interesting learning curve for me establishing just what level of understanding people have on these two distinct (but similar… confused already?) methods of reaching an audience and delivering content so I thought I’d write a bit more to help clarify a few things in an attempt to aid an informed choice of which direction to take.

What is a Native App?

Generally speaking, if a customer comes to us with a requirement for a ‘mobile app’ most (99%) will be thinking about a Native app. By Native I mean an application built for a specific mobile handset (they will be picturing a shiny iPhone), purchased from and delivered by a central store (they will be picturing Apple’s App Store), installed on the mobile device with an icon on the homescreen with updates managed through the store from which it was downloaded.

Do your clients Actually Want a Native App?

When you delve into what it is the client actually needs, it is not always apparent that a native app is the most suitable or appropriate tool for the job, especially if it is one being developed in a specific language (Objective C for instance in the case of an iPhone) which then needs porting to other target devices (for example BlackBerry, Android and Nokia).

As is often the case, what a lot of people think they need is down to a preconception (often established through marketing, advertising, trends and fads) that one way of doing things is the only (and best) way of doing things. The alternatives are not explored because they only appear on the periphery whereas particularly with the iPhone, iPad and the App Store people have perceived understanding of the end–to-end delivery and usage of a native app.

What is a Mobile Web App?

On the other hand, when I discuss mobile web apps it is clear from an early point in the conversation that most people think I am discussing a native app whereas what I am actually describing is an application developed on the web specifically for mobile devices (at present many sites use the ‘m’ subdomain to host their mobile web apps); to all intents and purpose this website (mobile web app) might look, behave and feel much like a native app but it is accessed through a browser and doesn’t have to be downloaded via an app store. In a lot of circumstances mobile web apps are actually advantageous:

1. You can better manage development across multiple platforms
2. They can look and behave like a native app (even having an icon on the homescreen) so UI/UX can retain a ‘familiarity’ across both types
3. Other than fetching the initial data / framework the app does not have to be online to run (a common misnomer) as content can be cached and we can use HTML₅’s offline mode
4. You don’t have to go through the App Store acceptance procedure and updates / enhancements can be released as and when required (see point one)
5. There is no reliance on someone else’s business model (eg Apple) to monetise your idea
6. You get to keep 100% of the revenue you generate
7. As you will see in the final paragraph, mobile web apps can be packaged as native apps for multiple platforms (eg iOS, Android, Symbian, Blackberry) using mobile frameworks such as PhoneGap and Appcelerator Titanium
8. Applications can be developed more rapidly (see all above)

Native is Still Best (sometimes)

That being said, there is no denying some advantages that native apps (particularly in the case of Apple) have:

1. End users currently better understand the concept (of the store – application – handset relationship)
2. Businesses currently better understand the business model because it is quite simple
3. People feel confident in the application vetting process and therefore have confidence they are not being scammed or having malware/viruses delivered to their handset via the app
4. You can access all the handset features and hardware (eg: the camera, geo locations, graphics acceleration, file system and so on)
5. Monetisation of the app itself – if your idea is to produce an app which makes money just because it sells 1 million copies at 59p then this is the only way you can go

There is a Third Way

Our mobile web application development uses the Sencha Touch framework (a HTML₅ Mobile Web App Framework for touch screen mobile devices). We can expose various methods of our content management system (for getting content or defining functionality) via webservices which take parameters and data and return data in json format (or XML if you desire) to the Sencha Touch application. The framework allows development of mobile web apps and provides a local storage proxy for saving data offline.

The Sencha Touch framework runs on Webkit which is shipped with all the major mobile devices these days (and Google Chrome) so when browsing the mobile web app via a web browser on the mobile handset the user experience is fairly consistent and as previously discussed can very much be like a native app.

However, if you want to deliver your mobile web app as a native app this is now possible using frameworks such as PhoneGap or Appcelerator. In our case we use PhoneGap which allows us to provide native functionality such as access to geo location, camera, storage, contacts and so on (list of PhoneGap supported features).

The steps are fairly easy (paraphrased here):

1. Develop your mobile web app in Sencha Touch (or other)
2. Add any native functionality your require (and is supported by your framework)
3. Package this up for your target device in PhoneGap (or other)
4. Send native app to appropriate store for acceptance testing
5. Sell / provide your app via the app store

See, sometimes you can have the best of both worlds!

Further reading:

http://www.phonegap.com
http://www.appcelerator.com
http://www.sencha.com
http://www.lukew.com/ff/entry.asp?1193
http://www.lukew.com/ff/entry.asp?1264
http://www.uxbooth.com/blog/its-about-people-not-devices

This post was written by Kirsten on May 27, 2011 at 4:03 pm

Accessible breadcrumbs using ARIA

Lately we’ve been working on a lot of content heavy websites here at UV^d, all of which follow the very common hierarchical structure (or taxonomy) of the web: categorised sections, which contain articles of content that are all related to that category.

When we are faced with the problem of having to show a way of navigating this hierarchical structure within our HTML it’s very common practice within our industry to use a breadcrumb pattern of markup. The most common of which up until recently has been to use an un-ordered list element <ul> and the navigation links to be list-items within the list, example of which can be seen here:

<ul>
	<li><a href=”index.html” title=”Home”>Home</a</li>
	<li><a href=”products.html” title=”Products”>Products</a</li>
	<li><a href=“shoes.html” title=”Shoes”>Shoes</a></li>
</ul>

Chris Coyier of CSS-Tricks recently wrote an article on the issues surrounding this age old pattern titled “Exploring Markup for Breadcrumbs“, and suggested some markup solutions to tackle it. As Chris stated the use of a <ul> is

“semantically wrong putting each navigation item on the same hierarchical level.”

The final solution he suggests uses the HTML5 <nav> element to wrap the items, which satisfies our semantic goodness needs denoting that everything contained within it should be treated as a navigation structure, and then uses the rel attribute and the up to indicate the hierarchy on each level:

<nav>
 <p>
  <a href="/" rel="index up up up">Main</a> >
  <a href="/products/" rel="up up">Products</a> >
  <a href="/products/dishwashers/" rel="up">Dishwashers</a> >
  <a>Second hand</a>
 </p>
</nav>

Although this solution is now semantically correct and the rel attribute allows each item’s level to become machine-readable there was something that still bugged me about it, it’s accessibility towards users using assistive devices or screen reading based browsers. The up value is still in debate by the spec editors and isn’t likely to be supported in any screen readers for a long time. After a lot of experimenting and some in-depth discussions with a fellow frontend dev friend of mine Dan Claydon and a sprinkling of ARIA I’ve come to this solution:

<nav role="navigation">
<p id="breadcrumblabel”>You are here:</p>
<ol id="breadcrumb" aria-labelledby="breadcrumblabel">
<li><a href="index.html" title="Home">Home</a></li>
		<li><a href="products.html" title="Products">Products</a></li>
		<li><a href="shoes.html">Shoes</a></li>
	</ol>
</nav>

The advantages of this pattern are:

• The use of the WAI-ARIA aria-labelledby attribute to instruct the user agent to use the label inside the <p> element to label the content of the navigation list
• Semantics: using the <nav> and <ol> elements to create a much cleaner structure to both machines and humans
• Separation of structure and aesthetics. You can use the CSS2 :after pseudo attribute to place the visual > separators after the links. As I am a strong believer that they do not belong in the markup
• You can chose to either hide the label off screen using css (which I have) or leave it if it fits your design and acts as a strong visual clue to everyuser
  Although a more accessible pattern it still brings some issues along with it. The elephant in the corner and its lack of support for HTML5 elements and CSS2-3 attributes (IE 6-8). Unfortunately the only way around this is to use some of the very clever javascript “polyfills” that are popping up all over the web at the moment. Two of our favorites here at UV^d , perfect for this pattern are: Modernizr and Selectivizr
• Modernizr allows you to use advanced feature detection on the clients user agent for progressive enchancement, and also uses a great HTML5 element polyfill which will allow us to style our <nav> element
• Selectivizr combined with your framework of choice (jQuery in our case) allows you to use some of the more recent CSS2-3 selectors in your stylesheets and parses them for the older browsers. Thus allowing us to use the :after pseudo selector for our navigation items

I would love to hear your feedback regarding this pattern and if you have any other techniques to improve the solution, and of course would like to credit Chris and Dan who gave me the inspiration. Below is a list of some further reading around the ARIA spec and accessible forms of navigation.

• ARIA Relationship attributes (i.e. labelled-by)
• ARIA ‘navigation’ role attribute
• An accessible pagination pattern

This post was written by Patrick on May 4, 2011 at 1:08 pm