Design-centered development

During the late 1990s I had the pleasure of working with Nucleus Design Ltd, a design consultancy based in Thames Ditton in the UK.  One of the projects I was involved in was the development of a web-based shopping pilot application for one of the major supermarkets in the UK: one of the first of its kind anywhere in fact.

One of the most interesting aspects of the project was the focus given to the project by Nucleus: that first and formost this was a design exercise, not a programming one,  A significant proportion of the preliminary work was about design: understanding the mindset of shoppers when they walk down an aisle in a supermarket, and figuring out how to translate that into a web-based user interface that was intuitive for the shopper.

Since that experience, I have always maintained that design is the absolutely critical aspect of an application.  What makes an application great, what makes it immersive and addictive is its design.  Great applications are nothing to do with programming.  Programming is just the necessary part that is required to realise a great design.

The crazy thing is that this is completely at odds with the way the IT industry sees things.  Look at any of the most popular web application development frameworks (eg Django, Ruby On Rails etc), and you’ll quickly discover that they view the process as first and formost a programming exercise.  It’s about writing code in whatever is your favourite programming language, and getting that code to perform the task of creating the markup and handling state/session management for you.

Unfortunately for everyone (and as I discovered at Nucleus), design is a very different discipline from programming.  Few designers, in my experience, know a great deal about programming and find many of the concepts in programming and accessing databases pretty baffling and/or incomprehensible.  Similarly, few programmers, in my experience, have much clue about design, other than the technical rudiments of it.

The normal process of web application development goes like this:

  • a designer is used to figure out the concept and overall look and feel of the application.  The design is discussed, refined and agreed.  The design often takes the form of storyboards using some graphical tool – occasionally a mocked up facade may be created to run in a browser.
  • the design, once agreed and signed off, is handed over to the programmers who “script it up”.  What this really means is that the design is buried inside lots of programming code in whatever is the favoured computer language at the organisation and on which the favoured development framework is based.
  • the working application is released and hopefully runs according to the designer’s design.

This would be fine if it weren’t for one of life’s great inevitabilities: change.  Modifications and enhancements are identified, changes to the original design are required.  But there’s a problem: the original design is now buried inside programming logic that is incomprehensible gibberish to the designer.  The designer is out of the loop.  Control of the design is now forever in the hands of programmers.

The programmers can, of course, attempt to work with the designer, to “code up” changes that he verbally describes.  But at the end of the day, what has really happened is that the discipline that should have control and which should retain control over the most critical aspect of the application – design – has lost it to the discipline that is most irrelevant in terms of the application’s success.

Based on that experience at Nucleus in the late 1990s, one of EWD’s design goals was to make it design-centric and ensure that a designer could be in control and remain in control of the application’s design.  The result was something very interesting: it turned out that the programming aspect ended up being rarely anything other than trivial.  Let me try to explain:

In EWD, applications are defined as pages or fragments, each of which describes, at a high level (expressed as XML-based EWD Custom Tags) the design of its bit of the application’s UI.  EWD pages are all about design.  Each page or fragment can have an onBeforeRender method – a reference to a back-end function that will do programming-focused stuff before the page or fragment is rendered.  The onBeforeRender methods are really the only programming part of EWD – they are certainly the only part of an EWD application that relates to the manipulation of the back-end database.

It turns out that the programming tasks involved in even the most complex EWD-based web applications  in which I’ve been involved are really quite trivial.  They boil down to:

  • running queries or existing back-end APIs to extract data from the database and placing it in the EWD Session ready for display by the UI.
  • validating incoming data (eg from forms in the browser UI) and saving them to the database (often via existing APIs that manage and maintain the database indexing and integrity)

EWD’s onBeforeRender methods do not and cannot have direct access to the UI.  They simply access and update the EWD Session: the user’s ephemeral session data storage.  EWD back-end script programers therefore have no role in the UI design.

Meanwhile the EWD pages know nothing about the database back-end.  They only have access to data held in the EWD Session.

Therefore, the front end EWD pages (the responsibility of the designer) are decoupled from the back-end database-related programming, with the EWD Session being the common middle-ground.

Most critically, in EWD, the common industry technique of data-binding – where form fields and other data in the UI are linked to data in the database as properties of database-linked objects – is not available.  Despite the IT industry’s love affair with data-binding, EWD’s decoupled architecture has proven to be highly effective in practice and incredibly productive (eg see http://clinuip.wordpress.com/ where a very complex clinical UI and supporting back-end database was conceived, designed and developed by one clinician and one developer in just 10 days, from scratch) .

Indeed my view is that the technique of data binding is one of the programmer mindset-centric curses of the web application development world.  It’s a great way to quickly create a demo, but quickly bites everyone in the backside when you want to create a production-ready application.

By comparison, EWD’s clean and decoupled separation of design from programming is one of the keys to its productivity and easy downstream maintenance.  The designer can stay in control of the EWD pages at all stages in an application’s life-cycle.  EWD has also demonstrated to me, time after time, that web application development should not be first and formost a programming exercise: in fact EWD demonstrates that programming can (and should) be a relatively trivial part of the exercise.

So next time you’re considering the framework to use for your web application development, spare a thought for the designer and remember it’s the designer, not your programmers, who is critical to success.  Programmers, of course, will, I have no doubt, continue to believe that it really is a programming exercise, and won’t understand the fuss I’m making.

But remember that programmers rarely have to pay for the development and downstream maintenance of the application throughout its lifetime, and will be always eager to use the latest in-vogue technology to enhance their career progression.  But that is a theme for another posting, perhaps!

Advertisements

2 comments

  1. Thanks Rob,

    Again another very important post..

    One of the recurring themes of implementing software most of us are familiar with involve the challenge of both scale and maintenance.. as the rest of the world changes.
    Another is the all too common clash between process change and software change.
    So the need for any knowledge based economy to get a better union between process improvement methods and related information technologies will become an increasingly important issue, in my view, as we all endeavor to work smarter>harder.

    Which is one of the reasons why user-centred design has become increasingly appreciated in recent years. This could raise some tension between user and developer until/unless both the business world and software industries embraces the importance of the users becoming more involved in the software development process.

    The likely answer which will emerge over the years ahead should be an increasing blurring of the boundaries between user and developer as better software tools emerge.
    This wordpress.com blog is a case in point… which has enabled web site administration and content authoring to be more easily available to the masses with amazing consequences for us all.

    As the clinician involved in the clinuip.wordpress.com work you mention, I’ve been very impressed with the design oriented approach and productivity of your EWD framework thusfar.
    Yet I’m aware that your work is not yet done and you foresee more changes ahead..
    Could you give a sense as to how you see the role of agile, user centred design and development moving forward in the years ahead?

    In particular would be interested in some discussion about the toolset required to support these changes..
    There still remains some important gaps within the current tools we might use in 2012 (eg Sencha Architect/EWD/GtM) which means the bar is still too high for most/all those involved in business change to understand/work more closely with their developer colleagues.
    Could you comment on the likely direction you expect things might take?

    thanks

    Tony

  2. Let me touch upon an EWD characteristic that affects design which was only mentioned in passing by Rob. The ability to decompose a web page and web interface into named web fragments is as powerful for design as using subroutines is for programming.

    I expect there is a lot of work done behind the scenes to make sure that various design elements may be arbitrarily embedded into design containers, even containers being embedded inside other containers. The genius of attaching those design elements into EWD as independent named fragments lessens the need for programming by designers, and keeps the over-all web application much simpler.

    I applaud this innovative insight by Rob and know that it makes life simpler for all of us, designers and programmers alike.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: