[Mailman-Developers] Fwd: Re: Hi! I'll be your intern for the summer :)
>Date: Wed, 21 Jun 2006 21:50:57 -0500 >To: emf <[EMAIL PROTECTED]> >From: David Andrews <[EMAIL PROTECTED]> >Subject: Re: [Mailman-Developers] Hi! I'll be your intern for the summer :) > >>Ethan Freeman Said: >>Thanks for all the references. If you know of a way that I can actually >>test JAWS or another screen reader, I would be grateful for the pointer. >> >>~ethan fremen > >Hi: > >I am a blind guy who runs a bunch of lists who is hanging out here, just for >this. I will be happy to help you test your pages. Also, you can download >demo versions of JAWS http://www.freedomscientific.com and Window-Eyes >http://www.gwmicro.com > >However, unless you are an experienced user, there can be dangers in sighted >guys doing this kind oftesting. I spent half an hour on the phone one day >trying to explain to a developer how you entered data into a web form, and why >it was different than from him and his mouse. Some of the cues are pretty >subtle, and unless you are used to them you might not realize they aren't >there if things are kind of sort of working. > >Dave ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
--On 21 June 2006 13:37:36 -0400 emf <[EMAIL PROTECTED]> wrote: > Ian Eiloart wrote: > >> How about this for extra: >> >> 1) Display a list of ALL members - just their names and addresses. >> 2) Delete ALL the list members with one click - OK, and maybe a confirm >> dialog! > > Hm. This comes slightly in opposition to the desire to have a more > user-centered mailman interface; what happens if a user changes their > preferences and you re-build the entire list? Well, for some of our lists it's simply inappropriate for users to set preferences. Let me give you an instance. We're a University. People make enquiries about studying here. We have to send an email to all of those people because -say- there's been a change in the registration process. > An associated problem is what happens to users that are subbed to >1 list? > > I recognize this may not be an issue in your specific case, I just think > that issues like these will be more of a deal when we don't keep > "members" in per-list silos. > > Perhaps something that might be more appropriate would be a "member > differ", wherein you upload a list of email addresses, and it shows you > the list of emails that were on the list but aren't now, and those that > would be added, and gives you the option to either accept all the > changes or selectively modify them. > > When you say you'd like these people to be able to take advantage of > "other mailman features", which features do you mean? Well, our MTA won't accept more than 250 recipients per email, so when people need to email several thousand recipients, they have to split their recipient lists into blocks. It would be much better to simply paste them into a Mailman web UI, and let Mailman handle the details. Why 250? Well, actually that's because our LDAP server barfs if you make more than about 300 queries on one connection. Those queries might be validating local email addresses. So, I could implement this another way, but Mailman also offers me authentication and authorisation, and allows me to ensure proper footers on the emails, and probably some other useful stuff too. > ~ethan fremen > > ___ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a > c.uk > > Security Policy: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp -- Ian Eiloart IT Services, University of Sussex ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
--On 21 June 2006 23:45:49 +0100 Matthew Newton <[EMAIL PROTECTED]> wrote: > On Wed, Jun 21, 2006 at 01:37:36PM -0400, emf wrote: >> > How about this for extra: >> > >> > 1) Display a list of ALL members - just their names and addresses. >> > 2) Delete ALL the list members with one click - OK, and maybe a >> > confirm dialog! > >> Perhaps something that might be more appropriate would be a "member >> differ", wherein you upload a list of email addresses, and it shows you >> the list of emails that were on the list but aren't now, and those that >> would be added, and gives you the option to either accept all the >> changes or selectively modify them. > > This sounds like the command-line "sync_members" program. I've > been meaning to add a web interface to that for a while, but > haven't managed to get around to it. Yes, that's exactly it. In fact, I use sync_members to sync some student and staff lists with our personnel database. However, there are some lists that need to be synced occasionally with - for example - excel spreadsheets that belong to people without access to our servers. > I guess it depends on what you use Mailman for. In then general > internet-user-subscribes-themselves-mailing-list it's great. For a > University with central management of some lists, it isn't quite > what is needed all the time. > > One thing that happens each year here for some lists is that all > list members of "course-year2" get moved to "course-year3", > "course-year1" to "course-year2", and new members added to > "course-year1". I can do this easily from the command line with a > "list_members | sync_members", but I'd really prefer the owners to > be able to do it themselves. Another way of managing that is to name the lists after the year that the student enrolled. For example course-2004, course-2005. That way you only need to handle the occasional student who suspends studies for a year, or something. If you like, you can create aliases (in your MTA config) like course-year1 for the list names and just move the pointers at the relevant time. > Which reminds me, another thing I've been wanting to add is > "download members as text file" (basically the same as 1 above), > which would go together with the sync_members option. > > Matthew -- Ian Eiloart IT Services, University of Sussex ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
[Mailman-Developers] Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)
--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > Thanks very much for your feedback, Laura! I am something of a > standards fanatic; all the pages I've re-written so far have made > heavy use of label (although I use the implicit label where > possible), fieldset, legend, thead & tbody and the title attribute > to provide as much support for assistive technologies and > alternative renderings as I can. Wonderful news to hear that you support accessibility and web standards, Ethan. Yes, fieldset, legend, thead, tbody and the title attributes are very important for structural markup. > Once I have a clear idea what form elements will be where, I am also > going to add tabindex and accesskey attributes to the form elements. I would like to mention a few things regarding implicit labels, accesskeys, and tabindex. LABELS The W3C identifies two different types of labels: implicit and explicit [1]. Basically, the difference is that implicit labels are an older, (deprecated in WCAG 2.0) technique that wrap around their target field elements; explicit labels use the for attribute to indicate which form element they describe (that value of the for attribute is the id of the element it describes. I would caution against using implicit labels. Explicit association is preferable. WCAG 1.0 12.4 advises web developers to "Associate labels explicitly with their controls."[2] It also says in section 508: "Experience has shown that implicit labeling should be avoided for two reasons. First, implicit labeling is not reliably supported by many screen readers and, in particular, does not work well if explicit labels are simultaneously used anywhere on the same web page. Often, the output can be wildly inaccurate and confusing. Second, if any text separates a label from its associated form element, an implicit label becomes impractical and confusing because the label itself is no longer easily identified with the form element.[3]" For an illustration of this visit Roger Hudson's Web Essential 05 Association Examples [4]. If you use explicit labels, you're specifically providing information about each form element. Each form control should have its own LABEL. Add the FOR attribute to tie the LABEL to the form control's ID attribute. ACCESSKEYS Something to be aware of is that the current opinion of many accessibility experts is that accesskeys mostly work against accessibility. Because of the many conflicts, defining accesskeys seems to be a waste of time unless you are designing for a controlled environment such as an intranet. Joe Clark suggests that there are at least 36 characters that can be used for accesskey attributes [5]. However, John Foliot's and Derek Featherstone's [6] [7] unofficial survey/research concluded that there really are no useful access keys not already reserved by some application or other. When you take internationalization issues into account, it becomes pretty much of a hopeless cause. Part of this is that browsers by default don't indicate the accesskey assignments or tabbing order. No one argues with the idea behind accesskey, and it's usefulness. But given the current state of affairs, and the potential for confusion and/or conflict with various adaptive technologies, they have issues. So... Based on the existing issues I usually advise developers to not use accesskeys. However, best practice is that IF accesskeys are used: - Always supply a legend that defines the accesskeys. - Make sure this legend is on or available from every page on the site...perhaps in an accessibility statement. - Supply title attributes on any accesskeys used. - Keep the number of accesskeys to a minimum. - Test to make sure that accesskeys help usability more than they hinder accessibility. TABINDEX If you have a logical page design tabindex isn't usually necessary. By default, with no tabindex attributes present, the browser will tab through elements in the order in which they appear in the source code. Using just one tabindex for the first field like you did for the exercise isn't bad, but just having a sensible natural order to start with, meets WCAG requirements for HTML documents. If the tabindex attribute is not assigned to all fields, JAWS first moves through the items with a tabindex assigned, then moves through the other form fields and links in the order they appear on the page. You can usually lighten your HTML and usually forego tabindex. But if there is something very weird with link or form presentation so they don't function in a sensible order it can be helpful to have a tabindex. In any event I suggest it may be better to avoid having a weird ordering in HTML. If tabbing needed to come in anything but their natural order, I think I would probably regard my document structure as flawed and would rework it. When a form is well structure, and still reflects that structure when styles are turn off, the tab flow is often the sa
[Mailman-Developers] Acessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :))
--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > If you know of a way that I can > actually test JAWS or another screen reader, I would be grateful for > the pointer. David Andrews already mentioned the demo versions of JAWS and Window-Eyes [1]. Thank you Dave for offering to help test! Dave can provide valuable insights and expertise. Human Evaluation is very important [2]. Ethan please do download and try a screen reader. But like Dave said, it is best for inexperienced users not make design decisions based on their experiences with screen readers. ItÂ’s just too different from someone who uses the technology on a daily basis, because they have to. Home Page Reader [3] is also a good tool for web developers and designers who are looking to try out a speaking browser. It will give you somewhat of an idea of how the blind or visually impaired would experience your pages. It presents a web page in two different views. It places the graphics view, a true rendering of the Web page, in the upper portion of the program window. Then, it shows a text view of the Web page in a window below that graphics view. Again, you'll gain an appreciation for what a blind user would hear when listening to your Web page. There is a free 30 day free demo available. There is also a tutorial on Testing Web accessibility with Home Page Reader available [4] One of the tools that I have my students use is to test forms is the WAVE. [5] It will spot violations like missing labels, labels not associated with inputs, empty labels, etc. and notify you with icons. [6] Cynthia [7] is also one online tool that every web developer should be familiar with. In the hands of someone trained to do accessibility checks, it's really no better or worse than any of the other tools. Cynthia analyzes web pages and checks for a set of accessibility problems that can be checked for automatically. Although it is a very limited program, it is also a good program. It can help with the checking process. The rest needs to depend upon human judgement. There's a great little Colour Contrast Analyser Firefox Extension [8] by Gez Lemon I have found useful lately. It saves time and helps take the guesswork out of determining accessible color combinations. It can go through a page and check (give you pass or fail) on luminosity contrast ratios, difference in brightness, and difference in color. Many, many more helpful accessibility tools exist. To get an idea of the number visit the Tool Section of the Web Design Reference. [9] All the best, Laura [1] http://tinyurl.com/e9bno [2]http://webaim.org/articles/process/human.php [3] http://www-3.ibm.com/able/solution_offerings/hpr.html [4] http://www-3.ibm.com/able/guidelines/web/webhprtest.html [5] http://www.wave.webaim.org/wave/index.jsp [6] http://www.wave.webaim.org/wave/explanation.htm (Scroll down to the forms section) [7] http://www.contentquality.com/ [8] http://tinyurl.com/awlqm [9] http://www.d.umn.edu/goto/tools ___ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN 55812-3009 http://www.d.umn.edu/goto/webdesign/ ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Acessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :))
> --On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > > > If you know of a way that I can > > actually test JAWS or another screen reader, I would be grateful for > > the pointer. If you are a Firefox user, there is an extension called Fangs [1] that emulates the output from JAWS. It doesn't speak it, rather it dipslays in text what JAWS would speak. [1] http://www.standards-schmandards.com/fangs -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
[Mailman-Developers] a picture, and a problem with the Debian package
Hello, here's a nice picture. The answer is in the mail http://www.flickr.com/photos/[EMAIL PROTECTED]/172609494/ More seriously (or, maybe, less), I've spent a few minutes trying to figure out a problem a user was having (on irc). The problem was that she had configured the list to be in Spanish, but it kept sending welcome messages in English. I finally traced it to the Debian installation, which has weird symlinks: /var/lib/mailman/templates -> /etc/mailman ls -al /etc/mailman/ total 36 drwxr-xr-x 4 root list 4096 2006-04-22 19:46 . drwxr-xr-x 95 root root 8192 2006-06-21 10:41 .. drwxr-xr-x 2 root root 4096 2005-10-04 18:17 en drwxr-xr-x 2 root root 4096 2006-02-10 17:46 fr that's 2 languages only! whereas /usr/share/mailman/ contains all the templates (including es/, which she linked into /etc/mailman/ and solved the problem) For me, if this is confirmed and not a weird thing on my and her Debian installation, it's a problem that should be solved. -- Fil ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
[Mailman-Developers] multilingual templates in Debian mailman [was: a picture, and a problem with the Debian package]
(I'm the currently least inactive maintainer of the Debian package.) On Thu, Jun 22, 2006 at 10:40:49PM +0200, Fil wrote: > The problem was that she had > configured the list to be in Spanish, but it kept sending welcome messages > in English. > I finally traced it to the Debian installation, When installing the mailman package, you got asked which languages you want that site to support. You didn't include Spanish in the list. Use "dpkg-reconfigure mailman" to change the list. All languages supported by a list on the site are forced on, meaning if you turn them off, they are turned back on in your back. > which has weird symlinks: > /var/lib/mailman/templates -> /etc/mailman Templates can be changed by the administrator and are thus considered as configuration files and are thus in /etc/, as per Debian policy (and Linux FHS). This guarantees that a package upgrade won't override changes the administrator may have made. > whereas /usr/share/mailman/ contains all the templates (including es/, which > she linked into /etc/mailman/ and solved the problem) That linking may or may not confuse the maintainer scripts of the package, I'm not sure. If you want to play it safe, have your user remove that link and use "dpkg-reconfigure mailman". -- Lionel ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
