Hyperkitty UI overview and list directory ideas

I emailed Aurélien early this week to see if I could help with HyperKitty. He said he would appreciate a UI review for mistakes and some help with icons too. Since it has been a very long while since I’ve been involved with HyperKitty, and a few months since I checked out the HyperKitty test server, I decided to do a review of sorts of the whole UI, check out how it works now, and brainstorm some ideas to make it better.

Mapping Out the UI

So first I clicked like a maniac and got a feel for the overall site structure. Then I drew up a site map to document the structure:
Thinking through the design as I was clicking through it, I noticed a two major-ish features that I thought would make the app better:

  • There aren’t user profiles. Each thread shows a list of the people involved in it as well as who wrote each individual post (of course.) This seems like a bit of a missed opportunity though. One of the strengths having a web app on top of the mailing list would allow in improving list communication is a bit more intelligence / smarts about the conversation – making up for cues you’d be able to benefit from in a real conversation. For example, how knowledgeable is a given person writing a message about a project? If you haven’t been following the list for a long time, you might not know that a person who is speaking so authoritatively has only been involved with the project for a week, or maybe doesn’t even really know anything about it at all. So it seems like it might be helpful to have a concept of profiles on the users, if anything, to see what other threads a given person has posted to, maybe even what other mailing lists they’re involved with. If they get really high peer ratings for their postings, there should be a place to display that as well.
  • There isn’t a way to view all posts in a certain category / under a certain tag. While the search system seems pretty good, it might be nice to be able to view posts by category or tag, especially for historical reference purposes. For example, the Fedora Design Team might create a ‘f20wallpaper’ tag and tag posts about the Fedora 20 wallpaper with that tag. Later on, a question might come up about the wallpaper or design from that release – so you could just visit the ‘f20wallpaper’ tag page to get a list of all threads about the f20 wallpaper to find the information you were looking for.

There’s a few other things I noted that I’m not going to dive into as much in this post because I haven’t done any further thinking or sketching around them:

  • Moderation information: It might be nice to have information about the moderators of the lists and the policies of each list. If you asked me who the moderator for a given popular Fedora list is, in 99% of cases I would have no idea. (The 1% would be the list I admin 😉 ). Maybe this is a problem. Maybe (and I bring this up because it was a recent Fedora Board public meeting topic) if the moderators were more visible, they would feel more empowered to step up and serve as more of a calming force on the lists when they get a bit wild. Maybe…
  • Message nesting: After trying to read through some long and very deeply-threaded devel list threads, I’m beginning to wonder if the message nesting (which, btw, Aurélien did an awesome job implementing) makes the thread harder to read. I’ve talked to a couple of people who follow these high-traffic lists and they use their Gmail accounts to read through them, and the way Gmail functions, nested threads are basically displayed flat. They seem to be happy with reading them this way though. How do you read mailing list threads – do you find the visual indentation to indicate nesting useful, or distracting? This is something that needs more research and thinking I think.
  • Back-linking: This is super-minor I noticed that when you’re viewing any single email from a thread, there is no link back to the thread from which it came from. This might be nice to add.

Okay, so with the user profiles and category/tag listing ideas in mind, I drew up a potential future site map to show how those features could fit into the existing UI:

Redesigning the list directory

One of the other things I noticed in my review of the UI is that the list directory page (‘available lists’) didn’t seem very scalable, and all of the mailing lists were given a visual treatment such as they were equal when they aren’t, necessarily. (I did actually originally mock up the list directory close to how it appears today and completely forgot about it. Here is a clear example then, of a designer disagreeing with her past self 🙂 )
Anyway, this last point about unequal lists appearing visual equal is most severe in the current mailman list UI:
Some of the things I noticed reviewing the current Fedora (old) mailman full list directory:

  • Some lists are dead. There are lists for projects that I’m pretty sure are long dead, some which even say they’re dead in the description, and some which are year-specific (e.g., there are flock-2013 lists that I’m sure in 2020 might not deserve a visual treatment equal to that of devel. If, of course, devel exists then, which hopefully it does. 🙂
  • Some lists are much, much higher-traffic than others. You may want to know before you sign up for a list just how high or low traffic it is. Signing up to a high-traffic mailing list with 50 messages a day is a much bigger commitment than signing up for a low-traffic announcement list that sends out 1 message every 3 months.
  • There are clear patterns in the list names. Some of the ones I called out are -devel, -announce, – (e.g., -latam), – (e.g., trans-), -tickets, -commits, -users, and -community. What might work better, and make for shorter list names, is enabling categorization of lists. Categories would also help display the lists in a more browseable format that a single alpha list with hundreds of items.
  • Some lists are singletons, some are part of a family. For example, the 389 project has a family of lists – 389-announce, 389-commits, 389-devel, 389-users. Is there a way to group these together to make it clear they’re related beyond just the name?
  • Some lists are regional or language repeats of cross-project lists For example, there’s a list just for Ambassadors in Italy. Could it be a compelling feature to highlight lists relevant to your location based on your GeoIP or browser language maybe?
  • Some lists are private. It’s not clear from the directory which lists are private and which are not.
  • Some lists are kind of robotic. E.g., there are lists that are just streams of commit messages or bug filings and don’t have a lot of human discussion (although some do, in the form of discussion threads in response to a robo-message. Would it be worth calling these out differently to set user expectations appropriately?

Categories of ListS

I wanted to play around a little bit with the idea of categorizing lists. So I went through the full list of current Fedora mailing lists and made a bit of an analysis of them, sorting them into different buckets and coming up with category names for them. At first, I had one category for SIGs + projects, but quickly came to realize the vast majority of lists were going under that bucket, so I ended up splitting out SIG lists and project lists into two separate categories. Here’s my little sketch of lists and categories – do you agree with the categorizations? Did I miss anything?
Now that I had a nice set of categories and lists to go under them, I started playing with how they could be displayed in the list directory in HyperKitty:
A few things about this mockup:

  • ‘All’ category: I thought it was important to have an ‘all’ category so you could easily search for a given list that you know the name of but not which category it’s under. You could use your browser’s in-page find feature to pull out the desired list from that ‘all’ category list.
  • ‘Statistical’ categories: Along the theme of all lists not being equal, and some being high traffic and some not – I thought it might be interesting to have categories of lists based on their activity (volume of posts) and popularity (number of subscribers.) What do you think?
  • Category categories: These are the categories I came up with in the analysis of the current lists. I think for each Mailman installation, this is something admins would have to do on their own – HyperKitty could potentially provide a way to create categories and add lists to them, but it wouldn’t do that for you by default – it could only offer the ‘statistical’ and ‘all’ categories by default.
  • ‘New’ flag: I noticed in my perusal of the full list of Fedora list that there were quite a few lists that had been created recently that seemed interesting. I wouldn’t have noticed them unless I had been carefully reading line-by-line the full list of lists – something I think most people just don’t do. So I thought it might be helpful to call out new lists with a spin on the old-school style ‘NEW’ icon.
  • Sparkline-style bar graphs for list traffic – Aurélien has some really awesome graphs on the individual list overview pages but it’s a shame you can’t use that data when comparing across lists. So, why not have some sparklines in the list directory to enable that?
  • ‘Dead’ lists are greyed out – lists that haven’t had any postings in the past 3 months or so are displayed with a grey background to show they’re not super alive right now.
  • High-activity lists are called out in magenta – but maybe this is overkill. Maybe if their sparkline graphs were darker this wouldn’t even be necessary. (I did this before I added the graphs.)
  • Private lists are called out in teal – and it’s not possible, I suppose, to display statistics for these lists since the archives aren’t available. Which brings up an interesting question – if you are logged in and are a member of these private lists… perhaps the stats should be available to you, and they should be displayed differently. Oh! Another idea – should lists you’re actually subscribed to, private or not, be called out differently than ones you’re not subscribed to?
  • More list metadata displayed at the directory level – the number of posts and number of users in the past 30 days are displayed in this directory view. In the current HyperKitty UI, you have to drill down to individual list details pages to get this information.

All right. I guess that’s enough for now. I dipped my toe a teensy tiny bit into mocking up a category/tag directory page, but there isn’t anything worth showing yet. Anyway this is my thinking on HyperKitty this week. Let me know what you think!


  1. gabriel

    I like the thoroughness and attention to detail that was offered with these suggestions and descriptions of the thought processes behind them. This helps the overall quality of the craftsmanship.

  2. David Malcolm

    Excellent work, as ever.
    Is there a 1:1 mapping from list to categories, or can a list be in multiple categories? (so that categories are more of a tagging thing than a rigid subdivision) The “python-devel@lists.fp.org” list is close to my heart, and I see that you put it under “Projects”, but it could equally be listed under “SIGs” or “Technical Teams” – so perhaps it could appear under all three?
    Looking again, I see you have “Categories/Tags” in the final mockup, so perhaps you’ve already answered my question 🙂
    Anyway, I hope that’s useful feedback.

    • mairin

      sorry for the super-late reply, I had some other deadline-driven stuff I had to crank on since I posted this!
      I was thinking there would be a 1:1 mapping for categories, and tags would apply to posts across lists.
      However, you do make a good point, so I don’t see why a list couldn’t be in more than one category. I was initially thinking of the 1:1 mapping because I was thinking the mailman server admin would dictate the category – but perhaps the individual list admins know their domain the best and would be better suited to decide which categories their list fits into, and maybe have the ability to create additional categories if the ones there don’t suffice?
      Does having tags apply to threads cross-list make sense? I was thinking it would be good because especially with the design team, we have project conversations that cross the design team list, marketing list, logistics list, etc. so it’d be nice to see all threads related to a specific project regardless of the list they were posted to.

  3. David Malcolm

    You mention language a couple of times, but perhaps it’s worth spelling out – the social convention is that discussion on a mailing list happens in a particular (human) language: typically English for our development lists – but currently AFAIK that isn’t captured in the list metadata. This seems like a useful thing to have an actual metadata field for, and be something to show in the UI.
    Hope this is constructive

    • mairin

      That’s a good way to think about it. The one thing I worry about is since the majority of lists are English, listing out the language in most cases would be really redundant. I’m trying to think of some way to display it without it being repetitive…

  4. User profiles
    Agreed, I’ll work on that.
    There isn’t a way to view all posts in a certain category / under a certain tag
    There is, so I guess it should be made more usable: when you set a tag on a thread, the tag itself is clickable and will lead to a search page for all threads with this tag. All tags are actually links to a search page.
    Moderation information
    I can certainly add some sort of “information panel” with details on who’s moderating the list. Are you also thinking about some sort of “Report post” link that would notify the moderators?
    Message nesting
    There is a “Sort by date” link on the right before the first reply. Should it be made more visible? By default maybe? (should the default be changeable in the user profile?)
    Uh? There should be a “Back to thread” button at the top, does it not display for you?
    List categories
    I agree with most, if not all, you’ve written here. Great ideas.
    There is no “list category” in Mailman at this moment, so this is something that should be implemented purely in HyperKitty, and it feels strange to do it there since it’s more a “list property” than something related to archiving IMHO. Oh well, I’ll find a way. @Dave: I’ll make sure a list can have mutiple categories.
    Great work Máirín, thanks.

    • mairin

      Hey Aurélien!
      There isn’t a way to view all posts in a certain category / under a certain tag
      Oh okay, I see the tag page now – fantastic. What I’m thinking of, beyond just clicking on a pre-existing tag to see what’s under it, is sort of a directory of all the tags that have already been created if that makes sense? Something browseable? Not sure if it’s necessary though. I think most people will search anyway, but kind of like how people aren’t consistent with twitter #hashtags so content about the same topic gets strewn across different hashtags… it might be good to have a place that shows the most popular tags so people know which to use, maybe? Or maybe better – when you type in the ‘add a tag’ field, it autocompletes with tags that others have already used?
      Moderation information
      Yep, having some kind of ‘report to mods’ button might be good too.
      Message nesting
      Ah, I hadn’t noticed the sort by date option! Yeh, I think it might be good to do something with it so it’s more noticeable.. I’ll play around with some ideas, I think this is mostly a visual design issue, the placement you have I think makes the most logical sense. Having it as a user preference would be fantastic!
      Back Linking
      As I’m clicking around, I see the back to thread button now! I definitely hit some pages where it didn’t display before though, I’m not sure how. If I run into it again I’ll email you an url!

  5. Pingback: Pokračující práce na HyperKitty – archivátoru poštovních konferencí | Fedora.cz

  6. Pingback: Hyperkitty user profile idea | Máirín Duffy

  7. Pingback: Hyperkitty categories | Máirín Duffy

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.