tl;dr: We love using Mobilizon, but need/did some changes for it to fit our needs and are wondering wether these changes would be in scope for the project as a whole.
We are a somewhat losely connected group of people that got to know each other through operating regionally specific Mobilizon instances in germany, that strive to attend to a leftist-alternative audience in the corresponding cities:
- https://fomobremen.info/
- https://fomo.rheinmain.social/
- https://rotes.potsda.mn/
- https://oberlausitz.vonunten.org/
- https://cottbus.vonunten.org/
Calendar platforms like ours are a lot more widespread, but are usually run on self-written software. One of our members created an overview of comparable calendar platforms in the GSA region (germany, austria, switzerland).
We are big fans of Mobilizon as a project and believe that these well-established platforms (some of them exist for more than a decade) could benefit from migrating to Mobilizon.
- Using only one codebase would ensure less maintenance work and better features, also in regards to accessibility.
- Finding and using a calendar platform in a different city would be easier, as the interface wouldn’t change much (e.g. when people move or are on vacation).
- Having a unified set of APIs would make it easier for producers and consumers of the data to build specialized tooling (e.g. a night club could integrate their Mobilizon events into their own Wordpress site).
- Having events available in the fediverse would allow people to follow their favourite event location and see their events in their social media timeline.
At the same time, we had to modify the Mobilizon frontend somewhat heavily for it to be suitable to our needs. The codebase for that can be found here. We see maintaining our own fork as an unnecessary bourden though, which even negates the mentioned benefits of introducing Mobilizon to these platforms. Our favourite outcome would be therefore for mainline Mobilizon to accomodate for our use case.
But let’s first talk about, what exactly that use case would be. In order to work out for our audience, we developed the following key design changes. Many of these are already proposed/being worked on in some way upstream. We try to mention all affected issues.
- Homepage needs to have an identity that is recognizable as a website that is primarily about events in a given region. That means it needs to be somewhat themeable. Marking the website as a Mobilizon instance should be secondary, as the average user is usually not concerned about that.
- Making the logo changeable was already proposed: Feature request: Allow logo in header to be changed (#1087) · Issues · Framasoft / Mobilizon · GitLab
- Ability to theme. Setting a different base color per instance might already help, but custom CSS might be even better. Possibility to add custom CSS/JS to own Instance (#751) · Issues · Framasoft / Mobilizon · GitLab
- Custom name and icon for the PWA, so people can have their regional instance as an app on their smartphone.
- Homepage needs to primarily inform about upcoming events in that region. That is pretty much the only question a user has, when visiting the site both for the first time or the hundredth time: What is going to happen this week? The amount of events per week is usually below 20, so no filtering or categorization is needed.
- An additional calendar view might also help with this goal: Add a calendar view (#1334) · Issues · Framasoft / Mobilizon · GitLab Embed calendar view on other sites (#1114) · Issues · Framasoft / Mobilizon · GitLab
- Display ongoing events in an distinctive way: Prominently display ongoing events in the UI (#1112) · Issues · Framasoft / Mobilizon · GitLab
- Show as many events as possible and let the user scroll.
- The main benefit of a regional platform is that the admins of the platform can decide about which groups are allowed to publish events. This creates a more or less well-defined scope and allows users to maintain expectations about an event to fulfill certain standards, even though they never went to the location before. This is especially useful for people that are either new in a city or suffer from social isolation. That means, that federated events should only be visible on the homepage, if the admins explicitly allowed it.
All of these design changes are already implemented in our codebase. For getting a better feel for what these changes mean in practice, we recommend having a look at https://fomobremen.info/, which is still based on Mobilizon 2.1.0 for now. A wip instance that follows our current main branch is available here.
Additionally to these core design goals we worked on the following adaptations:
- No decorative pictures – We felt like these were too distracting for our use case.
- Two changes to the german translation, that would both make Mobilizon appear less politically conservative, language wise:
- Change the address to a colloquial Du instead of Sie: This is pretty much the norm for interactions online, see e.g. the Mastodon website: Mastodon - Dezentrale soziale Medien
- Use degendered language, e.g. Nutzer:innen instead of Nutzer. While being debated in german society as a whole, usage of this language is pretty much the standard in our audience. Even some government websites adapted to it.
Our question would be now, wether this scope that we developed would be in line with the idea of the Mobilizon project as a whole? If yes, we could start upstreaming our changes, or work on making them configurable, so users of mainline Mobilizon could configure their instance to fulfill our scope. The reason we just didn’t start doing this right away, is because we aren’t sure wether our usecase is actually in line with the goal of the project.
Also looking at the at the announcement, that Framasoft won’t fund the development of new features starting 2024, some of us see us in the position to maybe contribute to the project long-term?
