dojo svn notes

Late last week the dojo committer svn URL moved and it was fairly straightforward to update my Eclipse settings. I had a clean sandbox so I just blew it away, then went to the SVN Repository perspective, added "https://svn.dojotoolkit.org/view/committer" as a repos, browsed to all/trunk and checked out as a project named dojo-trunk.

I learned there is an svn switch command for changing the prefix for all the URLs in a sandbox instance which would have been good if I had uncommitted local changes.

Aside: I use my macports svn client from a shell for creating patches as it strips the irrelevant directory prefixes.

Uniquely identifying chunks of UI

To follow up my last post, ARIA's templateid allows a finer grained customization than what Greasemonkeys, JAWS scripters, Orca scripters and others might be used to.

Normally AT customization happens based on which application currently has focus, and in the case of browsers, which URL is currently loaded. Now we can go inside the document.

We can mark a piece of our UI like this:
<div aria-templateid="abc123.org/FooComponent_v1">
    <!-- embedded FooComponent_v1 -->
</div>

Here's how I imagine it will work: when focus moves within this div, the user agent notices this and fires a platform accessibility event. This event ultimately notifies, for example, a screen reader which then checks for a customization script for FooComponent_v1. This script might offer keyboard operation enhancements, instructions on how to work with a FooComponent_v1 or anything else really.

Like many innovations at the edge, I suspect this will empower exciting and perhaps unintended use cases.

Note: there is discussion about renaming templateid for the final ARIA specification. It is fascinating witnessing the web push the boundaries of how we conceptualize an "application", "module", "component", or "widget".

Thanks for reading.

aria-templateid explained

PLEASE NOTE: some time after this post, aria-templateid was removed from the draft specification by the W3C.

I wondered when an aria-templateid might be used so I asked Richard Schwerdtfeger.

Rich enlightened me using Gmail as an example, whereby Google could define a unique template ID URL such as:

aria-templateid="google.com/gmail".

Whenever an assistive technology (AT) sees this template ID it can provide customization to improve the UX. For example, a screen reader like JAWS or Orca could load a script for adding keystrokes to open the Gmail inbox etc. If another web product embeds Gmail the AT can still pick up the the template id and apply some customization.

Thanks Rich. This rocks.

Maybe what's most cool about aria-templateid is that we can think about tackling web accessibility in innovative new ways via customization.

Could we now essentially "Greasemonkey" the interactive DHTML web space, including mashups, for accessibility? I'll try to post my thoughts on this in the near future.

Well, that's enough for now. Thanks for reading.

Debugging JavaScript evals

Note to self... when debugging dojo in firefox... always check the script option: "Show eval() sources" in firebug.

You might need to check this after updating minefield and/or firebug.

Thanks for the reminder today Becky.

CSUN 2008 - my regrets

Sorry to everyone who missed me at CSUN this year. Life got in the way. Next year for sure!

Do bug references taint code readability?

Sometimes we write code that looks slightly odd or unpleasant, but it works around (or fixes) a bug, a bug which otherwise is perhaps beyond our control (e.g. some interaction issue with a closed source tool). We write the code as best we can to make it self documenting, perhaps adding a short comment to describe why the workaround exists. We write an automated test to protect against regressions. We refer to the bug # in the tests for easier forensics should things go awry. We are fashionable.

Yet we are still worried about someone coming along and shredding our unpleasant fix, forgetting about the regression tests, and reintroducing the bug.

Refer to a bug number in a source code comment?

How fasionable is that? I've googled but couldn't find much on the topic. I've seen it done quite a bit in the Mozilla codebase, and I'm inclined to think it has merit in some cases. I wonder what others think.

Anyway... this blog was inspired by a dojo meeting a few months ago. I let it sit unpublished for a while... until a time when I'm mentally exhausted and just don't care what blatherings I post...

Thanks for reading.

ARIA-ized Google Reader

Yes! Nice work T.V. and Charles!

Don't read this. Read the Official Google blog: ARIA For Google Reader: In praise of timely information access

Hmmm. I'd like to see more about how to best use AxsJAX for prototyping. Did you guys find getting things to work using AxsJAX and FireVOX covered things quite well? Or did you then find it a lot more work to get things to sound right with JFW and WE? I haven't really played with AxsJAX much but maybe I should?

Go Google Accessibility!

ARIA on Webkit's R(a)dar?

What does this mean: "rdar://problem/5785134"?

It appeared recently in a comment on the WebKit ARIA bug.

If it is an internal Apple thing how do we keep informed on the status? Tackling this bug would be a great contribution!

Be sure to check out: ARIA UA Best Practices by Aaron Leventhal.

Personalized UI Generation

Working on campus has its benefits.

On Tuesday I attended a talk by Krzysztof Gajos titled: "Automatically Generating Personalized Adaptive User Interfaces". It was nice to see some solid research being done in this area with particular attention to users who have a motor/dexterity impairment. Here are some of my notes which of course may have wild inaccuracies.

Krzysztof seems to have applied theory in mathematics and algorithms, particularly "decision theoretic optimization" to graphical user interfaces. I'm not talking about Fitt's law. Think: AI meets HCI.

For his problem space he considers 3 things to adapt the GUI to:
1. devices
2. preferences
3. abilities

And things to adapt, or "UI building blocks":
A. Layout
B. Widget
C. Structure
D. Size (this last one he added later in his research)

The context seemed to be mouse based interaction in graphical user interfaces.

Treating GUI design as an optimization problem he developed quantitative metrics and a cost function, essentially with weights to be applied to widgets. For those with an AI background his bag of tricks included: branch-and-bound search and full constraint propagation. The "cost" function I think of as a "utility" function (common in game decision AI). Oh and perhaps most wonderful to hear him say was that "deep down it is a constraint satisfaction problem". Yes! I'm sort of known for saying a lot of things boil down to a constraint satisfaction problem and some of my colleagues would have a good laugh about this I think. Anyways, this isn't about me and I've lost track of what this paragraph is for.

He spoke of the geometric concepts that arise from considering each UI preference an axis in a multidimensional space, and that each preference of one UI element over another is a hyper-plane in that space. Overall the 'shape' of the solution space of elements that solve the preference criteria is a polytope. Way cool stuff to think about at a high level.

He mentioned four elements of UI Design:
a. Perceived effort
b. Cognitive effort
c. Motor effort
d. Aesthetics

In analyzing ability, or motor effort, he optimized for time as opposed to preference:
cost(rendering(UI)) = time

So what did I take away?

1. People without mobility impairments found the time optimized generated GUI ugly.
2. Everyone was more performant using their generated time optimized GUI.
3. Krzysztof is someone to watch.
4. The biggest gain in performance was using a widget or widget set that required less mousery to manipulate, for example: a set of 5 radio buttons, instead of a combo box with 5 options.

Krzysztof really made his algorithms quick and it was interesting to see a demo of UI changing dramatically as he changed a constraint, such as screen size. The widgets, and widget hierarchy changed on-the-fly, for example, widget groups became tab panels in an auto-generated tab container.

But no spinning angry face. Sorry... inside joke.

Thanks for reading.