Programming
Graphic Design
Human Computer Interaction (HCI)

An important consideration, possibly the most important consideration in some cases, when choosing an authoring tool is the training and expertise required to use the tool. No matter how powerful the tool, if the author needs several years of specialist experience to produce a usable application then that tool may not be suitable. Alternatively, the author may decide that a specialist should be employed to undertake or oversee certain aspects of the development. In the case of larger scale projects, it is useful for project managers and programming leads to know a tool's skill requirements ahead of appointing staff.

The skills required to develop in ToolBook can be divided into three broad areas which are common to all applications. These are listed below and discussed in the following sections.

• Programming
• Graphic Design
• HCI (Human Computer Interaction)

This is by no means an exclusive list and other areas could be added including project management, testing, systems analysis, media production and so on. Also, domain specific skills (e.g. economics, physics, biology, etc.) are required at some point to develop computer based learning software. However, these excluded skills requirements are either independent of ToolBook and would be just the same for any other authoring system, and/or too specialised for the intended readership of this report.

Programming

Despite inferences to the contrary in the Asymetrix publicity and product information, most ToolBook applications development requires programming, or scripting as Asymetrix prefer to call it, to a greater or lesser degree. While it is possible to create pages (i.e. screens) and populate them with objects such as buttons, scrolling lists and graphics, in order to add functionality to these requires the use of the built in "scripting" language called OpenScript. ToolBook's OpenScript, despite its name, is a full blown programming language and to use ToolBook 3.0 effectively OpenScript programming is required.

How much OpenScript coding is required for different types of project?

This is a difficult question to answer as there are numerous ways of implementing exactly the same functionality but with varying levels of "ease of development", robustness, complexity, maintainability and so on. For instance, the script controlling a menu screen consisting of a series of navigation buttons could be implemented as a series of independent self-contained objects. Such a bottom up approach requires a lot of coding, but much of it is very similar. Alternatively, a generalisation could be made and the code could be factored up to a higher level of abstraction so that a single script controlled all the buttons. This abstracted approach requires less scripting but the script is more complex. A further approach still would be develop a reusable component consisting of a set of navigation buttons which could be used in this and any future book. Here, more coding is required to make the buttons independent and generalised. So, clearly, the amount of coding required for different types of projects is entirely dependant on the precise nature of the project.

However, some generalisations can be made. Reference materials and, so called, electronic page turning applications require relatively little coding although, when implemented by inexperienced ToolBook programmers, will consist of numerous cut and pasted copies of functionally identical buttons. But even at this simple level, some esoteric OpenScript coding will be necessary to create a deliverable quality application. It has been the experience of the authors in their consulting work that most current multimedia applications fall into this category and that developers working on these projects progress well until they hit problems with the esoteric work required to finish off their application. This problem is by no means unique to ToolBook but it is perhaps less obvious that the problem is there in the first place because most of the core programming required to typical multimedia work is very short and fairly simple.

Projects with an element of computer based assessment (e.g. multiple choice questions) or record keeping (e.g. recording visited pages from session to session) require more coding still. Projects with elements of simulation, gaming, modelling and other rich interaction require just as much coding to implement in ToolBook as they would in Visual Basicä or Visual C++ä. The difference between the amount of code required for a rich interaction page and a simple hypertext page can easily be 10:1 and can rise to over 100:1 for complex interactions. If your intended ToolBook application is to contain rich interactions then serious consideration should be given to specialist tools (e.g. Excelä, Microfitä, Mathematicaä, etc. for numerically rich interactions, or Accessä, Oracleä, etc. for data rich interactions) more closely aligned to the interaction as this may bring more benefit than easily developing the less specialised elements which make up 95% of the pages but only 5% of the effort.

One approach frequently adopted by multimedia projects is to use ToolBook as the framework or container document and to develop custom extensions written in other programming languages. However, this approach requires both more coding and a greater degree of general programming expertise - it is not an approach for novice developers or non-programmers (unless they are prepared to invest a great deal of time acquiring new skills).

How long does it take to learn ToolBook programming?

OpenScript is a full programming language with an exceptionally large number of reserved words and alternative syntax structures. At its heart are the same selection, looping, procedural, functional and object constructs found in numerous other programming languages - although with non-standard syntax and names. Around this core are an extensive set of commands and functions for manipulating objects - allowing manipulation of properties such as size, colour and data. In other, more general purpose programming languages these operations would normally reside in a graphics library rather than in the programming language itself. The net effect of this is that OpenScript is exceptionally well integrated with its environment but at the cost of being daunting to a newcomer. The on-line help for each and every keyword makes life somewhat easier but new users seldom know how to use it efficiently .

