Sorry to spam your feeds today! I’m trying to collect all my thoughts about what I’ve been working on before the Fedora Hubs workshop tomorrow morning. Since my last post was pretty long, I’m combining these two different concepts I’ve been designing over the past week into one post. While both of them are at least as complex as the hub bookmarks, I ran into a lot fewer mental roadblocks when figuring it out, so I have fewer random thought tangents to explain away, so (hopefully!) this post will be a little shorter. (edit: It really wasn’t. Sorry!)
Subscribing and Joining Hubs
Since the hubs system focuses on participating in hubs, we needed to mock up an interaction for the different kinds of hub participation, and how users can set this up.
The first, and simpler, interaction is simply subscribing to a hub. When subscribing to hubs, users see that hub in their bookmarks list, and can view all the content, but may not be able to post content or participate in other ways. Subscribing to hubs won’t be admin-gated at all, so users can simply elect to follow a hub and it will go straight through.
Being a member of a hub is more like joining a group on FAS. A hub admin needs to approve your request to join the hub and, depending on the hub and its rules, there may be some conditions that someone will need to fulfill before being allowed to join the hub with full privileges.
The idea here is that when someone clicks the ‘+join hub’ link, this dialogue pops up and then the hub request is sent to the admin for approval. I made mockups for two separate ways that admins can receive notifications of requests to join hubs and approve/reject them.
The first of these ways is for this notification to show up on the hub page when the admin is viewing it.
As you can see, the text of the alert changes somewhat based on if there’s a single request or multiple requests, but that’s the basic idea. Under multiple requests, the manage link will open a modal with the list of users and the same approve/deny buttons as the single request. Also from the users list, the admin will be able to click on the names of the users and be taken to their personal profiles. Approving a user is a one-click action, but denying a user requires sending a message so users can understand why they aren’t allowed to join. We came up with the idea of having a short list of “Dear John letters” to send, pre-populated from the FAS group, as well as an area to type a message. While in the mockup this action is shown within the expanded modal, if there is only one user, clicking the deny button will summon this same modal.
The other place that admins will be able to manage hub requests is directly from their own personal hub feedsAs you can see, clicking the inline notification on the hub feed brings up the same modal from the admin page, where requests can be managed as explained before.
One other thing that you may notice is that some of the notification cards on the hub have blue outlines, while others don’t. The logic here is that the blue outlines indicate ‘action items’. While things like being mentioned in a post require you to look at them and perhaps interact, things like hub requests involve direct action, hence the attempt to visually distinguish them so they appear more prominent than the other cards.
The personal hub serves two main purposes. For each Fedora Hubs user, their personal hub serves as a newsfeed of activity regarding themselves across the entire Fedora community and across all of Fedora Hubs. Their hub is also their personal profile; originally it was fairly basic, but in these designs I’ve added several widgets.
The ‘about’ is a place for each user to create a bio; the library, like the library on the community hub pages, is a place to store reference links on ones topic of expertise. Hubs, badges, and an IRC chat are all exactly what they claim to be.
You can subscribe to hubs, but you can also subscribe to specific users. I debated for a while about whether or not this would be a helpful feature, but ultimately decided that while Fedora Hubs, as a social network, is focused mostly on the community scale, there is still value in connecting with individuals. I also debated about whether subscription should be wide open or on an approval basis. The two sides of that coin were privacy vs the possibility of receiving an overwhelming quantity of subscription requests. Ultimately I decided that people’s desire for privacy would outweigh any sort of annoyance from too many notifications.
To lower the risk of users becoming annoyed, then, the request management needs to be as streamlined as possible. Borrowing my own designs for hub management, the user will be able to approve or deny subscription requests in one click directly from their homepage. Also, as seen below, this notification will also include a quick link to subscribe back to the person who has followed you.
Since we added the layer of having user subscriptions, that gave my designs the opportunity to add a subscription-gate to the profile – some areas would be public, while others would remain private.
In this way, people can send their profiles (with bio and library) as references to other people without requiring them to subscribe on Fedora Hubs, while keeping things that they may consider more sensitive private only to approved users.
Some things (such as badges) might be able to be kept out of the subscriber-gate, but I figured it was best to default to too much privacy rather than not enough.
Since hubs is designed in part to help new contributors with the onboarding process, I figured that it might be helpful for them to see the subscribers list and the hubs lists of more experienced users. That way, they might be introduced to communities or people that suit their interests that they would never be able to find solely on their own. The subscribers/subscribing list shows up in a modal when the numbers in the upper right of the profile are clicked; the hubs list shows up in a similar modal when the “n more …” link is clicked.
So that’s all I have (finally!) I’m relieved to finally have all my work out in the open. If anyone has any suggestions or criticisms of these (or any other) designs, they’re very welcome. Thanks for reading (or skimming) these long explanations!