The problems with 'overpublishing'

One thing that has always bugged me about RedDot is that publication report as long as your arm. The first thought that runs through my mind is always "what the hell did I just publish?" On closer inspection, it usually turns out I've published one or two pages and ten images.

Now, that might not sound like a big deal, but when the image is "logo.gif", it's included (indirectly) on every page, and it gets published out with every single page, that's a bit more of a problem. RedDot's default mode is 'publish everything out', not the far more obvious 'publish out only the things that have changed'.

Why is this a bad idea?

1. Every write to a disk shortens that disk's life. It may be imperceptible, but it's happening. Probably not a big deal compared to all the other stuff that's writing to your disk, but certainly a flaw when it's absolutely unnecessary.
2. It considerably lengthens the time to publish, especially when you take documents, sound, or video files into account.
3. Your web server's sending out useful 'Expires' headers that tell the client not to request another copy of your logo because it never changes, right? Not any more.

Now, to workaround for RedDot's bug.

One option is to write-protect your long-term images, documents, etc. RedDot will still try to write to them on a publish, it'll just fail. This should fix problems 1 and 3, but you'll still experience lengthy (possibly lengthier) publication times.

RedDot offers an option to never publish images (even if they have changed) which is one possible solution, but you'll need to educate all your content authors / editors to rename image files when they update them. This may or may not be possible.

Failing that, you could actually remove image management from RedDot altogether. Let's face it, the media browser is pretty terrible, so managing the files directly on the web server (maybe using a better alternative front-end) could give several benefits. Of course, all your image references in markup will then need to be absolute (unless you're running RedDot on your web server ...) which could cause further problems.

I'll be investigating that last option - more soon.

Long time, no post

So, it's been over two weeks since my last post; the post-a-day aim has failed spectacularly. I've been on holiday for a while, so don't worry, the cause is certainly not lack of material. Over the next few days, I'll see if I can catch up a bit, and I'll also throw a slightly new format into the mix.

Rather than posting on individual 'gripes' and 'goodies', I'd like to just run a commentary on what I'm doing with RedDot, what goes well, and what fails. I'm hoping this will make for more balanced information, whilst still highlighting my grievances with the product. For example, if a problem is such only because of a poor implementation, I'll rightly absolve RedDot.

It's become obvious to me, recently, that poor organization is probably more culpuble than RedDot itself when it comes to many of the issues I've faced. I hope you enjoy reading what I have to say.

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.

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.

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?

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.

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.

Gripe #2: popups

RedDot CMS makes extensive use of popup windows. By extensive, I mean that certain operations can leave as many as 4 separate browser windows open at one time. Now, I'm not claiming here that all popups are evil, but their use in RedDot certainly leads to usability issues.

One very common action whilst working on a site is the switching of windows: for browsing the web, checking email, reloading a live site, and so on. RedDot's popups continually force themselves to the front of the window stacking order, causing an awful lot of frustrating 'ALT-TAB-ing'.

Another frustration is that switching back to a 'lower' window (most often, the main interface) and selecting something will cause a popup to disappear. This causes a lot of repeat behaviour at best, and the potential loss of work at worst.

Finally, possibly the most hilarious (if it weren't so annoying) bug regarding the popup windows is their size: time and time again, certain popups will open just that little bit too small. Too small to actually show a popup dialog's buttons. Every time certain windows popup, they have to be resized to action. This is a recipe for keyboard/mouse switching and a whole host of associated frustration and RSI. It's also really quite unprofessional.

Gripe #1: invalid markup

Introduction

Kicking off the series of RedDot gripes, here's number 1. Please note: the series is not in any kind of 'preference order', merely a big list of things as and when I find them.

The RedDot Text Editor

By default, RedDot creates invalid markup. This is purely down to the terrible 'WYSIWYG' text editor, that is neither WYSIWYG, nor standards-compliant, begging the question "why the heck have it in the first place?" Of course, to novices, it looks quite impressive ("Wow, I can write web pages without needing to know HTML! WOO-HOO!") but, as is often the case with attempts to dumb things down, this only hurts the expert editors who now cannot take advantage of their actual knowledge and experience.

This editor also annoys the novices, much in the same way Word, Outlook, and other poorly-implemented WYSIWYG editors do, in that it can make it extremely difficult to do things like cancel a list, unindent an indent, etc. I've seen real HTML editors that actually do a good job of this, so it's not like it's impossible.

It's almost comical the extent to which the editor screws things up. Inserting span tags everywhere, the proliferation of ' ' (note to RedDot programmers: the character represented by ' ' is NOT the same as a space!), and unquoting attribute values.

And RedDot's solution to this problem? "Use tidy". While I'm all for the use of separate, small, specific tools to get the job done, this is just not an option because tidy can only be used at the point of publication, so any problems caused by RedDot spewing out invalid markup will still be evident in preview / smartedit modes.

There are so many clean, reliable, open-source HTML text editors out there that do a really good job. There are also powerful, full-featured text-editors for those of us who like to do things by hand. By rolling their own tool - and doing a really bad job of it in the process - RedDot have managed to satisfy none of their audience.