Not sheepish, but individ-ewe-al (livredor) wrote in suggestions,
Not sheepish, but individ-ewe-al

Reduce dependency on JavaScript

Reduce dependency on JavaScript

Short, concise description of the idea
When an old page is replaced with a new version that uses fancy JavaScript, a link should be provided to the old version.

Full description of the idea
LJ is introducing a lot of new features which need JavaScript (the Xcolibur sitescheme, QuickReply commenting, AJAX commenting, the new update page, the new S2 editor, the proposed new portal page...). This is all very well, but not all these features degrade gracefully for people who don't have JavaScript or don't have modern browsers.

Obviously the developers can't be expected to make every page compatible with every weird or ancient browser out there. Hence I'm proposing that JavaScript heavy pages provide links to non-JavaScript pages, a bit like Gmail's "HTML only" version.

So for example, update.bml could include a link to /old/update.bml, the new S2 editor could provide a link to the old S2 editor (which was ugly, but a lot more widely usable than the new one). Ideally, it should be possible to set a site-wide preference in a cookie that you don't want to see JavaScript on site-based pages, but that would be more work and perhaps not justified.

An ordered list of benefits
  • More features of the site would be useable for everyone. I'm talking about some pretty core features, like the ability to post entries or reply to comments, not just frivolous add-ons, here.
  • Not everybody has the ability to upgrade to a newer browser or change their JavaScript settings.
  • The range of ways people can access the web is growing all the time. As well as catering for older computers, LJ should consider new technologies like WAP and who knows what might be invented in the next few years.
  • People who find they can't display a page properly are very likely to just give up and leave the site. Having lots of JavaScript which is broken for many users is ultimately going to cost business.
  • Better accessibility. The more of the site is available in as simple a format as possible, the more easily people with various disabilities are going to be able to use it.
  • The old, easily useable versions of pages already exist, so this would require little or no new coding.
  • Less developer effort spent on making JavaScript work cross-browser. If users have the option to use the old version, it will be less of a problem when unforseen bugs show up. For example, there was a huge kerfuffle over QuickReply until eventually an option was provided to turn it off; had that been available from the start, that would have been avoided. Likewise, there was a lot of stress and emergency patching needed to fix the update page so that it was even vaguely workable for a large number of users.
  • Lots of people dislike change, so having old pages available would quell some of the whining when a new feature is introduced.
  • Even though the proportion of users who can't deal with modern JavaScript may be small, in absolute numbers it's a lot of disgruntled users because the userbase is so huge.

An ordered list of problems/issues involved
  • JavaScript looks cool and modern.
  • Some of the old versions of pages are pretty sketchy.
  • Some new features might just not be possible without JavaScript.
  • It's generally good to retire obsolete code rather than keeping it running in parallel with new code.
  • It might be argued that it isn't worth any effort at all, even the most trivial, to support minority browsers.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • If an old HTML / BML page is replaced with a new JavaScript page, the new JavaScript page should contain a link to "HTML only version", and the old version should be kept available on the site.
  • If a new feature is introduced that relies on JavaScript, the option should always be added to disable it, at least in the console (qv QuickReply comments).
  • There should continue to be an option to display comment pages in the sitescheme (as there is now), even if that ceases to be the default. [link]
Tags: accessibility, javascript, usability, user interface, § rejected
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded