liveSTORYBOARD CMS Brief Technical Overview

We have stayed away from too many technical details on our site because making sure sound content management technology choices are made is part of the service we provide.

The following brief technical overview is not meant as a comprehensive guide to liveSTORYBOARD CMS, it is an attempt to anticipate potential common questions we usually get from fellow developers on new projects. Please feel free to get in touch for further details.

Content Repository

liveSTORYBOARD CMS stores content in a single-source XML repository. Different content types can be used in a project for fine-grained content control and rich semantics. A number of content Schemas are provided, including article, FAQ, blog entry, hCard, FOAF, event, job post, news item, etc. Any content schema (XML Schema or RNG) can be used, but not required. Schemas are provided and can be overriden.

liveSTORYBOARD CMS Customization

As the system provides default configurations and templates, more often than not, liveSTORYBOARD CMS users simply modify the CSS and (X)HTML snippets to produce new sites. The methodology we recommend is to use the XSL to create the XHTML structure, then further style it through CSS.

Developers familiar with XSLT can further customize most aspects of the CMS (see How it works/Customizing for more info). liveSTORYBOARD CMS's web interface is targeted towards easy content creation and updates and site configuration. We do not provide online XSLT or CSS editing capabilities because there are so many excellent tools for these tasks (we love Eclipse, TopStyle, but if you are reading this, you probably have preferred tool s of your own anyway.)

Operating System

liveSTORYBOARD CMS runs on Linux servers to avoid having to pass higher costs of other operating systems licensing to clients. That said, liveSTORYBOARD CMS can also run on Windows.

Hosting Facilities

liveSTORYBOARD CMS instances are hosted at Rackspace (http://www.rackspace.com). In many cases, we host client live sites at Rackspace as well - liveSTORYBOARD Inc. is a Certified Rackspace Solutions Partner. We made this choice a few years back because Rackspace has the highest reputation for dedicated hosting services. Their premium pricing is worth it. Rackspace guarantees 99.999% uptime. Rackspace's 'fanatical support' is simply unmatched, amazing and available 24/7 (we have put them to the test many times :). Visit Rackspace.com for more info on the data centers.

Software Configuration and Credits

liveSTORYBOARD CMS uses a J2EE compliant servlet container.

In addition to our custom liveSTORYBOARD CMS Java application, we utilize several Open Source packages for different tasks:

Scalability

Content Backup and Recovery

Any version of any liveSTORYBOARD CMS managed project can be 'checked out' literally in minutes.

Staging and Generation

We stage generations of the project/site for maximum confidence in the live version. At authoring time, a development stage is used (for example, http://dev.domain.com). Optionally, projects can utilize additional stages, such as:

qa.domain.com - a stage to use for quality assurance testing

cert.domain.com - a stage used to place a certified version of the project/site

domain.com - the live version of the site

etc.

Authorized and authenticated users generate a site, a folder, page, topic or content piece to the development stage first. liveSTORYBOARD CMS does not perform any changes directly to a live site.

Static assets are synchronized there as well. When ready to promote to another stage or the live site, the site/folder/page is copied to that stage. Live site promotions can either be automated through SCP / FTP or users can grab a .zip of the whole site and promote manually.

User Management

Registered users are validated against the MD5 encrypted passwords and placed into a general application-wide group. Further, users are grouped by project (site), according to their current context. Project groups can have fine-grained permissions, from the entire site down to the folder, page, topic or content piece level, as well as specific tasks that can or can not be performed at the different site levels.

Separation of Concerns

We strongly believe that content should be separate from presentation and business logic. With liveSTORYBOARD CMS, content can be assigned at the folder hierarchy level to cascade down to child pages in that folder or content can be assigned to pages. Content is stored in topic and subtopic hierarchies, but can easily be reused in multiple locations. Updates occur in a single source, regardless of multiple uses throughout a project or multiple generation formats. More than one content piece can assigned to a folder/page.

The XML configuration and content is transformed to simple/clean/light (X)HTML that is further styled by CSS. We enable and advocate using table-LESS layouts since, semantically speaking, tables are for tabular data and add unnecessary bandwidth demands for large scale sites when used for presentation. For that .001% of users out there, who are still using Netscape 4x, we strive to implement layouts that degrade gracefully.

Exit Strategy

The liveSTORYBOARD CMS team strongly believes in open software standards and liveSTORYBOARD CMS is standards based and output is standards compliant. We have used most large Content Management systems (Vignette StoryServer, Interwoven's Teamsite and others) in large scale production situations in our past lives and found that transferring content and templates between systems is usually very painful. Content migration is the most difficult part of a CMS implementation. It is, therefore, one of our primary goals to provide a clean exit strategy for clients, so that they are never "trapped" in our system.

At any time, liveSTORYBOARD CMS clients have access to all raw assets and/or generation(s) and can generate offline, if they wish. Or, the XML can be transformed to meet the needs of another system. We stand out from the competition on this criteria, through our standards based technology choice, and because, even systems with similar, non-proprietary architecture often do not provide true access to all assets.

More about the Server Side of liveSTORYBOARD CMS

An entire site of, say, 300 pages with 'print friendly' version and external metadata (metadata is stored as Dublin Core (http://dublincore.org/), but can appear in any form) would take approximately 5-10 seconds to generate, depending on current system load.