1.  KISS -- I sometimes have to do list administration and
        moderation from my Treo 650, so anything that depends on
        graphics, JavaScript, CSS, or anything fancy is really bad
        news. 

Ug, yeah. There's so much cruft stuck in so many places that I've just started over writing (x)html templates. I will be using CSS mostly so that underneath the pages can be Very Simple; I've got a Palm TX and table pages can be brutal. Additionally, I fully intend to have a CSS file just for mobile devices.

I will also be using JavaScript to add responsiveness to the UI for traditional browsers, but I swear on a stack of comic books that It Shall Degrade Gracefully.

        Stick to a pure text-only UI as much as possible,

Please forgive my insouciance on this point, but I believe one of the weaknesses of the current interface is that it provides no visual cues as to what is important/relevant. I will be using icons to draw the user's eye to relevant details, but I have no intention of gobbling up screen space for bling or committing similar crimes like using image-only links; the interface will be fully functional and aesthetically reasonable with images turned completely off.

        and try doing some actual tests with various PDAs and
        phones, as well as all common browsers (including Safari)
        on all common desktop platforms (including MacOS X).

Well, I've got me a testing lab right here! I'm only slightly kidding. Aside from the aforementioned TX, I have an intel mac, so I plan on installing Windows soon so I can see how things work on that end.

I'm also going to make sure it's fine in links or lynx.

        I would
        hate to see all the current WebUI code get thrown out and
        replaced with a Web2.0 AJAX/.NET framework.

I will be using some XMLHTTPRequest action, but only to allow partial-form-submission, and it will degrade to "submit the whole page" gracefully.

    2.  Functionality & 3. Completeness

I'm not committed to doing much with these problems in this project, but I assure you it is my desire as well; I'm hoping to get us closer to the day where there is One Holy UI that works identically across web/email/cli.

I'm not sure you fully understand how important.  Or how difficult.  ;)

Thanks! happily I feel like I'm making quite a bit of progress, so I think we might just get something viable out of this.

~ethan

Oh, goodness, Ethan... I was excited when Barry told me we were getting a SoC student to do this, and you sound *exactly* what we need. I'll try to restrain myself from declaring everlasting love until I've seen some finished work, but I will say that I'm very happy to have you on the project. (Even if I'll probably have to rewrite all the docs once you're done... ;) )

1. Integration with look/feel of people's existing websites

As others have said, the biggest question I get from people is usually along the lines of "How can I make Mailman fit in to the rest of my website?" Some of the, you aren't going to have much control over (Top of list: why can't we just have users with one password for mailman and everything else?) but things like making the interface all css friendly (is the plan for it to be all xhtml-compliant?) and providing configurable headers and footers will make a pretty huge difference right there.

2. Simplified (possibly customizable?) interface as an option

I'd also like to see it possible to make a page that contains a simplified version of the interface. I, as a geek, love having a billion settings to mess with, but lots of list managers aren't so inclined, and it'd be nice to give them just a simple (customizable) set of functions so they don't throw up their hands and decide that mailman is too scary. This could probably be done if the xhtml gives us control over each item to be displayed, and different people could use different templates with the options they don't want/need turned off. I can imagine even terribly technical users might like to have a mailman admin page which just contains the things they use most often so they don't have to delve into the entire interface all the time.

This might, incidentally, help a lot with the completeness-versus-simplicity problem that is inherent in all interfaces. It might also make my job as a documenter hellishly difficult when people start emailing me and saying "but I don't have that option!" but I can deal with that. ;)

3. Organization

I dislike the way the list admin interface is currently organized.
People are forever looking for things in the wrong places, which is probably a sign that the things are in the wrong places and we should maybe move them. :) I wish I had time to figure out what these places are and tell you, but if you start finding the same thing, or you get people testing your designs and going to the wrong spot, make note, please?

4. Wishful thinking....

I don't suppose you'll have time to make some of the options less utterly confusing? For example, I've yet to have anyone guess what an umbrella list was and what it's for unless they were already familiar with mailing lists...

5. Archives?

Are you going to get a chance to touch the archives? A lot of the same things apply for templating there, and people always want that same look/feel.

Of course, I really really want to replace pipermail with something a bit more modern (I'm looking at finding a nice way to use apache's mbox_mod for my current lists -- if anyone's got instructions for that, drop me a line!), but I think that's a little outside your scope. :)
Still, getting it so the archives at least use the same CSS might be nice.

