Complete Revamp (proposal)

[richardolsson]

This is a proposal to revamp Organize entirely, from scratch. In that way, it's similar to zetkin/www.zetk.in#277.

TLDR

We (mostly myself) began working on Organize in early 2015, almost six years ago. Since then, the team has grown and together we have learned so much from actual use of the product, and relevant technologies have evolved.

I believe a complete revamp is the way to go both for technical reasons and to improve UX. Examined separately they are probably good candidates for incremental improvements, but together they warrant a complete revamp.

A technical case for revamping Organize

Stack/libraries

While the choice to go with React/Flux was the right one, it was still very early when that choice was made in late 2014 (React 0.12). So much as changed in the React ecosystem and concerning best practices since then. We have tried to stay up to date but mostly failed, and to migrate the current code base (React 15) to React 17 would be a huge hassle.

On the server side, we've upgraded Node sporadically, but always remained a few versions behind the current LTS version. Some upgrades have resulted in bugs.

Language

At the time when we started development, JS/ES was evolving extremely rapidly and people were experimenting with all kinds of things. Since then the language has evolved immensely and stabilized. Some of the features that we used have still not made it in (e.g. decorators) while some that we chose not to adopt widely are now commonplace (e.g. ... object spread syntax).

This is also the right time to move to TypeScript. When we started, there was no consensus on what the right choice for scalable javascript (e.g. type safety) would be. Since then, TypeScript has emerged as the obvious choice.

Moving to TypeScript means that we will have to continue relying on transpilation, but at least the ecosystem for transpilation is much less convoluted today.

Development practices and tooling

We first used gulp and browserify, but then moved to webpack to build front-end JS. We kept our old system for SCSS though, so that still relies on gulp, as does server-side transpilation (which is mostly redundant nowadays, but required due to some minor language features that still haven't made it into the standard).

As part of a rebuild we should move entirely to webpack. We should also implement linting to enforce a common code style, and testing where it makes sense.

Utilize the modern web

The new Organize should be a PWA with reasonable support for installability, offline access, notifications et c. It should be mobile first (although a lot of features will remain more useful on bigger screens).

A UX case for revamping Organize

Organizers have been using Zetkin for close to four years, and we've learned a lot in that time about what features are actually used and how.

Task-driven over data-driven

We used to think of Zetkin as a set of distinct tools, "the campaign tool", "the phone tool" et c, based on how the data was structured and the order in which we introduced them. This is reflected in the Organize UI through it's dashboard, sections and panes. Much of the interface is glorified CRUD of different type of objects (actions, call assignments, surveys et c).

As more and more features have made it in, these lines are blurred. Organizing a campaign entails planning actions, but it also probably involves setting up a call assignment to mobilize. If you want to do that, you might want to keep track of responses during phone banking through a survey, so you have to set one of those up as well. This is distributed in three different sections, until you want to start searching based on participation, which introduces a fourth section.

With recent features like Views, most of the work that goes into organizing an event might be done in a View and not in the event calendar (Campaign section) at all. This is entirely counter-intuitive.

Instead let's reimagine the Organize UI from the perspective of tasks or goals. What does the organizer want to achieve in Organize?

Opportunity to teach

Re-designing Organize based on user goals also gives us an opportunity to design a UI based on best practices, which can teach these practices to the organizer. Helping organizers improve methods has always been a big part of Zetkin, but not in the UI. There is nothing in the UI for planning a campaign telling you that you probably want to set up some sort of workflow for mobilizing.

Consistent, mobile-friendly and accessible UI

For some reason (probably ecosystem immaturity) we never used a component library in Organize. We've developed some reusable widgets and form logic on our own, but the quality is not great.

For the revamp we should pick an existing UI library. Besides easing development and making things more consistent, this will also allow us to make the UI more accessible and mobile-friendly.

Summary

Here, again, are the most important reasons to completely revamp Organize:

• Use most recent (more stable) versions of everything
• Move to TypeScript
• Improve development experience with testing, linting and consistent tooling
• Design the interface based on user goals
• Use a UI library/design system for consistent, mobile-friendly UI

[richardolsson]

See zetkin/www.zetk.in#277 (comment) on incorporating a revamped Organize into the Activist Portal.

[richardolsson]

These are two old (but still relevant) article on rendering strategies and "Application Shell Architecture" that can be considered for a PWA Organize revamp:

• https://developers.google.com/web/updates/2019/02/rendering-on-the-web
• https://developers.google.com/web/updates/2015/11/app-shell

A library to help with this i Google Workbox which can be run as part of NEXT.js (as discussed in zetkin/www.zetk.in#277).

[richardolsson]

This is happening in the app.zetkin.org repo.