“He had brought a large map representing the sea, without the least vestige of land,
and the crew were all pleased when they found it to be, a map they could all understand.”
(Lewis Carroll, “The hunting of the Snark”)
OK, after playing around with all this proof-of-concept stuff, lets actually do some real design. What document types do I want, and how are they best organised?
Document Types for Events
I have three different types of event to deal with, each needing the following set of fields:
| Field | Type | Tab | Event | Course | Exhibition |
| Title | Textstring | About | x | x | x |
| Artist/Tutor | Textstring | About | x | x | x |
| Event Type | Dropdown | About | x | x | x |
| Suitability/Age(s) | Textstring | About | x | x | |
| Price | Textstring | About | x | x | x |
| Booking Details | Textstring | About | x | x | |
| Link(s) | Textstring | About | x | x | x |
| Headline | Textbox multiple | Content | x | x | x |
| Main Image | ? | Content | x | x | x |
| Content | Rich Text | Content | x | x | x |
| Other Images | ? | Content | x | x | x |
| Start Date | Date picker | Date/Time | x | x | x |
| End Date | Date picker | Date/Time | | x | x |
| Time/Opening Time | Textstring | Date/Time | x | x | |
| Recurrence | Radio box | Date/Time | | x | x |
| Open Sundays | Checkbox | Date/Time | | x | x |
| Hidden Page | True/False | Properties | x | x | x |
Notes:
- In several cases the different document types would have a field with the same alias, but different names displayed to the user, e.g. “Artist”, “Performer” and “Tutor” could all be variants of a single data field.
- Also “Event Type” will contain different options on each of the different document types, to give a further level of classification, but will all have the same alias.
- The Creative Website package has metadata fields for Description and Keywords. I don’t actually see the need to include these, and expect my users to fill them in all the time.
- Similarly I don’t see the need for separate “Page Header” and “Page Title” fields, since the template actually uses the same value for both purposes.
- “Headline” is expected to be a one sentence summary of the item. Where needed I propose to generate a 5-line short form entry by truncating the original (the alternative is a separate field for the user to fill in, which seems unnecessary work).
- Image handling is still to be fully investigated.
- Tab layout is to be reviewed in light of implementation experience.
- Rich Text fields will probably be a specific type to limit the number of editing functions available to users.
Content and Navigation Trees
As far as the end-user is concerned, there will be a single “What’s On” page under the home page, with access from there to lists of activities, and the Calendar. I am not sure yet whether this is a single step or a two step mechanism.
For the content authors I want to split activities into Events, Courses and Exhibitions, partly to help finding things, and partly for possible access control reasons.
The content tree is therefore:
- Home Page
- What’s On
- Event Listing
- Course Listing
- Exhibition Listing
Each level is potentially visible to the end-user, and will look different, so each will need its own Document Type and Template.
Documentation
Make a noddy Data Dictionary, because I think I am going to need it when it comes to writing templates. Just a spreadsheet with details of: Field Name, Alias, Data Type, Prevalues & Key values. I will probably not bother with “where used” since this is too hard to maintain and of less use.