I’m sure I don’t have to remind any readers of this blog that there are many considerations to make when first developing software.  It can be difficult to design so called idiot-proof software, and software that can adapt to the user from the most novice computer user to the greatest software engineers.  If there is a wide variety of users that you are targeting with your software package, trying to balance a friendly user interface can be a challenge.  There are also considerations to make when it comes to accessibility.  Not only should the final product be accessible and screen reader friendly, but the software development process is another consideration.  It is important that this development process be accessible to any programmer that might be blind or visually impaired.

Typically the software design phase is a very visual phase.  Actually, visual tools often come into the picture much earlier than that (yes there was a pun intended).  So how does a person who does not benefit from wonderful tools such as UML diagrams deal with this challenge?  This is actually quite pertinent to the computer science course I am taking right now.  In this course we are essentially developing a software product in one full semester, starting with the requirements phase and continuing all the way through the implementation phase which is what we’re doing now.  Our solution to date has not been all that creative.  That is, I deal with the visual aspects of development by, well, not dealing with them.  While there are a number of visual aspects, there are also parts of the development that are not so visual, and my responsibilities were primarily to focus on the non-visual aspects.  For example, I might work on writing a use case description document for our software, while someone else in the group draws the corresponding diagrams that accompany the descriptions I wrote.  The professor I have for this course has also not focused as much on UML as I originally thought she would.  There was only one question on our midterm that required us to draw a UML diagram, and she allowed me to describe the diagram rather than draw it.  So even though I may not be drawing diagrams, that doesn’t mean that I’m not responsible for knowing how each diagram is used and how to describe one.  I may not be describing it in terms of triangles, boxes, arrows etc. but I am still describing it.  I thought this was a reasonable modification for a few reasons.  First I am exposed to the uses that UML has and I still have the knowledge of how to communicate what I want.  Second, if I had to draw a diagram I’m pretty sure I would fail quite miserably at it.  You might be thinking that the whole purpose of a graphical language such as UML is so we don’t have to describe things in words.  After all, who wants to read about the design of a class for a program in a 10-page document that covers every class component in agonizing detail?  The reader will surely be comatose before the third paragraph.  This is probably why I will not be given the task of drawing up UML diagrams any time soon.  Communication through diagrams is quicker in general, but I contend that there is more than one way to skin the cat.  I think the reason visual tools such as those that we have in the software development cycle are so popular because so many people are visual learners.  I could be way off target in saying that so I hope I don’t get too many readers offended.  I don’t believe that a fundamental property of the software development cycle is that it is visual.  I think we make it that way because most people think it is more convenient and yes, it is probably more efficient in some ways.  This may be a case where accessible UML creation software comes into play (I don’t know of any UML software that is usable with a screen reader to date).  When it comes to me interpreting diagrams this is a bit of a different issue.  Since I am not a visual learner I think I’d rather read a description of a software design rather than try to get someone to describe a diagram to me.  For me, words have more meaning in a context such as this than diagrams do.  I will concede however, that I have never been involved in a major software development process before, and the software projects I have worked on thus far have been relatively small.  Therefor, it’s quite possible that I simply haven’t yet realized the full benefit of these visual tools.

I should apologize for the lack of a good blogging schedule.  Truthfully, I’ve been a bit busier than I would like to be and it makes it hard to find the time not just for blogging, but to get the amount of research done that I intended.  I’ve had grandiose plans for writing python scripts for the mac as I mentioned in a previous post and some other cool things.  This hasn’t happened yet, mostly because I haven’t found a whole lot of documentation on the subject.  I found plenty of tutorials on learning apple script which at least for the time being doesn’t interest me that much.  My original request for a how-to on writing scripts for the mac still remains.  A document that has an emphasis on VoiceOver would be even better.  Could I be so lucky?

Anyway, since I’ve essentially been learning two languages this semester I thought I’d describe some of the work that is involved in learning a programming language from a blindness prospective.  We are obviously using python for this particular project, but I am also learning C++ in the CS course I am taking this semester.  For me, learning language syntax is one of the easier tasks.  I think I share the sentiments of many others that once you know 1 language it makes it easier to continue to another because thankfully, the structures are very similar in all languages.  I suppose the tricky part is making sure I have the necessary resources to start exploring the given language.  This usually consists of documentation of some kind.  Unfortunately the selection of pre-recorded texts is limited, and brailled texts are even more rare to come by.  If there is a required textbook say, for a class, the publisher in question will usually release an electronic version of the book as long as one has purchased a hard copy of the book.  This process of releasing an electronic version can take a few weeks while your request is processed, so it’s a good rout to take if you know in advance what is needed.  This is why it is helpful to obtain the names of textbooks as early as possible.  Anyway I digress.  In a lot of ways I think having electronic versions of the text is more convenient than say, an audio recording of the same text.  This is because I’m usually at my computer when I’m looking at programming documentation and I use it as a reference.  A pdf version makes it easy to look up syntax quickly and then I can simply switch back and forth between the textbook and my work environment.  It is relatively easy to switch between windows on a computer logistically speaking, so it is not uncommon that I have 10 or 15 windows opened at a time, particularly when I’m writing a program.  I suppose this can be compared to someone sighted who might keep a python reference guide on their desk opened to the relevant page while they type.  By the way, I’m assuming sighted people actually do this; I wouldn’t know for sure, and I don’t want to sound too presumptuous.

