On Apr 5, 2015 7:27 PM, "David Andrews" <dandrews@visi.com> wrote:

At 02:48 PM 4/2/2015, Andrew Stuart wrote:

...

What’s on your wishlist for the perfect Mailman web interface? If you

can provide links to show where your ideas are done well that would help to illustrate your thoughts. Any killer features that you’d like to see in the perfect Mailman web interface?

A reminder that any web UI, whether end user, or administrator, needs to

be accessible to disabled persons -- preferably it will use the WCAG 2.0 AA standards.

+1

Bryan

On 04/05/2015 09:33 PM, JB wrote:

There should be no predefined interface, at least none that is not customizable in any way what so ever. As a web developer I should make the decision on the look and feel on my end so that for each site I build, I can completely customize every aspect of the entire interface.

You will have that in Mailman 3. The web UI we provide (Postorius) will be fully functional, but if you don't like it and can't skin it to your liking in Django, you can write your own. The architecture is modular for exactly this reason, The web UI and the core mailing list engine are separate entities that talk to each other via a defined RESTful API.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Monday 06 April 2015, JB wrote:

Ive been gathering that based on the research I have been doing.  I am REALLY looking forward to the new version.  As soon as it is out I will have to put in a feature request to the cPanle folks to make the upgrade ASAP.  As an FYI, they are tad behind the times with MM.  Their last upgrade was this...

Change Log for 11.44.0.2 Thursday, December 04, 2014 11:35 AM Fixed case 99393: Updated mailman to 2.1.18-1.

My web hosting upgraded from 2.1.17 to 2.1.18-1 on June 5 2014 so I'm assuming cPanle customers (not end users like me) can upgrade Mailman when they chose?

In any case plan to ask my host to request 3.0 in parallel with 2.1 if possible. Itching to get a test install up!

William

cPanel has been fairly quick (but not immediate) about merging our updated releases with their custom mods, and making recent versions available to their customers. I expect this will continue with updates to Mailman 2.1.

OTOH, it may be more difficult for cPanel to incorporate Mailman 3. While a large part of cPanel's MM 2.1 customizations have to do with supporting lists with the same list name in different domains on the same Mailman instance, and MM 3 does this out of the box, I expect it will be some time before cPanel offers MM 3.

I posted on cPanel's forums earlier today asking them straight-out if they were planning on including Mailman 3 in their future versions of cPanel/WHM when it became stable. One of their developer's post on the forums indicated that cPanel is definitely aware of the development of Mailman 3 which I found encouraging.

Brian Carpenter Owner, EMWD and Mailmanhost.com

Providing Cloud Services and more for over 15 years.

T: 336.755.0685 E: brian@emwd.com www.emwd.com

David Andrews writes:

A reminder that any web UI, whether end user, or administrator, needs to be accessible to disabled persons -- preferably it will use the WCAG 2.0 AA standards.

We do use industrial-strength web frameworks, mostly Django. To the extent they support the "string-of-letters-and-digits standard", we will certainly take advantage of those capabilities. Javascript- disabled, several of us are definitely in favor and know how to do it.

If that's not good enough, "detailed advice, and better yet designs and patches, welcome!" Sorry, but that's the reality in a volunteer project.

I'm willing to do it for money (hourly rate negotiable) :-), but the LOC per hour would be ruinously low because I am not a spectacularly fast programmer to start with and know nothing about the standard mentioned. Other project members tend to be faster, with less spare time, and quite likely about the same amount of knowledge of the relevant standards (standards that don't start with "RFC" are generally not on our required reading lists).

Please keep the details coming. We care, we just don't have the cycles to do it ourselves without help.

Regards,

Not kicking anyone's cat here but if the ADA applies to web sites then NO WEB PAGE EVER should be allowed to utilize that HORRIBLE 'flat' design strategy. Pages such as the new ESPN page are EXTREMELY difficult to read and sue for people who have vision and reading disabilities.

Having said that (and this may sound contradictory) making sure that pages are usable by ADA people is great but you cannot more difficult or cumbersome in doing so. The ADA complaint should be an alternative page layout if necessary just as many pages (rightfully so) have a mobile version. IOW it is not necessarily as import that all pages being ADA per se as it is that they all have an ADA 'version'.

Executive summary:

1. Some aspects of accessibility (providing text alternatives for non-text media) can be treated like translation (and will increase the burden on translation!)

2. Frameworks need to help point out the "pain points". Like: "Yo! there's an ALT-less image here that you can tag!"

