Category Archives: apps

Conversational UI

QZ have recently released a news reader app which uses a conversational style UI – mimicking the interactions that more normally take place in a person-to-person text or chat. Thanks to Rainer Wessler for pointing it out to me.

I’ve been fascinated by this sort of interface for a while – wondering which scenarios it would work best in – so it’s great to see QZ having fun with this. 


The app delivers news stories in text and image fragments with links through to QZ web articles, with cute prompts in between to keep you engaged and reading. Great fun to use and a really different approach to news delivery. 



Public transport suddenly makes sense

Over the past few years I’ve found myself using Taxis more and more to get around the city, steadfastly ignoring the fact that using the most expensive form of transport, in a grid-locked city like Sydney, one of the most expensive cities in the world, was becoming frustrating and digging a big hole in my wallet.

More than that, I found that in a Taxi I could never quite relax – always feeling somehow responsible for helping the Taxi driver navigate the best route, and always aware of the traffic jams around me. A minor comfort point is that I could never use my phone or ipad in a Taxi even on a short journey without feeling a bit queasy – not exactly the state I like to arrive to meetings in.

Over the past couple of months this situation has changed … a lot … since I took the time to recognise the brilliance that is Google maps + Public transport. I’ve been using maps for a long time, but typically while driving. Now I’m using them all the time during the day and the only downside is that my phone battery doesn’t like it so much.

From a user perspective using maps with public transport couldn’t be much easier :

Open Google maps on your phone. Tap on the directions button (circled red here).


Use the default of My Location and add the destination. Tap the button that looks like a bus – for public transport, then either use the default of “any transport mode” or select bus, train, ferry etc from the drop-down list (all circled in red).

Click Get directions. See a list of trips which include the walking time between stops, details of the stop number, bus number and time to complete the journey.


Details of each trip can be viewed as a list or map. So far, apart from buses being late (only occasionally) this has worked beautifully.


Now, with my additional discovery that there is a free shuttle bus around Sydney city, I’ve become a total advocate for public transport.

The utility of this becomes more amazing when you compare this to the official offering from the local transport companies, which has the same information presented in a much less simple way, and it is impressive that Google can plug all of this data into their maps and make it make sense. Good job Goog.

Summary and wrap up on HTML5 is ‘good enough’ for Enterprise

Over the past week I’ve been writing my thoughts and opinions on why HTML5 is not perfect, but good enough for the needs of most Enterprise applications.

Medium to large Enterprises are currently only at the point of being interested in mobilising their internal IT systems, and they are not yet at the point of committing time and money to think through what they need to mobilise their workforces. My expectation is that most organisations will make-do, only improving the mobile capabilities of their workforce as updates and new releases come from their traditional IT vendors.

These updates and new releases will use a mixture of good and bad mobile design, and little in the way of User Interfaces re-imagined for mobile. Really speaking, this is no improvement over where these IT-led organisations have always been with their systems on desktop computers (and before that on computer terminals).  Thinking about process re-engineering, User centric design and visual or creative design are not things that many companies are comfortable to address, and this problem will be exacerbated when the  job  of mobilising the organisation lands in the lap of the IT department.

In addition, there will be a small group of companies that either start from scratch as mobile-native operations, or have the vision, time and resources to rethink how their business could be revolutionised by embracing mobility. These guys are the ones who are going to be successful through, and because of their mobility strategy.

And, this is where HTML5 comes in. It’s not fantastic for creating engaging and visual interfaces on mobile, but it is very good for creating User Interfaces for form-filling and simple data entry (the bulk of business process rethinking currently appears to be about paper-form replacement), and, the skill sets needed to build and support HTML5 are 1) readily available, 2) mostly the same across many devices, and are therefore 3) cheaper to employ.

HTML5 will win the day not because of any of its features, but ultimately because it is the easy, non threatening, cheap option.

Here’s a recap of the points I’ve made previously :

Just enough is good-enough for Enterprise mobility

First two in a series of HTML5 expectations

3 and 4 in a series on HTML5 for the enterprise

Assumptions 5 & 6 in the series on HTML5 for Enterprise

Assumptions 5 & 6 in the series on HTML5 for Enterprise

The story continues – HTML5 and what it is mostly likely good for in Enterprise.

5 – An HTML5 web app can do everything a native app can

Native apps give ultimate access to the features of a given device.

For example Android allows the developer to pretty much do what they like – even going as far as overriding the built-in phone dialler app if that is really whats wanted. Android does suffer from some fragmentation of the operating system though – either because the user is not using the most recent version of the OS, or because the device manufacturer has changed the base Android software – so some things don’t always work on every device.

iOS is quite a bit more restricted both in terms of the device features that are made visible to the developer, and in terms of the functionality that Apple’s vetting process will and won’t allow.

