Harold McWilliams and Paul Rooney

Mapping Our City

A Progress Report on GIS as a Tool in Urban Education

(continued - page 3)


Interface Difficulties

One goal of this project continues to be exploring interface options that work well for students and teachers, options that reduce the complexity of GIS processes and offer the user an easier, more intuitive feel. Much of our investigation into this area has been empirical. The reasons for this touch on the complexity of the software and data and the processing skills involved in the use of GIS. GIS software is capable of performing elaborate analyses of spatial data, of tabular data, or the combination of the two. How does one best organize functionality for K-12 users? How much simplification do you stress in the application you offer users? And by simplification, by the clustering and streamlining of functions, are you depriving your users of important understanding? Spatial data has a dual nature, as we have previously stated. Can students visualize the "where" component of spatial data sufficiently to understand how spatial processes are actually occurring? Is it even necessary for them to do so to learn some of the basic concepts of GIS? Does their best option come in the form of a series of activities that stress spatial skills development, of which GIS is one (very important) part?

For Mapping Our City, our plan has been to start with the existing ArcView interface and choose features and functionality to combine or discard via ArcView's Customize options. This has been a largely subjective process, for the reasons addressed above, and has been based on staff perceptions of what the GIS process as a learning experience might entail. At this stage we have developed a prototype and exposed it to the scrutiny of TERC staff and the project's Advisory Board. Our next task is to field test the prototype with students. The objective is to identify those modifications and procedures that best lend themselves to Avenue script generation and set about the task of streamlining as much of the data input and analysis process as possible.


Screenshot of Spatial menu giving users access to 

specific neighborhoods

Spatial menu giving users access to specific neighborhoods.


Stumbling Blocks:

The recent acquisition of Avenue programming training will be enormously useful in creating the Avenue scripts. To date our work has been confined to the abilities of ArcView's Customize options. Although these options are useful (indeed the prototype interface was created entirely within Customize) the ability to modify the interface through Avenue opens up new possibilities for organizing the data entry process, streamlining related functionality into simple buttons and tools that perform tasks, and creating a more intuitive GIS interface.

Interoperability Across Platforms

It was decided early in the project to develop the application on the Macintosh platform. This decision was based on three assumptions: (1) that the Macintosh is the more common school platform, (2) that students and teachers favored the ease of use of the Macintosh and (3) that as ArcView had been designed for a PC environment, any difficulties encountered in development would be more readily apparent on the Macintosh. It was also decided early on to develop a parallel version of the application on the PC, so that it would be available to schools using those machines.

Stumbling Blocks:

It turns out that the software runs slowly on the Macintosh (even on a Power Macintosh 7500/100.) Esri staff were helpful with suggestions on how best to configure the system to optimize ArcView, but the difference in redrawing speeds still favors the PC (a 120mz Dell Pentium).

To accomplish all we would like in this project we have decided to migrate the application to the PC platform exclusively. We do so because we feel that the PC platform offers far superior interactivity and because of the time-consuming nature of creating two applications, two data libraries, and two sets of system administration strategies. While we know that by doing so we eliminate availability of the application to Mac users in the short-term, we are also aware that the project is a pilot, that future effort will include both platforms, and that we need to move forward with the greatest speed and efficiency. Our great hope is that with the trend toward open systems the choice of platforms will be irrelevant in the near future.

Version Control/System Administration

At this time we anticipate putting standalone systems in each of the schools participating in the project. The Avenue programming language offers many opportunities to provide version control for the "source project" installed at a site. The task is to use Avenue programming to control a student or teacher's ability to corrupt the source project without restricting their ability to enjoy the varied functionality of ArcView. One simple solution includes preventing users from saving to the name of the source project. Other "control issue" tasks will require similar solutions.

Another area of concern is administration of the systems we place in schools during the project. The spatial data used in GIS work requires a lot of system resources. Keeping these resources available on a day-to-day basis will be necessary to ensure the proper running of the installations.

A third area of concern is consistency throughout the installations. Without it, TERC faces the possibility of different schools working with different versions of an application. The results of any research conducted throughout the project will depend on this consistency.

Stumbling Blocks:

Many, if not all of the participating schools will not have any provision for system administration, and TERC staff cannot be on hand every time something goes wrong with a machine, or to perform necessary backups and clearance of extraneous files. Therefore it will be necessary to create "maintenance and administration scripts" with Avenue to accommodate many of these tasks on a daily basis.

Local Data

Many teachers involved in GIS have spoken about the importance of using local data in GIS projects aimed at students. The common opinion is that students relate better and react more strongly to data they can recognize. One of the missions of the Mapping Our City project is to provide a "set of local data", to which "students can add the data they create."

Stumbling Blocks:

While there is a wealth of consistently created material available at the global level, sets of data at the local level are obviously more difficult to create. And while there are likely to be numerous sources of local data in a given area, many willing to provide data for educational purposes, the sheer number of data-related issues makes the task of constructing a local data library very time-consuming. Different sources project their data sets differently, causing one type of issue. The item definitions of a source's data are not clear, or worse, not known, causing another type of headache. The time necessary for sources to provide you data (these folks are swamped with their OWN work, let alone getting donated data out to you) is certainly a factor. Converting data is time consuming. Determining what you have and coordinating those elements of outside data into something consistent and meaningful takes a lot more time. Updating it adds more time. Making it easy for the end user to use is very difficult for the person doing the development work.

