slate manifesto

"Manifesto" is not exactly the best name for this particular article but, hey, it's catchy. What I want to share are the guiding principles behind both our development of slate to this point and what will drive the future direction of slate. First, though, we should share some background to allow you, the reader, to better understand a) why we think these particular issues are important and b) where future development of slate will primarily geared towards.

slate is being developed at West Virginia University, a large public university. It is being developed to support the work of a centralized web development group in their efforts to help University departments and organizations manage their web sites. Pure "one-off" projects are eschewed for projects that will help more then one group. At the same time we want to push the technology we work with and craft the absolute best product.

Another important caveat, we have bought into "Getting Real" by the folks at 37signals. We're scratching our itch and realize whatever slate morphs into it's not necessarily for everyone and we're not going to create something that is.

So with that background, here are the guiding principles of slate:

It's All About Traditional Web Sites
First and foremost slate is about creating and managing "traditional" web sites. Not blogs, traditional sites. We're talking the old-school static HTML sites. These are predominant here. Ah, but why create a CMS when Dreamweaver and/or Contribute can take care of our "problem"? Users want more dynamic features (e.g. calendar). We don't want content to go out-of-date (e.g. faculty listings). Users want to edit content from anywhere (currently SFTP is limited to on-campus).We want to limit redesigns to literally that, redesigns.

One Install to Rule Them All (aka Multi-Site Support)
From the outset slate has been designed to a) support multiple sites and b) allow users to manage all of the sites they're related to through one interface. Easy on the user. Easy on us.

Limit Changes to Current Site Creation Process, Allow Design Flexibility, Limit Template Changes
We're currently in the business of creating Dreamweaver templates for our users. That works out pretty well for our staff. Both from a process and design standpoint. At the same time we, the developers of the CMS, don't want to rewrite the templates in some sort of slate-only templating language. We lean on Rails partials and keep all dynamic additions to a template to one-liners.

Don't Reinvent the Wheel (at Least When it Comes to Search and Stats)
We can't beat Google in either category. We have an on-campus Google Search Appliance box for providing search results and utilize Google Analytics for statistics. The latter is not perfect but way better and more user friendly then whatever we would have written or relied upon. So two things that most likely will never be written into slate by us.

Workflow Doesn't Work
This is one of the checkboxes that will probably always be left blank when comparing slate to other CMSs. When reviewing this particular feature our feedback revolved around two uses for workflow. A. Site admin wanted to let a contributer update content but review it before it got published. B. Infrequently they wanted an outside source to review content before publishing. A. is easily handled just by our normal permissions. B. Simply put we don't want to waste cycles trying to figure out how to do it considering it'll only be used once a year. Therefore, no workflow in slate.

Lean On and Work With Centralized Resources
The lovely acronym EAI or Enterprise Application Integration. We're trying to play nicely with several applications around campus to make it easier for users to share content with one another. We're also relying on central sources for our credentials though slate does also support "local" accounts for our future plans regarding collaborative web sites.

The following are two principles that we haven't exploited yet but are in the works:

MVC at the App Architecture Level (or What Led us to Spaces)
Our first priority with slate is to create a CMS for traditional sites. Once we've finished adding on the dynamic features (e.g. calendar) we don't have to necessarily limit them to the traditional sites but instead expand into collaborative or personal sites as well. It all comes down to how you use the V in MVC. The model and controller are the same across all sites you can create with slate but all you do is modify the view to change the "feel" and type of site you're displaying.

Email as Interface
This is aimed squarely at collaborative sites. No one wants to check-in a site all the time to either get an idea of what is going on or to add information to it. So use the one thing that people love to use, email!

Any questions or issue email me at slate@mail.wvu.edu