Testing Testing 1, 2 3

We’ve been busy working with some of our existing clients such as Contact Packaging (selling printed tape) and new clients such as The Translation People (providing document translation services) in optimising their conversion rates through analysis and testing (split and mutli-variate).

Event Speaking

Following on from my successful and rewarding presentation at the recent How Do conference in Liverpool, Rob Knight (PRWD’s lead technical architect) has spoken at an event titled Developing With Adobe AIR, which had a keynote from Adobe. Rob’s presentation was titled Business Systems With Adobe AIR and it featured the work we’ve done with a manufacturing company to deliver a user-centered designed business system for them. We have also developed a micro-site detailing our business systems and e-commerce services for manufacturers.

Case Studies

We’ve also released a couple more case studies of some of the work we have been doing and the results we’ve had, in particular on improving online sales by 400% for one of our clients and a technical case study on using Adobe AIR for business systems.

Twittering

I’ve been twittering over the past few weeks (not consistently I hasten to add!) and along the way picking up quite a few new followers, some of which I would put in the spam category. We have also been updating the PRWD twitter account although you tell its alot younger than my personal twitter account!

Featured Supplier In Econsultancy’s User Experience Buyers Guide 2009

We were delighted to be asked to feature as one of the 26 agencies who specialise in user experience and usability in Econsultancy’s annual guide on this topic. I also spent time providing feedback on a number of questions relating to the industry, and if you download the full version you will see various quotes from myself.

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.

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.

The Problem

The problem that Slimtimer attempts to solve is the problem of time-tracking. When you’re doing a mixture of in-house project work, billable client work and travelling to meetings, events and workshops, it’s important to keep a track of how long you spend on these activities. The uses of this data can be varied – perhaps you want to know which clients require the most time spent in meetings, or you want to compare project estimates with time logged – but the most obvious reason is to keep track of time spent for billing purposes.

The Solution

Slimtimer aims to solve all of that, by providing a good general-purpose time-and-task management system. It’s entirely web-based, meaning that there’s no software to install and you can access it from anywhere. It enables you to track – down to the second – time spent on individual activities, and it allows you to place comments and tags on these activities for later review. This makes organising your tasks very flexible. You could have a ‘Coding’ task, with different tags to reflect the different projects, or you could do it the other way around – tasks for each project, with tags indicating the type of activity undertaken. It all depends on what you find to make the most sense.

Upon logging in to your Slimtimer account (accounts are free, though premium accounts are available) you can go straight to the ‘Manage Tasks’ page. This gives you an overview of the tasks that you have added and how many hours you’ve spent on them. Before you can record any time on a task, you need to add it here.

You can also add default tags to a task – for example ‘billable’ might be a good tag for all tasks which relate to billable work. ‘Personal’ might be used for personal tasks, and so on.

Once you’ve added some tasks, you can start tracking your time. There’s an ‘Edit Entries’ interface which allows you to input details of how long you spent doing something – great for recording activities that took place away from the computer, such as meetings or events. But one really useful feature is the ability to start a live timer which counts time as you spend it. Right now, my timer is ticking away on the ‘Blogging’ task, recording how long I’m spending writing this post (once it’s done, I might add a comment to the task entry with a link to the post I’ve written, so I can see exactly where the time went). From within the timer window, just click the name of the task and the timer starts immediately and continues until you click the ‘stop’ symbol or click another task.

Now, this is where things get interesting and where the second part of this post begins. Slimtimer does allow you to open this timer up in a new browser window, but there are a few pitfalls here: what if you close the browser? What if it crashes? What if the timer keeps getting lost amongst the 50-or-so tabs you have open? What if your job doesn’t involve having a web browser running constantly?

This is where Mozilla Prism steps in. Prism is a system which creates a special instance of the Mozilla browser (you know, the browser that Firefox is based on) which runs only one website. I now have a ‘Slimtimer’ application on my Windows start menu and when I click it, Slimtimer opens straight up. No typing in URLs or clicking bookmarks. If I close Firefox down, Slimtimer stays running. In fact, I copied the Slimtimer shortcut to my Windows ‘Startup’ folder, so now Slimtimer starts running when my PC starts up, even if I never go near a browser. This gives Slimtimer a lot of the appearance of being a full application, and makes it a lot easier to keep track of. There’s a permanent Slimtimer icon in my system tray and clicking this brings Slimtimer up immediately.

