Post Filtering

In order to prevent users from being overwhelmed by a fire hose of notifications from the hubs they’re subscribed to and from all the other apps connected to Fedora Hubs, we decided to design a filtering system.

If a user sees a type of notification that they don’t find valuable, they can use a dropdown located in the upper right of the notification card to decide how they want to filter out these sorts of posts.

Selection_014

As you can see, there are three different options for how users can block future posts. First, they can decide not to see any notifications that are exactly like the active card – here, the example is design team meeting reminders. The user can also choose to hide all updates from the design-team hub, if that is the kind of content they find unhelpful, or hide all meeting reminders. We hope that with these three options will allow users to gain full control over their notification streams.

Also in this dropdown are the options to ‘save link’ or ‘pin link’. The idea here is that users will be able to bookmark specific notifications they find important. Saving the link will be a private area of the main notification stream, while pinning the link will put it in their library, which is a kind of public reference area. Libraries were initially conceptualized as being a place where team or project hubs can put links to content important for new contributors, but we realized that individual users may also want to collect these references to show to their peers or to new users they may be mentoring.

Selection_015

To complement the ability to filter ones stream, we needed to design the filtered stream itself. Each tab here reveals a different stream of notifications: ‘my stream’ has the contextual filters from above applied. ‘My actions’ is notifications that require action – generally things like approving subscribers, new hub members, answering private messages on IRC, and looking at tickets that have been assigned to you. The ‘saved notifications’ was mentioned above, and it’s where the notifs people explicitly wanted to save will populate. The ‘all’ tab is the firehose of all notifications.

If people want to look at their filters and remove any, they can do that by clicking ‘view filters’, which will open a modal.

Selection_016

I wasn’t sure whether these interactions would be clear to potential users, so I threw together a quick sketch and tested it on one of my fellow Red Hat interns.

image(1)image

 

 

 

Her feedback informed me that while the filtering dropdown was in the usual place, the wording of ‘hide this notification’ implied that it would only hide that specific card, not all cards with that exact overlap of traits. She also informed me that filter management seemed like something that would happen by going to the main settings panel in the upper right corner of the whole page. This issue may come from the fact that the ‘view filters’ link isn’t as visually prominent on my sketch as it is on the more polished design, but her feedback did encourage me to try to make the link as noticeable as possible. Fedora Hubs is still moving forward!

IRC on Hubs

As shown on earlier mockups, one aspect of the Fedora Hubs concept is the inclusion of using IRC to send messages. Some of the earliest mockups included the idea of a messaging/email system within Hubs, but that idea was deprecated. Fedora Hubs is supposed to be a system that reduces friction by streamlining and integrating disparate workflows, and adding another form of messaging that users have to keep up with seemed as though it would cause more annoyance than it would be worth.

Still, since the idea for hubs is also to help new contributors get integrated more smoothly into the Fedora community, an effective way to message people did seem like it would be valuable. Since the team/project hubs will have the ability to include an embedded IRC channel, using IRC to send private messages seemed logical. But Fedora Hubs is not an IRC client – it will use IRC to send private messages between users and to enable the channel discussions, but every channel must be directly associated with a hub and the messaging interface will only support messages between Hubs users, not to anyone external. This is an active design choice that Mo and I made, based on the concept of keeping the hub as the central organizing principle of this app in order to help fend off scope creep.

Private Messages

Private IRC messages have made a (brief!) appearance before in the mockups, as a widget on each users personal hub.personalhub_3Since then, we’ve refined the idea quite a bit, but the idea of the messaging widget in the sidebar still stands. The concept is that since multiple people can be sending private messages at the same time, and since it’s also incredibly unlikely that a given user would just happen to be on the profile of the person sending them messages, we also needed a) some sort of alert system and b) a private messaging area/portal/hub (name forthcoming!) to match.

ircpm_1As you can see in this mockup, there’s a small icon to indicate messages in the upper right; unread messages give the typical “red dot with number” style alert. Unread messages also send a notification to the users main feed.

There’s also a private messaging center where users can view all their messages and respond to these alerts (that’s where clicking the icon and the ‘reply’ button on the notif card takes you).ircpm_2I feel as though this mockup is pretty self-explanatory. On the left, users can select the person they want to send messages to; on the right is the actual chat interface. The dot next to the name indicates an unread message. I’ve included the person’s hub icon in addition to their username for clarity, and the essential timestamps are found on the lower right of each set of messages.

