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.

Having had our 1st client meeting back in April 2008, I’m delighted to confirm that we are now on the verge of launching phase 1 of our clients new ERP (Enterprise Resource Planning) system.

Regular follows of our blog will know that this project has been delivered using very much a user-centered design approach, something which our client C&O Powder Coatings knew absolutely nothing about until we introduced the concept to them back in April last year.

It is fair to say that if we didn’t use this user-centric approach to deliver bespoke web and business applications we would not have won the contract in the 1st place, as our client has heard countless horror stories of off-the-shelf business systems causing productivity and efficiency issues, in extreme cases nearly bringing some businesses to their knees.

2 months before the application has actually being installed, key members of the management team at C&O Powder Coatings shared their thoughts on a few key business areas:

• what are your efficiency and productivity issues?
• what are your customer service demands?
• what are your expectations?
• what does user-centered design mean to you?

If you haven’t seen the video then I’ve embedded it below:

You expect to hear much more on this project over the coming months, such as a case study and a run through of the technical development process of the Adobe AIR application from Rob.

In the meantime below are a few more related links:

• slideshow on usability for internal business systems
• AdobeAIR official website
• AdobeAIR showcase applications – Mini, Aol, Ebay

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.