Posts Tagged ‘mobile web’


Apple Watch – A sceptical badger’s experience

by Jun Taoka


It’s been one month since I have started wearing the Apple Watch. From the outset I was a sceptic; my general lack of faith stemmed from seeing a former colleague use the watch on a phone call. Awkwardly speaking in to the device, he would frantically raise his wrist to his ear for the response. It wasn’t that he just looked completely ridiculous, but I couldn’t see the sense or value in it, and it left me with a rather cynical thought;

Could it be that new technologies are actually regressing our forms of communication all in the name of progress? 

Sure enough, the appeal and abilities of the Apple Watch extend far beyond replacing the phone for conversation, and with an open mind I explore how it might improve my everyday life. I’ve been wearing the 38mm sized version, the smaller of the two options available. Aesthetically, the face looks stylish, although I can’t say the same for the white silicon strap. The screen is high quality, colours are sharp and text is crisp on the small scale, partly thanks to San Francisco, Apple’s new typeface. To navigate, the digital crown is an intuitive tool, a clever nod to its mechanical predecessors.

First Impressions

The screen is activated as you turn your wrist to face you, and you can customise how simple or complicated you want the watch face to appear. Swiping up from the main screen activates a dashboard, which summarises ‘glances’ – top-line stats or feeds from my selected apps. I like having the weather update in my glances, which is useful before stepping out the house in the morning. Also among my glances is the music app, which allows control of my music from my iPhone without having to take my phone out of my pocket – particularly handy on the crowded commute. The native Activity app keeps record of your calories burnt, minutes spent exercising and reminds you to stand at least once an hour. I’ve never been one for tracking my exercise as I’m naturally active, but for those who are keen to improve their fitness I can see its value and I do appreciate the reminder to stand, given the slump I easily fall into sitting at my desk.



The Apple Watch is able to take photos from the iPhone remotely. Here’s the happy design team out on a lunch trip. Goodbye, selfie-sticks. 


Double tapping the crown will take you to the last viewed app, which aids continuity in your task flow, whether it be returning to a news feed, inbox or map. Holding down the crown will activate Siri, which I have only genuinely found helpful for setting reminders for tasks at a particular time. Message notifications come in through a vibration, which can then display when looking at the watch. Surprisingly, I do find myself enjoying the ability to quickly read messages on the watch, and although it’s only a tiny inconvenience to grab your phone, somehow I find it less interrupting when I’m in the middle of a task or on the move. Receiving multiple messages at once is a bit unpredictable though, and often these messages can’t actually be read. In turn I’ll have to look at my phone, resulting in a frustrating and disjointed experience.


One crisp Autumnal morning I take the watch out for a run with the Strava app. Unlike fitness trackers, the Apple Watch doesn’t have an internal GPS. This means that if you intend to keep record of your route, you’ll need to carry an iPhone with you. I start running and with the press of a finger the timer starts ticking along with my speed and distance covered, which is all presented clearly enough to take in at a moments glance. Trying to change song track while in Strava was a problem, though. Navigating is just too fiddly if you’re not stood still. It’s certainly a nice-to-have pairing, but if I were a serious runner I might consider buying a GPS fitness tracker and a light MP3 player for simplicity’s sake.




Having read positive reviews, I try Google Maps, one of the more popular apps for the watch. Once I set my final destination using the iPhone, I tuck it back into my pocket. In theory, this should allow me to glance at the watch when I am notified for simple directions, rather than being glued down to my phone, helping me avoid oncoming lamp posts and commuters. The thing is, because my internal compass isn’t actually calibrated with my iPhone, directions like “Head East towards X Street” are rendered utterly useless. Instead, my colleague takes charge and leads us through some scenic London shortcuts. This is a bit of a shame, since the technology is ready, but the usability is let down by the execution.

In its early stage, apps for the Apple Watch seem to be in varying stages of development. The BBC app for example is excellent at summarising succinct headlines, which you can then read in further detail or open the full article on your iPhone. The Guardian, on the other hand, has a beautifully designed app on the phone, but is appalling on the Apple Watch. Publishing only one article at a given time and removing any control of browsing content leaves me feeling disempowered and discontent.

Final Thoughts 

The Apple Watch feels like an incomplete product, a prototype in its infancy still testing the waters, or maybe a strategic move for Apple to assert its stake in the market. Generally, I find it too delicate to navigate between apps, and the apps themselves often take a few seconds too long to sync with the iPhone. At other times I don’t find it sensitive enough; a casual glance at the time won’t work and you’ll sometimes find yourself doing a double take to ensure it displays. Although slight, the momentary delay between flicking your wrist and reading the time creates a small and unnatural disruption in fluidity.

With the development of better considered apps and hardware, such as integrated GPS, smart watches are likely to become more versatile and seamless in our everyday lives. Indeed, wearables in general and their interaction with ‘The Internet of Things’ are likely to shake things up in unexpected ways. They are already bringing new changes to healthcare and medical research and are likely to spread to sectors such as Insurance, Manufacturing, and Childcare to name a few. 

But if the Apple Watch was made to make communication less invasive, then I believe its purpose has failed. In the past few weeks a number of friends have commented (with offence taken) that I can’t keep looking at my wrist. Most of us learn to be courteous enough to ignore the vibration of a phone in a pocket, but it’s much harder to dismiss the temptation to glance down at your wrist. Naturally, the added complexity and functionality won’t change the fact that looking at a watch is universally recognised as an expression of impatience and boredom.

Fans of the watch will cry out that there’s no mention of Apple Pay here, and it’s something I would have tried had I not had a complication with the bank. That said, the more popular smart watches become, shops will need to anticipate how they can make payments easy enough for everyone, regardless of height or disability, without it feeling needlessly painful or harder than taking your card out your wallet. The biggest obstacle for the wearables market could rest in addressing behavioural change and integrating devices in truly seamless ways that won’t upset social norms.


React Native – When the Mobile Web Isn’t Enough

by Joe Stanton

Back in January, a few Red Badgers were lucky enough to be sent to React.js Conf at Facebook HQ. We’re huge fans of React and have been using it to great effect on every project since we discovered it in early 2014.

There were many excellent talks at the conference, and it was staggering to see just how much adoption React has gained in such a short space of time, especially by some huge players in web technology (anyone heard of Netflix, AirBnB or Yahoo?).

There was one very significant announcement that overshadowed the other talks, though. Tom Occhino took to the stage in the first keynote and delivered a Steve Jobs-esque announcement of React Native. As a bonus, all conference attendees were given early access to the project, now open source.

Tom Occhino

After experimenting with, and contributing to React Native during its private beta phase, I’ve formed an opinion on what it might mean for Web developers like us, and our clients. And it’s exciting.

The Present

Red Badger are rather good at building responsive websites. Our clients love them because they deliver a fantastic experience for their customers on all kinds of devices. These sites feel better, convert better, and look great. They also don’t cost significantly more to build than traditional websites, when developed with responsive in mind from the beginning.

They are the 80% solution, though. They don’t solve everything. The last 20% has proven to be a problem. This elusive 20% sometimes means we have to say no to projects where the mobile web is not yet a good fit, and we hate it.

So what is the missing 20%? Or rather, what’s wrong with the current state of the mobile web?

What’s wrong with the Mobile Web?

  • Real performance problems – The DOM is just slow. The weight of the DOM feels much worse on mobile, where resources are constrained. Attaining the 60fps necessary for a smooth experience can be very difficult when images are being decoded whilst scrolling, for example.
  • Poor gesture support – This is a huge part of why native apps feel more intuitive and higher quality. I frankly had no idea just how much control was given to native developers in dealing with gestures correctly until researching it, and it shows. Simple things like not accidentally clicking a link whilst scrolling, responding to sliding events with velocity etc. are much harder to deal with on the web.
  • Many Native API’s are still not exposed for web – So we simply can’t take advantage of them (Push Notifications, iBeacons, Vibration, TouchID to name a few). This is a major cause of us saying “no” to a requirement. This can be somewhat addressed by a framework like PhoneGap, which comes with its own set of negatives.
  • Half baked features that don’t really work as intended eg. offline support with AppCache.
  • Years of legacy browser support – A huge productivity killer.

Perhaps the biggest problem of all, though, is the glacial rate at which these problems are being addressed. We’re die-hard advocates of the web, but we can’t wait forever. Exciting new web standards such as ServiceWorker (bringing Push Notifications, much better offline support etc.) are still a way off, and Apple have no publicly announced plans to adopt this standard at all for Safari.

Web apps still don’t feel as good as native apps, and it’s a shame. We’ve been saying they’ll catch up for a while now (Facebook famously went native in 2012) and they aren’t.

So how do you avoid the unreasonable cost of native development, of running separate teams with separate tech stacks, with no code reuse, limited shared knowledge, and their minds on technology instead of the product?

React Native

After using React Native for a few weeks, I’m convinced. I’ve distilled my feelings into a list of benefits:

  • It’s Real, Native UI – With great performance, animations and gesture control, that blend effortlessly into the platform. This means you’ll still have different Web, iOS and Android implementations, but they’ll provide a great experience that’s tailored to each platform. It’s nothing like a WebView.
  • It’s React, a technology we already love – it’s fast, it’s familiar and we write far less bugs in it thanks to its functional properties.
  • It’s the same tech stack – modern JavaScript (ES6), the good parts of CSS (Flexbox) and the same tools for building, packaging (NPM), linting (eslint), testing (jasmine/jest) etc.

    This means the same team can develop the Web, iOS and Android versions of an app, using technologies they’re already comfortable with. The developers best placed to build a product are the ones that understand it the best, not those segregated into different teams based entirely on technology.

  • Speed of Iteration – Changes in the UI are reflected immediately via Live Reload. There is no lengthy recompilation step, and most changes appear within a few seconds. This is what we’re used to on the web, but something very new to Native development. It leads to happier, more productive development sessions, and a willingness to experiment without frustration.
  • A simple JS->Native Bridge – So you can use libraries written in Obj-C/Java when you need to. It’s possible to build both native libraries (eg. bridging the TouchID service on iPhone) and native UI components, such as a switch, or slider. You can create nice, declarative API’s for these libraries and distribute them on NPM.
  • It works on iOS and Android (coming soon) – There’s no reason it can’t work on other platforms too.
  • It’s even possible to hot-load new JavaScript code, thanks to this recent (extremely significant) relaxation of App Store rules:


These benefits boil down to enormous workflow and productivity gains over traditional native development, making that last 20% much more bearable and potentially a lot less expensive, too.

The Future

The most promising part of React Native is not the code itself, but the ideas. Facebook core contributors have regularly stated that they see it as a testbed for new ideas. These ideas can lead us to better abstractions and solve real problems before being implemented within browsers. More eloquently put:


We need better primitives for building performant and native feeling UI within mobile browsers, and this shouldn’t start as a draft from a standards body, perhaps React Native can help lead us there.


Haller – Releasing potential on the web

by Cain Ullah

Haller web appI’m very excited about a project that we are currently working on for The Haller Foundation and want to take this opportunity to talk about the amazing work they do and what we are doing to help.

The Haller Foundation

The Haller Foundation was setup to continue the work of the environmentalist, Dr. Rene Haller. Its fundraising branch is run out the UK with all funds focussed on its efforts in Africa, mostly in the rural areas of the Kisuani district. Haller’s focus is on helping farmers to realise the potential of the land beneath their feet by training them in life-skills, ultimately leading them to build better self-sufficient and sustainable lives. Their programmes include education, water, farmer training, health, alternative energy, nano-enterprise and the Bustani Urban Garden, an education centre that shows people how to use rural farming techniques in small urban spaces.

To meet the volunteers who make this happen and to see what they are achieving is a wonderful thing. We’ll be going out to Kenya to see it first hand in the next couple of months, something we are incredibly excited about.

What are we doing?

Alongside Haller, we are working very closely with Pearlfisher, a London and New York based design agency (Jonathan Ford, founding partner of Pearlfisher is a trustee of The Haller Foundation) to build a mobile web site that will support the activities of Haller in Africa. There is a surprising amount of mobile devices in Kenya, which as a country has a great deal of disruptive digital innovation (Research by RIA shows that over 60% of Kenyans use mobile phones as a method of payment). With so many mobile devices in the hands of Kenyans, in both urban and rural areas it makes perfect sense to utilise the potential of mobile to create a web application that works across multiple devices to put the power of Haller’s content into the hands of the people.

The Haller Foundation, Pearlfisher and Red Badger are working together to produce an application that provides real value that helps Haller to distribute digital content to as many people as possible. Taking key learnings from the existing Haller programmes, the project objective is to increase the reach of the Haller techniques and bring even more economic security to poor, small-holder farmers. With Pearlfisher building the vision and content strategy,  Red Badger are providing the user experience, visual design and development of the application.

AndroidDesign1    AndroidDesign2

How are we doing it?

Being a charity that is run mostly by volunteers, the investment available to hire a consultancy to build a web application is limited. So we had to be creative and look at ways in which we could afford, as a small tech consultancy, to free up resources to be able to run this pro-bono project. Using a mixture of senior resources we have also supplemented the team with part-time junior resources that are still at University. An opportunity arose with this project to use it to develop junior resources, preparing them with key skills once they graduate. Haller are fully supportive of us using junior resources on the project and are relaxed on delivery timelines. So as well as building an application for a great cause, we are also using the project to develop young developers, providing them with new opportunities for a career.

Next steps…

There is lots of work to do. We are making great progress with the first version of the app. We’ll also be going to Kenya to see the Haller operation first hand, to meet the farmers and to do some usability testing on the application. We’ll use the feedback from the testing and feed it in to the next iterations of the application.

We’ll be blogging on the progress of the app dev (with the Uni students talking about what they are learning), of the visit to Kenya and everything else to do with the progress of this project. 

The whole team is genuinely excited to be part of a project that could provide benefit to so many. Working with The Haller Foundation is truly inspiring. Perhaps we’ll use this project as a platform for doing similar pro-bono projects for other charities and developing young talent in the process. Watch this space…


Full Frontal 2013

by Stephen Fulljames


When assessing conferences for myself, I tend to break them down in to “doing conferences” and “thinking conferences”. The former being skewed more towards picking up practical tips for day-to-day work and the latter being more thought provoking, bigger picture, ‘I want to try that’ kind of inspiration.

Despite being pitched as a tech-heavy event for Javascript developers, Remy and Julie Sharp’s Full Frontal held at the wonderful Duke of Yorks cinema in Brighton has always felt like more of the latter. That’s not to say the practical content isn’t very good. It is, very very good, and naturally the balance has ebbed and flowed over the event’s five year history, but the general feeling I get when I walk out at the end of the day is always ‘Yeah, let’s do more of that!’ It’s been that way right from the start, in 2009, when Simon Willison ditched his prepared talk at a few days notice to speak about a new language in its infancy – a little thing called Node. So I was hopeful that this year’s conference would provoke similar enthusiasm.

