[Mailman-Developers] Hi! I'll be your intern for the summer :)
i at mindlace.net
Thu Jun 29 07:14:14 CEST 2006
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
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.
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
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
> 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
Yes. Basically my approach is punting on pre-rendering archives entirely
in favor of dynamically rendering* the .mbox / rfc8222 files as
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.
More information about the Mailman-Developers