In a nutshell

Our project for Fall 2008 is to create a soundscape map of the Oregon School for the Blind and update a soundscape map of the University of Oregon campus. Both maps (and this is the key thing) should be generated from geographic data using the exact same process, so that in principle what we will have is a system that could produce many other soundscape maps from GIS data, using a style sheet to attach sounds to geographic objects and the map.

Background and long-term goals

Blind people need maps as much as sighted people, maybe even more, but ordinary printed maps and typical electronic maps (like Google maps, Mapquest, etc) require sight. Tactile maps can substitute for ordinary paper maps, although they are not yet widely available. Soundscape maps — that is, maps that use sound in place of lines and colors — may be a way to make electronic maps that are accessible to blind users.

Research on soundscape maps is relatively new, and only a few research groups around the world are actively working on them. It is not really known whether sound can be an adequate medium for communicating map information, or what interaction techniques with sound will be most useful for blind users. Many cycles of design and evaluation will be needed before we can provide an efficient means to produce maps that use sound (and perhaps other stimuli, such as haptics) that blind users find effective and pleasant. Currently that cycle is slowed by manual steps in map construction, such as associating sounds with each object on the map. An important near-term goal, then, is to automate those manual steps so that soundscape map researchers can quickly try new ideas and perform usability experiments.

Long-term goals

The ideal system we want would be modular and extensible in two regards. First, as much as possible of the design of a particular soundscape map should be controlled by style sheets that can be written and modified by map researchers, quickly and without assistance of a computer programmer. For example, if a researcher wants to test whether musical or non-musical tones are more effective as map symbols, it should be a quick and easy job to produce two versions of a map that differ only in that characteristic, just by changing a few lines in a style sheet and then re-generating the map. Separation of presentation from content should also make it easier to generate several different maps with the same sound presentation decisions, just as a CSS style sheet makes it easier to create a set of web pages with a consistent style. Second, the architecture of the map system should also make experiments that do involve programming as easy and independent as possible. For example, if larger screens with touch (haptic) feedback became available, like the tiny ones starting to appear in cell phones, it should be straightforward to integrate a haptic feedback module into the map display system and to make touch attributes programmable through style sheets.

Project background: Where are we starting from?

Our initial foray into building a soundscape map was in Spring 2007, with a combined group of geography and computer science students. That group (working as a single large team) constructed a prototype haptic soundscape map of the UO campus in Flash. For haptics we used inexpensive gaming mice with vibration feedback. Preliminary feedback from blind users at the Oregon School for the Blind was that these mice were very unsatisfactory (and quite unfamiliar to blind users, who do not typically use mice at all).

A key goal in the original project was to provide a separate style sheet to associate effects (sounds and haptics) with objects in the map, as well as the map itself (e.g., grid lines). While this was successful, using the original style sheet language suggested ways in which that language could be made more powerful so that style sheets would be shorter and easier to write and edit. In fall 2007, Keith Allbin produced a new version of the style sheet language, while rewriting and restructuring parts of the code that processed and applied style sheets to map data. This version of the system, like the one before it, produced maps in Adobe Flash form. Two high school students, working as interns in Summer 2007, added to the library of sounds and made some other improvements to the code base.

Our initial project also produced some novel ideas for the user interface, and revealed limitations in Flash that kept us from trying some of those ideas out. In particular, a Flash display in a web browser cannot take control of the mouse cursor, so some ideas about controlling panning to simulate a very large screen (why be limited by the physical dimensions of a screen the user can't even see?) were not possible. So, in fall 2007, two teams in CIS 422/522 produced a new version of the project that produced, instead of a Flash map, a data file and display program in Java (runnable from Java Webstart). This project reused most of the code from the spring 2007 class, but added a Java display engine and modified the code generation routines. Since this project was going on in parallel with Keith Albin's revision of style sheet processing, it used the old style sheet processing code.

Goals for Fall 2008

Things I would like to accomplish in Fall 2008 include

• Merge Keith's improved style-sheet processing into the code that produces a Java-based soundscape map.
• Generalize any code that is specific to the UO campus map (there is some, in the conversion from GIS xml data to our internal XML data format) so that it works for other map data sets.
• Refactor and merge the code bases for producing Java and Flash maps, so that either or both can be produced, and so that other output formats (e.g., Silverlight, Air) can easily be added.
• Greatly simplfy the map build process, automating manual steps (especially for Flash maps) and making it faster and easier to produce a new map from a new data set.
• Demonstrate these improvements by producing a new map (or maps) for the Oregon School for the Blind.

This may be a lot, especially if you have some other ideas that you really want to try (and I do encourage you to be creative — try something I didn't think of!). We will talk a lot this term about prioritizing goals, staging projects through a series of prototypes and incremental releases, and “design to schedule.” In the spirit of incremental development, my minimum core goals, top priority, are

• Generalize any code that is specific to the UO campus map (there is some, in the conversion from GIS xml data to our internal XML data format) so that it works for other map data sets.
• Demonstrate these improvements by producing a new map (or maps) for the Oregon School for the Blind.

My second priority goals are

• Merge Keith's improved style-sheet processing into the code that produces a Java-based soundscape map.
• Greatly simplfy the map build process, automating manual steps (especially for Flash maps) and making it faster and easier to produce a new map from a new data set.
• Demonstrate these improvements by producing a new map (or maps) for the Oregon School for the Blind.

My third priority goals are

• Refactor and merge the code bases for producing Java and Flash maps, so that either or both can be produced, and so that other output formats (e.g., Silverlight, Air) can easily be added.
• Demonstrate these improvements by producing new maps for the Oregon School for the Blind.

And just to complicate things ... at the end of the first week of classes, I will accompany Professor Amy Lobben on a visit to the Oregon School for the Blind for a needs assessment (or call it "requirements elicitation" if you prefer software engineering terminology). It is quite likely I will bring back some new problems, ideas, and priorities. I want you to help me think creatively about how to proceed. If the terms goes as I hope it will, you will mostly tackle my priorities above in the first half of the term, and in the second half you will go beyond what I've outlined above and do something new and interesting.