Prism can be used for a whole range of other sites too and is particularly suited to those productivity sites which you need constant rapid access to – mail, calendar and task management sites. In fact, any site that you have open constantly could probably benefit from living inside its own dedicated ‘application’.

To Prism-ize a site, install the Firefox Prism extension, then browse to the site in question and simply click ‘Convert Website to Application’ from the ‘Tools’ menu. There are a few options to configure, but the defaults probably won’t need changing – just choose where you want your shortcuts created. And to have an application start up with Windows, just copy a shortcut to the ‘Startup’ folder in the Start Menu’s Programs folder.

So I am hereby serving notice that TechCrunch UK is going to start campaigning for a Digital Hub for the UK.

The working title for this concept is “The TechHub”.
…
Unfortunately this is going to sound boringly London-centric. But I think it ought to be in London. Why? Simple really. Money, access and the networks inside London.

I’m not sure that this idea holds much water. London has a number of major problems, mostly related to cost, which are major obstacles for small companies. London’s major claim to a role in the software eco-system comes from the fact that the financial services sector employs a lot of very able people developing and maintaining their software infrastructures (one of my favourite developer-bloggers, Kirk Wylie, is one of these). But the London financial services sector is in deep trouble right now. Moreover, office space is very costly in London compared to pretty much anywhere else in Europe, never mind the rest of the UK. The ‘London premium’ on salaries required just to get people to work there is an unavoiable fact. What’s unique about Silicon Valley is that its whole identity is bundled up in the idea of innovation, technology and entrepreneurship – the technology and software industries dominate there. London, on the other hand, is a centre of culture, tourism, history, government, finance and countless other things. The software industry will only ever be a small part of what London does and these other industries all compete for valuable space, resources and labour.

I’d like to argue against the idea of a single Tech Hub. Britain (or, more to the point, England) is a small country and there really isn’t much need to focus all of our attention on one area, particularly one that is already over-crowded. Travel between London and Manchester is doable in under two hours by train and this could be cut further if plans for a high speed rail link are approved. This would allow for startups to take advantage of the much lower costs of locating in, say, Manchester without losing touch with London and vice versa.

But if we do need a Tech Hub as Mike Butcher insists, where would I place it? Perhaps unsurprisingly, I’d vote for Manchester.

Why? The North West of England already has a number of advantages. The number one advantage as far as I’m concerned is the growing strength of the local developer community. There are a number of grass-roots groups in existence for networking between people working in the digital/tech sector – these are not top-down imposed groups funded by some quango or other, but private community initiatives to promote the North West tech community’s growth. The umbrella group for these, North West Digital Communities helps to ensure cross-fertilisation of ideas amongst the groups. The GeekUp community already holds regular meetings in Manchester, Liverpool, Sheffield, Leeds, Chester and Preston. Web development is well represented with groups for Ruby, Drupal, .NET and PHP. The PHP group in particular has grown extraordinarily in a short space of time and will, later this month, be holding the PHPNW08 Conference. Jeremy Coates deserves huge acclaim for driving this forward.

In addition, AgileNorth plays a role in promoting agile development practices and the Northern User Experience group is a growing forum for discussion of usability issues. The startup company sector is represented by NW Startup 2.0, which brings together innovators, venture capitalists and local tech companies for regular meetings and workshops. The notion that it’s all grim up north isn’t borne out by the facts.

If there’s anything that the North does badly, it’s probably self-promotion. Years of industrial decline as the manufacturing industry of the 20th century has withered away have left their mark and a lot of people don’t yet feel ready to shout about the good things that are happening. But what’s happening here is an organic, grass-roots growth of clusters of talented, passionate people who are interested in innovation. You can’t create that by coming up with clever branding ideas, blog memes or ‘campaigns’; nor can you create it merely by throwing money at it. It requires passion, inventiveness and talent, combined with the right environment to enable the expression of these attributes. The North of England does a lot better on these scores than many people would think.

I would recommend having a read as the usability issues that I talk about are what we have all experienced during our working lives, and there is extensive research provided which proves that the majority of business systems and software solutions in the market don’t value usability anywhere near as highly as we would always advocate.

The article includes my:

