Re: [Mailman-Developers] The Philosophy of Web Use.

[Laura Carlson]

--On Thursday, August 3, 2006 7:14 PM -0400 emf <[EMAIL PROTECTED]> wrote:

> You're a goddess, laura. Thanks so much for the docking-boxes hookup.
>
> ~ethan

You're most welcome, Ethan.

It may have some potential to aid usability in some circumstances.

Just be careful to heed the warnings and restrictions on its use for 
application interfaces.

Laura
___
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 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] The Philosophy of Web Use.

[Laura Carlson]

On Jul 7, 2006, at 12:08 AM, Brad Knowles wrote:

>> I'm much more
>> bugged by the Flash-only sites that are an avoidable annoyance for
>> me, but I can imagine are a scream-out-loud frustration for screen
>> reader based users.

On  August 2, 2006, at 12:08 AM, David Andrews wrote:

> As a screen reader person I will say that Flash-only can be made to
> work, there is accessible flash, but it is rarely done.  If it isn't
> implemented, a site can be useless, however you can do a good job, my
> department did a whole web training thing in accessible flash, and it
> works fine for blind users -- which is good

Yes, it's possible to build accessible Flash [1]. In theory, a Flash 
site should be as accessible as an HTML site; if it provides all the 
accessibility features that HTML provides, such as alt attributes, 
keyboard access, synchronized captions for any audio that conveys 
content, allowing the content to scale to a larger sizes, valid code, 
links, separating presentation from content, etc. Some flash content 
even has the potential to aid people with learning or cognitive 
disabilities.

And yes, the more modern versions of screen readers can render it. 
However, those screen readers can be very expensive, and many users' 
financial situations preclude even upgrading. There are still a great 
many people using legacy screen readers out there.

In time most people who use screen readers will have software that 
plays nice with Flash. Until then, though, my advise continues to be to 
avoid Flash or, if it must be used, to make sure a user has a chance to 
opt out of it for an accessible page before the Flash begins.

Currently the only way to be 100% forward and backward compatible is to 
create an accessible HTML version of a Flash site. Or only use it for 
nonessential parts of a web site.

Also Flash makes it harder for a site to rank well on the search 
engines. As far as I know, there are no search engine bots/spiders 
which can read the contents of Flash. So if you are concerned with SEO 
you need to include alternative content (ie. text, html) for any Flash 
content.[2]

Best Regards,
Laura

[1] http://webaim.org/techniques/flash/
[2] http://www.alistapart.com/articles/flashmxmoving/
___
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 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] The Philosophy of Web Use.

[Laura Carlson]

> Ethan wrote:

>> Can you do me a favor and let me know how these examples work
>> for you?
>>
>> http://tool-man.org/examples/sorting.html

Laura wrote:

> Works great for able bodied mouse users.
>
> But how are people with mobility impairments like low dexterity
> (unable to use a pointing device like a mouse and instead must use
> keyboard or switch) able to use it? It doesn't seem to work via
> keyboard.

Hi Ethan,

You might want to check out James Edwards' (aka brothercake) latest 
version of Docking boxes (dbx). It is a more keyboard accessible than 
the tool-man example. James is making progress in this area.

To quote from the site [1]:

"Docking boxes (dbx) adds animated drag 'n' drop, snap-to-grid, and 
show/hide-contents functionality to any group of elements. And ... in 
what might be  another  world-first for brothercake - dbx is fully 
accessible to the keyboard  as well as the mouse..."

He says in the accessibility notes [2]:


Docking boxes can provide equal functionality to both mouse and 
keyboard users, so the accessibility limitations usually associated 
with drag 'n' drop controls don't apply. However the dynamic interface 
is not supported in browser-based screenreaders, such as JAWS or Home 
Page Reader.

Many javascript events occur in browser-based readers exactly as they 
would for vanilla installs of the host browser (usually Internet 
Explorer). But having content which is switchable to non-displayed 
could be a major cause of confusion, in the absence of a reliable way 
to notify a non-graphical UA of the change explicitly.

To try to avoid these problems, the script uses event-disparity 
evaluations or repositiong routines at all;  for these users the layout 
should remain static, and accessible as though there were no dynamic 
behaviors, just as it is for legacy or text-only browsers.

This then means that CSS properties used to hide the inner content area 
- things like display:none which would normally be a total no-go - 
should not be a problem here, since readers should never activate nor 
cause to be activated the mechanisms  which apply those rules.

