Proposal for technical approach to redesign

[smit1678]

Right now we're leaning towards Jekyll as the open source framework for managing content and HTML/CSS/Javascript. Below is a short write up of some of the previous conversations about this direction and how we’ll look to handle some of the considerations.

We had started this conversation last year in the tech working group, but it was never summarized or posted. In short, we’re proposing to move to a static-site generator like Jekyll as we redesign the website instead of continuing on Drupal. Open to discussing other static site generators or other considerations.

Why do this?

A core reason is maintenance, usability, and simplifying. The Drupal site remains unmaintained on a HOT server and a goal of HOT in 2018 is to reduce the costs and maintenance overhead for the tools and services we run. Our current Drupal site also presents some challenges when writing blog posts - blog posts take a long time to format. Another goal is to equip and enable volunteer developers to be able to contribute more collaboratively in a more direct manner to the codebase that runs the core HOT website. We also do not use much of the dynamic functionalities of Drupal and the security risks that come from an unmaintained application are not insignificant.

Some considerations we’ll need to address

1. Migrating old content
   • we have a lot of older content - blog posts, project pages that will need to be migrated.
2. Cross-referencing between pages
   • We cross-reference quite a bit across the site. This still can be done with a static site generator quite easily. Related to old content, we’ll need to have a good way to migrate.
3. Other dynamic features
   • Search functionality. Need a good way to search across project pages and blog posts.
4. Blog writing and content editing functionalities
   • Content management: a distributed team needs to be able to post/review/publish content easily in a WYSIWYG editor
5. User accounts: dozens of staff and 100+ voting members
   • Having the ability for staff and voting members able to log in to edit either their profile page or create a blog post is helpful so there isn’t a single admin doing everything.
   • Since we’re leaning towards Github as the location for the source code, many staff and voting members already use their Github account. There are a number of WYSIWYG editors for Github that can be leveraged to provide similar editing functionality.

Other thoughts:

• Missing Maps team has been leveraging a Jekyll based site with a distributed team well. HOT has also used Jekyll for the HOT Summit Website.
• Leaning towards using SiteLeaf to help with content management and tiered access. This will allow users to draft and preview content. Has both a text editor as well as a visual WYSIWYG editor.
• Could also look at leveraging Medium for blog posts tiered access, draft and collaborative editing workflows, and improved commenting and sharing capabilities. OpenAerialMap started using Medium in August: https://blog.openaerialmap.org/.
• Allows HOT to conform to using Github a bit more for tracking conversations which many tools and the tech working group already use.

Next action here: discuss any other considerations and then proposal a path forward with an outline of how we'll structure content.

[pantierra]

Thanks, @smit1678. I deeply agree with all stated here. Moving away from Drupal to a static site generator is a good way, in my opinion. Besides Jekyll (Ruby based) I have also made good experience with Pelican (Python based), but as both are pretty similar, I think it is best to follow the one that people know most about, which seems to be Jekyll.

[smit1678]

Thanks @xamanu, I agree, I looked into Pelican and then also looked at Hugo as another option. I am more familiar with Jekyll and so I lean towards that of course.

I also think there are some interesting opportunities in the future to think about building a remote theme for jekyll: https://jekyllrb.com/docs/themes/. This would allow anyone to tap into the HOT style and bootstrap their own site or simple page with a HOT style.

I think if there are not other major issues then I think moving forward with Jekyll sounds like a good idea.

I don't have a proposal for an initial structure yet but working on that today. We'll be leveraging Collections to organize content types. There are some good updates in v3.7 which includes putting collections into a collections_dir which cleans up the root folder and makes it easier to navigate.

[DylanMoriarty]

Hard agree and glad to see this is on the table for the new site.

For the accounts, I'd be curious how many HOT members actually login to the site to edit their profile after the first time of doing so.