• evaluation of the enterprise level software market
• industry analysis on the lack of importance placed on usability in software
• advice on how businesses can attempt to improve the usability of their existing systems
• advice on how User-Centered Design should be embraced for businesses looking at bringing in new internal software systems
• summary of why usable internal business systems shouldn’t be a pipedream

Further reading

• User-Centered Design for Lean Manufacturing Business System Improvements
• User-Centered Design and Agile Development
• User-Centered Design Process Overview
• PRWD Press Release – Bringing User-Centered Design Into A Manufacturing Business

Luke’s talk was a great overview of the state of usability, touching on a wide variety of topics. In particular, he highlighted the tension between functionality and aesthetics from a number of different angles, pointing out that a functional but drab interface might score well for usability, but lack any emotional weight. Likewise, whilst it’s certainly possible to allow artistic impulses to run wild, the lack of usability input into interfaces can result in designs which look great but fail to deliver for users.

He explained how his own role at ThoughtWorks – a global company employing over 1100 people – has become ever more central as the importance of usability has moved up the agenda and gained acceptance amongst software developers, managers and clients alike. Often it’s hard to make a case for usability simply by talking or writing about it – customers can be dubious about what sounds like a costly exercise in something they don’t understand – but it’s often easy to get people on board once they begin to see the results. The modern approach of making extensive use of visual prototypes rather than written software specifications allows for much higher-quality feedback from the customer early in the development process, leading to better project execution in the long run.

Luke concluded by saying that he felt that there is a considerable benefit to combining modern usability techniques with ‘agile’ software development, a process which involves rapid prototyping and a willingness to change course to satisfy customer feedback. This is something that I’ve written about before, and it was great to encounter someone from such a successful company extolling the virtues of that approach. Events like last night’s are a great way to spread best practice amongst the software development and usability community and many of the attendees came away enthused by what they had heard.

Handling of credit card data is of paramount importance for trust and security, so it’s a good idea to check, as much as possible, that the user has entered the details correctly before submission. If the user does accidentally submit invalid data, this can lead to payments failing to go through, which is potentially worrying for the user and may also be an overhead for the retailer if they need to respond to any user support requests on the subject.

Fortunately, there are a number of checks that can be done to ensure that credit card data is valid, before submitting the data to the card issuer for payment processing. This can’t ensure that the user made no mistakes at all, but it can catch most errors before submission. Amongst the possible checks are:

• Number of digits
  An obvious check is to ensure that the number of digits is correct, for the given type of card.
• Card prefix
  The first few digits (normally the first two or four digits) of a credit card number depend on the type of the card (e.g. MasterCard, Visa, AmEx). It is possible to check that the prefix digits match the user’s selection of card type.
• Luhn algorithm check
  The Luhn Algorithm is a simple formula which can be used to check the validity of many different types of ID number, including credit card numbers. If there’s a mis-typed digit in the number, this check is likely to catch it.

When combined, these checks all act to ensure that any errors in the input of a credit card number are detected before submission, giving the user an opportunity to double-check and correct their input before submission. What we have implemented is a simple system which gives visual feedback to the user, showing a green tick symbol when they have inputted a valid credit card number which conforms to all of the rules mentioned above. Here’s how it looks on one of our clients’ sites:

When the user begins entering their payment card number, no feedback is given until a certain number of digits have been entered:

If the user enters an invalid number, they get this immediate feedback:

And if the number entered is valid, the user is encouraged by this feedback:

For more information, Wikipedia provides a good run-down of the various credit card numbers and their rules here.

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 is a hugely exciting event which should be a great day for PHP developers to listen, learn and discuss many interesting topics with each other. After the success of the initial social gathering, it’s great to see the final announcement.

There’s currently a call for papers underway, giving potential authors a month to submit their presentation abstracts. I see from Twitter that Jonathan Wage (lead developer of the Doctrine ORM library, which we have used here at PRWD) has put in a proposal and I’d certainly look forward to hearing what he has to say, with the launch of Doctrine 1.0 set to happen shortly before the conference.

Needless to say, I’ll be attending and I hope that as many others do so too. I expect that PHPNW will become a regular and important fixture in the development conference calendar.

Further Information

The conference website is here, PHPNW Google Group is here, and an Upcoming.org event for the conference is here.