So, in these and other environments where the script is not supported, 
you'll get a default HTML  and CSS layout  with no dynamic behaviors. 
This isn't necessarily an issue for things like navigation or news 
boxes, where the scripting is supplementary to the core functionality. 
But its use as an application interface should be restricted to 
situations where browser and scripting support is predictable, or where 
equivalent server-side functionality is also provided.


That last sentence is key. Restrict use of this technique to situations 
where:

1. Browser and scripting support is known (it's not for most Mailman 
admins) or
2. Provide equivalent server-side functionality

Best Regards,
Laura

[1] http://www.brothercake.com/site/resources/scripts/dbx/
[2] http://www.brothercake.com/site/resources/scripts/dbx/setup4/
___
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 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] The Philosophy of Web Use.

[David Andrews]

>On Jul 7, 2006, at 12:08 AM, Brad Knowles wrote:
>
>
>OTOH, I've used Linux and OSX, and before that NeXT, Solaris and
>various Unixes for (unfortunately, way :) longer than there's been a
>web, and except for the Windows programming I do at work, haven't
>ever used IE for any substantial amount of time.  I'm not excusing
>poor sites or Windows-specific sites, but for the most part, these
>days most sites are at least usable with Firefox on various
>platforms.  (The one sole recent exception was the SQLAlchemy doc
>pages which gave Firefox fits but rendered just fine in Safari -- and
>I'm sure those guys didn't tailor their pages for IE.).  Yeah, you
>hit the occasional WMV or ActiveX laden site, but I'm much more
>bugged by the Flash-only sites that are an avoidable annoyance for
>me, but I can imagine are a scream-out-loud frustration for screen
>reader based users.


As a screen reader person I will say that Flash-only can be made to 
work, there is accessible flash, but it is rarely done.  If it isn't 
implemented, a site can be useless, however you can do a good job, my 
department did a whole web training thing in accessible flash, and it 
works fine for blind users -- which is good since

> > Now, I know that you're not that kind of person, and you will actively
> > test your work with MacOS X/Safari, and as many other browser/OS
> > platforms
> > you can.  But the more complexity that is built into the user
> > interface,
> > the higher the likelihood is that something will accidentally happen
> > somewhere to seriously break something for someone else.
>
>Actually, I think skilled and judicious use of modern web technology
>can help to /reduce/ the complexity of Mailman's interface.
>Something I constantly struggle with is the plethora of configuration
>variables (both via the web u/i and in mm_cfg.py) that makes the
>system highly complicated.  I would love to have a self-discoverable
>interface, or an interface that can be used to selectively reveal
>just the parts you're interested.
>
>- -Barry
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.3 (Darwin)
>
>iQCVAwUBRK3kGXEjvBPtnXfVAQJfrQQAoYkRLIATvJrLsM2kx88DF4UZHbeoXXZI
>CrIhzM2URy+IIcRMQCBn8jfqnyIeTvVUcemHiCjpDyhyVEuYlYXtvjT9d5W9DrjR
>OW3rlDViFfuEA6NSU+/QS8YDhokpf2tLpbdKiKLdqgiAdMGR8+jhHFEsmbsha79d
>xX7xKMzNmOY=
>=/Mp9
>-END PGP SIGNATURE-
>___
>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/dandrews%40visi.com
>
>Security Policy: 
>http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

David Andrews and white cane Harry.


___
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] The Philosophy of Web Use.

[Brad Knowles]

Ethan wrote:

>> | Dollar for dollar, network-based computers are faster.
>
> This is incorrect, based on my experience of working in a few data
> centers.
>
> While it is possible to buy expensive hardware today that has more
> performance than the average consumer machine, hardware is getting
> better faster than purchasing decisions.

That's new hardware.  There's tons of old hardware out there that people
refuse to upgrade or replace.  Why do you think that Microsoft has had
such problems EOL'ing Windows 95?

> Because the consumer market is both larger and growing faster than the
> server market, and the machines less reliable, the average server is
> older than the average client machine, and thus have less resources than
> the average client.

That's not my experience at all, and I've been a professional systems
administrator for over sixteen years.  Businesses tend to rapidly
depreciate and replace hardware, much, much faster than individuals do at
home -- by an order of magnitude or more, in some cases.  This is why
companies like Dell focus almost exclusively on the business market.

