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. mapbasic in Mapinfo) or alternatively it may be developed using a lower level programming language such as Visual Basic. 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).