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.
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.As 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.The 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.
I 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.