A feature that would be great to include, though the feasability may need some estimating, is the idea of having inline images and link previews.

ircpm_3I also created an alternate version of this with differently shaped text bubbles. One of the things that’s hardest to express is when the same person sends multiple messages in a row, associating them with the correct user is about finding the balance between too much indication and not enough indication. I’m not sure that changing the bubble shapes helps with that anyway, but it does echo the shape of the chat icon and the fedora logo more cohesively.

ircpm_4

Hub Channels

The other aspect of the IRC integration is the channels in the sidebar of the hub page.This was covered previously, but one thing that we have to account for in the group chats that we hadn’t yet considered is mentions, and how to handle notifications for different use cases of these.

Mo and I did identify 3 main categories of mentions:

  1. The user is in the hub where the mention occurs
  2. The user is in a different hub than the mention
  3. The user is logged out entirely

The concept we eventually settled on for displaying mentions is to localize them to the specific hub, in keeping with the philosophy of the hub being the central organizing principle of the site. We’ve handled this by displaying the mentions in the IRC widget in a separate tab.

ircpm_5

Clearly there’s some details with the visual design that I need to fix (tabs are hard!) but this is the general idea. The main chat widget has a list of participants, a dismissible topic box, and then the IRC chat below. In a separate tab, the archive of your mentions in that channel collects. Rather than trying to decide on a time limit or basing it if you click the mention to dismiss the notification, we eventually decided to limit the number of mentions to ten and simply replace older ones with newer ones when the limit is reached. Users can also dismiss the mention themselves with the x in the upper right corner, if the mention is no longer relevant or if they’ve seen it already and don’t wish to keep it. The idea with the ‘go to mention’ link is that in a perfect world, it’ll go back to the other tab of the widget and scroll you back to the point in the channel archive where you were mentioned.

We came up with separate notification systems for the three cases discussed above.

ircpm_6This mockup is for case 1, where you are in the hub when you are mentioned. Your IRC nick, when mentioned, is bolded and turned blue. If you’re in the hub but not watching the chat (for example, you might be reading the mailing list posts or engaging with the content in the main block of the hub instead of the IRC widget itself) then there will be a visual alert, like the ! included here. This indication is dismissed by clicking inside the IRC widget, so if you are actively participating in the chat it won’t be a distraction but if you’re engaged elsewhere on the page it will notify you of the mention.

ircpm_7This is for case 2: if you’re in a different hub but still online when someone mentions you in a hub channel, a message icon will appear in the bookmarked hubs navigation at the top, similar to the ‘new posts’ dot. When you go to the hub, you’ll be able to find the mention either by scrolling or by finding it in the ‘mentions’ tab and clicking go to mention as discussed above.

As you can see by my comment there, I have some tweaks to do with the visuals of how to have two different sorts of visual icons/alerts in essentially the same place at a very small size. Below is a close-up view of the icon struggle I’m having. If anyone has any suggestions, please let me know!

Selection_010

ircpm_8For case 3, if someone mentions your nick when you’re totally offline, you’ll get all the same notifications as above – tab icons and collecting into the mentions tab. In addition to this, a notification will show up in the main feed (shown second card down).

These mockups cover all the scenarios we concocted for the various uses of IRC to facilitate group and individual messages. If you feel there’s something else we should consider adding please let me know in a comment!

Joining Hubs & Personal Profiles

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.

hub_subscribe

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.

hub_join1

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.

hub_join2

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. hub_join3Approving 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 feedshub_join4As 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.

Personal Profiles

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.personalhub

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. personalhub_1

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.

personalhub_2

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.

personalhub_3

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.

personalhub_4From these modals, users can click the links and be taken to the relevant hub page / user profile, where they can learn more and choose to subscribe/join or not as they see fit.

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!

Bookmarking Hubs

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.

edithubslist

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.edithubslist_modal

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.

edithubslist_accessibleedithubslist_accessible2

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.

edithubslist_alert

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.edithubslist_notifs

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!

Intro to Fedora Hubs

It’s the first week of my summer internship at Red Hat, and one of the projects I’m working on is creating mockups for a new application called Fedora Hubs. As best as I understand it from my perspective as an extreme newcomer, the idea behind Fedora Hubs is that it will be a sort of social networking site based on the Fedora Account System that will integrate all sorts of sites and applications across the Fedora community, including things such as mailing lists, blog posts, and ticket tracking. The purpose behind the creation of this network is to lower the bar and make it easier for new contributors to get off the ground and start getting involved in Fedora.

What I’ve been working on so far is taking some interface designs that Mo, the senior interaction designer on the fedora team, has created and adapting them to think about what workflows and interactions might look like from the perspective of an admin creating a new hub.

When I started thinking about what that process should look like, I was initially kind of confused. I don’t have a super technical background or any experience with any of the applications Fedora Hubs is aiming to integrate, so I didn’t have any ideas of which workflows I could imitate for this design. So I started sketching! The header image above is my whiteboard sketches that led me to the ideas for my mockup, but the full version (with my notes actually readable!) is also included below.

mockup_sketch

Once I started writing things out on the whiteboard, I quickly realized that the setup for a complicated object like the hubs easily got cluttered and confusing. Then I started thinking about different ways to make the layout as self-explanatory as possible, and decided to use Mo’s design as a starting point and have the admin hub creation view look as similar to the final product as possible, in an attempt to keep things as simple as possible for everyone. Once I had the whiteboard sketch above, I started transferring my ideas over into Inkscape so that the designs could be a little more legible and usable.mockup_newhubAs you can see from this mockup, I took Mo’s design and simply replaced every widget or display area with an editor. That way, the final layout will be visible in the editor mode, and since most of the widget areas only require a few pieces of information for setup, the design won’t end up overly bloated by the visual layout.

Starting from the top of the mockup and working my way down, the header area of the hub is customizable by the admin, with a smaller logo, a larger background banner image, and the name of the hub as simply text, reminiscent of the way Facebook/Twitter handles this.

Below that, the welcome message area would be a description of the hub and an explanation of the sort of work that the group tends to do. This correlates with the library, found at the top of the right sidebar. In the brainstorm meeting on 5/21, one topic that came up was the idea of having “pinned” topics (like might be found on a discussion forum) in addition to, or as part of, the welcome banner area. But one potential issue that was noted was that these pinned posts tend to add up quickly and can clutter the layout of the site, especially for returning or experienced users who may not need to view these posts more than once. Moving the pinned posts to the top of the sidebar was strategized as a method to keep them in a prominent position for new users who need them as a reference without compromising the usability of the hub for other users. I picked out the name ‘library’ since it would simply be a collection of links to posts on various sites.

As can be seen in each widget area, there’s a small text box in which to  input the necessary information for ‘syncing’ each type of widget. I wasn’t sure about how much information was needed for each widget, but I figured technical details can be refined further along in the design process by working with people who are actually familiar with the system the hubs will be running on. Special cases like syncing a private mailing list will also be considered then.

There are a few widgets that the admin panel will default to including – an IRC channel, a Hyperkitty mailing list, and probably a few others. The admin can of course remove these widgets as well as adding new ones; below is the basic interaction for adding new widgets to the hub.mockup_newhubwidgetThe idea here is that the dialogue to add a widget will pop up in a modal. The admin can then select the type of widget they wish to add from a dropdown menu, and then advance to the next page, which of course is dependent upon which type of widget was selected in the first page. The widget is then added to the hub layout. There are ‘add a widget’ buttons in both the body of the page and in the sidebar, so layout can be controlled by the admin in this way.

The final interaction I worked on was the ability to control who else is a hub admin. Since group member status is based on the FAS account, I initially assumed that hub admins would be set in the FAS account as well. But a discussion with Mo led me to realize that since hub admin duties are distinct from group admin duties, and also that there may not always be a one-to-one correlation between both the types of admins and the hubs/groups overall, I needed to think of a design for this case as well.

mockup_newhubadminI used the idea of the modal for this idea as well. Here, you can remove current admins and add new ones, by searching for users on Fedora Hubs and selecting the correct person. Things that still need to be considered are things such as, if people should be allowed to delete themselves as hub administrators, or how the flow should appear if someone tried to add an admin who was not currently a member of the group.

Overall, though, these designs are what I’ve been working on for the past few days. I’m very excited to be able to learn more about the project, refine these layouts, and move forward with the project as a whole.