Static Site Generators Research
Motivations For Converting To SSG
reduce system admininstration burden
security, updates, etc
very few pages don't need a CMS (e.g. clinic: 4 pages)
Candidate Sites
Site | Current | Convert to SSG? |
|---|---|---|
Joomla | want to move away from Joomla, but need ease of updating (Pat, Jutta, etc) | |
CMS Made Simple | ||
Hard-coded; github pages | ||
Confluence | use sphinx/restructured text or something like it? might need longer discussion | |
MediaWiki | probably not | |
MediaWiki | spam a problem; want ePub exporting options; community contribution was the intention | |
Confluence | ||
Wordpress | partner contribution is a goal | |
Wordpress | see above | |
PHP Schedule It | needs server back end | |
Wordpress | post this one to the list for discussion | |
CMS Made Simple | need to find out maintenance requirements (who edits, how often...) (Jan? Joseph?) | |
Wordpress | (ask Jan? Jorge?) | |
Mediawiki | Jan? Jorge? | |
Drupal | ||
Wordpress | ||
Wordpress | (alternative is to create a VideoPlayer drupal plugin) | |
Drupal | double-check with Jan | |
Drupal | Jan? | |
Drupal | double-check with Jan | |
MediaWiki | check with Jutta - done √ Jess 3/12/14 – this site can be taken down as long as links are updated on inclusivedesign.ca and content is placed there, somewhere | |
Wordpress | ||
MediaWiki | with password protection; Jan? |
Selection Criteria
Criteria | Reason |
|---|---|
Easy enough for step-by-step instructions | Non-experts may be asked to add content. The benefit of using a CMS like Wordpress is that anyone can edit content with a WYSIWYG editor and publish their changes. Ideally we should offer a similar experience to those who prefer not to use a text editor and Git client. This may be less important; we might be willing to sacrifice ease-of-updating in favor of ease-of-maintaining. We'd just pair non-techy editors with tech people. |
Be able to handle complex site navigation; breadcrumbs, table of content, sitemap, etc. | We would like to be able to use it for documentation. It's possible that with simplified information architecture for the docs, complex navigation might not be such an issue. |
Should be able to easily support plugins and integrate with custom content | Our documentation site will need to support structured content, as well as directly hosting demonstrations of our components inline in the site itself |
Easily extensible | The system we select should have some kind of plugin or extension mechanism that will easily allow us to fill in features that it might not have, but that are important for a particular site or context. Ideally this should be relatively well-aligned with Infusion so that we can use our tools and then use these extensions that we build as case studies of the power of Infusion, etc. |
Less intrusive templating system | Although we're willing to live for the medium term with a more technical workflow, in the long run we will want to support users with some kind of simple GUI editor. There are a lot of GUI editors (e.g. CK Editor, Aloha, Content Editable, etc.) that are capable of authoring ordinary HTML. If the system we choose doesn't require large amounts of custom in-markup code to create pages, this will make it easier for us or the generator's developers to add GUI tools in the future. |
Smooth workflow with Github repositories and easily hosting sites on our cloud infrastructure | While we aren't big users of Github Pages, we are really into Git and Github. Any tool we use should work smoothly with Git, and allow us to create git hooks that will automatically publish changes to live site. Similarly, the solution we choose should be easy for Avtar to provision a base VM image for, allowing any of us to quickly spin up a live VM from our cloud dashboard and manage our own sites as needed. |
Be able to handle news or blog style content easily | Project sites are updated periodically with news content |
Templating | Make it easier to create multiple pages that have a desired layout |
Sufficient power for layout | Some content has complex layout; simplified languages like Markdown, etc. might not be able to handle it |
Open Source | Preferably something open that has an established community. This will help us if we encounter any issues a long the way, as well as provide a means for us to fix issues ourselves if need be. |
Be able to define a default theme | We should be able to have a default theme, that can be used when we need to create a site quickly. This way we can maintain a professional and consistent look. |
Full Text Search | Sites with a lot of content might require full text search. Would it be acceptable to use an option like Google Custom Search (ads involved) instead of maintaining our own search indices? |
Node.js-based | Ideally, we'd like to use a system that is built with Node.js. There are a couple motivators for this, including the extensibility point above. A static site generator written in Node.js could be easily extended with features written using Infusion and other tools we already use every day (e.g. Grunt). Even more interestingly, we might consider the long-term possibility of integrating static site generation features into Kettle, so that developers could easily deploy blended sites that consistent mostly of static HTML but also include JSON feeds or some dynamically-generated pages. Imagine, for example, of a static site that contained demos for Infusion, but also allowed users to submit Github links to cool demos they'd created of Infusion. The other advantage of a Node.js process is that it's tooling we're familiar with and can anticipate. We are increasingly comfortable with things like npm and managing packages, and the new Grunt-based Infusion build scripts mean that a working Node.js instance will typically be available on most Infusion developers' machines already. Of course, if there was an insanely compelling solution written in some other language or platform, we'd consider it. |
Support for Twitter feeds | Several of the sites we're considering converting include Twitter feeds. |
Evaluation Notes
Inspiration
http://developmentseed.org/blog/2012/june/25/prose-a-content-editor-for-github/