Chapter 2. Introduction to the Case Study

Throughout this book, we will build a semi-realistic application that will demonstrate various Plone technologies and concepts. The source code for this application can be found on the book's accompanying website. We will explain the various packages and modules over the next several chapters, but if you are the type of reader, who likes to start at the end, feel free to browse through the code now.

In this chapter, we will:

• Put the example application in the context of a case study
• Show our fictitious client's requirements
• Perform some high level modeling of what the application may look like in Plone.

Background and high-level requirements

Optilux Cinema Group is a mid-sized chain of cinemas. They currently have a limited web presence, but wish to expand it to offer moviegoers a better way to find out about the latest films and reserve tickets for screenings.

The following high-level requirements have been presented to potential vendors of the cinema's web content management system:

	Requirement	Importance	Chapter
1	The site should have a look and feel consistent with Optilux's corporate branding.	High	5 and 8
2	The site should show information about all of Optilux's cinemas.	High	10
3	Non-technical cinema staff should be able to update information about each cinema.	High	6 and 10
4	The site should allow staff to highlight promotions and special events. These may apply to one or more cinemas.	High	10
5	Cinema staff should be able to publish information about new films. It should be possible to update this information after publication.	High	6 and 10
6	Customers should be able to find out in which cinemas a particular film is showing, and which films are showing at a particular cinema. Note that the scheduling of films at cinemas is managed in an existing relational database.	High	12
7	Only films that are currently showing or will be shown in the near future should be viewable.	High	10
8	Customers should be able to search and browse films by cinema, location, and date/time or film name.	High	10 and 12
9	Customers should be able to reserve tickets online. Tickets will be picked up and payment taken at the cinema. Reservations must use Optilux's existing relational database-based ticketing system.	Medium	12
10	Any digital assets, such as images or other files, used on the website must be traceable using a special Digital Asset Management Code, which will be used to link the assets to a third party system.	Medium	10 and 11
11	Customers should not have to log in to use the site, but a username and password should be required when they wish to reserve tickets.	Medium	12 and 13
12	Logged-in customers should have easy access to their preferred cinema or cinemas, such as those in their area.	Medium	13 and 14
13	Customers should be able to log in using their Facebook account.	Medium	13
14	Customers should be able to email enquiries to the site manager if they have questions or feedback.	Low	11
15	Customers should be able to discuss and rate movies.	Low	14

