RE: ACTION-713 Review some AJAX resources

Sean,
Thanks for the input, here are some questions on it:

Re "1. Separate JavaScript into external files; no JavaScript in markup
(maybe has performance/caching benefits)": this seems to conflict with
"5.5.6 Minimize External Script Files", unless they are delivered as a
multipart package as noted. What is the basic motive behind separation?
I think there are some cases, similar to in-line or embedded style,
where it is more efficient to include the script inside the markup.
Certainly " 2. Content should be basically usable without JavaScript"
means don't send script if the device doesn't support it, so that's not
the criteria for separating it for devices that do.

Re " 2. Content should be basically usable without JavaScript", I think
this is covered by "5.9.4 Provide Alternatives to AJAX", "5.9.1 Use
Device Capability Detection", and "5.9.2 Use Reliable Methods for
Determining Script Support", which together provide the "what" (provide
alternatives) and the "how". We could generalize 5.5.4 to "Provide
Alternatives to Javascript" though.

Re the accessibility issues, I think WCAG should pick up on them and we
can leave it as a reference to WCAG.

Re "3. Offer to disable automatic updates": this is already covered by
"5.3.5 Provide Useful Control over Application Behavior".

Re "4. Provide "notification" of changes": this seems to be specifically
a UI-usability issue, and might conflict with "5. Don't shift focus when
an update occurs".

Re "5. Don't shift focus when an update occurs": I agree totally with
this one. This is a problematic behavior in PC's and moreso in mobile
devices. I will see if I can craft a paragraph around this.

Re "6. Update elements with new content instead of adding elements.":
this seems to be a DOM-efficiency question, and if so would fit in
"5.5.5 Minimize DOM Manipulation". I would like a DOM-expert to craft a
way to express this in not-overly-techie terms.

Best regards
Bryan Sullivan | AT&T

-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Sean Owen
Sent: Thursday, March 13, 2008 1:29 PM
To: Mobile Web Best Practices Working Group WG
Subject: ACTION-713 Review some AJAX resources


Here is my condensation of points that seem to have some possible
mobile-specific connection -- maybe just by seeming even more important
on mobile. I came away with six possible BPs to consider including, with
proper attribution to source of course.


http://thinkingandmaking.com/entries/63

1. Separate JavaScript into external files; no JavaScript in markup
(maybe has performance/caching benefits) 2. Content should be basically
usable without JavaScript (more likely to encounter devices with limited
or no script in mobile)


http://ajaxian.com/archives/accessible-ajax-best-practices

These are largely *accessibility* concerns, and I am not clear any of
them overlap enough with *mobile-specific* concerns to include, but,
here is my summary anyway

- Dynamic changes to page content need to be relayed to a screen reader.
  - ECMAScript focus method can be used to place focus to the part of
the page that has changed
  - Can use a tabindex='-1' hack to make more elements focusable,
assisting the above
  - ... some problem with readers and tables embedded in forms that I
didn't understand -- there is some practice here though!
- (Not explicitly mentioned, but seems to be implied) Always set the
"title" attribute wherever you can -- used by readers


http://www.unc.edu/webaccess/training/ajax/ajax_best_practices.pdf

3. Offer to disable automatic updates of information (e.g. stock price,
temperature) (reduces data usage) 4. Provide "notification" of changes
(not sure exactly what this means). Helps accessibility, but also helps
the UA zoom/pan to the update area (small browser window on mobile may
not even show the area that was updated, when it needs attention) 5.
Don't shift focus when an update occurs (input is hard, usually a
special mode, on mobile -- don't shift out of it capriciously) 6. Update
elements with new content instead of adding elements. For example add an
empty <div> and fill it later. (Hmm, does this reduce rendering
overhead, and thus processing power usage / battery
consumption?)


http://web2.socialcomputingmagazine.com/best_practices_and_challenges_in
_building_capable_rich_user_.htm

(Actually just about a book of best practices -- anyone want to get a
copy?)

Received on Thursday, 13 March 2008 21:44:55 UTC