Game Plan for Ensuring the UX of Revolt is Top Notch
The Mastodon Model and how it can be applied to Revolt
about 2 months ago · 9 min read
Let's talk about the UX of Revolt. It's a topic that's been on my mind for a while now, and I think it's time to start talking to really get the ball rolling.
First, I will preface this: I think the UX of Revolt is pretty good in a lot of areas. For example, the app is snappy and responsive, and the vast majority of UI is perfectly intuitive if you've used Discord or any similar app before. However, there are some areas where I think we can improve, and I think it's important to talk about them, and specifically, how we can improve them.
The Mastodon Model
Mastodon is a social media platform that is very similar to Revolt in a lot of ways. It's open-source, user-oriented, and has a very active community. Unlike Revolt, it's not a chat-focused app, and it uses a decentralized model, where each instance is its own server. Revolt is a chat app, and it uses a centralized model, where there is one server that all users connect to (of course you can host your own server, but they are isolated entities).
Mastodon has many client developers in its community, and they all have their own ideas about how the UX should be. For the entirety of this piece, I will solely be talking about the official web client, and the official iOS/Android apps (which are largely the same UI-wise, with platform-specific design choices).
There has been a widespread misconception in the open-source world that open-source software simply cannot have good UX. This is simply not true, the Mastodon apps are a superb example of how to do UX right. They are intuitive, responsive, and have a very clean design. The web client is similarly great, and it's a joy to use.
However, if you look around some open-source projects, you'll see that the UX is indeed pretty bad. At best, developer-centric, and at worst, downright unusable. This is because the developers of these projects don't have a clear vision of what they want the UX to be. They don't have a plan for how they will ensure that the UX is top notch. Many open-source projects are simply not designed with UX in mind.
Similarly, the users simply want to see new features, and they don't care about the UX. This may work when your project is one-of-a-kind, or when it really doesn't matter if the UX is bad. Most of the users of OSS projects are developers, they don't care about UX, they want the application to work.
UX does matter work when all of your competition are companies that have UX teams full of professionals.
Let's look at Mastodon's Android app repository. In the README.md, we spot the following:
Our goal is delivering a polished, professionally designed and user-friendly app. We proceed according to wireframes provided by a professional UX designer that works with Mastodon gGmbH. This means that any outside contributions that change the app visually must first be coordinated with the UX designer. This can take time.
This is a very important point. The Mastodon team has a clear vision of what they want the UX to be. More specifically, they have a UX designer who works with them to ensure that the UX is top notch.
Revolt, unfortunately, does not have the resources to hire a UX designer. Despite this, we can still learn from the Mastodon team.
The Revolt Model, hopefully
While we don't have a UX designer, we do have a lot of talented people in the community. For instance, I'm not a professional UX designer, but I have a decent idea of how a non-technical user operates.
So, with the power of the community, this is a new model for how we can ensure that the UX of Revolt is solid:
1. There must be a clear vision of what the UX should be.
This includes finding answers to the following questions:
Who is the target audience?
This question is the absolute classic of Marketing 101. It's important to know who your target audience is, because it will help you understand what they want, and what they need. I'd say that the target audience of Revolt is broadly the same as the target audience of Discord before 2021, except less focused on gaming and a tiny bit more technical.
What are the most important features?
This is a question that is often overlooked. It's important to know what the most important features are, because it will help you understand what the user should be focusing on. We don't want to overwhelm the user with too many features, and we don't want to make the user feel like they're missing out on something important. We may want to roll a simple (privacy-respecting) analysis tool to see what features are used the most, and what features are used the least.
Do we focus on what makes us different, or do we focus on what makes us similar to other apps?
If we focus on what makes us different, we will have to make sure that those features are extremely simple to understand. If we focus on what makes us similar to other apps, we will have to make sure that the layouts conform to the expectations of the user.
What do we variate based on the platform, and what do we keep the same?
Many apps have a different UI on different platforms. This is because the platforms have different design guidelines, and the users have different expectations of layouts and looks depending on platform.
For instance, Android relies on Material Design, while iOS relies heavily on Apple's Human Interface Guidelines.
Therefore, the Android app is built around Material Design, while the iOS app should be built around Apple's Human Interface Guidelines.
2. There must be a plan for introducing new first-party features and changes.
We can't just introduce new features and changes without any plan, because then the UI will become a mess the more features are added.
UI and UX should be part of the workflow, a during-the-fact process, not a post-fact process.
For example, new features should stay toggleable in the "Experiments" section of settings until they are deemed stable enough, and the UX is production-quality, to be enabled by default. This will allow us to test the new features in the wild, and see how they are received by the users.
Potentially, an A/B testing scheme could be used to test new experiments, and if they are deemed successful, they can be graduated away from experiments. On the contrary, if they are deemed unsuccessful, they can be removed entirely, and no harm will be done, as it was an experiment after all.
This allows us to keep iterating quickly on new features while not making the app unstable, worse-looking, or harder to use. In addition, users will be better-informed about new features via word-of-mouth, and they will be able to provide early feedback on the new features.
3. There must be a plan for introducing new contributed features and changes.
Revolt, of course, is free and open-source. This means we handle contributions. However, third-party contributions do not always have a good user experience consideration. This is normal and expected, as the contributors are not UX designers and we should not expect them to be in the role of UX designers.
However, we can still ensure that the UX is good by having a plan for how we will handle third-party contributions.
For example, we can have a "UX Review" label on issues and pull requests, and we can have a UX Reviewer who will review the UX of the changes and provide feedback.
Other than that, we can keep external contributions in the "Experiments" section of settings until they are deemed stable enough to be enabled by default. This brings us back to the previous point. It allows us to test the new features in the wild, and see how they are received by the users, while keeping Revolt wide open for contributions.
4. Already existing features must be reviewed for UX.
Many UX and UI corners of Revolt have been cut. This is entirely understandable, as Revolt is still in its early stages. However, we should still review the UX of already existing features, and make sure that they are as good as they can be.
A list of things that should be reviewed should be made, and the community should be encouraged to help out with redesigning the UX of Revolt. There could be a separate GitHub repository for this, with an issue for each feature that needs to be reviewed. Other than that, it could be integrated into the main front-end repository, but it would clutter the issues quite a bit.
5. Improved communication and dialogue between the community and the developers.
Community is key. Communication will help us understand what the community wants, and for anyone else, what the developers are working on. This is the closest thing we have to Google Analytics, the closest thing we have to a UX designer, and best of all, it's free.
However, it is important to note that most of the community is not made of UX designers. When in doubt, it is always better to ask a UX-inclined person inside the development team. We must keep our demographics in mind, most of the community is technical, and their suggestions will be corresponding to that.
Keep in mind the fact that the community is not a monolith. There are many different people with different opinions, and we should not expect them to agree on everything. We should not expect them to agree on the UX of Revolt, either. We should not expect them to agree on the UX of any app, for that matter. Even when there is disagreement, it may turn into agreement a few hours later.
In addition, humans simply hate change. We should not expect the community to be happy with every change, and we should not expect them to be happy with every new feature. Usually, any disagreement will turn into agreement after a few days, when the community has had time to get used to the change.
Revolt is still in its early stages. We have a lot of work to do, and we have a lot of things to improve. However, we can learn from the successes of other open-source projects, and with the power of the community, we can make Revolt an amazing app on all platforms.
That's the game plan, at least. We'll see how it goes.