Introduction
Today, Web sites are a critical part of business, and the tools to create and deploy Web sites are becoming more flexible and easier to use. However, the production of complicated Web applications that require more than the standard methods of interaction (such as blogs) is not trivial. Often, each application within an organization can require customization.
In this series we use a fictitious organization, International Business Council (IBC), to show you how to more effectively maximize your Web site capabilities. IBC connects its employees with external business partners in a collaborative community; however, the existing Web site is not meeting their current business needs, and the site must be redesigned. The new, customized Web site must have document storage, discussion groups, specialized workgroups, conference scheduling, schedule session descriptions, session expiration, and other tasks.
The users' role is to enhance the offerings of the company by improving strategic and tactical decisions. The user community is organized around core issues of workgroups. The community meets face-to-face several times a year in a conference setting. At the conference, issues are identified and then resolved between meetings. The Web site is used to provide information about the community's activities, such as conferences, and as a way to track progress about issues raised at the meetings.
The existing Web site is based on a document repository that provides a way to exchange documents and update the members about upcoming events. However, the Web site is inadequate for promoting community interaction, especially in the context of Web 2.0 sites with enhanced capabilities such as Weblogs, discussion groups, RSS feeds, and so on. The team's goal is to encourage the community's interaction and provide a publishing framework to support the community activities.
Issues
Since this is going to be a secure Web site, we need session management to support expiration and acknowledgement of a terms and conditions document before access can be granted. We also want to support a direct manipulation approach to content editing -- if there is an action to take on a piece of content, we want that interaction control to be placed next to the content it affects.
Other issues with the existing Web site are based on inconsistent visual language, navigation, and information architecture. Content is often hidden within the documents that are placed in the repository; there is no indication of what is in the document until you download and view it. As a result of our analysis, the team decided that the model of a document repository was the wrong model to enforce. We want a content management system to do much more than that.
Design process
Our design process was iterative, starting from analysis, to prototyping, to evaluation. We involved the end users as early as possible with questionnaires, design alternatives, and prototypes of varying fidelity. We wanted to focus our decisions on both the business goals and the end user's needs. Before launching into a set of functional requirements or development, we found that the earlier we involved the user, the quicker we could understand what was useful and what decisions were good ones. Without a whole lot of effort we gathered some very valuable feedback, while making the user feel they were part of the design process. We also gained a lot of credibility with the user community.
Another component to understanding the design is to understand the information architecture. For example, through the user research, we learned that one of the most important requirements is access to three major areas:
* Information about working groups
* Information about past and upcoming conferences
* Access to information about all members
It was also clear from the user feedback that a clean, uncluttered, and simple architecture was required.
Our analysis identified three classes of users (or personas) who come to the site: customers, workgroup leaders, and administrators. These personas formed our design and decision-making process. By learning what information is important and how it relates to the major personas, we were able to create a content architecture, its hierarchy, how it might be presented, and how each class of user might interact with that information. For example, conference information might include agenda or session items, the scheduling of those items, topics of interest that spanned conferences, and action items that were resolved between conferences.
As analysis proceeded, additional features started to emerge. For example, to support an active community we wanted to enable discussions and comments on the content, and support contextual feedback and online collaboration. Another important client requirement that emerged was the use of a unique, yet neutral, brand or visual identity. Because the Web site presents a neutral ground where users from different backgrounds come to collaborate, a strong visual connection to any one company or background could cause unnecessary distraction.
Development environment
To ease our own development process, we wanted to use an existing content management system to help generate a timely solution. Most content management systems could support the basic functions we needed, but there was an obvious need for detailed customization. An out-of-the-box implementation was not going to be sufficient. We wanted to base our development on the significant body of work that has been done in the open source community. The tools we eventually used are from that tradition.
We had several goals for our development environment, such as being able to write and test our code changes independently of the network. When the changes were sufficiently tested, we wanted to share that code with the development team. This iterative development cycle lead us to use the remote versioning system CVS, which let us synchronize with our team members and maintain a code base we could all share.
We chose Eclipse to support the project and use all the technologies in an integrated development environment (IDE). Eclipse provides a number of extensions and makes the integration with Concurrent Versions System (CVS) very straightforward. Eclipse perspectives provide several views and editors that support the current activity. In our case, that activity was editing PHP modules and HTML fragments. Eclipse also tracks local changes to your code. So even if you don't check in the files to CVS, you can still recover earlier versions of a file from your local machine. This feature of Eclipse helps ensure that you never lose code again. We created a centralized development and test environment so we could optimize working with the code and other members of the team -- your time should be spent writing and testing code, not managing the files and other resources on your system.
The selection for our content management system had implications for the other tools we'd need to use. In the case of Drupal, this meant PHP, HTML, and Cascading Style Sheets (CSS) for the development of pages and MySQL for the back-end storage.
Requirements
We generated a set of requirements that helped guide us in selecting a content management system. If these features did not exist, we wanted the system to be easily extended to include these functions. The requirements include:
* Separation of content from presentation
* In-place commenting on content
* In-place editing of content
* Threaded discussion groups
* Control of access privileges
* Searching of content
* Authentication before seeing any content
* Session control, including expiration and the signature of legal terms and conditions
* Support community interaction through discussions
* Simple learning curve of the content management system
* Simple administration interface of the content management system to hand off to the client
