Glossary Language With this tool, even non-technical users can improve and customize applications
From "VS Workshop",  Access to Wang, May 1993
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Watch carefully as any software is used and you can see many tedious, repetitive typing tasks. These include tabbing through unused fields, entry of coded information at specific locations, and occasional stops to wait for the system to catch up. Frequent users of software have memorized the keystrokes necessary to get them through this morass and have often entered these keystrokes well ahead of the system's ability to respond.

Recently, our organization has begun an experiment using Wang's Multistation Glossary language to expedite some of these tiresome duties. Multistation glossaries are now being developed to speed data entry and improve consistency between members of a production data entry group. While glossaries are not new to most technical VS users, this program is unusual in that end users are specifying and programming most of the routines.

It's too early to tell, but it appears that this program will benefit the organization in many ways: the company will benefit from better productivity and more accurate entry, end users will spend less time on tedious entry, and all will be more satisfied with the process.

The purpose of glossary languages

Glossary, script, and macro languages have existed from the time of the first computer programs. Why? Perhaps computer applications are designed for a larger audience and may need customizing to appeal to personal tastes. In some cases, the main applications no longer fit the needs of the end user but rewriting them is prohibitively costly. Whatever the reason, glossary languages can reduce the sting of an application that does not perfectly fit the needs of the user.

Wang's Multistation Glossary language provides a unique environment for end user glossary programming. In its simplest form - recording keystrokes to form a Glossary-by-example - it is usable by anyone with little training. At the same time, Glossary offers many of the features of a high-level language, including conditional branching, a procedural language, and fast execution. Much of the program code can be generated using the append function within the personality editor, saving time and providing easier access for those with little or no programming background.

Sharing glossaries among group members

The sample group used for this experiment was already meeting as a part of the organization's quality improvement program. They saw the use of glossaries as a project that would benefit all users within their group, most of whom perform similar data entry work. The process works as follows:

1. Propose ideas for common routines: This process is conducted during regular meetings of a quality circle group for the group. Teams are formed to tackle an individual need, propose a solution to the main group, and arrange for this solution to be developed.

2. Develop routines: Some glossary routines are developed by the team that proposed them, often using temporary glossaries as a starting point. More complicated processes - such as those that "read" the screen and react to events accordingly - may require help from a programmer. A representative of the program development staff is consulted to check for any conflicts with program modifications underway.

3. Distribute routines to members: Once a glossary is developed and tested, a member of the group compiles the glossary files of all group members to include the new function. All common routines are incorporated into the personal glossaries of group members using an %include statement in each member's source file. (See description below for more information.)

4. Documentation and training: As each glossary routine is developed and tested, updated documentation is distributed to all members of the group. If necessary, group members are trained in the use of the glossary.

The development of glossaries begins with careful analysis of the task, including whether the routine is generic enough to be useful to other members of the group. Consideration must be made for the key that each routine is "bound" to, since most group members also develop their own glossaries and the distributed routines might conflict with an existing definition. Finally, training and documentation procedures have been developed.

It is important that a member of the program development staff play a role in reviewing glossary developments by the team. This is necessary because the glossary might be affected by changes to the location of fields on the screens. There are also changes that are best made directly to the affected programs, removing the need for glossaries.

Training end users in Glossary programming

Part of the secret of this workgroup approach to glossaries is having at least one member that is trained in Glossary programming - what I call a group expert. This provides better flexibility for the group, since they do not have to depend on a programmer to get things done, and also helps in keeping the solutions proposed by the group practical. One or two group experts appears to be enough for a working team of a dozen members.

The training given to these group experts was tailored to the needs of end users, most of whom have never worked in a programming language before. For this training, I designed a program of two courses: the first covers general capabilities, including special key functions, the Glossary-by-example function, control over workstation features, generating permanent glossary entries, and use of the Wang editor; in the second course there is more detail on Glossary language syntax and functions, including use the SUBSTR function for conditional branching based on text displayed on the screen. Each course requires four hours to complete.

Completion of the first course gives most users enough background to understand the capabilities and requirements for glossary programming, and fills the requirements for a group expert. The second course allows the group experts to shoulder more complicated tasks, such as the use of conditional branching. Each organization and user group must decide for themselves how far to carry this training and programming activity; for now, our group has chosen to remain within the first level.

Distributing glossaries

Once a routine is developed and tested, it is incorporated into the source file containing other group glossaries. A group expert then uses the personality editor (PERSON or WSPERSON) to compile the glossaries of each member of the group, using the following process:

1. Within the personality editor, select each group member's personality file.

2. Select the Glossary option, making sure that the glossary file name matches the initials of the user.

3. Select the Compile option.

4. When the compile process is completed, exit and save.

Each group member has a glossary source file that contains the following statement:

%include groupgls;

This copies the group glossary file into the user's source file at compile time. Note that it is not necessary to enter the Wang editor to compile each file, which simplifies the distribution process.

Program change or glossary?

The existence of glossary languages can be viewed as an extension of the development process - one in which the end user is allowed to modify how they interact with the application. While it would be irresponsible to design programs to depend on this capability - expecting the user to overcome a bad design through other means - the use of glossaries should be considered as an alternative to program development.

In the choice between program change and end-user effort, the level where the change should take place should be carefully examined. If users find an application difficult to use, changes to that application should be considered. If it is impractical to change the program to fit the personal desires of each user of that program, glossaries can help make it fit the user's desires better.

The results of this experiment are not complete, but it appears that our goals for accuracy and production quantity will be met. Users are also satisfied with their role in this process, since it capitalizes on the expertise they have in the application and allows them to play a part in the development process. Hopefully, this process will improve job satisfaction even as is increases the amount of work performed by each user.