By: Martin Bauer

December 17th, 2004

Reader Rating: 8.5

In March 2002, we were asked by the Graduate Careers Council of Australia (GCCA) to investigate the redesign of the gradlink Website, and implement a content management system (CMS). This case study covers the rebuild of the gradlink Website using the eZ publish open source content management system.

The Site

The gradlink Website [1] is a resource designed primarily to help Australian graduates find jobs. It also assists employers in graduate recruitment and careers services find jobs for graduates, and help them during the recruitment process.

The site was first built in the mid-1990s with its own job vacancy system. This was later outsourced to Seek Campus. The rest of the site consisted of static HTML and underwent a number of redesigns. Prior to this project, the most recent redesign was in 1998.

Initially, all maintenance of the site was outsourced to Web development firms, while GCCA gradually developed enough in-house skills to manage the majority of the site internally. Unfortunately, over the four-year period since the last redesign and rebuild, the site had become much larger and hence more difficult to manage and maintain. It was time for an overhaul.

The Brief

Before it even considered designs or CMS packages, GCCA conducted a user survey to get an idea of who used gradlink, what they used it for, and what improvements users would like to have.

The results of the survey were eye-opening. The site had always been split into three main sections: one for students, one for employers and one for careers services. The survey showed that over 80% of visitors to gradlink were students, approximately 10% were careers services and only 2% were employers. The overwhelming reason for students coming to the site was to find a job -- a facility that GCCA had outsourced to Seek Campus.

There were three key outcomes that GCCA wanted from the rebuild of gradlink.

1. Give the site a modern, clean professional look.


2. Add a job search facility that integrated the Seek Campus job database and GCCA's own Graduate Opportunities (GO) employer directory [2].


3. Implement a CMS that would enable GCCA to maintain the site in-house.

Look and Feel

designIT mocked up many 'look and feel' designs in order to gain feedback from gradlink as to which resonated with its objectives for the organisation's representation online. As the site is the main front door and resource for the organisation, it had to represent the GCCA's intention and attitude, and be user-friendly to all 'markets'. While 80% of the users were found to be students, the funding for the organisation comes from institutions, so their needs were equally as important even though they comprised a minority user group.

Why not build from scratch?

We discussed building a custom solution from scratch with GCCA, but strongly recommended against it. Five years ago it would have been a serious consideration, but the marketplace for CMS solutions has matured significantly since then. The requirements for the new gradlink site fitted in with the standard offerings of CMS solutions. The idea of building from scratch offered almost no advantages and came with many disadvantages such as time, cost and maintenance challenges. The decision to go with an off-the-shelf solution was an easy one to make.

Defining the solution

In order to choose a CMS, we started with a requirements-gathering phase that was conducted over a series of long meetings of about 3-4 hours each.

This phase led to the production of a requirements document that stated what GCCA wanted in the new gradlink site. The next step was to translate those requirements into a functional specification. We did this by creating a site map and then produced wire frames for each main section of the site, defining each of the elements of the screen, along with any applicable business rules.

The requirements told us what the site was supposed to achieve. The functional specifications provided the blueprint of how we were going to do it.

Choosing the CMS

There were two key elements that we had to consider in choosing a CMS. The first and most important was budget: the more the CMS was going to cost, the less we'd have left over to spend on design and implementation.

The second element was its functionality. Ideally, we hoped to find an open source solution that had all the functionality we needed, but no associated licence fee. Of course, there is no such thing as a free lunch, and chances were that an open source solution would require more work to implement than would a commercial product. It was a matter of balancing the effort required to implement the solution against the benefits of an open source product with no licence fee.

Our first step in choosing a CMS was to distil the requirements and functional specification into a list of functions. We found there were 18 areas of functionality that the CMS had to provide. When searching online for potential solutions, we found that dozens of open source solutions were available.

In selecting the end solution, the first step was to see if the solution provided the full set of functionality. This eliminated many of the solutions we found, and we ended up with a shortlist of 10 possible options that we documented in an evaluation matrix. We then looked at each of the 10 shortlisted solutions more closely and analysed factors such as:

1. Was it actively maintained by the open source community?


2. How mature was the solution?


3. Had it evolved over several versions?


4. Had the solution been used for commercial sites?


5. Did good documentation and support exist?


6. Was it easy to understand and use?

This shortened the list to three possible solutions. We then obtained a copy of each solution and installed all three, to get a closer look at the underlying architecture and structure. This was also important in providing us an idea of how easy the solution was to use from the client's perspective, as GCCA would need to use the chosen solution to maintain the site. In the end, the solution that we felt was the best on all fronts was eZ publish, produced by eZ systems [3] in Norway.

Staged Approach

We had the full requirements and the functional specifications, and knew which CMS we were going to implement. After we revisited the fundamentals, it was obvious that the scope of the project, and hence the budget, were much larger than expected.

The problem was that all of the functionality was important and necessary, but could not be afforded initially. Thus, we prioritised the requirements to establish the minimum functionality required for the initial launch, and called this Stage 1. The rest of the functionality was prioritised into Stages 2 and 3, to be implemented later.

This prioritised approach was primarily driven by budget, but we also felt it was important to get the CMS up and running and have GCCA work with it for a while, after which we could review Stage 2 and 3 with the benefit gained from their knowledge and experience with the system.

Test Implementation

As we had not implemented eZ publish before, we knew there was going to be a steep learning curve on the first implementation. Rather than face that learning curve on the gradlink site, we decided to invest our own time and resources in doing a test implementation on our own site, so we could be sure that it was the right solution for GCCA.

What we discovered in implementing eZ publish on our own site was that the actual implementation was the easy part -- defining the structure and how it was to work was more difficult. Basically, we had to deconstruct our site into each element, then configure eZ publish to assemble the elements in order to produce the Website.

These elements we defined as:

1. Content types - the structure of the actual content within the site, each with its own attributes. For example, one content type was an article, which had a heading, author, date, body copy and image.


2. Templates - how the content was to be displayed. Templates addressed the look and feel: basically, the HTML and graphics that provided the structure for the page and defined how the content would look.


3. Rules - what content was to be displayed with which template into which sections of the site? For instance, staff profiles only appeared in the 'about' section of the site.

Which version?

At the point at which we performed the test implementation, the latest version (3.0) was supposed to have been released, but delays meant that only a release candidate (RC2) was available. This changed our plans significantly, as we had anticipated being able to use the new features provided by the new version in the GCCA site. We didn't want to implement an old version and then, within a matter of months, have to upgrade to a new version, as this would cost more in the long run.

We discussed this issue at length with GCCA and compared time lines for implementation with the previous version and the latest version. In the end, in line with our recommendation, GCCA decided to delay the deadline by 2 weeks to give us the extra time required to wait for the release of the latest version of the CMS software.

When the time came to start work on the real implementation, the final version of the software was still not ready, and we were forced to go forward with the latest release candidate. The final version was released during our real implementation, but by then it was too late to migrate to the final version. This caused two minor yet annoying issues. Firstly, we had to implement some work-arounds for bugs that would not be fixed until the final release.

Secondly, the WYSIWYG content editor was not available until the final release. This meant that GCCA would have to deal with manual content formatting using HTML tags.

Real Implementation

Having learnt much about eZ publish from our test implementation, we went about defining the content types, templates and rules for the gradlink site, which we compiled into an information architecture document.

It took us a number of iterations to get the information architecture to the point that we felt ready to start working on the site. The hardest part about defining the information architecture was being able to abstract the content from presentation, and understand how to construct the site from the combination of content types and templates. It was a difficult shift in mind set from simply constructing sites based on pages. For example, a piece of content entered once could appear in different places on the site in different ways. We had to capture all of these possibilities to ensure the site would work as expected. It was extremely important to get the information architecture right so that content management would be easy for GCCA, and so it would be presented in a meaningful way to the end user.

What took us approximately 10 months to define and plan from the user survey through to the information architecture took just under two months to actually implement.

Content Population

This was the real test of how well we had done on the information architecture.

Once GCCA started to enter content, we found that we had most of the system right, but there were some content types for which we hadn't catered, such as articles that spanned more than one page, and contact details. Also, we thought that the article content type would be flexible enough to handle event information, but when we saw it displayed on the site, we found that it didn't quite work: we needed to provide another content type just for events. There were other things, like page anchors, that we take for granted in static sites, but which are not easily accommodated in a CMS.

GCCA had prepared for the content population phase by taking all the content on the current site and saving it in Microsoft Word files in folders to reflect the new structure. Through this process, the staff discovered that it wasn't as easy as cutting and pasting from one site into the other. The client also found replication in the existing site and had to edit some content to make sure it fitted into the new site.

