Re: [Mailman-Users] Web UI request
On 18 Jun 2008, at 20:32, Terri Oda wrote: [...] I've opened up a new page on the wiki to get more of a process going: http://wiki.list.org/display/DEV/Web+Interface This is great, but how should we use it? :) I think the easiest is simply to go through all settings, decide what is needed/not needed. Then group the relevant stuff, and then do categorization. This should probably just be done by 1-3 people and then submitted as a proposal. But how easy is it to actually improve the web UI? It was said in another letter that it is generated from various source fragments, so is there the necessary abstraction in Mailman to allow the web UI to be improved? If it is feasible to redo the UI for 2.x then I’ll gladly submit some more complete suggestions. [...] 4. Labels are too verbose, contributing with noise to the overall view, and the “Details for «the_mailman_option_name»” under each label does not help in this regard. I've got mixed feelings about this. The labels do contribute to noise, but they also provide the ability for me to tell people change the setting with name $foo *or* describe the description if I'm not near a computer to check the stuff myself. The longer labels also make it easier for people looking at the interface the first time to figure out what things do at a glance instead of having to click each details button to find the one they want. My main problem with the verbose (right-aligned) labels is that it makes skimming very difficult. A few days ago I created a list where I wanted to allow posts from non- members and I spent at least 10 minutes skimming page after page for this setting. Eventually I found it under “Privacy Options… → [Sender Filters]” with this label: Action to take for postings from non-members for which no explicit action is defined (Details for generic_nonmember_action) The first six words of that label has no value with respect to telling what it is. For optimal skimming, the first few words should have words that are unique to the option. I also am not sure about the importance of stressing that this is for the case where there is no explicit action defined (sort of goes without saying). So here I would propose something like: Non-members have their posts: ( ) Accepted (o) Held (for the list admin to approve) ( ) Rejected (they receive a bounce) ( ) Discarded (no bounce is sent back) I also added info about each choice hopefully making the previous “more info” link unnecessary. Another example of the long verbose labels are (in same category): List of non-member addresses whose postings should be automatically accepted. (Details for accept_these_nonmembers) In my mind a simple label of “white-listed non-members” would suffice. And back to the point about skimming, there are actually four settings which all start with “List of non-member addresses whose”, meaning that when skimming, this is 20 words I have to read which say nothing about the actual option. For the above, it is actually the last word (of first sentence) which makes all the difference compared e.g. to this setting on same page: List of non-member addresses whose postings should be automatically rejected. (Details for discard_these_nonmembers) So we have two paragraphs of 15 words each which in the first sentence only differ in the last word. So while I agree with you in theory, I don’t think this verbosity holds the value you assign it ;) -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
On 19-Jun-08, at 12:13 PM, Allan Odgaard wrote: On 18 Jun 2008, at 20:32, Terri Oda wrote: I've opened up a new page on the wiki to get more of a process going: http://wiki.list.org/display/DEV/Web+Interface This is great, but how should we use it? :) Sign up for a wiki account and either edit the page or leave comments on the bottom. I like your idea of doing regrouping, and I think the wiki format would better let multiple people edit the groupings until we find something that works. That said, Brad is right -- this discussion should definitely be happening on mailman-developers rather than here, so I'll post further comments there. Please direct any follow-ups to that list. Terri -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
Allan Odgaard wrote: http://wiki.list.org/display/DEV/Web+Interface This is great, but how should we use it? :) This entire discussion belongs on the mailman-developers list, not mailman-users. I say this as the co-moderator for both of the lists in question. -- Brad Knowles [EMAIL PROTECTED] Member of the Python.org Postmaster Team Co-Moderator of the mailman-users and mailman-developers mailing lists -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
Date: Wed, 18 Jun 2008 22:54:04 -0500 From: Brad Knowles [EMAIL PROTECTED] On 6/18/08, Cyndi Norwitz wrote: I second this. Subscribers losing their password and asking me to make changes for them is one of my biggest timesinks, outside of moderation. I don't molly-coddle users. If they can't figure out for themselves how to get their password sent to them, that's their problem. :-) I take a middle approach. I tell them to log on to the site (sometimes I'll cut and paste the link, sometimes I just say look on the bottom of any post) and they can get their password from there. If they have an overridding circomstance, are really too disabled and computer illiterate to follow such directions, or have honestly tried and failed, then I try to help them. But just replying to the letters and such can take a lot of time, if there are several. It was also a big issue because for a long time I didn't know that the password could be sent to someone more than monthly. I always changed mine to ones I memorized and it's not obvious on the login page. But then I'm in a position where it's probably a lot easier for me to do that for me and my user base as compared to you and your user base. ;-) Yep. Part of running a support group for people with disabilities is that you can't assume they all have solid computer skills, their own computers, or the ability to figure it all out. Cyndi -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 18, 2008, at 11:24 AM, Dragon wrote: Mark Sapiro mentioned in another post that the web UI is in need of an update/overhaul. I'd like to make one feature request for that which came to light with a bunch of non-technical users on one of my lists. It is not obvious from the list information page how one would obtain a password reminder. You have to click the Unsubscribe or edit options button to get to the page with the password reminder button. This really needs to be FAR more obvious. It really should be an item on the very first page a user sees. In future versions there will be no reminders. Please, a moment of silence for the future death of Mailman Day. :) There will be a password reset feature though and that should be plainly obvious on any new u/i we develop. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhZKZEACgkQ2YZpQepbvXE+NACgpkM7sH7wtn1gUL6Zwxp+OpIv jgsAoKNdtiY17veU986WY8H549eR+lKd =kiiG -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
On 18-Jun-08, at 11:24 AM, Dragon wrote: Mark Sapiro mentioned in another post that the web UI is in need of an update/overhaul. I'd like to make one feature request for that which came to light with a bunch of non-technical users on one of my lists. It is not obvious from the list information page how one would obtain a password reminder. You have to click the Unsubscribe or edit options button to get to the page with the password reminder button. This really needs to be FAR more obvious. It really should be an item on the very first page a user sees. Agreed! And thanks for mentioning it -- the more user input we get, the better! It's a bit hard to make everything obvious on that first page, but I'd definitely like to see us improve the functionality for existing members (right now the page is clearly optimized for new subscribers). Would it make more sense to have just a giant existing list members click here and a separate page that's targetted at existing members, or do you think we can do both things in one place? Saving that click can be a big deal... Hmmm... now you've got me thinking about it again. Perhaps some good will come of this. ;) Terri -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
On 18 Jun 2008, at 17:41, Terri Oda wrote: [...] the more user input we get, the better! Another thread said that “the web UI is scheduled for overhaul”. Is anyone assigned to this? Is it an open process? Can we follow it somewhere? I think the admin UI suffers from: 1. Too many options. 2. Weak categorization. 3. Typographically bad, e.g. no visual cues about significance, related options, etc. and right-aligned labels make it difficult to skim down through a page. 4. Labels are too verbose, contributing with noise to the overall view, and the “Details for «the_mailman_option_name»” under each label does not help in this regard. I believe the current UI is generated from the Defaults.py, which is a contributing factor to some of the above. Is the plan to keep generating the UI, or would it be OK to actually design a UI? Switching to a designed one means more work when adding new options that require UI, but considering that the current UI has been the same for as long as I can remember, it’s not exactly a moving target. Also, having the lists themselves stored as pickled objects make it problematic to leave stuff out of the web UI, but I would strongly suggest that the lists switch to using a plain text format. Anyway, for the overhauled web UI, I will gladly participate in the process, if I am welcomed, but I think it might be a little controversial because I probably want to cut all the options I consider unnecessary, for example does an admin really need a web UI for setting whether or not digest users are allowed to switch to immediate mail delivery? etc. I think a first step would be to find out what options actually are necessary in the web UI (and presently there are some stuff not available that I would like to have there, for example the list URLs really should be visible in the web UI). Next step would then be to categorize this stuff sensibly, and after that, we can look at mockups. But as indicated above, at least step 1 should probably not be done “by committee” because you want to be harsh and not include some arcane option that one guy argue is really very useful to him :) If the pickled lists were instead plain text, that would be much easier, because then it could be a very clearly stated goal that the web UI is for the stuff most of us want most of the time, and for the more exotic stuff, there is the list config file. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
On 18-Jun-08, at 1:56 PM, Allan Odgaard wrote: On 18 Jun 2008, at 17:41, Terri Oda wrote: [...] the more user input we get, the better! Another thread said that “the web UI is scheduled for overhaul”. Is anyone assigned to this? Is it an open process? Can we follow it somewhere? The last major push was last summer, as part of a Summer of Code project: http://wiki.list.org/x/2Q I think Ethan's still doing some work here, but I don't know what his status is. I believe there was also some work done on basic CSS conversion that was more recent. I've opened up a new page on the wiki to get more of a process going: http://wiki.list.org/display/DEV/Web+Interface 1. Too many options. Agreed. My solution would be to have an expert and a simple interface. Three reasons: 1. Even *as* an expert, I'd love to have a small interface that met my most common needs. 2. Choosing what options to keep and which to toss would likely slow down the process so much that we'd never get a new interface. 3. Giving people access to files is more of a pain than letting them interact through a web UI. (eg - don't have to worry about shell access, bad file syntax, etc.) 2. Weak categorization. Agreed. Often the option people want is there, but not where they look. And even writing the documentation, I've found myself hard- pressed to explain some things. 3. Typographically bad, e.g. no visual cues about significance, related options, etc. and right-aligned labels make it difficult to skim down through a page. Agreed that there's some visual stuff that needs work. Mostly, I find it just looks old and clunky and too busy. 4. Labels are too verbose, contributing with noise to the overall view, and the “Details for «the_mailman_option_name»” under each label does not help in this regard. I've got mixed feelings about this. The labels do contribute to noise, but they also provide the ability for me to tell people change the setting with name $foo *or* describe the description if I'm not near a computer to check the stuff myself. The longer labels also make it easier for people looking at the interface the first time to figure out what things do at a glance instead of having to click each details button to find the one they want. The web interface for 3.0 is going to be *very* different from the 2.1 stuff because a lot of things are just going to go away or appear. But I think we'd do well to think seriously about making 2.2 have an improved interface. Honestly, I feel that the web UI which used to be Mailman's strength has lately become its biggest weakness. I've been putting my thought into organizing the documentation lately (as anyone who's been following the wiki has no doubt noted), but I'm almost done what I wanted to do there, and I want to be writing code next. I'd been planning on tackling the archiver, but perhaps I should take a harder look at web UI for my next project. Terri -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
Date: Wed, 18 Jun 2008 08:24:34 -0700 From: Dragon [EMAIL PROTECTED] It is not obvious from the list information page how one would obtain a password reminder. You have to click the Unsubscribe or edit options button to get to the page with the password reminder button. This really needs to be FAR more obvious. It really should be an item on the very first page a user sees. I second this. Subscribers losing their password and asking me to make changes for them is one of my biggest timesinks, outside of moderation. Cyndi -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
Allan Odgaard wrote: Another thread said that “the web UI is scheduled for overhaul”. Is anyone assigned to this? Is it an open process? Can we follow it somewhere? This is a development issue, and would be discussed on the mailman-developers mailing list. The rest of this thread should really be moved over there. I believe the current UI is generated from the Defaults.py, which is a contributing factor to some of the above. The Web UI is generated by various bits of Python code throughout the system. Defaults.py is how standard defaults are picked up that are used throughout all of Mailman -- not just the Web UI. The Web UI and the rest of the Mailman code are pretty tightly integrated. You can't just rip out one file and replace it with something else, and have everything magically changed. Also, having the lists themselves stored as pickled objects make it problematic to leave stuff out of the web UI, but I would strongly suggest that the lists switch to using a plain text format. In Mailman3, I believe that all of this stuff is going to be stored in a proper database, and not in Python pickles. With the appropriate back-end database connector, you should be able to choose what database is used to store this information. If the pickled lists were instead plain text, that would be much easier, because then it could be a very clearly stated goal that the web UI is for the stuff most of us want most of the time, and for the more exotic stuff, there is the list config file. We're going the opposite direction. There may be a simplified WebUI that is available to certain users or certain administrators, but we've had too many problems with things that can only be done by the site admin who has full privileged access to the server in question. For Mailman3, I believe that one of the goals is that *EVERYTHING* that can possibly be done with Mailman will be do-able through at least the full incarnation of the WebUI. At that point, everything the site admin can do could be done through the site admin WebUI, and if they wanted to restrict certain features/functions from being visible to the list owners or moderators, they would be able to do that, but you would no longer require any privileged command-line access to the server in question, unless you were doing the first-time install. -- Brad Knowles [EMAIL PROTECTED] Member of the Python.org Postmaster Team Co-Moderator of the mailman-users and mailman-developers mailing lists -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
Hi, Just some background about myself and why I lurk on this list: I'm someone that contracts with some ISPs, maintaining various different kind of servers, amongst others a few Mailman servers. I run Mailman with a single self-cooked patch for these folks (patch is for virtual hosting, isn't perfect, but is available from http://bugs.gentoo.org/show_bug.cgi?id=208789), partially based on the cpanel hack. Terri Oda wrote: 1. Too many options. Agreed. My solution would be to have an expert and a simple interface. Three reasons: 1. Even *as* an expert, I'd love to have a small interface that met my most common needs. Not only that, some people are severely intimidated by the sheer number of options. Imagine your average reception lady trying to make head or tails of half the options in Mailman. 2. Choosing what options to keep and which to toss would likely slow down the process so much that we'd never get a new interface. I tamper with most of the options from time to time, so I would want to keep the lot, but the simple vs expert idea is a good one. 3. Giving people access to files is more of a pain than letting them interact through a web UI. (eg - don't have to worry about shell access, bad file syntax, etc.) No. In a hosting environment giving shell access like this for multiple clients is a no go. So as someone that contracts for ISPs I'll back this idea. Shell access should ideally _never_ be required for normal operation. Obviously I don't mind doing problem-finding in the shell (in fact, I personally prefer that - but for clients this is a no go). Just to make it clear, it's not that security cannot be controlled, if I tell my average client they need to use a shell - they'll run away. 4. Telling a client (admin from virtual isp) to leave the expert options the heck along or else would be much simpler than please only modify options a b and c. A possible further enhancement to this would be to have an additional admin level. Basically exactly the same as an admin, but not allowed to use advanced mode. Not sure about the rest of the world, but this would be extremely handy for me (can give the lady that first level support the restricted login only, second level support the full, and then keep shell for my trained technicians). 2. Weak categorization. Agreed. Often the option people want is there, but not where they look. And even writing the documentation, I've found myself hard-pressed to explain some things. Thirded. 3. Typographically bad, e.g. no visual cues about significance, related options, etc. and right-aligned labels make it difficult to skim down through a page. Agreed that there's some visual stuff that needs work. Mostly, I find it just looks old and clunky and too busy. This stuff doesn't bother me *too* badly. However, the ability to customize look feel would be advantageous, not required. Not sure how easy this would be. I can probably already do what I want by (ab)using libcurl and/or iframes. 4. Labels are too verbose, contributing with noise to the overall view, and the “Details for «the_mailman_option_name»” under each label does not help in this regard. I've got mixed feelings about this. The labels do contribute to noise, but they also provide the ability for me to tell people change the setting with name $foo *or* describe the description if I'm not near a computer to check the stuff myself. The longer labels also make it easier for people looking at the interface the first time to figure out what things do at a glance instead of having to click each details button to find the one they want. However overs? Not sure if you're familiar with Trixbox but it's the only example I can think of at the moment. Their implementation just isn't particularly good. The web interface for 3.0 is going to be *very* different from the 2.1 stuff because a lot of things are just going to go away or appear. But I think we'd do well to think seriously about making 2.2 have an improved interface. Honestly, I feel that the web UI which used to be Mailman's strength has lately become its biggest weakness. I wouldn't quite go that far. Trust me, it's still much, much better than not having it at all. I've been putting my thought into organizing the documentation lately (as anyone who's been following the wiki has no doubt noted), but I'm almost done what I wanted to do there, and I want to be writing code next. I'd been planning on tackling the archiver, but perhaps I should take a harder look at web UI for my next project. What can I do to help convince you? I don't have spare cycles at the moment to contribute code (sorry, just about every spare second is going into VoIP and mail clustering systems at the moment). May I also suggest some level of reporting? There is currently some elementary virtual hosting support, so only certain lists gets displayed
Re: [Mailman-Users] Web UI request
On 6/18/08, Cyndi Norwitz wrote: I second this. Subscribers losing their password and asking me to make changes for them is one of my biggest timesinks, outside of moderation. I don't molly-coddle users. If they can't figure out for themselves how to get their password sent to them, that's their problem. But then I'm in a position where it's probably a lot easier for me to do that for me and my user base as compared to you and your user base. ;-) -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
