Techniques to review for next week

During this week's Team C call, Sofia and I found that we could have
meaningful discussion only on techniques that had been reviewed and
comments posted to the list. To prepare for next week's call, I would
like to ask each person in Team C to review a couple of the following
techniques. I've put names beside two techniques each, semi-randomly. If
you could take a close look at your two in preparation for next week's
call, it will help us to go much faster.

Suggestions for how to do the review follow the list of techniques.

Michael

* Ensuring that users are not trapped in content
<http://tinyurl.com/dv7zm>
* Providing keyboard-controllable event handlers
<http://tinyurl.com/96d2t>

Sofia

* Failure due to using script to remove focus when focus is received
<http://tinyurl.com/9bskn>
* Providing a script on page that warns the user a timeout is about to
expire <http://tinyurl.com/deqv7>

Tim

* Allowing the user to extend the default timeout
<http://tinyurl.com/cpupv>
* Polling the server and triggering a warning to the user when a session
timeout is imminent <http://tinyurl.com/e3n3g>

Makoto

* Failure due to using meta redirect <http://tinyurl.com/bwg5r>
* Failure due to using meta refresh <http://tinyurl.com/8m2cf>

Andi

* Failure due to using server-side techniques to automatically redirect
pages after a timeout <http://tinyurl.com/ddts8>
* Ensuring content blinks for less than three seconds
<http://tinyurl.com/az2gd>

REVIEW SUGGESTIONS

Typos and grammatical corrections - it is preferable if you just go into
the wiki and make those corrections yourself. No need to send anything
to the list about this, as long as you don't change the meaning.

Wording improvements that don't change meaning - feel free to put these
directly in the wiki as well. If you're uncertain if people will think
your change is an improvement, you can put it in a new paragraph
prefaced by "SUGGESTED WORDING: " and your initials. Alternatively, put
your suggestions in a message to the list. Keep in mind, if you think
wording needs to be improved, please make a suggestion, as it is very
difficult for the team to decide what to do when a concern has been
raised but an alternate suggestion is not in front of them.

Corrections to code of examples and tests - if these are to make the
code valid, or do what the intro says it does, you can just go ahead and
make that change directly in the wiki as well.

Questions or suggestions that might change meaning - you can put these
in the wiki, but don't replace anything that's there. Instead, put it on
its own line, prefaced by your initials, and with a space in front of
the line so it will appear as an editorial note (or you can wrap it in
<pre></pre> tags). If you prefer, you can just send these to the list,
but it's usually easier to understand these questions when they're
directly in context.

Received on Tuesday, 31 January 2006 22:04:43 UTC