Terri Oda wrote:
- 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.
- 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.
- 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.
- 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.
- 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