I'll probably think of a dozen more things to say later, but as everyone else seems to have covered the most important things I'll try to restrain myself a bit. :) I'm very excited to see this happen, though -- I think the web interface is often heralded as one of Mailman's strengths, and it'll be nice to see it a bit more polished and modern and less like someone's opened up a dusty panel and let us grab all the live wires we want. :)

Terri

Terri Oda wrote:

1. Integration with look/feel of people's existing websites

As others have said, the biggest question I get from people is usually along the lines of "How can I make Mailman fit in to the rest of my website?"

The main thing I'm doing in this regard is building each piece of functionality, down to individual options, as separate pages/page snippets that will work if embedded into another page.

If the user has JavaScript and a browser that supports XMLHttpRequest, the form submissions will happen asynchronously and feedback will occur within the site's page; if they do not they will go to a mailman-specific page that can still be styled by the site administrator.

Some of the, you aren't going to have much control over (Top of list: why can't we just have users with one password for mailman and everything else?)

While I can't take this on this summer, I am building "as if" mailman has a concept of a user and - if Barry doesn't come back from vacation with a Super Happy Report with regards to SQLAlchemy - writing glue code to make the UI behave as if there were a concept of a user. Said glue code should be able to handle the site providing user/pass details, as it will already be looping through the list(s) collecting user/pass details.

There are some icky complications with this- if the site doesn't notify the glue code a user's pass has changed, it won't be for mailman, and if the code gets halted before it updates all the passwords for a user the user might end up with some lists failing to allow auth.

It comes down to me not being able to figure out how to make a user interface for software with no real concept of a user, so I will do the lifting required to at least generate the appearance of such.

but things like making the interface all css friendly (is the plan for it to be all xhtml-compliant?)

Unless I am forced to go transitional by browser vagarities, all my pages will be xhtml strict.

and providing configurable headers and footers will make a pretty huge difference right there.

The headers and footers are going to be window dressing*. Every single other component will be embeddable from any program capable of fetching an url using basic auth.

• they will of course be stylish and customizable, but from what I've seen, the First Thing every site administrator wants to do is rip chunks out of the UI and embed them into their pages.

2. Simplified (possibly customizable?) interface as an option

I'm using standard elements and CSS's ability to style child nodes as much as possible; this means that interface elements should take on the site's styles "automagically", with the possible requirement of adding selectors for those sub-elements they hadn't styled themselves.

(It is making me wish I didn't have to specify *which* header level I meant, but enh.)

I'd also like to see it possible to make a page that contains a simplified version of the interface.

My thought is I don't know in advance which options are most important to which users.

Therefore I'm working on a page that (ala google's customized home page) lets you drag/drop option elements around (or reorder them via form submissions, if you're without javascript).

I'm also making a config page for a site/domain/list administrator that will allow the specification of which options should be available and in what order.

3. Organization

I dislike the way the list admin interface is currently organized.

a-bloody-men to that. The first thing I've done is move the wordy and visually cluttering help text and its confusing sub-pages with more help into pop up / submit-form-to-display elements.

The other half of that is as above; I don't think I know the Right Places, so I'll defer to the site administrator as to which options should be presented in which order.

4. Wishful thinking....

For example, I've yet to have anyone guess what an umbrella list was and what it's for unless they were already familiar with mailing lists...

The help thing might address this issue, but the other side of this point is that I will try to provide a "task centric" approach; the current interface is noun heavy and verb light. I'm going to try to offer a "so you want to..." interface option so that people can figure out they want an umbrella list, for example.

5. Archives?

Are you going to get a chance to touch the archives? A lot of the same things apply for templating there, and people always want that same look/feel.

Yes. Basically my approach is punting on pre-rendering archives entirely in favor of dynamically rendering* the .mbox / rfc8222 files as xhtml/RSS/atom.

This will avoid the "re-archiving your 10 years of archives totally horks your box" situation I encountered once, a while ago. Additionally it will eliminate the maddening index-by-artificial-date-segment stuff that currently amputates threads. Finally, the "private/public archives have totally different paths" bit will be gone.

Again all eye candy will be provided by CSS, not the underlying xhtml, and site administrators will be able to call the archive-browsing widget directly, bypassing the header/footer otherwise placed on the archives.

• I intend to cache the most expensive bits, like the thread tree, and archive views that have already been rendered, so that a historical thread that suddenly becomes popular won't kill your box.

This will, however, place additional CPU load on the box, especially if people opt to read mailing lists in their feed reader; OTOH, right now you can't see what people are talking about until the pipermail process kicks off, so I suspect it will be tolerable.

~ethan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jun 16, 2006, at 7:30 AM, Ian Eiloart wrote:

a) arbitrary page headers and footers so I can make it match  

