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:
following our discussions at the Pycon 2009 Mailman sprint I've come
up with first draft of a/the future mailman 3 web interface.
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>:
On Apr 23, 2009, at 11:16 AM, Patrick Ben Koetter wrote:
following our discussions at the Pycon 2009 Mailman sprint I've come
up with first draft of a/the future mailman 3 web interface.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.
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-NavigationStructure>
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.
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.
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
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).
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:
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 couldbe 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.
That does sound good. Comments, or some other way to capture your
thinking behind it, would be good.
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.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.
Agreed.
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
whenStyle as in "profile"?
Just to think of two prototypes:
Techi-Profile No HTML Mail No Attachments
Party-Profile HTML Mail Attachments
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.
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).Yes. They have to functions: the whole site because they don't remember where it was).
- 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
+1
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?
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>:
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.
That does sound good. Comments, or some other way to capture your
thinking behind it, would be good.
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
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.
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.
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.
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
On Apr 27, 2009, at 12:10 PM, Terri Oda wrote:
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.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.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.
Both are excellent suggestions Terri. Thanks! -Barry
Terri,
thanks for taking the time to read my proposal and writing this email.
- Terri Oda <terri@zone12.com>:
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.
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...
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 ;).
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.
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.
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.
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
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:
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.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.
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.
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.
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>:
Patrick Ben Koetter wrote:
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.
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.
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.
Agreed. If it helps we will find a place for 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.
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
Believe me. I won't. ;)
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.
Yes.
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.
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