Fedora Community (the app) Update

The story up ’till recently

So you may have heard about Fedora Community, a web application we developed and launched in 2009. Or, maybe not. From the wiki planning page for the project:

Fedora Community is a web portal designed to make it easier for package maintainers to do their job. The goal is to create a modular web page in which each module would pull views from the various Fedora resources and display them to the user.

Well, the project wasn’t the resounding success Spot, J5, Luke, and I were hoping it might be. We’d set out to make life easier for Fedora package maintainers, which of course benefits everyone who uses Fedora. We did run a usability test of Fedora Community at FUDcon Toronto in December 2009 after it had been available for a couple months. There’s some detailed testing analysis here, but in short we identified the following issues during testing:

• The testers had never heard of it before, and were confused as to what it was for.
• The application runs pretty slowly.
• The navigation was confusing.
• Search results weren’t always great.

Because of various commitments / new projects on each of our plates, however, after the usability test the site pretty much remained the same for a while. We never did a huge marketing push for it, and around the same timeframe we launched fedoracommunity.org which kind of confused matters: it is a completely different site with the same name! (It’s a portal for world-wide, region-specific Fedora websites and teams.)

The plot thickens

As you may already be aware, the Fedora infrastructure team has been evaluating the services they provide and shutting down services that aren’t in active use that expend resources that could be better used for Fedora in other ways. For example, recently the Fedora WordPress MU server was shut down for a number of good reasons. (Please check out the full rationale for more backstory.)
In this spirit, Smooge started a thread about Fedora Community and what future plans for it are on the Fedora infrastructure mailing list a couple of week ago. Here’s a summary of the points that came up in the thread:

• It’s aimed at contributors, not users.
• It’s AGPL so it may pose a burden other apps in Fedora’s infrastructure don’t, so the license may be an issue.
• If it’s meant to be used, it needs to be advertised more.
• It’s not built for RHEL 6 which limits the servers it can be deployed to.
• There was one user of the app (Thomas Spura) who spoke up in its favor, saying it enabled him to view information across infrastructure apps without having to dig into multiple apps individually to get the same data.
• Smooge put together some usage statistics: “Currently we are seeing 380->420 unique ip addresses per month who are not bots or not referrals from other sites. Most go to /community/ but ~100 of them made queries beyond standard page data (images, javascript, and /community/). While it doesn’t sound a lot… for a site that doesn’t have a lot of advertising it is an audience.”

So last week the Fedora Community team (Spot, J5, Luke, me) got together to figure out what we should do. We grabbed a couple of whiteboards and discussed a bit about Fedora Community’s fate!

Whiteboard time!

In short, we basically started talking through the issues we’d need to fix to make the application more awesome, which involved some great expansion ideas, but then receded back to ‘let’s fix the core first,’ which then ended in ‘let’s get a new, clean, minimal front-end going, really get it right, and expand carefully from there.’ Okay, so, let me see if I can walk you through how the discussion went so you can understand this train of thought:

Ideas for more features

I think we started out talking about cool new features we could add on to it. Luke’s initial post to the Fedora infrastructure list thread covers a lot of these ideas, as does his summary of the ‘Next Big Fedora Engineering Project’ session at FUDcon Tempe earlier this year. Here’s an at least partial summary in case you’re lazy like me and don’t click on all the links:

• Real-time Infrastructure
• Meeting app
• Improved upstream monitoring
• Discussions app
• Spin Master
• Source-level package diff viewer
• SIG dashboards, with action items, SOPs, packages, people, meetings, etc
• Package review app

(Want more details? Check this link and this link for them!)

Ideas are great, but…

I think we talked about some of these awesome ideas, but then came to the realization that our scope was too big, and while all of the ideas rocked, it might take us a really long time and a lot of effort to do them right, and we should probably focus on fixing what we’ve got before adding more stuff.

Okay, what should we fix in what we’ve already got?

So we then started coming up with a list of the issues in the current site that we wanted to address, and went into some detail about how we might fix them:

• Performance issues: it takes a long time to get data back from some of the other infrastructure apps that Fedora Community queries. Some sub-topics we branched out into:
  • Real-time enablement reliability: (pardon my less-technical take) We built Fedora Community with the idea of being able to display real-time updates via an underlying message bus infrastructure to which all of the various components of the infrastructure providing notification data (koji, bodhi, FAS, etc.) are hooked up. Any notifications could be displayed live in the UI without a page refresh. However, we’re still doing some static queries and the live messaging isn’t fully hooked up yet. There were concerns that flipping the switch, turning off the old system, and enabling only messaging would mean we’d get a performance hit on various servers and messages might get lost. So I think Spot or J5 said we could just leave the normal email notifications on and the messaging queue-backed new live stream on at the same time, and diff the new system to the old system to see if any messages had dropped.
  • Real-time enablement performance hits: there was a concern raised that enabling real time messaging everywhere would slow down the web app, but the conclusion seemed to be it would actually make a lot of systems more efficient and would help performance.
  • Benchmarking: some benchmarking tools should be built into the Moksha stack (the middleware that Fedora Community is built on to of). Then we should do some benchmarking of queries between the Fedora Community app and the various infrastructure apps it talks to so we have some data on which apps are slowing down Fedora Community because the queries are taking too long. These benchmarks should be query-level, not just app-level so we can isolate specific queries as the cause of pokiness and have them fixed.
• Feature re-evaluation: As my sad little cartoon guy kind of shows, having too many features that aren’t quite there yet can be an overwhelming position. What do you fix first? What do you focus on? Spot suggested, in a similar manner to what the infrastructure team is doing with hosted services, that we evaluate the features Fedora Community has today and consider paring it down to a core. The core he proposed was to not support packagers per se, but to just be a useful source of package data. So the focus would be packages, not packagers. (See crossed out ‘packagers’ in upper leftish area). Using this as a mantra, could we go through feature-by-feature and pare things down?
• UI issues: As the main designer of the UI I will be the first to tell you, it is not great and could be much better.
  • Navigation complexity: We built it to be something that, depending on your role in Fedora, would have a very different interface. For example, if you’re a packager you’d see builds, updates, package info, etc. If you’re an ambassador, you might see an ambassador roster widget where you could view ambassadors by region, and an events calendar to see what events are coming up that you could help out with. We designed it so that we could give users different tools based on their needs, but we only partially implemented tools for one target user – Fedora packagers – and never really realized that vision of different flavors for different user needs. The navigation suffers a lot from this; we may have been better off making a finely honed packager tool, and making a completely separate tool for each other user and maybe loosely tying them together with an optional global navbar (kind of like the new Google accounts one? But I kind of also hate that toolbar too…)
  • Search: The search functionality in the UI needs work. Some of the query times in the usability test were pretty bad. Search is a hard problem technically, though.
  • Mobile UI: The UI doesn’t have a mobile stylesheet to render it nicely on a mobile device.
  • URL ickiness: The url for the app is not short and not memorable: “http://admin.fedoraproject.org/community. The URLs we display for various pages are not predictable and kind of ugly. These are symptoms of a security system in place because we have Fedora account logins on the site. We use the user’s account information to provide personalized data (e.g., we’ll give you information on packages you own) and also to give you access to user information on other folks in the system.

  This last point was fodder for the next phase of the conversation, which I’ll call the Zen phase.

  Everything Zen

  
  Nirvana by ePi.Longo on Flickr. Used under a CC-BY 2.0 license.
  “Well, why do we require login in the first place?” I think Spot asked when we were trying to figure out how to rememedy the ugly URL issues.
  “Personalization in presenting packages!” I think Luke said. (Maybe he didn’t. But doesn’t dialog make the blog post so much more interesting to read?)
  “It allows you to search users and get details about them,” said J5.
  “I can get those details about users from a bot in IRC without being logged in,” I said.
  Spot also pointed out, “You can also look up the packages someone owns without having to log in as them.”
  !
  WHY DO WE NEED LOGIN IN THE FIRST PLACE?
  Turns out maybe we didn’t. Simplification idea! We continued on this track of minimalism. J5 brought up what I think was a pretty cool idea, “design the interface as if it was for a mobile phone, to keep it clean and minimal and to only have the essentials.”
  So they talked for a bit and I started drawing what I thought such a (gentle) beast may look like:
  
  There’s a user track along the bottom where you can, read-only:

  • Search or browse for packages in Fedora.
  • Search or browse for users in Fedora.
  • View a list of the latest package updates (with filter?)
  • View a list of the latest builds (with filter?)

  This is the simplest plan. Next, there’s a track for packagers (ones not present above highlighted):

  • View your packages.
  • Search or browse for packages in Fedora.
  • Search or browse for users in Fedora.
  • View your updates.
  • View a list of the latest package updates (with filter?)
  • View your builds.
  • View a list of the latest builds (with filter?)
  • View your bugs.

  We talked about how you shouldn’t have to log in to get the above personalized features, but that people might get creeped out if we ask for their FAS username without a password, so we need to figure out a way to do that without scaring people.
  From those scribbles above, we pared things down some more into an initial first cut feature set:

  • Search packages
    • Search interface
    • Package results list:
      • First precedence: exact match in name of package
      • Second precedence: partial match in name of package
      • Third precedence: match in package tags
      • Fourth precedence: match in package summary
      • Fifth precedence: match in package description
    • We should be able to pull results for both packages as they are named in Fedora, and packages as they are named in Debian and any other distros that provide a way to correlate packages cross-distro.
    • We will not list subpackages as separate packages. If a subpackage has name unique to the package that generated it, we’ll show the parent as being the package but also highlight that the match was in a subpackage.
    • Other package types that will be children of their parent and not treated as separate packages include debuginfo, devel, and specific binary packages.
  • Browse packages: by default you’ll get a search box though. We’ll let you opt into a browsing interface. Maybe not based on comps.
  • Packages I own
  • Package details page: we talked about this being kind of like a facebook profile for a package. It should show the full family of the package: its binaries, sub pages, devel package, debuginfo package, source, spec… but at least initially, no dep list or dep browsing interface.

  We ended this discussion by talking about how we should see what features users ask for and implement them if there is enough demand, and to be careful not to take on too much and expand the scope too wide and have it become an unruly garden to tend again. (This is kind of the 37signals approach, isn’t it?)
  Okay, cool. Sounds like a plan. Does it make sense how we got to this point now?

  The contract

  
  So here’s what we agreed on from this exercise:

  • We’re going to try this Zen approach read-only to start.
  • No logins. We’ll get the data without having you log in to get it.
  • We’re focusing on packages, not the packager.
  • We’re going for minimalism, both in look, feel, and feature set.
  • We will not base this new Fedora Community on the UI we have now. It’ll be a fresh start (but of course we’ll make use of pre-existing research, backend, and other components in enabling the new UI.)
  • This thing is gonna be fast so strap on your seat belts!
  • We need a re-branding. ‘Fedora Community’ is too vague and non-distinctive. Ideas?

  Homework

  Here’s our homework! (Note ‘next week’ on this whiteboard means Thursday this week. Eep!)
  

  What do you think?

  Well? Comments are open. Do you use Fedora Community? Do you have an amazing idea for a new name for it? Are you down with the Zen approach or have we taken minimalism to the extreme here? Are you terrified by what we are proposing? Or overjoyed? Let’s hear it.