the rest of my site.

+1, with CSS to help in integration.

b) site-wide masking of features that we don't allow by policy.  

There's already some of this.

+1

c) templates for lists. We have four or five basic list styles

(announce/discussion with open/closed membership and umbrella
lists). When we create a list, I'd like to be able to specify there and then
which style to use. Such a feature would rely on having a set of files on the
server that hold the relevant list settings. The UI would simply let me
pick which style to apply. The task here is not to design the templates, but
to enable their easy application.

+1 I did a little experimentation with this in the mm3 branch and I
don't think the basic mechanisms are that difficult. The UI is the
challenge (i.e. how do you set up a style?).

d) When creating an list, I'd like to be able to choose an  

umbrella for it to live under, and have it inherit privacy settings from that
list. So, to create a complex heirarchy, I'd start by creating the root list,
adding privacy settings, and then work down the heirarchy - perhaps making
the privacy settings more liberal as I go.

Very interesting idea!

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRJLsDnEjvBPtnXfVAQIaVQP8DKy0zzZ2SD10iHRGaBUI8UgE3M+9ugTt Kjpo8ohrkCygEIk8UHFtkRc42u90HXMPjE9HUbdgVG0SAbPjiorwAK8YscKEYPWq wf5L39+vdOZ/yBLC5lZ2e5PYhgh6dfatktH/9Q353LD/bWNnoOMAmJxo3U0OpkcE Slep3Z3GcHY= =Y578 -----END PGP SIGNATURE-----

--On 19 June 2006 11:31:30 +0100 Ian Eiloart <iane@sussex.ac.uk> wrote:

--On 16 June 2006 13:36:14 -0400 Barry Warsaw <barry@python.org> wrote:

...

...

c) templates for lists. We have four or five basic list styles

(announce/discussion with open/closed membership and umbrella lists). When we create a list, I'd like to be able to specify there and then which style to use. Such a feature would rely on having a set of files on the server that hold the relevant list settings. The UI would simply let me pick which style to apply. The task here is not to design the templates, but to enable their easy application.

+1 I did a little experimentation with this in the mm3 branch and I don't think the basic mechanisms are that difficult. The UI is the challenge (i.e. how do you set up a style?).

Well, in our case, the styles would be site-wide and set up only once. We don't need a UI to set up the styles, because we've already created them. Our current workflow is 1. Create a list through the UI 2. Shell in to the list server 3. Run a script which applies the style to the list.

I'd just like to avoid 2. and 3. by having some UI to apply the style on creation - like the subethaedit example.

Sorry, I wasn't paying attention there. Someone sent me this link, <http://subetha.tigris.org/images/list_create.png> and in my caffeine-deprived haze I didn't notice (a) this is a rival email list project not the subethaedit text editor, and (b) they hadn't posted to the list.

I guess it would be nice for the CGI to look for a style file at -say- /mailman/styles/foo.style and a text description at /mailman/styles/foo.description - or to extract the description from the style file.

-- Ian Eiloart IT Services, University of Sussex

On Fri, Jun 16, 2006 at 01:36:14PM -0400, Barry Warsaw wrote:

...

a) arbitrary page headers and footers so I can make it match  

the rest of my site.

+1, with CSS to help in integration.

That would be nice for me, too, definitely with CSS.

...

b) site-wide masking of features that we don't allow by policy.  

There's already some of this.

+1

I wrote a patch for that a while ago (assuming I understand what you are after). See patch 1164457 on SF. It's for 2.1.5 as I haven't had time to update yet (apart from a couple of security patches). I doubt it would be difficult to update, though, as it's very small.

I use it to disable the "owner" list setting, as list owners here have to request that change via our information desk staff, and then my back-end script handles it.

Matthew

-- Matthew Newton <mcn4@le.ac.uk>

UNIX and e-mail Systems Administrator, Network Support Section, Computer Centre, University of Leicester, Leicester LE1 7RH, United Kingdom

On Tue, 20 Jun 2006, emf wrote:

Ian Eiloart wrote: [...]

...

d) When creating an list, I'd like to be able to choose an umbrella for it to live under, and have it inherit privacy settings from that list.

This is great; I'm not sure I can do all that without writing a fair amount of under-the-UI code.

Going slightly off to one-side...

One of the things on the TODO list: http://www.gnu.org/software/mailman/todo.html is: Allow lists of the same name in two different virtual domains

(i.e. "thislist@somedom.com" and "thislist@otherdom.org", where "thislist" and "thislist" are the same name).

I suspect that most of this functionality would likewise be "under-the-UI" and so not directly related to your "work on the Web UI" brief.

But it would be worth bearing this in mind so that your code could interwork as near as reasonably possible with any future virtual-domain developments. For instance, when your code passes processes a "listname" consider also having a "virthost" sitting alongside it, even if, for the moment, that is null, or default or always-the-same etc.

--

: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

On Thu, 29 Jun 2006, Barry Warsaw wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jun 21, 2006, at 1:47 AM, David Lee wrote:

...

One of the things on the TODO list: http://www.gnu.org/software/mailman/todo.html is: Allow lists of the same name in two different virtual domains

(i.e. "thislist@somedom.com" and "thislist@otherdom.org", where "thislist" and "thislist" are the same name).

I've started working on this in my 2.2 branch, but haven't ironed out all the details yet. It's a top priority for me, but there are some gotchas. I still think it's doable.

Many thanks. That would be greatly appreciated. We are a multiple-domain site (one main, about thirty much smaller), making the transition from majordomo to Mailman. In general, Mailman is a huge improvement, but this lack of true multiple-domain support is a significant retrograde aspect in our transition.

Is there an estimate of likely timescale for 2.2 ? (Yes, I know these things slip! But approximate: two months? six months? a year?) When you get to the beta stage, I would hope we could offer to try it.

Thanks.

--

: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

--On 20 June 2006 19:01:16 -0400 emf <i@mindlace.net> wrote:

...

d) When creating an list, I'd like to be able to choose an umbrella for it to live under, and have it inherit privacy settings from that list.

This is great; I'm not sure I can do all that without writing a fair amount of under-the-UI code.

:) Maybe not.

How about this for extra:

1. Display a list of ALL members - just their names and addresses.
2. Delete ALL the list members with one click - OK, and maybe a confirm dialog!

The aim here is that I can completely change the list membership (through a delete-all and mass subscribe) before sending a mailing. The reason is that I have some users who maintain lists outside of Mailman. I'd like them to be able to take advantage of other Mailman features.

-- Ian Eiloart IT Services, University of Sussex

On Wed, Jun 21, 2006 at 01:37:36PM -0400, emf wrote:

...

How about this for extra:

1. Display a list of ALL members - just their names and addresses.
2. Delete ALL the list members with one click - OK, and maybe a confirm dialog!

Perhaps something that might be more appropriate would be a "member differ", wherein you upload a list of email addresses, and it shows you the list of emails that were on the list but aren't now, and those that would be added, and gives you the option to either accept all the changes or selectively modify them.

This sounds like the command-line "sync_members" program. I've been meaning to add a web interface to that for a while, but haven't managed to get around to it.

I guess it depends on what you use Mailman for. In then general internet-user-subscribes-themselves-mailing-list it's great. For a University with central management of some lists, it isn't quite what is needed all the time.

One thing that happens each year here for some lists is that all list members of "course-year2" get moved to "course-year3", "course-year1" to "course-year2", and new members added to "course-year1". I can do this easily from the command line with a "list_members | sync_members", but I'd really prefer the owners to be able to do it themselves.

Which reminds me, another thing I've been wanting to add is "download members as text file" (basically the same as 1 above), which would go together with the sync_members option.

Matthew

-- Matthew Newton <mcn4@le.ac.uk>

UNIX and e-mail Systems Administrator, Network Support Section, Computer Centre, University of Leicester, Leicester LE1 7RH, United Kingdom

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jun 21, 2006, at 3:45 PM, Matthew Newton wrote:

One thing that happens each year here for some lists is that all list members of "course-year2" get moved to "course-year3", "course-year1" to "course-year2", and new members added to "course-year1". I can do this easily from the command line with a "list_members | sync_members", but I'd really prefer the owners to be able to do it themselves.

Which reminds me, another thing I've been wanting to add is "download members as text file" (basically the same as 1 above), which would go together with the sync_members option.

What if we built a framework for site owners to add their own canned
actions, or a per list or per domain basis? A list owner wouldn't be
able to do much more than click a button to invoke the action, but it
would probably allow you to do both things.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRKOfm3EjvBPtnXfVAQLIvAQAiIPBm08SiXSzZJe2PGXLXlM265mFfjWV TEgnku73Mf92VPvBUc9dmcp3K4Ans3MlFm1x196Wj+e953X9i1o0tb+TW8Gm3/GQ TM/aQ3CmTm0omzk/0AyUSFAtGxgK71CHYxVWcSrJpwOaaPuX6jUbXMHtsBscwVWC XWqJpM/50nE= =MNp2 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jun 22, 2006, at 3:33 AM, Ian Eiloart wrote:

