So, the first time we talked about Hyperkitty recently, I mapped out the current Hyperkitty UI and we talked about future ideas. We also walked through a new mockup for displaying the directory of lists on the server (marked in blue on the diagram below.) Then, following that initial post, we talked about the design of Hyperkitty user profiles, which was one of those ‘future ideas.’ (I’ve also marked that in blue in the diagram below.)
Today we’re going to talk about another one of those future ideas – on the right of the diagram below you’ll see the ‘Tags & Category Directory’ and the ‘Category Overview’ areas, highlighted in yellow.
First, let’s talk through what categories and tags are, or at least, how they function in Hyperkitty today.
Categories
Categories are pre-set in the system – an administrator would have to add or remove categories, these are not something a user would be able to make up and apply to discussions. However, from the defined set of categories, any user can mark a thread with a given category. This brings up the next point: categories are used to categorize an entire discussion or thread… they don’t apply to single posts in a thread. Here’s a few example categories:
- Question – This category is used to mark question & answer threads, started by a user with a question and where the discussion centers around coming up with an answer to that question.
- Schedule – This category is used to mark threads that either discuss upcoming schedule milestones or involve coordination around a schedule.
- Bug – This category is used to mark a discussion about a bug, and hopefully make it easier to generate a list of bugs across mailing lists in order to file them. (What could make a really cool plug-in is a button on threads marked ‘Bug’ to automatically copy them into Bugzilla.)
Tags
Tags are, well, tags – as you know them elsewhere on the internet. Users can use any tag they want and they can apply to individual posts in the thread. If you want to ‘tag’ a discussion, you could add a tag to the first post in the thread.
Okay, sounds good. Why should I care?
Why would people want to use these?
Well, first of all, traditionally the organization of mailing list archives is via list, month, and year. Unyieldingly so. What happens if a particular topic spans multiple lists? For example, perhaps the fedora-advisory-board list kicks off a discussion about the next upcoming Flock, then that moves to a flock-planning list, and then as the event gets planned, the design-team list gets involved in the T-shirt and collateral design, and the marketing list gets involved in getting the word out about the conference. Fast-forward to a year later, and it’s time to plan the next Flock. Wouldn’t it be great to be able to easily read through how things went down last year to see what worked and what didn’t, as to improve the experience this next year? You could tag all of the flock-related posts with the tag ‘flock,’ or you could try to push all of the threads into ‘Event’ category.
Now the scenario I illustrate above does rely on some manual intervention, in that someone involved needs to be using the web interface in the discussion and needs to make the effort to click on the category and/or tag controls to mark the discussions. (It would be cool to have tags automatically applied based on keywords in a post, maybe have a whitelist of terms we care about and if they appear they are added or suggested as a tag?) I think we need to see how categories and tags work a simple manual application model first, though, before we get too fancy. (What if we implement some kind of Bayesian filtering to automatically apply categories, for example? Hehe. But that’s a lot of work if the categories and tags feature doesn’t pan out to be useful, so let’s not waste the effort before we understand how things shake out first!)
We’ve gone into a bit of a tangent, though. Okay, so categories and tags could be a good way of bridging the barriers between lists when a topic spans multiple lists. They would make it easier for folks looking to easily access the history of a given topic. Why else would a user want to use categories or tags? Here’s a few more scenarios:
- Working a Queue: I want to help newcomers on a list and make sure their questions are answered, so every week or so I’ll check the ‘Questions’ category on my list and go through the question threads, making sure each question receives a suitable answer.
- Planning for the Future: I’m planning my travel budget for the next year, so I want to view a list of all of the upcoming events that have been discussed on the lists I’m subscribed to. I check out the ‘Events’ category for my subscribed lists.
- Learning About a Topic: I’m trying to figure out how to get a bluetooth speaker working. I’m wondering what the current state of bluetooth is right now. I pull up a list of all posts that have the tag ‘bluetooth’ to see if this feature is supported yet and if anybody has discussed making it work.
- Active Collaboration: During wallpaper brainstorming season, we have a lot of mockups fly-by on the design-team list. Typically we brainstorm different visual ‘themes’ and then work in groups to create visual mockups to go with the theme, riffing off of each other’s work until we get final mockups we think represent the final theme. For example, I’m making this up, but one release we might have a ‘gears’ theme and a ‘flowers’ theme. Any threads or posts containing mockups along the ‘gears’ theme could be tagged, ‘gears’ and ‘fedora-artwork’ and then any in the ‘flowers’ theme could be tagged ‘flowers’ and ‘fedora-artwork.’ That would make it really easy to see all of the work done (under ‘fedora-artwork’) if you’re trying to decide which theme is best, or to see all of the works along a theme (e.g., under ‘gears’) and look at them that way.
- Search weighting: If someone searches for ‘fedora artwork’ in Hyperkitty’s search, and there’s a tag with all sorts of lovely pieces attached to it already, the things that are tagged with the term could be included in the search results too, even if the only way they include the search term is via the tag and not in the actual message content.
Certainly, though, the strongest case for both the category and tag mechanisms is easier future access of past discussions and this purpose is threaded through many of the example scenarios I give above. On a number of mailing lists I’m on – not just Fedora ones – I have noticed that topics come up sometimes in a cyclical nature. It’s hard to go back and look up the last time the topic came up to see how it was resolved (if at all) the last time. If someone asks a question that has been already asked and answered 359 times, categories and tags would make it easier to dig up a link with good reference information to point that person to. (‘Go search the archives’ in today’s mailman is a daunting thing to ask someone to do – you expect someone to manually scan subject lines month-by-month, year-by-year, if they even know which list to look under? Heh, I’ve done this before, but it sucks!! This is a good way to turn off newcomers!) If the information is easier to access, though, maybe we’ll find that people ask the same questions over and over less because we made it easier for them to find.
You’ve sold me. Show me those mockups!
Well, hopefully there’s at least a partially good case here for having tags and categories, and we’ve got some decent use cases in mind for why they’d be useful. To the mockups, then?
Category List
In this screen you get a listing of all of the categories in the system. As noted above, these are static – you really have to be an admin of the whole mailman instance to add or remove these. These aren’t intended to change very often, but they could be customized per site. (By default though, they should come with a good stock set.) There’s a way to suggest a new category in the upper right, which should bring you to a form that might submit it to an admin panel somewhere.
Anyway, per category you can see per time period (here we’re looking at the past 30 days) the activity under each category. Click on the category, and you’ll get the Category Details page, which is next…
Category Details
In this screen you can see what kind of information you can get about any single category. The example category we chose here is ‘Question.’ Per list on the mailman server, you’ll get a rundown of the discussions that were held under that category. You could filter it down to only view the lists you’re subscribed to in this list (see ‘My Lists’ button.) By default, it’s in alphabetical order per list, then in date order of most recent to oldest. You could click on the ‘Age’ header and view all across the lists in date order instead.
Thinking About Tags
I’m still working on a tags overview mockup and tags details mockup. I’ve done the tags overview a number of different ways, but I’m still not happy with the results. What do you think – should we show tags as a tag cloud or a more simple directory like on ask.fedoraproject.org’s tag listing?
Also, what about composing tags? What if you wanted to see all posts that were tagged with both ‘fedora-art’ and ‘gears’, as in the example given above? How would you view that composition? What if you wanted to throw a category in the mix? Too crazy? Maybe provide the functionality through a RESTful interface and keep the UI bits simple?
What do you think?
I would love your thoughts and feedback on any aspect of this! I look forward to chatting in the comments 🙂
Hi Mairin!
On tag lists vs clouds:
We discussed this on the infra list recently. We couldn’t really make a clear decision on which form was better. Ultimately, I decided to go with lists:
– The look neater, better organized.
– They provide numbers, which clouds do not.
I’ve found a post that talks about why clouds are used here:
http://www.perceptualedge.com/articles/guests/whats_up_with_tag_clouds.pdf
I’ve created screen-shots showing a tag cloud and list from the Ask Fedora staging instance so you can see and decide for yourself:
http://ankursinha.fedorapeople.org/ask-fedora-tags-screenshots/
I still can’t decide between them. I just think lists are neater, but that’s probably a personal preference rather than a well thought of decision.
Ankur