Continuing the discussion from Exploring the idea of using Discourse as a badges frontend — the backend implications:
As you may have noticed, I conducted an experiment in mirroring all of the badges from Fedora Badges to here. See: Magical Experimental Fedora Badges Topic!. Here’s some notes from that!
I think this can actually work. The current badges site is really slow, and discourse isn’t, even with a similar number of badges. (Getting list of badges for
mattdm via JSON here: about 140ms. From badges site, about 35 whole seconds.) The UI isn’t perfect, but many things could easily be done with Discourse theming. Some more sophisticated things may require a plugin or code changes, but nothing looks really like a huge blocker.
You can see the list of all badges here: Fedora Discussion: Badges.
Compare to the current badges site: Fedora Badges: Badge index.
Note that the Discourse view can be divided by categories. I just didn’t implement that. Also, it puts a check mark next to the badges you have earned, and a count of the overall number of that badge awarded.
The current Index has this feature; Discourse does not. If we want this, we’d have to figure something out.
See for example: badges for mattdm on Fedora Discussion vs badges for mattdm on Fedora Badges. Here, the Discourse version just shows one big list. I think we’d want some work here to organize and categorize them better.
It does let you pick favorites, which show on your “user card”. (Click on my avatar image on this post to see an example.)
With Discourse, it is possible to allow badge names (on a per-badge basis) to be used as a “title” which shows up next to the user’s name. That… could be fun?
This is pretty key to the whole gamification thing. The current badges leaderboard is fairly rudimentary, but does the essential thing of showing who is “winning” for both all time and for various recent periods, and showing your own position.
Discourse also has leaderboards — see “Users” on the hamburger menu:
But unfortunately badge count isn’t an option, and it’s not completely trivial to add it. (I looked at the code and I don’t think it’s super-complicated either, but it’s not just like a “oh, add a value here” thing.)
Also, I see that it would be nice to filter out bots like “coprservicer” from the list, while I’m looking for features.
This is somewhat ironic given the work I’m planning to move discussions on this site to be organized by tag, but — although they’re presented in groups in the UI, under the hood, Fedora Badges can have multiple tags, while Discourse badges just get one group. I don’t think we’re really using that heavily (for example, the badge index and user page just show the first tag… I think it’s basically only functionally meaningful for search).
On the other hand, Discourse badges can be grouped by level — but there’s only three levels. I’m honestly not quite sure what to do with this, if anything. My current test just makes them all “gold” badges. See below on “badge paths”.
RIght now, the Badges UI allows people to award badges. The Discourse UI allows admins (only) to do so as well. We’d need to come up with something new for this.
That’s not really a feature here. However, there are several ways we could implement it using bot actions — even including generating a QR Code image. Still, development needed.
The Badges system has the ability to opt out. The current system does not. I’m honestly not convinced this is important, but if we think it is, we’d need to implement something.
Well, currently the system is opt in only, so there’s that. I guess this wouldn’t be that hard, but we’d have to think about it.
I actually have no idea what this looks like currently or what it allows, compared to the command line.
What other features does the current Badges UI have that that I haven’t mentioned?
This is an annoying one. If you tried the experiment, you may have noticed a lot of notifications — one for each badge you already have. There’s no mechanism to suppress this, and dealing with it would require some patches to Discourse itself, which we would have to get upstream.
I do have a partial workaround: notifications can be marked read via the API. So there’d still be a lot of notifications, but they could be immediately marked as seen. (Downside, in addition to the obvious “still kind of overwhelming and annoying”: this requires a global API key rather than one limited to the badges scope.)
The current badges system has the same thing, really — if you don’t ever sign in, you don’t get badges. I am not sure how this currently works with the backend vs. frontend architecture of the system. At the very least, it means that the notification problems isn’t just something we can deal with once for all current users.
Oh actually, also: if we keep the existing backend but replace the frontend, we would need to tell the backend when someone new logs in here.
So, why do all of this if it seems still kind of complicated? Why not just do something to fix the performance problems? Well, right now, badges are kind of a secret game. You have to go to the badges site to activate them, and then generally checking back there is the only time people see them. This puts them in a much more visible, active place — better for showing off, and better for inspiring people to earn more.
Not implemented in either system but really wanted: the ability to have sets of badges one can progress along. This can show new users what to do next, and of course inspire people who like to “collect” to move further up a ladder. The existing system uses badges with increasing numbers, but has no way to visually link them together — or to suggest that something unrelated would actually be a logical next step.
I think we should move forward with this, replacing the wsgi front end and keeping the backend, existing database, and API module. This would really just be mirroring the badge system here, but we’d deprecate (and hide) the current web interface.
We’d need to solve some of the above, but I think it has a lot of advantages over having a whole separate new or revamped UI.
Then, over time, we can look at actually replacing more of the system (including using the Discourse badges database as the authoritative one.)
What do you think?