> Even if you disagree with this point, there's one server for many
> clients; the amount of resources available to devote to the task of an
> individual user's web experience is almost always greater on their end
> of the pipe.

True, the number and power of clients can always overwhelm the number and
power of servers.  The [EMAIL PROTECTED] project certainly taught us that.  And 
we
knew that lesson at AOL before [EMAIL PROTECTED] came alone, because there were 
a
number of incidences when a surprisingly small number of attackers could
do serious damage to the service.

But just because the number and power of clients can overwhelm the number
and power of servers doesn't mean that they necessarily will always do so.
 If that were the case, then we'd all be permanently out of work.


Moreover, although you might be right in general, you cannot assume that
each specific user will always be in that same sort of situation.  That
would be like claiming that everyone is above average.

> What it boils down to is that people perceive change at around 150msec;
> very few net users get anywhere near this latency, and so for most, the
> round-trip delay represents a substantial impediment to the
> responsiveness of the interface.

Right, and if they're running on an ancient Pentium computer with Windows
95 and their interface is dead-dog slow because you force-fed it too much
stuff to process, they're not going to have a particularly good
experience.


The lesson that Yahoo! and Google teach is to keep everything as simple
and light as humanly possible.  They learned this from Colin Chapman and
the guys at Lotus, whose motto was "Simplify and add lightness".

That's all I'm looking for.  Give me the Lotus Exige of interfaces.

-- 
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See .
___
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] The Philosophy of Web Use.

[Brad Knowles]

Ethan wrote:

> Can you do me a favor and let me know how these examples work for you?
>
> http://tool-man.org/examples/sorting.html

It seemed to work as the author expected, using Safari 2.x under MacOS X
10.4.x.  Using Blazer on my Palm Treo 650, although I enabled everything
(especially including JavaScript), the supposedly draggable items were
instead rendered as plain text.


This is the key problem with something like JavaScript.  It advertises
that it works, your web application can see that JavaScript is enabled,
you test it with your preferred browser(s) and everything seems okay, and
you release the code.

Only problem is, when it's put out there in the real world you discover
that it has "interesting" failure modes with other browsers that you
didn't test with.

-- 
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See .
___
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] The Philosophy of Web Use.

[Brad Knowles]

Ethan wrote:

> Have you used http://wiki.list.org/ ? Is it "flat out broken" or "slow
> and distracting"? I find it has a few bugs, but mostly it works well.

I have tried to use Confluence, yes.  Not all that successfully, however. 
It seems to be an improvement over TWiki, but that's not saying much.

> Here's a specific example that works well for me: Does the drag/drop of
> boxes on the customized google home page not work for you? You don't
> have to sign in to try it, and it allows drag/drop reordering for me in
> Safari just fine, and way more intuitively than resubmitting the page
> after clicking on buttons.

I had never tried that particular feature of Google, but I'm not
particularly impressed by it.


And if the choice is to send a whole bunch of stuff to the other end and
then hide most of it or to simply not send it at all, I vote for not
sending it.

If you read the Slashdot article that I referenced in another message, I
believe you'll find that it's the Google people who are saying that the
bottleneck in most cases is not the network, but is actually the amazingly
low-end Pentium machines that people have at home, and that we (they) have
to work hard to avoid overtaxing those systems.

> So you have no constructive feedback, nor a sufficiently detailed
> critique that I can even address your concerns. I'm not sure what you
> would have me do with your advice, beyond my already existing commitment
> to make the page work without JavaScript.

It's not just making sure that the page will work without JavaScript. 
It's also making sure that the JavaScript which is added is relatively
simple and unlikely to break when viewed/used in unexpected or unknown
browsers, and will be likely to continue to work in all future browsers
and browser versions.

It's also not pushing things too far, because I might end up browsing a
Mailman admin site with my Treo 650 with JavaScript turned on, across a
slow spotty GPRS connection, and I still need this 320x320 screen to be
useful when trying to do some emergency list maintenance away from home.

> * IE 5+, Mozilla (any), Safari from 1.0+ and any other KHTML browsers,
> JAWS 6+, Opera 6+, Lynx, Links. All in any combination of
> Images/CSS/JavaScript off/on.

You've got PCs on the brain.  Or maybe not PCs, but certainly desktop
computers.  Don't forget about Opera Mini, Brew, the web browser on Palm
from Access, the other web browsers for common PDA and phone devices,
etc

-- 
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See .
___
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] The Philosophy of Web Use.

[Laura Carlson]

Ethan wrote:

> Can you do me a favor and let me know how these examples work
> for you?
>
> http://tool-man.org/examples/sorting.html

Works great for able bodied mouse users.

But how are people with mobility impairments like low dexterity (unable 
to use a pointing device like a mouse and instead must use keyboard or 
switch) able to use it? It doesn't seem to work via keyboard.

WCAG Guideline 9.  Design for device-independence:

"Use features that enable activation of page elements via a variety of 
input devices. Device-independent access means that the user may 
interact with the user agent or document with a preferred input (or 
output) device -- mouse, keyboard, voice, head wand, or other. If, for 
example, a form control can only be activated with a mouse or other 
pointing device, someone who is using the page without sight, with 
voice input, or with a keyboard or who is using some other non-pointing 
input device will not be able to use the form." [1]

Best Regards,
Laura

[1] http://www.w3.org/TR/WCAG10/#gl-device-independence
___
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 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] The Philosophy of Web Use.

[Laura Carlson]

Bryan wrote:

> I've seen WAY to much bad scripting (and I'm not implying that the
> code you are going to write is going to be bad) to actually want to
> implement and Javascript.

I've seen a lot of bad, inaccessible scripting too.

But if JavaScript is used in a device independent way to *progressively 
enhance* the user experience, as option, and if it degrades 
gracefully...all of which Ethan is aware of, then it can be a valuable 
tool.

I'll be eager to test his implementation.

Best regards,
Laura
___
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 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] The Philosophy of Web Use.

[Laura Carlson]

Ethan wrote:

>> No in-page form validation?

Brad wrote:

> I'd rather not, no. I have yet to see a single place on the Internet
> that actually does it right, and across all platform/browser
> combinations.

When using Javascript for form validation, there is a right way and a 
wrong way.

The right way (which I am sure Ethan already knows) is to use 
Javascript as an optional extra to improve usability. All form 
submissions are validated on the server. If the reader has Javascript 
available, an initial validation is done on the client, to check for 
*simple* errors such as missing information or non-numeric characters 
in a numeric field. This means the user gets faster feedback than 
waiting for a response from the server.

Javascript validation should be always optional. Since the validation 
must be on the server anyway, it is silly to insist that the user must 
have Javascript. Adding Javascript validation should help some readers 
and hinder nobody.

Best Regards,
Laura
___
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 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] The Philosophy of Web Use.

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think it's time to put this thread to rest for now.  I'm convinced  
Ethan understands and is sympathetic to the whole JS-vs-noJS issue.   
Let's give him a break so he can stop defending himself and give us  
something concrete to try and debate.

But thanks everyone!  It's was a good discussion to have!
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRK5SqXEjvBPtnXfVAQJv6gP/eVcOxHyifCN/603HHAqBFtPUmIneQqed
hq7oq0fNzWX2i1aUUC6anD2DnMekc6FiT39zjrvFQ7AlCWOk5icNkaZ0gUvfTbT/
3DwNQbaK9+UPtgzojvymvABN+cslCeZ24RwsxUr37T+JvQCCm6z9BbhWcPFnn9gO
1FABW2C/X5o=
=/ukC
-END PGP SIGNATURE-
___
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] The Philosophy of Web Use.

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 7, 2006, at 6:13 AM, Ian Eiloart wrote:

> One reason we might choose to switch off client side scripting is  
> so that
> we can support our 20,000 odd users without having to worry about  
> which
> view of Mailman they're seeing. We'll probably resist that, but our  
> front
> line support would probably prefer a single interface for everyone  
> - and
> that would necessarily be the java free interface.

Just to be clear, you meant JavaScript, not Java.  No one's proposing  
to use any client-side Java (hopefully).  That's a whole 'nother cup  
of Joe.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRK5RwnEjvBPtnXfVAQJHLAP/cTStX6Lg/UpE83MaZsPGZCsuZ8ZJ5G87
UepxfGU/4aN2I80NbQ2FNGsmokwBXtrqD9ZtgnHRoKZ57lGUCknIcLJrDUOG894W
7e8Oj2PPs8zjLsIG/E6RTQr4SJVGxL08wiZxu76znAlq/pvr1X9p8G35rREZRzU8
RvdkWmPDHuE=
=4mvZ
-END PGP SIGNATURE-
___
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] The Philosophy of Web Use.

[emf]

Brad Knowles wrote:

> I just read the intro to a Slashdot article at
> , which quoted the
> following section:
> 
> | Dollar for dollar, network-based computers are faster.

This is incorrect, based on my experience of working in a few data centers.

While it is possible to buy expensive hardware today that has more 
performance than the average consumer machine, hardware is getting 
better faster than purchasing decisions.

Because the consumer market is both larger and growing faster than the 
server market, and the machines less reliable, the average server is 
older than the average client machine, and thus have less resources than 
the average client.

Even if you disagree with this point, there's one server for many 
clients; the amount of resources available to devote to the task of an 
individual user's web experience is almost always greater on their end 
of the pipe.

What it boils down to is that people perceive change at around 150msec; 
very few net users get anywhere near this latency, and so for most, the 
round-trip delay represents a substantial impediment to the 
responsiveness of the interface.

~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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] The Philosophy of Web Use.

[Ian Eiloart]

--On 7 July 2006 02:01:19 -0400 emf <[EMAIL PROTECTED]> wrote:

> Can you do me a favor and let me know how these examples work for you?
>
> http://tool-man.org/examples/sorting.html
>
> ~ethan fremen

Works fine in Safari. Hopeless in a non-graphical browser, which I have 
used in desparation sometimes.

-- 
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] The Philosophy of Web Use.

[Ian Eiloart]

--On 7 July 2006 00:08:54 -0400 Brad Knowles <[EMAIL PROTECTED]> 
wrote:

>  In fact, I honestly believe that many of them
> actively work to break their websites on all other types of browsers and
> platforms, just so that they can force you to use Windows and Internet
> Explorer.

That's true. I've seen several sites that only work with Safari if I make 
it spoof another user agent!

-- 
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] The Philosophy of Web Use.

[Ian Eiloart]

--On 6 July 2006 23:05:46 -0400 emf <[EMAIL PROTECTED]> wrote:

> You are, I assume, OK with the server doing whatever sort of dynamic
> foofaraw it likes to generate a given web page; what makes server side
> manipulations inherently superior to client-side manipulations?

It's simple. You know what you can do on the server, you don't know what 
you can do in the client.

The site has to be able to work without client side scripting, so it would 
be useful to disable it in Mailman.

One reason we might choose to switch off client side scripting is so that 
we can support our 20,000 odd users without having to worry about which 
view of Mailman they're seeing. We'll probably resist that, but our front 
line support would probably prefer a single interface for everyone - and 
that would necessarily be the java free interface.

-- 
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] The Philosophy of Web Use.

[emf]

Brad Knowles wrote:

>> No reordering a list
>> without a zillion little checkboxes/number boxes and ambiguous behaviour
>> if the same number is entered twice?
> 
> Not really, no.  When I've seen that done in the past, it was almost
> always dead-dog slow and far more of an annoyance than any help that it
> could possibly have been.

Can you do me a favor and let me know how these examples work for you?

http://tool-man.org/examples/sorting.html

~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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] The Philosophy of Web Use.

[Brad Knowles]

Barry wrote:

> OTOH, I've used Linux and OSX, and before that NeXT, Solaris and
> various Unixes for (unfortunately, way :) longer than there's been a
> web, and except for the Windows programming I do at work, haven't
> ever used IE for any substantial amount of time.

I've been using Unix and the Internet since the summer of 1984, and a
Macintosh Fanatic since December of 1983 (when I saw a prototype, before
the official unveiling during the SuperBowl commercial).  I've never
voluntarily used IE, except when I'm at my parents house and I need to do
something on the web with her computer -- which is almost never, since I
always take my laptop with me.

> I would love to have a
self-discoverable
> interface, or an interface that can be used to selectively reveal
> just the parts you're interested.

I just read the intro to a Slashdot article at
, which quoted the
following section:

| Dollar for dollar, network-based computers are faster. Unless you're
playing Grand Theft
| Auto or watching HDTV, your network isn't the slowest part of your
setup. It's the
| consumer-grade Pentium and disk drive on your Dell, and the wimpy home
data bus
| that connects them. Home computers are marketed with slogans like "Ultimate
| Performance," but the truth is they're engineered to run cool, quiet,
and slow compared
| to commercial servers.

I'm not 100% certain the original author being quoted by Slashdot is
right, but at the very least I think you have to give some serious
consideration to what the author is saying.

-- 
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See .
___
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] The Philosophy of Web Use.

[emf]

Brad Knowles wrote:

> One thing that really concerns me is excessive complexity in the user
> interface.  As a MacOS X/Safari user, I've found so damn bloody many web
> sites that are totally hosed for me, regardless of whether I allow them to
> use JavaScript or not. 

I can see that; I have that problem intermittently.

> But the more complexity that is built into the user interface,
> the higher the likelihood is that something will accidentally happen
> somewhere to seriously break something for someone else.

This is really vague; I have no idea how, given that I have said that 
this thing will work without JavaScript on at all, this "don't do it 
because it might be complicated" heuristic is applicable.

> In fact, I think it's quite likely that you will even be put into a
> situation where a bug in a given platform/browser combination causes you
> to completely re-work a lot of your carefully written code,

I'll put $10 down on the side of "I know what browsers do" and thus 
won't have to re-work my code to accommodate one broken browser.

> In other words, I'd like to see that you really can walk in all the
> different likely shoe and surface combinations, before we let you draft us
> into supporting your plans to win the marathon -- especially if we're all
> going to be giving you all our scissors, razors, knives, swords, and other
> bladed instruments.

This strikes me as an argument from extremes; I am not advocating doing 
anything particularly complex.

> I'd rather not, no.  I have yet to see a single place on the Internet that
> actually does it right, and across all platform/browser combinations.

If you would give a concrete example maybe we could get past FUD.

> More often than not, when typing in a phone number, I'll be unable to
> enter the last four digits because they simply set a length limitation on
> the field, and didn't bother to check for non-numeric characters.

Length limitation is something you can set in HTML. It's possible to 
make that mistake in JavaScript, too, but it's not JavaScript's fault.

> I'd rather not, no.  Again, every single website I've ever seen that tries
> to show me exactly what my comment is going to look like ends up not
> working very well. 

Have you used http://wiki.list.org/ ? Is it "flat out broken" or "slow 
and distracting"? I find it has a few bugs, but mostly it works well.

>> reordering a list without a zillion little checkboxes/number boxes and 
>> ambiguous behaviour
>> if the same number is entered twice?
> 
> Not really, no.  When I've seen that done in the past, it was almost
> always dead-dog slow and far more of an annoyance than any help that it
> could possibly have been.

Here's a specific example that works well for me: Does the drag/drop of 
boxes on the customized google home page not work for you? You don't 
have to sign in to try it, and it allows drag/drop reordering for me in 
Safari just fine, and way more intuitively than resubmitting the page 
after clicking on buttons.

> Like that damn bloody stupid "find as you type" crap.  I've learned a few
> things about torture over the years. 

I'm sorry that this has been so unpleasant for you. I find it helpful in 
several cases.

>> What do you do when you have a data structure not well suited to tabular
>> display or a list/tree? Just give the user fragments of the content?
> 
> I'm not sure that I've got any answers for you, with regards to how you
> should resolve this issue. 

So you have no constructive feedback, nor a sufficiently detailed 
critique that I can even address your concerns. I'm not sure what you 
would have me do with your advice, beyond my already existing commitment 
to make the page work without JavaScript.

> it's not physically possible to know, a priori, everything that any
> user might ever want to do under any and all possible circumstances.

If this were the criteria, no user interface would ever get built.

I have already articulated a strategy that covers all browsers currently 
released with a measurable market share.

* IE 5+, Mozilla (any), Safari from 1.0+ and any other KHTML browsers, 
JAWS 6+, Opera 6+, Lynx, Links. All in any combination of 
Images/CSS/JavaScript off/on.

I look forward to your feedback when I have something that you can try; 
perhaps that will help us talk about specific issues.

~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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] The Philosophy of Web Use.

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 7, 2006, at 12:08 AM, Brad Knowles wrote:

> One thing that really concerns me is excessive complexity in the user
> interface.  As a MacOS X/Safari user, I've found so damn bloody  
> many web
> sites that are totally hosed for me, regardless of whether I allow  
> them to
> use JavaScript or not.  Virtually every single web page designer  
> I've ever
> met has always had Windows/Internet Explorer on the brain, and they  
> don't
> care about anything else.  In fact, I honestly believe that many of  
> them
> actively work to break their websites on all other types of  
> browsers and
> platforms, just so that they can force you to use Windows and Internet
> Explorer.

