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 Ihave 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 ListA (regular) user, for example, would do this to see a list of all currentsubscriptions: Go to top level menu item: "subscriptions"This will show a list of all current subscriptions that could beindividually choosen for "unsubscription" or "modification".Also all subscriptions could "inherit" applicable settings from thecurrently 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 andwe'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 theirsubscriptions 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'dprobably 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 letsthem 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 usercan do (i.e. the "3 pending"). This of course would be linked totask-oriented pages for addressing those things. A user might also see alist 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 throughthe 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 ofredoing 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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
