Modifications to the base_properties will have rippling effects within the Plone style sheet, which, in turn , will have an effect on the Plone templates, resulting in a change that is visible to the user . This can be a good thing, if the modification was planned for, or it can be a horrible misstep if you did not mean to change all of your body text to the color pink (for example). However, if you inadvertently change your body text to pink, you can use the Undo feature to roll back the base_properties to its previous form.
As noted earlier in this chapter, implementing a custom skin is a project that begins with a design team. If you are a site administrator for a corporation, an educational institution, or even a secret society of some sort , chances are good that there are design guidelines, logo usage rules, and so forth that must be followed. If you're just Joe User with your own Plone site, you have more freedom, but that doesn't mean you should do less planning.
The design process includes several factors, many of which have little to do with Plone but have everything to do with the message you are trying to send to your users. However, if you expect to be able to implement any of your plans within the Plone infrastructure, it is highly recommended that you traverse the planning process, to ensure that fewer (if any) items fall through the cracks.
Define Your Goals
Even if your site is only for you and a few friends , you should have some goals. If you are developing a site that is corporate, commercial, educational, or any combination thereof, you should seriously plan out your goals because your responses will determine where and how content is placed within the site, from hierarchy to aesthetic display. For example, if your goal is to provide information about an educational department, you won't be leaving a space in your design for the presence of a shopping cart and checkout button, as you would if you were designing a retail site. Your overall goals will have lasting effects on the design and architecture of your site, and those are not elements that you want to change often ”it's best to get it right the first time and make only minor adjustments down the line.
Developing the Overall Site Architecture
Despite its name , you shouldn't actually build anything during the architecture phase. Instead, you should be thinking about the content that will be going into your site and how to organize it in a manner that makes sense to the user. For example, a very flat structure would have numerous sections with very little information in each one, while a tall structure would have only a few sections but a great depth of content. Usually, the "right" place is somewhere in the middle ”four to six sections, with a similar number of subsections. Because sections will map to tabs in a Plone site, you can see where this decision is an important one.
Determining the content architecture is usually the most difficult step in the design process for a corporation or information-based institution; retail sites tend to have a ready-made site architecture, in that the sections of their online store tend to mimic the departments of a brick-and-mortar store. You can apply the same idea to a corporation if you're designing an intranet site because the sections could be the internal departments: Legal, Human Resources, Sales and Marketing, and so forth. But if you're creating an external corporate website, your decisions get a lot more difficult.
For example, you first have to determine whether you're going to allow your users to choose their own path through your content or whether you are going to select it for them. You might have visited websites that ask "What type of user are you?" and then send you into a specific architecture if you answer with Individual User or Enterprise User. Although this does allow the company to subdivide its content and target it for the selected user type, it has its drawbacks: How do you ensure that you've presented the proper content? Is the information you want to present really mutually exclusive ”that is, can you be sure that no individual user will ever want to read some bit of content you've chosen to place in the section for enterprise users?
Deciding not to target your content per user type also has its drawbacks because companies tend to create very broad sections for their content, often with ambiguous names . For example, what does the Press section of a corporate website really contain? Is it information for the press, or information by the press? In the ubiquitous Company section, what really belongs there? Information for investors, one might argue, but wouldn't that warrant its own section full of financial press releases, filings, executive team information, and so forth? Another frequent categorization issue is the debate between Products and Services. How do you present information for products ”things you can buy in a box ”and services ”things you can buy but that don't come in a box? Fundamentally, they're both offerings from a company, usually in exchange for money. But just because you can make a differentiation between the two internally doesn't mean that the end user knows where to look. If your goal is to show the end user the items you offer in exchange for money, you want to make that as easy as possible; you don't want the user to have to determine whether it's a product or a service before selecting a section to visit because if the user selects the wrong one and doesn't see the item he thinks he wants, it's quite possible that he'll miss out on the sale.
Obviously, one could write an entire book on the thought processes that go into creating a site architecture, but the point is this: It's a crucial step and should not be taken lightly. All subsequent design decisions hinge on the architecture decided upon in this step. After the architecture has been mapped out, you can move on to the next step, which is determining the overall navigational presentation.
For more information on the concepts of site and content architecture, some helpful books include Information Architecture: Blueprints for the Web , by Christina Wodtke (Pearson Education, 2002), and Practical Information Architecture , by Eric L. Reiss (Pearson Education, 2000).
Determine Your Navigational Elements
Using a Plone site, this step is handled for you: Tabs represent sections, and the Navigation slot can be used to display the individual pages within a section. Because Plone is template driven and fundamentally well designed, you don't have to spend time worrying about your navigational elements being consistent or your users getting lost in your site. Unless you decide to turn off tabs, the Navigation slot, and the breadcrumb trail, your users will always know where they are and how to get to where they're going. Your biggest concern during this phase of the development process is determining how closely you want to stick to the default Plone style. This leads us to the next step, developing the overall look and feel, or theme, of your site.
Developing the Look and Feel
If you've made it this far, you probably have a content architecture in mind, corporate guidelines in hand, and a design team in tow. Now is when the fun begins: You'll select a color scheme and start mocking up graphical representations of pages. It is crucial that everyone on the design team understand the basics of Plone templates, not because you can't completely customize a Plone site (you can), but because some decisions will require far more customization than others.
For instance, suppose that your design team comes to you with a mockup that includes extremely stylized , curvy tabs to delineate your sections. Although you can certainly implement such a feature using partially transparent table cell background images, the design team should understand the trade-off: Any page laden with graphics will take longer to load than a page that is not. Similarly, suppose that the design team wants the top-level heading of all body content to be in some obscure font that users are unlikely to have on their system. Because users are unlikely to have the font, team members have determined that they want to use a graphical title for all content pages. Again, although this can be easily done, the process might outweigh the potential rewards. Instead of all H1 headings being 160 percent of the base font used throughout the site, which requires no additional work from the content administrator, now all H1 headings will be replaced with graphics, which must be created and then added into your Plone site so that you can link to it within the page body. Add to that the additional 3K of page weight, and you really have to ask yourself whether that special font is really worth the hassle.
The development of the look and feel should not be a contentious experience, but it should be a series of compromises that results in a set of web guidelines and assets for use throughout the site. Because one of the primary reasons for using Plone is to maintain content separately from design and to provide a consistent user experience, the last thing you want to do is nullify those positive aspects by selecting a design that simply doesn't work within a structured templatized environment.
Fitting the Pieces Together
After you and your design team have determined the overall look and feel, you can begin the process of customizing the base_properties and making any changes to the Plone style sheet that you feel are appropriate. As you've learned in this chapter, making modifications to the base_properties goes a long way toward customizing your Plone site because modifications to these properties have cascading effects throughout the style sheet. For example, if you and your design team have settled on a primary font family to use, you can see an immediate change throughout your site just by modifying the fontFamily property.
If you find that you need to fundamentally change the definitions of elements in the style sheet, do so via the ploneCustom.css file rather than the default plone.css master file. Any customizations made in ploneCustom.css override like-named items in plone.css ; if you need to revert back to the original, you can simply remove your entry instead of trying to remember how the entry looked in the master file. If you want to add definitions of your own, you can also do this in the ploneCustom.css file; Plone templates look for this file first and then the standard plone.css to determine how pages should be rendered.
When you've worked out the basics of properties and styles, you can begin to collect custom assets ”graphical headers, icons, and so forth ”to replace the files that the standard objects reference. For example, if you change all of your supplemental images to red-tinged graphics to match your logo or corporate colors, you simply have to go into the plone_images area of the portal_skins section of your Plone instance with the ZMI and create custom versions of the referenced objects. As you learned in Chapter 5, you can attach a file of any name to an object called arrowBottom.gif (for example). While arrowBottom.gif is the ID used in Plone templates, it could display myRedArrowBottom.gif , if that's what you've uploaded as your custom asset. Continue the process for all custom images you want to use, and you will soon see your theme emerging.
The final step in a basic Plone customization is to move around or disable slots and other Plone-specific structures. In the next section, you'll see an example of an actual Plone- powered site that contains numerous customizations but retains enough of its inherent Ploneness that you can see how and where the derivations occur.
Plone Customization Example
Plone customizations abound; you saw a few of them in Chapter 1, "Introduction to Plone and Content Management." An entire page at the Plone website (http://plone.org/about/sites/) is full of links to such sites. Some site designers have chosen to use the standard Plone template, not even changing the color scheme, while others have replaced almost all traces of standard elements with structures of their own. But the website for the current governor of Texas provides an example of a customization that embraces the fundamental structural and usability aspects of Plone, while applying its own look and feel to the elements. In other words, the design team for the Perry site has skinned the Plone installation.
Figures 6.5 and 6.6 are used to illustrate some skinned portions of the Perry site. To see the full-color site, visit http://www.governor.state.tx.us/.
Figure 6.5. Main page of Gov. Rick Perry's Plone-based website.
Figure 6.6. Subpage within Gov. Rick Perry's Plone-based website.
Figure 6.5 shows the majority of the Perry home page.
At first glance, this site looks nothing like your out-of-the-box Plone installation because there are significantly more color fields and graphics used. But if you ignore the color and instead look at the structural elements within the template, the similarities become quite visible:
The logo in the upper left of the page.
The search box in the upper right of the page.
The tools strip underneath the logo but above the body of the page. Although it does not include the Log In or Email links, it does include the Print link, and this area is used for the breadcrumb trail on subsequent pages.
Sections are delineated using tabs.
The left column contains slots, including the standard Plone calendar.
Even the standard Plone items, such as the slots and tabs, have custom colors. You learned previously in this chapter that the globalBackgroundColor property is used to fill tabs; in this case, the value has been set to #CBCFE0 .
You can see instances in which other properties have been modified, such as fontFamily , fontColor , and linkColor . Continuing on to a subpage, even more customized Plone items are visible, as shown in Figure 6.6.
In Figure 6.6, you can clearly see the Navigation slot. This slot holds the secondary and tertiary navigation; the selected section is Divisions, and the secondary page selected was Women's Commission. In the Navigation slot, this secondary page is shown with all its attached tertiary files beneath it. If the selected secondary page had been Human Resources, its tertiary files would have been shown as links. The items in the Navigation slot are representative of the content hierarchy, as stored within the Plone database. The standard Plone breadcrumb trail is also seen in the color field under the heading. Utilizing this design, users can see where they are and also can access the navigational routes to other information, both above it and below it in the hierarchy.
Although it is common for templatized websites to all look the same, the Perry site and those on display at http://plone.org/about/sites/ show that customization is indeed possible. By studying Plone properties and the style sheets, and by carefully planning the elements of your design, you, too, can create skin for your site that will set it apart from all others.