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.
