Fedora Hubs Update!!!

The dream is real – we are cranking away, actively building this very cool, open source, socially-oriented collaboration platform for Fedora.
Myself and Meghan Richardson, the Fedora Engineering Team’s UX intern for this summer, have been cranking out UI mockups over the past month or so (Meghan way more than me at this point. 🙂 )

We also had another brainstorming session. We ran the Fedora Hubs Hackfest, a prequel to the Fedora Release Engineering FAD a couple of weeks ago.
After a lot of issues with the video, full video of the hackfest is now finally available (the reason for the delay in my posting this 🙂 ).

Let’s talk about what went down during this hackfest and where we are today with Fedora Hubs:

What is Fedora Hubs, Exactly?

(Skip directly to this part of the video)
We talked about two elevator pitches for explaining it:

• It’s an ‘intranet’ page for the Fedora Project. You work on all these different projects in Fedora, and it’s a single place you can get information on all of them as a contributor.
• It’s a social network for Fedora contributors. One place to go to keep up with everything across the project in ways that aren’t currently possible. We have a lot of places where teams do things differently, and it’s a way to provide a consistent contributor experience across projects / teams.

Who are we building it for?

(Skip directly to this part of the video)

• New Fedora Contributors – A big goal of this project is to enable more contributors and make bootstrapping yourself as a Fedora contributor less of a daunting task.
• Existing Fedora Contributors – They already have a workflow, and already know what they’re doing. We need to accommodate them and not break their workflows.

The main philosophy here is to provide a compelling user experience for new users that can potentially enhance the experience for existing contributors but at the very least will never disrupt the current workflow of those existing contributors. Let’s look at this through the example of IRC, which Meghan has mocked up in the form of a web client built into Fedora Hubs aimed at new contributor use:
If you’re an experienced contributor, you’ve probably got an IRC client, and you’re probalby used to using IRC and wouldn’t want to use a web client. IRC, though, is a barrier to new contributors. It’s more technical than the types of chat systems they’re accustomed to. It becomes another hurdle on top of 20 or so other hurdles they have to clear in the process of joining as a contributor – completely unrelated to the actual work they want to do (whatever it is – design, marketing, docs, ambassadors, etc.)
New contributors should be able to interact with the hubs IRC client without having to install anything else or really learn a whole lot about IRC. Existing contributors can opt into using it if they want, or they can simply disable the functionality in the hubs web interface and continue using their IRC clients as they have been.

Hackfest Attendee Introductions

(Skip directly to this part of the video)
Next, Paul suggested we go around the room and introduce ourselves for anybody interested in the project (and watching the video.)

• Máirín Duffy (mizmo) – Fedora Engineering UX designer working on the UX design for the hubs project
• Meghan Richardson (mrichard) – Fedora Engineering UX intern from MSU also working on the UX design for the hubs project
• Remy Decausemaker (decause) – Fedora Community lead, Fedora Council member
• Luke Macken (lmacken) – Works on Fedora Infrastructure, release engineering, tools, QA
• Adam Miller (maxamillion) – Works on Release engineering for Fedora, working on build tooling and automation for composes and other things
• Ralph Bean (threebean) – Software engineer on Fedora Engineering team, will be spending a lot of time working on hubs in the next year
• Stephen Gallagher (sgallagh) – Architect at Red Hat working on the Server platform, on Fedora’s Server working group, interested in helping onboard as many people as possible
• Aurélien Bompard (abompard) – Software developer, lead developer of Hyperkitty
• David Gay (oddshocks) – Works on Fedora infrastructure team and cloud teams, hoping to work on Fedora Hubs in the next year
• Paul Frields (sticksteR) – Fedora Engineering team manager
• Pierre-Yves Chibon (pingou) – Fedora Infrastructure team member working mostly on web development
• Patrick Uiterwijk (puiterwijk) – Member of Fedora’s system administration team
• Xavier Lamien (SmootherFrOgZ) – Fedora Infrastructure team member working on Fedora cloud SIG
• Atanas Beloborodov (nask0) – A very new contributor to Fedora, he is a web developer based in Bulgaria.
• (Matthew Miller and Langdon White joined us after the intros)

Game to Explore Fedora Hub’s Target Users

(Skip directly to this part of the video)
We played a game called ‘Pain Gain’ to explore both of the types of users we are targeting: new contributors and experienced Fedora contributors. We started talking about Experienced Contributors. I opened up a shared Inkscape window and made two columns: “pain” and “gain:”

• For the pain column, we came up with things that are a pain for experienced contributors the way our systems / processes currently work.
• For the gain column, we listed out ways that Fedora Hubs could provide benefits for experienced contributors.

Then we rinsed and repeated for new contributors:

While we discussed the pains/gains, we also came up with a lot of sidebar ideas that we documented in an “Idea Bucket” area in the file:

I was worried that this wouldn’t work well in a video chat context, but I screen-shared my Inkscape window and wrote down suggestions as they were brought up and I think we came out with a useful list of ideas. I was actually surprised at the number of pains and gains on the experienced contributor side: I had assumed new contributors would have way more pains and gains and that the experienced contributors wouldn’t have that many.

Prototype Demo

(Skip directly to this part of the video)

Ralph gave us a demo of his Fedora Hubs prototype – first he walked us through how it’s built, then gave the demo.

In the README there is full explanation of how the prototype works so I won’t reiterate everything there. Some points that came up during this part of the meeting:

• Would we support hubs running without Javascript? The current prototype completely relies on JS. Without JS, it would be hard to do widgets like the IRC widget. Some of the JS frameworks come with built-in fail modes. There are some accessibility issues with ways of doing things with JS, but a good design can ensure that won’t happen. For the most part, we are going to try to support what a default Fedora workstation install could support.
• vi hotkeys for Hubs would be awesome. 🙂 Fedora Tagger does this!
• The way the widgets work now, each widget has to define a data function that gets called with a session object, and it has to return JSON-ifiable python code. That gets stored in memcached and is how the wsgi app and backend communicate. If you can write a data function to return JSON and write a template the data gets plugged into – that’s mainly what’s needed. Take a look at the stats widget – it’s pretty simple!
• All widgets also need a ‘should_invalidate()’ function that lets the system know what kinds of information apply to which widgets. Every fedmsg has to go through every widget to see if it invalidates a given widget’s data – we were worried that this would result in a terrible performance issue, but by the end of the hackfest we had that figured out.
• Right now the templates are ginja2, but Ralph thinks we should move to client-side (javascript) templates. The reason is that when updated data gets pushed over websockets from the bus, it can involve garbage communication any time new changes in data come across – it’s simpler that the widget doesn’t have to request the templates and instead the templates are already there in the client.
• Angular could be a nice client-side way of doing the templates, but Ralph had heard some rumors that AngularJS 2 was going to support only Chrome, and AngularJS 1.3 and 2 aren’t compatible. nask0 has a lot of experience with Angular though and does not think v2 is going to be Chrome-only.
• TODO: Smoother transitions for when widgets pop into view as they load on an initial load.
• Langdon wondered if there would be a way to consider individual widgets being able to function as stand-alones on desktops or mobile. The raw zeromq pipes could be hooked up to do this, but the current design uses EventSource which is web-specific and wouldn’t translate to say a desktop widget. Fedora Hubs will emit its own fedmsgs too, so you could build a desktop widget using that as well.
• Cache invalidation issues was the main driver of the slowness in Fedora Packages, but now we have a cache that updates very quickly so we get constant time access to delivering those pages.

Mockup Review

Next, Meghan walked us through the latest (at the time 🙂 we have more now!) mockups for Fedora Hubs, many based on suggestions and ideas from our May meetup (the 2nd hubs video chat.)

Creating / Editing Hubs

(Skip directly to this part of the video)
First, she walked us through her mockups for creating/editing hubs – how a hub admin would be able to modify / set up their hub. (Mockup (download from ‘Raw’ and view in Inkscape to see all screens.)) Things you can modify are the welcome message, colors, what widgets get displayed, the configuration for widgets (e.g. what IRC channel is associated with the hub?), and how to add widgets, among many other things.
Meghan also put together a blog post detailing these mockups.
One point that came up here – a difference is that when users edit their own hubs, they can’t associate an IRC channel with it, but a nick and a network, to enable their profile viewers to pm them.
We talked about hub admins vs FAS group admins. Should they be different or exactly the same? We could make a new role in FAS – “hub admin” – and store it there if it’s another one. Ralph recommended keeping it simple by having FAS group admins and hub admins one and the same. Some groups are more strict about group admins in FAS, some are not. Would there be scenarios where we’d want people to be able to admin the FAS group for a team but not be able to modify the hub layout (or vice-versa?) Maybe nesting the roles – if you’re a FAS admin you can be FAS admin + hub admin, if you’re a hub admin you can just admin the hub but not the FAS group.
Another thing we talked about is theming hubs. Luke mentioned that Reddit allows admins to have free reign in terms of modifying the CSS. Matthew mentioned having a set of backgrounds to choose from, like former Fedora wallpapers. David cautioned that we want to maintain some uniformity across the hubs to help enable new contributors – he gave the example of Facebook, where key navigational elements are not configurable. I suggested maybe they could only tweak certain CSS classes. Any customizations could be stored in the database.
Another point: members vs subscribers on a hub. Subscribers ‘subscribe’ to a hub, members ‘join’ a hub. Subscribing to a hub adds it to your bookmarks in the main horizontal nav bar, and enables certain notifications for that hub to appear in your feed. We talked about different vocabulary for ‘subscribe’ vs ‘join’ – instead of ‘subscribe’ we talking about ‘following’ or ‘starring’ (as in Github) vs joining. (Breaking News 🙂 Since then Meghan has mocked up the different modes for these buttons and added the “star” concept! See below.)

We had a bit of an extended discussion about a lot of the different ways someone could be affiliated with a team/project that has a hub. Is following/subscribing too non-committal? Should we have a rank system so you could move your way up ranks, or is it a redundant gameification given the badge system we have in place? (Maybe we can assign ranks based on badges earned?) Part of the issue here is for others to identify the authority of the other people they’re interacting with, but another part is for helping people feel more a part of the community and feel like valued members. Subscribing is more like following a news feed, being a member is more being part of the team.

