Symphonious

Living in a state of accord.

One Line Toolbar

I was going to write a post around accessibility and WCAG 2.0 but got annoyed once again about the EditLive! toolbar taking up two lines instead of one.  I’d already removed a whole bunch of stuff from it but it was still wrapping around by a few buttons.

It occurred to me that there are a range of functions that I had on the toolbar because I use them frequently, but that aren’t actually required because I always use the keyboard shortcut. In particular, I have no need for cut, copy, paste, undo or redo because without exception I use keyboard shortcuts. I could probably apply the same logic to strong, em and insert hyperlink as well but my toolbar fits on one line with them so they may as well stay.

Here’s what it looks like:

  • Styles
  • Insert hyperlink
  • Insert image
  • Strong
  • Emphasis
  • Insert unordered list
  • Insert ordered list
  • Decrease indent (actually I always use shift-tab anyway)
  • Increase indent (ditto but for tab)
  • Insert table (useful on the toolbar so you can just drag out the size instead of going through a dialog)
  • Pop out into a new window – great for getting that extra space you need to see what you’re doing.

Everything else is still available in the menus if I need it, but the toolbar is reserved for really quick access to common stuff – just like it should be.

This leads me to Sutton’s first law of editors:

The perceived value of an editor for purchases changes in proportion to the number of buttons on the toolbar, whereas the actual value of an editor for authors changes in inverse proportion to the number of buttons on the toolbar.

Thus, editor vendors should add as many buttons to the toolbar as possible to show off the functionality and nearly all of these should be removed before you actually put it into production. Note however that this is about toolbar buttons, not features – I use an awful lot more functionality than what is on the toolbar but not commonly enough to need to move it out of the menus. This minimal toolbar simply wouldn’t work with an editor that didn’t also have a menu bar.

Note to self: I really must add a good style for highlighting important sections like the law above.

Further note to self: Also need a good style for these notes to self.

Note to engineers: I love how easy it is to add drop shadows with the inline image editor. Finally even lazy people like me can join the Web 2.0 drop shadow revolution! Fantastic work.

What’s The Difference Between a Wiki and a CMS?

Permissions and an edit link.

All too often we think of wikis as some special breed of software that’s completely different to CMS. In reality any good CMS should be able to be a wiki simply by opening up the permissions, removing the workflow and adding an “Edit this page” link when viewing the site. The problem is, most CMS implementations spend all their time focussing on locking things down and adding 10 stage workflows. It’s no wonder user adoption is such a problem, no one has the required permission to do anything!

So it was refreshing to see James Robertson’s article What intranet CMS’s can learn from wikis:

At the end of the day, I don’t care about the publishing tools that underpin the intranet, as long as they work and are used appropriately. I am also not arguing for throwing away our intranets and replacing them with wikis. That would be naive.

It is, however, a good time to take a fresh look at how we manage and grow our intranets, and to learn lessons from the wider community.

Indeed. Learn to find the balance. There are a lot of documents on the intranet where you need to get them right first time – critical policies and procedures etc, but there are also plenty that should be more living documents and evolve over time, benefiting from the experience of your employees. Open up those documents like they were in a wiki and you’re on the road to a successful intranet, without the confusion of having two completely separate systems.