As we become more experienced with Plone development, these requirements will start to ring a few bells. For example, we may identify content types by finding the nouns in the requirement descriptions (for example: #2, #3, #4, and #5), such as Cinema and Film. We may be able to satisfy a few requirements by using Plone's standard content types or simple extensions thereof – a Promotion (#4) could be an extension of an Event or News Item.

It is also likely that the various content types will require custom workflows and security (#5, and #7). We can identify user roles like Customer, Staff, and Management from the subjects in the various requirement descriptions and start to understand what permissions these roles may have.

For reservations and reporting, we will need some relational database connectivity (#9). This in turn will probably mean developing custom forms and templates which access the information in the database.

As the system requires management of member (user), data, and preferences (#11, and #12) we may need to add additional user properties. To support an external authentication mechanism such as the Facebook Graph API (#13) we need to write a custom plugin for the Zope Pluggable Authentication Service (PAS).

Lastly, we must provide client-specific branding (#1). Plone provides user-friendly administrative pages and content management operations. We may also want to use the jQuery JavaScript framework to add dynamic user interface elements.

Modeling and mockups

We may, perhaps in conjunction with the client, decide to do some initial modeling of how the system should look. Some developers advocate very detailed modeling and strict adherence to relevant standards such as UML, the Unified Modeling Language. This depends on personal preference. In the author's opinion, the models themselves are not as important as the act of modeling—thinking through the client's requirements in terms of high-level components and interfaces.

Models can help structure a conversation with the client. Walking through a model and showing screen mockups or wireframes brings an abstract idea of an application to life.

For the purpose of this application, we will start by drawing a UML Use Case Diagram, which highlights the main types of users of the system and the types of things they may want to do with it:

This diagram is by no means exhaustive, but it does give a quick visual representation of the kind of interaction the application will need to support.

From this, we can identify major system components, represented in a high-level class diagram. This also shows where external interfaces will be needed, in this case to the relational database holding film reservations.

Again, this diagram is far from exhaustive, but it shows that we need to manage Cinema and Film, which is related by Screening. Customer and Staff are different types of site users, and Customer can make Reservation for particular Screening. Customer can also create Rating for a particular Film. In the content collaboration system, Staff can be members of various Projects, which contain documents that staff are working on.

We will also typically work with visual design mockups, drawn in a graphics program and/or provided as 'flat' HTML pages, to indicate how the site will look and feel:

In Chapter 8, Creating a Custom Theme, we will see how this mockup forms the basis of a custom site theme.

Information architecture

The design and requirements have implications for the site's information architecture. In Plone, content authors add folders, pages, and other content items to build site structure. This structure is automatically reflected in Plone's navigational aids—the top level tabs, breadcrumbs, navigation tree, and site map, that is, in the website's URLs.

Tip

A logical site structure is an important step towards making a website user-friendly and easy to navigate, and can help improve search engine rankings.

Looking at the design mockup, the links across the top and in the left hand side navigation will most likely expose the main functionality of the site. Different options may appear for logged-in customers, cinema staff or managers, as appropriate. Note that the labels in the mockup are suggestions from the graphic designer. The actual information architecture may be different and may change over time, depending on how the site administrator wishes to set it all up.

The following table outlines initial information architecture for the site:

Section	Purpose	Content types	Visibility
Home	Front page, contains general information	Folder, Page	All
About Optilux	General information about Optilux Cinemas	Folder, Page	All
About membership	Information about membership benefits	Folder, Page	All
Films	Container for films, including film listing	Film Folder	All
First film	Information about a film currently showing	Film	All
Unpublished film	A film not yet visible to the public	Film	Staff
Cinemas	Container for cinemas, including listings	Cinema Folder	All
Region one	Container for cinemas in one region	Cinema Folder	All
Promotion	A promotion specific to Region one	Promotion	All
Cinema one	A cinema in Region one	Cinema	All
Screening times	Listing of screening times for films	Screening	All
Reserve	Form to reserve tickets for a screening	Reservation	Member
Cinema two	Another cinema in Region one	Cinema	All
Promotion	A promotion specific to Cinema two	Promotion	All
Future promotion	A promotion not yet visible	Promotion	Staff
Region two	Container for cinemas in another region	Cinema Folder	All
Corporate information	General corporate information	Folder, Page	All
Project one	A project, visible to all staff	Folder	Staff
Project two	Another project, private to one group	Folder	Some staff

This structure should translate reasonably to a site map of the content hierarchy. Typically, a folder may represent a section or subsection, and contain pages or other content items as necessary. Most folders will have a 'front page' set as its default view, using Plone's Display menu, rather than use the standard folder listing view.

This pattern is also used for custom content types. For example, we will create a Cinema Folder type to contain Cinemas. The default view of the cinema folder will allow users to browse for cinemas. Custom types will be built in Chapter 10, Custom Content Types.

Note

It is often helpful to prototype the site's information architecture using standard content types (mainly Folders and Pages) with placeholder text, even if some items will eventually be built using custom types. This makes it easier to test the navigation and any customizations.

Running the project

Project management is outside the scope of this book, and every developer and organization will have different ways of managing their development projects. It is probably fair to say, however, that most Plone consultants prefer to work according to "agile" principles (See http://agilemanifesto.org), which typically include rapid prototyping, short development iterations and a high degree of customer interaction throughout the design and development process.

Indeed, Python is often branded an 'agile' programming language, because it is quick to write, easy to read and lends itself well to code refactoring. Furthermore, since Plone gives you a fully featured system out-of-the-box, you will be able to have something tangible and usable up and running almost instantly, which you can incrementally refine with input from the client.

Many developers keep a live test server for the client to test, periodically deploying code updates to showcase new functionality. If you go down this route, you will probably want to set up an issue tracker for the client to report any problems they find. There are many options here. Trac (http://trac.edgewall.org) is a popular Python-based test server.

Getting a draft of the customer's desired branding up for testing quickly can be very valuable, as users often have trouble making the conceptual leap from vanilla Plone to their own requirements. Even just putting a logo and color scheme into a site otherwise using the standard Plone theme can give the client a greater sense of ownership and generate some excitement. It is normally advisable to turn off unneeded core Plone functionality sooner rather than later, to avoid initial confusion. Also remember that in general, you cannot assume that delivering something Plone does out of the box will involve zero effort. At the very least, you will have to test the functionality within the overall context of your application.

As you work with your client, you will get a better idea about what is important to them. Giving them what they want most first, getting them involved in testing early, and being receptive to changes in the specification is usually a very good idea.

Because of this, many Plone consultants prefer to work on a time-and-expenses basis and promise frequent code releases, allowing the project to grow with the client's understanding of their needs. This is not so different from how Plone itself grows as people discover new things they would like it to do. By following good development and project management practices and effectively leveraging Plone's base functionality, you can ensure that at any given point the client has a fully functional (but partially complete) application at their disposal for testing and experimentation.

Summary

In this chapter, we have been introduced to:

• A semi-realistic case study that will be used throughout this book
• High level requirements for the example application following this case study
• Some initial models that point the way to how the application will look and work
• Initial thoughts on the site's information architecture
• A few tips for running Plone development projects

In the next chapter, we will learn how to set up our development environment, before we start building the application for real.