Joining Hubs

(Skip directly to this part of the video)

Personal Profiles

(Skip directly to this part of the video)
Next Meghan walked us through the mockups she worked on for personal profiles / personal streams. One widget she mocked up is for personal library widgets. Other widgets included a personal badges earned display, hubs you’re a member of, IRC private message, a personal profile.
Meghan also talked about privacy with respect to profiles and we had a bit of a discussion about that. Maybe, for example, by default your library could be private, maybe your stream only shows your five most recent notifications and if someone is approved (using a handshake) as a follower of yours they can see the whole stream. Part of this is sort of a bike lock thing…. everything in a user’s profile is broadcast on fedmsg, but having it easily accessible in one place in a nice interface makes it a lot easier (like not having a lock on your bike.) One thing Langdon brought up is that we don’t want to give people a false sense of privacy. So we have to be careful about the messaging we do around it. We thought about whether or not we wanted to offer this intermediate ‘preview’ state for people’s profiles for those viewing them without the handshake. An alternative would be to let the user know who is following them when they first start following them and to maintain a roster of followers so it is clear who is reading their information.
Here’s the blog post Meghan wrote up on the joining hubs and personal profile mockups with each of the mockups and more details.

Bookmarks / main nav

(Skip directly to this part of the video)
The main horizontal navbar in Fedora Hubs is basically a bookmarks bar of the hubs you’re most interested in. Meghan walked us through the bookmarks mockups – she also covered these mockups in detail on her bookmarks blog post.

ZOMG THIS IS SO AWESOME!

Yes. Yes, it is.
So you may be wondering when this is going to be available. Well, we’re working on it. We could always use more help….

Where’s stuff happening?

How does one help? Well, let me walk you through where things are taking place, so you can follow along more closely than my lazy blog posts if you so desire:

• Chat with us: #fedora-hubs on irc.freenode.net is where most of the folks working on Fedora Hubs hang out, day in and day out. threebean’s hooked up a bot in there too that pushes notifications when folks check in code or mockup updates.
• Mockups repo: Meghan and I have our mockups repo at https://github.com/fedoradesign/fedora-hubs, which we both have hooked up via Sparkleshare. (You are free to check it out without Sparkleshare and poke around as you like, of course.)
• Code repo: The code is kept in a Pagure repo at https://pagure.io/fedora-hubs. You’ll want to check out the ‘develop’ branch and follow the README instructions to get all setup. (If I can do it, you can. 🙂 )
• Feature planning / Bug reporting: We are using Pagure’s issue tracker at https://pagure.io/fedora-hubs/issues to plan out features and track bugs. One way we are using this which I think is kind of interesting – it’s the first time I’ve used a ticketing system in exactly this way – is that for every widget in the mockups, we’ve opened up a ticket that serves as the design spec with mockups from our mockup repo embedded in the ticket.
• Project tracking: This one is a bit experimental. But the Fedora infra and webdev guys set up http://taiga.fedoraproject.org – an open source kanban board – that Meghan and I started using to keep track of our todo list since we had been passing post-it notes back and forth and that gets a bit unwieldy. It’s just us designers using it so far, but you are more than welcome to join if you’d like. Log in with your Fedora staging password (you can reset it if it’s not working and it’ll only affect stg) and ping us in #fedora-hubs to have your account added to the kanban board.
• Notification Inventory: This is an inventory that Meghan started of the notifications we’ve come up with for hubs in the mockups.
• Nomenclature Diagram for Fedora Hubs: We’ve got a lot of neat little features and widgets and bits and bobs in Fedora Hubs, but it can be confusing talking about them without a consistent naming scheme. Meghan created this diagram to help sort out what things are called.

How can I help?

Well, I’m sure glad you asked. 🙂 There’s a few ways you can easily dive in and help right now, from development to design to coming up with cool ideas for features / notifications:

1. Come up with ideas for notifications you would find useful in Fedora Hubs! Add your ideas to our notification inventory and hit us up in #fedora-hubs to discuss!
2. Look through our mockups and come up with ideas for new widgets and/or features in Fedora Hubs! The easiest way to do this is probably to peruse the mini specs we have in the pagure issue tracker for the project. But you’re free to look around our mockups repo as well! You can file your widget ideas in Pagure (start the issue name with “Idea:” and we’ll review them and discuss!
3. Help us develop the widgets we’ve planned! We’ve got little mini design specs for the widgets in the Fedora Hubs pagure issue tracker. If a widget ticket is unassigned (and most are!), it’s open and free for you to start hacking on! Ask Meghan and I any questions in IRC about the spec / design as needed. Take a look at the stats widget that Ralph reviewed in explaining the architecture during the hackfest, and watch Ralph’s demo and explanation of how Hubs is built to see how the widgets are put together.

There are many other ways to help (ask around in #fedora-hubs to learn more,) but I think these have a pretty low barrier for starting up depending on your skillset and I think they are pretty clearly documented so you can be confident you’re working on tasks that need to get done and aren’t duplicating efforts!
Hope to see you in #fedora-hubs! 🙂