mailman 3: webinterface: prototype (PDF)

Greetings,
following our discussions at the Pycon 2009 Mailman sprint I've come up with first draft of a/the future mailman 3 web interface.
The interface has changed a lot. Changes follow these principles:
- Simplify interface
- Focus on tasks
- Order and sort by task recurrance
- Reduce information overflow e.g. by hiding help messages
- Show help messages as bubbles when selected by user
- Remove instructions on using a web from
- Use default button texts e.g. "Save" instead of "Submit your changes" See also: <http://wiki.list.org/display/DEV/Rest+client>
I've come up with a paper prototype, which you can download in an annotated PDF by clicking at "Mailman webinterface draft" at the following location:
<http://wiki.list.org/display/DEV/Information+Architecture>
Important The version you can download is _not a design_. It's a grid that creates a structure, puts elements we need on a (HTML) page, orders and groups them following the principles I've outlined above.
Please feel free to comment on it and ask questions. I've spent the last 5 days clicking the old interface, thinking and sitting before my current proposal - I just might be blind to my own stupidity or brain dead by now. ;)
My goal is to agree on an information architecture, so we can go on and create a design that combines functional requirements and aesthetics.
Once we've agreed on a design, we will create HTML templates and then we will put them together with the upcoming REST client.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

On Apr 23, 2009, at 11:16 AM, Patrick Ben Koetter wrote:
Patrick, thanks very much for doing this. I think it's a good way to
begin the discussions.
One thing that it would be good to think about is how MM3's improved
model can make navigation and configuration easier. For example, when
a user is thinking about her subscriptions, she needn't be constrained
to a list-centric view. In MM2, certain global operations were pure
hacks, and a user always had to see a list-centric view. For sites
that run many inter-related mailing lists, the user will probably want
to get a more general view of their subscriptions and options.
On Launchpad for example, they can go to one page that shows all their
subscriptions. Each mailing list that they are (or may) subscribe to
is listed on one page, and each has a pull down menu that lets the
user unsubscribe (i.e. not subscribed), subscribe with their
"preferred email address" (a concept not yet exposed in Mailman, but
which could be), or subscribed with a specific address.
This is nice because they can pretty easily manage all their
subscriptions from one page. You could imagine other global-ish
things on this page, like vacation settings, or default site-wide user
options. This page might also contain widgets for registering and
confirming additional email addresses linked to the user account.
On the list-admin side, another thing to think about is the
application of styles. A style needn't be just something that can be
applied when the list is created. Say for example, there is a "micro-
style" that lets them disable digests and select a standard
personalized footer. That might be a style available to the list
owner on their list page.
I do like the idea of a notifications area with a list of things a
user can do (i.e. the "3 pending"). This of course would be linked to
task-oriented pages for addressing those things. A user might also
see a list of registered emails that need confirming (with a link to
send another confirmation message).
That's all for now. -Barry

- Barry Warsaw <barry@list.org>:
Agreed. We discussed that at the sprint and I think the navigation structure I have come up with allows for that:
<http://wiki.list.org/display/DEV/global+requirements#globalrequirements-Navi...>
Here's the excerpt of a users navigation structure:
options general topics plugins subscriptions subscribe remove modify statistics List
A (regular) user, for example, would do this to see a list of all current subscriptions:
Go to top level menu item: "subscriptions"
This will show a list of all current subscriptions that could be
individually choosen for "unsubscription" or "modification".
Also all subscriptions could "inherit" applicable settings from the
currently choosen account.
If user wanted to subscribe another list a subpage would have to be choosen. This page would list all available subscriptions. It's a separate page on purpose to prevent information overflow if we'd put it all in one page.
What do you think? Should I comment the navigation structures? I've put a lot of thinking into it and that is, of course, not visible. I could comment and we'd have it easier to see where I think things should be put to.
Yep.
This page might also contain widgets for registering and confirming additional email addresses linked to the user account.
Agreed, but having the concept of a task-oriented navigation in mind I'd probably put this on the users personal homepage.
On the list-admin side, another thing to think about is the application of styles. A style needn't be just something that can be applied when
Style as in "profile"?
Just to think of two prototypes:
Techi-Profile No HTML Mail No Attachments
Party-Profile HTML Mail Attachments
Yes. They have to functions:
- Notify user if (!) attention is required (hide otherways...)
- Provide quick-/deeplink into the lower navigation levels without having the user click through tons of navigation levels (or even worse clicking through the whole site because they don't remember where it was).
That's all for now.
We will start working on design May, 1st. Minor changes to pages and elements are possible. I'd like to avoid major changes after that - the effort of redoing design is immense.
Think we can get the discussion to a point of "let's start design" 'til then?
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

On Apr 27, 2009, at 5:11 AM, Patrick Ben Koetter wrote:
That does sound good. Comments, or some other way to capture your
thinking behind it, would be good.
Agreed.
In a sense. Technically, a "list style" is just a named collection of
list variable settings, so it could be anything. The plan is to allow
site admins (and maybe list admins) create new styles, which would be
applied by name.
+1
I think so. I'll be largely unavailable the second half of May. In
the meantime, I'm still working on the REST infrastructure.
-Barry

- Barry Warsaw <barry@list.org>:
I created a separate page for each role (admin, moderator, subscriber) and added notes to each menu item. If you want to start with a top view, start here:
<http://wiki.list.org/display/DEV/global+requirements>
Then, in each subsection of "Navigation Structure" choose "See a commented <role> navigation structure."
To jump right at it:
administrator navigation structure
<http://wiki.list.org/display/DEV/administrator+navigation+structure>
moderator navigation structure
<http://wiki.list.org/display/DEV/moderator+navigation+structure>
subscriber navigation structure
<http://wiki.list.org/display/DEV/subscriber+navigation+structure>
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

I love how you've put all this thought into a better structure here. But no matter how much thought goes into it, someone's gonna have trouble finding stuff in a tree that big...
Can we add a search box for options? It might not be necessary on the smaller pages, but the full admin/owner interface looks like it's still going to be sufficiently busy that it could help.
Can we please please please do some user testing on the initial designs before they get set in stone? Ideally, I think we'd want to do this at the point where there's a clickthrough prototype. Then we could sit some people down and ask them to do some tasks, and see how long it takes/where they go wrong. Plus we could get general impressions on usability from the mailman-users list.
Terri

Terri,
thanks for taking the time to read my proposal and writing this email.
- Terri Oda <terri@zone12.com>:
Yes. For a list owner this seems acceptable to me. Those are the ones who are willing to spend some time - they expect a certain level of complexity because they know the software is complex.
For a regular subscriber the interface should be as simple as possible (but not simplier or they will think we believe they are stupid ;).
We can. But I, personally, would want to wait for usability test and see if we can do without it simply because it makes the interface more complex.
Reason is, I have planned search boxes for several other use cases e.g. finding a subscriber, a mail address etc.
I would rather not have two search boxes fanning out ambiguity and competing for user attention - unless we need to.
I do believe complexity is a deliberate decision.
Yes, very welcome.
the point where there's a clickthrough prototype. Then we could sit
some people down and ask them to do some tasks, and see how long it
The test scenario affects the outcome of the test. We need to standardize the test before we run it. I might be able to get some people from a usability lab we work with help us. Let me check that.
takes/where they go wrong. Plus we could get general impressions on
usability from the mailman-users list.
We should also manage the change actively e.g. provide a little website that explains why things have changed, where they have gone etc.
The goal would be to re-empower the people and give them the security back they have accquired using the old interface over the years.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

Patrick Ben Koetter wrote:
Well, here's some user data from a recent mailman-users post
http://www.mail-archive.com/mailman-users%40python.org/msg53494.html
This is a *common* way for people to find things in the current mailman admin interface, sadly. I've watched people do it and had people tell me in person that's how they find things too. Most people who maintain mailing lists do settings changes infrequently, and often under some time pressure. And they never have time to learn the menu hierarchy unless they maintain a lot of different types of lists. And often not even then. There's a lot of options there, and most people nowadays are used to the google method of finding things. ;)
I totally understand not wanting to add too much extra, but... my user observations thus far imply that this is a feature that would be used heavily.
I'm an academic researcher professionally, so I'm well aware of issues in testing methodologies. But honestly? Don't get caught up in doing Perfect Science here. Even a quick, dirty, messy user study would give us a lot of information that could be useful. The current interface suffers badly from lack of user testing, and I'd hate for the same to be true of the new one.
If you need more help with user studies, I should be able get some help from the usability research lab here. I know one of the profs here expressed interest in mailman usability in the past, and we may be able to find people willing to work on the problem.
Terri

- Terri Oda <terri@zone12.com>:
Agreed. If it helps we will find a place for it.
Believe me. I won't. ;)
Yes.
That would be the perfect opportunity. Please ask him if he's still interested.
The question is: How do I get there. I life in Munich, Germany.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

On Apr 23, 2009, at 11:16 AM, Patrick Ben Koetter wrote:
Patrick, thanks very much for doing this. I think it's a good way to
begin the discussions.
One thing that it would be good to think about is how MM3's improved
model can make navigation and configuration easier. For example, when
a user is thinking about her subscriptions, she needn't be constrained
to a list-centric view. In MM2, certain global operations were pure
hacks, and a user always had to see a list-centric view. For sites
that run many inter-related mailing lists, the user will probably want
to get a more general view of their subscriptions and options.
On Launchpad for example, they can go to one page that shows all their
subscriptions. Each mailing list that they are (or may) subscribe to
is listed on one page, and each has a pull down menu that lets the
user unsubscribe (i.e. not subscribed), subscribe with their
"preferred email address" (a concept not yet exposed in Mailman, but
which could be), or subscribed with a specific address.
This is nice because they can pretty easily manage all their
subscriptions from one page. You could imagine other global-ish
things on this page, like vacation settings, or default site-wide user
options. This page might also contain widgets for registering and
confirming additional email addresses linked to the user account.
On the list-admin side, another thing to think about is the
application of styles. A style needn't be just something that can be
applied when the list is created. Say for example, there is a "micro-
style" that lets them disable digests and select a standard
personalized footer. That might be a style available to the list
owner on their list page.
I do like the idea of a notifications area with a list of things a
user can do (i.e. the "3 pending"). This of course would be linked to
task-oriented pages for addressing those things. A user might also
see a list of registered emails that need confirming (with a link to
send another confirmation message).
That's all for now. -Barry

- Barry Warsaw <barry@list.org>:
Agreed. We discussed that at the sprint and I think the navigation structure I have come up with allows for that:
<http://wiki.list.org/display/DEV/global+requirements#globalrequirements-Navi...>
Here's the excerpt of a users navigation structure:
options general topics plugins subscriptions subscribe remove modify statistics List
A (regular) user, for example, would do this to see a list of all current subscriptions:
Go to top level menu item: "subscriptions"
This will show a list of all current subscriptions that could be
individually choosen for "unsubscription" or "modification".
Also all subscriptions could "inherit" applicable settings from the
currently choosen account.
If user wanted to subscribe another list a subpage would have to be choosen. This page would list all available subscriptions. It's a separate page on purpose to prevent information overflow if we'd put it all in one page.
What do you think? Should I comment the navigation structures? I've put a lot of thinking into it and that is, of course, not visible. I could comment and we'd have it easier to see where I think things should be put to.
Yep.
This page might also contain widgets for registering and confirming additional email addresses linked to the user account.
Agreed, but having the concept of a task-oriented navigation in mind I'd probably put this on the users personal homepage.
On the list-admin side, another thing to think about is the application of styles. A style needn't be just something that can be applied when
Style as in "profile"?
Just to think of two prototypes:
Techi-Profile No HTML Mail No Attachments
Party-Profile HTML Mail Attachments
Yes. They have to functions:
- Notify user if (!) attention is required (hide otherways...)
- Provide quick-/deeplink into the lower navigation levels without having the user click through tons of navigation levels (or even worse clicking through the whole site because they don't remember where it was).
That's all for now.
We will start working on design May, 1st. Minor changes to pages and elements are possible. I'd like to avoid major changes after that - the effort of redoing design is immense.
Think we can get the discussion to a point of "let's start design" 'til then?
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

On Apr 27, 2009, at 5:11 AM, Patrick Ben Koetter wrote:
That does sound good. Comments, or some other way to capture your
thinking behind it, would be good.
Agreed.
In a sense. Technically, a "list style" is just a named collection of
list variable settings, so it could be anything. The plan is to allow
site admins (and maybe list admins) create new styles, which would be
applied by name.
+1
I think so. I'll be largely unavailable the second half of May. In
the meantime, I'm still working on the REST infrastructure.
-Barry

- Barry Warsaw <barry@list.org>:
I created a separate page for each role (admin, moderator, subscriber) and added notes to each menu item. If you want to start with a top view, start here:
<http://wiki.list.org/display/DEV/global+requirements>
Then, in each subsection of "Navigation Structure" choose "See a commented <role> navigation structure."
To jump right at it:
administrator navigation structure
<http://wiki.list.org/display/DEV/administrator+navigation+structure>
moderator navigation structure
<http://wiki.list.org/display/DEV/moderator+navigation+structure>
subscriber navigation structure
<http://wiki.list.org/display/DEV/subscriber+navigation+structure>
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

I love how you've put all this thought into a better structure here. But no matter how much thought goes into it, someone's gonna have trouble finding stuff in a tree that big...
Can we add a search box for options? It might not be necessary on the smaller pages, but the full admin/owner interface looks like it's still going to be sufficiently busy that it could help.
Can we please please please do some user testing on the initial designs before they get set in stone? Ideally, I think we'd want to do this at the point where there's a clickthrough prototype. Then we could sit some people down and ask them to do some tasks, and see how long it takes/where they go wrong. Plus we could get general impressions on usability from the mailman-users list.
Terri

Terri,
thanks for taking the time to read my proposal and writing this email.
- Terri Oda <terri@zone12.com>:
Yes. For a list owner this seems acceptable to me. Those are the ones who are willing to spend some time - they expect a certain level of complexity because they know the software is complex.
For a regular subscriber the interface should be as simple as possible (but not simplier or they will think we believe they are stupid ;).
We can. But I, personally, would want to wait for usability test and see if we can do without it simply because it makes the interface more complex.
Reason is, I have planned search boxes for several other use cases e.g. finding a subscriber, a mail address etc.
I would rather not have two search boxes fanning out ambiguity and competing for user attention - unless we need to.
I do believe complexity is a deliberate decision.
Yes, very welcome.
the point where there's a clickthrough prototype. Then we could sit
some people down and ask them to do some tasks, and see how long it
The test scenario affects the outcome of the test. We need to standardize the test before we run it. I might be able to get some people from a usability lab we work with help us. Let me check that.
takes/where they go wrong. Plus we could get general impressions on
usability from the mailman-users list.
We should also manage the change actively e.g. provide a little website that explains why things have changed, where they have gone etc.
The goal would be to re-empower the people and give them the security back they have accquired using the old interface over the years.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563

Patrick Ben Koetter wrote:
Well, here's some user data from a recent mailman-users post
http://www.mail-archive.com/mailman-users%40python.org/msg53494.html
This is a *common* way for people to find things in the current mailman admin interface, sadly. I've watched people do it and had people tell me in person that's how they find things too. Most people who maintain mailing lists do settings changes infrequently, and often under some time pressure. And they never have time to learn the menu hierarchy unless they maintain a lot of different types of lists. And often not even then. There's a lot of options there, and most people nowadays are used to the google method of finding things. ;)
I totally understand not wanting to add too much extra, but... my user observations thus far imply that this is a feature that would be used heavily.
I'm an academic researcher professionally, so I'm well aware of issues in testing methodologies. But honestly? Don't get caught up in doing Perfect Science here. Even a quick, dirty, messy user study would give us a lot of information that could be useful. The current interface suffers badly from lack of user testing, and I'd hate for the same to be true of the new one.
If you need more help with user studies, I should be able get some help from the usability research lab here. I know one of the profs here expressed interest in mailman usability in the past, and we may be able to find people willing to work on the problem.
Terri

- Terri Oda <terri@zone12.com>:
Agreed. If it helps we will find a place for it.
Believe me. I won't. ;)
Yes.
That would be the perfect opportunity. Please ask him if he's still interested.
The question is: How do I get there. I life in Munich, Germany.
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
participants (3)
-
Barry Warsaw
-
Patrick Ben Koetter
-
Terri Oda