Skip to end of metadata
Go to start of metadata

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

SiteCurrentConvert to SSG?
idrc.ocad.caJoomla(question) want to move away from Joomla, but need ease of updating (Pat, Jutta, etc)
www.fluidproject.org

CMS Made Simple

(tick)
floeproject.orgHard-coded; github pages(tick)
Infusion DocumentationConfluence(question) use sphinx/restructured text or something like it? might need longer discussion
wiki.gpii.netMediaWiki(warning) probably not
handbook.floeproject.orgMediaWiki(warning) spam a problem; want ePub exporting options; community contribution was the intention
wiki.fluidproject.orgConfluence(error)
inclusivedesign.caWordpress(question) partner contribution is a goal
dev.inclusivedesign.caWordpresssee above
booking.inclusivedesign.caPHP Schedule It(error) needs server back end
fluidproject.org/blogWordpress(tick)(question) post this one to the list for discussion
aegis.idrc.ocad.caCMS Made Simpleneed to find out maintenance requirements (who edits, how often...) (Jan? Joseph?)
mobile-accessibility.idrc.ocad.caWordpress(tick)(question) (ask Jan? Jorge?)
wiki.mobile-accessibility.idrc.ocad.caMediawiki(question) Jan? Jorge?
snow.idrc.ocad.caDrupal(error)
deep.idrc.ocad.caWordpress(error)
snowvids.idrc.ocad.caWordpress(tick) (alternative is to create a VideoPlayer drupal plugin)
adod.idrc.ocad.caDrupal(tick) double-check with Jan
stretch2.idrc.ocad.caDrupal(question) Jan?
websavvy.idrc.ocad.caDrupal(tick) double-check with Jan
wiki.inclusivedesign.caMediaWikicheck 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
clinic.idrc.ocad.caWordpress(tick)
bell-community.idrc.ocad.caMediaWiki(tick) with password protection; Jan?

Selection Criteria

CriteriaReason
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 contentOur documentation site will need to support structured content, as well as directly hosting demonstrations of our components inline in the site itself
Easily extensibleThe 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 systemAlthough 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 infrastructureWhile 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 easilyProject sites are updated periodically with news content
TemplatingMake it easier to create multiple pages that have a desired layout
Sufficient power for layoutSome content has complex layout; simplified languages like Markdown, etc. might not be able to handle it
Open SourcePreferably 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 themeWe 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 feedsSeveral of the sites we're considering converting include Twitter feeds.

 

Evaluation Notes

 

Inspiration

https://readthedocs.org/

http://www.openstack.org/

http://developmentseed.org/blog/2012/june/25/prose-a-content-editor-for-github/

 

 

  • No labels