[Mailman-Developers] Hi! I'll be your intern for the summer :)

[emf]

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