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.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
-----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-----
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
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:
- Too many options.
- Weak categorization.
- 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. - 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.
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
- Too many options.
Agreed. My solution would be to have an "expert" and a "simple"
interface. Three reasons:
- Even *as* an expert, I'd love to have a small interface that met
my most common needs. - 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. - 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.)
- 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.
- 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.
- 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
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:
- Too many options.
Agreed. My solution would be to have an "expert" and a "simple" interface. Three reasons:
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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 when using a certain web interface. At least one of my clients (An ISP) is interested in reports that basically states how many emails went out to a list during a month, and then for each message how many recipients was in the database at the time of sending, as well as how big each message was. I need to take a look at this in any case, and would be willing to throw resources at this, but I'm going to need a few pointers to how where and what.
Another idea - and this may or may not be viable - templatized list creation. In other words, different templates that pre-sets options, these templates are then copied into the new list when a new list is created. I don't create too many lists myself, but I know one of my clients has two or different "standard" setups, and then have a long list of steps to take to go from the default setup to that specific setup.
Regards, and thanks for a great product, Jaco
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:
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 ;)
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:
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
Allan Odgaard wrote:
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 <brad@python.org> Member of the Python.org Postmaster Team & Co-Moderator of the mailman-users and mailman-developers mailing lists
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 <brad@python.org> Member of the Python.org Postmaster Team & Co-Moderator of the mailman-users and mailman-developers mailing lists
Date: Wed, 18 Jun 2008 08:24:34 -0700 From: Dragon <dragon@crimson-dragon.com>
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
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 <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Date: Wed, 18 Jun 2008 22:54:04 -0500 From: Brad Knowles <brad@shub-internet.org>
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
participants (8)
-
Allan Odgaard -
Barry Warsaw -
Brad Knowles -
Brad Knowles -
Cyndi Norwitz -
Dragon -
Jaco Kroon -
Terri Oda