OTOH, I've used Linux and OSX, and before that NeXT, Solaris and  
various Unixes for (unfortunately, way :) longer than there's been a  
web, and except for the Windows programming I do at work, haven't  
ever used IE for any substantial amount of time.  I'm not excusing  
poor sites or Windows-specific sites, but for the most part, these  
days most sites are at least usable with Firefox on various  
platforms.  (The one sole recent exception was the SQLAlchemy doc  
pages which gave Firefox fits but rendered just fine in Safari -- and  
I'm sure those guys didn't tailor their pages for IE.).  Yeah, you  
hit the occasional WMV or ActiveX laden site, but I'm much more  
bugged by the Flash-only sites that are an avoidable annoyance for  
me, but I can imagine are a scream-out-loud frustration for screen  
reader based users.

> Now, I know that you're not that kind of person, and you will actively
> test your work with MacOS X/Safari, and as many other browser/OS  
> platforms
> you can.  But the more complexity that is built into the user  
> interface,
> the higher the likelihood is that something will accidentally happen
> somewhere to seriously break something for someone else.

Actually, I think skilled and judicious use of modern web technology  
can help to /reduce/ the complexity of Mailman's interface.   
Something I constantly struggle with is the plethora of configuration  
variables (both via the web u/i and in mm_cfg.py) that makes the  
system highly complicated.  I would love to have a self-discoverable  
interface, or an interface that can be used to selectively reveal  
just the parts you're interested.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRK3kGXEjvBPtnXfVAQJfrQQAoYkRLIATvJrLsM2kx88DF4UZHbeoXXZI
CrIhzM2URy+IIcRMQCBn8jfqnyIeTvVUcemHiCjpDyhyVEuYlYXtvjT9d5W9DrjR
OW3rlDViFfuEA6NSU+/QS8YDhokpf2tLpbdKiKLdqgiAdMGR8+jhHFEsmbsha79d
xX7xKMzNmOY=
=/Mp9
-END PGP SIGNATURE-
___
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] The Philosophy of Web Use.

[Brad Knowles]

Ethan quoted Bryan Carbonnell:

