Short Run by J.D. Hancock on Flickr (Used under a CC-BY 2.0 license.)
The Background Story
I come from a background strongly focused on communication; my Human-Computer Interaction masters’ degree was out of RPI’s Language, Literature, and Communication Department and my coursework was built on language, literature, and communication as a foundation to understanding newer digital communication methods. I may be biased, then, in thinking a lot of the angst (E.g., It’s Scary to Join an Open Source Project, Customer Support, The Simon Cowell Way, Channels for Community Communications) around getting things done in free software is coming to a crescendo because our tools for basic communication are not serving us well as we scale larger, and fixing that problem has massive potential to better the free software community.
Two years ago now (*sob*!) Luke Macken and I came up with some ideas for a web-based mailing list interface that would complement (not replace) mailing lists as they are today. We’re both pretty busy though and have had a ton of projects we needed to work on for our jobs, so neither of us have really done much with it since then. However, the post is one of the most widely-referenced and popular posts on my blog – maybe a good indicator of an idea worthy of time investment. Honestly, I really really want it to happen, and occasionally have wonderful dreams about it that make waking up to the reality of mailing lists a bummer.
A New Hope
So, over the past couple of weeks my team has been devising a plan for what we’ll work on over the next year, and fixing mailing lists made the cut!
I feel good…!!! by Lenora Enking on Flickr (Used under a CC-BY-SA 2.0 license.)
So, expect to see some more mockups and workflows for a potential mailman archive web interface revamp, then. 🙂 Pingou and Toshio are on-board as well and have started talking to Barry and the mailman developers who are in the planning stages right now of a revamped webui for list archives. We’re very early stages in discussion right now.
I recently joined the mailman-developers mailing list, joined #mailman on freenode, and set up a an area on the fedora-ux git repo to start throwing out UI ideas for it. I’ll make blog posts about this project under the Mailing List Improvements category.
Okay, Here’s Something to Look At
Click on it. It’s 7,750 pixels tall. Probably the longest mockup I’ve ever made. It’s really just a rough idea of what a view of a single, real-life fedora-devel thread might look like in a mailman web UI. There is nothing here that is wedded / married to anybody or anything, so please blow away. The visual design could stay or go. Maybe we could support different visual styles for different communities.
Please leave comments here in the blog comments if you’ve got any feedback / advice on this. Does it seem like something that would be natural to interact with? Here’s some notes on it with some questions for you, thanks to some good questions / comments on identi.ca, on Twitter (the thread is really broken on their webui though. Twitter: 0 Identi.ca: 1), and in #fedora-apps today:
- We waffled back and forth on this in IRC today, but I think we concluded what’s in the mockup is right: in the very top header, you click on the left-facing arrow to go to the next-newest thread, and the right-facing arrow to go to the next-oldest thread. You read a book from left-to-right, oldest content to newest content… but I think you read mailing list threads from newest-to-oldest. (Once within a thread, however, you read the messages from oldest-to-newest until you’ve caught up.) I think then, treating threads as newest-to-oldest is the right way, so the current mockup arrows / positions for navigating between threads make sense.
- Replies don’t have buttons to reply to them. Whoops. They need ’em.
- Threads have a value. Potentially a category too. (The category in the mockup is ‘Question’) This value helps users figure out which threads to skip and which ones to pay attention to.
- Individual messages in a thread have a value. Think Slashdot. When you first go to Slashdot, troll-y messages with low moderation ranks are hidden from your view by default. A very interesting and insightful thread still might have some useless noise in it; giving individual messages in a thread each their own value will help filter the bad apples out.
- People have ranks. If Matthew Garrett posts a message detailing what you should do to fix your laptop, it’s a lot more authoritative and trustworthy than Binky the Clown telling you what he thinks you should do to your laptop in his debut list post. Serial trolls also have a rank – it’s not very high.
- There’s a lot of different ways to display a rank for a given concept (person, thread, post.)
Although Toshio and Pingou like YouTube’s ranking widget with bar graph, number of votes, and total vote count (example), it is a bit heavy for individual messages within a thread, so something lighter-weight should be chosen there.- There are a lot of different people-ranking systems. You could give folks a rank number, or a military-style rank with a title. Some forums have ‘stars’ you earn over time. We’re not sure what works best yet in a mailing list context.
There are progress bars per thread for the number of participants and comments. These are meant to give you an idea how how ‘crowded’ and how busy a given thread is. E.g., if a thread has 500 people and 500 messages, it’s going to be flavoured a bit differently than a thread that has 2 people and 500 messages. 🙂- There’s a little arrow in the upper-right notch of each comment. I was thinking that could be a drop-down menu for less-commonly used utilities like, ‘report as spam’ or ‘link to this comment.’
- The full date is only displayed in comments where the date changed between comments. Only the time is displayed if the comment was made the same day. (maybe weird? I didn’t want to clutter everything with a full date/time stamp on every single comment.)
On the Queue
Some ideas mockup-wise I’ve got in the queue to explore for this:
- A mockup to show a profile page for folks in the thread. It might talk a bit more about the stats that gave them their rank, and show their most-liked posts, and recent activity.
- For this single-thread view, a way towards the top of navigating straight down to particular sub-threads, and a way to jump back up to the main post. Maybe. I’ve been thinking about playing around with this.
- Again in the single-thread view, some kind of ‘hide all’ or ‘collapse’ for threads, or a more minimal (vertically) view.
- Again in the single-thread view, a mechanism to vote / change the category of the entire thread. Is this something admins only can do, or can individual users vote on this?
- Single-thread view again, display the mechanism for the thread’s rank itself (if needed; maybe the category is enough)
- Place this same exact thread in a variety of different ‘styles’ (
Slashdot style, phpbb / classic forum style, Reddit style,Facebook style, etc.) to get a feel for how the same exact conversation feels differently in different UI arrangements. - I’m sure more will shake from working on the above, and some of the above will turn out to be abandoned dead ends!
If you want to work with me on the mockups, you can grab the source files from my web checkout of the repo and you could even check stuff into the fedora-ux git repo if you’re a member of fedora-ux in the Fedora account system. (Let me know if you want to join)
lively conversation by Kai Schreiber on Flickr (Used under a CC-BY-SA 2.0 license.)
Well, what do you think? Go nuts in the comments.
UPDATED
(Added a couple more variations on the mockup style to illustrate how we could provide different themes.)
Looks so cool. But please keep a possibility to switch it back, hehe. But I like it.
I have no comment other than (a) it all looks great, and (b) any changes are welcome changes.
This looks outstanding, Máirín. I have been dragging my feet a long time on migrating some old mailing lists I’ve been maintaining from ezmlm over to mailman, and knowing that this might be on the horizon is encouraging me greatly.
This might be well beyond the scope of your role in this whole project, but just out of curiosity, how would the WebUI interface interact with the email-based authorization of a traditional mailing list, and how is it stored on the backend? Would using the WebUI be transparent and equivalent to sending an e-mail to the list?
Yep, if all goes to plan, you can interact either way. So if you only use the web ui, people who only use their email clients will see your posts and vice-versa.
Hooray! This is a fantastic idea. As much as I dislike their privacy policies, I really think Facebook’s idea of “frictionless sharing” is asking the right questions about electronic communications.
I expect this to ultimately fail: many (most?) people will continue to interact with mailing list using a mail interface (mail client, gmail, whatever) so the extra-info (ratings, profiles) won’t be available for them. If there are a lot of people not providing this extra-info, it makes having the extra-info useless, clutter.
It may be a detail, but I don’t like people having ranks. Sure, people are not equal, but this is a *subjective* quantification, for me, if you ask to rank some certain X GNOME developer and Bozo the Clown… I will favor Bozo at any minute, so it is bases on friendship and personal preferences.
If you add enough extra-info (profiles, ratings, friendship) then you have a… social network. Guess what? There are already social networks providing this functionality and they even send email notifications for the posts!
An email archive is a tool to provide *fast* access to previous conversations and maybe a way to allow you to interact with them (reply). To be useful, it has to be lean and fast.
On a side note, as an anecdote: I have friends in FOSS who when need access to the history of some mailing list, they just ask other friends for it in mbox format, so they can import in the mail client.
There is a real problem with mailing lists right now. You must subscribe to participate in 90% of cases since non-subscriber mails are typically blocked to prevent spam. It is a big burden to find the mailing list website, sign up, wait for the confirmation mail, click the confirmation mail, maybe wait for the moderator to approve your membership (or not), and then finally make your post. Even harder, when you have to do this for 50 lists or so and you have to manage all the incoming mails and filtering for these, when your interests and thus your membership desires might change. It is a huge hassle. Folks new to free software who have a lot of great expertise to contribute many times get left at the door here because, honestly, nobody has time to fight it.
Oh and today is mailman day. I have some 20+ odd mailing list server reminder mails in my inbox this morning. What a pain. It’s like shovelling a heavy snowfall in my inbox.
Folks who are comfortable with mailing lists as-is, under this proposal, will not be affected in the least. The only thing that will change for them is that some of the ratings could be provided to them via mail headers, making it easier for them to filter their incoming mail.
Profiles aren’t going to be provided. They will be generated based on a given email address’ activity on-list.
Ratings and categories will be user-provided through the web interface. Right now, moderating a mailing list is a pain in the butt; moderators have to log into a nasty web ui and do a lot of things manually and they don’t have the power to do a lot of things that would make a mailing list run smoother. Even if nobody uses the web interface as you suppose, today moderators must use the web interface, so at the very least if they want to maintain a well-moderated list the tools will now be there for them to do it.
I understand and agree that a given person may have a very high rank from one perspective, and a low rank from another perspective. Whether or not you agree with someone shouldn’t be a factor in their rank. Rather, if they are a spammer, they should be blocked. If they do nothing but flame and don’t contribute much useful, whether or not you agree with them, that is a useful data point. The thing is, individual users are in control of what they do with the data provided / generated by the mailing list. If you don’t want anything filtered or blocked, that’s cool, there shouldn’t be anything blocking you as an individual list user from drinking from the firehose there.
This is not a social network. The point is to have a productive conversation.
An email archive is not a tool to provide fast access to previous conversations if it doesn’t have a search (most mailman archives do not and it is provided by a third-party)
We could definitely ensure than the history of the mailing lists is available via downloadable mbox format as it always has been.
Have you looked at nntp ? Some friends use that because that’s easier for people to subscribe and see threads, etc.
Also, for avoiding getting mail from mailman, there is a setting ( I disable it on each list, and life is much better ).
I like your proposal, except this is based on mailman, and the project I help to administrate use sympa 🙂 ( for ldap integration )
IMO, Mairins got most important things listed. True, most of us will stick with e-mail most of the time. But there are reasons why a listwebUI 2-way-bridge is a neat idea, specially opposed to a web forum. For examples you needn’t look any further than Google Groups.
Another plus for a nice UI would be people arriving via a search engine query. How many time we end up in a mailing list conversation looking for things? And even for people woth mostly email-centric workflows there are times when a webUI can be real nice thing.
While a webUI is mostly about presentation of things already there plus complemetary additions such as tags, ratings, filters, etc., another thing is to have alternative authentication/autherization machanism (than the send plaintext mail back-and-forth dance, and current list preferences page) from current mailman setups. Although this I guess should stem from the mailman backend it self, a webUI can complement it nicely. For example meego.com had an integration where a user can manage list subscriptions in one page.
These mockups certainly look great and is a promising step to a good direction. And did I mention the thing I love probably the most is that search box on top right. Anyone going through a list archive knows why.
To sum it up this is a great initiative. You are looking to solve a problem a lost of peope whish someone had solved. In the same note, it would be even more awesome if the result were to be a generic FOSS webUI for mailman/list manager than just a part of Fedora infra.
“it would be even more awesome if the result were to be a generic FOSS webUI for mailman/list manager than just a part of Fedora infra.”
Oh absolutely, we’re talking to upstream right now.
One suggestion that was forwarded to me was to have some kind of ‘complaint-to-patch-provision’ ratio. So if you just complain about stuff on a mailing list and never send patches to fix things, you might look different than if you do actually send patches in to fix things.
Not sure if this is too controversial, but what about extending this idea to “productive-to-flaming” ratio? I don’t often send patches, but I do try to make my posts productive or helpful and not at the expense of other people’s efforts. Ultimately, someone’s views of my posts would probably not be affected much by “complaints-to-patches,” but they might want to see me affected by “productive-to-flaming” factors.
I especially like the expand/collapse functions, and the subthread markers on the sidebar, which would help me focus on (or avoid) different kinds of subthreads. It might be useful for those to change color or some other marker, based on either (1) overall +/- rating on the thread overall, or, and this might be really crazy, (2) the polarization of +/- ratings on the thread. In other words, the (1) idea is that subthread markers in the sidebar with lots of likes would be more toward color1, and with lots of dislikes they’d be more toward color2. With idea (2), color1 would be for less polarized threads that have overall fewer +/- votes at all, and color2 would be for threads that have lots of +’s and lots of -‘s, which might show a higher degree of emotion in the subthread.
+1 for productivity based ratio. Not all lists deal with patches.
This reminds me of two more cosmetic suggestions. First one is displaying syntax highlighting. Code, config file snippets, log snips, etc. can use this as well as patches to a certain level with diff highlighting.
Second one is how to hangle gpg/pgp signatures. It’s not completely necessary to (nice to have) validate signatures, but at least folding/hidning from the view could be useful.