Proposal for a new menu grouping in MM3 webUI
As introduced by terry yesterday I'm the one who will support the development of the WebUI which should be published together with MM3 - or even better as a standalone Django Application using the REST-Api.
Those who already saw my Blogpost know what I'm talking about now - the new menu grouping. I've created a mindmap showing a possible regrouping of menu items. Florian asked me only to use these which are already available in the REST API.
Just in case you didn't read my Blog yet - I've attached the image.
Feel free to give any feedback you like, but I'm especially interested in the following things:
- Digest → volume : Do you really need this internal value to be displayed in the WebUI ?
- What do you think about regrouping all List related mail adresses from General Options to a special "Mail " section
- Same like 2. but formatting options
- Sorting out all kind of notifications
- showing stats within the archives view instead of the config
Thanks for you help improving this work. benste
On May 24, 2011, at 01:39 PM, Benedict Stein wrote:
- Digest → volume : Do you really need this internal value to be displayed in the WebUI ?
I think this would only be useful information wherever you had a control to explicitly start a new volume. What might actually be interesting is to show the current volume number and the accumulated size of the current volume, along with a button to explicitly send out the current volume and increment the volume number.
(It might also be interesting to show some historical data about the digests, e.g. when they went out and how big they were. This isn't currently being collected though.)
- What do you think about regrouping all List related mail adresses from General Options to a special "Mail " section
Since those are read-only, it might be useful to have an "information" page for the list, detailing useful things like this that can't be changed.
- Same like 2. but formatting options
Same, perhaps?
- Sorting out all kind of notifications
Can you go into more detail?
- showing stats within the archives view instead of the config
Yep. We need to do a much better job of collecting and exposing stats.
Thanks for you help improving this work.
Thank *you*!
-Barry
On 5/24/2011 5:23 AM, Barry Warsaw wrote:
On May 24, 2011, at 01:39 PM, Benedict Stein wrote:
- showing stats within the archives view instead of the config Yep. We need to do a much better job of collecting and exposing stats.
I don't know if this is the place to mention it but along with increased accessibility to statistics and archives, the ability to look at or review the logging information is also very important. Anywhere in the code that output's to a log file should provide enough information to follow a message coming into Mailman, through the various Mailman processes, and out of Mailman. I went through Mailman v2.1.9 to add additional logging information so I can track a message. My users call on a regular basis to check if their message "went out" to a list they can post to but not read (it gets complicated). Once I had the logging information (message-id, listname, sender, etc.), I wrote a web app that parses the vette, smtp, and post logs and combines the information so I can see what happened to the message either by list or by sender. It works well for me but additional logging information for tracking messages and problems is also need.
I know I drifted a bit but additional logging is needed and an administrative interface to view the information is also needed.
Thanks for you help improving this work. Thank *you*!
-Barry
Thank you for the work also. I did view your latest diagram and the volume/digest issue seems to be correct. But just to make sure, the volume number is increased for every SCHEDULED digest sent out (with the digest number reset to 1). Next, any addition digests sent out BETWEEN scheduled digests (whether due to size of digest or number of messages in the digest) increase the digest number but not the volume number. If that is true, then I am in agreement with you :) because it mimics the magazine style of volume/issue.
Thanks for yours and Barry's hard work, Chris
C Nulk wrote:
Thank you for the work also. I did view your latest diagram and the volume/digest issue seems to be correct. But just to make sure, the volume number is increased for every SCHEDULED digest sent out (with the digest number reset to 1). Next, any addition digests sent out BETWEEN scheduled digests (whether due to size of digest or number of messages in the digest) increase the digest number but not the volume number. If that is true, then I am in agreement with you :) because it mimics the magazine style of volume/issue.
This is not the way it works in MM 2.1. In MM 2.1, the volume increments and the issue resets to one for the first digest produced in a new period, where period is Year, Quarter, Month, Week or Day as set in Digest options -> digest_volume_frequency. The issue increments for each digest produced in that period whether the digest is produced 'periodically' or by size. If there are no posts/digests produced during a period, the volume doesn't increment for that period.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Yeah, I took a look at what I wrote and I wasn't as clear as I thought I was. By SCHEDULED digest, I mean a digest sent out on a set time period or frequency (like Years, Months, Weeks, etc.). Those digests would have the volume number incremented and the digest number reset to 1. Any digests sent within (or BETWEEN) the scheduled digests time period / freq. for whatever reason - size, number of msgs - would increment the digest number only. If there are no digests/msgs to send, then the volume number does not increment.
Thanks Mark, Chris
On 5/24/2011 3:50 PM, Mark Sapiro wrote:
C Nulk wrote:
Thank you for the work also. I did view your latest diagram and the volume/digest issue seems to be correct. But just to make sure, the volume number is increased for every SCHEDULED digest sent out (with the digest number reset to 1). Next, any addition digests sent out BETWEEN scheduled digests (whether due to size of digest or number of messages in the digest) increase the digest number but not the volume number. If that is true, then I am in agreement with you :) because it mimics the magazine style of volume/issue.
This is not the way it works in MM 2.1. In MM 2.1, the volume increments and the issue resets to one for the first digest produced in a new period, where period is Year, Quarter, Month, Week or Day as set in Digest options -> digest_volume_frequency. The issue increments for each digest produced in that period whether the digest is produced 'periodically' or by size. If there are no posts/digests produced during a period, the volume doesn't increment for that period.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5/25/11 7:25 AM, C Nulk wrote:
Yeah, I took a look at what I wrote and I wasn't as clear as I thought I was. By SCHEDULED digest, I mean a digest sent out on a set time period or frequency (like Years, Months, Weeks, etc.). Those digests would have the volume number incremented and the digest number reset to 1. Any digests sent within (or BETWEEN) the scheduled digests time period / freq. for whatever reason - size, number of msgs - would increment the digest number only. If there are no digests/msgs to send, then the volume number does not increment.
That is essentially what I thought you meant, and as I said, that's not how it works in Mailman 2.1 (See below)
digest_volume_frequency and digest_send_periodic are separate, independent settings. digest_volume_frequency controls only when the volume number changes. digest_send_periodic controls whether or not a digest is sent when cron/senddigests runs (default, daily at noon). In any case, a digest is always sent when the size of the list's accumulated digest.mbox reaches digest_size_threshhold.
I.e. there are no 'scheduled' digests other than the ones sent daily by cron/senddigests and those have no relation to the volume number.
Even if digest_volume_frequency is Daily, and digest_send_periodic is Yes, and digests are sent at noon, a digest triggered on size at 09:00 will be issue number one of that day's volume if it's the first digest of the day.
On 5/24/2011 3:50 PM, Mark Sapiro wrote:
This is not the way it works in MM 2.1. In MM 2.1, the volume increments and the issue resets to one for the first digest produced in a new period, where period is Year, Quarter, Month, Week or Day as set in Digest options -> digest_volume_frequency. The issue increments for each digest produced in that period whether the digest is produced 'periodically' or by size. If there are no posts/digests produced during a period, the volume doesn't increment for that period.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California Better use your sense - B. Dylan
On May 24, 2011, at 03:11 PM, C Nulk wrote:
I don't know if this is the place to mention it but along with increased accessibility to statistics and archives, the ability to look at or review the logging information is also very important. Anywhere in the code that output's to a log file should provide enough information to follow a message coming into Mailman, through the various Mailman processes, and out of Mailman.
It is, and I agree! Well, let me say that I definitely think better logging is on the table for MM3, and I've been careful to ensure that at least the Message-ID is logged for anything that pertains to the disposition of an email message. I'm not sure how or if the logging information should be available through the web ui (and thus the REST API).
I went through Mailman v2.1.9 to add additional logging information so I can track a message. My users call on a regular basis to check if their message "went out" to a list they can post to but not read (it gets complicated). Once I had the logging information (message-id, listname, sender, etc.), I wrote a web app that parses the vette, smtp, and post logs and combines the information so I can see what happened to the message either by list or by sender. It works well for me but additional logging information for tracking messages and problems is also need.
One other thing I've been thinking about is a kind of "debug" option where a fake message could be injected into the system, with the appropriate headers, and out would come some debugging information about which rules got hit, and exactly why a message would be held, accepted, discarded, or rejected. I haven't thought more about this other than "it would be cool to have" ;).
-Barry
On 05/27/2011 05:09 PM, Barry Warsaw wrote:
One other thing I've been thinking about is a kind of "debug" option where a fake message could be injected into the system, with the appropriate headers, and out would come some debugging information about which rules got hit, and exactly why a message would be held, accepted, discarded, or rejected. I haven't thought more about this other than "it would be cool to have" ;).
More than just "cool to have": it would enable people to write more tests for the test suite, which in turn makes developers more confident in undertaking aggressive re-factorings without fear of breakage. That would be a Good Thing.
--dkgOn May 27, 2011, at 05:26 PM, Daniel Kahn Gillmor wrote:
More than just "cool to have": it would enable people to write more tests for the test suite, which in turn makes developers more confident in undertaking aggressive re-factorings without fear of breakage. That would be a Good Thing.
Most definitely. In the meantime, take comfort at least that MM3 has a pretty extensive test suite that *actually runs and passes* :)
-Barry
Benedict,
- Benedict Stein <benedict.stein@googlemail.com>:
As introduced by terry yesterday I'm the one who will support the development of the WebUI which should be published together with MM3 - or even better as a standalone Django Application using the REST-Api.
Those who already saw my Blogpost know what I'm talking about now - the new menu grouping. I've created a mindmap showing a possible regrouping of menu items. Florian asked me only to use these which are already available in the REST API.
Just in case you didn't read my Blog yet - I've attached the image.
Feel free to give any feedback you like,
The current (MM2) structure is far too complex. I work with it often and I still get lost or spend too much time searching for an option that must have been, wait, well where did it ...
In 2009 I ended up buying tickets for Pycon 2009, visiting Barry to work on the MM3 WUI.
Here's what I came up with (and what I personally still would do):
The navigation structure should work for the following user groups:
- subscriber
- moderator
- admin
Each group (in descending order) requires an interface that offers/exposes more options. Put the other way around: The interface should hide all options not required for a group.
A user can see the same interface different any time she logs in, IF she acts out different roles (subscriber, moderator, admin).
I think we need to develop a structure that works for all groups and remains consistent. No matter which role you own, menu items should always be located at the same place.
I think this can be done best if menu items were rearranged following a role/task driven approach.
Here's a model I've come up with at Pycon 2009:
The model forsees plugins, something Barry and I discussed to open MM3
to development by third parties.A subscriber could see these items:
dashboard options general topics plugins subscriptions subscribe remove modify statistics List
A moderator would see more items, building upon the already established "subscriber" structure:
dashboard requests statistics System List User plugins plugin 1 configuration options plugin 2
Finally, an admin would be exposed to all options available through the WUI:
dashboard maintenance requests options General Subscription Rules Language Non-Digest/Digest Filter Sender Recipient Spam Message Topics Bounces Archive Gateways Auto-Responder Plugins subscriptions subscribe remove statistics System List User plugins plugin 1 configuration options plugin 2
I've laid all this and descriptions of the various items down in <http://wiki.list.org/display/DEV/global+requirements>.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
participants (6)
-
Barry Warsaw -
Benedict Stein -
C Nulk -
Daniel Kahn Gillmor -
Mark Sapiro -
Patrick Ben Koetter