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.

It’s confirmed, the North West’s first PHP conference is to be held at Manchester Central on the 22nd of November!

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.

Following my earlier posts on Zend Framework and Symfony, the final part of my comparison will be an evaluation of Kohana.

Kohana is the newest of the three frameworks, appearing in May 2007 (albeit under a different name). However, Kohana began life as a fork of the CodeIgniter framework. The Kohana developers wanted to take the framework in a new direction, adding support for PHP 5 amongst other things. Now, over a year later, relatively little of the original CI code remains in Kohana.

Features

Having already written two posts about the feature-sets of MVC frameworks, I find that there’s not a lot new to say. The usual features are in place: Kohana provides a default front controller which dispatches requests to methods of a controller class, located via routing rules. Unlike Symfony’s YAML approach or Zend Framework’s .ini files, Kohana’s configuration files are all PHP-based, which adds some flexibility.

One particularly nice feature of Kohana’s configuration system is the ‘overriding’ of system-level defaults by application-level replacements. The Kohana file-system is structured as follows:

<root>
  application/
    config/
    controllers/
    models/
    views/
    ....
  modules/
  system/
    config/
    controllers/
    models/
    views/
    ....

I’ve skipped out some directories from this file structure – the important point is that the structure of the ’system’ tree – which contains the core Kohana files – matches that of the ‘application’ tree. This provides a useful concept for thinking about your application: it’s all about extending Kohana to do what you want. A parallel can be drawn with Drupal’s module system, where modules in the ’sites/*/modules’ directory override those in the ‘modules’ directory, and so on. In many respects, this doesn’t offer any particular advantage over any other approach, but I found that it helped my conceptual thinking.

This ‘override’ approach applies to all files in the application tree, from config files to controllers and views. The system config files provide sensible defaults, but if you want to change them it’s easy. Just copy the config file from the system directory to the app directory and start editing. That the config files are in PHP is especially refreshing – no .ini files, no YAML and (praise be!) no XML! Although some might argue that this detracts from readability, I disagree: not having to do a mental context-switch to go from reading YAML to reading PHP saves a lot of time and reduces the likelihood of error.

Taking the ‘override’ approach even further is the concept of ‘hooks’ and ‘events’. These will be familiar to many developers coming from other backgrounds; essentially, Kohana allows you to perform actions when events occur within the system. The core system provides some basic events (’startup’, ‘load controller’ and so forth) which can be handled by your own code. There’s nothing particularly revolutionary about this, but Kohana makes it easy to, for example, perform an action each time a page is displayed simply by writing a function and registering it as an event handler. No object-oriented inheritance voodoo, just a simple system that works.

Documentation

Kohana’s core code is readable, generally well-commented and using a good coding style. And it’s a good thing too, because any Kohana developer will probably find themselves referring back to the source code quite often, owing to the relative lack of documentation. There’s a valiant effort at creating some Kohana tutorials underway, but there’s a long way to go before Kohana’s docs can compare to Symfony’s. From a developer’s perspective, this makes using Kohana fun; it’s obvious that the developers haven’t made any particularly stupid blunders in designing the software and have succeeded in producing a very nice, elegant codebase. But there can be frustratingly few good examples of its use around, and the ‘community, not company-driven’ ethos can leave Kohana’s documentation and support materials looking a little unpolished compared to others.

Community

Kohana’s community looks strong and enthusiastic, driven by a genuine desire on the part of the participants to build a genuinely good framework. It’s hard to explain this in detail, but it’s possible to sense the desire of the developers to create something that is, in its own way, a work of code-as-art. The Kohana community is, of course, only a little over a year old. There isn’t yet a major book on Kohana and there are relatively few blogs about it. But there’s enough action at the core to suggest that Kohana can be sustained for the long term.

Conclusion

Kohana has much to recommend it. It’s evidently well-coded, with plenty of intelligent ideas behind its design, and a vibrant community. But, on the down-side, the documentation is severely lacking and many of the ‘jump-start’ features of other frameworks – say, basic CRUD code generation – aren’t present. This adds a little steepness to the learning curve, although I have to admit that I really enjoyed getting my hands dirty with Kohana. One regret is that there seems to be no central repository for Kohana modules (equivalent of plugins in Symfony). Being able to grab some ready-made modules to solve common problems would be nice.

My overall sense of that Kohana is that it probably will be the best PHP framework at some point in the future. It’s clear that what the Kohana community is building is something big and ambitious that might, one day, be the best way of rapidly developing PHP applications. But the shortcomings can’t be ignored: lack of documentation and lack of modules mean that there are other frameworks that can get the same job done faster. If you’re embarking on a long-term project and are not scared of using the code and comments as your primary documentation, Kohana is a great choice.

I’ve been meaning to blog about this sooner, but there’s no time like the present. Recently the first meeting of the PHPNW (PHP North-West) user group was held, at the 235 Casino in Manchester.

For a first meetup, the attendance was excellent – over 30 people from the local PHP and web development scene. There were some familiar faces, from GeekUp and other similar groups, but also plenty of new people who I had never met before. The conversations were interesting and we were all helped along by a free round of drinks and, later, free pizza courtesy of Jenny Dunphy and her employers (thanks Jenny!).

There was a great buzz and lots of energy around the group, in large part due to the excitement at the upcoming PHPNW08 conference. Final dates and venue details are to be confirmed (soon!), but there is a huge potential for a ground-breaking conference right here in the North West of England. The PHP development community has changed a lot in the last couple of years, becoming more professional in outlook and spreading into new and more interesting areas of development. The fact that there have been many interesting PHP conferences around the world proves this, and it’s about time that the vibrant NW web development sector put on its own show.

The main driver behind the idea of such a conference is Jeremy Coates, and he deserves huge credit for getting people together behind this idea and making it all happen. There’s still a long way to go, but he has certainly managed to pull a lot of talented people into the operation, giving it every chance of success.

From my point of view, I’m greatly looking forward to more opportunities to network with other people in the PHP and web development industry locally, and the chance to listen and speak to some of the leading figures in our industry at the conference. Adoption of PHP and similar technologies to tackle big IT and web projects is increasing all the time, and conferences like this are essential for promoting the practices and ideas that are needed to make this work, as well as the social network of companies, developers, entrepreneurs and managers whose collaborations are vital to the future of new business in the North West.

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.