Use a static site generator for the CoTech website and host on GitHub Pages
Chris Lowis (Go Free Range)
Public
Seen by 69
Howdi folks,
We (Chris, Chris and James at Go Free Range) would like to propose that we move our CoTech website to Jekyll and host it on GitHub Pages. Jekyll is a static site generator and GitHub Pages is a free host for static content.
While we appreciate all the effort that's gone into our current WordPress setup we’re concerned that the complexity makes it harder to make changes (to the site as well as the content) than it needs to be.
To help those unfamiliar with Jekyll to understand this proposal we’ve ported the look-and-feel of the existing CoTech website and some of the content. You can see the generated site at https://cotech.github.io/statically-generated-website/ and the code at https://github.com/cotech/statically-generated-website.
This prototype gives us confidence that changing to a static site generator is technically possible and that the result will be simpler than our current setup.
Advantages of switching
- All our site content (text, data and media) will be under version control
- Changes can be made using the GitHub user interface
- Changes can be discussed using Pull Requests (avoiding the current wiki/Loomio process)
- Deploying becomes as simple as pushing commits to GitHub
- The site hosting is free
- Local development only requires Ruby
- No servers to manage, security updates to apply, or databases to backup
- Switching to an alternative static site generator is relatively easy
- Switching to an alternative host is relatively easy
- Less moving parts mean that it's simpler overall
Disadvantages
- We lose the existing Wordpress admin interface for editing data
- Users will need (free) GitHub accounts to make changes
- Knowledge of Liquid required to make logic changes
Next steps
If we turn this into a proposal and it is accepted we’ll commit to porting the existing content over to this system so that the transition is as painless as possible. We’ll also be happy to help anyone in the network learn how to contribute using git and GitHub. If you’re interested in the kind of things that need doing next we’ve added some information to the README.
We'd love to answer any comments or questions before we make this into a proposal.
Shaun Fensom Tue 4 Jul 2017 5:55PM
@asimong ha! Loomio not good at holding thread context. You said: “Is Wordpress a good solution to handling transactions? I wouldn't have imagined so…” so I said “No, but why change twice?”
Simon Grant Tue 4 Jul 2017 6:21PM
You ( @asimong ) said: “Is Wordpress a good solution to handling transactions? I wouldn't have imagined so…” so I ( @shaunfensom ) said “No, but why change twice?”
I still agree :) If we might want some kinds of transactions in the future -- perhaps in the sense of people identifying with appropriate use cases as adding real value -- then if we can move to a technology that supports such transactions, great, other things being equal (which they never are, of course, but anyway...)
Graham Tue 4 Jul 2017 8:58AM
I'm in favour of sticking with the current set-up until such time as a compelling argument is made to change (and by that I'm saying that i don't consider the arguments made thus far to be compelling). The biggest single issue surely is what the plans are for the future, as others have hinted at.
Right now this feels like a solution looking for a problem. In my world about 1000x more people know how to fumble around in Wordpress than even know what Github is.
Chris Lowis (Go Free Range) Tue 4 Jul 2017 9:09AM
There's some great feedback here and we appreciate it, thank you!
To address Graham's point: there's certainly a concrete problem we're trying to solve here which is that we had some spare time to contribute to CoTech and make it easier for people to find out more about our network (by moving some wiki content to the site and adding some new information pages) and the current system prevented us from doing that easily. Developing, deploying and modifying the current system is currently very difficult.
It sounds as if there's some broad consensus that static pages are easier to host and deploy (hosting static HTML is commoditised to such an extent that Github for example offer the facility for free). This gives us less support, security updates and maintenance to worry about/donate time to/pay for.
It seems that the principle objection is the ease of adding new content to the site. I note that some of the current information is out-of-date - so I'd need some more evidence to convince myself that we've already cracked that problem.
What can we do to convince people to adopt this proposal? I think we've learnt that using version control software (and github in particular) isn't familiar to some members - it's such an important part of our daily work that we took that for granted.
We've made some suggestions of how people could edit the content using the github user interface - would someone who is not familiar with that approach be willing to test that in the prototype with and give some concrete feedback?
We would be happy to give a short video demonstration if it would help.
Nick Sellen Tue 4 Jul 2017 9:15AM
It seems that the principle objection is the ease of adding new content to the site
The other key point was which features the site should have in the future, and how they would be implemented in each of the solutions.
Chris Lowis (Go Free Range) Tue 4 Jul 2017 9:16AM
Yes - I think there's a meta-discussion here about approaches to building software. The idea of anticipating future requirements now and adopting a solution today that can cope with those anticipated requirements versus using the simplest possible solution to today's problems and iterating on it as requirements change and we have more information. I'd say Go Free Range favour the latter approach in general. I don't want to take this discussion off on too much of a tangent so I haven't addressed that issue in detail.
Roy Brooks Tue 4 Jul 2017 9:36AM
From a (purely) comms standpoint, seems to be a 'function before form' thing going on. It's our (general) public-facing website. So, assuming we want to 'say' more than we already do (do we?) ... isn't it better to decide what that is/will be ,then decide how best to do it?
Ignore if I've the wrong end of the stick...
Nick Sellen Tue 4 Jul 2017 10:07AM
@chrislowis I agree with your approach to development. Right now though (with a site already running) the simplest possible solution is to do nothing at all :)
James Mead (Go Free Range) Tue 4 Jul 2017 2:17PM
I've put together a sequence of screenshots demonstrating:
- A GitHub user creating a pull request to add a new cooperative using only the GitHub user interface
- The pull request being merged
- The changes automatically appearing on the website
I purposefully made life more difficult for myself by using a user who is not a member of the cotech GitHub organisation and by adding two files (content and logo) in one go.
I can see how this could be a bit daunting for those not familiar with GitHub and it is clearly slightly more complicated than using the Wordpress admin interface. However, there are lots of advantages to working like this and whether or not this proposal is accepted, we (Go Free Range) would love to help members of CoTech learn more about how to use GitHub and/or git to collaborate on stuff.
Do let us know if you have any questions.
Simon Grant · Tue 4 Jul 2017 3:37PM
Sorry, @shaunfensom -- no what? I lost context. I don't suggest changing web technology more times than needed. The only disadvantages I can see for learning twice are time and motivation. All I'm suggesting is that we don't base our choice of technology mainly on what people currently know, as we can learn, and learning can be useful in other ways.