This section will eventually move off the a part of www.tanasity.com. When we install a Wiki there. For the meantime this is a good place.
This page should really be called:
So what are the attributes of the perfect system?
Probably the single most important aspect of software, and the most underplayed. It’s how it looks and acts that matters most. It should be flexible and simple, allowing you to grow the facilities available slowly and steadily.
Programmers are really bad at crafting interfaces to understand implications. If it’s A or B as a choice, and B has a sub part B1, then by clicking B1, I am implying B. Why should I choose B then B1 when one operation will do fine. And if I change my mind, and click on A, all the subparts of B should understand that they are no longer selected. And if I subsequently change my mind, well it should remember my last set of B preferences instead of making me do all the work again. Particularly if B is long and complicated.
That sounds obvious. But you wouldn’t think so looking at CMS systems. Firstly, some pages don’t need the template around them. Some need different templates. Some need the template and handcrafted interactive DHTML. Some are similar to other pages and can be based on templates. Others are list views. Some list views are graphical - a map with locations for instance. A good CMS system needs to accomodate variety.
So you can mix-and-match bits, and the user interface is smart enough to recognise & change. So for instance, if my site doesn’t need people to be able to comment, then I should be able to turn off the Comments module. Voila! No more comments, and no overhead.
You should be able to add and remove modules afterwards. You should be able to disble modules. There should be a failsafe.
You should be able to set features at any level. For instance, if the comment system is useless except on one particular page of the site, I should be able to switch it off everywhere except on that page. And I shouldn’t have to endure a great deal more complexity for using the feature minimally; that is - the complexity of using a feature should scale as the feature is used more.
You need a proper installer that asks questions and only installs things that match.
It should be able to handle pretty much any database you throw its way. Including the plain vanilla file system. But it shouldn’t impose unacceptable penalties for the abstractions required.
For instance, some sites are for members only. The policies might be:
Another site might be more democratic:
For instance – overlay this block on that block.
The steps below describe Drupal’s built in congestion control mechanism, the auto-throttle, and walks you through its configuration. Drupal.
So that installations can share data. See Drupal.
Plone – has acquisition. An inheritance mechanism for content. /bob/smith refers to the smith object attached to the bob object attached to root object. The default is to render smith which may ask/call bob to render. Smith inherits lots of stuff from bob.
A poor man’s if reqd.
Discussion about nodes is rubbish computerism. Pages. Page parts. Not nodes.
And the store should deal with VAT.
Should allow pages, snippets, templates, modules, database drive portions, forms and more.
Interfaces that are modular are made of parts. Sounds obvious. There are always two ways to get to the same feature, and the UI should give access to both. But to avoid things seeming to be complicated, the navigation to the parts should be very carefully handled.
For instance. Suppose I add a new feature to an existing CMS. Let’s suppose I want to be able to attach a picture to every (or some posts). If I’m working in my CMS adding one page at a time, then I want this feature to be available in the same place as where I’m editing the content. So if I go Home>Content>New Page, it should be part of the New Page script.
But if I already have a lot of content and I’ve just added the new feature then I need a central area to add pictures to many pages at once.
There’s a third place to do with the feauture; at the meta level, I may need to configure how the picture feature works. That means that there needs to be a place where I can change the settings for this feauture across the whole CMS.
And indeed there may be a fourth place if I can change the settings for individual pages or groups of pages.
A good CMS will have a well structured UI that takes account of all these possibilities, and provides smooth links between them, giving obvious cues about the differences.
A good CMS will re-use what you already know. Whereever you deal with data there are several fundamental functions on data items: you can enter a new data item; you can edit an existing data item; and you can delete an item. You also have some fundamental functions on groups of data items: you can list them (perhaps changing the order); you can select some for an operation (delete, update, change, whatever); you can perform an operation on a selection. Selection may be through direct selection (e.g. ticks in tickboxes) or through filtering (search to find all people who are older than 50). Providing a decent filtering mechanism is difficult - you need to balance power and complexity for the audience. For instance - an audience of database administrators may feel perfectly comfortable typing SQL into a field to make their filter, but most people will be lost at this point. A graphical tool for selection becomes very complicated if it’s possible to make selection criteria as complex as SQL allows, so you usually have to provide something less complex. Firefox’s Find Mail is a perfect example of this problem - you can either find mail using an AND function or OR. But not both.
Then there’s a meta-level. It’s sometimes very useful to be able to save and recall particular selections. This leads to a decision point: are selections static or dynamic? That is - if a particular filter has selected items 1,3 and 5, then is this information stored as (filter: items 1,3,5) or (filter: query). If item 7 which matches the query criteria is added to the data, then using the first version of the saved filter, you won’t find it when you search again. Using the second version you will. Neither way is always good. What if item 3 is changed so that it no longer fits the criteria, does that mean you want the historical information that you embodied in the save invalidated? Probably not. When I save, I mean save. I don’t usually mean save but forget some stuff because it’s changed. One solution is increased complexity - remember both and warn the user when they don’t match.
This leads onto the greater problem of what happens in when the data has changed. Maybe the search criteria are no longer valid because a particular column has been removed.
A good CMS will provide a consistent UI for all these functions that can be re-used regardless of what you are doing in the CMS.
One of the things we see again and again is different styles of listing. Drupal has all sorts of modules for listing nodes in particular ways.
You often have overview pages pulling content from one or more places. For instance your front page is very often an overview page, pulling data from the sections, using the last few posts. Or you might have a product over view page with listings of your top sellers in each category. Or you may have a personal portal page which brings together content from lots of places. You may wish to enter a Logo on every page to indicate ownership. Or...
One of the problems of developing a CMS with flexibilty, but without ridiculous unwieldliness might be a configuration mechanism which is based on flow graphs.
Drupal solves the problem with hooks and user configuration, but this seems clutzy. Plone solves it by using the Zope contextual hierarchy mechanism - aquisition: pages are made of objects which establish their context from the objects that host them, and this happens recursively up the tree. But you could do it with a meta facility letting you say that a particular page template is made up of these parts in this order, then page processing would comprise a calling list, passing along the page data, starting with the page template, and ending up with a full page.
Would this system have advantages?
Another way to do it would be to have it entirely data driven. Use the database structure as the driver, with handlers attached to particular data parts. Would this offer flexibility? Or would it be too complex for ordinary users to configure? It would make it very easy to extend the system if the default handlers were sensible. But it might make it hard to have contextual handlers. A practical example: the db holds a table with columns for date, author, place. Viewing a page based on this table might show a listing of the individual rows in a row-by-row fashion because the handler knows that this is the way to show an individual data row. But now you want to see the data in a different context - you’d like to see it on a map. Now the handler for each row has to do a different thing.
Maybe there’s a convenient compromise?
Notes: Xaraya has dynamic data idea. Typo3 has content elements. Investigate. Drupal also has Flexnodes - v1 and v2.
So, my CMS is really flexible. I’ve selected a bunch of components and organised them in a particular way, and it’s turned out to be very useful for my particular industry (say, education). I should be able to very easily share my setup. A single file(?) should encapsulate all the important choices I’ve made - the components I’ve used, the database structure, the way that components are configured and the way that the components are wired together.
So I’m working in my CMS, adding a page. I come to the part where I want to classify the page. It’s a page about cars. But my classification list only has Birds, Bees and Misc. Uh oh. I could go somewhere else and add in Cars. Or I could put the page in Misc. I should be able to add Cars to the list. See crosscutting above.
That’s not as bad as it sounds. Deleting a page is easy. Click and it’s gone. Hopefully to a bin so that it can be retrieved if necessary. Now what if the page is built from a template and you delete the template? Should all pages based on that template be deleted too? Should they be marked as not published, but not deleted? Should they be just not be deleted, the deletion would just leave you without the option to create new pages of that type. (Unless perhaps you have ‘Create another page like this’ prototyping.) Are pages that are made from templates chopped up into parts and the parts become a database table? Or maybe it’s more like cookie cutting: the page stays as a whole and is independent of the template after the initial stamping. Or you could confuse people with choice. What this is partly about is how strong the page type system is and has similarities to the sort of difference between early or late binding too.
It depends on the degree to which the data is tied to the item. If the item is a tag, then no, you don’t delete the page when you delete a tag term. Even if the tag term is in a taxonomy. Because those are only for classification.
It’s a general problem of dealing with change. So it’s not only for pages. Suppose you have a classification system and you change it from flat to hierarchical. No problem. What if you want to go the other way? It’s okay if there are no subterms, you can go back to flat. But what if it’s got subterms. Do you delete them? Do you refuse to change? Do you reclassify the list and ignore the subterms. Or assign any items with that subterm its parent term? It gets worse with multi-parented items.
Dealing with things that get too popular. Caching. Ways of aggregating. Gardening.
Breadcrumbs - either hierarchical or trace. Or both if they are in different places.
They happen in two ways: static content linked in series and forms. Forms should deal nicely with Back reposting data.
There are two broad ways of positioning things. Firstly you can just order them by placing them. This works well for a small number of items. Or you can position through weighting which works well when you have a large number of items or a dynamic list of items.
You should be able to display content based on the content. That is - it’s not good enough to display a special block of info for blogs. You need to be able to display a special bit of info if the actual blog page that you are viewing has some particular content. Say the word ‘GPL’. Or perhaps it’s part of a taxonomy branch. Or it’s content from an external site. Or whatever.
You shouldn’t need to have to go to some external site, download code and install. Ideally it should be do-able from inside the CMS.
List from CMS matrix:
System Requirements Application Server Approximate Cost Database License Operating System Programming Language Root Access Shell Access Web Server Security Audit Trail Captcha Content Approval Email Verification Granular Privileges Kerberos Authentication LDAP Authentication Login History NIS Authentication NTLM Authentication Pluggable Authentication Problem Notification Sandbox Session Management SMB Authentication SSL Compatible SSL Logins SSL Pages Versioning Support Certification Program Commercial Manuals Commercial Support Commercial Training Developer Community Online Help Pluggable API Professional Hosting Professional Services Public Forum Public Mailing List Third-Party Developers Users Conference Ease of Use Drag-N-Drop Content Email To Discussion Friendly URLs Image Resizing Macro Language Mass Upload Prototyping Server Page Language Spell Checker Subscriptions Template Language UI Levels Undo WYSIWYG Editor Performance Advanced Caching Database Replication Load Balancing Page Caching Static Content Export Management Advertising Management Asset Management Clipboard Content Scheduling Content Staging Inline Administration Online Administration Package Deployment Sub-sites / Roots Themes / Skins Trash Web Statistics Web-based Style/Template Management Web-based Translation Management Workflow Engine Interoperability Content Syndication (RSS) FTP Support UTF-8 Support WAI Compliant WebDAV Support XHTML Compliant Flexibility CGI-mode Support Content Reuse Extensible User Profiles Interface Localization Metadata Multi-lingual Content Multi-lingual Content Integration Multi-Site Deployment URL Rewriting Wiki Aware Built-in Applications Blog Chat Classifieds Contact Management Data Entry Database Reports Discussion / Forum Document Management Events Calendar Expense Reports FAQ Management File Distribution Graphs and Charts Groupware Guest Book Help Desk / Bug Reporting HTTP Proxy In/Out Board Job Postings Link Management Mail Form My Page / Dashboard Newsletter Photo Gallery Polls Product Management Project Tracking Search Engine Site Map Surveys Syndicated Content (RSS) Tests / Quizzes Time Tracking User Contributions Web Services Front End Commerce Affiliate Tracking Inventory Management Pluggable Payments Pluggable Shipping Pluggable Tax Point of Sale Shopping Cart Subscriptions Wish Lists Speed