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

[Barry Warsaw]

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-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.

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  
>> when
>
> Style 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:
> 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).

+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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090427/9460a67a/attachment.pgp>