There has been some discussion over what constitutes a "neighborhood." Would students define their neighborhood at the scale in which we depict it, or do they hold a more intimate image in mind when they hear the word?

Data Creation and Analysis Process

Data creation is a key element in the student and teacher's experience with GIS. When combined with spatial analysis skills it represents critical components in a spatial decision-making equation. In this project data creation can come in one of two forms, via the creation of shape files from existing themes, or from the creation of new themes (using student- or teacher-entered data.) These situations need to be well thought out from the standpoint of administration of the system and version control, as well as how the process of data creation can play a part in educational content (from the standpoint of developing critical thinking skills.)

Screenshot of Examples of potential student-generated 

data

Examples of potential student-generated data. Through field work and on-screen data creation, students enrich the understanding of their neighborhoods.


Stumbling Blocks:

This is an area where the risk is run of being too confining with what the application provides the user. If the ability to manipulate existing data into a new form, or to create new data entirely, is too structured then the potential learning may become limited. That point was brought out during the Advisory Board meeting when one of the members questioned the elimination of certain functionality from the standard ArcView interface. The question becomes "how much control is too much, both for the developer and the novice user?" It is a question we have yet to fully answer, though one possibility toward resolution may lie in the tiering of functionality. As users become more skilled, they are exposed to more and more functionality and creative opportunities.

Selection Process Problems (aspatial/spatial)

In our view the Selection Process consists not only of the work on screen, or within the computer, but takes into account the entire spatial analysis process. It asks the questions "What questions do we want to ask? How do we ask our questions? What information do we need to answer these questions?" The "aspatial/spatial" selection process is the second component of the spatial decision-making equation we identified above. For purposes of discussion this process will be limited to how users manipulate the software to answer questions, when it is acknowledged that spatial data has two distinct forms; "what" something is (its aspatial quality) and "where" something is (its spatial quality.) The challenge is to organize the interface and the functionality so as to make these processes, these "questioning abilities," clear and easy to distinguish.

Stumbling Blocks:

This is a big challenge, because the dual nature of spatial data is so often integrated. Personal experience indicates that aspatial questions often lead to spatial questions, and vice versa. A "where" question often leads to a "what" question. As one teacher put it "If they (her students) get it (the understanding of the dual nature of spatial data,) they've got it." (Kathryn Keranen, 4/2/96.)

The standard ArcView interface offers a confusing collection of icons as buttons and tools, as well as a variety of menu options, all having a role in the selection process in one capacity or another. Pulling these various menus, buttons and toolbar options into a coordinated palette of "selection options" will be an important and time-consuming task.

Multimedia

ArcView now offers users the option of incorporating multimedia in their work. This is a potentially important advance in the way GIS is used in schools. The question we ask is "multimedia to what end?" Linkages between pictures, drawings, text or film and spatial locations can be a powerful means of reinforcing a sense of place with personal expressions. But our concern is the possibility that students will place more emphasis on the technology than the process and content of what they are doing. Therefore it will be important to preface the use of multimedia with a clear explanation of its place in the activities.

Stumbling Blocks:

There are multiple possible formats of images to contend with and accommodate, some of which work better than others. Images retrieved from the Internet may have publishing restrictions that users need be aware of. Accommodating movies requires video software.

Some Questions to Ponder

We would like to conclude with some questions to ponder regarding the future role of GIS in K-12 education:

Endnotes

1. For brief reports on a number of educational applications of GIS in education, see First National Conference on the Educational Application of Geographic Information Systems (EdGIS) Conference Report. (1995). Cambridge: TERC. The report is available from TERC Communications, 2067 Massachusetts Avenue, Cambridge, MA, 02140, (617) 547-0430, fax: (617) 349-3535, e-mail: Communications@terc.edu.

2. Grant No. ESI-9452785.

3. Boston, like many urban school systems, has city-wide attendance at many schools, so that the students at any one school do not necessarily come from the neighborhood surrounding the school.

4. The EdGIS listserv is open to anyone interested in the educational applications of GIS. To subscribe to the list, send a message to hub_mail_services@hub.terc.edu Leave the subject line blank and in the body of the message write "subscribe edgis firstname lastname". (Replace "firstname" with your own first name and "lastname" with your own last name.)


Author Information

Harold McWilliams, Scientist and Project Director, TERC, 2067 Massachusetts Avenue, Cambridge, MA, 02140. (617) 547-0430. FAX (617) 349-3535. E-mail: Harold_McWilliams@terc.edu.

Paul Rooney, GIS and K-12 Education Specialist, TERC, 2067 Massachusetts Avenue, Cambridge, MA, 02140. (617) 547-0430. FAX (617) 349-3535. E-mail: Paul_Rooney@terc.edu.


Go to: Page 1