Happy Monday from Bangalore! Apologies for not posting over the weekend, but as usual, our Internet connectivity was more or less non-existent. We had a really nice weekend however. On Saturday we went to an art gallery, Gallery Ske, and then later saw a local band, PARVAAZ. On Sunday we got up bright and early and traveled to Mysore, which is about a three hour drive southwest of Bangalore. It is a town mostly built around the Mysore palace, and was a very nice place to spend the day. Avia achieved her lifelong (or at least India-long goal) of riding an elephant, and rivaled–and quite possibly surpassed–a 12 year old girl meeting Justin Bieber in her excitement levels.
This past week was a short, but good one at work. It was short because halfway through the week I got fairly sick (just a fever–nothing too bad), and spent a lot of time sleeping. I’ve been feeling much better since Friday however, and have been working at night some to try to make up lost time. I was able to get lots of things accomplished that I had wanted to get done though. The biggest thing that I wanted to get done was adding support for multi cell Braille characters. For those of you who are perhaps unfamiliar with Braille, there are 6 cells to indent, which makes 2^6 (64) possible one cell characters. The Hindi and Kannada Braille alphabets have more than 64 defined characters, so a select few are represented by two adjacent cells of dot patterns. Additionally, some math symbols require more than one cell. The Braille Writing Tutor software as it was was not able to accommodate these character (as English, French, and Arabic alphabets are relatively short) , so my job this past week was to make it possible for users to enter multi-cell characters and to have the tutor react appropriately.
This presented several interesting challenges from an implementation perspective. The first was the tradeoff between the ease of adding a new multi-cell character and how much of the code’s general structure would have to be changed. If we had unlimited time, I would have liked to restructure how the characters were read in, so adding a character that required two cells would be as easy as adding any other character. However, since we are only here for another 3 weeks, Vivek and I decided that given multi-cell characters are rare and the fact there are a lot of other enhancements we’d like to make, that it would be best to make it more involved to add a new multi-cell character from a developers point of view, and move on to other features. (For our technical readers who might be curious, to add a multi-cell character right now, you add it as a struct with the character, how many cells it takes, and an array of the bitmask of the Braille pattern, and add it to a vector of such structs). The second interesting challenge that this addition poses is the how the tutor should actually instruct the user to enter it, and which series of buttons the user should press to “move” in between the cells as they write. As of right now, when teaching the letter, the tutor alerts the user that the character is multi-cell, and then instructs cell by cell. We will test this with students and teachers later in the week or early next week, and see if they like that way of entering things, or if they have other ideas for what would make more sense. I really have been enjoying that we’re working so closely with our end users, as we can get concrete feedback very easily rather than having to guess at what would be the best ways to do things.
That’s all for now, thanks for reading.