Activist Portal revamp (proposal)

[richardolsson]

The activist portal is now a few years old and we have started discussing a re-design based on learnings from the past few years, as well as all the new considerations that will be making it's way into Zetkin as part of the sub-organizations feature that we are currently working on.

This issue is a place for discussing the high-level direction of these changes, and to collect inspiration. There are several smaller issues concerning different aspects of the re-design, and more will likely be created.

Examples of more specific re-design issues:

• Single-action pages, Single-action pages #267
• Past actions, Past actions #259
• Upcoming actions/campaigns in org pages, Upcoming actions/campaigns in org pages #152
• Contact information on org page, Contact information on org page #151
• Organization summary on org page, Organization summary on org page #150
• Find actions on map, Find actions on map #105
• Organization list, Organization list #79
• Filtering actions by proximity, Filter actions by proximity to other location #271

Other ideas and aspects to consider have included:

• Finding/discovering organizations
• My Page/feed re-design (for large sets of actions/events)
• Navigate between related organizations

[richardolsson]

@jensborje has started sketching out some wireframes for the "home page" and organization pages (UI in Swedish):
https://www.sketch.com/s/1125a4eb-62d9-48c4-81e4-3e3fc84936d8

[richardolsson]

Some thoughts about development/technology strategy.

Roughly 1% av our users (past 6 months) use legacy web browsers like Internet Explorer. Maybe this is the time to stop catering the UX to that user base? Basic functionality should probably still work without JS though, so I'm not actually sure what this would mean in practice.

Another aspect which we should implement is code splitting. The JS bundle is really big (although not as bad as in Organize) and it would probably be a big optimization to split it into several bundles.

One way of doing this is to think of the activist portal as multiple smaller apps with individual entry points, instead of one big app. Registering, managing your user preferences, exploring events and navigating organization pages are probably three very different flows which do not need to have perfect SPA-like transitions between them.

At the same time, we should take this opportunity to fully adopt PWA practices like local storage, installability and service worker offline availability.

[richardolsson]

Here is a list of component/UI libraries that we should investigate. Feel free to add more!
https://docs.google.com/spreadsheets/d/1cqzIY8DdThtAjVby-kh-yZTmAmc4zkRid-B7NM_WWEM

Adopting a robust and sustainable UI framework is even more important for a future Organize revamp, but lets start exploring it already (and replace the need for most of zetkin-common).

[richardolsson]

Consolidate Call, Organize and Activist Portal?

As suggested recently on Slack, I am proposing that we build the new Zetkin Activist Portal in such a way that Call and Organize can be integrated into the same app.

Motivations

Less architectural complexity

Running all three user-facing front-ends in a single app will make the architecture less complex. Here are some ways in which this is relevant:

• We could run the app on a single server without the need of reverse proxying.
• We could more easily use a single set of OAuth client credentials.
• It would be easier for volunteer developers to get up and running with all relevant front-end code at once.

Easier maintenance

With a single front-end, there is only one codebase to keep up to date with dependencies, front-end issues and pull requests only need to exist in a single GitHub repository et c.

The zetkin/zetkin-common library exists to share some components between the three front-end apps, especially www and call. The need for this would go away entirely if we run everything within a single app.

New features possible

This would make it much easier to implement features like in-context editing. For example, a user which is authenticated at level 2 (2FA) could be allowed to edit organization information on the public organization page itself, instead of in a dedicated administration area.

Consistency

It would be much easier to reach and maintain consistency, both in user-facing aspects of the app (UI/UX) and across the codebase.

Challenge: Avoid bloat

The main set of risks come from a combined app being a much bigger code base. Measures would need to be taken to avoid bloat. Code splitting will be made even more important. Perhaps a framework like NEXT.js could help us here.

[richardolsson]

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