High expectations, then, and a promising start with Angus Croll taking us through some of the new features in EcmaScript 6 (ES6), aka “the next version of Javascript”. Presenting a series of common JS patterns as they currently are in ES5, and how they will be improved in ES6, Angus made the point that we should be trying this stuff out and experimenting with it, even before the specification is eventually finalised and brower support fully implemented, as David commented that if you’ve done Coffeescript you’re probably well prepared for ES6, and really one of the aims of Coffeescript was to plug the gap and drive the evolution of the language, so its hopefully something I will be able to pick up fairly easily.

This was followed by Andrew Nesbitt, organiser of the recent Great British Node Conference, demonstrating the scope of hardware hacking that is now becoming possible using Javascript. As well as the now-obligatory attempt to crash a Node-controlled AR drone into the audience, Andrew also explained that “pretty much every bit of hardware you can plug into USB has a node module these days” and demonstrated a robotic rabbit food dispenser using the latest generation of Lego Mindstorms. Being able to use Javascript in hardware control really lowers the barrier to entry, and the talk only reinforced the feeling I got after the Node Conf that I need to try this (and ideally stop procrastinating and just get on with it).

Joe McCann of Mother New York gave a high-level view on how mobile is increasingly reshaping how we interact with the web, with the world and with each other. Use of phones as payment methods in Africa, where availability of bank accounts is challenging, has reached around 80% of the population with systems such as M-Pesa. And SMS, the bedrock of mobile network operators’ revenue since the early 90s, is being disrupted by what are known as “over the top” messaging services that use devices’ data connections. These are familiar to us as iMessage and Whatsapp, but also growing at a phenomenal scale in the far east with services such as Line which is offering payment, gaming and even embedded applications within its own platform. Joe’s insight from a statistical point of view was fascinating, but it didn’t really feel like many conclusions were drawn from the talk overall.

Andrew Grieve and Kenneth Auchenberg then got down to more development-focussed matters with their talks. The former, drawn from Andrew’s experience working on mobile versions of Google’s productivity apps, was a great explanation of the current state of mobile performance. It turns out that a lot of the things we often take for granted, such as trying to load Javascript as required, aren’t as important now as perhaps they were a couple of years ago. Mobile devices are now able to parse JS and selectively execute it, so putting more effort in to minimising DOM repaints, using event delegation, and taking advantage of incremental results from XHR calls and progress events are likely to be better bets for improving performance.

Kenneth spoke about the web development workflow, a subject he blogged about earlier in the year. His premise was that the increasing complexity of browser-based debug tools, while helpful in their purpose, are only really fixing the symptoms of wider problems by adding more tools. We should be able to debug any browser in the environment of our choice, and he demonstrated this by showing early work on RemoteDebug which aims to make browsers and debuggers more interoperable – shown by debugging Firefox from Chrome’s dev tools. By working together a community on projects like this we can continue to improve our workflows.

My brain, I have to admit, was fairly fried in the early afternoon after an epic burger for lunch from the barbeque guys at The World’s End, a spit-and-sawdust boozer round the corner from the conference venue. So the finer points of Ana Tudor’s talk on some of the more advanced effects you can do purely with CSS animation were lost to struggling grey matter. Suffice it to say, you can do some amazing stuff in only a few lines of CSS, in modern browser, and the adoption of SASS as a pre-processor with its functional abilities makes the process much easier. It’s also brilliant that Ana came on-board as a speaker after impressing Remy in the JSBin birthday competition, and a perfect demonstration that participating in the web community can have a great pay off.

The last development-orientated session was from Angelina Fabbro, on Web Components and the Brick library. Web Components are a combination of new technologies which will allow us to define our own custom, reusable HTML elements to achieve specific purposes – for example a robust date-picker that is native to the page rather than relying on third party Javascript. This is naturally quite a large subject, and it felt like the talk only really skimmed the surface of it, but it was intriguing enough to make me want to dig further.

The finale of the day, and a great note to finish on, was Jeremy Keith speaking about “Time”. Not really a talk on development, or at least not the nuts and bolts of it, but more of a musing about the permanence of the web (if indeed it will be so) interspersed with clips from Charles and Ray Eames’ incredible short film, Powers of Ten – which if you haven’t seen it is a sure-fire way to get some perspective on the size of your influence in the universe.

Definitely a thought-provoking end to the day. As someone who has done their time in, effectively, the advertising industry working on short-lived campaign sites that evaporate after a few months (coincidentally Jeremy mentioned that the average lifetime of a web page is 100 days) it has bothered me that a sizeable chunk of the work I’ve done is no longer visible to anyone. On the other hand I have worked on projects that have been around for a long time, and are likely to remain so, and I suppose in the end its up to each of us to focus our efforts and invest our time in the things that we ourselves consider worthwhile.

(Photo: Jeremy Keith recreating the opening scene of Powers of Ten on a visit to Chicago)


Something about the Quirky World of Mobile Web Apps