3. Frameworks can and should take advantage of embedded comments in non-text media.

4. I personally don't have much clue about partially sighted (color issues or extreme myopia), or those who lack the dexterity to mouse around. However, frameworks can do a lot of the work for improving accessibility for those less dextrous (tab navigation), and maybe for partial sight?

David Andrews writes:

I know what you say is true. Nevertheless, it makes me sad. Twenty percent of the population has some sort of disability, yet accessibility just isn't taught in computer science courses.

The 85% of the world which strongly prefers to use a language other than English bothers me more, to be honest (especially since that's 100% of my dayjob users). Funny thing, American universities don't teach Japanese and Chinese to their CS students. Sad, isn't it?

The only accessibility tool for the web that I'm familiar with is the ALT attribute for IMG and other non-text elements of HTML. I should think that "filling in the ALT blanks" would be amenable to the same kind of volunteer effort that provides our natural language translations. I hope that a similar kind of separate effort can deal with many of the accessibility issues.

Obviously, the incentive will have to be somewhat different. Unlike translators who generally get involved for their own convenience and have some English ability that grows stronger with the practice, blind people aren't going to be able to write the descriptions of images or video that they need for themselves in many cases, and it's unlikely that they'll improve dramatically with practice. :-( But it should be quite possible to recruit sighted volunteers for the task.

I'm not sure how to deal with the partially sighted, although I suppose use of relative dimensions and some CSS is helpful. But this is exactly where frameworks can help. I'm even less sure what to do about colorblindness, and people who lack sufficient dexterity for "pointing and clicking".

The Justice Department has already said that the web is a place of public accommodation, and the ADA applies. It is only a matter of time before they issue specific regulations. So, in the near future, anyone producing publicly facing web sites will need to do this!

No, they won't -- they can always shut down. And I suspect that's exactly what will happen to most volunteer sites if they try to apply the ADA standards to them. I can't be happy about that. I live in Japan, and I assure you that public policies that equalize benefits by reducing the average suck -- especially for the less-well-off.

Using a current, "industrial-strength framework" is not a guarantee of accessibility, and passing the buck to them will ultimately not hold water.

It had better at least reduce the leakage to a trickle! If it doesn't, accessibility isn't going to happen. Content accessibility really has to be a matter of a separate volunteer effort (especially since every ALT attribute increases the burden on our translators!!), with most of the "pain points" being automatically pointed out by the framework.

And things like checking for color and sufficient size of clickable elements and the like should be automatable.

Realistically, programmers are *not* going to do this in general. In the case of Mailman, we'll do some of it, but it's hard enough to create a usable site for ourselves, let alone the sighted and nimble in general -- I doubt accessibility is something we'll get to in Mailman 3.0 (except to the extent that general usability principles provide a strong basis for accessible pages, as apparently happened with Mailman 2).

Really, you accessibility advocates should be looking for opportunities to organize this kind of effort. The translators prove that such volunteer efforts are practical, and most translators seem to be willing to donate effort to apps they don't use when necessary (obviously, experienced users are preferred). Translators might also be willing to do this kind of thing.

But translation only really took off with the development of gettext -- earlier systems were just too painful all around. So you should also be looking for ways to improve the frameworks. For example, most image, audio, and video media now provide for textual comments embedded in the stream. While most content authors do not (yet) provide useful comments, some do and others would be encouraged to do so if the frameworks automagically extracted them and provided them as default ALT attributes.

By the way, the web UI for Mailman 2.X is very accessible -- at least for blind persons.

That's nice to know!

If anyone has an actual site I can get to, I will take a look.

I'll talk to the developers here at PyCon and search the mailing list for URLs. A few real lists are running with Mailman 3 + Postorius + HyperKitty already, and I'm pretty sure there are a couple of demo sites.

Regards, Steve

Quoting Adam McGreggor <adam-mailman@amyl.org.uk>:

On Thu, Apr 09, 2015 at 02:31:50AM +0900, Stephen J. Turnbull wrote:

...

...

The Justice Department has already said that the web is a place of public accommodation, and the ADA applies. It is only a matter of time before they issue specific regulations. So, in the near future, anyone producing publicly facing web sites will need to do this!

No, they won't -- they can always shut down. And I suspect that's exactly what will happen to most volunteer sites if they try to apply the ADA standards to them. I can't be happy about that. I live in Japan, and I assure you that public policies that equalize benefits by reducing the average suck -- especially for the less-well-off.

Apropos to that, the US DoJ doesn't really have much effect in jurisdictions outside of the US. I do wish we wouldn't be so parochial.

...

Really, you accessibility advocates should be looking for opportunities to organize this kind of effort.

+1

...

A few real lists are running with Mailman 3 + Postorius + HyperKitty already,

are those apps ADA-compliant?

Dave

and I'm pretty sure there are a couple of demo

...

sites.

At least one has been posted to one of the lists; possibly -developers.

-- "Get me a beer. I don't care what kind it is, just get me a beer!" -- Duke of Edinburgh, on being offered the finest Italian wines by PM Giuliano Amato at a dinner in Rome in 2000.

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/geek%40uniserve.com

-- "As long as politics is the shadow cast on society by big business, the attenuation of the shadow will not change the substance."

-- John Dewey

On Thu, Apr 09, 2015 at 02:31:50AM +0900, Stephen J. Turnbull wrote:

The only accessibility tool for the web that I'm familiar with is the ALT attribute for IMG and other non-text elements of HTML.

I'm not an expert, but as I understand it, you can get a long way towards good accessibility by following standard UI guidelines and not fighting the web frameworks. E.g. don't use colour *alone* as the only distinguishing feature between elements. If you have the choice between using open HTML that a screen reader can work with, or closed Flash that screen readers cannot, then use HTML. Don't invent your own "fancy" (i.e. sucky) UI that doesn't interoperate with (e.g.) the tab key functionality that the browser already provides.

Accessibility for the handicapped ("differently abled") actually helps us all, and for the most part shouldn't be too onerous.

-- Steve

Teijo writes:

As to WCAG 2.0, it's W3C's recommendation for Web Content Accessibility Guidelines (http://www.w3.org/TR/WCAG20/).

Maybe this standard is better, but most W3C standards are not very helpful to app developers. They're intended for library and framework developers, as well as conformance testing.

Sounds like not working with JavaScript is something important to you. What’s the thinking behind wanting to work without JavaScript? Isn’t it kinda hard to navigate the modern web without JavaScript?

as

On 7 Apr 2015, at 9:48 am, J.B. Nicholson-Owens <jbn@forestfield.org> wrote:

Andrew Stuart wrote:

Any killer features that you’d like to see in the perfect Mailman web interface?

Thanks for asking.

Such an interface would work completely without running any Javascript to do anything the interface can do. If Javascript is turned off in the browser, the interface should work completely. If Javascript is turned on in the browser, the Javascript should be free software and clearly labeled as free Javascript so the LibreJS add-on will recognize it and let the user run it. But no Javascript would be required to use the Mailman interface at all. I see no reason why anyone's Mailman task should require Javascript.

The perfect Mailman web interface would do what it needs to do with links, form submissions, and CSS but work fully with text-only browsers like lynx, links, and so on.

Disabled persons access is, of course, something a perfect interface would offer. I am sure others can point you to the relevant standards/linters to implement and validate this.

Also, the perfect Mailman web interface would let admins use gratis, auto-renewing[1] TLS certificates such as what letsencrypt.org is proposing to do[2]. Until we can get away from the current ridiculousness to publish encrypted websites, letsencrypt.org is the most promising practical means I know of to increase the number of encrypted websites. A Mailman web interface should offer a 1-click means of acquiring a letsencrypt.org certificate that automatically renews itself until the admin clicks the button again to stop using that letsencrypt.org certificate. And it should be trivially easy to make all visits to the site use encryption.

The defaults for this web interface are critical because they will be what most installations will offer (I believe most users of most programs don't change or investigate defaults).

[1] I know this automation requires the interface's back-end to do the renewing using letsencrypt.org API, but from the admin's perspective this is automatic certificate renewing.

[2] Obviously I don't know the details of letsencrypt.org's setup because they've not yet begun production use of their service.

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/andrew.stuart%40superc...

On 4/6/2015 10:17 PM, Steven D'Aprano <steve@pearwood.info> wrote:

It's not just the popup windows. It's not just the sites that hijack the right-click menu. It's not just the autoplay videos. It's not even the browser crashes! (Mostly Opera, Firefox seems a bit more stable.) Any one of them alone is enough to make Javascript-off-by-default essential, in my opinion. (Thank you Ad-Block!)

Actually, it sounds like NoScript is more what you are looking for (I use AdBlock too though)...

Sorry if I enter now in the thread at an arbitrary point.

Sincerely I'm rather happy with the *current* mailman interface, and in particular I'm used to it.

Considered that there should be quite a large base of mailman lists around, that they are unlikely to migrate to a new UI soon, and that list administrator tasks are something one does rather seldom ...

... e.g. I administrate a very small list (10 subscribers) on my machine (probably will add a couple soon), I moderate a quite larger (>1000 subscribers) nationwide on a server in another city, and administrate a couple intermediate ones (~300 and >20 subscribers) in another continent, while I do not count the lists I'm subscribed as a user ...

... and the frequency of access as archive user / moderating out spam / customizing my user profile / customizing list parameters / initial setup of a list goes in decreasing order ...

... my main requisite would be that any new mailman UI remains as close as possible to the current one (or has a way to revert to it) !!!

Possibly the only real "improvement" (change) I'd like would be in the way to go through the subscriber list (e.g. scroll alphabetically, or search users who have a specific flag settings).

--

Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html

Do not like Firefox >=29 ? Get Pale Moon ! http://www.palemoon.org

On Tue, Apr 07, 2015 at 08:31:04AM -0400, Jim Popovitch wrote:

On Mon, Apr 6, 2015 at 10:17 PM, Steven D'Aprano <steve@pearwood.info> wrote:

...

I'm not happy when web sites *demand* that you run their untrusted and untrustworthy code in your computer before you can see the content.

How do you currently see the HTML content before it is interpreted by your computer?

This is increasingly getting less and less on-topic, but to give a brief answer, HTML is a markup language, not a programming language. (I'm aware that technically HTML5 + CSS is Turing complete, but it's completely impractical as a programming language.) Web devs use Javascript because it allows them to run more or less arbitrary code, which is either impossible or impossibly difficult from HTML alone.

While it is possible that buggy or malicious HTML alone might crash my browser, it is far easier and more likely to do so from Javascript.

-- Steve

On Wed, Apr 08, 2015 at 09:29:23AM -0400, Jim Popovitch wrote:

So, you do want to see the HTML content before it is interpreted by your computer? :-)

As HTML is not executable code, "interpreted" is a misleading word to use. But taking it in the loosest possible way, no, of course not. I have no desire to see raw HTML content, I want my browser to render it, I never said differently.

Look, your JS vs HTML argument is cloudy at best. :-)

I'm sorry that neither I, nor the existence of Javascript malware, have not been able to convince you that there is a large difference between rendering a HTML document and executing code.

I am happy for you to continue allowing Javascript to run in your browser, and you should be happy to allow me to disable it by default even if you think I'm being silly. All I asked for is that Mailman's web UI should degrade gracefully when Javascript is turned off. Is that so wrong?

-- Steve

On 04/08/2015 06:07 PM, Steven D'Aprano wrote:

All I asked for is that Mailman's web UI should degrade gracefully when Javascript is turned off. Is that so wrong?

No it's not and Mailman's developers are highly sensitive to this.

I have not been very much involved in MM 3 development - almost not at all outside of the core (2.1 support still takes a lot of energy and someone has to do it) - but I can assure you that the people working on the Postorius web UI are very much in agreement with you on this.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 6 Apr 2015, at 20:02, Andrew Stuart wrote:

Sounds like not working with JavaScript is something important to you. What’s the thinking behind wanting to work without JavaScript?
Isn’t it kinda hard to navigate the modern web without JavaScript?

I don't know the original poster's motivations, but for me it is entirely practical. I work in a diverse variety of environments administering a complex menagerie of systems and Mailman is just one small piece of that. I frequently don't have a convenient modern GUI browser configured to my tastes/paranoias running on a network I trust, and it is actually more convenient for me to use a text browser with weak or no JS support (yes, really.) It is also an issue for user support, since users do work with the MM web interface from time to time. JS is an area where interop between browsers and the diverse ways users tweak them is at its worst. Supporting users who have found new ways for the MM web interface to not work because of JS subtleties sounds like at least the 6th ring of Hell. Also, sticking with a pure HTML client interface makes it easier to validate its security, e.g. a site with no scripts has no XSS vulnerabilities. MM isn't the sort of web application that one spends hours at a time using, so the slicker operation you can get from a JS-heavy system isn't really very valuable.

Short version: a tool like the MM web interface should minimize the possible failure modes even if that means sacrificing some fluidity of use.

As someone who raised this issue 15 years ago and was seriously rebuffed with lots of notes that said essentially "this is a mailing list and not a web forum" I then started looking elsewhere.

Anyway, my NGO has put a lot into our web interface for our primarily email based set of neighborhood forums built on GPL GroupServer:

http://forums.e-democracy.org

Kick the tires and "steal" as much as you can for Mailman.

I'd check out what other mail-centric platforms have also developed like: http://wordsandwriting.github.io/lumen/ http://DGroups.org https://www.sympa.org/

Personally, it would be great to see all these "open source" mailing list projects work together ... despite the different code bases. Our members increasingly expect Facebook Groups like experiences and discovery of new groups to join, etc. ... and I don't see how we attract the next generation of users without upgrading our web-based design and engagement (why still preserving full email participation).

On Tue, Apr 7, 2015 at 1:30 PM, Dave Stevens <geek@uniserve.com> wrote:

Quoting Bill Cole <mailmanu-20150316@billmail.scconsult.com>:

...

On 6 Apr 2015, at 20:02, Andrew Stuart wrote:

...

Sounds like not working with JavaScript is something important to you. What’s the thinking behind wanting to work without JavaScript? Isn’t it kinda hard to navigate the modern web without JavaScript?

I don't know the original poster's motivations, but for me it is entirely practical. I work in a diverse variety of environments administering a complex menagerie of systems and Mailman is just one small piece of that. I frequently don't have a convenient modern GUI browser configured to my tastes/paranoias running on a network I trust, and it is actually more convenient for me to use a text browser with weak or no JS support (yes, really.) It is also an issue for user support, since users do work with the MM web interface from time to time. JS is an area where interop between browsers and the diverse ways users tweak them is at its worst. Supporting users who have found new ways for the MM web interface to not work because of JS subtleties sounds like at least the 6th ring of Hell. Also, sticking with a pure HTML client interface makes it easier to validate its security, e.g. a site with no scripts has no XSS vulnerabilities. MM isn't the sort of web application that one spends hours at a time using, so the slicker operation you can get from a JS-heavy system isn't really very valuable.

Short version: a tool like the MM web interface should minimize the possible failure modes even if that means sacrificing some fluidity of use.

+1

D

...

---

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/geek%40uniserve.com

-- "As long as politics is the shadow cast on society by big business, the attenuation of the shadow will not change the substance."

-- John Dewey

---

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/slc%40publicus.net

On 4/8/15 11:34 PM, Peter Shute wrote:

Andrew Stuart wrote:

...

What's on your wishlist for the perfect Mailman web interface? It would be helpful to me if it somehow allowed an iOS browser to stay logged in. I haven't found one that will - something to do with cookies expiring when the app is in the background, I think.

Peter Shute

My understanding is this is a basic problem about using session cookies. In iOS, the browser "session" can end even without "closing" the browser, buy switching to another app, and the OS deciding it needs the memory from the browser so it unloads it, causing the cookies to disappear. Perhaps using a "long-lived" login cookie, but that has other security issues, and I am not positive that iOS browsers keep those either (and many more people have these disabled by default).

-- Richard Damon

On 4/9/15 8:49 PM, Peter Shute wrote:

Richard Damon wrote:

...

...

It would be helpful to me if it somehow allowed an iOS browser to stay logged in. I haven't found one that will - something to do with cookies expiring when the app is in the background, I think. Peter Shute

My understanding is this is a basic problem about using session cookies. In iOS, the browser "session" can end even without "closing" the browser, buy switching to another app, and the OS deciding it needs the memory from the browser so it unloads it, causing the cookies to disappear. Perhaps using a "long-lived" login cookie, but that has other security issues, and I am not positive that iOS browsers keep those either (and many more people have these disabled by default). I can stay logged in for months on some other web sites, so it can be done. I guess it's just a matter of how adopting the same methods would affect security.

What I would normally do in cases like this is save the password in the browser, but for some reason Safari and other browsers don't offer that option for mailman logins - maybe something to do with the form only asking for a password, and not a username? If getting the login to survive going into the background isn't appropriate then doing whatever it takes to make the browser realise it's a login page would be a good second best.

That said, I haven't tested how long a Safari login will survive for a while now. Maybe the latest iOS does better.

Peter Shute

Web sites that keep you logged in for a long period of time tend to use a "long-lived" cookie to validate you (in addition to the session cookie like Mailman uses). Normally this cookie holds a token that the site will accept as a valid log in for you. The security risk is that if something gets hold of this cookie, then it too can log into the site, and thus presents a security risk. How big a risk depends on a number of factors.

Yes, I suspect that the lack of a user name on the admin pages is what trips up most password memory systems.

-- Richard Damon