In contrast, HTML5 does not offer the developer access to all of the native device features. The browser on the device is somewhat abstracted from the underlying hardware and so while HTML5 does offer access to some functions which were traditionally only available to native apps – the camera for example – there are some things which it doesn’t do, or doesn’t do particularly well.

Anything that requires intensive computation within an HTML5 web page – such as complex animation, or even page transitions – can often appear stilted or unresponsive on a mobile device. Coding these compute-intensive tasks inside the browser is all achieved through Javascript, which is traditionally not considered a high performance language (though this does have a lot of attention so it continues to improve rapidly). Native apps – coded in Java for Android or Objective C for iOS – don’t suffer from these same performance limitations, and can access a multitude of third-party libraries to assist with complex tasks.

Last on this point, a note on some of the UI frameworks that are around right now, such as the well known JQuery mobile and Sencha, and the lesser known such as Kendo, Lungo (in development, but my favourite looking),

6 – Hybrid apps will solve HTML5’s deficiencies

There is a middle ground between Native apps and HTML5 web apps, known as “Hybrid” apps. There are several of these available, but from what I know these all work in a similar way … a native app which offers access to underlying device features through an API which is common to all devices, and a User Interface built in HTML/Javascript/CSS.

Hybrid apps have a few immediate benefits :

  • Your hybrid app is installed onto the device in the same way as any other native app – downloaded from a website or Apple iTunes/Google Play.
  • The hybrid app containers offer the same access to native device features across all devices and operating systems
  • Most coding for an app uses HTML5/Javascript/CSS3 so the skills are relatively available, and are cheaper, compared to Objective-C or Java

With a few drawbacks, of course :

  • HTML5 User Interface may use a different browser (or web view) than the standard browser on the device, leading to more inconsistencies regarding HTML5 and Javascript support.
  • Some Hybrid technologies require the developer to ‘tool-up’ for each platform so that they can build and deploy the hybrid app to the app store. This would include using a Mac for any iOS development (which may seem like a small thing, but not every dev. shop use Mac’s). Note that there are Hybrid technologies around such as, Phonegap, and maybe others – which offer a service to build your app in the cloud, removing the need to tool-up for each device platform. is a personal favourite of mine due to it’s easy to use web based toolset vs. Eclipse IDE.
  • In an attempt to provide generic support across platforms, not all Hybrid containers respect the uniqueness of all devices’ User Interface. The UI can look generic, meaning that at least in theory your users are not going to like it. In practice this may not be that big a deal. It is worth checking though that all the devices physical keys work in the expected way – e.g. as iOS don’t have a physical “back” key it may be missing or not work on a Hybrid app running on Android.

More to come in conclusion on why only some of the above points and preceding posts are relevant to Enterprises.

3 and 4 in a series on HTML5 for the enterprise

Continuing the story on HTML5 and why it’s ‘good enough’ for enterprise, here are two more commonly heard assumptions regarding building a web app using HTML5.

The current HTML5 ecosystem is by no means perfect, but it is very good for some things. The current draw backs in user experience and browser and device ubiquity probably just don’t matter for Enterprises, who are for the most part IT driven and uncomfortable thinking about visual design and User Experience as part of a system design.

3 – HTML5 development is cheap – ’cause it’s the web, right ?

There’s no doubt that the design and development skills needed to build HTML (and the absolutely necessary Javascript and CSS) are readily available, and the development tools are mature and sophisticated. However, my own experience has been that :

  • Because HTML5 is an evolution from HTML4 and other associated technologies, it is fairly easy for any web designer or developer to claim some HTML5 skills.  While HTML5 is not a hugh leap from HTML4 or XHTML, it does have nuances and a very heavy reliance on CSS3 and Javascript.
  • CSS3 skills can be in something of a no-mans-land between visual design and development. A good all rounder web generalist is more likely to be comfortable with CSS3 than a dedicated designer or dev.
  • Javascript is becoming more and more arcane as a plethora of frameworks and add-on libraries and languages sprout up, in an attempt to rationalise and simplify the use of the language which is now expected to be enterprise-grade. In fact these are having the effect of making the development ecosystem more and more complex.

Add to this that few people are really familiar with Responsive Design (so it has to be learnt), + time overheads to cater for the vagaries of each browser and device, and suddenly things are not looking quite so cheap and straightforward.

4 – Developers will desert native apps in favour of HTML5 (because it’s cool)

Development using native technologies for iOS and Android have become a huge success story for Apple and Google and also for the developers who actually build the applications that fill iTunes and Google Play. While Apple and Google take 30% of the sale of any application (for providing a consumer billing platform and app store as a distribution point to the market), the remaining 70% goes into the pocket of the developer. Build a successful app and you could be rich.

