Starting KTypeFri, 17th Sep '10, 12:05 am::

For some time now, I've been looking for a good way to build a system to help people with speech/neurological disabilities communicate better and tonight, I found it. After my cousin Keval from Mumbai got in an accident over six years ago, he lost his voice and motor skills. Over the years, he has gained some control over his right hand but it is not enough for him to type on a keyboard or use a mouse. It appeared from some videos that my sister sent me last year that he might be able to use a touchscreen to push digital buttons so I decided to look into developing a software/hardware system customized for him.

I created a rudimentary on-screen keyboard that helped guess what he was trying to type, a "smart" version of the T9 typing-mode on cellphones. I called it KType and it used Google's AutoSuggest feature to "guess" what the next word or phrase would be. That it was a good idea was confirmed when I recently ran across Google Scribe - a simple demo that works on the same principle (and uses the same Google data-source) as KType but offers a different user-interface.

I sat with Keval for many hours during my recent trip to India to try and figure out what kind of system would work for him. Last month, I met a friend's brother who has a neurological disorder that prevents him from speaking and makes motor control very difficult. I know I shouldn't extrapolate too much from just two people's requirements but I know that if I am able to make something that works for both, it will most certainly work for a hundred others, as there are many people who have problems speaking and using general-purpose electronic devices to communicate. With all of this in mind, I started to build a list of requirements for the hardware and software platforms that I will use for the next generation of KType.

The hardware I need to use will:

  1. Be cheap and affordable: After all, health-care is expensive as it is. No need to make software that only runs on $10,000 machines. Maximum hardware cost: $1000, prefer to be: under $500, sweet-spot: sub $300.
  2. Be available throughout the world: If not immediately, then within a year or two at most. No NASA rocket parts, only commodity hardware.
  3. Have a touchscreen: It can be used as the primary input or as the configuration panel.
  4. Have good audio out: Will be required for text-to-speech.
  5. Be connected: Wireless required, Bluetooth highly desired.
  6. Integrate with other devices: I may need the ability to integrate with joysticks, hardware push buttons, HDMI monitors, and other I/O devices.
  7. Run on battery and for many hours: So the user can be mobile.
  8. Easy to reset: 9 out of 10 errors should be fixable by turning the device off and on again.
  9. Relatively easy to program: This is very important for me because I don't have five years to code patiently. I want to give a working KType device to Keval yesterday.

The software I need to use will:

  1. Be free from licensing issues: I want everyone to use KType without any restrictions.
  2. Work on multiple hardware devices: I want to write once, deploy anywhere. I am not building a high-performance, finely-optimized video game. I just want to make code that works and is stable, even if it's not "perfect".
  3. Allow users to update to latest version: I don't want to manually upgrade all the devices. Ever.
  4. Perform low-level hardware-functions is necessary: If I want to create a wireless network between my selected hardware device and a webcam, the end-user shouldn't have to deal with complex configuration. I want the ability to create an ad-hoc wireless network dynamically in code.
  5. Exist today in usable form: I'm not going to wait for Apple, Google, Microsoft, or Adobe to release their latest and greatest SDK before I can start coding. I need to get started right away.
  6. Be fast: While initially I'll do simple things like easy-to-use on-screen keyboard, I have plans to do some very CPU-intensive processing in the future. So I can't really develop in QBasic.
  7. Have an extensive set of libraries: I don't want to reinvent the wheel. I want to use the most advanced wheel freely available today.
  8. Not be a fad (i.e. be around for a while): I plan on working on KType for the foreseeable future. I can't start to code it in Erlang and find that the flavor of the day is Clojure or Ruby. Last thing I want to do is a complete rewrite. So the software platform I decide to use, better be around for a long time.

Having mulled these requirements over and over in my mind for the past few months, I was starting to get disappointed that I couldn't find a viable software/hardware solution. While the Apple iPad definitely met most of my hardware requirements, programming for it in Obj-C hardly fulfilled my software requirements. Finally tonight, I came across AirPlay - a software development system that will let me write code in C/C++ and run it on a variety of hardware devices, including the iPhone, iPad, and Android devices. Though AirPlay may not meet every single software requirement immediately, with the iPad expected to get some competition in the coming months from the likes of Samsung Galaxy Tab and Archos Tablets, I think making a cross-platform software that would work on any of these devices will be the best solution for me and my users.

I started to play around with AirPlay tonight and I'm definitely excited. My iPad is setup and ready to be programmed. Can't wait!

 < Aug 2010Oct 2010 >