Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 18, 2010, at 01:46 PM, Stephen J. Turnbull wrote: Barry Warsaw writes: It's an interesting idea, but I'm not quite sure how a webserver pipeline would work. The way the list server pipeline works now is by treating messages as jobs that flow through the system. A web request is kind of a different beast. Why? Abstractly, both web requests and mail messages are packages of data divided into metadata and payload. You line up a sequence of Handlers, each one looks at the metadata and decides whether it wants a crack at the package or not. If no, back to the pipeline. If yes, it may process metadata or payload (possibly modifying them), then decide to (a) do something final (reject/discard it or send something back out to the outside world), or (b) punt it back to the pipeline for further processing. The primary difference is that with email jobs, we can handle the asynchronously and there's little demand on handling them quickly. Web requests are synchronous and must be handle immediately, or the browser will time out. It's certainly possible to turn a web request into an asynchronous job, but it's much more complicated, and we don't often have the same access to the underlying jobs. With the email pipeline the MTA hands us a message and that (plus an accompanying metadata dictionary) *is* the job. Usually with a web request we don't have quite the same thing, even in a WSGI environment. You can also keep state across requests. If it's request-specific the nature of HTTP and email both require cookies (aka one-time keys). So, what's so different? I'm not sure I follow about email requiring cookies. It seems to me that it might also make communication between the webserver and the mail server(s) easier to organize (eg, when the user sends email to list-subcribe, then confirms by clicking on the web URL in the response) if these jobs had a unified format. I don't quite see how that follows. It's possible that having a thousand handlers all looking at everything would be horribly inefficient, then you could divide things up into subpipelines (in the Linux kernel firewall they're called chains), with master Handlers in the toplevel pipeline dispatching to lower level subpipelines. I thought that was how Mailman 3 was organized. I know that Mailman 2's mail pipeline has inspired a lot of my thoughts about how Roundup's internal implementation could be improved. (Roundup auditors and reactors look a lot like Handlers.) I guess I'd better go look more closely at Mailman 3. Mailman 3 has the same basic architecture, except that the rule-checking handlers live in a different pipeline and have a slightly different semantic and interface. Please do take a look! -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Barry Warsaw writes: It's an interesting idea, but I'm not quite sure how a webserver pipeline would work. The way the list server pipeline works now is by treating messages as jobs that flow through the system. A web request is kind of a different beast. Why? Abstractly, both web requests and mail messages are packages of data divided into metadata and payload. You line up a sequence of Handlers, each one looks at the metadata and decides whether it wants a crack at the package or not. If no, back to the pipeline. If yes, it may process metadata or payload (possibly modifying them), then decide to (a) do something final (reject/discard it or send something back out to the outside world), or (b) punt it back to the pipeline for further processing. You can also keep state across requests. If it's request-specific the nature of HTTP and email both require cookies (aka one-time keys). So, what's so different? It seems to me that it might also make communication between the webserver and the mail server(s) easier to organize (eg, when the user sends email to list-subcribe, then confirms by clicking on the web URL in the response) if these jobs had a unified format. It's possible that having a thousand handlers all looking at everything would be horribly inefficient, then you could divide things up into subpipelines (in the Linux kernel firewall they're called chains), with master Handlers in the toplevel pipeline dispatching to lower level subpipelines. I thought that was how Mailman 3 was organized. I know that Mailman 2's mail pipeline has inspired a lot of my thoughts about how Roundup's internal implementation could be improved. (Roundup auditors and reactors look a lot like Handlers.) I guess I'd better go look more closely at Mailman 3. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Wed, Jun 16, 2010 at 12:57:59AM -0400, Cristóbal Palmer wrote: While I'm digging around and thinking of other anti-spam tools, maybe it's worth digging around in here for ideas, since this seems rather popular with WordPress: http://www.bad-behavior.ioerror.us/documentation/ Another one to look at (I'm not exactly a 'fan' of bad-behavior), is http://mollom.com/features (and http://mollom.com/benefits) -- it's quite a popular (aiui) plugin/module for Drupal-based/powered sites to use. (apparently, there's a Python library available at http://github.com/itkovian/PyMollom) -- A traitor may betray himself and do good that he does not intend -- J. R. R. Tolkien ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Cristóbal Palmer writes: On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote: The question is what are they protecting? My claim is that if you're protecting economic resources (bandwidth, accurate counts of real users) they may be more or less useful. If it's a security issue -- including ways of harvesting email addresses that involve subscribing -- though, you're busted. To my mind the main resources we're protecting are moderator time and site owner time, and we're admittedly cost shifting onto subscribers for lists where CAPTCHAs are enabled. I consider that a valid tradeoff, with the breakeven point to be determined by the moderators/list owners/site owners. OK, I'm happy again, no crazy people here. :-) But think of it this way: if what mailman does is provide a plugin spot for something external to do CAPTCHA or CAPTCHA-like work, then some non-CAPTCHA method could be inserted that doesn't impose user load. But IMO the pipeline architecture already does that. I haven't looked closely at the Mailman 3 webserver, but my understanding is that it gets a pipeline too. It seems to me that once you have that (and IMHO that is extremely desirable just by analogy to the list processing pipeline, which I have written several Handlers for), the rest is going to be pretty CAPTCHA-specific, and quite possibly specific to the particular CAPTCHA implementation. It might be worth recommending a third-party implementation of a best-of-breed (reCAPTCHA?) plugin or even providing one ourselves, but I plan to leave that decision to Barry, as long as the documentation for any such feature points out the limitations of the technology. Also, sorry about your stolen bike. :( Don't be. It was a $150 bike, and the Minister of Finance in my house approved purchase of a $670 replacement. :-) All I really lost was a junk lock and about $50 resale value. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 16, 2010, at 12:33 AM, Cristóbal Palmer wrote: Are you saying that no scripts/bots can automatically sign up for mailman lists? I get plenty of signups like qneu45...@nanke62w.net that suggest otherwise. I should take the time to log those and send them to you, perhaps? After my masters paper... Only if I can send you all the bounces and unsubs I get every month on Mailman day. :) Okay... now that I've put all this energy into this explanation, I'll admit: spam to list owners, especially of the Dear $LISTNAME owner, we at $SITENAME security need you to reset your password. Please find instructions in the attached .zip file... were a much bigger problem a couple of years ago (surprisingly even after implementing SA) until I decided to block .zip and several other mime types at the MTA level. So if y'all have no interest in doing any reCAPTCHA integration, I'll just spend that much more time making anti-spam tweaks at the MTA level, and I'll field one or two more I'm a moderator and I'm dealing with a lot of spam here tickets every now and then. Two points: antispam defenses are always going to be better done in the MTA upstream of Mailman. We may provide some hooks to allow integration with SA/spambayes/clam/etc. but just seeing the cpu these take up on my measly server I do not think I want such a check running on everything teh intarwebs can throw at your lists domain. Second, I intend to pass -owner email through a pipeline the way posted messages go through, so you will at least have the opportunity to do some content and other checks on the message before they're forwarded to the owners. That's another point, come to think of it: I've had plenty of time and experience running a couple of decently-sized mailman installs, but what about the many, many people who have less experience running mailman? The easier we make it for them to make it hard on spammers, the better. Yes, we should be opinionated and make reasonable defaults so that it's easy to install and run a working system, with good tradeoffs between usability, functionality and security. These are not always easy tradeoffs to make. A final note: are there any published user studies on mailman? I see your ATEC '03 and LISA '98 presentations in the ACM portal, and I see http://www.gnu.org/software/mailman/otherstuff.html ... but nothing else turns up in google scholar. Please point me to other research on mailman and its user base if it exists. If it doesn't, maybe I need to make that happen Terri was talking at one point of contracting such research, and I think some is being done as part of the GSoC work. None exists that I know of. If you're offering, I'm sure we would love to have some additional solid usability studies, especially focused on helping to guide Mailman 3 design. Thanks so much for all the work all of you do. It really is a pleasure and a privilege to be involved. Thanks to you and everyone who contributes to Mailman development. It truly is a great community. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 16, 2010, at 09:44 PM, Stephen J. Turnbull wrote: But IMO the pipeline architecture already does that. I haven't looked closely at the Mailman 3 webserver, but my understanding is that it gets a pipeline too. It seems to me that once you have that (and IMHO that is extremely desirable just by analogy to the list processing pipeline, which I have written several Handlers for), the rest is going to be pretty CAPTCHA-specific, and quite possibly specific to the particular CAPTCHA implementation. It's an interesting idea, but I'm not quite sure how a webserver pipeline would work. The way the list server pipeline works now is by treating messages as jobs that flow through the system. A web request is kind of a different beast. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Before getting into this (long) reply, I want to re-emphasize that what I want is (1) the ability to plug in existing CAPTCHA systems (notably reCAPTCHA) quickly and easily, and change simple config settings to enable those CAPTCHAs for parts of the interface that have been tested and confirmed to make sense. And (2) I want other (non-CAPTCHA, probably transparent to most users) changes to some points (eg. new user signup, moderator login) in the default MM interface that are designed to reduce abuse. I want (1) merely to the extent that it helps with (2). With that, more reply below. On Tue, Jun 15, 2010 at 01:15:47PM +0900, Stephen J. Turnbull wrote: Not every three-line patch needs to be a standard feature. Or 300-line patch, for that matter. But some do. Are captchas a feature that ordinary Mailman users need? Or are they something that if you know enough to know why you need them, you know enough to code an appropriate Handler? (Or snaffle one from the CheeseShop, for that matter.) I have my opinion ;-), but I'm willing to be corrected. :-| While I could in theory maintain a patch, I have a lot of machines to herd, and I am unlikely to customize anything unless I must do so in order to meet a requirement. I very much want upstream to maintain anything that is reasonable and I will configure within the parameters set by them. This is not an issue of my expertise. This is an issue of maintainability and good use of admin time. I subscribe to a *lot* of Mailman lists. So do I, but neither of us can claim (as individuals) to be representative of mailman users (subscribers, moderators, list owners, etc.), and in this case our claims seem to clash, so we need to look elsewhere. I would be mildly annoyed if uninformed list owners started using captchas just because they're easy to configure and because a lot of big names use them. At this point, I don't see a good reason to make it easy to annoy millions of subscribers that way. While I share your distaste for bad implementations of... anything, really, CAPTCHAs do not annoy me unless they are poorly implemented, and they do not have to be poorly implemented. If you're going to say that millions of subscribers are going to be annoyed, please cite some studies. Here, I'll start: (As an aside, please contact me off-list if you're not able to access the full text for one or more of the papers cited below, and I will arrange for you to have access.) (1) Yan, J. and El Ahmad, A. S. 2008. Usability of CAPTCHAs or usability issues in CAPTCHA design. In Proceedings of the 4th Symposium on Usable Privacy and Security (Pittsburgh, Pennsylvania, July 23 - 25, 2008). SOUPS '08, vol. 337. ACM, New York, NY, 44-52. DOI= http://doi.acm.org/10.1145/1408664.1408671 ABSTRACT CAPTCHA is now almost a standard security technology, and has found widespread application in commercial websites. Usability and robustness are two fundamental issues with CAPTCHA, and they often interconnect with each other. This paper discusses usability issues that should be considered and addressed in the design of CAPTCHAs. Some of these issues are intuitive, but some others have subtle implications for robustness (or security). A simple but novel framework for examining CAPTCHA usability is also proposed. (2) Bigham, J. P. and Cavender, A. C. 2009. Evaluating existing audio CAPTCHAs and an interface optimized for non-visual use. In Proceedings of the 27th international Conference on Human Factors in Computing Systems (Boston, MA, USA, April 04 - 09, 2009). CHI '09. ACM, New York, NY, 1829-1838. DOI= http://doi.acm.org/10.1145/1518701.1518983 ABSTRACT Audio CAPTCHAs were introduced as an accessible alternative for those unable to use the more common visual CAPTCHAs, but anecdotal accounts have suggested that they may be more difficult to solve. This paper demonstrates in a large study of more than 150 participants that existing audio CAPTCHAs are clearly more difficult and time-consuming to complete as compared to visual CAPTCHAs for both blind and sighted users. In order to address this concern, we developed and evaluated a new interface for solving CAPTCHAs optimized for non-visual use that can be added in-place to existing audio CAPTCHAs. In a subsequent study, the optimized interface increased the success rate of blind participants by 59% on audio CAPTCHAs, illustrating a broadly applicable principle of accessible design: the most usable audio interfaces are often not direct translations of existing visual interfaces. And finally, my favorite: (3) M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re: CAPTCHAs–Understanding CAPTCHA-Solving Services in an Economic Context. Proceedings of the USENIX Security Symposium, Washington, D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf ABSTRACT Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense used to protect open Web resources from being exploited at scale. An effective
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 13, 2010, at 05:16 PM, Cristóbal Palmer wrote: If there's some other non-CAPTCHA approach (or set of approaches) that we could use to help reduce spammy signups, then I'm all for it. I guess my hope is that we'd have something in place that reduces the signups themselves rather than imposing work or workflow changes on moderators or list members after they've joined. If that's necessary, fine, but let's try things that happen at the signup step, too, yes? Even something as simple as requiring a hidden form field NONCE and conservative rate limits on public signups, neither of which require javascript or images Given that all signups require an email validation step, and that we'll rate-limit that to prevent using signups as a spam vector, what additional protection does captcha provide? -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Cristóbal Palmer writes: While I could in theory maintain a patch, I have a lot of machines to herd, and I am unlikely to customize anything unless I must do so in order to meet a requirement. This is a straw man in the context of the Mailman pipelined architecture and the CheeseShop. While I share your distaste for bad implementations of... anything, really, CAPTCHAs do not annoy me unless they are poorly implemented, and they do not have to be poorly implemented. Show me some well-implemented CAPTCHAs. Maybe I don't have to avoid them any more. However, the ones I have seen recently are no better than the ones I was seeing 3 or 4 years ago, and they still involve extra clicks, extra typing, and eyestrain. For blog comments, a CAPTCHA invariably means I'll move on. I'd also like to see evidence that CAPTCHAs work better than other efforts at confusing the attacker. M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re: CAPTCHAs~Understanding CAPTCHA-Solving Services in an Economic Context. Proceedings of the USENIX Security Symposium, Washington, D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf ABSTRACT Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense used to protect open Web resources from being exploited at scale. An effective CAPTCHA resists existing mechanistic software solving, yet can be solved with high probability by a human being. In response, a robust solving ecosystem has emerged, reselling both automated solving technology and real-time human labor to bypass these protections. Thus, CAPTCHAs can increasingly be understood and evaluated in purely economic terms; the market price of a solution vs the monetizable value of the asset being protected. We examine the market-side of this question in depth, analyzing the behavior and dynamics of CAPTCHA-solving service providers, their price performance, and the underlying labor markets driving this economy. Heck, I could have written that paper. So I'm going to disagree with your premise that CAPTCHAs are necessarily annoying to most people unless you give more than anecdotal evidence that that is the case, There are plenty of studies showing that every extra click is costly. What I mean by annoying is increases the probability of an exit click vs. staying on this site. and I'm going to disagree that they are always or even usually useless for protecting parts of WUIs. The question is what are they protecting? My claim is that if you're protecting economic resources (bandwidth, accurate counts of real users) they may be more or less useful. If it's a security issue -- including ways of harvesting email addresses that involve subscribing -- though, you're busted. (2) it should need to be enabled by the site admin (and off by default); Agreed, but only to the extent that having it available by default would add a dependency, which is too much of a burden on the MM team. Mailman should clearly not provide any CAPTCHA implementation itself, given your claims of rapid progress in the field. (3) both configuration tools should have documentation indicating that captchas do not provide security; what they do is chase off the frivolous (both bona fide users and would-be abusers). This is a genuine benefit in several ways for many lists; it's just not real security because serious abusers will get through. Disagree. This is like saying that putting a $30 (USD) cable lock on my bike is not security because serious thieves could defeat it with a large pair of bolt cutters. Yes, exactly. My point is that you and I understand defense in depth and the economic aspects of security; most people think in terms of privacy leaks or hacking the financial system, which is far more severe than the loss of a bicycle. Mind you, I use a ~$100 (USD) chain lock on my bikes, but that doesn't mean the $30 (USD) cable lock is useless, It is where I live. My $25 USD (1982 prices) Kryptonite lock is still in service, and I have never lost a bike when using it. I did lose a $150 bike with a 4000 yen (1993 prices, ~$30) chain lock on it, in less than 4 months, though. You seem to think that only $100 (USD) chain locks are worth the effort, In fact, for the bike lock, I do. A good bike lock lasts forever (unless the thieves take the whole bike rack, nothing's perfect ;-). Unless you know your bike-riding life will last less than a year, there's no real point in buying less than than best bike lock available. Note how much knowledge and planning is required to make a good decision here! Computers are even harder This is not true for computer network services, however, where the stakes are higher and defense in depth is necessary. and that I'm insisting people use cheap locks. No, that's not my claim. My claim is that it is unethical to make weak locks available for free, without
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Tue, Jun 15, 2010 at 10:44:03PM -0400, Barry Warsaw wrote: Given that all signups require an email validation step, and that we'll rate-limit that to prevent using signups as a spam vector, what additional protection does captcha provide? Are you saying that no scripts/bots can automatically sign up for mailman lists? I get plenty of signups like qneu45...@nanke62w.net that suggest otherwise. I should take the time to log those and send them to you, perhaps? After my masters paper... Most of these numbers are educated guess numbers; if you want real, validated numbers they'll have to wait, again, until I turn in my masters paper. With that... Let's say I have a large list that receives 16 signups a day, and of those two are actually humans and not scripts. The list owner, having had trouble with spammy signups in the past, has set the list to require moderator approval before users can post. What are the human costs? We'll say that the two human signups took 40s each (80s), and the moderator also took 40 seconds per signup (640s), for a total of 720s = 12 minutes. Now let's assume the reCAPTCHA adds 13s[0] to real human signups and cuts down spammy signups to 4 per day and re-run our math. The two people now spend 106s and the moderator spends 160s, or 4.43 minutes. Yes, we've shifted some costs to our subscribers, but they do that once, and the moderator gets back time daily. What's more, we've increased their burden by just over a quarter and almost divided the moderators burden by three. And we haven't even mentioned the increased cost to the spammer, or (in the case of reCAPTCHA) the benefit to society the CAPTCHA solving work. That's the real point of all this: drive up the cost to spammers as much as possible while imposing as little burden as is reasonable on list owners, moderators, subscribers, site admins, etc. We can't exactly follow the metafilter model[0] here, and I think this is as good an idea as I have seen, but I'd love for others to propose something else that imposes less of a burden on subscribers and we know will drive up costs to spammers over a longer-term basis. Again, I don't even propose we turn this on by default. I would just like to see this as a documented, tested option that can be enabled by site admins and cleanly upgraded without extra work. Okay... now that I've put all this energy into this explanation, I'll admit: spam to list owners, especially of the Dear $LISTNAME owner, we at $SITENAME security need you to reset your password. Please find instructions in the attached .zip file... were a much bigger problem a couple of years ago (surprisingly even after implementing SA) until I decided to block .zip and several other mime types at the MTA level. So if y'all have no interest in doing any reCAPTCHA integration, I'll just spend that much more time making anti-spam tweaks at the MTA level, and I'll field one or two more I'm a moderator and I'm dealing with a lot of spam here tickets every now and then. That's another point, come to think of it: I've had plenty of time and experience running a couple of decently-sized mailman installs, but what about the many, many people who have less experience running mailman? The easier we make it for them to make it hard on spammers, the better. A final note: are there any published user studies on mailman? I see your ATEC '03 and LISA '98 presentations in the ACM portal, and I see http://www.gnu.org/software/mailman/otherstuff.html ... but nothing else turns up in google scholar. Please point me to other research on mailman and its user base if it exists. If it doesn't, maybe I need to make that happen Thanks so much for all the work all of you do. It really is a pleasure and a privilege to be involved. Cheers, -- Cristóbal Palmer ibiblio.org metalab.unc.edu [0] http://www.sciencemag.org/cgi/content/full/321/5895/1465 reCAPTCHA: Human-Based Character Recognition via Web Security Measures. Originally published in Science Express on 14 August 2008 Science 12 September 2008: Vol. 321. no. 5895, pp. 1465 - 1468 DOI: 10.1126/science.1160379 Quoting: User testing on our site (http://captcha.net) showed that it took 13.51 s on average (SD = 6.37) for 1000 randomly chosen users to solve a seven-letter conventional CAPTCHA (25th percentile was 8.28 s, median was 12.62 s, and 75th percentile was 17.12 s), whereas it took 13.06 s on average (SD = 7.67) for a different set of 1000 randomly chosen users (also from http://captcha.net) to solve a reCAPTCHA (25th percentile was 5.79 s, median was 12.64 s, and 75th percentile was 18.91 s). [1] Charge five US dollars (paypal) for an account. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe:
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote: The question is what are they protecting? My claim is that if you're protecting economic resources (bandwidth, accurate counts of real users) they may be more or less useful. If it's a security issue -- including ways of harvesting email addresses that involve subscribing -- though, you're busted. To my mind the main resources we're protecting are moderator time and site owner time, and we're admittedly cost shifting onto subscribers for lists where CAPTCHAs are enabled. Mailman should clearly not provide any CAPTCHA implementation itself, given your claims of rapid progress in the field. Not my claim. Others in the literature. I can do more digging if you don't believe me or don't have institutional access. Regardless, we're in agreement that it should not be the job of the MLM to provide the CAPTCHA. I'd just like a tested, approved way to plug in reCAPTCHA at the moment. I'll do it myself without any help from y'all (after my masters paper), but I think this would benefit the community. and that I'm insisting people use cheap locks. No, that's not my claim. My claim is that it is unethical to make weak locks available for free, without explaining to people their correct use. Ahhh. Very much agree. Also, sorry about your stolen bike. :( The first thing I want to see, then, is documentation that CAPTCHAs are more effective than other methods of confusing the dumb 'bots. http://www.sciencemag.org/cgi/content/full/321/5895/1465 Originally published in Science Express on 14 August 2008 Science 12 September 2008: Vol. 321. no. 5895, pp. 1465 - 1468 DOI: 10.1126/science.1160379 http://recaptcha.net/faq.html Good a place as any take it up with the authors. But think of it this way: if what mailman does is provide a plugin spot for something external to do CAPTCHA or CAPTCHA-like work, then some non-CAPTCHA method could be inserted that doesn't impose user load. For example, people could use a plugin that adds a junk form field that is hidden by CSS, or a simple 1 + 2 math problem, or any number of other things. The point is that we're doing the equivalent of adding braze-ons to the seat stays of a bicycle frame: whether the user adds a sturdy rack, a cheap one, or none at all is up to them. While I'm digging around and thinking of other anti-spam tools, maybe it's worth digging around in here for ideas, since this seems rather popular with WordPress: http://www.bad-behavior.ioerror.us/documentation/ Cheers, -- Cristóbal Palmer ibiblio.org metalab.unc.edu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Eric Bloch writes: I am a lurker here and can concur with Cristóbal's sentiments wrt captchas . I run http://markmail.org where we provide a search index for thousands of public mailman lists (and google groups and other mailing lists as well). The captchas we use (for a variety of purposes) aren't perfect, but they get rid of a lot of junk. How do you know? Post hoc ergo propter hoc is a fallacy. In my (limited and often second-hand) experience, *any* change to a form reduces junk dramatically. Simply using obfuscated names for signup fields (such as swapping the email address variable name and the full name variable name) often reduces signups (presumably the difference is 'bots) significantly. I've heard one report that switching from a homebrew CMS to Drupal (IIRC) was followed by a dramatic increase in signups ... most of the increase being bogus. Nothing against Drupal, just that it apparently provides standard forms for certain purposes, and 'bots take advantage. Any standard and common system (eg, Mailman) which recruits members would face the same problem. Do cosmetic changes work as well as captcha? I don't know. I do know that about 2 years ago I downloaded one of the gocr-based captcha breakers and watched it get 5% to 40% success rates against a star-studded cast (don't recall exactly, but the likes of Google and Yahoo were in there). 95% correct answers may sound good to a college student taking a final exam, but what that means in the case of captchas is bogus signups at a maximum rate of about 3/min. Oops. My conclusion (lacking other data) is that the cost of annoying my users is far greater than the potential benefit. I don't intend to even try to collect real data on captcha efficacy. ;-) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
My experience is not limited nor second hand. We get scanned by plenty of bots every day. We also see captchas broken every day by some bots. Not all bots break the captchas. Not all are trying to, either of course.But without the captchas, the ones that weren't even trying would be getting to things we don't want them to get at. It's that simple. Not a solution, just a screen door in the way - one that I don't mind asking my users to open up by hand as they come in. -Eric From: Stephen J. Turnbull [step...@xemacs.org] Sent: Monday, June 14, 2010 7:11 PM To: Eric Bloch Cc: Cristóbal Palmer; mailman-developers@python.org Subject: Re: [Mailman-Developers] UI for Mailman 3.0 update Eric Bloch writes: I am a lurker here and can concur with Cristóbal's sentiments wrt captchas . I run http://markmail.org where we provide a search index for thousands of public mailman lists (and google groups and other mailing lists as well). The captchas we use (for a variety of purposes) aren't perfect, but they get rid of a lot of junk. How do you know? Post hoc ergo propter hoc is a fallacy. In my (limited and often second-hand) experience, *any* change to a form reduces junk dramatically. Simply using obfuscated names for signup fields (such as swapping the email address variable name and the full name variable name) often reduces signups (presumably the difference is 'bots) significantly. I've heard one report that switching from a homebrew CMS to Drupal (IIRC) was followed by a dramatic increase in signups ... most of the increase being bogus. Nothing against Drupal, just that it apparently provides standard forms for certain purposes, and 'bots take advantage. Any standard and common system (eg, Mailman) which recruits members would face the same problem. Do cosmetic changes work as well as captcha? I don't know. I do know that about 2 years ago I downloaded one of the gocr-based captcha breakers and watched it get 5% to 40% success rates against a star-studded cast (don't recall exactly, but the likes of Google and Yahoo were in there). 95% correct answers may sound good to a college student taking a final exam, but what that means in the case of captchas is bogus signups at a maximum rate of about 3/min. Oops. My conclusion (lacking other data) is that the cost of annoying my users is far greater than the potential benefit. I don't intend to even try to collect real data on captcha efficacy. ;-) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Eric Bloch writes: My experience is not limited nor second hand. We get scanned by plenty of bots every day. Heck, I can beat that: some of my sites get scanned by more bots than they have actual users.wink The question of limited is how many different sites/kinds of sites do you have experience (eg, log access) on? In my case, it's a half dozen or so, plus the talk I hear from other admins in the LUGs etc I hang out with. You can surely beat that, but does your experience generalize to a large fraction of Mailman lists, so that it should be a standard option provided by Mailman? Not every three-line patch needs to be a standard feature. Or 300-line patch, for that matter. But some do. Are captchas a feature that ordinary Mailman users need? Or are they something that if you know enough to know why you need them, you know enough to code an appropriate Handler? (Or snaffle one from the CheeseShop, for that matter.) I have my opinion ;-), but I'm willing to be corrected. :-| We also see captchas broken every day by some bots. Not all bots break the captchas. Not all are trying to, either of course. This is the post hoc part. Of course, you see this, I was assuming you do. But without the captchas, the ones that weren't even trying would be getting to things we don't want them to get at. It's that simple. This is the propter hoc part. It's not that simple. Captcha-using pages are *different* from non-captcha pages. What is it in your experience that shows that the captcha has any additional effect compared to *other* differences that are less annoying to bona fide users? I subscribe to a *lot* of Mailman lists. I would be mildly annoyed if uninformed list owners started using captchas just because they're easy to configure and because a lot of big names use them. At this point, I don't see a good reason to make it easy to annoy millions of subscribers that way. Or lose them, for that matter; I'm an Anonymous Coward on more than one site because I couldn't be bothered to use my neural network to break the captchas. Especially in open source development, the frivolous contributions (eg, one-off bug reports) add up --- we really don't want to encourage features of known cost to the individual subscriber and dubious benefit to the list community. Not to mention that this is an arms race game: the more captchas are used, the more 'bots will be programmed to recognize *and break* them. You admit that you already see successful break-ins every day, and the rate will only increase. They're really mostly suitable for well- informed admins who understand concepts like defense in depth. (But again, those folks can typically cons up a patch pretty quickly. These parts of Mailman are not that hard to modify, especially in Mailman 3.) I guess my bottom line is that if a captcha feature is provided standard in Mailman 3, I believe that (1) it should be configurable per list (and off by default); (2) it should need to be enabled by the site admin (and off by default); The rationale for this is not just to make it harder to use the feature, but that the site admin is likely to be more expert in general to understand the limitations of the feature, and also some of the benefits and costs accrue to the site rather to the list community, so the site admin should have some input. (3) both configuration tools should have documentation indicating that captchas do not provide security; what they do is chase off the frivolous (both bona fide users and would-be abusers). This is a genuine benefit in several ways for many lists; it's just not real security because serious abusers will get through. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Tue, Jun 08, 2010 at 10:12:18PM -0400, Rich Kulawiec wrote: could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. I'd like to re-emphasize the fact that what I would like is some sort of plugin support. Want this kind of CAPTCHA? Take these simple steps But, captchas? Pre-defeated. With all due respect to your experience, I don't think CAPTCHAs as a class have been defeated, in the sense that the goal is not to completely defeat all spam, but rather the goal is to mitigate at relatively low cost to ourselves and at high cost to the spammers, and from personal experience I can say that reCAPTCHA has served that purpose well when I have deployed it. If there's some other non-CAPTCHA approach (or set of approaches) that we could use to help reduce spammy signups, then I'm all for it. I guess my hope is that we'd have something in place that reduces the signups themselves rather than imposing work or workflow changes on moderators or list members after they've joined. If that's necessary, fine, but let's try things that happen at the signup step, too, yes? Even something as simple as requiring a hidden form field NONCE and conservative rate limits on public signups, neither of which require javascript or images Cheers, -- Cristóbal Palmer ibiblio.org metalab.unc.edu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
I am a lurker here and can concur with Cristóbal's sentiments wrt captchas . I run http://markmail.org where we provide a search index for thousands of public mailman lists (and google groups and other mailing lists as well). The captchas we use (for a variety of purposes) aren't perfect, but they get rid of a lot of junk. -Eric But, captchas? Pre-defeated. With all due respect to your experience, I don't think CAPTCHAs as a class have been defeated, in the sense that the goal is not to completely defeat all spam, but rather the goal is to mitigate at relatively low cost to ourselves and at high cost to the spammers, and from personal experience I can say that reCAPTCHA has served that purpose well when I have deployed it. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
At 02:50 PM 6/6/2010, Patrick Ben Koetter wrote: Great. I can see and I need to use my imagination to figure what a _real good_ interface for visually imapaired people looks like. Better to have people who really know from first hand experience what to look out for. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. Well, you probably wouldn't like the look or feel of an interface I would design for myself as a blind person. No danger of having to suffer through it anyway, as I am not a developer. I think I started this thread a couple days ago, and my point was, and is, that if WCAG 2.0 guidelines are followed, the UI can look however you guys want, but still meet the needs of blind and other disabled users -- including the deaf. I am not a developer -- but run a bunch of lists and have a little experience at web site accessibility testing and would be pleased to help out in that area in any way I can. Dave David Andrews: dandr...@visi.com Follow me on Twitter: http://www.twitter.com/dandrews920 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Sun, Jun 06, 2010 at 04:29:14PM -0400, Crist?bal Palmer wrote: The ability to use reCAPTCHA or other CAPTCHA systems as part of the web signup would also significantly reduce spammy signups, so if we could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. No, it won't. Spammers have quite thoroughly defeated these, years ago, via an assortment of techniques. Yes, some deployments don't see this: they're not considered important enough to attack. But as Yahoo most recently found (and they're only the most recent entry in a long parade) when spammers or other abusers decide it's time, they can rapidly solve them by the tens of thousands. Moreover, there's really no need for spammers to trouble themselves with this approach. If the goal is address-harvesting, then there are far more efficient ways that yield much better results. If the goal is to spam the list, then it's much easier to hijack an already-subscribed account -- particularly if it's located at one of the many freemail providers whose security is weak, but alternatively by via the subscriber's own system. There does not exist a truly effective defense against these attack vectors for lists of substantial size. (Very small lists can be defended by limiting membership, mail account location and operating system but these are clearly special cases and these tactics don't scale.) This isn't surprising, nor is it Mailman's fault: when the adversary owns so much infrastructure, it's just not going to be possible to craft defenses that work other than temporarily and accidentally. One mitigation step -- and it's not a terribly good one, but at least it's one with minimal impact -- is to employ the policy that list subscribers posting from freemail providers are always moderated. Of course this only intercepts one vector and of course it requires manual intervention -- which is why I *said* it's not terribly good. But experiments I've run indicate that at least for the moment, it deals with the most likely attack vector, and it has the virtue of using an existing mechanism. But, captchas? Pre-defeated. ---Rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Sun, Jun 06, 2010 at 11:44:07PM +0200, Patrick Ben Koetter wrote: * Geoff Shang ge...@quitelikely.com: Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. I know some people that use magnification. I can ask them to test also the new MM WUI or ask them for their needs regarding a new user interface. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? I also can help out on this point maybe, because I also have friends that are deaf or work for a big German organization for deaf people. @p...@trick: Maybe I can also arrange a meeting with these people, they also live in Munich. Regards, Schoepp -- Christian Schoepplein chris at schoeppi.net signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Christian Schoepplein ch...@schoeppi.net: * Geoff Shang ge...@quitelikely.com: Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. I know some people that use magnification. I can ask them to test also the new MM WUI or ask them for their needs regarding a new user interface. Great. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? I also can help out on this point maybe, because I also have friends that are deaf or work for a big German organization for deaf people. Even better. @p...@trick: Maybe I can also arrange a meeting with these people, they also live in Munich. That would be perfect. Should we all meet before we start working on the new WUI so we can take the input into consideration right from the start? p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Mon, Jun 07, 2010 at 09:16:58AM +0200, Patrick Ben Koetter wrote: * Christian Schoepplein ch...@schoeppi.net: * Geoff Shang ge...@quitelikely.com: Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. I know some people that use magnification. I can ask them to test also the new MM WUI or ask them for their needs regarding a new user interface. Great. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? I also can help out on this point maybe, because I also have friends that are deaf or work for a big German organization for deaf people. Even better. @p...@trick: Maybe I can also arrange a meeting with these people, they also live in Munich. That would be perfect. Should we all meet before we start working on the new WUI so we can take the input into consideration right from the start? IMHO it is easier to talk / discuss about real things than about things that should be done theoreticaly :). So I'd suggest to meet if a early draft of the new WUI is available. Regards, Schoepp -- Christian Schoepplein chris at schoeppi.net signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Mon, Jun 7, 2010 at 12:00 PM, mailman-developers-requ...@python.orgwrote: ... That would be perfect. Should we all meet before we start working on the new WUI so we can take the input into consideration right from the start? IMHO it is easier to talk / discuss about real things than about things that should be done theoreticaly :). So I'd suggest to meet if a early draft of the new WUI is available. Please keep the rest of us, or at least myself and Florian, posted about your discussions when meeting IRL. I believe you Patrick work together with Florian so I guess that should be easy enough. :) In German or English doesn't really matter unless you want to post it to this list... Thanks, Anna ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 06, 2010, at 04:29 PM, Cristóbal Palmer wrote: On Fri, Jun 04, 2010 at 09:58:12AM -0700, Mark Sapiro wrote: As Barry suggests, setting moderation of new members as the default can also thwart the subscribing spammers. The ability to use reCAPTCHA or other CAPTCHA systems as part of the web signup would also significantly reduce spammy signups, so if we could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. I personally hate captcha systems because I think they all have horrible usability issues. But I understand the appeal so I think I would vote against enabling such things by default, but would support allowing it to be added fairly easily. Is there a good place in the wiki for me to stick this suggestion, or will somebody who knows where it should go do that? Probably start here: http://wiki.list.org/display/DEV/Web+Interface but I think with the ramp up of work on the wui, these pages could use some gardening and reorganization. Any volunteers? -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 05, 2010, at 07:52 PM, Geoff Shang wrote: I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. That's great Geoff, we appreciate all your help in understanding the issues and driving toward a ui that's at least as usable as the MM 2.1 interface is. I have a general question though: given that Mailman 3 will be scriptable, is that a better long term solution than screen scraping? We still need to work out the security model for public access (i.e. OAuth, a proxy to the internal admin interface, etc), but I think it'll be very cool to write the scripts you want and actually interact with Mailman without using a wui. 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. +1. We want links/lynx users to be able to use the site. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. Indeed. :) You know that song by the Bare Naked Ladies? Well, if *I* had a million dollars, I'd write a killer new open source mail archiver. :) 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. Definitely. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Looking forward to it! -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 06, 2010, at 09:50 PM, Patrick Ben Koetter wrote: For this summer (of code) Anna has joined the team and I believe if Barry manages to do more work on the REST server and IMAP backend - *HINT* *HINT* - we will soon be able to present an early version of MM3 to test and play with while we bring it to a stable state. Hint taken. :) -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
I could look into reorganizing the pages since I'll be working with the UI anyways but I'm not sure how to gard them (might be that I don't have the rights to do so though)? Anyone else willing to help out is of course welcome to do so. Anna On Mon, Jun 7, 2010 at 8:41 PM, Barry Warsaw ba...@list.org wrote: ... Probably start here: http://wiki.list.org/display/DEV/Web+Interface but I think with the ramp up of work on the wui, these pages could use some gardening and reorganization. Any volunteers? -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/anna.granudd%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 07, 2010, at 09:16 AM, Patrick Ben Koetter wrote: That would be perfect. Should we all meet before we start working on the new WUI so we can take the input into consideration right from the start? Although I wouldn't be able to make that in person, please do use the bug tracker to request any new features of the REST interface. You can always tag them with 'mailman3' to get my attention. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Hi p...@trick, On Sat, Jun 05, 2010 at 11:59:31PM +0200, Patrick Ben Koetter wrote: Geoff, I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. That sounds very good. I also got in contact with Anna and asked about the accessibility in the new WUI, that should be an important point IMHO and should be not forgotten. Very nice that other people, who are more involved in the development of mailman, are keeping this point in mind too :). As allready said to Anna, just let me / us know, if there is anything to test. I'd be happy to support the development of the new WUI as good as possible regarding the accessibility for blind or visual impared users. Regards from Munic, Schoepp -- Christian Schoepplein chris at schoeppi.net signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Sat, 5 Jun 2010, Patrick Ben Koetter wrote: I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. Glad to hear it. I've been using Mm successfully in varius capacities for 10 years, so I have some experience of using it. I've only recently taken on site admin tasks with it, which is when I decided to jump on the mailing lists. This said: I believe the current interface is too complicated even for those who don't need to meet any perceptional or motional challenges: Oh I can see the issues. I think its served us nurdy types reasonably well for some time, but as you say, it's not very logical in the way it does things. I was mainly wanting to highlight my accessibility concerns, particularly since I couldn't see the mock-ups, but I agree with all your points. But JavaScript et al. must not be a basic requirement. We want progressive enhancement http://en.wikipedia.org/wiki/Progressive_Enhancement and, to answer one of your questions in your message, our goal is to ship a default user interface that provides the needed accessibility. I'm glad to hear it, and I'm sure others will be also. You mentioned some other feature requests based on 2.1.x functionality. I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. Most of my other feature requests are functionality-related, rather than UI as such. Some may already be in the wishlist(s) on the Wiki (or wherever I saw it). I'm happy to post them here in a separate thread if people think it's relevant. They're just things I've jotted down when using Mm that I've thought should be changed/fixed. As for UI development, I'm fairly rusty at Python and I've never actually used Django (though I like the look of it), but I'd be happy to get my hands dirty if it's a matter of tweeking what someone else has started. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Geoff Shang ge...@quitelikely.com: I was mainly wanting to highlight my accessibility concerns, particularly since I couldn't see the mock-ups, but I agree with all your points. Great. I can see and I need to use my imagination to figure what a _real good_ interface for visually imapaired people looks like. Better to have people who really know from first hand experience what to look out for. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. You mentioned some other feature requests based on 2.1.x functionality. I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. Most of my other feature requests are functionality-related, rather than UI as such. Some may already be in the wishlist(s) on the Wiki (or wherever I saw it). I'm happy to post them here in a separate thread if people think it's relevant. They're just things I've jotted down when using Mm that I've thought should be changed/fixed. Please post your feature requests even if we find out they are duplicates. As for UI development, I'm fairly rusty at Python and I've never actually used Django (though I like the look of it), but I'd be happy to get my hands dirty if it's a matter of tweeking what someone else has started. You are more than welcome to help. As far as I know MM3 development has taken place mostly in sprints at Pycons in 2009 and 2010 (I don't recall everybodys name right now) and after these events almost solely by Barry and Florian. For this summer (of code) Anna has joined the team and I believe if Barry manages to do more work on the REST server and IMAP backend - *HINT* *HINT* - we will soon be able to present an early version of MM3 to test and play with while we bring it to a stable state. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Christian Schoepplein ch...@schoeppi.net: I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. That sounds very good. I also got in contact with Anna and asked about the accessibility in the new WUI, that should be an important point IMHO and should be not forgotten. Very nice that other people, who are more involved in the development of mailman, are keeping this point in mind too :). As allready said to Anna, just let me / us know, if there is anything to test. I'd be happy to support the development of the new WUI as good as possible regarding the accessibility for blind or visual impared users. Great. I live near Munich. Maybe we can meet and you can give me some first some Sendmail bashing... ;) p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Fri, Jun 04, 2010 at 09:58:12AM -0700, Mark Sapiro wrote: As Barry suggests, setting moderation of new members as the default can also thwart the subscribing spammers. The ability to use reCAPTCHA or other CAPTCHA systems as part of the web signup would also significantly reduce spammy signups, so if we could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. Is there a good place in the wiki for me to stick this suggestion, or will somebody who knows where it should go do that? Cheers, -- Cristóbal Palmer ibiblio.org metalab.unc.edu ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Patrick Ben Koetter p...@state-of-mind.de: * Christian Schoepplein ch...@schoeppi.net: I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. That sounds very good. I also got in contact with Anna and asked about the accessibility in the new WUI, that should be an important point IMHO and should be not forgotten. Very nice that other people, who are more involved in the development of mailman, are keeping this point in mind too :). As allready said to Anna, just let me / us know, if there is anything to test. I'd be happy to support the development of the new WUI as good as possible regarding the accessibility for blind or visual impared users. Great. I live near Munich. Maybe we can meet and you can give me some first some Sendmail bashing... ;) That's what you get when you delete the wrong lines... :-D I wanted to say: Great. I live near Munich. Maybe we can meet and you can give me some first hand experience using MM3 as a blind person. And I was going to say something about the two of us using Postfix and we could do some Sendmail bashing... ;) p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Sun, 6 Jun 2010, Cristóbal Palmer wrote: The ability to use reCAPTCHA or other CAPTCHA systems as part of the web signup would also significantly reduce spammy signups, so if we could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. I would think that having some way of plugging this in would be better than hard-coding it, as new solutions come along all the time. Recaptcha is good as far as traditional captchas go, but while we're voting, I'll vote for Text Captcha (www.textcaptcha.com) for obvious reasons. Though one available in multiple languages would be a good idea of course. And it goes without saying that this only would make a difference for web-based subscription, it wouldn't make any difference for Email subscription requests unless you wanted to plug something like Text Captcha into the confirmation process, which would be rather novel at least. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Sun, 6 Jun 2010, Patrick Ben Koetter wrote: Great. I can see and I need to use my imagination to figure what a _real good_ interface for visually imapaired people looks like. Better to have people who really know from first hand experience what to look out for. Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. Huh? This makes no sense to me. People who only have hearing impairments shouldn't have any more problems with comprehention or reading than people with only vision impairments. By all means make allowances for people with reading/learning/cognitive disabilities, but please don't atribute the need for this to something unrelated. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Most of my other feature requests are functionality-related, rather than UI as such. Some may already be in the wishlist(s) on the Wiki (or wherever I saw it). I'm happy to post them here in a separate thread if people think it's relevant. They're just things I've jotted down when using Mm that I've thought should be changed/fixed. Please post your feature requests even if we find out they are duplicates. Ok, will do. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Geoff Shang ge...@quitelikely.com: Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. Huh? This makes no sense to me. People who only have hearing impairments shouldn't have any more problems with comprehention or It didn't make sense to me either until I listened to a Chaos Computer Club (CCC) Podcast about accessibility with the two guys who started/participated in the Web Standards Project http://www.webstandards.org/. Too bad the Podcasts are German only. I recommend them to anybody interested in technics, society and culture. Anyway, their story went like this: If you are deaf you learn sign language to communicate with others. Sign language is the first (mother) language for deaf people. Any other (written) language is foreign and that introduces all the problems people usually have with foreign languages. reading than people with only vision impairments. By all means make allowances for people with reading/learning/cognitive disabilities, but please don't atribute the need for this to something unrelated. Do I seem overeager? Don't worry I am not a do-gooder trying to create an interface that attempts to work for _everybody_ on this planet. I simply want to create an interface that accounts for accessibility and that includes deaf people too. If the relation deaf - reading problems stands then I'd like to find a way that works for deaf people too. Maybe (!) that's not a problem at all with an application interface as we are going to create, but only with websites that contain lots of text. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Barry Warsaw writes: We'll probably end up using Launchpad since our branches and bug trackers are there, but Transifex does look nice. File an RFE on Launchpad! Then go twist some arms at the next Ubuntu summit, or better yet, lull them into submission with slow sexy bass line. Maybe you can get Slowhand as the front man! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Patrick Ben Koetter writes: Geoff, I am really happy to find out you, as a blind person, Yeah, a big +1 on that. Good to hear that we can get first person feedback. Interesting to hear that Mailman 2 has a reasonably usable interface, as AFAIK that wasn't a design consideration. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Fri, 4 Jun 2010, Anna Granudd wrote: there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! As a blind person, I'm not able to comment on these as these are images. I can understand the desire for an overhall of the Mailman UI, but I think it's worth saying that for the most part, the 2.x UI works well for people using screen reader technology. The only area which provides some challenges is the membership management screen, as it can be difficult to associate each checkbox with the function it performs. But even this can be managed using screen reader commands for reading tables. I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. Right now, my UI wishlist is as follows: 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
At 07:29 AM 6/3/2010, Anna Granudd wrote: Hi, my name is Anna and I'm participating in GSoC for Systers where my project this summer is to develop a new UI for Mailman 3.0 as well as a UI extension for Systers who are running a customized version of Mailman. The UI will be written as an app in Django. Together with my mentor Florian we've discussed some general matters regarding the UI and the most recent concern adding a database for it. We figured it might be good to use the core db only for the standard UI with which we'll communicate through the rest-client and for organizations wishing to customize the UI, such as Systers, we'll let them add a UI db. Other things we've discussed was the number of apps for the UI, if we should use only one or if we should separate it into, for instance, one app for the user UI's and one for the admin UI, or possibly split it up even more. We've gathered all our thoughts on http://wiki.list.org/display/DEV/Web+Interface+Status and now we'd like to get some feedback from you people as well as to find out if you have other opinions or ideas for us. I/we would really appreciate your help on this. I hope that you plan on following WCAG 2.0 standards! There are plenty of moderators and Admins who are blind or have other disabilities and still want to keep using the software! Dave ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Geoff, I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. This said: I believe the current interface is too complicated even for those who don't need to meet any perceptional or motional challenges: - It doesn't enforce reasonable grouping of related functions - It exposes an immense number of configuration options to the user but doesn't seem to prioritize how often they are required - It has a high signal noise ratio i.e. it's crowed with text (help messages) which makes it hard to focus on the configuration options themselves. - HTML is not used in a semantic way. You already mentioned there's no association between option names and their fields aka 'labels'. If I remember correctly structure i.e. headings and reasonable use of list are also missing. The list is totally uncomplete, but I guess you get the idea. This and more should go and be replaced by better solutions AND the interface should be modern, nice to look at and provide a set of comfortable JavaScript functions. But JavaScript et al. must not be a basic requirement. We want progressive enhancement http://en.wikipedia.org/wiki/Progressive_Enhancement and, to answer one of your questions in your message, our goal is to ship a default user interface that provides the needed accessibility. You mentioned some other feature requests based on 2.1.x functionality. I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. p...@rick * Geoff Shang ge...@quitelikely.com: On Fri, 4 Jun 2010, Anna Granudd wrote: there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! As a blind person, I'm not able to comment on these as these are images. I can understand the desire for an overhall of the Mailman UI, but I think it's worth saying that for the most part, the 2.x UI works well for people using screen reader technology. The only area which provides some challenges is the membership management screen, as it can be difficult to associate each checkbox with the function it performs. But even this can be managed using screen reader commands for reading tables. I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. Right now, my UI wishlist is as follows: 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht
Re: [Mailman-Developers] UI for Mailman 3.0 update
Hi, there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! Thanks, Anna On Fri, Jun 4, 2010 at 9:05 AM, Martin Albisetti argent...@gmail.comwrote: Hi Anna! It's great to see this happening. Do you have a clear idea and/or wireframes for the layouts of the pages? If not, I'd be happy to help mock-up a default skin that looks nice and easy to use. -- Martin ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Jun 04, 2010, at 10:01 AM, Mark Sapiro wrote: Adam McGreggor wrote: On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote: Is it? Aren't most open source discussion lists generally open membership (perhaps with initial moderation)? I'm not quite sure I go as far as Ian, in requiring approval, but certainly to require confirmation, and I might suggest, moderation bit being set, too. I think that's exactly what Barry was saying. open membership does not imply subscription without confirmation. It only means subscription without approval. Correct. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
hey, On Thu, Jun 03, 2010 at 02:29:40PM +0200, Anna Granudd wrote: my name is Anna and I'm participating in GSoC for Systers where my project this summer is to develop a new UI for Mailman 3.0 as well as a UI extension for Systers who are running a customized version of Mailman. I think I may be missing something: Systers. Is this something specific? The UI will be written as an app in Django. Together with my mentor Florian we've discussed some general matters regarding the UI and the most recent concern adding a database for it. We figured it might be good to use the core db only for the standard UI with which we'll communicate through the rest-client and for organizations wishing to customize the UI, such as Systers, we'll let them add a UI db. Do translations/i18n aspects come under UI customizations? Other things we've discussed was the number of apps for the UI, if we should use only one or if we should separate it into, for instance, one app for the user UI's and one for the admin UI, or possibly split it up even more. We've gathered all our thoughts on http://wiki.list.org/display/DEV/Web+Interface+Status and now we'd like to get some feedback from you people as well as to find out if you have other opinions or ideas for us. I/we would really appreciate your help on this. In Features to be implemented first 1. Ability for users to subscribe, manage subscriptions, unsubscribe, change emails 2. Admin ability to create/delete lists via pre-defined styles 3. Users ability to customize their subscirptions s/subscirptions/subscriptions/ 4. Moderation 5. Site admin ability to create domains, add and modify styles 6. List admin ability to customize lists I think admins being able to set-up/customize lists, is probably equally important, if not more important, then being able to (un)sub; if the lists can't easily be set-up, then what's the point in having people subscribe to them? a -- ``Freedom of the press in Britain means freedom to print such of the proprietor's prejudices as the advertisers don't object to.'' (Hannen Swaffer) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Django's handling of i18n/l10n is well done. You could also use something like Transifex to encourage contributions in various langs. http://docs.djangoproject.com/en/1.2/topics/i18n/#topics-i18n http://www.transifex.net/ Richard Leland r...@richleland.com 240-242-7424 On Thu, Jun 3, 2010 at 2:20 PM, Barry Warsaw ba...@list.org wrote: On Jun 03, 2010, at 04:56 PM, Adam McGreggor wrote: I think I may be missing something: Systers. Is this something specific? www.systers.org The UI will be written as an app in Django. Together with my mentor Florian we've discussed some general matters regarding the UI and the most recent concern adding a database for it. We figured it might be good to use the core db only for the standard UI with which we'll communicate through the rest-client and for organizations wishing to customize the UI, such as Systers, we'll let them add a UI db. Do translations/i18n aspects come under UI customizations? We do eventually need to make sure all of the web ui can be translated. Ideally, we'd be able to extract text strings into .pot files and then set up a catalog for the wui. I don't know how Django does it, but it should be part of the story. 1. Ability for users to subscribe, manage subscriptions, unsubscribe, change emails 2. Admin ability to create/delete lists via pre-defined styles Note that in my current thinking, it is the site admin who can create styles. I don't know if individual list admins should be able to do that, though they should definitely be able to pick a style and do some customizations of their list. The ability of site admins to lock down styles, control customizations, and delegate style definitions can come later. 3. Users ability to customize their subscirptions s/subscirptions/subscriptions/ 4. Moderation 5. Site admin ability to create domains, add and modify styles 6. List admin ability to customize lists I think admins being able to set-up/customize lists, is probably equally important, if not more important, then being able to (un)sub; if the lists can't easily be set-up, then what's the point in having people subscribe to them? Lists can currently be easily created on the command line, and subbing/unsubbing is a much more common task, so I think there is an argument for users being able to easily join/leave existing lists before it's easy to create lists through the web. But I don't have strong feelings either way. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rich%40richleland.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