Well, our MTA won't accept more than 250 recipients per email, so when people need to email several thousand recipients, they have to
split their recipient lists into blocks. It would be much better to simply
paste them into a Mailman web UI, and let Mailman handle the details.

Why 250? Well, actually that's because our LDAP server barfs if you
make more than about 300 queries on one connection. Those queries might be validating local email addresses.

Is that per email or per smtp transaction? If the latter,
SMTP_MAX_RCPTS handles that.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRKOgHHEjvBPtnXfVAQLO7wP/VidKVEnoMK3FkxOjcvh/sMCDhFqhKWwm pbUIrMNge83hSnAOtvheeGkIFC4jij+wUXpXinwRJET7b3s06rA0n16Tu11KLWTU kueTs/5LRJMB6QhVoHuIP51pHyLt/tjpdT5jltrtjBlfsoH4FyiM7zwa7VVKKj+F Gox2g4U2fJM= =yHh7 -----END PGP SIGNATURE-----

Ian Eiloart wrote:

Well, for some of our lists it's simply inappropriate for users to set preferences.

OK, I can see this. My query/issue is this: as I understand it, completely re-setting the list membership will also reset mailman's memory of who bounces, etc. So if any of the new members were old members with subscription issues, mailman goes through the same rigamarole.

It still seems to me like "set the active membership of the list to this list of email addresses", with existing addresses being retained, non-existent addresses dropped/set nomail, and new ones added, would address your needs without breaking things in the case that other admins use the feature.

Does that sound right/ok?

So, I could implement this another way, but Mailman also offers me authentication and authorisation, and allows me to ensure proper footers on the emails, and probably some other useful stuff too.

What I hear you saying is you would like "one-off" lists; is it important that the list persists? It seems odd, but perhaps what you want, to have lists whose membership entirely changes every n mailings but retains the same email address.

Are there any regularities to the emails you add? e.g. might the set of emails you add after a delete be equivalent to some past set of emails?

I'm just thinking that the example you gave - sending all enquiring students a registration-change notice - is a case where you might want to keep some knowledge of past email addresses to which you had sent notices.

Not that I'm necessarily signing up to implement some "remember past emails" kind of thing, but the feature you want could be implemented by, for example, setting all the emails that don't occur in the most recent set to nomail, rather than just throwing them away.

~ethan

Ian Eiloart wrote:

Yes, that sounds good. I'd be uploading a list of addresses to be synced with the current membership.

Great! I'll go this route.

Erm, perhaps. It would still be nice to be able to delete all the members, though. For example, I can bulk subscribe a list of people. If I then notice that I've subscribed them to the wrong list, it's a pain to get them unsubscribed.

Yes, I very much want mass-manipulation :) as well. In addition to bulk unsub, I'm extending the membership management thingy to allow for iterative searches (preserving existing results) so that you can quickly get to a set of email addresses you'd like to perform some operation on.

~ethan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jun 21, 2006, at 10:37 AM, emf wrote:

...

How about this for extra:

1. Display a list of ALL members - just their names and addresses.
2. Delete ALL the list members with one click - OK, and maybe a
   confirm dialog!

Hm. This comes slightly in opposition to the desire to have a more user-centered mailman interface; what happens if a user changes their preferences and you re-build the entire list?

An associated problem is what happens to users that are subbed to

...

1 list?

I recognize this may not be an issue in your specific case, I just
think that issues like these will be more of a deal when we don't keep "members" in per-list silos.

Definitely, and what about when list memberships come from external
rosters (e.g. external systems or generated on demand)?

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRKOfCnEjvBPtnXfVAQJ89AP8DFF6sGVUUhS0kH/+yCmympS4MURhM6k7 1RJCq9M9hBFsS+ZrByWf9N042J+zYPmTeTB4UQEpNdDlauG3VVrcKODazu6juhiL bpC1ccT2jZd22Q5gQcdSiMjE+qmXSrP1VgL9WSl2qC69IGdCNoKn31I3q452zN9x mzCuMbq4c00= =IpxP -----END PGP SIGNATURE-----

On Wed, Jun 21, 2006 at 02:09:44PM +0100, Ian Eiloart wrote:

2. Delete ALL the list members with one click - OK, and maybe a confirm dialog!

Don't forget to fail gracefully if there is no Javascript (ie: server-side generates the confirm dialog).

Regards, Msquared...