The fact that there is money to be made from native apps development is something that the HTML5 lobby continually ignore – vaguely hoping that because HTML5 is a new, cool, thing developers will realise its the future and just slowly move across to it as demand from consumers increases.

Unfortunately, there are some things that will need to be in place before there is an easy way for a developer to charge for their work and an easy way to be found by potential customers. Some native devs are indeed now saying that it is getting difficult to be found in the iTunes app store and Google Play due to overcrowding – but where would they rather be ? Out on the web trying to drive traffic to their web-app with SEO and charging customers via Paypal … ? I’m not so sure.

More to come soon.

First two in a series of HTML5 expectations

The first couple of expectations and assumptions regarding HTML5. Please let me have your comments and see whether these ring true …

1 – HTML5 works the same in all browsers

HTML5 is not yet a ratified W3C standard, however each of the major browsers already have support for the bulk of HTML5’s features. There are plenty of compatibility matrixes available if you need to find out what works where (here’s one at Wikipedia), so I’m not going to worry about that here. However HTML5 compatibility only describes (approximately) one third of the whole picture of what needs to be built. Javascript and CSS3 are the two other cornerstones of the technologies needed to build a modern web interface*, and both of these have their own varying levels of support in the major browsers, complicating things further. So, if you want to build one web site that works in several browsers, there are two possible approaches :

  1. Cut the features of the web site to a bare minimum so that what you build uses only the generally supported features of HTML5/Javascript/CSS3 that work in all browsers. This will result in something that looks very generic/plain/old-fashioned (take your pick) but will probably do the job from a functional point of view.
  2. Plan to allow your designers and developers an extra 10%-15% for every additional browser that you add to the list to be supported. They will spend this time working around different features and variations in the HTML5/Javascript/CSS3 support for each browser.

Alternatively if cross-browser support is less important you could target a single browser, or choose a couple which are widely used across your target user base. Chrome and Firefox might be the two, Opera could be a consideration, Safari if you have Mac users, while Internet Explorer – in any incarnation  still considered something of an outsider – will probably pickup with the spread of Windows 8 and IE 10.

There’s a great score card for all browsers here, showing that Maxthon 4 is the winner in the HTML5 stakes right now (and I’ve got to admit I’ve never heard of it)

*There are several other lesser-used technologies included and referenced by HTML5, such as SVG, MathML, Ruby …

2 – HTML5 works the same on all devices

A common statement from a client who is looking to build an app or web-app is

“We only want to build one thing, and we want it to work the same on everything”

This question is driven from the clients (usually anecdotal) understanding that native apps need to be written explicitly for a given single device, and the following expectation that simply building it in HTML(5) will magically make it work on everything, everywhere.

If you think about it for a moment, it’s actually a big ask for a web page (and all of its embedded media and images) that are designed for a 15″ screen to shrink down to a 2.5″ screen, and every other screen size in between, without some serious considerations about the effect on the usability and features per device, not to mention the fact that the smartphone user almost definitely wants different things from a website when they are walking around town vs. in front of their laptop in the office, and would want a different experience again on their web TV.

A simple way to think about this usability difference per-device is to consider ‘hover’; A common bit of design fluff is that some parts of a web page change when you hover your mouse pointer over them – maybe the colour changes or something animates …

Now think about how hover works on a tablet – that’s right, there’s no mouse pointer and no hovering – when your finger is not on the screen, the browser doesn’t know where it is – therefore your designers and developers need to cater for this when building the web app. Either they don’t use ‘hover’ at all for any device, or you design and code to cater for the devices where the concept of ‘hover’ exists, and those where it doesn’t.

The current answer to the most obvious of device differences – screen size – is known as Responsive Design, which is a way of scaling a given page up and down so it is fit for the size of the screen on the device. Responsive Design is a great idea, and can work really well, but it involves a lot of complex design decisions (per device-size) up-front, followed by a highly complex HTML5/Javascript/CSS3 coding exercise. Of course, frameworks and tools are springing up to meet this complexity, but be prepared for 5x effort when building for responsive design vs. a single device and browser.

More to come on this topic over the next few days.

Just enough is good enough for Enterprise mobility

Over the next few days I’ll be writing about HTML5 – what it is, and is not, and why some of the issues it faces are irrelevant for Business and Enterprise.

HTML5 has a lot riding on its shoulders, and there are many misconceptions about what it can and cannot do, and why you’d choose to use it as a technology. There are many things that, as of this writing, just don’t completely work. For the most part, these flaws are well known and will probably be fixed in time by the various browsers but there are other problems of expectation that are not really technology problems, so won’t be fixed as such.

