Re: [Mailman-Developers] Turning off dynamic JavaScript
--On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote:
Are you suggesting I provide *no* link for the screen-reader-with-javascript client and let them at some point figure out that they're not seeing what's going on and thus turn off javascript?
That seems like a worse solution.
I'm suggesting that javascript is fine to use for progressive enhancement but not for core functionality. Javascript should be used to enhance the usability, _if_ it doesn't negatively affect accessibility. A Javascript dependent app is just not accessible.
But like it says in 6.3 of WCAG 1.0, if it is not possible to make pages accessible when scripts, applets, or other programmatic objects are turned off or not supported, the fallback is to provide equivalent information on an alternative accessible page.
SitePoint's JavaScript Anthology chapter on JavaScript and accessibility that features a lot of test results with different screen readers, but I don't see that as much more use than a DHTML script that was tested in 1999 on Netscape and IE - by making your DHTML accessibility dependent on the user agent - regardless of screen reader or browser - you make it easily outdated.
The problem is not only users of assistive technology, it is about availability as well. What if I work in a high security environment where my employer turns off JavaScript or filters it out via a proxy by default? What if I am somewhere without internet access on the ground and want to use my mobile or satellite phone to reach an app?
In both Section 508 and WCAG 1.0 a separate text only version is not considered an accessible solution. Basically the requirements state that the author has determined that the primary site CANNOT be made accessible, and the text only site provides some kind of second class access to the content.
Creating a text-only version of a web site should be done when there is no other way to make the content accessible, or when it offers significant advantages over the main version. And then the text-only version needs to provide the functionality equivalent to that of the main version.
Some thing to consider with separate versions:
Text-only versions are rarely totally equivalent in content to the "real" version. They often do not fully convey content and its context. They effectively segregate the audience they are targeted at.
When there is a text-only version available, developers sometimes do not make the "real" version accessible.
From a maintenance view, creating a text-only page for every Web page
is twice the work. Invariably, the text version is going to be out of sync with regular content. This then creates an accuracy problem.
The accessible version is often hidden behind its inaccessible counterpart. People needing to use the accessible version of the website still need to be able to deal with the inaccessible one. They have to search through an inaccessible page to find the link to the text-only page. This problem could be reduced by ensuring that the "skip to accessible version" link is the first piece of information on a page.
Ethan, have you considered making the main site not rely on JavaScript for functionality and having a link to a JavaScript enhanced version, so the accessible version is not hidden behind its inaccessible counterpart?...Or you might want to consider this approach:
- make it work without JavaScript
- add event handlers or even an AJAX layer to make it work more smoothly
- give the user the option to use one interface or the other - as most
web apps require login and have a defined user journey this is a lot easier, as visitors are not likely to enter in any of the pages like they do in a web site.
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/
Laura Carlson wrote:
--On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote:
Are you suggesting I provide *no* link for the screen-reader-with-javascript client and let them at some point figure out that they're not seeing what's going on and thus turn off javascript?
That seems like a worse solution.
I'm suggesting that javascript is fine to use for progressive enhancement but not for core functionality.
Laura, I appreciate your thoughtful and detailed replies. I feel like we're kind of talking across each other. I had indicated in a previous post that the mailman interface I am building will be fully functional without javascript/css; it is the first point on the technical plan at http://wiki.list.org/display/DEV/Summer+of+Code .
- make it work without JavaScript
- add event handlers or even an AJAX layer to make it work more smoothly
I am not sure what you mean by this. I will be using event handlers, but existing screen readers fire event handlers just fine; in fact they do everything I want them to do *except* change focus to the modified portion of the page.
- give the user the option to use one interface or the other - as most
web apps require login and have a defined user journey this is a lot easier, as visitors are not likely to enter in any of the pages like they do in a web site.
That is what I was suggesting by providing a link to a js-light version for screen readers. My logic was something like this:
Because I am otherwise being quite accessible, someone using a screen reader *with JavaScript enabled* may not realize that some actions are causing other parts of the page to refresh. The javascript code I want to use will be perfectly functional or degrade gracefully otherwise, and I suspect/am working to ensure that they will still provide usability enhancements for those running a javascript interpreter, including said screen readers.
One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a "overview" page variant and then being able to expand as necessary.
Therefore I am attempting to find a solution to this one problem so that I don't have to push screen readers to a JS/css free page unless they choose that.
Right this second, it looks like I may be 'safe' if I make sure that whatever DOM manipulations I perform only cause 'downstream' (in code order) elements to become visible/hidden/filled.
~ethan fremen
Ethan wrote:
One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a "overview" page variant and then being able to expand as necessary.
I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of "hidden" text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see.
On 7/6/06, Brad Knowles brad@stop.mail-abuse.org wrote:
Ethan wrote:
One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a "overview" page variant and then being able to expand as necessary.
I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of "hidden" text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see.
I have to agree with Brad on this.
An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable.
Bryan Carbonnell wrote:
I have to agree with Brad on this.
An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable.
I'm a little reluctant to add another bit flip to mm_cfg when you'll be able to delete the .js files or forbid access to the js directory in apache and get what you want.
Or you could avoid subjecting all your users to your preference and use the no-JS variant that will always be available, or just turn JS off in your browser.
Can you help me understand your opposition to Javascript in a webpage you serve? Something specific rather than in principle, if you would be so kind; I often have a hard time applying abstract concepts to code I'm in the process of writing.
Thanks for your help,
~ethan fremen
On 7/6/06, emf i@mindlace.net wrote:
Bryan Carbonnell wrote:
I have to agree with Brad on this.
An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable.
I'm a little reluctant to add another bit flip to mm_cfg when you'll be able to delete the .js files or forbid access to the js directory in apache and get what you want.
Or you could avoid subjecting all your users to your preference and use the no-JS variant that will always be available, or just turn JS off in your browser.
Can you help me understand your opposition to Javascript in a webpage you serve? Something specific rather than in principle, if you would be so kind; I often have a hard time applying abstract concepts to code I'm in the process of writing.
Ethan,
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 think the content of the page should stand on its own legs and not rely on "fancy tricks" to make it appealing.
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 also know that quite a few of my users are going to be up in arms if scripting gets added to the pages. 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 know this sounds negative, it's not. I'm really glad the UI is getting overhauled. I have done what I could with the XHTML/CSS patch that I wrote, but I know the UI could be a LOT better.
Just my $0.02
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
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 the right fiddly kerning, or whatever.
No autocomplete in any text element?
No, my browser is annoying enough when it tries to do autocomplete, and it almost always fails to autocomplete what I'm trying to type in the way I would want it to.
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.
Like that damn bloody stupid "find as you type" crap. I've learned a few things about torture over the years. I'd like to test them all on the guy who invented that idea, and then maybe see if I can come up with a few more new concepts in that area that have never previously been explored.
And there's no way I'd let that guy pull a Ken Lay and up and die on me before I'm done with my experiments.
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. I'm just telling you the sorts of things I have had experience with in the past, and which I would be very annoyed to ever have to encounter again at any time in the future.
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?
Yes, but it's not physically possible to test with all possible platform/browser combinations that will exist throughout all of history (at least, throughout the entire history of the program you're designing), and it's not physically possible to know, a priori, everything that any user might ever want to do under any and all possible circumstances.
Some things you can guess at, and provide reasonable failure modes should you guess wrong. Other things you can guess at, but the failure modes are going to be quite a bit more nasty. And then there are a lot of things that you would never have guessed in a million years, and you've got to wonder what complex code is going to do under those circumstances and what the failure modes will be.
-----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
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 http://slashdot.org/articles/06/07/06/1654242.shtml, 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 wrote:
I just read the intro to a Slashdot article at http://slashdot.org/articles/06/07/06/1654242.shtml, 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
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 SETI@Home project certainly taught us that. And we knew that lesson at AOL before SETI@Home 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.
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.co...
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
David Andrews and white cane Harry.
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
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 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
--On 7 July 2006 02:01:19 -0400 emf i@mindlace.net 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.
Ethan wrote:
Can you do me a favor and let me know how these examples work for you?
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.
--On 7 July 2006 00:08:54 -0400 Brad Knowles brad@stop.mail-abuse.org 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!
--On 6 July 2006 23:05:46 -0400 emf i@mindlace.net 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.
-----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 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
Brad Knowles wrote:
I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered
Can you help me understand the basis for this claim? I have looked into the matter somewhat deeply and this works in every browser I have come across that supports JavaScript:
document.getElementById('foo').style.display = 'none';
An intelligent layout allows you to minimize the amount of page rejiggering that goes on when you display text.
Visual tests using Greasemonkey allow you to see all the visual states a page can get in (including different sized displays) to ensure you don't get into an unpleasant corner.
Perhaps you mean to say that the variety of CSS implementations prevents me from knowing how a UA will render the page. Strictly speaking, this is true; pragmatically speaking, there exists suitable CSS that works in all current browsers that I know of.
if you send all sorts of "hidden" text that isn't shown until such time as someone does something to make it appear,
The document with all the hidden text shown will be something like a "full detail" view; after all, I've promised the page will work fine with JavaScript off.
and you can't control what kinds of mailicious cross-scripting attacks people may throw at you,
I am unaware of any cross site scripting (XSS) attacks that can occur when a linked-in stylesheet uses the event model to alter the style of a element.
Perhaps you are referring to the approach of using some mechanism (XMLHttpRequest or naive furl() type stuff) to fetch new bits to go into a page. This definitely a risk, and one I'm disinterested in playing with.
I intend to use XMLHttpRequest to fetch JSON messages like "preferences saved" from the server. These messages will be carefully scrubbed and come only from server-generated translations, rendering them an improbable source of XSS.
I also intend to use it for one-way communication where the client informs the server that something has changed via JSON. As with all form submissions, each JSON submission will have to come with the appropriate hashcash-esque validation element to be considered to come from the user.
The UI benefit that drives the above choice is that I can provide the user with the UI state of the web app at the last time they used it, no matter what machine they come from.
it's best to simply not send anything that the user cannot currently see.
I'm not sure I understand this principle.
Most people have internet bandwidth that is inferior to the rendering speed of their browser, and a monitor that is smaller than most page content; some people (like those using screen readers) have essentially a 2d/linear monitor.
This suggests that sending fewer, "larger" chunks is preferable to sending many smaller chunks when the user will be aware of the load time. The way modern rendering engines work makes 'hidden' text *much* faster to load during initial page rendering than it would if it were all displayed.
One use case is where the new user clicks on all the help buttons to learn what's going on; a delay rendering help increases exploration cost.
Another one is the way people read on the web. Nielsen [1] and many others in the usability field have shown that people scan, looking for key words, rather than reading. The fewer words the shorter the seek time and the more likely the user will do an exhaustive search of the page for what they're looking for.
[1] http://www.useit.com/alertbox/9710a.html
When it comes to screen readers, text *is* space; sighted individuals can skip big swaths of text with a single saccade, but a blind user must give voice to enough of the text to hear where they're going.
This makes scanning text both temporally and cognitively more expensive than it is for sighted users.
As screen readers *do* respect hidden/shown elements, I can significantly improve the user experience for them, while making life easier for visual uses as well.
On somewhat of a side note, I have heard a certain amount of antipathy towards JavaScript in this forum. I know it was unpleasant in the late '90s, but it is much better and more cross-browser these days.
I'm fairly certain that *some* author-initiated manipulation of a user's experience of a node set is obligatory in any conceivable Web; the only alternative I can see to using JavaScript or another interpreted language would be using something like XSLT, a horror that I shrink from even contemplating.
~ethan fremen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 6, 2006, at 4:45 PM, emf wrote:
On somewhat of a side note, I have heard a certain amount of antipathy towards JavaScript in this forum. I know it was unpleasant in the late '90s, but it is much better and more cross-browser these days.
I'm sure a lot of that comes from me, inspired by early experience
and my own general paranoid dinosaurism. OTOH, I remember Guido
telling me a few years ago that I might as well give up on that one,
and so I have -- mostly. That's why I love NoScript so much :).
I'm no web developer expert by a long shot, but I've been following
the discussions and istm that Ethan is striking a reasonable balance
and is being extremely diligent in his research. I for one am quite
eager to see what he comes up with!
- -Barry
Barry wrote:
I'm sure a lot of that comes from me, inspired by early experience and my own general paranoid dinosaurism. OTOH, I remember Guido telling me a few years ago that I might as well give up on that one, and so I have -- mostly. That's why I love NoScript so much :).
No, you're not the only one. I flat-out refuse to use most sites that require JavaScript, and run with JavaScript, Java, popups, and most extensions turned off by default (especially Flash). With Safari, I use PithHelmet to control what few sites I encounter that I will allow to use JavaScript, Java, plug-ins, etc... and when I'm running Firefox I use NoScript plus a number of other similar tools to do the same.
Unfortunately, most of the sites which try to force me to use JavaScript do such a horrible job that they're pretty much completely unusable on MacOS X regardless of whether I use Safari or Firefox (or Opera, or anything else), and whether or not I allow JavaScript or not.
I've been burned badly and repeatedly. And new sites are always popping up all over the place that continue to introduce me to new ways to screw up my browser and my machine, primarily through JavaScript, Flash, and all that other crap that I always leave turned off.
You'll drag me into a pure JavaScript/AJAX world over my dead body -- and maybe a few million dead web site authors, if I can ever get my hands on the football.
I'm no web developer expert by a long shot, but I've been following the discussions and istm that Ethan is striking a reasonable balance and is being extremely diligent in his research. I for one am quite eager to see what he comes up with!
I'm skeptical, but I am curious to see the result. I hope I'm being open-minded enough that I'm giving him a fair chance to convince me that these kinds of things are not Inherently Evil.
--On 6 July 2006 16:45:26 -0400 emf i@mindlace.net wrote:
Can you help me understand the basis for this claim? I have looked into the matter somewhat deeply and this works in every browser I have come across that supports JavaScript:
And the ones that don't?
participants (7)
-
Barry Warsaw -
Brad Knowles -
Bryan Carbonnell -
David Andrews -
emf -
Ian Eiloart -
Laura Carlson