Paul Rouke - Usability Professional

We’ve just launched our latest project at PRWD, a manufacturing resource-planning application (MRP) which is being adopted by a local manufacturer. MRP, and its close cousin ERP, systems are used to facilitate essential business tasks, such as order processing and the tracking of jobs through production.

This has been quite a bold step for us, given that ERP systems are famously complicated. We started out with a knowledge of web technologies – HTML, JavaScript, PHP – and software design techniques mostly gained from experience of delivering web projects – user-centered design and web usability. What we did was apply those technologies and techniques to delivering a very specific type of business application. And what we found was that these techniques worked far better than even we had expected.

In this post I will mostly be talking about the technology, but you can read an earlier post which includes video feedback and comments from the customer and links to other resources.

The Challenge

For us, the challenge was taking our expertise on the web into a different environment. The requirements for the application we’ve developed specified that it be able to interact with the IT environment, including saving files to the local disk, printing, creation of PDFs and other files and that it should operate on a local network. No ‘cloud’ hosting here, or simple ‘just run it in the browser’ operation. Furthermore, ERP systems are typically quite complex and there are no real examples of web-based implementations. It was clear that we’d have to break some new ground.

When is a browser not a browser?

Image via Wikipedia

To deliver the kind of intuitive, user-centered user interface that we wanted, and to utilise our existing skills and expertise, we wanted something browser-based. But we didn’t want the application to be just another tab in the web browser – we wanted the application to be able to have full control of the user experience, with notifications, modal dialog windows and other features more typical of standalone desktop applications. For that reason, we decided early on to get to grips with Adobe AIR.

AIR supports two main modes of operation: the first involves running applications based on the Flash platform; the second is based around a WebKit browser, providing extra services to the application via a JavaScript interface. It was the latter option that we chose.

This made creating the interface a breeze, especially important as we had our customer heavily involved in the development process. Using HTML meant that we could go quickly from a paper sketch to a wireframe image to a HTML mockup and to a working prototype. And if we needed to make alterations (which, following customer input, we often did) then it was painless to repeat the process and have a new working prototype up and running quickly. This enabled a rapid, iterative development cycle which was a perfect fit for the user-centered design approach.

JavaScript and jQuery

To create the smooth, intuitive and responsive interface required, we adopted jQuery as the JavaScript library of choice early on. jQuery provides ‘just enough’ functionality to get a complex web app started – AJAX, DOM manipulation, visual effects and event handling are all made incredibly simple. We ended up building several thousand lines of JavaScript code on top of this, but jQuery meant that we didn’t have to worry about handling the basics.

Since Adobe AIR exposes its extensions to the browser via JavaScript functions, it was easy to integrate access to the local filesystem or a local database. This helped to ensure a fluid user experience and, from a developer’s point of view, working with JavaScript was immensely enjoyable. It’s a great language that can only really be appreciated after a project like this, where it’s stretched to cope with more than just some visual flair or AJAX data submission.

PHP and the server-side

Again, we wanted to make good use of our existing expertise on this project, so we stuck with PHP and the Symfony framework. Again, this enabled some pretty rapid development, to the point where – once some infrastructure code was written – we were able to add the facility to store lots of different kinds of data on the server merely by altering some configuration files and without having to write a single extra line of PHP. This was crucial because the main purpose of the server was to act as a data store for information about orders and job tracking.

REST and the data model

The server would store the data, but how best to access it from the client software? Early on, we adopted the principles of REST – REpresentational State Transfer. In a nutshell, this means using the protocols that the HTTP specification – the underlying design of all web servers – gives us. It means thinking in terms of ‘resources’ that can be identified as residing at certain locations on the server, and breaking down the data model of the application into resources that can be created, updated, viewed and deleted.

Because the data model of an ERP application is quite complex, having a clear set of principles about how this data model is exposed within the application was important. REST gave us some simple rules about how to handle data and how to handle some of the tough problems of synchronisation and versioning of changes being made by multiple users concurrently. Again, this was important in the context of the rapid and responsive development cycle we needed to have; adding extra data and extending the data model was painless where it was required.

Web technology on the desktop and in the enterprise

What this experience has made clear to us is that the techniques of web application development, forged in an environment where rapid development is essential, where every click and every second spent on a page counts and where usability really matters, are just as applicable in an enterprise environment. The same approach that can help sell more on an e-commerce website can help to make an office employee more productive. And the same technologies that allow rapid development in response to competition on the web can be used to drive rapid development in response to business needs too. Getting users on the web involved in driving the development of a website is great, but getting employees involved in driving the development of the business system they spend most of their working day using is even more important.

There can be little doubt that the major desktop software innovation of the last decade-and-a-half has been the web browser. The web has helped to create far more powerful tools for user interface designers, allowing them to create much better – and, in some cases, much worse – user interfaces. And, these days, we’re all so familiar with the browser, the metaphors of ‘back and forward’ navigation, the look-and-feel of websites, that it makes perfect sense for new applications to be developed around the technology of the browser.

Finding the best means of achieving this – of leveraging web technologies in desktop business applications – hasn’t always been easy. We want powerful web applications that can access the local file system, network file shares, printers and other devices. But there are also security concerns whenever any browser technology is used – the potential for dangerous scripts to be downloaded from the web makes IT managers rightly nervous.

Adobe AIR is one well-established attempted at solving these problems, and it’s something that we’re using at PRWD to deliver business applications for our clients.

From an application development perspective, AIR is a great tool to work with. The most important advantage is the fact that I can build the application using standard web technologies – HTML, CSS, JavaScript – and yet also have access to extra features and functionality that would normally only be available to applications developed for .NET or Java. This makes it easy to implement clean, functional user interfaces which are familiar and reassuring to end-users. It’s possible to take advantage of 15 years of best practice in web design, layout and interactivity when building a desktop application.

As an example, here’s one of the screens from a web application that we are building at the moment:

It’s a simple HTML interface, clean and easy to use.

Even better for developers is the fact that you can easily access back-end systems using AJAX. In the application shown above, the interface is almost entirely powered by JavaScript running in the browser, but data is also frequently exchanged with the server in the background. With some common sense in the use of REST architecture, this provides a responsive application for the user, as well as ensuring that it’s as easy as possible to add new features to the front end. This makes the separation between data, logic and presentation much clearer than in typical web applications, a fact which tends to make quality control and testing much easier.

For future business systems this kind of approach, based on open protocols and ubiquitous technologies, will be essential. The use of principles such as REST and data formats such as XML and JSON mean that it will be possible to build a wide range of components which access the back-end service, including other enterprise services, as well as a multitude of client applications which may include mobile devices as well as desktop applications.

User-centered design is a big part of what we believe in at PRWD. At its most simple, UCD is all about ensuring that the needs of the user are placed at the heart of the development process, from the very first designs to the very last details of implementation and support. A UCD process involves significant stages of testing in which real system users are able to give their thoughts and opinions on a system’s design and use and ensures that, when deployed, the new system will fit neatly into the intended environment. For customer-facing websites such as e-commerce sites, this is all about ensuring that the customer’s experience of the site is enjoyable, making it easy for the user to locate and purchase those items that may be of interest. Whilst this all sounds quite obvious, it’s amazing how much difference can be made to a site’s conversion rate by testing it against users in the real world!

The Usability Professionals Association, an international industry group, provides a definition of user-centered design which includes the following development cycle, codified in the ISO standard 13407:

1. Specify the context of use
   Identify the people who will use the product, what they will use it for, and under what conditions they will use it.
2. Specify requirements
   Identify any business requirements or user goals that must be met for the product to be successful.
3. Create design solutions
   This part of the process may be done in stages, building from a rough concept to a complete design.
4. Evaluate designs
   The most important part of this process is that evaluation – ideally through usability testing with actual users – is as integral as quality testing is to good software development.

This process still leaves a substantial part of the development process open to discussion. In particular, it doesn’t make any specific reference to the technical implementation of a project. Since that’s my responsibility, that’s where my interest lies! However, there are many development methods which are a good fit for UCD, and this includes the ‘Agile’ development methodologies.

Agile software development comprises a group of related approaches to software development which attempt to overcome many of the problems faced by traditional software development processes. The fundamental tenets of Agile Development are set out in the Agile Manifesto, and the approach is summarised as follows:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In short, Agile development is based on the notion that software development processes can be unpredictable and that the bigger they are, the less predictable they become. Agile offers us some important insights into how to manage that process on a dynamic basis, rather than try to eliminate all uncertainty with a huge and detailed up-front plan. As a result, Agile development can cut costs and cut delivery time by placing the emphasis on delivery and quality, working with customers on a good faith basis rather than by setting down overly strict requirements at the start which may bind both parties in ways that neither wants. And this is a very good fit for user-centered design, because it leaves open the possibility of incorporating user feedback as the project gets underway.

One of the 12 principles of Agile Development is this: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. User input and user testing are perfect examples of that kind of late change. Imagine that you’re setting up a major new e-commerce store; your company needs to boost sales but can’t extend the marketing budget. User testing reveals that the new system does improve slightly on your old one, but with a few more improvements – perhaps to increase the user’s trust in your system, or to improve the system for recommending related products – you could gain a few more percentage points on your sales. At that point, you need a software development process that can react and incorporate those new insights into the site development.

Agile development puts an emphasis on delivery of working prototypes early in the development cycle, giving customers and users a much better idea of what will be delivered at the end. And because these prototypes are delivered early, it’s much easier to incorporate feedback into the finished product. Having worked in software development for some time, I’ve seen plenty of frustration from clients who want to make changes at the last minute, causing even more frustration amongst the software developers who see weeks or months of work being re-written to accomodate them. Projects go over time and over budget when that happens, and Agile development excels at preventing these problems.

It is by combining the two approaches outlined above that we deliver our projects at PRWD. As a developer I’ve found the Agile mindset to fit much better with the problems that I have to solve and with the need to react to a variety of inputs, from clients and system users alike. Being that responsive to user requirements does require a change in mindset from that of a traditional software developer: it’s no longer safe to assume that I always know best about how something should work, and I have to be more flexible to cope with the requirements of the users. But this is all worthwhile as it reduces the pressure associated with delivering a piece of software – if the users and the clients have been involved in the development, you know that they will be happy with the end result.

This post is the second in a series. The first post focussed on the strengths and weaknesses of the Zend Framework. This post about another leading PHP framework, Symfony.

Note: This post refers to Symfony 1.0. Version 1.1 has recently been released, but I have not had time to examine it in detail, though I imagine that most of my comments here apply equally to the new version.

Superficially, Symfony reminds me of Django. This is a Good Thing in my book. Symfony is a framework that is clearly designed to get applications up and running quickly, with a good ORM system and the facility to generate basic code automatically. The contrast with ZF is quite clear: Symfony is a tool that makes building web applications quick and easy as a top priority.

Features

Symfony provides all of the things that one would expect from a modern web framework, and a few more besides. The MVC components are all there – model development is supported by an ORM system that uses the Propel library, although there’s nothing to stop you using another library, such as Doctrine, instead (in fact, this is quite commonplace, and there is a well-supported plugin for Symfony that does just that). The controllers (‘actions’ in Symfony parlance) are supported via a base class that provides useful abstractions over the HTTP request/response process. Views are rendered automatically for successful actions, with ‘partial’ views allowing sub-elements of a view to be templated, and ‘components’ fill a gap between heavyweight action-view combinations to provide ‘widgets’ which can be reused in different views throughout your app. Various helper functions save time and code by generating common HTML elements for you.

A lot of time spent on small Symfony projects will be spent editing configuration files as much as writing code. Some people might not like this, but I found it to be inrcredibly useful. Form validation, for example, can be set up using configuration files (although you can extend the basic set of validation options using custom classes). More importantly, your data model is defined using a configuration file which specifies your tables, their contents, and the relations between them. Once you have created your schema file, you can run command-line scripts to auto-generate the PHP class files that form the basis of your model. For example, for a table called ‘Posts’, Symfony (or, more accurately, the Propel library) will generate a PHP class called ‘Post’ which you can edit yourself, but this class inherits from the class ‘BasePost’ which provides getter/setter functions for the fields, as well as functions to retrieve related objects. Also created is the PostPeer class which provides (mostly static) functions to retrieve Post objects from the database. From here, you can run further commands which will generate basic CRUD modules – you can actually have a functional data-entry app without writing a single line of code. It will rarely be useful for production purposes out-of-the-box, but it provides a good foundation to build from.

There are plenty more configuration files, controlling database connections, caching, routing (URL paths), logging, security (access control) and default view settings, amongst other things. This approach won’t be to everyone’s tastes, but I have to admit that I liked it. One wrinkle is that many of these configuration files are in YAML format – a kind of strange hybrid of INI files, XML and Python’s whitespace handling that has been used in the Ruby on Rails. Again, it’s a matter of personal taste, but I found these files to be more readable than XML and certainly a lot less typing is involved in editing them.

Documentation

The documentation for Symfony is awesome. It is, quite simply, the best set of free documentation I have ever read for any software library, ever. The documentation on symfony-project.org consists largely of three main parts: The Book, the API reference, and Askeet. The Book, as the name suggests, consists largely of the content which makes up The Definitive Guide to Symfony, by Fabien Potençier (CEO and lead developer at Sensio Labs, where Symfony was created) and Francois Zaninotto, until recently the head of the Symfony documentation team. The Book is an invaluable reference to the core features of Symfony, and provides all of the introduction that anyone could need. The API reference provides a comprehensive backup for when you need the precise details, although it could be slightly easier to navigate. And, as if all of that were not enough, there’s ‘Askeet’, a 24-part mega-tutorial, in which Symfony is used to create a whole, functioning web 2.0 app, in easy-to-follow stages. Each stage represents a new achievement, with an emphasis on getting a new working piece of functionality in place. Often, code from earlier stages is substantially refactored during later ones, providing a good example of how to go about transforming a prototype into a final application. The bottom line: Symfony’s documentation rocks.

Community

Symfony’s community is not huge, but does seem to be fairly active. Symfony seems to follow the ‘benevolent dictatorship’ model of open source development, as exemplified by Linus Torvalds‘ leadership of Linux or, in the PHP realm, Dries Buytaert‘s leadership of the Drupal project. Fabien Potençier appears to be the overall head of the Symfony project, although there are other major contributors. Symfony seems to have a particularly strong set of plugins – code modules which extend or enhance the framework, or provide substantial units of functionality which can be plugged in to Symfony apps. There certainly aren’t as many Symfony plugins as there are, say, Drupal modules, but this is a strength that does not seem to be present in many other PHP frameworks. The community is also active in contributing documentation, with Andréia Bohner’s Symfony cheat sheets being a shining example.

Conclusion

I have to admit, I’m now something of a fan of Symfony. There is a streak of common sense running through the way it works which makes it very fun to work with. The documentation is fantastic, and the community looks strong enough to support development for the long term. The only dark cloud on the horizon is the fact that questions have been raised by some long-standing community members about the direction that the newly-released version 1.1 is going in, suggesting that it may be sacrificing some simplicity and ease of development for a slightly more ‘purist’ approach to code structure. Time will tell whether or not these fears are well-founded but, for now, I think that Symfony is worthy of recommendation.

I have recently been researching various PHP frameworks, for use in upcoming projects. These projects are large-scale, enterprise PHP systems which are going to be developed and maintained over a long period of time, so making the right choice of framework is crucial. Also important is the ease of development – how easy the different frameworks make application development, and how they support rapid development, prototyping and agile development processes. This post is the first in a series comparing the strengths and weakness of PHP frameworks.

The first two frameworks I have considered are the Zend Framework (currently at version 1.5) and Symfony (version 1.0, though version 1.1 has just been released). I have considered a number of different factors and my judgements are very much a subjective view. I have had plenty of experience of different software libraries, from coding C++ using the Microsoft Foundation Classes library in the late 90s, to PHP using the Drupal CMS/F (whether one considers Drupal to be a ‘framework’ is a matter of debate) and Python using Django. In this time I think that I have learned to spot the strengths and weaknesses of frameworks and libraries, so, although subjective, my views aren’t totally uneducated.

Zend Framework

The first thing to say about ZF is that it wasn’t what I expected. Having used Django and observed the general trend in web frameworks towards code generation and advanced ORM, ZF was surprising in that it bucked this trend entirely. If you want CRUD code with ZF, you can write it yourself. This, in itself, is not necessarily a bad thing, but it is slightly discouraging when you just want to get in and have a play about it with the framework. In this day and age, the ability to rapidly assemble a working prototype is very important, and ZF could go further in making this easy.

Features

After a while of using ZF, it becomes apparent that my initial objection – that it doesn’t really speed up development during the very early phase of a project – is an intentional design choice. The ZF developers refer to this as ‘use-at-will’ architecture; in old-fashioned software engineering lingo, we might say that ZF is ‘loosely-coupled’, in that the various classes it provides can be used separately, without reference to the rest of the framework. This makes ZF a great choice for refactoring legacy code, as you can just plug in those bits of the framework that you need, without having to modify anything else. If all you really want is the (very useful) ZF Akismet class (which interfaces with Automattic’s Akismet service), you don’t need to use the rest of the library at all.

In fact, after a while I started to think that the aims of ZF are actually somewhat different to the aims of other frameworks. Most other PHP frameworks were funded and contributed to by developers who needed the functionality in their day jobs. CodeIgniter came from the development of ExpressionEngine, Fabien Potencier’s Sensio Labs created Symfony to power their in-house projects, Drupal was started by Dries Buytaert to provide a basic community website and forum and Ruby on Rails began life as a basic library of functions used by 37 Signals for the development of Basecamp. The Zend Framework, on the other hand, was funded by Zend specifically to create a strong, reliable PHP framework in order to give PHP a rival to Rails and Django. It is, in effect, an ‘immaculately conceived’ framework, designed from first principles to support the widest-possible deployment, rather than to solve specific common problems.

In this respect, ZF is more of a ‘library’ than a ‘framework’. It provides a set of classes that you can use as you see fit, taking out the ones that interest you, and leaving the rest. What it does not really do is provide you with the basic foundational structure of an app that most other web development frameworks tend to do these days. This is probably due to Zend’s different motivations in creating ZF – they are not a bunch of deadline-driven web developers trying to make their own jobs easier by creating a framework to build new apps with; instead they are attempting to create a set of classes that others can use in a whole variety of different ways, many of which the ZF developers cannot anticipate.

As such, ZF represents something similar to the C++ Standard Template Library – the object-oriented successor of the older C Standard Library. Zend appear to be trying to give developers a new set of modern, object-oriented tools with which to build applications, perhaps replacing some of the reliance on the huge legacy PHP feature set.

Documentation

ZF’s documentation is poor. There’s a reasonably good reference for each class, but there are nowhere near enough example applications and tutorials. This is probably related to the fact that ZF classes can be used in isolation from each other and there isn’t always a clear way of constructing a basic app to make use of these classes, but this is no excuse. For a developer considering ZF for the first time, it can be hard to see exactly how one is meant to make use of it. What examples there are tend to be quite complex and focus on the arcana of the framework’s implementation than practical use cases. This is my single biggest problem with ZF.

Community

The genesis of ZF also contributes to the slightly odd feel of the community. Coming from a Drupal background, I’m used to a very self-reliant community, with a strong ‘do it yourself’ approach to improving the software, the kind of ethos that, to me, signifies a truly great open source development. The Zend Framework doesn’t have that yet. Too often, the ‘community’ seems to consist of ‘users’ rather than ‘doers’, people who would rather petition Zend to improve the software than submit a patch or create a new module. Open source projects, if they work well, are a bit like crowd-surfing at a gig – you throw yourself out there and hope that enough people decide to catch you. At the moment, it’s not apparent that there are enough people to catch the Zend Framework, so it can’t make the leap. The developers can’t quite let go of their creation, either because they are unwilling to, or because there’s not enough people there to catch it. This does lead to some unfortunate examples of developers reacting personally to criticism, rather than the standard open source response of ‘fix it yourself if you don’t like it!’.

Conclusion

ZF’s strengths are clear – the code is well-written, covers a range of common web development tasks, including some areas neglected by other frameworks, and succeeds in making it easy for developers to incorporate ZF code into legacy projects. These strengths alone make it an important piece of software that is likely to remain relevant for cutting-edge PHP developers over the next few years. The framework’s weaknesses – that it isn’t really a framework – are easily addressable; it’s not hard to imagine someone creating the additional ‘glue’ that would make ZF a viable framework in the mould of Rails and Django. If that code came from the community rather than Zend, then it would be a sign of ZF blossoming into a truly useful framework. And if this could all be documented, we might be getting somewhere!

Part two of this post will consider the Symfony framework. Stay tuned!