Some thoughs on Anti-Feature UX on F-Droid
A while ago, F-Droid rolled out a new anti-feature in their repository. It's called "Tethered Network Services" and informs users of whether an app is dependent on access to a single centralized web service. E.g., a YouTube app won't work without access to youtube.com. There are many reasons to consider this before installing an app. E.g., some users might want to avoid GAFAM; some may live in countries where, where US based services are censored; etc.
Organic Maps is a FOSS map/navigation app with exceptional user experience. When the Tethered Network Services anti-feature was rolled out, it happened to get assigned to Organic Maps, because they provide a custom download service for map data. Due to the way F-Droid's app is handling new anti-features, it effectively removed Organic Maps from search results and browsing in F-Droid's app for the vast majority of users. As you might imagine, I think that's quite a frustrating situation.
F-Droid app has a feature for hiding apps based on anti-features. At the very least there are some very vocal users who love this feature and I think hiding NSFW apps is also broadly accepted default. It's implemented as an allow list. This means that, when F-Droid gets installed for the first time (or when users do a full data reset) the allow list will be populated with some default values. Then when there's a new anti-feature the F-Droid app doesn't handle that and apps with that new anti-feature will be hidden.
Another important thing to acknowledge here is that anti-features are dynamic. So every repository can make up their own set of anti-features however they see fit. So while this is in theory a great feature for informing users, apps with custom anti-features will not show up. The anti-feature hiding functionality can be configured in F-Droid app settings. It is based on a hard-coded list of anti-features and groups all of custom anti-features into the 'other anti-features' category which are disabled by default.
This made me think and come up with some UX research question:
- Are users aware that some content is hidden when searching/browsing F-Droid?
- Do users understand what exactly is hidden from them when searching/browsing?
- Do users understand how to change what's hidden from them when searching/browsing?
- What do users expect to be hidden and/or visible by default in search results?
- Do users trust F-Droid App to provide default settings for filtering their search results?
- or would users prefer to be guided to pick their own preferences?
I don't really have stake in the design process of F-Droid, all I can do really is raising questions and pushing in certain directions. So I think I'll bring this up and see what will happen.
However since I think I've got good intuition for UX design, I think it's fun to do some predictions about these questions. It might be fun to come back in a couple of years and see what I got right or wrong:
I think the vast majority of users is not aware that some search results are hidden. So I think the sane approach here is to hide as little as possible.
Since I don't think that users expect their app to censor search results, they also have no concept of what's hidden or not.
I do think quite a few users are capable of changing Anti-Feature visibility settings. But again I'd expect that the majority of users don't fully grasp this feature as presented in F-Droid App right now. I think reworking the "Include Anti-Features" settings would help maybe a quarter of users but I'd expect a substantial fraction of users to be overwhelmed buy that feature. In F-Droid App settings I'd rename the "app compatibility" section to "content". I'd rename "Include Anti-Features" to "Hide unwanted Anti-Features". I'd also make "Hide unwanted Anti-Features" displaying Anti-Feature Icons, short descriptions of the Anti-Features and most importantly short examples of what those Anti-Features mean in practice.
I think that a substantial fraction of users will either conscious or unconscious expect that search results are filtered for NSFW content ant nothing else. I'd also expect that there's a non-negligible fraction of users that'll expect no filtering by default. An easy fix would be to add a 1 click solution for getting full search results when filtering is active.
I think the vast majority of users will prefer to get sane defaults for search filters (NSFW only) instead of having to make a choice there. Overall I think the right place to make those kind of decisions is a repo inclusion policy. Users with special need then can setup their own filters, but by default getting mostly unfiltered repo content is making things easier for everyone involved.