One of the main points regarding the functionality of the Fedora Hubs site is the idea that each user will have the ability both to become a member of various hubs, and also to subscribe to them. For easy access to these hubs, a list of the hubs each user ‘follows’ is collected sitewide in the header area of Fedora Hubs. The mockups in this post describe the ways that users will be able to customize their personal hub ‘bookmarks’.
The general inspiration for this comes from Reddit and the idea of subscribing to subreddits. However, while Reddit does have a few different ways to manage ones subscriptions, there’s no easy way to view all these subscriptions at once. There is a dropdown that provides a list of all ones subscriptions in alphabetical order, but the font is tiny and its probably not the way most Reddit users end up interacting with their subscriptions. (I could be wrong! This is just me making blind assumptions, with a tiny sample size of asking fellow interns about their preferences.)
Either way, though, it’s clear that the Reddit interface model won’t map well to Fedora Hubs, so instead I started thinking of hub bookmarks as browser bookmarks. As many as will fit across the top of the screen will display there, and the rest will collapse into a dropdown at the right-hand side of the screen.
At one point, I considered whether or not this interface should include the ability to unsubscribe from or leave hubs. I decided that this would end up being confusing to the users; while it might be convenient to have multiple places to manage hub subscriptions, I feel that it should be as clear as possible when users are leaving or unfollowing hubs to avoid accidental exits, especially in cases where re-joining the group will need to be approved by an admin. To encourage this, I feel that all hub subscribing and un-subscribing should occur on the homepage for that specific hub.
I also wondered if it might be helpful to be able to remove hubs from the bookmark list without unfollowing them. In this case, notifications mentioning them would still show up on their home page and they would still be subscribed/a member of these hubs, but they simply would not appear in the ‘bookmarks’ list. However, I ultimately decided that this would unnecessarily complicate things. If users were allowed to un-bookmark hubs, then they would need a place to re-bookmark them as well. Adding these interactions seemed unnecessary for the amount of clutter they would add to the layout, considering that I personally project user desire for this sort of control to be relatively low.
If we don’t grant users the ability to remove hubs from their bookmarks list without also leaving/unsubscribing, then we should give them the ability to control the order in which their bookmarked hubs display across the top of the screen. Of course, some users don’t want to be forced to set up preferences for this sort of thing, so we had to come up with a default behavior. The obvious solution that we settled upon was all the hubs the user is a member of first, followed by all the hubs they are subscribed to, both sorted from oldest to newest. Especially for users who will be importing their hub memberships from FAS, having an out of the box solution that’s a little more user-friendly than Reddit’s plain alphabetization seemed necessary.
While browser bookmarks are simply click-and-drag to rearrange, that seemed prohibitively difficult to ask developers to code, as well as potentially being confusing to users, since it’s not an interaction found many places outside of browser bookmarks. My mockup for the management task, then, involves opening up a separate modal window and rearranging the hubs within that interface.
The idea, as is hopefully pretty intuitive, is that you simply drag and drop your hubs into the order you prefer, and then they’ll display in that order in the header. One thing Mo pointed out to me when we went over these designs, however, was that I had completely forgotten that these designs need to be accessible to people who use screenreaders or who may not be able to access the site with a mouse.
The final aspect of the hub bookmarks management was something Mo suggested as well. Again, many people may not think it is worth their time to take the minute or two necessary to order their hubs list correctly, or they may have skewed conceptions about which hubs they check on and engage with the most. One idea we briefly floated around was using analytics tracking/heuristics to control the order of the hubs, but that seemed a little too controlling. Users generally prefer to be able to edit their own preferences, and also moving items in a navbar around without notification is one of the greatest sins of UX. It can be incredibly confusing (and frustrating!) when you remember a link being in a certain place and it’s no longer in that location.
Instead, we came up with the idea that hubs would look for the hubs that a user was viewing and posting on the most. If any one hub presented itself as being far more popular than its position in the list would suggest, a notification would display on that hubs home screen for that user with a link to the hub editing modal.
The final thing I’ll include in this post doesn’t specifically fit in with the idea of ‘managing hub bookmarks’, but it doesn’t fit super well anywhere else either. As you can see above, hubs with unread notifications display the bubble with the number in it – a fairly standard thing on social media sites these days. I realized, though, that since ‘extra’ bookmarks would be collapsing into a dropdown, then I had to plan for alerts showing up there, too.
So that’s the mockups & explanations for this set of interactions. I know it got a bit wordy, but I always find it helpful to put all my thoughts down in writing; it helps me to stay organized and to explain to myself why I’m doing a certain thing. We have an upcoming Fedora hubs workshop/hackfest tomorrow, and I’m really excited to meet people on the team in real life and see the project start to come together more in a concrete way!