Congrats to all who contributed to ensuring Assistive Technology can provide a good user experience on Windows.

Community is a part of Open Source that fascinates me more and more, perhaps a natural development process as I'm increasingly interested in the people as much as the code.. It also appears to be one of the more complex and uncertain aspects of a maintaining successful Open Source project (another is creating a sustainable business model.

It's good to be able to finally meet OSS Watch who have for many years been promoting Open Source in HE/FE. While this complements the work of schoolforge.org.uk in the compulsory education sector we are very different groups. SF is a loose collection of people interested in Open Source and OSS Watch is a JISC funded organisation. However we all have a commitment and firm belief in the good match between Open Source and Education and both have helped many realise the benefits of using and creating open source and being part of a community. I hope Monday will be a chance to forge better links between us.

I've just notice that Mozilla Labs will be in London on the same day and it will be a great shame ot miss that as Mozilla are so good at community, as well as fostering innovation

Now web authors can include media without requiring users have plugins or proprietary players.

$700bn is roughly twice the amount needed to lift everyone in the world out of poverty.

Full details on the RAatE website and there are a few places left.

The initial requirements made it clear that communication, web access and web integration were a critical part of the concept and Simon Judge had already sowed the idea that a browser based solution might well be workable. I've previously felt Mozilla's platform (as used to make Firefox, Thunderbird and several third party programs like songbird and Miro) could be great for certain assistive technologies and Mozilla's funding or my work on Jambu had allowed me to get a clearer perspective of Mozilla development, 'warts and all'. So it was that Mozilla tech was used as the key technology.

Mozilla

I had a couple of agenda's of my own and in addition to wanting to use Mozilla technology I also felt it was important to use familiar and light technologies to encourage a wide community of contributors. So it seemed sensible to leverage the simpler web technologies to allow people to try out and share ideas, and hopefully something of the viral nature of web development will eventually take place. So initially I thought I would use XUL + HTML + CSS + Javascript and these would also allow flexible deployment possibilities, including perhaps a browser-only solution. However technical  complexity (or lack of experience) and rapidly vanishing time meant I changed to dropping HTML and using XUL only.

Early experiments in using Firefox in a kiosk mode eventually gave way to XUL Chrome windows running full screen but a legacy is that Maavis is currently a Firefox plugin where a XULRunner application might be more sensible and have less 'issues. There are issues with profile use to resolve, especially when user are using FF a a browser as well as Maavis.

The main area of difficulty was that were are rather fighting against the XUL layout (box) model which works rather 'inside out' flowing around content. Maavis wants to work 'outside in' and defines boxes while it scales/clips content to fit. I'm sure there are ways and means that I have not yet discovered but currently using timeouts to substitute for the lack of rendering events or hooks feels like a bodge and there are still odd drawing problems to resolve.

XBL provides a nice way to create more abstract widgets and is used for the buttons, media players and slideshow. At times the Javascript binding is a little confused and debugging can be time consuming but it works very well.

XPCOM components created in C++ provide a way to extend Mozilla and access platform services. This has been done for process control, window z-order management, synthetic speech and volume control. These components are currently Windows specific but can be made cross platform in future. Indeed they isolate much of the platform dependence, and important point as I plan for this to be on Linux and Mac too. Development here can be tedious due to long build times of Mozilla but here are ways to reduce this. Standard XPCOM components are also used, mainly for file and URI manipulation.

Mozilla's Javascript modules are used heavily as they give reasonable encapsulation and module control, better than is available in raw browser hosted JS. However syntax errors are often not generated so debugging can be a painful 'binary chop' affair at times. The availability of modules has given the architecture a package/module flavour more than object oriented. But then most objects are singletons and I'd prefer good encapsulation to complex class hierarchies any day.

Dojo

I intended to use the module and class features of Dojo or an equivalent but in the end felt they were unnecessary once Mozilla's modules had been discovered and the design began to take shape.

There was also an intention to use the data abstractions of Dojo and JSON to allow config to be local or remote (and async) but in the end this gave way to a simple local folder scheme that allows facilitators to easily configure by copying files into predefined locations. I expect this to get reinstated at some point as web service integration means config becomes more complex 'under the bonnet.

VOIP and Skype APIs

Skype was chosen for it's API (Ekiga's was not obviously suitable) and ubiquity. However I hope this is temporary as I want to use an Open solution and while we really only want Skype to be a VOIP server, it insists in putting it's UI in the way. I tried using the Skype4COM API from a XPCOM component but it fails, I'm guessing due to to it being windows message based and needing a message pump.

In the end I used a fork of the University of North Carolina's Outfox Firefox add-on which talks to a Python server from XUL via sockets. The Skype4Python api is used though I guess Skype4COM would have worked via Mark Hammond's snazzy COM automation client code. Having a python server really opens up the possibilities for what we can integrate with Maavis so I'm not unhappy about the extra work and complexity (well not now, I have got something working). Indeed it might be a way to get asynchronous speech going and use a free speech engine.

Bar far the largest amount of time was spent on Skype integration, which in hindsight is not surprising as it is a fairly complex product and state machine. However they could make life much easier.

VLC media player

Though I looked around and tried the mediaplayer and mplayer plugins for Firefox the VLC is easily the best choice. It's cross platform, mature and works well with many media (though not Real). I did try just installing the FF plugin silently but in the end problems led to requiring a full install for now. The api is well documented once you find the right pages.and does most things you could want (but not all). I wrapped it in a XBL component.

INNO setup

Trusty old INNO setup is AFAIKS now on a pukka open source licence. I'm a fan of it's simple declarative style, but did have to use some Pascal scripting this time as well (which took me back a few years). The code was needed to overcome the limited Firefox api for managing profiles.

So that's the main technologies used and hopefully some insight into the whys and wherefores.