[Mailman-Users] Web UI request

[Jaco Kroon]

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