A Graph Description Language for Blind Programmers

1. A Graph Description Language for Blind Programmers Dale Parson, Genevieve Smith, Andrew Wernicki - Kutztown University PACISE 2017, Edinboro University of PA

2. The Problem • Our graduate course in advanced object-oriented analysis and design makes heavy use of Unified Modeling Language (UML) diagrams. • Our blind student author (Genevieve Smith) needs ways to read and create UML diagrams. • Tactile diagrams of textbook illustrations take too long to internalize and are cumbersome to create. • One diagram can span multiple pages. • She can use the JAWS text reader to capture and debug code with amazing speed!

3. Solution: Make a Graph Description Language • UML diagrams are mostly boxes and other graphical containers with visual links, tagged with text. • Use { paired curly braces } to delimit containers. • Use UML keywords for most of the text. • Borrow Java keywords, such as “implements” or “extends”, for textual counterparts to graphics. • Invent keywords only when absolutely necessary. Make them short and descriptive. • Use a Python-based parser generator PLY.

4. A Visual UML Class Diagram

5. Abbreviated Textual Class Diagram class Customer { // Indentation is optional. It slows reading. name [1] ; address [0..1] ; getCreditRange() : String ; } class CorporateCustomer extends Customer { contactName ; creditRating ; creditLimit ; billForMonth(Integer); remind(); } [*]uses[0..1] "salesrep" Employee ;

6. Diagram generated from text for communication with colleagues

7. A Visual UML Sequence Diagram

8. Abbreviated Textual Sequence Diagram object anOrder : Order {} object anOrderLine : OrderLine {} object aProduct : Product {} object aCustomer : Customer {} ? calls anOrder.calculatePrice() ; anOrder.calculatePrice() calls anOrderLine.getQuantity() ; anOrder.calculatePrice() calls anOrderLine.getProduct() ; anOrderLine.getProduct() returns aProduct to anOrder.calculatePrice() ;

9. Pitfalls and UML Extensions • Avoid visual symbols such as “->”, “<-”, “<->”, and “--”. JAWS reads them as punctuation. • We invented keywords new keywords “uses”, “usedby”, “useboth”, and “usehuh” for these. • Nesting curly braces and Java keywords “package”, “static”, “implements”, “extends”, and others are known to most programmers. • Other diagram types require more keywords.

10. Usability • We settled on keywords that work with JAWS. • In-line comments and brevity work well. • Coding experience minimizes learning load. • Blind developers can create and read UML diagrams independently. • No need for sighted assistant in the workflow. • No need for long waits for tactile diagrams. • Indentation is optional; it slows reading.

11. Additional Usability • Using JAWS is time-effective and cost-effective for developers who already use it. • Typing text is much faster than drawing tactile diagrams. • Some sighted programmers find graph descriptions faster and more intuitive. • There remains the need to build & maintain a mental map for blind developers. • Back end generates indented and un-indented descriptions and visual graphs.

12. Conclusions • Textual UML for analysis of existing designs sped acquisition of design structure and behavior significantly. • Textual UML capture also much faster and more reliable than tactile punches or rubber band and pin boards. • Iterative prototyping identified feature improvements as the course progressed. • Several sighted students preferred this approach.

13. Future work • The round trip between visual and textual graphs is partially complete. • We can generate image files from text graphs. • Available open-source tools are not modular and are more difficult for blind programmers than readers that they already use. • A visual graph editor that supports tagged graphs, and text-to-graph conversion. • What we already have works well for communicating with colleagues.