slate blog

slate info has been pretty quiet lately. Unfortunately we’ve had a number of commitments that have kept us from posting. One of the things we said when we made the post about not open sourcing slate is that we’d still like to share how we do things in slate. Today I’m presenting the first article and it’s focused on versioning. We’re actually calling this “History” now in our development version of slate. With the next release we will be getting rid of versions in the current form in favor of this new methodology.

A Quick Overview of What We Had
What features we had had with versions:

• draft and production
• a user could save multiple draft versions
• a user had access to only 5 versions (including draft)
• colored diff
• rollback

What Was Wrong with Versions
I’m not going to cover the good. Draft and a certain safety net are the obvious reasons you’d want versioning.

• the big problem: versions for draft content. users end up only having versions of draft content saved when what we really need are the last published versions
• you could spend an hour on editing content and forget to save content, losing changes
• it took up UI space when the only useful info was knowing who last edited the page and when
• when it comes down to it, versioning is a feature that only advanced users get. everyone else just gets confused with the term and avoids the feature. so why include a feature that people avoid anyway?

See the comments of Discarding useless features for a better explanation. To sum up, our implementation was screwy and we tried too much to be like writeboard when we had slightly different needs. Now would it be nice to have multiple draft versions? Sure. Especially since everyone thinks that somehow, someway they’ll need it. You know, just in case. But after watching, using and maintaining slate for a year it just gets in the way. Great checklist feature that really has no day-to-day usefulness.

So the Move to “History”
So we’ve now sketched out a slightly different take on versions and we’re calling it History. So what are the features now?

• still have draft and production
• will only have one draft available at a time per content area
• will have auto-save for the draft content, think gmail
• save four old production versions to rollback to
• those versions though will now be hidden behind a tab called history thus freeing up some space for us in our content editor pane
• might actually list out a longer timeline for the history of the content area but not allow rollback past the previous 4 (this relies on another feature that we’re working on so it’s note a definite)

The benefits are that this will work more like email which I think people “just get.” It’s made the database a lot simpler on our end to the point where we’ve dropped a few tables. If there’s some reason to add a new feature to content areas then hopefully the simplification of the DB will make it easier to make changes. The “default content” feature gave Chris some fits with the duplication he encountered in the tables.

Draft vs. Production vs. Old Version of Productions: Getting Technical
I think I have this right. It seems really simple so follow along:

• have a table with content and a version number (ok, more then just content and version number but for the sake of simplicity…)
• draft = version number 0
• production = version number 1
• old production = version 2 and above

Um, yeah. That’s it. Pretty easy to increment content up and blast the oldest version which shouldn’t be saved after publishing your draft content. Also easy to check for draft and published content. Chris can chime in with a more technical explanation if it’s required.