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!