With the redesign of our current homepage there was the chance to re-evaluate our requirements and make pragmatic decisions filling our needs.
Our previous websites were always implemented in OpenCms since we are OpenCms Solution Provider and contributor. Using a CMS like OpenCms seemed the natural decision and it worked well for several versions of our homepage. But given the amount of work needed to set it up, develop templates and administrate it, was it really what we needed?
A CMS is useful if you have many editors, granular access management with user roles, editor/publisher workflows etc. But we are a team of technically versed people, even our marketing prefers to edit HTML directly instead of rely on a WYSIWYG editor where you don't always know the resulting markup. So OpenCms was a little heavy-weight for our homepage where we didn't need most of it's features.
Finding the right tool for our needs
Result of analyzing the old homepage was that 99% of it was static content. The only dynamic parts were blog aggregation and a contact form. Only for these two it wasn't worth using a CMS or application framework. Yet we still wanted some templating and generate static HTML.
There are many static HTML generation tools. I'm not going into detail on which we looked into, just the solution we came up with. Some evaluation lead to nanoc which is simple to set-up, supports various templating formats, is very flexible, has good documentation and is easy to use.
What about the contact form and blog aggregation? Contact forms that only send an email are no added value to an email address. Analysis of it's usage on the old homepage resulted in that it attracted mainly spam and very few real messages. Blog aggregation is sufficient every few minutes and doesn't need to be live. So instead of dynamically fetching and rendering, it can be done by a cronjob and regenerating server-side.
ERB is part of Ruby's standard library and quite similar to JSP templating in the Java world. All we need is HTML, some meta data replacement from pages (e. g. a title) and snippet inclusion for which nanoc provides a rendering helper.
LESS enables a more maintainable way of writing CSS since it extends CSS by dynamic behavior such as variables, mixins, operations and functions. We chose it over SCSS because we also use Twitter Bootstrap. I think in modern CSS styling you should use either of them to make your CSS maintainable and readable. For example defining our new CI colors as variables or mixins for common button stylings is a good use of these features.
The latest popular layouting/css toolkit for common things like a grid layout. In my point of view the main advantage to older CSS frameworks like 960 Grid System is the use of LESS in Twitter Bootstrap, so for example the grid columns can be altered by changing variables.
Deployment and Publishing
We set-up deployment via Git. Basically a Git post-receive hook calls a shell script that loads the correct Ruby version via rvm and executes a rake task:
The rake task then updates dependencies via 'bundle install', fetches blog posts via RSS and Tweets via Twitter API, cleans up old files and compiles the site via nanoc.
So adding new content or changing some styling is as easy as doing that locally, commiting and publishing by
git push stage
git push live
The advantage of using Git in this way is not just the easy publishing, but also it's main feature: versioning. Content changes can be followed, reproduced and rolled back. For example if you have a marketing campaign and styled your page in X-mas colors, you can do so in a branch and after New Years you can switch back to the usual styling by switching the branch again.