Skip to content

GitLab

Closed (promoted)
Created by Stephen Michel@smichel17Owner0 of 6 tasks completed0/6 tasks

Remove roadblocks to frontend development

Problem

We have 3 core problems preventing progress on frontend development:

  1. The site's build process is too slow; "tweak until it looks right" is not possible.
  2. The live site's css is hard to work with before you understand all of it; the barrier for new volunteers is too high.
    • Because of (1), this problem can't be easily fixed using the site itself. We tried, and the result was a half-migration to newer styles and inconsistent site theme.
  3. A prototype was created to iteratively clean up the css (and allow new pages to be created without suffering the site's build times). While that has allowed progress to continue, we have no path for getting that progress deployed on the live site.
    • This means we have a third set of styles to contend with, in addition to the two in use on the live site.

(1) is the most important, long-term. However, it's also the hardest to fix, requiring either skills (haskell) or time (migrating to a different frontend framework) that I do not have. So, I will not attempt to address it here.

Instead, my goal is to fix the other two issues. With good enough solutions, it should be possible to make progress despite the poor build times. Hopefully that will raise morale, create momentum, and maybe even lead to fixing our tooling as well (say, a new volunteer who has the time/skills to help).

Proposal

  1. Iterate on the prototype css to make it easier for newcomers to interact with.
    • @iko has already done the bulk of this work
  2. Adopt the following temporary workflow for updating the live site.
    • Create a new, third template ("skin") for the site, using the prototype styles exactly.
    • To update a page to the latest styles, recreate it in the prototype, then drop it in to the real site with minimal changes (just convert html to hamlet).
    • Repeat until all pages are converted to the latest skin.
    • It is allowed to continue iterating on the prototype css mid-migration. When that happens:
      • If the changes are minimal, just drop it in and replace the newest skin.
      • If the changes require per-page tweaks that will need visual verification, create another new skin and repeat the same process for updating pages to this skin.

This strategy creates some unnecessary work, repeatedly converting pages to hamlet. However, I think:

  • It will still be faster than trying to develop on the live site directly.
  • The conversion will be little enough work that I can personally commit to doing it.
  • Therefore, we should be able to make progress with this workflow (ie, it's functional, which can't be said of our current work-doesn't-flow).

Also, I think we find it easier to continue improving our workflow once it is functional. For example, if all pages have been updated with the method above, then the prototype will include an up-to-date copy of all pages, which will make it easier to move the site to a different framework, if we chose to go in that direction.

Plan

I am taking the week of June 22-26 off to focus on this; my goals this week are:

  • Prototype css cleanup — July 7 update: After spending time on cleanup, I have realized that most pages individually need to be updated to be "production ready" (ie, maintainable). This will surely result in changes to the site-wide css. I don't want to create a new "skin" on the production site that I know will be replaced shortly after. So, my plan is:
  • Update a few production pages to validate the proposed workflow.
    • /about first because getting visibility on our state is important.
    • /auth/* pages next because the prototype versions are such drastic improvements.
  • [maybe] Do some outreach (write a blog post?) to find new volunteers (eg, by sharing said blog post on social media or with people who've expressed interest in the past) who can validate whether the css is more approachable now, and help increase momentum.

PS

This post has been edited heavily as I spent time on it and understand the problems we're dealing with better. Original contents here, for context.

Edited by Stephen Michel