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.

Advertisement

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.

From:

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

To:

{{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.

HTML:

<script type="text/x-handlebars" data-template-name="registration">
   <form autocomplete="on" id="registration" {{action createUser on="submit"}}>
      <label>Name</label>
      <input type="text" id="firstName" placeholder="First" autofocus required>
      <input type="text" id="lastName" placeholder="Last" required>
           
      <label>Email</label>
      <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';" />
   </form>
</script>

JavaScript:

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.

Speak to your users in 3D

I care a lot about Software Craftsmanship.

I care a lot about User Experience.

I care a lot about designer-developer workflow.

I care a lot about continuous deployment (although I will opt for continuous delivery).

I care a lot about the lean startup movement (if you haven’t already done so buy, and read, Eric Reis’s book The Lean Startup).

I am firm believer in innovate or die and the need to conduct validated learning, and as such you should become intimately familiar with the build-measure-learn feedback loop.

I have spent a lot of time recently absorbing the technology landscape, whether that be HTML5, Flash, PaaS (Heroku, Windows Azure, …), BIG DATA, real-time, blah, blah, blah…

More than ever I feel technology doesn’t really matter. It’s an enabler. The difference between the choices that we have are closer than ever. Make the right choice for the job at hand. Practice Software Craftsmanship and you will have the confidence to adapt.

Software Craftsmanship in isolation is not enough. User Experience in isolation is not enough. Build-measure-learn on its own is not enough.

It’s a question of how we bring these methodologies and practices together and how an organisation molds itself around them. They need to be absorbed in to the corporate DNA and used to weave the fabric of innovation.

Going forward I feel our innovation mantra should be Design-Develop-Deliver. Like the build-measure-learn feedback loop advocates we need to rapidly move around this loop.

We need to shift our horizons to fully encompass the user. We start with the user and we end with the user. In his book Eric provides an anecdote about a feature not being complete until it has been validated by the users. I love this. It’s seems obvious and a subtle shift from the product owner or QA saying a feature is done, but its a big leap in terms of mindset. Imagine having the confidence to remove a feature (and deleting all the code) if users don’t actually get value from the feature? The focus this would bring to an organization would be immense.

We can destroy the traditional mindset and reject the dogma that software follows a fixed release cycle (regardless of how short it is). When the feature has been coded, give it to the user, it not done until the user says it is done.

I believe the Design-Develop-Deliver philosophy will allow us to innovate faster and deliver experiences that users want. It also creates opportunity for tech companies to enable this workflow. I would love to have a seamless set of tools and services that enable me to design-develop-deliver, this is far more powerful than getting caught up in the underlying technology debates and teams practicing their principles in isolation. We need to blend it all together.

Speak to your users in 3D.

TDD with Node

The last few days I’ve been looking at how TDD with Node. This blog provides an example project that uses RequireJS.

My requirements were kinda simple (and obvious):

• I want to easily write clear and articulate tests
• I want to use an expressive framework for writing test spies, stubs, and mocks
• I want a simple to use test runner so I can run my tests from a CI server (and ideally support for headless browser testing for when it comes to my client-side testing)

What I wasn’t expecting was an overwhelming choice of frameworks. That’s good…isn’t it? There were a few frameworks that initially jumped out, such as Vows. However, I struggled to get my tests working when it came to RequireJS. A lot of the examples I found out there were kinda of trivial and I didn’t find any good examples that showed RequireJS.

I have grown fond of RequireJS. I like that I can use it on both the client-side and the server-side, and I like the separation of concerns it affords in my code. So I was determined to find something that worked!

I came across Sinon.JS, which led me to Buster.JS (they both share the same author, Christian Johansen). Although Buster is still in Beta is made an immediate impression on me. It supports Node, it has Sinon embedded, it’s headless, the architecture is robust,…and the list goes on.

I soon got a simple test working and then struggled a bit with Require, but I eventually got it working!

My example app is intended to demonstrate the structure of a more complex app and how testing works. I’ve got a more comprehensive reference app coming soon. So enough said, jump over to GitHub for a closer look, the README provides more context.

Below is the documentation that I think you will find most useful:

• Node testing
• Sinon integration
• Sinon documentation

Predictive Analytics for eCom

Recently I worked as part of a multi-disciplined team of User Experience designers, Software Craftsmen, and business domain experts to deliver a SaaS-based solution for Predictive Analytics.

It is targeted at existing customers of Adobe SiteCatalyst. The premise is relatively simple. We take historic web analytics data and run it through forecast models, which are typically associated with the investment world.

In the context of an e-commerce site and revenue we are looking to predict revenue and to identify problems ahead of time i.e. a shortfall in revenue. Think of it as an “early warning system”. This is where it gets interesting. The question we then want to answer is what actions can be taken to counter the shortfall? By knowing the correlation between site metrics and revenue the user can then model a % percentage in a metric and what impact it has on the revenue, which may be positive or negative. This level of foresight can then be used to make up the shortfall.

The experience is delivered on an iPad and leverages a statistical analysis engine on the server.

This was truly a fun project to work on and showcased the tight interlock between User Experience and Software Craftsmanship to deliver the “best imaginable experience” that meets the needs of the user – Experience Craftsmanship.