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()
        });
    }
});

Advertisement

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.