by Haro Lee

On a recent mobile-focused project we ran into a few challenges over getting what turned out to be a fairly complex layout working smoothly and responsively over a range of target devices. It also highlighted a number of real edge-case quirks in how different phones and browsers deal with modern web technologies such as the audio element, and even how ‘shake to undo’ can affect a form that the UI hid several transitions ago.



(There was a time mobile phones were simpler… or not…)



To help with the total payload of the project we chose to use the Zepto library rather than jQuery. This has an API very similar to jQuery’s and the advantage of size but is focussed on modern, mobile browsers so drops support for IE and – significantly – doesn’t cover Windows Phone. That wasn’t a problem on this particular project but worth bearing in mind for the future.

We found a couple of niggles in the Zepto API, mainly related to our own coding styles and the requirements of the project. We missed jQuery’s ability to set a hash of functions against AJAX http response codes, for example.

In the end, given the eventual size of the rest of the application’s payload, the filesize saving of Zepto over jQuery probably didn’t make a whole lot of difference.


How to be responsive

The biggest problem encountered while implementing a responsive layout with the given design was how the DOM flow needed to change depending on whether the screen is portrait or landscape. It would have been ideal if we’d had the option to change the design and eliminate the worst of the problems, but once we realised how complicated it would be it was already too late. So a lesson learned…

One of the big problems in trying to fit a fairly fixed size application design to a phone screen is orientation. Fine in a native app; you can just specify if the app fits to portrait or landscape, or both, but in a browser that level of control is not available.

Fitting the level of interaction we needed, responsively, into a landscape phone viewport meant quite a lot of juggling of DOM elements and events when switching from and to portrait layout. This was particularly tricky on iPhones as Safari in landscape orientation has three different possible sizes (address bar visible, address bar hidden, fullscreen) and generally smaller screen sizes than our target Android devices. The eventual experience in landscape wasn’t as satisfying as in portrait but we did manage to make it work.

Because of all the complexities that are not possible to handle only with CSS and media queries, we heavily depended on a Javascript layout manager to handle resize events and orientation changes, calculating available screen estate and rearranging elements.

A simpler way to get around this, although perhaps a cheeky one, would be to use the ‘orientationchange’ or window’s ‘resize’ event to effectively hide the main app with a “please turn your phone round” message. Unfortunately the ‘orientationchange’ event is not available on older Android devices.



The procedure we used to preload assets for our single page web app was to have separate CSS files for the preloading/splash screen and for the main app.

The splash page was part of the app, so we didn’t want users to proceed from here and start using the main app until all the assets were loaded. To achieve this, we made one stylesheet for the splash screen with all the generic styles that didn’t require any images and another for the main app which referenced all images and assets (i.e. icons and background images) and only linked the splash stylesheet to the HTML page. We then used a Javascript preloader which requested all the image assets and the main stylesheet, attached this CSS file to the HTML page once everything was loaded and ready.

This method could also be used to load different stylesheets and assets depending on the screen size or device, if required.



A new technology for us on this project was the Web Audio API which is a programmatic way of cuing and playing sound files rather than relying on a DOM element such as <audio>. Support is limited for now with only modern desktop browsers, and Safari in iOS 6, able to use it, but it looks to be a great way of adding spot effects to browser games and other interactions.

We used the Howler library to add sound to the application, with the expectation that we would use its fallback methods to increase support across devices and browsers. In the end due to other technical constraints (see ‘Device Quirks’ at the end of this post) we chose to only play sound through the Web Audio API, so if we were to refactor here we could have removed Howler (not that there’s anything wrong with it) and go direct to the API.


Jam off the boil

We’ve used the Jam package manager on a few projects now, and while it does have some advantages in dependency management and compilation it also uses its own module install system. So it relies on package owners keeping the versions that are published in Jam (rather than their main Github, etc, repo) up to date. We’ve had a few cases where the version of a library we needed isn’t available yet in Jam.

Jam interface with the browser is a modified version of Require, which we like for its clean module loading mechanism. So for future projects we’d look to dropping back to regular Require and find something else, perhaps a Grunt task, to handle the file concatenation and minification which Jam also offers.


App logic

The application logic required a fairly complex state to be maintained, and for these we used our old friend Knockout. We did consider lighter MV* libraries but ultimately felt that with Knockout’s very comprehensive view binding built-in we would save ourselves a lot of trouble. The other main aspect of the Javascript architecture was the use of a PubSub (publish-subscribe) library to communicate between the various parts of the app. So for example the AJAX API methods were fairly isolated – to enable their easy reuse – with their success states publishing the returned data for the viewmodels to pick up.

This decoupling did present a few edge case bugs around timing issues later on in development, but overall the ability to have communication, view state, preloading, sound and so on implemented independently and talking to each other via PubSub suited the Require modular loading we used as well as resulting in cleaner code.