The other part of this discussion that deserves attention is text editors.  When I first started writing simple programs I really preferred editing with regular old notepad that comes with windows.  While it is really a no thrills solution it was good enough.  However now it is not uncommon for me to be dealing with lots of files at once. Thus, I’m learning to appreciate IDEs a bit more.  I’ve been using visual studio in windows and have started exploring x-code on the mac.  For python however, I still just use a text editor most of the time since my programs are still somewhat simple.  While notepad works fine, I’ve used notepad++ a bit too and it also seems to work reasonably well from an accessibility prospective.  One thing I noticed is that, because of the automatic syntax highlighting that notepad++ does by default, it can sometimes confuse screen reading software when trying to determine what text is selected.  Many screen readers rely on the highlight color of the text to determine what text is selected for manipulating.  This would include deleting, cutting, copying etc.  I found that it’s best to turn off syntax highlighting if you are a screen reader user.

On a closing note let me just say to Please feel free to leave comments if there are any questions; it may give me an idea of topics I should cover in future entries.

I’m now convinced that I’m blogging to myself here, but what the hell.  My printer arrived today.  I’ll start building it next week.

As I reported in my previous entry, I recently bought a Macbook Pro.  For the past week or so I’ve been learning the essentials of using that system and thus far it has been a pleasant experience.  Most applications that are preinstalled such as iTunes, Safari and the email client are very accessible right out of the box.  In addition I’ve downloaded Skype as well as some other miscellaneous apps that work really well.  Not only is the UI very usable from an accessibility standpoint, but the Mac also provides a very accessible approach for using the power of unix commands in the terminal window.  In that sense it really gives the best of all worlds.  I’ll just go into a quick explanation of some of the accessibility features on the mac.

Apple has implemented a screen reader called VoiceOver, which is built into OSX 10.4 and higher.  The fact that it is built-into the OS has some interesting implications.  First, there is no screen reader installation process; you can simply walk up to any mac and press a hot-key and immediately have speech access to the OS.  Second, the installation of OSX is completely accessible and there is speech feedback during the entire install if needed.  This is something that is long overdue in Windows.  Currently there is no way to completely install Windows from start to finish with speech.  Some people have found ways around this such as using automated install procedures, but this does not account for the exceptional situations when an error may occur during the install.  Unlike windows where there are multiple 3rd party screen readers to choose from, on the mac VoiceOver, the built-in  screen reader is the only one currently available.

To tie this into more project-relevant subjects, by the end of the week I was able to test a python script on the mac which worked very nicely.  One thing I am interested in is writing scripts for VoiceOver, as I have a few ideas for some useful VoiceOver scriptlets.  According to the getting started with VoiceOver documentation, not only is VoiceOver scriptable with apple script but also pearl, ruby and python.  I thought this would be a good way to implement some of my ideas as well as practice some python skills.  The scripting documentation for VoiceOver however, does not seem very extensive, or maybe I just haven’t been looking in the right places.  If anyone stumbles across some good scripting documentation for VO or the mac I’d definitely be interested.

This week Stephanie and I continued to play around with image manipulation. We were pretty excited when we discovered the concept behind changing the background of an image. This meant that we could put George anywhere we wanted! Even on Zon (the Sun)!

The white background of George was replaced by another image.

This background swapping is done by comparing and image to another image that is the background of the original. If a pixel’s color differs by a certain designated amount, then that pixel is assumed to be part of the background and then changed to the corresponding picture of another image, the new background.

The next idea that was played around with was scaling. For simplicity, assume we are shrinking the image to half its original width and height. Then a new, empty image is created whose measeurements are half the size of the original. Then every other pixel on the original image is placed in successive positions in the new, smaller, image.

Following this method, we created Little George:

Which you can see is much smaller than original George:

Next we played around with placing images on top of one another. We were able to get Little George on George: