LiveWhale, our CMS, is essentially a module-based system. Individual modules can be provided to our customers on a per-client basis. Each module is a self-contained element, that “registers” itself in the CMS framework, thereby establishing its functionality throughout. A module is responsible for creating and managing its own data, but if it is flagged as group owned, access to that data is handled by LiveWhale’s users and groups system.

It is, of course, possible for an administrator to manage those users and groups, and should a circumstance arise in which a group should be targeted for deletion, LiveWhale automatically cleans up data associated with that group (whether it is stored in a database or the file system) so that it is not orphaned. (This is in fact the case with any piece of data which “contains” additional hierarchical data.)

The mechanism we have in place for this is simple, but it is also flexible. Each piece of associated data that has to be cleaned up by a parent marked for deletion can optionally be given to a handler deletion function. For example, if a piece of news stores an image in the file system, the handler function is activated to clean that up as well.

Eventually we added a global activity log to our CMS, LiveWhale. Activity is associated with a user and a group, making this data group owned. As it turned out, the group deletion mechanism possessed a flaw. LiveWhale’s internal delete routine initially expected the logic about what a handler function had to do, if anything, to come from the handler function itself. In fact what it needed to do was to first deduce if a handler was optimal for a particular type of data at all. The activity data made this clear, when there was suddenly a need to delete hundreds or thousands of individual pieces of data which were designed to be stored in huge quantity over a long period of time (unlike with news management, for example). Pushing the handler logic up into LiveWhale’s delete routine made it no longer necessary to perform logic a hundred or thousand times when the result was always going to be the same, and a one-off deletion procedure could alternatively be used for the bulk data.

This drives home the point that building something requires either the proper foresight to know how that system has to conform to conditions that haven’t yet come about, or ensuring that the foundation you’ve already built adjusts to appropriately handle new features as you add them. Fortunately, our LiveWhale development process utilizes a variety of monitoring tools and diagnostic tests which inspect the system closely to continually perform a sanity check on the results of code execution over the product’s development lifetime. This was a case where the system noticed the deletion flaw even before I did.

Our first effort, a screencast of LiveWhale’s news system, leaves much to be desired; it’s clear that we’re new at this.  It’s hard to figure out the right tone of voice (how much humor?  how fast?  etc.), and it took several takes to get through it without messing anything up.  (And we still had to edit the final product a bit.)  I’m sure it’s something we’ll continue to refine and improve as we continue developing LiveWhale’s documentation.

All of this is to say that I  just watched the most effective screencast demo I’ve seen in a long time, if not ever.

Google has just added video chat to its Gmail service.  This is a big deal— not only is it a potential Skype-killer, it opens up the possibility that video chat will become a part of life for all computer users the way it is for Mac people.  (Video chat has been deeply integrated into the Mac for years now; I know several people who have bought their parents Macs solely because it’s so easy to do long-distance videochats.)

Anyway, the video demo is sublime, wonderful, perfect:

On the one hand, it’s probably best to let users make mistakes, or format as they wish, and depend on human communication to clear things up— instead of trying to build in a bunch of extra structure designed to cover for mistakes.  It’s our view that the latter approach leads to bloated, overbuilt CMS systems that discourage accountability.  But at the same time, consistency and coherence of communication across a Web site is a really, really important thing— it is what distinguishes sites that serve as good vehicles for an institution’s messaging from sites that are just decorated Web pages.

We’re thinking about this right now because we are considering automatically converting the titles of news items in LiveWhale to Title Case.  The following three news headlines, though identical in content, send very different messages:

1.  White Whale Web Services to Release New Content Management System, Revolutionize CMS Industry
 

2.  White Whale Web Services to release new content management system, revolutionize CMS industry
 

3.  WHITE WHALE WEB SERVICES TO RELEASE NEW CONTENT MANAGEMENT SYSTEM, REVOLUTIONIZE CMS INDUSTRY
 

Although there might be a justification for #3 in a particular Web design, it’s clear that you wouldn’t want a user to enter news headlines that way.  For one thing, caps are just hard to read in many contexts; but on top of that, it’s always easy to {text-transform:uppercase} if you need caps.  My general preference as a design snob would be for #2, but that’s clearly not common practice— as much as I enjoy headlines like this (or this), that style is much more common in European news than American.

It’s also the case that styles #1 and #2 look terrible next to each other:

• White Whale Web Services to Release New Content Management System, Revolutionize CMS Industry
• Other CMS providers cower in fear

So.  Should we let users do what they will, and enter headlines according to any system they prefer?  Or should we legislate something?  It seems pretty clear from the above examples that— at least in the particular case of news headlines— legislating is the way to go.  And if you’re going to require a particular format for headlines, it seems pretty clear that Title Case Is Your Only Option.

So what’s the best way to do it?

You could, for example, simply ask the user to format the headline a particular way:

___________________________________________________
Please use Title Case for headlines.

Or, a bit more diplomatically, you could provide an example:

___________________________________________________
Example: Stock Market Soars on Rumors of Bailout

Alternatively, we could let users enter any headlines they want, and control the front end display with CSS’s text-transform property.  But that’s not going to work either, because these are the only options we have:

Title Case Is Great, But Not If You Capitalize Every Word In The Sentence.  Otherwise It Looks Hacky.  The text-transform property doesn’t have the kind of sensitivity you’d want in a good Title Case headline.  I am personally big on punctuation and capitalization styles that reflect spoken rhythms— that’s why, no matter what Douglas says, I always put a space after an em dash— and capitalizing “the,” “and,” etc. ruins the spoken rhythm of a headline.

So the only approach left— assuming you want to engage this issue at all!— is to automatically convert headlines into Title Case on the back end.  And that’s the whole reason I started this post in the first place.

It turns out that converting to Title Case is nowhere near as simple as you’d imagine.  Sure, we know that you don’t capitalize “the” or “a” or prepositions, etc.  But how about sentences like these?

Read markdown_rules.txt to Find Out How _Underscores Around Words_ Will Be Interpreted

Notes and Observations Regarding Apple’s Announcements From ‘The Beat Goes On’ Special Event

These sentences are from a suite of test cases for a Title Case script originally created by John Gruber of Daring Fireball.  We are planning to use the PHP version of the script to convert some of Southwestern’s old news headlines (originally entered with uppercase headlines) to a thoughtful Title Case, and are considering using it when headlines are created in LiveWhale in the first place.  In the process we discovered yet another odd, fascinating corner of the world of CMS development to geek out in.

But at the risk of stealing some thunder from that announcement, I’d like to show off something that we’ve been spending a lot of time on:

This is the add-a-news-story page of LiveWhale, the CMS we’ve developed as an answer to problems posed in our infamous (among our clients, anyway) content management manifesto. In later posts I’ll go into some detail about specific interface choices we’ve made (a personal favorite is the flowchart behind attaching images to news stories), but for now I’ll talk about what we didn’t do.

One of the main problems with most enterprise content management solutions is their unapproachability. A simple task like a creation of a news item can be buried by layers of menus, technical jargon, and–let’s be honest–really ugly interfaces. It’s the type of interface that savvy users master through days or weeks of training and non-savvy users end up navigating by way of post-its on the side of their monitors. But you need those weeks to worry about everything else involved in your website launch; you need that space on the side of your monitor for pictures of your kids.

We set out to create an interface that minimizes the distance between what the user wants to accomplish and what she has to do. This gap is huge huge in most enterprise CMSes. Adding or editing a news story is a task that every staff member at your institution understands intuitively; why does it so often feel like piecemeal data entry?

Making the user click “Attach resource” when she wants to add an image creates a cognitive separation where one needn’t exist. So all of our instructions and labels are in plain English. Steps like having to enter the story body on one page and the contact info on another–or burying things in menus, or presenting disparate information as visually equal–create a similarly artificial distance. That’s why our news edit page looks almost like a published news page: we want the headline to jump out at you and the image to appear at reasonable size, and we want everything that appears on the frontend to appear here.

By minimizing this distance between the user’s goals and the user’s processes, we think we’ve made LiveWhale a snap to use regardless of where you fall on the scale of technical knowhow. One of these days we’ll give more of a detailed tour; but, in the meantime, let us know what you think.

With some thought, we were able to come up with a taxonomy of content photo sizing:

1. Constrained horizontally (e.g. in a sidebar):
   
   
2. Constrained vertically (e.g. to align alongside text):
   
3. Constrained both horizontally and vertically within a box:
   
4. Constrained both horizontally and vertically to fill the box, with the edges lobbed off automatically (e.g. when needed as specific design element):
   

I thought the fourth case would be the only troublesome one, but we knocked out uses 1, 2, and 4 rather quickly. Use 3, however, proved to be a problem; we just couldn’t get it to size appropriately for every test case. Unlike the others, it was unclear what dimension to constrain to: it varies not only for the same image placed in different spaces, but also for different images in the same-sized space:

It was one of those problems that is as easy to describe–”fit the image in the box”–but hard to wrap your mind around programatically. We knew there must be simple logic to it, but despite examples in Photoshop and repeatedly walking through the problem we were having trouble making sense of it. Finally, we realized that the key comparison is the ratios of the images: if height_original:width_original > height_target:width_target constrain by height; otherwise, constrain by width. We actually managed to make an educated guess at the solution before we fully understood the problem, but we did some old-fashioned pen-and-paper work to prove ourselves right.

The ins-and-outs of this backend code and logic no doubt are pretty dry to much of our audience. But this sort of problem is one of my favorite parts of my job: working through the logic of it is completely fun stuff to my inner geek, but more importantly there’s a great satisfaction in knowing you’ve found that killer solution. When you get home, it’s hard to explain to your significant other why spending the afternoon on this one simple function wasn’t a waste of time–heck, sometimes it’s tough to get that across to your boss. But here’s a case where, by taking that time, we were able to both clearly define all the ways we employ content photos on the design-side and create a single function that quickly fits any given photo to those uses. And that not only solves an immediate goal, but we can take that solution with us. We nailed it. And we may never need to think about image sizing again.

But IE stylesheets can only get you so far. When working with a public-facing website design you just need to get it right once: we make sure the structure is flexible and adaptable and forward-looking, but mainly we build to the best standards of the current day. But because development of our backend solution will be continuous (that’s a hint about a major feature, by the way), continuing to tie ourselves to IE6’s sundry limitations would be crippling down the road.

All this is to say that we’ve made a careful and tentative decision to drop IE6 support for the backend web app. The software is seven years old and was buggy when it was released; its replacement is already two years old. Still, requiring a more modern browser felt somewhat risky: about 20% of visitors to the public pages of a small liberal arts college are still on IE6; at a major research university, the portion is slightly higher. But we decided that a fully-fledged rich “web application” can have different requirements than a public site, and now we see that we’re in good company: both Apple in MobileMe) and 37signals (in all their apps) have decided to drop support for IE6. Hopefully this will be the start of a sorely-needed chain-reaction–it’s clear that the catalyst is not going to come from Microsoft, which is not at all interested in pushing the upgrade, even with version 8 on the horizon.

So if you’re using IE6, might we suggest an upgrade to Firefox, Safari, or IE7? Your web experience will be leagues better. And you’ll be able to play with our new toy as soon as we release it, just around the corner.