For the past about six months, I am working on the eZ Publish CMS of the eZ System. I feel it has some unusual characteristic compare to other CMS: joomla, drupal, XOOPS to name a few. From the projects I built and am building, I have outlined some points which a Project Manager may need to get clear before push the work to developers (If only this would be true, my life would be so much easier ).
Every Object is an instance of a class, and every Object can has different looks on different pages on the website. For example, an “an interesting story” article object of the Article class can display on the Home page, Listinig Page and its own Detailed Page. On each of these pages, the same article may have different looks: On home page, it just show its title, publish date and short description; On Listing page, it may just show Title, Author information, short description and a listing logo; On Its detailed page, it shows Title, Publish date, Full Description. These different “looks” in eZ Publish, Called different “Views”.
Class Definition Information
EZ Publish Data Types
The complete list at http://ez.no/doc/ez_publish/technical_manual/4_0/reference/datatypes. Here I just clarify the concepts of some common ones:
.Date & Date and time & Time: the main difference between them is slightly edit interface change. If an attribute only requires Date info, then should just use the Date Datatype. The edit interface is the similar, the value created are unix timespan in the system.
.File, this will stores any binary file. Must know that every file uploaded will stored in the storage directory under the /var, and the file name will be encrypted; also, by default, normal use can’t access the /var directory through urls directly.
.Image Get a notice that the image file is used with this datatype, and the system will convert all the versions of the same images according the configuration file image.ini. So, the image can be multiple versions of the same file, and can be resized automacitally. For example, if an object will be listed on the listing page (list view), and it also has a detail full page (full view), and on both page, an image is displayed. If the image is the same, just has the different size requirements, then, no need define two attributes, just one attribute is enough.
.Media The content in this kind attribute can store Flass/QT/Real/WindowsMedia. By default, the system will load the standard template for this attribute, which will take care of set up the correct browser plugin to view the media file. But, it uses the <object> tag, and whether the file will play, depends on the supported file extentions (MIME TYPE). Except Windwos Media, other media type may not supported very well.
.Price & Multi-Price Any object of a class which has these kind of attribute will automatically treated as “Product” in the system.
.Selction. This Datatype will generated a dropdown. It can be single choice or mulit-choice. Notice however, the options text is not supported translation (multi-language).
Text line: When you need only “one line of pure text”, you need this datatype. E.g., the Title of something.
Text block: It just support multi line pure text. No text formatting!
XML block: This is most important and most confusing datatype maybe. It supports multi-line, formatted text. When on edit interface (in backend, for example), the eZ Online Editor will loaded for this kind attribute. The latest stable Online Editor is somewhat limited, not WYSIWYG at all; the newest version, still on beta, is based on tinymce, is more modern (if we can used it on production?).
.URL It validates and stores url. One thing need notice that, by default, it provides two field, one for the anchor text, one for the actual uri. And the standard template will not take care if the uri value started with “http://” or “https://” or not.
What we need to know when define a class:
Container or Non-Container This means if the object of the class will contain “Sub items”. This is important because this directly related to the navigation system of the website. For example, if we have a “Category” class, then it probably will need contain “Sub items”; so it is a “Container”; on the other hand, if there is also a “Blog Post” class, then it probably will not be a container, it may always exits as a “leaf” in the structure tree.
.Which Attribute is Optional, and which is Required. This is important not only because it directly depends on the client requirement but also need be checked in the template code, and it effects the way of design integration also. For example, if an attribute is optional, then, we need write code to check if it contains some content or not first; also, if it is optional, in the case its content not exist, the web page probably will not show them, the design integration team need take into account with this situation I think!
.Information Collector Or not In this case, if we need create a form or something, we need specify which attribute will collect data input from the user. The Information Collector is an imported idea, these what the forms built upon in eZ Publish. If an attribute is specified as information collector, then there is no need to input content by the webmaster or editor whiling publish a content; also, “the required or not” property of the attribute will directly affects the form validation process.
.Naming the Classes Please trying to name each class. Name like “text 2 column plus agenda” for a class is just not legal! A class is a “blue print” of a “content type”, if you feel can’t name a class easily, then the problems are probably meant we get the “Content Type” wrong. When you say a “tree”, you will know what you are talking about; but when you say the “green top and brown bottom” thing, you are probably 3 year old and just starting to learn how to speak.
Content Management Information
.Before any visual information, i.g., those colors, images, column in the designs and templates. It is important to get the information how the “Content will be managed”. Which sections/folders/catetories the site will have? how the client like to sore each of the content? Are the categories or sections divided meaningfully?Are the client like “centralized approach” to manage the content, e.g., every news are stored in one folder (which many contatin sub folders)? Or the client like “de-centralized approach”, e.g., s/he just navigate to a specific “Container” and publish whatever object s/he wants? Which need be made navigatable in the dynamic tree menu under the content top node in backend ( this also involves “which will be naviagatable in the websites menu system “)?
Navigation System Information
I separated this “Navigation System Information” part out from others because I want especially emphasize on this topic. What “Navigation System” means is that it refers to all the items on the website (front end at least), fall in (but not necessary just these): horizontal main menu items and sub items; left column main menus items and sub menus items; footer links; header links; things will be shown on the site map page; the breadcrumb links.
First of course we need know which kinds of information should be on each of these items; second of course we need to keep the navigation system “consistent”.
If there is a need for a page show a Container (the category description) itself? How the Container will list its children (the sub items)? Is the “if there is only one article under this folder, go to this article directly” really meaningful (especially when the folder itself contain a description information already)?What kinds information a Contain will contain? Does it will contain only article (only article will be published under it); or does it contains more than one content type under it ( e.g. It contains News and Articles, News and Articles will be published under it)? How the whole menu will be organized? Do we need the breadcrumb(if it is needed, then every entry in the breadcrumb links should the same as it in the menu and site map)?
Is there a Member Area? What we could do in terms of the “section” concept in the eZ Publish? A setion in eZ Publish is a virtual space which can be used to divided the content in the web site into several sections. For example, in the case, there is a blog area which has main different page layout and look and feel, then we can assign the contain in the blog into a “blog” section; then the template override system and the user permission configuration will be much more easier. Of course, another aspect need consider is that will the content be move around? Or will it require some content have more than one location? If the different locations of the same node belongs to different sections which has dramatically different design or layout, we can’t simply wish the design will be ok if we only have one design for one section.
For Menus, It is better we divided the Content Type Class into “menu items” and “non menu items”. The “navigation items” means those thing will always shown on the menu, and thus on the site map; normally these will include those content type defined as “Container” (Folder, Sections, Categories); of course, sometimes, “seem non-menu items” need displayed on the menu also, such as some articles or news; but if there are too many these kind of “article”, we may need re-think about the content structure and content modeling.
Major Modules/Functionalities Information
Before we talk about design, we should also know which major functionalities will be required. Does the website require the webshop, e-commercial? Dose it require the front end editing? If so, do we mind the interface of the editing(edit templates)? Does it contains workflows? User groups and Roles Policies? Version management? Mulit-language? Urls?Which kind of search engine will be needed?…And so on.
General Design Intergartion Guide Line
Adequate information on the Content Types (class attributes) will help Design integration. For example, if knowing something is dynamic (is a xml block or text block or something entered in the backend), the design integration will not make mistake to create wrong xhtml mark up to divided a single attribute content into half; if knowing an attribute is optional, the design integration should take consideration in the case that the content will disappear if it is not entered by the user.
However, there are still some general design integration guile lines should provided to the team, for example: By default, which font family, font-size the web page should use? Font and size on the main navigation menu items? The rules for all the header tags, the h1, h2, h3 …tags should keep the same on the whole site. Which font, font-size, color should they use? Border style? Color theme: Can the website require some main colors? Does the website has a color theme? If a introduce section of an article should have a back ground color, same rule should apply to every article on the whole site (or the whole section)? Rules for all the ordered or un-ordered list? If there is a special kind of box, does this box should keep the same design wherever it appears?
We need print version of some page and need a “tell a friend” or “tell the admin” button, but if it is meaningful that a listing page also has the print button or a “tell a friend” button or “tell the admin” button?
If there is a need for a print version, we should provide a print layout design to design integration team! It shouldn’t be added at later. If there is requires for some Pop Up windows, it should also be provided with the design. In most case, a website should just need one print layout and one pop up form to take care every instance of them.