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.

Design has no value

Give me a minute to explain…

My wake-up call came back in January of 2006. I started work as an engineer, or more precisely as an architect. I had worked on many projects and I was proud of my technical skills and my accomplishments. I was pleased to be starting my new job and I was excited by the prospects that lay ahead, and rightfully so, it’s been a lot of fun and it’s defined who I am now.

I got introduced to a new concept, User Experience design, but what did it mean? I met designers, people with art degrees, what place – what right, did they have to be part of a software team that was built upon degrees in Computer and Software Engineering? They threw about phrases such as user-centric design and design-thinking, they talked about personas and user ecosystems, they created wireframes and visuals designs. What did this mean to the people writing the code, the code which the users interacted with?
Something happened though, I’m now an advocate and evangelist for User Experience. If you are going to build software then start with the users, not with the architecture. It’s common sense. So not so provocative, so why make such a statement? Let me reframe the user as the consumer. I’ve come across two types of designers, those who design, and those who care passionately about their design making it in to the hands of the consumer – it has real-world tangible value for the consumer and for the brand – value we can measure and quantify.

Designing for the sake of design doesn’t add value, to the consumer or to the brand. Designing for value means putting the design firmly in the hands of the consumer and demonstrating quantifiable success. Too many designers stop at the design vision – the engineering element is a handoff.

The Experience Design team at Microsoft, which is part of Marketing Solutions, has been formed upon the principle of ‘designing for value’. We are a team that is equal parts User Experience design and User Experience engineering. We have fused a symbiotic relationship between the designer and the engineer. We share a common goal – a portfolio of referencable success – our design has value. We have refined how we bring together the principles of User Experience, the lean startup movement, agile, and Software Craftsmanship. I hope to share some of our insights in future posts and to talk more about our principles and practices.

The future is here, be part of it

I’m hiring engineers for ‘Studio 415’.

Read on if you want to bring the future to life. We are the Experience Design (XD) team – equal parts User Experience and Software Engineering. We are a design-led team and our remit is to imagine the future and to bring it to life.

Studio 415, in San Francisco, is creative and collaborative environment that promotes innovation and co-creation of solutions alongside our customers.

We are a sandboxed group within Microsoft, we have the resources and might of a large corporation behind us, but we think and act like a startup. We believe in the principles of the lean startup movement and we believe in being agile. We literally have the ability to touch billions of users and have an enviable war chest of technology at our disposal. Our weapons include Windows 8 and its extensive ecosystem that spans surfaces such as PCs, tablets, and smartphones. We have the XBox and Kinect. We have the power of Bing and cloud-based services such as Azure at our disposal. Our innovation knows no boundaries. We use the right tools for the job at hand – our job is simply to delight users and surpass their expectations.

We are looking for a mind-set. You will be passionate about technology. You will care deeply about Software Craftsmanship and crafting simple, but elegant software. You will see yourself as a polyglot, you are not bound to a single programming language, and you delight at learning new languages and perfecting your craft. You see the whole of the team as stronger than the individual.

You will be happy developing user interfaces, but not afraid to reach-in and touch back-end code. When we say user interfaces, we aren’t necessarily thinking GUIs. We want you to push beyond pixels and develop natural user interfaces that combine gestures and speech.

A love of sci-fi and gaming is an advantage, as your vision for technology holds no bounds. If this excites you then apply for one of the roles today. We exist to disrupt – our mission is to re-imagine, it is who we are.

See the available jobs in XD. All levels of experience welcome.

Tell me a story

At the tail end of last year I ran a week long ideation workshop for my extended team. We split in to four groups, with each group focusing on a different social medial scenario. It was a fun week and generated a load of unique ideas.

Having been inspired by the work the team had done I decided to revisit it in the new year. What really interested me was telling a story from the data. It also caused me to question why we were isolating social media and more broadly why digital marketing likes to treat channels separately. Is it the channel that’s important or is it the the user who’s important?

At the time Nike were in the process of launching the Fuel Band and I was intrigued by the various campaigns they were running and the different channels they were using. I spent a good bit of time exploring the different channels, Twitter, Facebook, YouTube, the Fuel Band microsite, and searching for the Fuel Band in Google.

As a user it felt like a fragmented experience and it made me question what was happening with all this data I was generating and what story it was telling about me. What was the Marketer or Product Manager seeing? Did they have a dashboard or a spreadsheet that showed the number of tweets, retweets, Facebook likes, page clicks, etc. Is there really any value in reporting we had 1m Facebook likes and 10k retweets? Did they have a conversion funnel showing the number of pre-orders? Was there an Analytics Manager in the background frantically aggregating data across disparate databases and building custom reports? Was the data simply being folded around the metrics that were deemed as important, or was the data telling a story? I suspect the former.

I really wanted to move away from the metric-centric world and focus on the data telling a story. I wanted the data to provide insights that could be acted upon. I wanted to stop optimizing the metrics and focus on optimizing the experience.

Last week I watched a Ted Talk from Jer Thorp called Make data more human. It struck a cord. He was using data to tell a story.

The digital marketing space and the onslaught of big data feels ripe for disruption. Who’s going to break from the norm and innovate the data? Start telling stories, not reporting metrics!