New Web Interface

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)

-  ⇤ ← Revision 3 as of 2008-06-18 13:34:21 → 
  Size: 2034
  Editor: terri
  Comment:
+   ← Revision 15 as of 2010-02-22 21:55:17 → ⇥
  Size: 7294
  Editor: p@state-of-mind
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 1:
-#pragma page-filename DEV/versions/4489291
= Summer of Code/Templating: =
 1. [[..//2006/08/20/Summer of Code summary|Summer of Code summary]]  - the project for 2006 concentrated on new ideas for the web UI, and [[../~mindlace|~mindlace]] has an excellent summary here of what was tried
+#pragma page-filename DEV/versions/8978903
= 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 are some [[../Web UI Mockups|Web UI Mockups]].

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

The Mailman WUI will be developed on [[https://edge.launchpad.net/mailmanweb|Launchpad]], and discussions will be conducted on the [[http://mail.python.org/mailman/listinfo/mailman-developers|mailman-developers]] mailing list.

Please add your name to this list if you are interested in helping out!

 * [[~barry/Home|Barry Warsaw]]
 * [[~p@state-of-mind.de/Home|Patrick Ben Koetter]]
== Guidelines ==
 1. Modern, easy to use web user interface for users, list admins, and site admins.
 1. 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.
 1. 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.
 1. WUI template system must be Python-based (framework TBD) and GPLv3 compatible.
 1. {{{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 [[http://www.python.org/doc/current/library/gettext.html|gettext]] catalog.
 * Of course, written in Python :-)
Here's a table of templating system candidates:

{{{#!table
'''Framework'''
|| '''Pros'''
|| '''Cons'''
==
[[http://www.cheetahtemplate.org/|Cheetah]]
|| 
|| 
}}}
= Previous work =
(This should probably be moved off onto a separate page - BAW)

== 2006 Summer of Code ==
 1. [[..//2006/08/20/Summer of Code summary|Summer of Code summary]] - the project for 2006 concentrated on new ideas for the web UI, and [[../~mindlace|~mindlace]] has an excellent summary here of what was tried
-Line 6:
+Line 47:
-= Specific suggestions =
== Member/subscriber Interface ==
+== "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 ===
-Line 11:
+Line 99:
-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
+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
-Line 17:
+Line 105:
-== List Admin interface ==
+=== List Admin interface ===
-Line 25:
+Line 113:
 . Typographically bad, e.g. no visual cues about significance, related options, etc.
-Line 27:
+Line 115:
 . Labels are too verbose, contributing with noise to the overall view, and the "Details
-Line 31:
+Line 119:
-= Other Notes =
+From [[http://www.mail-archive.com/mailman-users%40python.org/msg49700.html]] (this is [[../~terri|~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.
 1. 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.
 1. 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.)

Framework	Pros	Cons
Cheetah