The documentation accompanying ToolBook 3.0 includes a User Manual which is designed to lead developers through the process of learning all aspects of OpenScript and object manipulation. Opinions as to how good this documentation is vary from person to person. We, as authors' of this report, found this User Manual to be easy to use and helpful. However, we did have prior programming experience and were familiar with ToolBook 1.5 too. Other developers have expressed exactly the opposite view, raising concerns over the way the "how to program" issues are largely ignored. Fortunately, there are a number of third party books on Multimedia ToolBook 3.0 and numerous sources of further information on the Internet (see the appendices of this report for details of both of these). In fact, the Hustedde book is a book teaching computer programming that just happens to use ToolBook OpenScript as the language.

Regardless, ToolBook programming can not be learnt overnight and requires a considerable time investment. A potential ToolBook developer, unassisted by a more experienced ToolBook programmer and without prior extensive programming experience, would be unwise to allow anything less than a 4-12 week (full time) lead in time to climb the steepest part of the learning curve. Becoming fluent in OpenScript and relevant ToolBook-specific design techniques can easily take 6 months to a year of working with the software. Obviously (one would hope), becoming fluent in programming itself can take many years.

Despite the need for programming skills, most ToolBook developers are non-specialist programmers and yet they manage to produce some top quality material. So, this requirement should not necessarily be seen as an insurmountable barrier, rather it should be taken into account in scheduling and resource allocation. Also, it should be noted that a great deal of the effort involved in multimedia software development is not "programming" as such. In the authors' largest ToolBook development, the coding (which is what people normally think of as programming) only accounted for 20% of the "programming" work . The rest consisted of user interface design and educational content (i.e. subject matter content) in roughly equal amounts. Therefore, mastering OpenScript programming is only a part of the overall skills set required to develop in ToolBook.

Does experience in other programming languages help?

Undoubtedly. OpenScript is only a proprietary programming language which supports all the programming constructs normally found in mainstream programming languages. While procedural in some respects, it is also semi object orientated in that it supports message passing and the concept of data and code in the same object.

Experience in programming in Hypercard or Visual Basic is especially useful as there are many similarities. Experience in C/C++ also helps to understand why and how ToolBook works and allows custom extensions to OpenScript to be written to add needed features.

Care is needed though, as a number of familiar constructs have slightly different semantics and it is easy to miss some of the powerful features of OpenScript by assuming the same restrictions on familiar operations apply. A careful read of the manual is always worthwhile even if commands look familiar.

Can the programming be done by someone other than the domain expert?

The design of ToolBook makes it feasible to divide up the development work so that, for instance, a reasonable experienced ToolBook programmer could write a basic application framework or template and an inexperienced programmer (or even a non-programmer) domain expert could then populate the template with content. These and similar approaches are examined in the case studies section of this report.

Graphic Design

Does ToolBook help non-specialists achieve attractive and professional looking screens?

ToolBook 3.0 provides little software or written guidance in this area and so the answer has to be, "It is very difficult." In fact, the sample applications and documentation accompanying ToolBook are by no means exemplar in this respect.

This is a major weakness of the package in one respect but it could be argued that this is not an area which should be dictated by the software tool. Indeed, it is the lack of layout restriction which has enabled developers to use ToolBook in a wide range of application areas. ToolBook 4.0 introduced a wizard and template based approach to creating basic page layouts but, in the opinion of the authors of this report, the resultant layouts are far from impressive.

Could graphic designers who know little or nothing about ToolBook provide useful input?

Yes. The basic screen design functions of ToolBook 3.0 would be familiar to most graphic artists through their existing knowledge of drawing packages. With only a little knowledge of ToolBook, a graphic designer can produce screen layouts which may be populated by a domain expert and made functional by a programmer.

Human Computer Interaction (HCI)

Does ToolBook enable effective human computer interaction (HCI) design?

ToolBook, unlike more prescriptive authoring environments, has sufficient flexibility to produce a wide range of interface designs. The down side of this is that it also has the scope to produce highly unusable designs.

How does ToolBook encourage or discourage good practice in this area?

Specialised and highly usable human computer interfaces can be produced provided that the developer has either some training in HCI and/or an ability to think like a user.

ToolBook has been used to mock-up and prototype interfaces so that user input can be obtained while there is still a chance to feed the findings back into development. This makes ToolBook an ideal RAD (Rapid Application Development) tool suitable for an iterative cycle of prototyping and evaluation until the prototype eventually becomes a deliverable product. This is in stark contrast to the traditional waterfall model of software development where the product is specified in detail before implementation.

Other than the RAD nature of the tool, ToolBook 3.0 includes no specific tools or documentation which substantially encourage good practice. The sample applications contain little evidence of having being designed for or ever been near a user. Similarly, the sample widgets (reusable software components) have inconsistent behaviour and look and feel.

Does ToolBook assist in measuring and controlling usability?

There are no direct examples of how to measure and control usability and advice on user trialing is minimal. However, ToolBook does have an outstanding ability to monitor its own environment, including user actions, without having to write complex and long winded code. Coverage, timing and logging are easily implemented. Also, it is a surprisingly simple matter (given a reasonable level of programming experience) to provide integrated user feedback collection or questionnaires.