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.
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:
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.
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.
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?
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:
To understand what will happen, you need at least two types of knowledge:
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.
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'.
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.
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.
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.
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.
