Let's discuss site platforms & themes


(Michael Downey) #1

A few weeks ago during our @website-wg voice chats, we discussed peoples' thoughts about various tools & platforms for the new ODK web site. There were some decent discussions, but let's quickly revisit them, just in case opinions have changed, or people have had more time to think. I know I have a few more refined ideas which I'll share in a reply. (For those of you who feel strongly about any particular platform, this is your chance to speak up!)

Please share your thoughts here by answering the following 2 short questions:

  1. What technical platform (or "non platform") do you recommend for the new ODK site? This could be anything from a CMS to a collection of HTML files on a web server. Most importantly, tell us why you think your recommendation is the right choice.

  2. Do you see any compelling case for building a custom theme/design template for the ODK site, both short/immediate-term and long-term? A custom design would be considered as creating something "from scratch" as opposed to configuring/"customizing" an existing design with CSS/images.

Please share your responses and any other relevant comments by replying to this topic. As always, thanks for your feedback as we move forward with the web site transition!


(Michael Downey) #2

OK, since I'm here already, I'll start things off. :slight_smile:

  1. While the Drupal proof-of-concept site did a great job in getting us to think about what a new site could be like, my final thoughts is that Drupal as a platform is currently overkill for what ODK needs. It does not seem there is any current demand for any kind of dynamic content inclusion or application functionality. As a result, I'd recommend a static site generator for the foreseeable future.

    • The path of least resisitance, IMHO, would be to consider using Jekyll as a theme engine + GitHub Pages for hosting. GH Pages is a zero-cost way to host the site and would allow the community to use existing permissions, user accounts, and issue trackers to manage the content contribution workflow. Jekyll is by and large the most static site generator for GH Pages, and is widely used elsewhere too, so it would be very easy for a large number of folks to get used to.
  2. I don't think we need to do a custom theme/template right now, especially if adopting Jekyll. There is a very large number of themes available for Jekyll, and the support for many of those themes can be very reliable given the large number of sites using them.

    • Many themes are offer a high degree of customization should we need it, but for now I think with some basic color changes, nice-looking images & screenshots, and the content mainly already assembled during the Drupal site POC, we'll have a very appealing web site with a fairly low amount of effort. We could always invest more time later on a custom ODK theme if there is critical mass in the @website-wg to maintain it.

As a quick example of this recommendation:

I did a very quick mockup of an potential ODK home page using the US Web Design Standards Jekyll theme designed and maintained by 18F, an organization in the US government. You can see the home page at https://downeym.github.io/ and an example inside page at https://downeym.github.io/docs/. Keep in mind these are very basic examples and we'd be including inline images, videos, etc., in the content. You can see example components for this theme at https://standards.usa.gov/components/. Importantly, once I worked through some starting configuration bugs, customizing both the home page and creating new static pages was very fast.

Happy to hear reaction to my recommendations as well as ideas from other folks!


(Hélène Martin) #3

For me, the top goals for the website are:

  • Get new users started quickly
  • Encourage new contributors by making processes for engagement clear
  • Highlight breadth of ecosystem

To serve those goals, I think it's important that anyone can propose website changes and that the edit history is clear. Static site generators are very good at both of those. Tools like Prose make edits easy for non-developers. It's relatively straightforward to set a static site up for translation through Transifex which we use for other tools (http://iilab.github.io/contentascode/technology/translation/).

For maintainability, the simpler the infrastructure the better. Static site generators win there as well as does using an off-the-shelf template.

I'm a fan of Jekyll or Hugo but generally not picky as long as the requirements above are satisfied.

Regarding templates, I feel strongly that whatever is chosen should look current (minimal, punchy text on landing page, clean colors, etc) and that the above-the-fold content should make clear what ODK is for. Beyond that, again not very picky. The 18F template looks like a fine starting point and I like that it's Section 508 compliant (accessibility), mobile-ready and has lots of different visual components to choose from.


(Yaw Anokwa) #4
  1. I agree that we don't need the complexity of Drupal. I'm a big fan of static websites. I've used Jekyll in the past and it's pretty good.

    • I'd also be open to trying Hugo because it's fast and the single binary would get rid of the gem hell that comes with Jeykll, but let's make that v2.
  2. I agree that given the timeline, it's going to be hard to iterate on a custom template. It might be reasonable for the workgroup to pick 3-4 stock themes (Jekyll or Hugo) that look nice and ship that.

    • I think the 18F template is OK, but I don't love it. I'd love to see links to other good foundational templates.

@downey I think you are conflating GitHub and GitHub Pages. We can put the source on GitHub, manage it with permissions, issue trackers, user accounts, etc. Where GitHub Pages helps is with the hosting of the output.

Case in point, both the docs (github.com/opendatakit/docs) and the xforms-spec (github.com/opendatakit/xforms-spec) use GitHub, but the docs output is hosted on S3/CloudFront and spec output is on GitHub Pages. The flaw with GitHub pages is that you can't use HTTPS on a custom domain and I think HTTPS support is important for SEO and a bunch of other reasons.


(Michael Downey) #5

Great point about HTTPS! I'm a big proponent of it as well, enabled and defaulted. When I wrote this I was thinking that GitLab static site hosting does allow HTTPS for custom domains (e.g. through LetsEncrypt) and forgot that GitHub wasn't there yet.

So we'd either have to use a CDN as you say, or deploy the pages elsewhere ... both of which are relatively painless. :slight_smile:


(Jeff Beorse) #6

I am not really a design or branding expert, so I do not have strong opinions in any direction on this. I'm happy to go along with what the community sees as best.

I will say that I like the idea of something that can have its source hosted on Github to make community contribution follow the same channels and procedures that it does for all the other tools.


(Yaw Anokwa) #7

It seems like we've reached consensus on making a Jekyll site where the source is on Github and we publish to Amazon S3/Cloudfront, likely through CircleCI, so that's great progress.

I've had a chance to reflect on the 18F template and it feels very heavy. I looked at some of the users of the template at https://github.com/uswds/uswds/blob/develop/WHO_IS_USING_USWDS.md and it's mostly federal agencies. Not a lot of product websites.

I'm worried it might be more of lift to wrangle it into something simple and so I looked at a few Jekyll/Hugo websites that have permissive licenses and I'd like to offer them up for consideration.

I also liked https://html5up.net/uploads/demos/dopetrope (CC License) because of the clean and responsive design/typography, obvious links at top (for docs, forum, GitHub, etc), clear placements for calls to action, value props (the three icons below the hero) and the various tools (in portfolio).


(Michael Downey) #8

Hey y'all. Thanks Yaw for those other theme recommendations. I have also been poking and testing a few different themes locally this week but ended up getting a bit too sidetracked by GSoC and Outreachy activities, which have stabilized more or less for now.

I am going to try to whip up a couple ODK-specific examples today & tomorrow, then get them up for folks to look at. My goal is to get some feedback from folks and get a complete site load by the end of the month (that's next week!) so we can start February with a specific plan for go-live of the next opendatakit.org version.

For that last bit, it'd be great if I could get either an export of (or access to) both the UW dev site, as well as the old WordPress site just to make sure there's a clean copy of all the data that for processing into static pages. (Outside of their respective CMS systems.) @W_Brunette and/or @yanokwa is that something you can assist with?


(Yaw Anokwa) #9

Check your inbox for the complete dump from the WP website.