Ten years ago I sat down and started to learn HTML code with a view to creating my own web site. Actually, that is a process which continues to this day, because it's a technology which cannot be mastered in an instant - as anyone with half a brain will agree. It wasn't as easy as some guidance books make out, but I persisted; and 1,500 pages later, I have something of which I am not ashamed at www.mantex.co.uk. But as it grew in size, I realised that I needed to move from hand-crafted pages and navigation to a content management system (CMS).
These are stand-alone, modularised programs which can be used to create, edit, review, index, search, publish and archive a large scale collection of materials. They are reputed to take much of the slog out of dealing with complex web sites - and I was eager to avoid having to change a single detail of my site 1,500 times on each occasion of coming up with a bright new idea.
But where to start? My son gave me the first piece of good advice. "Whatever you do, avoid in-house, custom-made systems". This turned out to be correct. I even put out tenders to some web-designers, and almost all of them came back with solutions which would mean being locked into their systems - which hardly anyone else would be using, and which might go out of business in six month's time. The answer was obvious - use Open Source systems. I located Drupal, Joomla, and WordPress.
For the next few weeks I dabbled with all three, and was led into a labyrinth of puzzlement and time-consuming frustration - all because I had not grasped some fundamental concepts about CMS. In the end I settled on WordPress because it seemed easier to use - but the fundamental concepts (and problems) are similar with each program. Some of these might seem elementary to expert users, but as a rule of thumb I always think that if I am struggling with something, there will be plenty of other people in the same boat. Hence these notes.
The number one conceptual issue (and I've not seen it mentioned in any guidance manuals) is that what you see on screen whilst inputting data has nothing to do with what the finished results will look like. That's for two reasons.
The first is that the interface for entering the data is just a tool, - it's not part of the end product. But the far more important reason is that when using CMS the content of your site is separated entirely from its appearance on screen. Why is that the case?
Because in CMS all items - text, graphics, links, titles, sub-titles, adverts, and stock items - are entered separately and kept in different places from each other so that they can be recombined in a number of different ways at a later date. This avoids having to re-submit data each time a new page is created.
For instance, the content of footer to a page is usually fixed. It might contain the name and address of the organisation; the contact details; a copyright notice; terms and conditions; a datestamp; and web links. All of this information goes into one file, and that file is added to the bottom of every page. If anything changes, you edit the file once and the change appears on every page throughout the site.
How does this work? Well - all the separate items of information - the text, the graphics, the footers, and the adverts - are entered into a database (probably MySQL). The database keeps all these separate items in their own ''containers' until they are summoned to appear. Text goes into one container; graphics will go into something like a photo album; and so on. So far so good, but how do they get from the database onto the screen?
Enter two more layers of software. A program called PHP decides what to drag up into the screen. It is software which is programmed to decide which elements of a page to assemble. First grab the header, add the body text, throw in any graphics, then finish off with the footer. Templates decide where and how that information is displayed, and the appearance of the information on screen is determined by style sheets (CSS).
This probably sounds complex, but you can see the logic which lies under the process. Put any number of elements into a big database, then summon up those you require. It's a combination of these separate elements: the database in which the elements are stored; the program which summons the elements; a template which determines how the elements are arranged; and a style sheet which determines their appearance on screen. Makes it sound quite simple, doesn't it? No - I thought not.
Content Management Systems have huge advantages, and they also have problems. For instance, one enormously powerful in-built feature is that you can designate which parts of a site a particular page belongs to, and the CMS software will automatically work out the navigational system for getting there. For instance, a page on Virginia Woolf can be categorised as belonging to a sub-category twentieth-century literature in a main category Literary Studies - but it can also be attached to pages listed in categories 'Bloomsbury', 'Modernism', and 'Literary Criticism'. That's the upside. The downside is that you still need to know quite a bit about information architecture to know how to control all this.
And there's another thing. You'll endlessly be asking yourself - &qot;I've just created a new page. Where is it now? And how can I find it?" It's not easy to keep a mental picture of all your assets (as they're called) when everything is disappearing into that big database.
That's more or less where I'm up to right now - and I know there's still a long way to go. But if like me you're still a beginner, I just thought these few words might help.
No comments:
Post a Comment