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
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
------------------------------------------------------
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=show&file=faq01.027.htp