>> For me it's nothing specific. It's more philosophical. I am a very
>> minimalist when it comes to the 'net. Plain text e-mail and no
>> scripting or embeded audio/video on web pages.
>
> I can appreciate that philosophy, to some extent. So you always surf
> with JavaScript turned off? How do you turn off embedded media? Why is
> image embedding (I assume you don't turn off *all* images) acceptable
> within your philosophy while other media types are not?

When I browse, I don't turn off GIF, JPEG, or PNG images, although I do
wish I could turn off GIFs (they are/were encumbered by patents and I
don't support any kind of software patent, and are also a security risk). 
Since these things are rendered from within the browser itself, short of
turning off all images, I don't think I have a choice.

But I do browse with multimedia and flash turned off by default, except
for those few sites that I've decided to take a risk on.

> I agree that content should stand on its own legs. However, many
> websites- including mailman's interface - are applications where the
> *interaction* between the user and the content is at least as important
> as the content itself.

One thing that really concerns me is excessive complexity in the user
interface.  As a MacOS X/Safari user, I've found so damn bloody many web
sites that are totally hosed for me, regardless of whether I allow them to
use JavaScript or not.  Virtually every single web page designer I've ever
met has always had Windows/Internet Explorer on the brain, and they don't
care about anything else.  In fact, I honestly believe that many of them
actively work to break their websites on all other types of browsers and
platforms, just so that they can force you to use Windows and Internet
Explorer.

Being sensitive to this sort of thing in my own condition, I really don't
want to see us creating a similar situation for someone else.


Now, I know that you're not that kind of person, and you will actively
test your work with MacOS X/Safari, and as many other browser/OS platforms
you can.  But the more complexity that is built into the user interface,
the higher the likelihood is that something will accidentally happen
somewhere to seriously break something for someone else.

In fact, I think it's quite likely that you will even be put into a
situation where a bug in a given platform/browser combination causes you
to completely re-work a lot of your carefully written code, or even
completely abandon the idea of providing certain features that you had
once thought very important.


So, my vote is to set expectations a lot lower, prove to yourself (and us
;-) that you really can implement that restricted set of features on all
specified platform/browser combinations, and then hopefully you will have
produced a set of specifications and a design that is easily adaptable for
future work to expand on those options and provide more of the kinds of
advanced features that you were looking for.

In other words, I'd like to see that you really can walk in all the
different likely shoe and surface combinations, before we let you draft us
into supporting your plans to win the marathon -- especially if we're all
going to be giving you all our scissors, razors, knives, swords, and other
bladed instruments.

> You are, I assume, OK with the server doing whatever sort of dynamic
> foofaraw it likes to generate a given web page; what makes server side
> manipulations inherently superior to client-side manipulations?

Pretty much, yes.  So long as it comes across the wire to my browser as
pretty plain-jane HTML, I don't really care too much what you do on the
back-end.  At least there, you've got a much more restricted set of
platform/server combinations that you have to worry about, and hopefully
Python can help you hide a lot of those complexities.

>   No
in-page
form
> validation?

I'd rather not, no.  I have yet to see a single place on the Internet that
actually does it right, and across all platform/browser combinations.

More often than not, when typing in a phone number, I'll be unable to
enter the last four digits because they simply set a length limitation on
the field, and didn't bother to check for non-numeric characters.  Or,
when I was living in Belgium, my phone number had to be much longer than
anyone in the US is used to, because it had to include some sort of
indication that I was providing an international phone number, plus my
country code, and all the other local stuff.

> No showing users a rendered preview
of text
> they enter?

I'd rather not, no.  Again, every single website I've ever seen that tries
to show me exactly what my comment is going to look like ends up not
working very well.  When it's not flat-out broken, it's slow and
distracting.

I'd rather focus on the words and not whether I've got the right fiddly
font or 

[Mailman-Developers] The Philosophy of Web Use.

[emf]

Bryan Carbonnell wrote:

> For me it's nothing specific. It's more philosophical. I am a very
> minimalist when it comes to the 'net. Plain text e-mail and no
> scripting or embeded audio/video on web pages.

I can appreciate that philosophy, to some extent. So you always surf 
with JavaScript turned off? How do you turn off embedded media? Why is 
image embedding (I assume you don't turn off *all* images) acceptable 
within your philosophy while other media types are not?

> I think the content of
> the page should stand on its own legs and not rely on "fancy tricks"
> to make it appealing.

I agree that content should stand on its own legs. However, many 
websites- including mailman's interface - are applications where the 
*interaction* between the user and the content is at least as important 
as the content itself.

I know of no application environment where the behaviour of an 
application's user interface can be specified entirely through 
declarative code.

It's hard for me to see why one would want this in the first place; any 
dynamicism carries with it the requirement for some logical manipulation 
of the user interface and thus a requirement for logic.

Things like XForms try to shove a good deal of this into a declarative 
syntax; I would happily code an interface in this fashion, but the vast 
and mysterious gods of the internet have not deemed it possible. If you 
even want to use a XSLT transformation in any dynamic way in browsers, 
you have to load it from JavaScript.

You are, I assume, OK with the server doing whatever sort of dynamic 
foofaraw it likes to generate a given web page; what makes server side 
manipulations inherently superior to client-side manipulations?

> I also know that quite a few of my users are going to be up in arms if
> scripting gets added to the pages.

Of any sort? No changing to a high-visibility stylesheet without 
refreshing the content (that hasn't changed?) No in-page form 
validation? No changing active and inactive form elements based on the 
user's prior selections? No showing users a rendered preview of text 
they enter? No autocomplete in any text element? No reordering a list 
without a zillion little checkboxes/number boxes and ambiguous behaviour 
if the same number is entered twice? No re-sorting of lists? No 
context-sensitive help beyond the title="" attribute? No user feedback 
of any sort until a Submit button is pressed?

So in this philosophy, if I want to offer two mutually exclusive sets of 
options, I should: a.) display them both, then render a page saying "you 
can't do that" when they pick a combination that doesn't work; b.) make 
them resubmit the page with the appropriate radio button checked to see 
the 'other' possibility; c.) provide an additional bit of text that says 
"if you do x, then you can't do y"?

What do you do when you have a data structure not well suited to tabular 
display or a list/tree? Just give the user fragments of the content?

That's the part that gets me; if Content is sacrosanct, shouldn't 
providing as complete a picture in a given page's content be a goal?

> I just want to have the option to
> NOT use in in MM. I realize that I can just delete the JS file or
> disallow it with Apache, but I feel that since this is a MM endeavour
> I should be able to control it within MM and not have to resort to
> things like you mention to disable the JS.

I'm still not with you on this one; any user can turn off JS, but no 
user can turn on what you've disabled.

~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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp