Forum Moderators: coopster
I started off creating my CMS systems when I was at university using a kind of flow map, one page submitting to the next in a way that forces the user to go through a whole set of pages to insert / modify their data, this led to a lot of files in the directory you are working from. After this process was getting a bit tedious (both for myself working on it, and the user using it) I decided to start making my CMS systems so that all code is contained on one page, using variables to display different blocks of content, this seemed to work well until very large CMS systems caused long pages of code so the different sections of code had to be split into include files to keep the size of the index page down.
Recently I have been creating modules so that I can plug these into the relevant CMS section I am working on, for example a module to create the code for a drop down list / check boxes containing various data from the database. This limits code and time when you need to add something into the CMS that wasn’t originally planned for as you can just call these modules and add code quickly. The only problem with this is that it takes a while to set up, but once it is it works well. The only thing is I am sure in 6 months or so I will see a style of writing CMS systems that I think is better that the style I am using and change what I am doing to correspond more with that.
What I was wondering is what is the best type of architecture for a CMS system, I would be very interested to know what processes or flow works well for different people, and whether there are any cool time-saving tips and tricks I am missing out on.
Cheers
Ally
For example, when WordPress came out, I ditched all my "classic" CMS systems for it, because I was using them as blogs, and was turning off three-quarters of their functionality. WordPress was designed as a refined blog CMS. I would not use it for a community portal, though. A more "traditional" CMS like Xaraya would do better for that. Gallery2 and Coppermine Photo Gallery work best for image galleries. I think you can shoehorn them into other CMSes, but that isn't the way they are usually used.
Basically, I won't design my own CMS, except in response to a specific need (I do it all the time for the sites I design). In these cases, I have a known workflow and a definite specification, so there is no need to design a "Swiss Army Knife" site.
I go for a few targets in my designs:
1) XHTML 1.1 Validation. Every page needs to validate, and I send Content-type:application/xhtml+xml headers when the browser will accept it.
2) CSS 2 Validation
3) WAI AAA Validation, even in the "behind the scenes" administration interfaces.
4) Speed. I will sometimes use "page compressors" to strip out the cruft from my pages.
5) Visual Simplicity. Only the required UI should be presented to the user at any given time. I'm pretty ruthless about taking out crud unnecessary to the task at hand.
This generally means that each page is crafted to meet the needs of only that page. I use a "taxonomy" model of design, in which I start with a genus, or the common features of all pages, then establish branches to specific areas, and finally resolve down to specific individual page design.
This means that, if I design a CMS, it is a lot of work, so I have to spend the time to see if a more commonly-available CMS would be more appropriate to the task at hand.
There's also a very simple formula: "One Plus One Equals Three or More." This is a saying that designers use to describe visual complexity. It also goes for code.
Every line of code you have, unused or not, is another place for a bug to happen. Every character you transmit gives more time for the stream to be corrupted.
I totally believe in the KISS principle. Maintenance is 3/4 of the work in a site, and we often neglect thinking about it during the crucial design phase.
Just my $0.02.
P.S. There have been all kinds of discussions [webmasterworld.com] about CMS systems on this site. Search around [google.com], and see if there is anything useful.
