Will the ‘Appification Of Everything’ Transform The World’s 360 Million Web Sites?

I don’t think so…

OK, so I want to be slightly provocative here.

Forbes recently wrote a great article called the “The Appification Of Everything Will Transform The World’s 360 Million Web Sites“.

We can’t deny that the web has been appified in recent years, largely driven by Apple. The cynical (and honest) amongst us would believe this is purely so content can be controlled and monetized. However, I don’t believe this is the sole reason. Innovation around the browser and web standards did stagnate for a long time, but that tide has shifted now with HTML5 and CSS3. Adobe Flash and its cohorts Flex and AIR plugged the gap for a while, but they too stagnated and failed to innovate in-line with the needs and aspirations of users, developers, and businesses. I think the bloody nose that Adobe suffered in the ungraceful, and rapid, demise of Flash will ultimately be a good thing for us all. Adobe has shifted their focus to web standards and has regained it’s innovation foothold. Just look at their web platform site and blog. They are not alone. Google is innovating web standards as are other companies large, small, and new. There is also a buoyant open-source community which has contributed an overwhelming amount of innovation.

I often use Java as my baseline. There was a community that exploded and dominated for a long time. The web standards community feels bigger, and it feels like it is in its infancy. Building web apps, and in particular single-page apps, has never been easier. The web has been commoditized by the likes of Heroku and GitHub. The web has never been more expressive. I’m blown away by HTML5 and CSS3. As I think back to my Flex days and the difficulties we had changing simple aspects of the experience, for example the rendering of validation errors on input fields, or adding a placeholder. It’s just so easy now. It’s also providing a clean separation of responsibilities between the designer and the developer, and better still giving ownership of the experience to the designer. I’m seeing more and more of a new breed of designer, who doesn’t just design the experience, but they code it!

So coming back to appification, and in particular mobile. It’s a fragmented market. We have iOS and Android dominating. Windows Phone and BlackBerry are fighting for market share. There’s a new wave of OS’s on its way, Firefox OS, Tizen, Ubuntu Phone OS. They are all proprietary. Even if HTML5 is a supported language, the code is littered with proprietary references to the underlying SDK, which binds the app to the hardware. At most we can claim the language is common, but I have yet to see a truly portable app. The fact that some of these are open-source makes very little difference. To reach my users I have to build a native app for each platform I want to support. This is a huge investment and creates a maintenance headache. My main option for reuse comes from my back-end services, which I can exploit across all platforms.

Well may be it’s not all that bad – or is it? There are many cross-platform languages and tools for packaging web apps as native apps. This is a big problem and there are lots of people working on solving it. However, the problem doesn’t just disappear, it simply moves the burden from the app developer to someone else, and hopefully that someone else has the deep pockets to deal with the fragmentation. But who cares, this is great news for the developer, it has to be! Well, from my experience it comes with compromise. The reason we usually build a native app is to access to the capabilities of the hardware (and in many cases performance). It’s a BIG job to support all these capabilities and the nuances that exist across all these OSs. Often the cross-platform thingamajiggy has to opt for the lowest common denominator. Often they lag as they can’t keep pace with new updates. This can become very frustrating for the developer and the end-user experience begins to suffer. Ultimately the user pays the price. Not good.

It not always compromise though. If I pick on my old friend Adobe AIR, it was just too big a job to support all the capabilities of all the platforms. The strategy to combat this is typically native extension. But hold on, that means I still have to write native code and I still have to incur an element of cost for each platform. The community does help as there are libraries of native extensions. However, I’m in a funny place. There’s a threshold I cross where my non-native app is mostly native. So why suffer all the compromises, is it not just simpler to suck it up and to build a native app in the first place?

My hypothesis, the tide will turn from appification back to the browser.

At the end of the day the browser has far greater penetration in the market and broader reach. We also have greater control over our app and the experience. When we make an update we reach all our users. No more app store approval and no more waiting on users updating the app.

There are still wrinkles. We still have to deal with browser compatibility. I feel this is the lesser of two evils though. I also wonder if in the future we will be comfortable only targeting a single browser…that’s another topic of discussion for another day.

There is also the wrinkle of mobile and incorporating hardware capabilities such as geo and the accelerometer in to our experiences. I bring us back to the fast pace of innovation, just look at WebRTC as an example. I suspect it won’t be too long before we have parity and web standards shift to the position of influencer.

Only time will tell.

Ember and the Designer

For the last 7 years I’ve worked with User Experience designers and I have a huge respect for their craft. I’m also loving how designers are embracing HTML5 and CSS3, and how it is giving them ownership over the experience.

