Home arrow How To Use CMS
How To Use CMS



How To Use CMS   

Now we can look at using a CMS, and performing basic tasks. Firstly let's consider simple publishing jobs: getting your content online.

See also: How CMS Works
- a guide to how it actually functions

How content is organised

As you know, there are no pages on the server when the website is run by a CMS - the text and how to publish it are in the database. Other media such as images or video are placed in the usual folders on the server, called directories when we're talking about servers. So we need to organise the way that the application calls up that text and creates a page.

Firstly, let's look at the way a CMS stores and organises content. For this we'll use the current benchmark, Joomla, since it's easy to comprehend the way it works. Benchmark, by the way, just means here that it's popular and therefore well-known and understood, and is an easy yardstick with which to compare other apps. It's right for some jobs, wrong for others.

There are three levels or layers of content, and three types. The three levels, very common in CMS (though often named differently) are:
  • Section
  • Category
  • Content Item

This lays out the common 3-level hierarchy used in CMS. There are variations and additions, but this is the basic format. It is also used extensively in ecommerce, where the designations (though having the same function) would be termed Category, Sub-Category, and Product. Therefore it is common to many dynamic applications.

An item often equals a page - since it is often displayed on its own page. On the other hand, smaller items can be displayed in multiples on some types of site; magazine-style or portal-style for example. So in fact an item isn't a page - but it often is.

Next, the three basic content types, which are essentially just variations on a Content Item:
  • Content Item (CI)
  • Static Content Item (DCI)
  • Alternative content item types (MCI)

The main type of content is a standard Content Item (or CI),
for instance a product or service description, or an information article. It is usually grouped with other items, and edited occasionally.

The next type is
a kind of 'static' content item. This refers to a standalone item that is normally displayed separately and where the text is unlikely to change on a regular basis. A Terms of Use statement would fall into this grouping. We term this a Discrete Content Item or DCI (as static is not an accurate term). This reflects the fact it is standalone, separate, and cannot easily be repurposed. A DCI is not contained within a section or category.

In addition to these common types, there are also some alternative content types. These vary between CMS, but in Joomla, as in some others, an example is the Module Content Item (or MCI) - which is our descriptor as none exists for this. This is content within a module, that is only displayed within that module. It can be of any type, just like any other content, for example text, images or video. It can be displayed in any way or in any position that is possible for a module (including of course in the main page content area if you arrange this correctly).

Create your own module

You can create your own MCI in this way: simply create a new module from scratch (without any plugin etc). Just go to the Module Manager in the backend; click the New button at top right; and you have a new module waiting for your content. Fill the text editor pane displayed: put your material into that editor box. You can use text, images, or anything else that can be displayed.

In this way you can create separate content blocks of any type. Like a DCI, it is hard to reuse and therefore stands alone and separate. It is not contained in a section or category. Bear in mind that only CIs can be reused and republished easily - which is why the bulk of content should be allocated as CIs.

Abbreviations

Because we don't like long descriptions, we will use the following abbreviations here:
  • CI - a Content Item (an item that can be categorised and moved)
  • DCI - a Discrete Content Item (a separate item that cannot be reused)
  • MCI - Module Content Item (content locked within a module)

Content usage

So, probably by the name used for each type, you can see what uses it could be put to. Just to make it clearer, here are the general ways content is used. Section and category use comes a little further down.
  • A CI is the main type of content. It is how you will enter most of the site material, and it can be used in many different ways. It can be moved between sections and categories, or published in different formats according to layout options and plugin features. It can appear on the front page or virtually anywhere else.

  • A DCI is used for items that are unlikely to be used elsewhere, moved, edited often, or repurposed in any way. Therefore, something like a 404 error page, or a Privacy Statement, will be placed in this grouping. A DCI cannot normally be used on the front page, though certain templates can override this.

  • An MCI is created as a module and within a module. It can only be used there and cannot be moved. It is probably designed to be displayed in a certain way specific to that module. An MCI can only be created or used by a backend admin, since module controls are not available via the frontend.

An example in use

If we take an example, let's say an estate agent or realtor: we can start with two groups of pages and some individual items. There might be different areas, with property to let, and property for sale; together with a ToS statement. So, we would first need to create a section, for an area - as the top level. Then, we need some categories for that section: To Let and For Sale. We cannot start by creating individual pages, they need somewhere to live first. A section is needed first; then a category or two that fit inside that; then the page items, which fit in a category.

Create sections and categories

So the first job is to create those sections, otherwise we can't go any further. Having created a Knightsbridge section, we'll have some categories in it: some areas, or maybe price groups, seems appropriate. We can create two categories, for To Let and For Sale, by these names, within the Knightsbridge section. Having done so, we can now create some items / pages. We couldn't do that before as it was not possible unless we made them independent items of the DCI type - which are best avoided except for specific purposes.

So, we'll have a page for an apartment in Knightsbridge, then another page to describe a different one. These pages then exist in the following hierarchy:

  • Knightsbridge (a Section)
    • To Let (a Category)
      • apartment 1 (an Item or page in the To Let category)
    • For Sale (a Category)
      • apartment 2 (an Item or page in the For Sale category)
      • apartment 3 (an Item or page in the For Sale category)
  • Terms and Conditions (a DCI)
