Revision 10 as of 2010-01-23 09:30:52

Clear message

New Web Interface

Mailman 3 comes with a new architecture which allows for a separation between the web user interface (WUI) and the mailing list engine. In fact, you can run Mailman 3 with no WUI at all, or integration Mailman 3 with the rest of your web site by accessing the REST admin interface.

For standalone systems, we want to develop and ship our own updated WUI. The original Mailman 2 user interface was designed in the late 1990's so it's clearly dated, and the technology backing it is ancient, inflexible and non-standard. Today, there are tons of great Python-based web frameworks, and of course JavaScript is all the rage today. We want a modern, good looking, well-organized WUI that can be used with Mailman 3 but is optional for those sites that want to heavily customize their use of Mailman.

Here then are some guidelines, along with historical notes about previous attempts to update the Mailman WUI.

The Mailman WUI will be developed on Launchpad, and discussions will be conducted on the mailman-developers mailing list.

Guidelines

  1. Modern, easy to use web user interface for users, list admins, and site admins.
  2. Progressive enhancement; i.e. can use JavaScript for dynamic aspects, but must remain usable for non-JavaScript browsers, and must be friendly to screen readers.

  3. WUI templates must support internationalization by allowing us to mark up translatable texts for inclusion in the gettext catalog. Technology must integrate with Python's gettext module and/or Mailman's i18n infrastructure.

  4. WUI template system must be Python-based (framework TBD) and GPLv3 compatible.
  5. JavaScript library must be GPLv3 compatible (framework TBD).

Templating systems

Exactly which templating system we'll choose is TBD. A couple of thoughts though:

  • It would be nice to use the same templating system in the WUI and core engine. I'd like to be able to use templates for all email that Mailman sends
  • It should be friendly to DEV/Internationalization. Meaning it should be possible to extract texts from templates and add them to a gettext catalog.

  • Of course, written in Python :-)

Previous work

(This should probably be moved off onto a separate page - BAW)

2006 Summer of Code

  1. Summer of Code summary - the project for 2006 concentrated on new ideas for the web UI, and ~mindlace has an excellent summary here of what was tried

    1. StyledPages

    2. TemplatingNotes

"Simple" versions of interfaces

From http://www.mail-archive.com/mailman-developers@python.org/msg11021.html

List admin:
   Jason said:
   #1.  Manage subscriber list
       I think this needs bulk un/subscribe. Strong warnings about legal requirements should be present. Perhaps with localised links to guidance.
       Should also put individual moderation here. Perhaps some other options.
   #2.  Manage digest/non digest options
       I'm not sure this is absolutely required in a simple interface.
   #3.  Emergency moderation
       Yes!
   #4.  Archives (Public/private settings), navigate to archives, (maybe censor an archived message).

   Cristóbal added:
   #5 3 PRESETS:
       announce-only list vs.
       moderated discussion vs.
       open discussion
   #6 List Description
       web landing page description
       footer content

   I would add:
   #7 search for a list member.
   #8 Display/export entire membership list.
   #9 Add/remove a moderator
   #10 contact a system administrator to
       Request list removal,
       Request a new list, or
       Get help

Site admin:
----------
   site management (define lists, and list ownership, apply emergency moderation):
   #1 Display lists, with ownership and emergency moderation status.
       Perhaps sort/filter by owner or domain, style or moderation status, traffic.
   #2 Add a list with a preset style/change style.
   #3 Disable or Delete a list, and/or list archive.
   #4 Change a list owner or moderator.
   list management:
   #5 disable list features  (eg, to prevent the owner from changing footer content).
   #6 manage a list - with full feature set
   #7 become list owner - (so you can see the effect of disabling features)

Other Specific suggestions

Member/subscriber Interface

From http://www.mail-archive.com/mailman-users%40python.org/msg49681.html:

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.

List Admin interface

From http://www.mail-archive.com/mailman-users%40python.org/msg49698.html

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.

From http://www.mail-archive.com/mailman-users%40python.org/msg49700.html (this is ~terri)

My solution (to the problem of there being so many options) 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.)