3 .A Theoretical Advance "TO-ASIST "

It has been established that if new users to SIT are to feel comfortable and productive

in their use of the technology, they require adequate training materials and user-.

friendly software interfaces. It is proposed here that the concept of a TO-ASIST

(Task Orientated - Application of a Spatial Information Systems Toolbox) is a possible vehicle by which both of these objectives may be met. A TO-ASIST may be

defined as a:

Customised software tool developed for a specific function using spatial information systems principles, presented in an environment that guides users through the application andfcicilitates learning of those principles.

The TO-ASIST represents a re-assessment of how SIT is delivered to users from a non-technical background. An important feature of the TO-ASIST concept is its restriction to one function. Further, the TO-ASIST must undertake all of those tasks that are repetitive and require complex sequences of processing algorithms. The simplicity of use of the TO-ASIST is the key to its success. If a more complex TO-

ASIST were developed, this would represent a return to a more generic interface menu, the very thing that should be avoided. The development of a TO-ASIST must be driven from the end-user rather than a SIT specialist attempting to predict what is needed. The development of useable software must be matched by an equal desire to provide linked, on-line instruction on the use of the software as well as linked, on-line reference to technical theory, should the analyst wish to pursue it. In this way the non-technical users, who may only need -the software on an infrequent basis, can be guided through the use of the package without having to remember complicated processing steps. Further to this, the opportunity is provided for on-line theory about the SIT principles that are driving the TO-ASIST. In this way, users who wish to become more familiar with SIT principles are encouraged to do so.

The TO-ASIST therefore has two roles. One is to make SIT useable for those who need it by guiding them through simple steps without the need to rote-learn long

40 command lines or navigate confusing menus. The other is to educate those users in

the SIT principles on which the TO-ASIST is based, if the user so wishes.

If the TO-ASIST is one possible answer, then this thesis offers us the opportunity of

not only undertaking research and development into SIT applications, but also their

suitability for deployment as a TO-ASIS T and hence into the natural resource

management community.

Not all tasks will be suitable for customising into a TO-ASIST. As a guide, an SIT

application is readily adaptable and suitable for a TO-ASIST if;

• There is a demonstrated need

• That need is recurrent

• ][t can be demonstrated that the technique works reliably

• The application contains a series of repetitive tasks that can be combined into

fewer, simpler steps

A task may not be suitable for development as a TO-ASIST if;

• The tasks involve complex processing procedures with a high user-input based on

experience (The use of expert systems may overcome this).

• Processing steps or components of .the task vary markedly from one time to the

next

• The task is performed infrequently

From concept to operational product, the development of a TO-ASIST is a methodical process that is outlined in Table 3-1. Adherence to this process will determine whether an application is suitable for development as a TO-ASIST and if so, that a reliable TO-ASIST is developed that is true to the concept.

41 Table 3-1 Following a structured method will ensure a successful TO-ASIST is developed.

1. An information need is established by end-users. The end users are in the best

position to describe what they need, and ultimately shape the final form of the TO-

ASIST. To do otherwise would run the risk of the technology manipulating the

process for technological outcomes rather than the management process

manipulating the technology to achieve good management and planning decisions.

2. The task is conceptualised and a method developed by a SIT expert.

3. A research case study is undertaken by a SIT expert to test the methodology.

4. The structure of the TO-ASIST is developed.

5. The task is formalised and divided into sub-tasks and a flow diagram created to

depict each task and where it fits into the overall structure of the TO-ASIST.

Technological barriers are identified against each sub-task. Solutions to the

technological barriers are devised (if possible).

6. Key SIT concepts are identified next to each task and theory lessons and

informative practical tips are written. The theory lessons are linked to these tasks.

7. Implementation options are considered. The system may be developed under the

envelope of an existing system using a scripting language (e.g. in

Mapinfo) or alternatively it may be developed using a lower level programming

language such as .

8. The prototype system is developed and tested by the end-users.

9. Necessary modifications are made and the TO-ASIST is commissioned in the

10. The system is monitored for performance.

3.1.1 Grass Roots Application or Macro-based Add-on

A decision to implement a TO-ASIST raises the question of which development environment to use. Development of a TO-ASIST is possible using a low level programming language such as Visual Basic (VB) or via a scripting language such as the Arc Macro language (AML, associated with ESRIs Arc/Info package). Table 3-2 and Table 3-3 highlight some of the advantages and disadvantages of each approach.

42 Table 3-2 Development using a programming language.

Advantages Disadvantages

1. Complete control over software 1. All functionality must be programmed

functionality, system can be fully "open" from the beginning

2. Distribution is easy, no need for 2. Software development costs are high and

expensive licenses in all offices requires specialist staff

3. TO-ASIST can be marketed to other users 3. Data structures are not always known as

easily some vendors have proprietary data

4. Can take advantage of latest custom structures

controls to improve TO-ASIST 4. Using vbx/ocx technology carries the risk

of relying on other vendors for updates

and bug fixes of the components used

Table 3-3 Development using a macro or scripting language.

Advantages Disadvantages

1. Full power of system is available with 1. Functionality may be restricted to

less programming required. software functionality.

2. Existing SIT experts can easily learn the 2. Interfaces can be clumsy.

language. 3. Licenses are often needed to run the

3. Development and maintenance of system software.

requires dealing with one vendor only. 4. Vendor may drop support of

4. Development costs may be less. system/programming environment.

It is apparent that for simple SIS such as EDRISL the low level programming language is a better option. For complex systems, such as Arc/Info, a scripting language may be the preferred option. This may change as software is implemented under the

43 Windows environment and SIS software functionality may be called via Dynamic

Link Libraries, OLE and through custom controls. The first signs of this (at least in the Windows environment) are becoming evident. ESRI have announced a product

called "Map Objects" which allows users to develop their own applications using

Arc/Info tools via a custom control, designed fbr use with Visual Basic, C++, Delphi

or a similar programming language.

One of the biggest barriers to open standards for SIT is the persistence of some vendors such as ESRI and ERDAS to develop and maintain proprietary data

structures. Other vendors such as Earl Resource Mapping (ERM) and Resource

Industry Associates (RIA) have taken the opposite approach and made their systems totally open. This move is to be applauded and will ultimately lead the way in the future development of SIT. Until that time, the imposition of proprietary data structures will remain a major barrier to the implementation of a TO-ASIST using low level programming languages. This in turn will continue to restrict the expansion of the functionality of SIT and therefore offer an impediment to its wider adoption within the resource management community. Further concepts such as OpenGIS and the new spatial data transfer standard (SDTS) will enhance inter-system operability in the future.

3.1.2 Capability versus Complexity

The application of a TO-ASIST need not be at a sophisticated processing level.

Indeed most uses of these technologies are quite simple and productive. The use of technology for the sake of using technology can be an easy trap into which to fall. A well defined user needs survey will soon ascertain whether benefit is to be gained for an organisation by the adoption of all, or some of these technologies. Many a sophisticated GIS modelling facility has been used for nothing more that an expensive mapping tool. In these circumstances it is easy to be overwhelmed by the technology and not make sensible and informed decisions. Zwart (1993) proposed that SIT will only really become fully institutionalised when it becomes embedded ubiquitously, as a sub-system within other hardware and software regimes. Under these conditions the

SIT becomes transparent. Zwart also predicted that SIT software would become increasingly dedicated to specific tasks in a similar vein to a TO-ASIST. Wegener

44 (1993) is critical of this prediction and believes that routine operations are only one segment of possible SIT applications. This is true but Wegener trivialises these routine applications by referring to them as "not the most interesting" (Wegener

1993:206). This type of operation may not be the most interesting but none the less constitutes the majority of operations expected from SIT and are therefore of critical importance. How can we even think of tackling advanced processing if we have not mastered and disseminated the more basis; functions of SIT? The attitude of Wegener may typify the attitudes of advanced woncers in SIT towards the more practical applications of the technology and may indeed explain why the introduction of SIT has traditionally been forged from a technical perspective rather than a solutions- oriented perspective.

3.1.3 Development Environment — Visual Basic

Visual Basic (VB) for Windows was first released in April 1991 following the success of Visual Basic for DOS (Murdoch 1996). VB is an event driven, object oriented programming language. Of particular utility is the ability to build user interfaces graphically and then write event code for each object as necessary. Interfaces are developed using a menu editor, buttons, text boxes etc. Each of these is an "object" and has a series of methods, properties arid events associated with it. For example, when a user uses the mouse to click a Command Button it initiates a click event and the code associated with the click event is, executed. Figure 3-1 represents a simple

Visual Basic program Graphical User Interface (GUI) that writes the word "Hello" into a Text-box. This is accomplished by clicking the Command Button. When the Command Button is clicked using the left-mouse-button the Click Event is fired and the code in that procedure is executed, in this instance the code looks like;

Private Sub Commandl Click() TextBoxl .Text = "Hello"

End Sub

Code Example 3-1

45 This makes programming easier and within the capability of many more people.

Is Button Demo IN a IN Button Demo Pi a Hello

Command Button Command Button

Figure 3-1 Event driven programming makes application development easier. When the Command Button is pressed, the code in Code Example 3-1 is executed.

Visual Basic Custom Controls and Add ons

The .vbx and .ocx

A significant development in computer programming came from in the form of the Visual Basic Extension (.vbx) (Webb and McKelvy 1995). Vbx controls extend the capability of Visual by adding to the standard set of controls that come with the compiler. Vbx controls can be identified by their file extension, .vbx.

Some sample vbx controls include, 3-D replacements for option buttons, check boxes and frames, data-aware list boxes and tabbed interfaces. Most .vbx controls are supplied and purchased through third-party developers. Vbx is fundamental to the development of the TO-ASIST concept.

One drawback of vbx is it is based in a 16 bit architecture that limits its life as mainstream desktops move towards 32 bit architecture. With this in mind the concept of vbx was merged with Microsofts Object Linking and Embedding (OLE) to create

OLE Custom Controls (.ocx). OLE controls are similar to .vbx in that they support the properties, methods and events model. Since theyre based on OLE 2.0 they can be built in 32-bit versions. The .ocx standard was introduced in Visual Basic version

4.0. On the surface .ocx work the same as .vbx controls. The new .ocx standard offers some advantages however, particularly in the area of future expansion and

46 compatibility. The standards on which .vbx were built were written specifically and

(at the time) exclusively for Visual Basic. Since then, other development tools, such as Microsoft Visual C++ and Borland C++, have added support for .vbx. The differences between these development environments and Visual Basic provided significant development problems so the vbx standard was no longer a suitable vehicle for all custom controls.

Additionally, Visual Basic is now available on several different operating systems;

Windows 3.1, Windows NT, Windows 9`; and potentially Macintosh and other platforms. Moving to an OLE based standard will enable Microsoft and other vendors to develop controls that are suitable for multiple development environments, rather than invest a lot of effort in maintaining the .vbx standard on all platforms. The .ocx standard is much broader than the original .vbx standard. Hence the move from .vbx to .ocx represented a logical step in the development of the component object model.

3.1.4 Future Direction of Programming

The extension of Microsofts OLE objects in the form of .ocx or Active X controls

(Active X is a new name for Microsofts ()LE technology) means that computer programming may become "modularised". This is a core principle of the Component

Object Model (COM) whereby new applications are built using "building blocks".

Land Use Modeller was designed and written using this programming paradigm.

Rather than writing software from scratch, we can now purchase extensions to our programming languages using .vbx or .ocx. For example, there are several custom controls available to display and manipulate images. Rather than programming from scratch it is a simple (although sometimes costly) matter of purchasing a custom control, "plugging" it into your application and writing a few lines of code. In this situation VB becomes the "glue" that binds the application.

Linked and embedded objects are not the only type of OLE objects that can be used with the Visual Basic programming environment. New developments include object applications. Unlike .ocx and .vbx, object applications are not designed to be pasted into an application. Instead they become sub-applications that can display their own dialog boxes and forms to perform services. One may postulate on the future

47 direction of SIT-applications development using a building-block approach whereby specific functions of SIT are strung together using the various programming tools available to us: DLL, VBX, OCX, object applications, Windows API etc. The advent of Map Objects and the NT version of Arc/Info by ESRI is an early indication of the potential of this paradigm. In any event, these developments in programming paradigms will allow us to explore new ways of delivering SIT applications to the desktop of natural resource managers.

Now we have a new direction to pursue for the delivery of SIT, it is appropriate to develop several new applications and assess their suitability for development as a TO-

ASIST (Chapter 4). Ultimately, in order to demonstrate the new concept, a TO-

ASIST will be written based on one of these projects (Chapter 5).

48