This should be fairly straightforward. You cannot create normal pages (CIs) unless there is a category for them. You cannot create a category unless there is a section for it to be placed in. A DCI can be created straight off but cannot be placed in a category or otherwise reused.

A section is the top level, and may have dozens of categories within it. A category is the middle level, and may have hundreds or even thousands of items (pages) in it. Normally, it is found that CMS are limited to a 3-layer system - and it is not therefore possible to have sub-categories. There are workarounds, depending on the final result (and especially the menu options) you are looking for. Sub-categories can be created, but this is stepping past basic use.

Displaying your content

Now you have some pages, you can publish them. To 'publish' them means to make them visible to site vistors. In order to do this they need to be able to 'turn the pages' of your site, to see the next page. We do this with menus and links.

Links are text or visual items that can be clicked on to produce a change in the visible elements of a page, or to move to another page; menus are a structured collection of links. You will probably link your important resources via a menu or two.

So this means, in plain language, that in order to find a page it has to be linked somewhere. The easiest way to link it in is via a menu button:
  • You can display a section header page if you wish; this will contain a list of categories within that section, plus whatever text / images you wish.
  • You can display a category header page; this will have a list of pages within that category, plus text and images if wished.
  • Or you can dispense with those and just link the pages to a menu somewhere.
  • DCIs, which are discrete items, have to be linked directly via menus or other links.
  • MCIs can only be displayed within their own module. That can be assigned to all pages / some pages / one page alone. The position on the page can be chosen.

Menus

In Joomla there are 4 menus available out of the box, but you can create as many new ones as you like. If you need a menu for Apartments, you can create one and name it as you like; and you can display it on any page or pages you wish. You don't have to use an existing menu or name it in any set way.

If you want a completely new menu, called Apartments, not using any of the existing menus, to show only on page 38, in an unusual position - that's OK, you can have exactly that.

The first and main choice is how you want to display the main menu. The two most common choices are as a left column vertical menu, or a top of page horizontal menu. In general, if there are going to be many links, then a vertical menu is normally used. If there will be less than six or eight menu items, then a horizontal top menu is popular. Extra items can be placed on this by using a drop-down system.

This type of moving menu expansion is termed a fly-out or cascading menu. There are some usability issues here because some believe all menu options should be clearly visible from the start.

In addition, fly-out menus must be scripted carefully to ensure that search engine indexing bots - spiders - can travel through them easily. There is only one known way to ensure this, and it is by using the Suckerfish HTML-CSS cascading menu system. This method can have add-on scripting (normally JavaScript) to provide additional functions such as smooth delays. JavaScript can be used purely as an add-on provided that the menu still works correctly without the scripting.
Flash should never be used in a menu in any circumstances.

Site architecture

There are choices to be made as to how to arrange your site. This refers to the 'shape' of the site, insofar as the way access to pages or other resources is arranged. These devolve to four main choices:

  • A 'deep' architecture, with few top-level and 2nd-level pages but many at the 3rd level and below.
  • A 'wide' architecture, with many top-level pages visible in the main menus.
  • A standard architecture, which is a combination of these types.
  • A specialist architecture, such as a member-based site, or a directory.

Menu arrangements

In general, for very large sites it is preferable to use section and category main pages as part of the menu system, in order to locate the large numbers of pages. Such pages act as the start page for that section or category; and the CMS populates the menus automatically.

For large sites, category pages can be used as part of the menu system. Again, the CMS provides the menu entries and does all the linking, so no manual input is required.

For medium size sites, sub-category pages can be arranged, containing manually-created additional menus. These menus have to be created and linked by hand. They can be used in addition to the CMS-created category main start page menus.

For small sites, manually-created menus can be used throughout. In fact this may be the best system as a category page with few page items in the on-page menu does not look correct.

Any combination of these menus can be used for any site. New menus can be created from scratch for specific purposes - if you need 99 new menus, of different styles, on different pages, in different positions - that can be accomodated.

Designing site architecture

It's true that the menu structure defines the site architecture: the way the site appears and is laid out. Before you start to build menus, then, you should have already decided on the 'shape' of your site.

One way to do this is to make a list of the various content groupings that will exist on the site; how they will interact, if at all; and what the main and secondary purposes of the site are. Once you have a picture of the site content and functions, you should be able to see how it needs to be structured. When that is decided you can arrange the menus.

As an overall general rule for menu structuring, when a site consists of more than 5,000 pages you will be better off using CMS auto-created menus for the basic structure - there is too much work otherwise. At under 1,000 pages, an all-manual menu system will probably be best as this is a small site. Small sites benefit from the finer control that manually created menus give. At any stage, a combination can be used - even on small sites, if perhaps there is a category with many pages in it. Here, it may be found useful to adjust the CSS on such a category start page, to obtain the best possible appearance for the on-page menu.

 
 
Web Business Managers