Problem: I want to track water conservation notices in my county, but ncwater.org does not offer feeds or alerts of any kind. It only has static HTML pages generated via form input.
Solution: My very own NC Water Management Dapp. I can now consume notices about water restrictions in an RSS feed, NetVibes module, XML doc, email alert, JSON, CSV, and about seven other formats.
I’d toyed with Dapper before. It sounded like an interesting concept: point Dapper to similar pages, show it what inputs generated that page, tell it what output is important on the page, and choose an output format for the scraped data. Admittedly, I shrugged it off. Why would I want to screen scrape a site? Doesn’t everyone provide RSS/Atom feeds, email alerts, text messages, etc. these days?
How easy I forget that not everyone is so tech-savvy. I can thank Google for making me so naive. “What do you mean I can’t get service X delivered in format Y to my device Z?!”
Anyways, now I see how truly useful Dapper can be. I spent about fifteen minutes teaching it:
- What input to use on the Check water use restriction status page
- What output from the county Water system summary page to scrape
- How to group the output information
- What output format to produce from the data
If you haven’t seen Dapper already, I recommend watching the demo or toying with it yourself. It appears capable of doing quite a bit more than what I tested today.
Three days off ahead. Time to cook some dogs and ‘burgs tomorrow, relax with Jackie and Zora. Then time to work on my thesis over the last two days of the week. I’ve spent entirely too much time hacking on mindtrove lately, but I’m happy with where it’s heading. I’m sure it has all sort of issues rendering in non-Firefox browsers since I haven’t had the willpower to enter the compatibility quagmire yet. But MochiKit sure is fun. :)
Now that the structure is decent, I think I’ll work on expanding the content, particularly the articles section. There are four on my wish list (+1 in my head) that I need to write down. It gets more important by the day as I start to forget all sorts of details about GNOME accessibility as PHP/JS/Dojo/Zend and Web accessibility start filing my head.
On the topic of forgetting, I just remembered that I still have some outstanding accessibility-related patches to commit for pyatk. They’re a first step toward making it possible for Python developers to implement accessible custom widgets (e.g., pycairo widgets). If you’ve got some free time and would like to hurry the work blocking meta bug #377642 along, please contact me.
Up early to mow the lawn and paint bookshelves for Jackie. Do shelves that hold bound paper count as a proper gift for a first anniversary? Four cases hold about 50% of our books. Dang.
For those who read this, I’m not longer working on GNOME accessibility projects for IBM. I’ve been transfered to the QEDWiki project, and may or may not have accessibility duties in the long run, but possibly some in the short term.
Nevertheless, I’m writing up some final documentation on LSR in hope that someone will find it useful:
- A patterns document stating ways to solve different problems using the existing Perk scripting sytem.
- A LSR in retrospect document starting what I would change, if I were starting over again today
I may work on making the latter changes myself in my spare time. I can see some usefulness is having a basic accessibility engine which I can use to script certain desktop actions or speech enable specific applications. For instance, maybe I want to listen to changes in a particular window (e.g. console with tail -f running, gaim chat window). Maybe I want some pre-recorded macros that perform a specific set of actions across applications that do not make their models public through dbus or another API. Or maybe I want a small toolbox window to augment an application with functions that aren’t immediately available in its toolbar.
I still plan on contributing to GNOME accessibility. I have some patches outstanding for pygtk that will allow widgets drawn with pycairo to become visible to AT-SPI clients (e.g. Orca, Accerciser, GOK). I just have to find time to work on them.
Q: Why a static HTML site?
A: I need a place to collect tutorials and such. I hate using a blog for that purpose.
Gary has solutions for two accessibility problems with Flash applications:
- Having to click on or mouse over a Flash embed before it receives other mouse and key events.
- Having no access to right click events in embedded Flash.
Yesterday, IBM decided to change strategies with respect to GNOME accessibility:
http://www-03.ibm.com/developerworks/blogs/page/schwer
Under this new plan, IBM is no longer supporting development of LSR, accerciser, pyatspi, AT-SPI::Collection, or Firefox/AT-SPI accessibility. These projects will not vanish, but the news does have an impact on each.
Accerciser
Eitan Isaacson is busy preparing Accerciser for inclusion in GNOME 2.20 under a grant from the Mozilla Foundation. Its development and documentation is far enough along that it should only require minimal future maintenance (i.e. bug fixes, updates to stay in sync with at-spi). As far as I know, Eitan plans to stay on as maintainer of Accerciser after the grant concludes. Even if Eitan does decide to leave, someone from the accessibility or automated testing communities could step up and take ownership over the code.
pyatspi
The Python bindings for AT-SPI are complete enough to power Accerciser today. Dogtail and LDTP are busy adopting them as well. Orca, as I understand it, plans to adopt them sometime in the GNOME 2.20 or 2.22 time frame. I will do my best to support pyatspi as problems arise until another member of the GNOME community is expert enough to own the binding. Since pyatspi is in the at-spi module, Li Yuan remains as the proper maintainer.
LSR
Development on LSR as a screen reader for GNOME will cease. We will make one last release of LSR 0.5.3 on Monday in line with GNOME 2.19.3. After that, the project will go dormant until various groups decide whether the LSR core will be used to drive other open source AT projects or if it will be abandoned altogether. Over the next few weeks, I will be updating and writing documentation in case the LSR core goes on to live in other projects. I will also reorganize the LSR wiki to de-emphasize the screen reader user content, and put the focus more on developer documentation. Contact me directly if you wish to discuss LSR.
Firefox and the Mozilla platform
Aaron Leventhal will remain the maintainer of accessibility for the Mozilla core. His priorities will now be: 1) ARIA support — Windows and Linux , 2) Firefox 3 accessibility regressions, 3) IAccessible2 and cross-platform issues.
Aaron will not be focusing on Linux accessibility support in the Firefox 3 timeframe unless it affects all platforms, API harmonization or ARIA support. The ATK/AT-SPI-specific support of XUL and HTML must now be via the existing community and module peers. Aaron will continue to be available to review bug fixes in those areas. Contact Aaron directly for details.
AT-SPI Collection
Ariel Rios has (or will) post his outstanding work on implementing the AT-SPI Collection interface. I’m not sure of his immediate plans, but he has expressed an interest in completing the work on his personal time. Contact Ariel directly for details. Documentation about Collection can be found at http://live.gnome.org/GAP/Collection.
—-
Personally, I am still extremely interested in accessibility and the GNOME desktop. The IBM decision means that I will no longer contribute to GNOME through my daily work, but I certainly plan to make contributions to GNOME as a hobbyist. In addition, I will gladly help anyone who wishes to develop or reuse any of the projects I worked on for the past two years. Feel free to contact me about them at any time.
Finally, I want to wish all the other accessibility developers on GNOME the best of luck. Keep fighting the good fight of making free software accessible to all those who want it.
Some prep work for the Monday release of LSR 0.5.3. Crunched some outstanding bugs with the event dispatch and method chaining optimizations I’ve been doing in the core. Everything seems to be running smoothly now…
But this too shall pass.
Spent the rest of the day in a haze of phone calls, emails, and IMs. More on this frenzy soon enough.
