Hi everyone, We are in the middle of updating the floeproject.org website and in the process started to have a discussion about transitioning that website from a Drupal instance to a static site (static site being a site written in plain HTML and CSS, with no databases or PHP).
The advantages to using a static site are (but not limited to): - less software to maintain and less security issues - source documents and content can be version controlled using a code repository like github - platform agnostic - since the site is primarily plain HTML and CSS, it can be moved and migrated easily, and doesn't depend on any software platform. The primary disadvantages is a slightly more complicated route to modify and update content and less interactive features like native comments system, and wysiwyg editors (although there are reasonable alternatives or equivalents). For floeproject.org, a static site makes sense because the site is rather small and the content doesn't change often. This raises some issues regarding the floeproject.org website update: 1. Should we do this floeproject.org update using Drupal now and consider the static site conversion later? To do the update in Drupal will take about 1 day. To do the work using a static site (assuming all the infrastructure / processes are in place) it should take maybe 2 days. 2. If we go a static site route, we'll need to set up the infrastructure for generating static sites (kicking it old school using Win95 Notepad isn't going to work). We would have to choose a static site generator (like DocPad, Jekyll, or Octopress), decide on a repository for the content, and then create a process in which the content from the repository is deployed to a host. Personally I have been using DocPad (http://docpad.org/) which supports text formatting (markdown), templating (eco and jade), compilers (stylus, less, sass, coffee), minifiers, deployers (for github pages, AWS, Azure, dropbox), and automators (grunt). DocPad also runs on Linux, Mac OS, and Windows unlike other static site generators which primarily support Linux / Mac. The bigger implication of this discussion is that it can have an effect on other project websites such as fluidproject.org, and even documentation sites like Infusion documentation, design handbooks etc. Where it makes sense, I think it's good to reduce the number of CMSes we are maintaining and patching. Perhaps the floeproject.org website would be a pilot? Thoughts? - Jon. -- *JONATHAN HUNG* INCLUSIVE DESIGNER, IDRC *T:* 416 977 6000 x3951 *F:* 416 977 9844 *E:* [email protected] *OCAD UNIVERSITY* Inclusive Design Research Centre 205 Richmond Street W, Toronto, ON, M5V 1V3 www.ocadu.ca www.idrc.ocad.ca
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
