This is Swipe, a blog by pinch/zoom about mobile, design, user experience, usability, development and the future of technology.
An very detailed run through on how to setup, scaffold a HTML5 Mobile app with Backbone.js and jQuery that doesn’t require hacking into the jQuery source.
Trove did a survey on Hacker News on what was the most painful part of API integration. They have since published their results, which every company should pay attention to. API integration (namely your own) is the most expensive aspect of mobile development.
Consider Trove’s list of “Biggest Headaches” as your starter list of requirements for any mobile app:
I definitely agree with the point of this article when it comes to mobile, assuming you have someone that can lead the vision.
This WebKit only version of the Kindle reader shows what type of reading experience one can create using HTML5. Our own framework is in private beta now, and will be available soon.
PPK has culled together the top mobile browsers in 12 countries around the world. The report is spilt up into two parts, both available now.
Interesting insights on the effects of poor usability.
“I found that most of the unhappy customers had one bad experience […] and then just left. They didn’t keep hammering […] where they had the bad experience, heck they didn’t even respond again. Neither did they e-mail us to “escalate” the matter.”
We certainly saw this effect in mobile during usability tests for the BBC iPlayer.
Like everybody, we’ve been watching the chaos and vandalism of the London riots with horror and sadness. We’ve been reading the media reports on how the riots have been spreading via social media such as Twitter and Facebook. There’s definitely been a lot of Twitter conversations happening, although this appears to be more people condemning the riots and discussing them rather than inciting further looting (of course, we don’t follow many teenaged London hoons).
The Guardian reports that Blackberry Messenger has had a large part to play.
Using BlackBerry handsets – the smartphone of choice for the majority (37%) of British teens, according to last week’s Ofcom study – BBM allows users to send one-to-many messages to their network of contacts, who are connected by “BBM PINs”. For many teens armed with a BlackBerry, BBM has replaced text messaging because it is free, instant and more part of a much larger community than regular SMS.
This is where it gets interesting:
Unlike text messaging or Twitter, BBM is a free, private social network where almost all messages are encrypted when they leave the sender’s phone – meaning that many messages are untraceable by the authorities.
RIM can be legally ordered to hand over details to police of users suspected of unlawful activity. However, the Canadian company would be likely to resist those demands and the content of users’ inflammatory messages would be encrypted. The manufacturer has previously insisted that even it cannot unscramble users’ messages when sent on the devices.
According to a news report, this is one of the mass BBM’s that went out to multiple users:
“If you’re down for making money, we’re about to go hard in east london tonight, yes tonight!! I don’t care what ends you’re from, we’re personally inviting you to come and get it in. Police have taken the piss for too long and to be honest I don’t know why its taken so long for us make this happen. We need a minimum of 200 hungry people. We’re not broke, but who says no to free stuff. Doesn’t matter if the police arrive cos we’ll just chase dem out because as you’ve seen on the news, they are NOT ON DIS TING. Everyone meet at 7 at stratford park and let’s get rich.”
It appears the rioters were aware that their messages were encrypted and untraceable by authorities. RIM has come under fire from police before for encryption and lack of traceability in their messenger service, however is has now become a powerful and emotive issue and I predict some soul-searching and policy changes in the RIM offices today. A British MP has called for RIM to suspend BBM to prevent further rioting in the area.
RIM’s blog was hacked yesterday, with a threatening message posted warning RIM to not cooperate with police.
“You Will NOT assist the UK Police because if u do innocent members of the public who were at the wrong place at the wrong time and owned a blackberry will get charged for no reason at all. If you do assist the police by giving them chat logs, gps locations, customer information & access to peoples BlackBerryMessengers you will regret it, we have access to your database which includes your employees information; e.g – Addresses, Names, Phone Numbers etc. – now if u assist the police, we WILL make this information public and pass it onto rioters”, said the message.
There is already a mass social media effort to identify rioters, with tumblr, flickr and Facebook groups gaining momentum.
Over the past year I’ve been pretty hard on HTML5 Mobile Apps. The general perception is that HTML5 will provide companies with a scalable and flexible cross-platform mobile app strategy. While I firmly believe in the principle of web technologies as a platform on mobile devices, we just aren’t there yet.
I worry that people underestimate the amount of effort that is involved before they get started down the path of HTML5 for mobile. Trying to debate the pro’s and con’s of the approach often sound like Mr. Waturi’s famous phone conversation from Joe versus the Volcano
“I know HTML5 can get the job but can HTML5 DO the job? I’m NOT arguing that with you. I’m not arguing that with YOU. I’m not ARGUING that with you. I’m not ARGUING that with you Harry! Harry… Harry… Yeah Harry… but can HTML5 DO the job. I know HTML5 can GET the job but can HTML5 do the job?”
(BTW one of the best movies ever!)
To be honest I’ve really been struggling over the last year to educate customers on some of the realities of HTML5 as a mobile platform (something I’ll try to articulate in future posts). I feel like it often comes down to Mr. Waturi’s tedious cyclical debate that has more to do with our belief and faith in HTML5 more than the evidence.
We all agree HTML5 can get the job, but can it DO the job?
For some background, I’ve been building products for mobile using web technologies since day one, over ten years now. I’ve been a vocal part of every mobile web movement to date. I even wrote a bestselling book about how to design and development mobile web apps. Over the past two years pinch/zoom has been doing a lot with HTML5 in mobile (and the “mobile web” before it) for some of the largest brands on the planet. Over the years we’ve learned a lot.
So what does it take for HTML5 to DO the job? This is the question we find a lot of companies asking themselves these days. Enter the Anatomy of a HTML5 Mobile App, our “stack” for building HTML5 Mobile Apps.
Consider this as a starter roadmap of the tools and technology needed to create a cross platform mobile web strategy. This is why HTML5 Mobile Apps are hard. In many cases you will need to create every part of this diagram. If you don’t create it, you can borrow it, but you’ll still need to test and debug each piece.
It all starts with the user making a request to view content on a mobile device. This request will be some sort of HTTP request that will hit a web server. In most cases this will be dynamically generated content. To render content into the app will need need at least two things, data and how to make that data meaningful, or our HTML5 app.
Since all devices are unique in one way or another, it highly recommend that you also have a server-side device detection solution in place as well. There a number of ways to do it and will give you a lot more detailed information about the device and it’s capabilities.
Foregoing this step implies that all devices can be treated equally. This can be true for very simple experiences, but from my experience this won’t hold water for very long on most projects.
For more on dealing with devices, pinch/zoom’er Scott Gledhill has been creating short tutorials on mobile topics he calls Mobile Bits
15% of all mobile apps launch when they the device is offline. So it is also likely you are going to have deal with the offline data experience as well. Your data architecture is most certainly designed to deliver pages over the Internet, but what happens when access is lost? How do you plan to anticipate the users data needs while they are online, provide them with a great offline experience, then sync everything together when they are back?
I’ll talk about cache manifest in a minute, but for now keep in mind that cache manifest will only get you so far. You will likely need some sort of RESTful API on top of your content to deal with data sync as well.
With a plan to deal with data and devices in hand, the next step is to create your HTML5 app. This is probably the easiest part. HTML5 is an evolutionary technology and if you know HTML, then chances are you’ll understand what’s new in HTML5 in under an hour.
For a quick overview of what’s new in HTML5, check out these fine resources:
There are a lot of handy new features to HTML5, but honestly isn’t that much difference between how we made mobile apps five years ago versus how we do it now – at least from a markup perspective. There are a ton of other things we can do with HTML5 using Javascript and CSS3, however the markup itself it is still just content wrapped in tags to be made meaningful and little more.
Probably the best feature of HTML5 for mobile is the cache manifest also referred to as the app cache. This is a simple text file that lists out the files you wish to cache locally. This is handy for storing the common Javascript, CSS and images files that you will use for your app in the devices memory. Therefore if the user goes offline a lot of your required interface elements are still available.
Even if you aren’t planning to take your app offline, the cache manifest is an easy way to reduce the number of network connections required. Getting dynamic data cached is an entirely different matter and typically falls into using Javascript to do your data sync, not the cache manifest.
And remember that having your app work offline – at least in some degree – is a requirement for most app stores. So make sure you don’t overlook this step.
Lastly, don’t forget that not all mobile devices are equal. Even if you plan to only support one platform, there is still a lot of uniqueness between devices, versions, carriers, etc. In mobile having bulletproof code is always the best fallback in case something doesn’t work as expected. In other words keep it simple and don’t rely on bleeding edge techniques that has meager or unknown device support – a concept known as graceful degradation.
In the case of HTML5 my best advice is to keep code very semantic. Write all your markup first without any CSS or Javascript. The resulting markup should always be perfectly usable in its lowest form.
Alright, now it comes to the big daddy, Javascript. When I wrote my book a few years ago there was very little to be discussed around cross platform Javascript (for that matter there wasn’t much to be said about HTML5 at the time either). A lot has happened since then. In just two years, Javascript has gone from spotty mobile support (outside iPhone) to the primary means in which we provide data, logic and interactions to users.
This sea change is happening at the same time as the transition to HTML5, so it is no wonder that people are conflating the HTML5 with Javascript. In other words HTML5 has many new features, but very few of them cannot be used if Javascript is absent. Can you look up the users physical location? Yes, with Javascript. Can you store data in offline storage? Yes, with Javascript.
For some this distinction may be slight, but I believe it to be quite significant. Remember before the days of Javascript frameworks like Scriptaculous, Prototype, MooTools and jQuery? I don’t think anyone claimed to like writing Javascript – it was a chore. While these frameworks have undoubtedly made all our lives easier and changed the face of the web, many developers can’t write Javascript without the aid of these frameworks
In mobile this is a problem. The most difficult and time consuming aspect of mobile web app development is testing. Every piece of technology you use has to be testable. If you don’t know how something works, you create a black hole of time and effort to trace through hundreds of lines of code to find a simple bug.
If you are only planning to support one platform this might be tolerable, but the complexity of supporting multiple platforms can add an order of magnitude of time to your development and test effort.
Murphy’s Law – that states “anything that can go wrong will go wrong” – is the only mobile development and testing principle that I know with absolute certainty is true. At pinch/zoom we don’t take this de facto law of mobile testing lightly – if we commit to using something, then we are also committing to fixing it if it breaks (something we are often contractual and professionally obligated to do).
So let’s dive into the three parts of the Javascript stack to see what is required.
These scripts bridge the gap between your core scripts and the device SDK. A necessary step if you plan to ship your HTML5 app in a native wrapper like UIWebView or PhoneGap. Your hybrid scripts may need to be distinct for each platform you plan to support (as far as I know phonegap.js is the only generalized script that works on multiple platforms in a hybrid context).
Your core scripts are the common components of your app that will be available in every platform. It will also serve double duty performing the functions a native SDK would perform if the app is accessed through a web browser. Think of this like the internal logic that your app will require to assemble and render your HTML5 pages. This is where a full framework like jQuery comes in handy, though we typically recommend micro frameworks for most jobs.
Lastly you have your device scripts that work to emulate native behaviors of the device with Javascript. Probably the best example that comes to mind is jQTouch that uses jQuery to mimic iPhone native behaviors and animations. However since jQTouch doesn’t make a distinction between devices, it uses iOS methods for Android and other mobile platforms as well. Something users of these other platforms don’t love. Therefore we can assume these scripts will need to be unique to each platform we plan to support.
The CSS is the presentation layer of your app. Technologists tend to dismiss CSS as a chore for designers to create around our application, like the art student in a computer lab. However the presentation is the most important aspect of a HTML5 Mobile App.
Companies like Apple, Nokia, Microsoft have spent millions to create a great mobile user experience so you don’t have to (and yes, the others are omitted intentionally). That means if you create a HTML5 Mobile App you need to create your own experience, often from scratch.
Meeting today’s customer demands of mobile experiences is not a trivial task. The CSS is the code that you will use to meet this high expectation.
If your HTML5 app were a car, then the CSS would be more than just the make, model and color, it would be the interior detail as well. When you sit inside you’ll notice more than just fabric or leather. We notice the attention to detail. How it feels to hold the steering wheel in your hands, the dashboard design, the distance to the stereo controls. All of these factors influence our driving experience.
Javascript definitely influences our experience as well, but they are the machinations out of view. We absolutely need it to be there, but as any Top Gear fan can tell you – power under the hood doesn’t always equal a powerful experience (as seen in this first half of Jeremy’s review of the Ferrari 599 GTO).
Both the performance and presentation must work harmoniously with each other (as seen in the second half of the 599 GTO review).
When I talk to those interested in using tools like jQTouch, Sencha Touch or jQuery Mobile I ask them what exactly do the plan to get out of these frameworks. More often than not it is actually the “Device Theme” stylesheets that emulate the primarily iOS aesthetic, plus the few lines of Javascript that perform the CSS Transforms that mimic iOS transitions, and little else. Few seem concerned about using CSS to emulate any other device aesthetic. (try finding a CSS template for Android)
But chances are you want your app to be distinct from other apps and you’ll want to break away from default aesthetic and adapt the tools to meet your own brand styleguide. Therefore you need to consider the full CSS stack when planning for your app:
As mentioned above, this is the CSS that will be required to mimic the platform aesthetic. This is the visual language the user is accustom to. They use this language to spend time performing tasks instead of learning your interface. While not required, by recent count, there are over 100 unique interface elements to each platform. I wouldn’t recommend inventing your own language unless you know what you are doing.
Sencha Touch, jQuery Mobile and others have done this work for you, but then your app looks like their platforms, not your own. However using these tools as a starter can be the best route if you plan to construnct your own language.
The core theme is the resuable “furniture” of your application – the stuff you need, but don’t typically see. I like to seperate presentation essentials like resets, layouts, typography, color and image handling to a unique stylesheet that will serve as my core or brand theme. These are the elements that should always be the same regardless of what platform you use. A simple example: your logo will likely always be presented the same way. While your toolbar color might be your brand color. Both of these elements would be defined in your Core Theme. However in your Device Themes you might add a gradient effect over your toolbar for iOS, which will be absent on Android.
Finally you have your App Theme which is the presentation elements that are specific to your app. Many projects tend to incorporate these elements into one stylesheet, which is fine. However I recommend keeping your Core and App elements at least somewhat seperated conceptually. This will come in handy for debugging later.
So can HTML5 get the job? Of course, I’m not arguing that with you.
Can HTML5 do the job? Absolutely, but…
Watch the pinch/zoom team discuss HTML5 on The Context.
A new kid on the HTML5 framework block. I have a feeling we will see a lot more of these this year.
Boy Genius Report has a complete round up of what is new.