Thursday, 27 November 2008

Gripe #7: empty field values

Not a lot to say about this one, it's just so obviously wrong. An empty value isn't really an empty value, not according to RedDot. An empty value is treated in the same way as not specifying a value i.e. the default value overrides it.

This is just so incredibly annoying, and I cannot fathom quite how it can't be fixed. Surely it's a no-brainer? The workaround always involves doing stupid things like putting in an HTML comment for the value. Crazy.

Tuesday, 25 November 2008

Gripe #6: target containers

Target containers seem like a great idea. In fact, they sound like an absolute necessity, until you actually encounter them in use and, in RedDot's case, forced misuse.

A target container is much the same as any content inclusion mechanism; the training manual describes them, intriguingly, as a combination of server-side includes and iframes. The one drawback RedDot has over (possibly all) other inclusion mechanisms is that it only allows one inclusion. Well, one inclusion per link to be fair and correct.

This only really dawns when:

  • You start thinking about the nature of linking and whether links should only be able to lead to full pages, changes in one part of the page, or changes in several parts of the page. Each is vastly superior than its predecessor.
  • You end up with an 'unbalanced' template: one whose open/close tag pairs do not match up.

The latter seems inevitable in any reasonably structured site that uses the one-hit target container, and causes untold problems involving trying to fit a 'good' template into a 'bad' hole.

I'm sure there's plenty more to be said about the dreaded target container; this is only the beginning.

Monday, 24 November 2008

Goody #1: regular expressions

Yup, even I think that RedDot gets it right from time-to-time, and just when you think this CMS might have abandoned or ignored every standard you're familiar with, you come across user-defined fields and realise it's done the right thing. A user-defined field can be restricted - to the extent allowable - by a regular expression, allowing for flexible, user-defined types. Well done, RedDot.

Gripe #5: date formats

A minor gripe about standards, this one. 'Standard field' placeholders with a date type use 'Microsoft conventions' for formatting. Not being familiar with Microsoft programming, I had to hunt quite a bit for these 'conventions' ... In every other web application I've used where date formatting is specified - the most obvious examples being apache and php - the standard strftime formatting is used. Why reinvent the wheel here?

Thursday, 20 November 2008

Gripe #4: publishing the unknown

Performing an action can be dangerous if you don't actually know what the results of that action will be. This applies to website publishing, much as it does in real life.

When you publish a page in RedDot, you are given three options:

  • Publish just that page
  • Publish that page and 'related' pages
  • Publish that page and 'following' pages

To understand what will happen, you need at least two types of knowledge:

  • An exact understanding of what the concepts 'related' and 'following' mean
  • An understanding of exactly which pages are contained within the relevant set

The first is tricky, partly because the two concepts are not embedded within the general structure and use of the CMS. There are many levels of indirection involved, and neither concept - in particular, 'following' - really has a direct equivalent in a standard HTML structure.

The second involves either a deep knowledge and familiarity with these concepts, or a great deal of manual inspection. Or trial and error.

Furthermore, the concept of a 'page' needs to be borne in mind, particularly when a 'page' is, in fact, a component that might belong on many pages. Even publishing 'just a page' may result in publishing hundreds of actual pages, if that page is, for example, a footer. That's a vitally useful operation to have at your disposal, but it's confused by the notion of 'related' pages.

Add in publication packages, and project variants, and there results a huge number of factors in determining exactly what will happen when a page is published, an operation which is one of the most basic, and fundamental there can be.

Wednesday, 19 November 2008

Gripe #3: no way back

One issue that graphical user interfaces often suffer from is a lack of scalability. Whilst a GUI can make a single operation trivial - think renaming a file in Windows Explorer, for example - it can, at the same time, make a larger number of operations excruciatingly painful - say, renaming a thousand files using Windows Explorer.

At least in your file manager, you can perform more basic operations on a number of files: think deleting them, for example. Imagine if you were forced to delete files one-by-one, selecting each one individually, waiting for a small delay, then moving your mouse over a menu item, and selecting 'delete'. Also imagine that it's very easy to accidentally copy an entire set of files that then need to be deleted.

Yes, RedDot enables you to get into this situation very easily. Thousands of unwanted 'pages', thousands of individual operations to get rid of them. A more powerful command-line interface, or even a more sensible GUI, could prevent this situation from arising but, unfortunately, neither appears to be offered as part of the package. Oh well, I guess that's the price of keeping things 'simple'.

RedDot Users forum

For those wishing to discuss RedDot issues, there's a forum frequented by some helpful folk. I'm not sure quite how active it is at the moment, but it's certainly provided significant feedback to my original post.

Needless to say, I shall be responding to some of those comments over the coming weeks, and will be interested to see the responses this series of gripes elicits.