This complexity of the application was borne out in the eventual size of the DOM, as we had several ‘pages’ within one document which were hidden and shown as required. For smoothness of experience this was useful, but retrospectively we’ve wondered if it might have been better to have a minimal HTML document with more extensive use of Javascript templating through Backbone or similar. Ultimately its hard to tell without implementing, but at least we have a steer for future iterations in this programme of projects.


Phonegap and other gotchas

It is well known that the performance of a web app wrapped in the Phonegap library is not as good as a native application.

Our previous Phonegap projects had a lot more DOM elements involved than this one so we hoped for better performance, but there were still a few performance issues on older iOS devices. Aside from that the Phonegap wrapping was pretty straightforward with minimal changes needed.

In the end perhaps the weirdest problem we discovered was that mobile service providers such as T-Mobile and Virgin appear to strip comments in HTML when sending data to mobile devices. This caused failures in our Knockout implementation, which used the library’s containerless control flow (i.e. specially formatted comments) to reduce the number of DOM elements – a very unexpected surprise. We ended up replacing all comment bindings with regular DOM bindings.


Device quirks – iOS[I] vs Android[A] vs Blackberry Z10[B]

– on-screen keyboard

[I] no viewport size change when hiding/showing the keyboard

[A, B] viewport size changes when keyboard is showing

[older A] even when the form page is hidden, the on-screen keyboard will not be dismissed unless the focus on the textfeld is forcibly removed.

– in-page scrolling

[A] even with overflow settings its still very buggy on the stock browser but Chrome doesn’t have problems.

– overflow: hidden

[older A] cannot interact with elements inside of “overflow: hidden” even if they are visible

– shake to undo (only on iOS)

[I] we found a filled-in form which was subsequently hidden triggered the iOS ‘shake to undo’ event. Unfortunately there was no known way for users to disable this feature easily but having an iframe somewhere in the DOM and changing its src (to anything) disables the “feature”. This hack doesn’t work if the app is wrapped in Phonegap but you can explicitly turn off shake to undo here.

– <audio> elements

[A] when a sound clip plays in an audio element it stops other background music from other apps

[B] the sound clip files are added to system playlist and so become accessible through its music player

– ‘devicemotion’ event

[A] on Android Chrome browser the ‘devicemotion’ event is not supported, although it is available on the stock browser. Future Chrome updates should add support.

– ‘orientationchange’ event

[older A] not supported


co-written by Stephen Fulljames



Device Independent Web – All For One, One For All

by Haro Lee

“All For One, One For All!”


What Happened…

A few days ago, I got an email with a url to an article on a website.
I clicked it without giving it much thought and the page opened on my web browser and for a moment I was puzzled as it looked quite not what I expected.

The font size was unnecessarily big, the paragraphs filled the entire width of the window, images were stretched, and I scrolled down and on the bottom of the pages there were several huge buttons filling all the available width.

At first I thought ‘what a badly designed website’ and then realised something was not right (other than it looked bad…).

I checked the url and it started with “mobile”.

Yes, it was the mobile version of the webpage.

I removed the “mobile” bit and it reopened the normal desktop version of the webpage now with a lot more comfortable look.

I figured out what happened there. The colleague was looking the webpage on his mobile phone and shared it by sending the url.

I’m sure many of you have the same experience.



I don’t want to start yet another debate what should a mobile internet be like or even the point of the existence of mobile internet (such as “There is no mobile internet” debates). There are plenty of other people talking about it with probably more knowledge than I have.

This post is not to argue or teach others what to do but just to talk about a little detail seems to be forgotten sometimes.

I appreciate the extra effort the people pour in to make their website look better on mobile devices or smaller screens.
Most of the times, it really helps my browsing experience.

But sometimes they seem to forget how advanced the mobile and web technology is becoming.

One example is Chrome browser on all the different devices.
As far as you are logged in, your browsing history and bookmarks are shared between devices. It knows what were the webpages you were looking on your phone so you can open them again on your desktop and vice versa.

It’s not just the browsers.

There are many many chances that you send an email with a link to somebody or even to yourself while browsing on your mobile phone and the recipients may open it on their desktop exactly like my experience above.  

That brings forward the importance of being versatile between devices.

In many cases if you open a webpage saved or sent from desktop on your mobile web browser, it correctly shows the mobile version of the page.

What it seems to be often forgotten is the opposite case.

Even a big company like BBC ( has forgotten it.

Maybe it’s like that so the developers can check the mobile version of website easily on their developing process, or just a simple memory loss, or hasn’t been considered at all, I am not sure.


A Little Thought…

One way to fix this quickly is just not to forget to check what device the webpage is opened on even on the mobile version of the website.

However, if you can afford to re-make the website, probably one of the most manageable ways of ensuring cross device experience will be using responsive web design. This may bring another good old everyone’s favourite debate of what and how responsive design should work but that is another story.

May your tool be Twitter Bootstrap (, Skeleton (, or HTML KickStart ( or whatever you choose to work with for an easier start, or even your own creation.

Responsive web design lifts at least the burden of managing two or more different versions of the same page or template for different devices and it comes with an extra peace of mind that you don’t have to worry about the different devices and screens available on the wild all the time.

Another side effect of responsive design I like is that it makes the user experience less cluttered by forcing the designers and developers to think more about what and how to show and not, of course that’s if they are bothered to be bothered…


Functions to consider for Mobile testing

by Samera Butt

Having a mobile version of an application has now become a must. With mobile devices ranging from different OS platforms and tabletdevices – as testers, we have a lot on our plate!!

However, there are key points that we must consider whilst drafting out test plans and scripts for any mobile device. In this blog I attempt to cover some of the key points along with functional testing we should consider for mobile testing…

User Interface

Unlike our desktops, mobile devices come with various interfaces, from small screens that can be re-orientated when the device is physically rotated, touchscreen only devices to those which allow a combination of touchscreen and hard keypads, soft keypad only and not forgetting the various navigation methods such as hard keys and trackballs.

Being familiar with the device you are/will be testing on is important, if you are not, ensure you have a play around with it before testing. Check for the following:

  • Check for overall colour scheme/themes of the device. For example, Windows phone allow you to change the accent colour and background colours.
  • Style and colour of icons
  • Progress indicators when pages are loaded
  • Menu’s – how they are invoked and typical items they contain
  • Overall responsiveness of the application on the device

Screen Orientation/resolution: Applications should be tested in portrait and landscape view. Rotating the device fast, and checking to see the application’s response and errors

Touchscreens: Things to consider when testing touch screens are:

  • Multi-touch such as : pinch to zoom and single touch.
  • Long touch and short touch. For example, on some phones, pressing and holding an item will bring up a context menu, or a secondary function of a button.

Button Size & Position: Buttons and icons should be large enough to be seen clearly and be clickable by a fingertip.

Workflow: Use of radio buttons and checkboxes to minimize the amount of typing required, as this can be time consuming.

External Factors

Factors such as interaction with other devices and interruptions from the devices own functions such as incoming phone calls should be considered.

Factors to consider are:

  • Loss of Network Connections
  • Memory Card usage
  • 3G Network, 4G network, 2G network
  • No SIM card in the device
  • In airplane mode
  • Test intermittent network scenarios that a user might encounter in the real world such as:
    • Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a large building like a hospital or airport, or outdoors)
    • Ride in a lift or on a train where the network connection may go up and down
    • No network connection available at all

Device Options such as Screen Timeout/Auto on/off: Is your application subject to screen dimming or automatically turning off even when it is actually busy? For example, you wouldn’t want your screen to dim or turn off while watching a slideshow of your photos.

Screen orientation: You may be able to enable/disable automatic orientation switches when the device is rotated. Does your application apply the setting set on the device?

Font: Does choosing a different font family, size, or style affect the appearance and usability of your application?

Connections: Using one of the connections on a device, such as Bluetooth or Microsoft Direct Push (only on Windows Phone devices), could have adverse effects on your application. How does enabling/disabling Bluetooth or other connection types affect your applications behaviour?

Emulator Use

Can be a great way to achieve testing coverage across multiple devices, but it is not safe to assume that just because your application works on an emulator, it will work on the actual device itself. When using Emulators, it is important to consider the following points:

  • Not all activities can be realistically emulated, like switching network connections, or taking a picture or video.
  • Some activities don’t work at all on emulators, like streaming video on a Blackberry emulator.
  • Due to lower device power and memory, the application could exhibit slower performance overall when run on an actual device (versus in an emulator on your powerful desktop computer).
  • If the emulator and actual device have different resolutions, your screens may not display as you expect.

Stress Testing

Mobile device applications have much less memory and power available than PC’s

Security Testing

This applies to applications which require sensitive data storage such as banking applications, and how the application behaves under various device permission schemes.

Mobile devices will no doubt continue to grow, and as testers we will need to keep up to date with the latest gadgets out there to keep on top of the latest changes in OS and functions belonging to a gadget. No doubt the device functions discussed in this blog will continue to grow.



QCon Notes Part 2: The Future Application Platform

by Can Gencer

Unsurprisingly, there were several talks about the web and JavaScript at QCon. There is no doubt about the meteoric rise of JavaScript in the recent years, and it’s hard to imagine that this will not continue. Web browsers have been powered by JavaScript for years and more and more desktop applications are moving to the web. Node.js proved that JavaScript is as good as any other language for building a framework for web applications. Mobile web seems to be the next frontier and where progress seems to be among the fastest.

JavaScript Today and Tomorrow: Evolving the Ambient Language of the Ambient Computing Era

Allen Wirfs-Brock (Mozilla)

Download Slides

Allen is a Mozilla Research Fellow and was the project editor for the ECMAScript 5/5.1 standard.

Allen started off his talk by illustrating the two major eras in computing, the corporate computing era and the personal computing era. A major shift in computing happened in the late 70s and early 80s, where the shift to personal computers radically changed the nature of computing. Currently, we are undergoing another significant shift to what could be called the “ambient computing” era. Ambient computing has the characteristics of being device based rather than computers and being ubiquitous.

Every computing era had a dominant application platform. The dominant platform emerged as the winner through a combination of market demand, good enough technical foundation and superior business execution. The dominant platform for the corporate computing era was IBM mainframes. In the personal computing era, the dominant platform was the combination of Microsoft Windows and Intel PC (much lovingly called Wintel). In the emerging ambient computing era, it is becoming clear that the new application platform will be the web.

Each computing era also had a canonical programming language – COBOL/Fortran for mainframes and C/C++ for personal computing. The canonical language for the web and thus the ambient computing era appears to be JavaScript. Allen brought up the interesting question about what could replace JavaScript and how that could happen. JavaScript, even with it’s quirks is “good enough” and there doesn’t seem to be any apparent way that it would be replaced by anything else. As such, his claim that “JavaScript will be the next canonical language for the next 20 years” seems spot on.

After the ECMAScript 4 fiasco, TC-39, the committee responsible for deciding the future of JavaScript, is moving a lot faster and is more driven and organized to improve the language. There are a lot of improvements to the JavaScript language coming with ECMAScript Harmony, which represents ECMAScript post version 5. Some might be considered controversial, such as the inclusion of classes, and are ongoing current discussion. Considering the slow browser adoption rate, even ES5 is not yet mainstream and will not be for a couple of years more. This unfortunately seems to be one of the biggest bottlenecks in moving the new ambient computing platform forward.

The Future of the Mobile Web Platform

Tobie Langel (Facebook)

Tobie is currently the chair of the Core Mobile Web Platform Community Group which is dedicated to accelerating the adoption of the Mobile Web as a platform for developing mobile applications. Tobie and his team at Facebook put a lot of effort into analysing the most popular native applications and finding out what capabilities were missing in web applications to make them on par with native applications in terms of user experience.

Facebook recently launched ringmark, a test suite aimed to accelerate the adoption of HTML5 across mobile devices and provide a common bar for implementations of the mobile web standards. Ringmark provides a series of concentric rings, where each ring is a suite of tests for testing mobile web app capabilities. There are currently three rings, however the intention is to continue the project by adding more rings as the capabilities of mobile devices increase.

Ring 0 is designed as the intersection of the current state of iOS and Android and 30% of the top 100 native mobile applications can be implemented using ring 0 capabilities.

Ring 1 includes features such as image capture, indexDB and AppCache. Browsers implementing ring 1 should be able to cater to 90% of the most popular native applications, most of which actually don’t or need utilize advanced device capabilities such as 3D. Tobie highlighted that getting ubiquitous ring 1 support should be the short term goal for mobile browser vendors and developers to drive mobile web adoption.

Ring 2 will fill the gap with the final 10% of applications, with things like WebGL, Web Intents and permissions. Ring 2 is aimed to be a longer term goal.

Mobile Web should also be able to achieve beyond 100% of the native apps, with capabilities such as hyperlocal applications (e.g. an application tailored to a certain local event) and deep linking.

Lack of standards for mobile web applications when it comes discoverability or manifest files was also mentioned as one of the hurdles that mobile web needs to overcome. It will be exciting to see how fast we will be able to reach there.

The Future Is Integrated: A Coherent Vision For Web API Evolution

Alex Russell (Google)

Slides (Built with HTML5!)

Alex is a TC-39 representative for Google and is also a member of the Chrome team. One of Alex’s missions has been to drive the web platform forward. He is as frustrated as the rest of us developers with the current state of fragmented support and slow progress.

WebIDL and JavaScript have a cognitive dissonance problem. DOM was specified as an API for the browser programmers rather than the actual consumers of the API who are the JavaScript/web developers. It was also devised at a time where there were expectations that other languages than JavaScript would be consuming it, and artifacts of such an ideal still persist in the API. Moreover, DOM does not conform to normal JavaScript rules. The DOM types cannot be extended or constructured. It is not possible to do a new HTMLElement() whereas it would be very useful for many scenarios.

As web applications have increased in complexity, the disconnect between application data and the browser model has grown making web development painful. The developers have been trying to solve this using frameworks such as Backbone.js, however they are not perfect. Alex outlined two proposals to W3C that seek to make web development easier.

Shadow DOM is a way to create web components by a browser provided API. Modern browsers include native controls, such as the standard HTML form components. These built in controls are isolated from the rest of the page and are only accessible through whatever API they expose. There is currently no API to create third party components with the same strong encapsulation enjoyed by the native components.

The other proposal is Model-driven Views which reminded me a lot of how Knockout.js works. MDV provides a way to build data driven, dynamic web pages through data binding and templating via native browser support.


Also interesting, but didn’t get the chance to attend:

Mobile, HTML5 and the cross-platform promise

Maximiliano Firtman

Download Slides

Wrap Up

The various efforts around HTML 5, JavaScript and the mobile web all point to an improved developer experience. The question is how soon will this future will arrive? Combined with browser vendors pushing updates aggressively and consumers changing mobile phones every 1-2 years, it might not be as far as it seems. Listening to the talks also confirmed my opinion that native mobile apps are only a stopgap solution and the future lies in HTML 5+ and JavaScript as the platform that will power applications in the future.