The common expectations are that :

  1. HTML5 works the same in all browsers
  2. HTML5 works the same on all devices
  3. HTML5 development is cheap – ’cause it’s the web, right ?
  4. An HTML5 web app can do everything a native app can
  5. Instant updates are better than software upgrades
  6. Developers will eventually flock to HTML5, leaving native apps behind
  7. Hybrid apps will solve HTML5’s deficiencies

What I’ll be attempting to explain in the posts to follow :

  • The ins-and-outs of these expectations
  • Why none of the above actually matter for an Enterprise application
  • What does matter for an Enterprise considering a mobile application

First post in this series, addressing points 1 and 2 is now available


Native apps in their infancy

In the face of the popular, simplified, ideas about HTML5 as the saviour of mobile development, it is begininning to feel hard to defend the definitely old-school-style of native development for iOS and Android.

The steps in development seem not to have really progressed that much since the dawn of time ; Want a User Interface ? Code, comment, compile, link, test, check-in … same as its ever been. Eclipse and other IDE’s are great tools, no doubt, but they are still hard-core programmer tools, requiring complex setup and requiring deep understanding of the tool itself to make them really hum. Xcode meanwhile faces few of the issues that Eclipse does, but the creation of a UI for an app, and the tying of that UI to the code is no less complex.

Where are the tools that allow the really easy visual design of native User Interfaces with integration to visual design tools ? Why is it so complex to just get started – particularly with iOS developer certificates, provisioning profiles and the rest – and why is the process of pushing an app out to through the app stores a pain ?

My hypothesis is that the processes and tools are at the end of their very first iteration (or errortation as a colleague used to say), however I’m worried that a closed shop such as Apple will be slow to see or address the shortcomings of their toolset while they are reaping the rewards from the iTunes store. There might be a high technical hurdle to iOS coding, but it is still resulting in many thousands of apps being created on a daily basis.

I don’t have a specific view on what the next iteration of tools might bring, but frameworks with a generative nature like rails, and languages/environments like Scratch hint at a different way of doing things. Nothing particularly new about either of these, but I would like to see more smart tools that take away the drudgery and bring a new accessibility that means the number of apps will multiply exponentially from where it is now. Tools that will support the coming boom in DIY devices and 3D models from maker-land.

HTC Salsa apps limit

I have a new HTC Salsa. Black.

It really feels like the successor to the HTC Legend – similar size and handling, with a less pronounced kick up at the end of the body, which, when you are on a call, ever so slightly curves the mic towards your mouth.

The feel of the phone is great, and the addition of a prominent and featured Facebook button (the only hard button on the front of the device) seems like a useful idea.

In practice, I found that I don’t really use the Facebook button. It functions differently depending on the context … if you are looking at a photo and press the F button, it uploads the photo, if you are listening to music and you press F, it posts the track, artist name and album artwork. If the phone is idle, then a quick press of the F button lets you post to your wall. All of these seem great, but for some reason I am just never compelled to use it even though like a lot of people, I spend a lot of time on FB.

Some of the other integration with Facebook is more useful – such as notifying you with suggestions of contacts that are on your phone, and on Facebook – prompting you to link the two contacts together. This works really well, but I’m not sure this is new to the Salsa – I think this was the same on Legend and other HTC’s.

I have come across a fairly annoying limitation with the Salsa/Android. The phone only has 150Mb of internal memory, which is largely taken up – about 2/3 – by factory installed apps from HTC and Google. This only leaves about 50Mb for apps, which might sound like a lot (and would be plenty if any app could be copied off to the SD card), but in practice it fills up very very quickly. Install Google maps updates, Facebook, Foursquare, Angry Birds  and Shazam and you’re pretty much out of room.

This is such an annoying miss by the Android creators. Apple have made memory management a thing of the past, whereas for Android its left to the user to manually copy apps back and forth out of internal memory onto SD. A really poorly executed experience, which will limit apps takeup for owners of this phone.

SXSW redux

It’s a month or more since I got back from my first visit to SXSW in Austin, Texas – and some of the takeaways from the conference are finally starting to properly take shape.

First, I have been coming round to realise how important it is to recruit and retain talented people. There was a lot of angst at SXSW from people either looking for a gig, or trying to employ good people. The common theme was that as soon as you find someone who’s good, they get snapped up by Facebook/Google and the rest.

Second, there are no new ideas. Not a new one in itself this, but just having a good idea in this world is nowhere near good enough – you really need to be able to execute well. There were a multitude of group messaging apps at SXSW but even though they were attracting a lot of attention (and investment) in truth there were several which were no good and will dissappear with out trace as quickly as they emerged.

Third, HTML5 is definitely the future, but is not the “right now”. No matter how annoying the fragmenting apps. ecosystems are, developers can’t drag themselves away from the real money available through the app. stores, and their clients want to have a presence in the app. store as well. The iTunes app. store that is – forget about the geek-fest that is still the Android marketplace.

%d bloggers like this: