[Mailman-Developers] mailman 3: webinterface: prototype (PDF)

[Patrick Ben Koetter]

* Barry Warsaw <barry at 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:
1. Notify user if (!) attention is required (hide otherways...)
2. 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 at rick


-- 
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung

http://www.state-of-mind.de

Franziskanerstraße 15	   Telefon +49 89 3090 4664
81669 München              Telefax +49 89 3090 4666

Amtsgericht München        Partnerschaftsregister PR 563