It’s affording deep collaboration between the designer and developer, and asserting the need for frameworks and tools to play to our respective crafts, and to be sensitive to the designer-developer-workflow.

With this in mind I struggled for a while with Ember. I wanted a clean separation between my HTML and my code. Ideally I didn’t want to change the HTML, and I really didn’t want to pollute it with proprietary code belonging to Ember (or any other framework).

I was really disappointed as the only solution offered up was to use Ember.TextField.


<input type="text" id="firstName" placeholder="First" autofocus required>


{{view Ember.TextField valueBinding="firstName"}}

It breaks the clean separation between designer and developer. It makes my code difficult to maintain. I loose the expressiveness of HTML5. Why?

I get the binding goodness it may bring, but…

At this point I did consider walking away from Ember, but I did persevere. In the end I opted to use plain old JQuery in my code. I’m intrigued to see how this plays out as I grow my codebase, but in the meantime it keeps my HTML as pure as it can be.


<script type="text/x-handlebars" data-template-name="registration">
   <form autocomplete="on" id="registration" {{action createUser on="submit"}}>
      <input type="text" id="firstName" placeholder="First" autofocus required>
      <input type="text" id="lastName" placeholder="Last" required>
      <input type="email" id="primaryEmailAddress" placeholder="hello@mydomain.com" autocomplete="on" required><br>
      <label>Password <em>Minimum 6 characters</em></label>
      <input type="password" id="password" autocomplete="off" required pattern=".{6,}" title="Passwords must have a minimum of 6 characters."><br>
      <input type="submit" value="Create account" onmouseup="form.className='submitted';" />


App.UsersController = Ember.ObjectController.extend({
    createUser : function () {
        'use strict';
        var user = App.User.createRecord({
            firstName : $("#firstName").val(),
            lastName : $("#lastName").val(),
            primaryEmailAddress : $("#primaryEmailAddress").val(),
            password : $("#password").val()

Organically grown architecture

For a long time the Agile movement has advocated that you shouldn’t anticipate future needs, and as such, you should defer important architecture decisions until the ‘last responsible moment’. Like a lot of the Agile principles it is based on common sense – you should do the minimum amount of work required to satisfy the current feature you are implementing. This may seem irresponsible, as we often consider architecture as the cornerstone of software development. I equate this to architecture being rigid and requiring a large up-front investment before we can demonstrate meaningful progress to our users and the business.

Architecture doesn’t need to be rigid, particularly when viewed in context with the other practices of Agile and Software Craftsmanship.

In a previous post I introduced the principle of experience-driven architecture, which unfolds from User Experience design. My motivation was not to replace one type of big up-front design for another form of big-up front design. When it comes to surfacing requirements, User Experience has the same flaws as traditional software development – we always surface more requirements than we can possibly deliver within the required timeframe. So regardless of the approach you favor – your software will evolve organically. So why shouldn’t your architecture?

It all boils down to one motivation. It builds trust and confidence (it also eliminates waste – more on that another time). Agile advocates that we deploy software early-and-often. The sooner our stakeholders and users see demonstrable software, the sooner we start building trust and confidence. The shorter the interval between deployments, the faster that trust and confidence grows. It eliminates the need for estimation and gnarly gantt charts, which are just tools for conveying trust and confidence, and exist to support rigid architectures. With an organically grown architecture we are able to demonstrate trust, rather than using tools that say “trust me”.

When we combine this with experience-driven architecture and User Experience we bring a laser focus to what really matters. We build the feature that matters most, we deploy the feature when it is done, we respond to changing priorities, and we act upon new insights. In short we get to our goals quicker. We can’t do this with a rigid architecture.

The anti-principle of architecture

If we look at architecture through the lens of User Experience then we should consider the following principle: the experience drives the architecture

To understand why this principle may be important we need to look at one of the limitations often encountered with Service Orientated Architecture (SOA), or any other approach that relates to big up-front architecture. When we build the architecture from the ground-up we are unknowingly placing constraints on the user experience. As is then too often the case, the limitations of the architecture are surfaced to the user. To state this as an anti-principle: the architecture drives the experience

The goal of User Experience is to consider the needs of the user, often in the context of the business needs. We put the user front and center – user-centered design. Our goal is to design the best imaginable experience and to allow the user to complete their task with the least amount of fuss.

As with all principles in Agile, it follows common-sense. I’ll continue to build on the principle of experience-driven architecture in future posts. In particular I want to discuss experience optimization and organic architecture.