SIGNWRITERRichard GleavesValerie SuttonDeaf Action Committee for SignW - PDF document

SIGNWRITERRichard GleavesValerie SuttonDeaf Action Committee for SignWritingCenter For Sutton Movement WritingLa Jolla, California, USArgleaves@signwriting.org sutton@signwriting.org AbstractThis paper reviews the design history of SignWriter, aword processor for the SignWriting system. While theprimary goal of SignWriter was simply to create a wordprocessor for SignWriting, its development andsubsequent use had several beneficial effects on theSignWriting system. Various design aspects ofSignWriter of illustration rather than a true writing system. Thereforean efficient typing mechanism would cause SignWriter toserve as implicit proof that SignWriting was indeed aform of writing.It was evident that SignWriting's complex symbol setwould prevent it from being typed as efficiently as theRoman alphabet on a standard keyboard. However, thedesign that evolved - which involved the context-sensitive dynamic redefinition of the keyboard keys -yielded a valuable tradeoff of efficiency for learnability.The key boxes displayed on the screen highlighted thenatural categories of the SignWriting symbols in amanner that allowed the typing mechanism to serve as animplicit learning tool: a crucial property given the symbolset complexity and the application's intended audience.See Figures 1, 2 and 3 from the SignWriter-At-A-GlanceInstruction Manual.The SignWriting symbol images were created by ValerieSutton using the SignWriter symbol editor program. Inaddition she defined the mapping of SignWriting symbolsto the keyboard keys. As with the key boxes, thismapping emphasized learnability by grouping symbolsaccording to their natural categories. Conversely, themapping of the key box keys and symbol attribute keys(Arrow, Cursor, Mirror, Size, and Rotate) was determinedstrictly by typing efficiency.SignWriter's Find and Replace commands wereimplemented (at significant expense in memory) both toestablish SignWriter as a complete word processor andagain to demonstrate SignWriting's status as a truewriting system. Unfortunately the search algorithm didnot take into account the relative positioning of symbolswithin a sign, thus making the search feature itself moreof a demonstration than a useful tool.Because SignWriter was developed as a stand-aloneapplication, it was free to possess an application-specificuser interface. The interface design was influenced byTufte's principle of graphical minimalism [Tufte83]:namely, every pixel that was not part of a SignWritingsymbol existed onscreen only because it was functionallynecessary. While this design approach may seem austeregiven today's large color displays, it made for a simpleand easy-to-use interface on the Apple II, which had ascreen resolution of only 560 by 192 pixels.The major drawbacks to SignWriter's interface designwere the inefficient cursor movement commands and theneed for a keyboard card showing the assignment ofSignWriting symbols and commands to the keys.The Apple II version of SignWriter supported the fullSignWriting system as it was defined at the time (palmorientation had not yet been introduced). The softwarewas quite usable, but was never widely used becauseexperienced SignWriting users had to type in eachoccurrence of each sign, while for new users typingsymbols was relatively inefficient and Ð in the absence ofa system for teaching typing Ð posed a significantlearning curve.SignWriter DOSBy the late 1980s the IBM PC had replaced the Apple IIas the personal computer of choice. SignWriter wasported to the IBM PC with programming assistance fromBarry Demchak. We chose the CGA display modebecause at the time it was the graphics display modesupported by the most PC models, and because its screenresolution of 640 by 200 pixels was close enough to theApple to simplify porting the existing symbol graphics tothe PC (which is why the SignWriter symbols are sojagged).The extra memory available on the IBM PC allowedSignWriter to be expanded with additional symbols, asign dictionary, and support for multiple countries andlanguages. These features (along with softwaredistribution on the Internet) had a significant impact onSignWriter use, as researchers began using SignWriter tocreate and publish dictionaries for various signedlanguages. This is the version of SignWriter that is incommon use today.Effects on SignWritingThe purpose of SignWriter was simply to provide a wordprocessor for the SignWriting system. However, itsdevelopment and subsequent use had several beneficialeffects on SignWriting: É SignWriter offered a concrete proof of SignWriting'sstatus as a systematic notation rather than an ad hoc formof illustration. This notion influenced the subsequentdesign of the software. É The typing mechanism served as an implicitinteractive system for learning the SignWriter symbols(an important achievement given the complexity of thesymbol set). É The SignWriter symbol editor was withheld fromdistribution to ensure the controlled development of the 8 SignWriting system as it evolved to support more andmore signed languages. É The constraints of computer implementation exerted apositive influence on the subsequent evolution of theSignWriting system. É The SignWriter software itself served as an efficientmeans of distributing the SignWriting system, andestablished a de facto standard for data exchange (aneffect greatly amplified by the introduction of theInternet). ConclusionBeyond its immediate value as a tool for practical signprocessing, SignWriter offers a number of lessons forcurrent and future developers of sign processing software.The most important is the need to standardize a userinterface mechanism for symbol input; just as the symbolset is being standardized across all sign processingprograms that use SignWriting, so must symbol entry.Such a standard should be centered on typing, withmouse input as an alternative rather than a replacement.Compelling pedagogical and linguistic reasons exist forproviding efficient input mechanisms at the level ofsymbols rather than signs; while such mechanisms neednot supplant text entry at the sign level, the reverseequally holds true.The diagrams in this paper illustrate SignWriterÕs typing-based symbol input system as an example of how futuretyping-centered systems could be designed.With regards to efficiency, Valerie Sutton has learned totype SignWriting almost as efficiently as English. Thissuggests that with the proper training (an accepted normfor typing) and appropriate hardware (e.g., a notebookcomputer with an integrated touchpad for cursor controland fine symbol positioning), typing-centered symbolinput may well prove superior to any mouse-basedsystems.Finally, SignWriter demonstrated that with theappropriate software architecture a true word processorcould be implemented for SignWriting given limitedresources for memory, processing power, and displayresolution. This in turn suggests opportunities fordeveloping useful sign processing software on theemerging handheld computing platforms such as PDAsand cell phones.References[Bowles78]Bowles, Kenneth L., "UCSD Pascal", Byte. 46 (May)[Newkirk87]Newkirk, Don, "SignFont Handbook", San Diego:Emerson and Stern Associates (1987)[Tufte83]Tufte, Edward R., "The Visual Display of QuantitativeInformation", Graphics Press (1983)[Sutton93]Sutton, Valerie. SignWriter-At-A-Glance InstructionManual, SignWriter Computer Program Notebook,Deaf Action Committee For SignWriting (1993)[Sutton04]Sutton, Valerie. SignWriting Site. www.signwriting.org 9 Figure 1: A page from the SignWriter-At-A-Glance-Manual. Symbol groups are under each key. 10 Figure 3: A page from the SignWriter-At-A-Glance-Manual. 17 countries with 17 fingerspelling keyboards. 12