If you’re not a software developer or don’t really understand the art of programming, I suggest you skip this post, because it probably only will cause confusion. If you do know something about software development, sure, read on!
The next pVoice version will be different. Very different. In fact, pVoice will no longer be developed as a standalone application, although I think I will eventually create an installer that gives you the same functionality as the current pVoice gives you.
Instead, I’ll first design and create the OpenAssistive framework. Before I “paused” the development of pVoice, I had already started the development of OpenAssistive, which -at the time- was supposed to be a wxPerl based framework for assistive software. Here’s the shock: neither pVoice nor OpenAssistive will be based upon wxPerl!
For all of you who know me, and who know how enthusiastic I have always been about wxPerl, this must be a big surprise. It is for me as well 
Instead, the OpenAssistive framework is something I hope will be so simple in design, based upon open standards like AJAX, HTML and HTTP, that really anyone with a little knowledge of webdevelopment, can contribute to it. In the past, many people suggested to use HTML for pVoice. “A simple webpage should do the trick”. Yeah, but not quite. There are a couple of things that “simple webpages” cannot do:
- Switch input. That’s the most important issue here. Switches like the buttons of a mouse, or keystrokes can be caught with Javascript. However, if you need to interface with special devices, like wheelchairs, you need to be able to access local devices, which is not that easy (if possible at all) via Javascript
- Speech synthesis. Until recently it wasn’t possible to do Text To Speech on other platforms than Win32 in an HTML page. I’ve found a page last week that defines a project using the Java Speech API, and adds Text To Speech capabilities to any webpage on any platform. At this stage I’m not sure I want to go with that.
The basic idea of what the OpenAssistive framework is supposed to do is the following:
- A HTTP daemon will be the heart of the framework. Sure, you can use your own flavor of HTTP servers. But this daemon will run on the local machine and knows how to do Text To Speech. If you use Apache (or other HTTP servers), the framework will still do its job, but Text To Speech capabilities will not be available. That is not a problem per se. If you don’t need TTS, then you’re fine using another web server (remember, it’s a framework, not only pVoice will run on it…)
- An Event listener will listen for events coming from the switch device as configured. It will send those events to the HTTP daemon. That can be done using IPC, or if it’s a distributed setup, also via XML calls to the HTTP daemon.
- The user interface will be any webbrowser. And when I say any, I mean any. It just needs to be able to work with AJAX-based pages. These pages will constantly poll the server for events from the Event listener, and highlight the selectable items in the HTML page. Selectable items are marked as such using a CSS class. Highlighting and returning to a default state is very easy within CSS. When there’s a “NEXT” event coming in, it highlights the next selectable item in the page, the same with “PREVIOUS” and “SELECT” takes the defined action.
- A module in the OpenAssistive framework can consist of only HTML and Javascript, but it can also be much more complex by adding server side scripts, allowing you do do almost anything.
This is the basic idea. I’m already doing some proof of concept, and so far I see no reason why this won’t work. It’s much more flexible, requires no “hard to find skills” like wxPerl programming, and if I’m not mistaking, the development will be much faster than before.
Comments are welcome!