To get GCCA started, we conducted a training session on how eZ publish worked. The administration screens were very user-friendly and we found that it took only an hour or two for people to be comfortable enough to find their way around and enter content. The difficulty was not so much around entering content, but in understanding how that content would end up displayed on the Website, i.e. understanding the separation of content from presentation.

During the content population phase, we had a few issues to resolve but all in all, it went quite smoothly. The biggest issue was the amount of HTML formatting that had to be done to the content, and the other 'buggy' problems with the version of eZ publish that we'd used (release candidate 2). This version, as well as lacking the online WYSIWYG editor, had other minor bugs such as adding extra white space, which made previewing difficult without first publishing the article. This required review and re-editing in order to get the system to function correctly.

All these problems were solved when the code was upgraded to the final version of eZ 3 a few months later.

Job Search Integration

One of the requirements of the new site was to have it offer users a job search facility that used the Seek Campus and Graduate Opportunities data. We built this as a separate project and integrated it into eZ publish so that it was seamless from the user's perspective.

Initially, we integrated the job search directly into the eZ publish code. While this worked, it meant that updating eZ publish would require that the job search functionality was reintegrated with each upgrade.

eZ publish 3 included examples and documentation that detailed the creation of custom modules. Armed with this information, we created the job search functionality as a custom module. This meant that the functionality was independent of the core eZ publish distribution and made the upgrade process much simpler.

Support and Documentation

We purchased enterprise support from eZ publish to ensure we could have our questions answered within 24 hours. As eZ publish is built by Norway-based eZ systems, we couldn't rely on a local contact or the use of phone support. This made email support very important.

Largely, we were impressed with the quality and professionalism of the eZ publish support service. There were only two occasions on which the service did not live up to expectations. With both incidents, the support questions were answered within a reasonable time frame, but not within the advertised 24 hours. The first of these was due to the support staff being overloaded and when we queried the support levels we were credited with an hour of support time and assured that it would not happen again. The second incident was due to a Norwegian public holiday.

As a result of our support experiences, we contacted the eZ Systems management team to outline our concerns. We received a response stating that they were working on improving their support procedures so that they could better accommodate overseas clients.

What we did find frustrating, however, was the level of documentation surrounding the product. As we didn't have access to training courses, our learning and understanding of eZ publish relied heavily on experimentation, user forums, and reading the source code. When the documentation wasn't sufficient, we basically had to learn the hard way, by trying things out ourselves. This resulted in a fair amount of trial and error before we worked out the best way to implement things. Since then, we have seen improvements in the documentation and eZ systems has committed to improving the documentation further.

The End Result

The new gradlink site launched on March 21, 2003. The site has worked well and GCCA is now in full control of it. About a month after we went live, we conducted a project debrief with GCCA to find out collaboratively what went well and what could have been improved.

What went well?

• Delivered on time
• Looked great
• Received positive feedback from users, clients and stakeholders
• DesignIT and GCCA worked well as a team
• Good planning upfront
• User survey helped focus project
• Open communication on both sides led to giving and receiving advice
• High levels of trust on both sides
• Integration with Seek and GO was straightforward

What could have been improved?

• Closer review of content to see how it fitted into the CMS and content types defined
• Selection of a mature product (e.g. not a release candidate) to reduce the risk of delays and difficulty in usage

Five months later

About 2 months after the launch, we planned and worked on a much reduced Stage 2, which was mostly a cosmetic update, but more importantly, involved the final version (3.0) of eZ publish. This fixed some of the temporary solutions we implemented to launch on time and improved the performance of the site through better caching and template management. We are now planning the next stage to enhance functionality even more.

In Conclusion

Ultimately, the project was a great success.

Each stage of the project was valuable in shaping the next stage and in turn, the end result. The user survey helped shaped the requirements, which helped shape the functional specifications, and so on. There were definitely moments at which we felt that we were spending too much time documenting and not enough time building. But the speed, ease of implementation, and small number of changes that were required after the launch proved the effort spent upfront was well worth it; we'll continue to reap the benefits as we plan Stage 3.

As a product, eZ publish has proven to be a quality solution, and eZ systems a professional organisation to deal with. The product is well-supported and future releases will add valuable features.

Defining the information architecture is where the real challenge and real value lies in implementing a CMS.

[1] http://www.gradlink.edu.au
[2] http://www.graduateopportunities.com
[3] http://ez.no/