Apple Guide with External Code Modules

A real world example with design lessons

By Jesse Feiler, Philmont Softwre Mill

The Story So Far

Apple Guide is a major new technology available for the first time in System 7.5. In the March 1995 MacTech Magazine article, “Apple Guide Isn’t Help”, a very brief overview of Apple Guide touched on how it provides active assistance to users.

In this article, you’ll see a concrete example involving an AppleScript-based coach mark and a custom-written external code module to guide a user through a task. This case study is simple - but so are many of the activities which Apple Guide assists users in performing. The external context check, likewise, is very basic - but so are many of the external context checks that you may write.

The Problem To Be Solved

Imagine an environment in which a number of different people use a single computer. Most of the time, these people will be doing simple word processing. This computer of many masters might be in an office that employs a number of part-time and/or temporary staff, or it might be in a shared computer room at a school, or it might be located at a non-profit organization where volunteers drop in periodically to help in a Good Cause.

If you are managing such an environment, it will save wear and tear on everyone if you can tell your staff/students/volunteers that word processing can be done by selecting the Word Processing item from the Apple menu. You create uniformity by making an alias to WordPerfect 3.1.0 (your current word processor of choice) and placing it in the Apple menu. This helps keep things under control, even as the busy little bees rename the hard disk, open/close all needed/unneeded windows, etc. (Of course, you could use At Ease or a similar product, but there are cases where such a solution is not appropriate - most often when you need to let people have more Finder access than At Ease allows.)

This idea is received so well that you are promoted immediately. (Congratulations!) Now someone else has your old job and needs to know how to create and maintain the Word Processing alias in the Apple menu. Furthermore, this strategy is replicated throughout your organization, and it turns out that 432 office managers now are saddled with the task of creating and maintaining this alias. Having read a bit about Apple Guide (possibly even buying one of the excellent books on the subject), you decide that this is a great Apple Guide project.

Where to start?

Who is the user?

Remember that Apple Guide is a very personal service that is provided to a user who needs assistance in carrying out a task. Before flinging yourself into writing a guide file, think about who will be using the guide file and in what context. In this case, it’s very clear. The users will be office managers. You know from experience that they are basically familiar with the Macintosh - enough so that they can supervise people who know little more than how to type and select items from a menu.

Some of them - like you - are fairly sophisticated about the interface and about what you can do with it. Others of them are rather leery of trying anything new - particularly something that might cause a problem.

The purpose of this particularization of your users is to help you in knowing the vocabulary to use and the degree of detail that you need to go into in your guide file. The users in this case, for example, can be expected to be able to understand the phrase “drag this file to the trash.” The people who are actually doing the word processing, who may be much less sophisticated than the supervisors, may need to be told how to drag a file and where the trash is.

Sometimes one key element will stand out and put everything else in perspective. In this case, you decide that the best impression you can get of your typical user is that you will need to remind the user of what an alias is. The office managers will have heard about aliases, probably have used them, and may well have created them. But they don’t create them every day. This simple idea gives you guidance as to the tone and complexity of your guide file.

Whenever you create Apple Guide assistance, don’t skip this all-important step (and don’t spend too much time on it - five minutes is quite enough in most cases). It is very hard to provide a good service to a user if you don’t know who your user is.

What precisely do you have to do to provide assistance to the user?

In this case it seems clear: create an alias for WordPerfect. You could probably write a little AppleScript to do it. But consider:

• what if there are multiple versions of WordPerfect on this computer?

• what if there are multiple copies of a single version WordPerfect on this computer?

• what if WordPerfect isn’t even on this computer?

• what if WordPerfect can’t run on this computer?

The strategy that you adopt is to ask the user to run WordPerfect. In the context of your user definition, this is a reasonable request. This pushes the responsibility of choosing among multiple copies onto the user. If the user can’t find WordPerfect, the Find File command is available to help in locating it. In the scope of your guide file, you can refer the user to Macintosh Guide for more detailed assistance if necessary. Furthmore, since installing software is part of the office manager’s job description, you have no qualms about asking the user to do that if necessary.

What you will do in your guide file is verify that WordPerfect can run and that the right version is running. If you only wanted to verify that WordPerfect can indeed run, you could prompt the user to launch it and use one of the Process external code modules in Apple Guide Standard Resources to check that WordPerfect is running. But checking the version

Defining an External Code Module

No, there’s not doubt about it: checking the version of an application that’s running is going to require a new external code module which will need to check that the correct version of WordPerfect is running. As always when you write an external code module (or in fact any code), take a moment and stop to think if you can make the code more general without increasing development time.

In this case, you will have to check the version of WordPerfect. The version consists of three numbers (3.1.0 for example) which are stored in two bytes in the 'vers' resource of the application (the second two are packed into one byte). Do you need to check for version 3.x? Version 3.1.x? Version 3.1.0? Here’s an opportunity to generalize your external code module. After no more thought than this, you decide that the external code module will take five parameters (listed out of order):

2. The signature of the application to check.

3. The major version number to check (3 in the example above).

4. The minor version number to check (1 in the example above)

5. The bug fix version number to check (0 in the example above)

And of course, you’ll want to provide yourself (and other Apple Guide authors) the flexibility to use this module for various checks, so the first parameter will be:

1. Which comparison to perform.

This parameter will take any of the following values:

0= Compare signature only

1= Compare signature and major version number only

2= Compare signature, major and minor version

3= Compare signature, major, minor and bug fix version.

Defining the context check in Guide Script

If you name the external code module 'apVr', your context check will look like this in Guide Script:

<Define Context Check> "VersionApplicationRunning", 'apVr', 'MACS', SHORT, 
OSTYPE, SHORT, SHORT, SHORT 

The context check is addressed to the Finder ('MACS'), and the parameters follow as defined above.

You can use it in a line of code like this:

<If> VersionApplicationRunning(3,'WPC2', 3, 1, 0)

This will return TRUE if the application with signature 'WPC2' is running and if its version is exactly 3.1.0

Likewise, this line will return true if the application with signature is running - regardless of its version (remember the first parameter specifies the type of comparison):

<If> VersionApplicationRunning(0,'WPC2', 3, 1, 0)

The only other thing you need to do on the Apple Guide side is to remember to include the external code module in your guide file. If you have compiled it into a file called “contextCheck”, just add its resource in with the following line:

<Resource> "contextCheck", ALL

And that’s it!

Preparing the context check interface

Writing the context check itself is equally straightforward, even if it involves a few more steps. The first step is to prepare the context check to match the definitions in your guide file. This means making certain that you compile it with the same name ('apVr') and that you are prepared to take the same parameters in the same order that you specify them in your guide file.

If you are using MPW and your source file is named “contextCheck.c”, this code will compile and link it:

contextCheck ƒƒ contextCheck.c.o
     Link -sn contextCheck=apVr -mf -t extm -c reno -rt 
          extm=1200 -m MAIN -sg myModule 
          contextCheck.c.o 
          "{Libraries}"Interface.o 
          -o contextCheck
contextCheck.c.o.  ƒ contextCheck.c
     C -r -b contextCheck.c

In CodeWarrior, make certain that the project preferences specify a Code Resource, creator 'reno', type 'extm', restype 'extm', resource ID 1200 (or whatever number you’ve chosen), and resource name apVr (or whatever name you’ve chosen).

In order to make certain that the parameters arrive in your code module in the same way that you specify them in the guide file, the easiest method is to declare a struct:

typedef struct{
    // 0 = signature only
    // 1 = signature and major rev
    // 2 = signature, major and minor rev
    // 3 = signature, major, minor, and bug rev
 short  whichCompare;

 OSType signature;

    //note that we bring in 3 values; the 'vers'                   
    //resource combines minorRev and bugRev
 short  majorRev;
 short  minorRev; 
 short  bugRev;
}contextCheckData,*contextCheckDataPtr,**contextCheckDataHandle;

Now all you have to do is write the context check.

Writing the Context Check

The context check described here is brief enough and typical enough that it is included in its entirety. It is broken up into four sections only for clarity. Paste listings 1, 2, 3 and 4 together and you’ll have the whole ball of wax.

Listing 1: Headers and housekeeping

Headers and housekeeping

What would a source code file be without these things? You might want to put these in a header (.h) file and 
include that file.

#include"Types.h"
#include"AppleEvents.h"
#include"Errors.h"
#include"ToolUtils.h"

typedef struct{
    // 0 = signature only
    // 1 = signature and major rev
    // 2 = signature, major and minor rev
    // 3 = signature, major, minor, and bug rev
 short  whichCompare;

 OSType signature;

    //note that we bring in 3 values; the 'vers'                   
    //resource combines minorRev and bugRev
 short  majorRev;
 short  minorRev; 
 short  bugRev;
}contextCheckData,*contextCheckDataPtr,**contextCheckDataHandle;

//these are the values for whichCompare above
enum {
  compareSignatureOnly = 0,
  compareMajorRevOnly = 1,
  compareMajorAndMinorRev = 2,
  compareAllRevs = 3
};

/* prototypes */
Boolean VersionAppRunning(
 short  whichCompare, 
 OSType signature, 
 UInt8  majorRev, 
 UInt8  minorRev, 
 UInt8  bugRev);

OSErr   SetContextResult(
 void*  theData, 
 Size   theSize, 
 Ptr*   outMessage, 
 Size*  outSize);

(In case you’re wondering about the includes, AppleEvents.h contains the definition of errAECorruptData, the default return value.)

As in most context checks, there are two important functions. The first (VersionAppRunning above) does the work. The second (SetContextResult above) packs the result into the structure that Apple Guide wants to get back. This particular function is used almost verbatim in most context checks.

Listing 2: main

main

This is the heart of your context check.  Unpack the parameters passed in from Apple Guide, call the routine 
to perform the context check (VersionAppRunning) and package the result for return to Apple Guide.  All 
context checks have this general structure.

pascal OSErrmain(
 contextCheckData* msg, 
 Size   inSize, 
 void*  outMessage,
 Size*  outSize, 
 Handle ignoreMe )

{
    //    the default return value of the operation
 OSErr  err =  errAECorruptData; 
    
    //    the default return value of the context check
 Booleanresult   = FALSE; 
 
    //    this is what changes for different context checks
 result = VersionAppRunning (
 msg->whichCompare, 
 msg->signature, 
 msg->majorRev, 
 msg->minorRev, 
 msg->bugRev);

    //    this is usually the same for all context checks
 err  = SetContextResult(
 &result, 
 sizeof(Boolean), 
 outMessage, 
 outSize);
 
 return(err);
}

All of the parameters that you provide in the <Define Context Check> command are packed into a pointer (msg above) of size inSize and are passed to your code module. The struct that you declared above - matching the order and types of the parameters in your <Define Context Check> command - keeps this under control.

Apple Guide wants the result of the context check returned in the pointer outMessage of size outSize. This is a Boolean value of TRUE or FALSE, indicating whether or not the context check is true.

In addition to the result of the context check, the module itself returns a result of type OSErr, indicating whether or not it was able to perform the context check. At the moment, Apple Guide only recognizes noErr for such a return value. You may want to be more particular in reporting why you couldn’t do a context check, but Apple Guide isn’t interested in excuses.

Listing 3: Setting the result

SetContextResult

Apple Guide wants the result passed in a pointer with its size provided in a second parameter.  This is the 
code that is used in most of the Mac OS context checks as well as in many others.  It’s more general than 
needed, but that never hurt anyone.

OSErr SetContextResult(
 void*  theData, 
 Size   theSize, 
 Ptr*   outMessage, 
 Size*  outSize)
{
 Ptr  p;
 
 if (p = NewPtr(theSize))
 {
 BlockMove(theData, p, theSize);
 
 *outSize = theSize;
 *outMessage=  p;
 
 return(noErr);
 }
 else
 return(MemError()); 
}

Notice that if the pointer for the result cannot be allocated, this function returns the result of the MemError function, which in turn is returned as the result of main. As noted above, Apple Guide only looks to see if the result of main is noErr.

Listing 4: The heart of the context check

VersionAppRunning

Loop through each process on the computer until we find one that matches the signature requested.  Once 
we find it, check the version in accordance with the whichCompare parameter.

Boolean VersionAppRunning (
 short  whichCompare, 
 OSType signature, 
 UInt8  majorRev, 
 UInt8  minorRev, 
 UInt8  bugRev)
{
 Booleanresult = FALSE;
 ProcessSerialNumber PSN;
 ProcessInfoRec  info;
 OSErr  err;
 Str31  aProcessName;
 FSSpec aProcessAppSpec;

 PSN.highLongOfPSN = 0;
 PSN.lowLongOfPSN = kNoProcess;
 info.processInfoLength = sizeof(ProcessInfoRec);
 info.processName = aProcessName;
 info.processAppSpec = &aProcessAppSpec;

 while (GetNextProcess(&PSN) == noErr)
 {
 if(GetProcessInformation(&PSN, &info) == noErr)
 {
 if(info.processSignature == signature)
 {
 switch (whichCompare)
 {
 case compareSignatureOnly:
 result = TRUE;
 break;
 
    //    need to check the application file’s version
 default:
 {
 short  appResource = FSpOpenResFile (                         
 &aProcessAppSpec, fsRdPerm);
 short  myResError = ResError();
 
 if (myResError == noErr)
 {
 NumVersion theVersion;
 VersRecHndl aVersRecHndl = 
 (VersRecHndl)GetResource ('vers', 1);
 
 if (aVersRecHndl)
 {
 MoveHHi ((Handle)aVersRecHndl);
 HLock ((Handle)aVersRecHndl);
 theVersion =
 ((**aVersRecHndl).numericVersion);
 HUnlock ((Handle)aVersRecHndl);
 };
 CloseResFile (appResource);
 
 switch (whichCompare)
 {
 case compareMajorRevOnly:
 {
 result = (majorRev == theVersion.majorRev);
 break;
 };
 
 case compareMajorAndMinorRev:
 {
 result = (majorRev == theVersion.majorRev)
 && 
 (minorRev == 
 theVersion.minorAndBugRev >> 4);
 break;
 };
 
 case compareAllRevs:
 {
 UInt8  versionComparer = 0;
 versionComparer = (minorRev << 4) + bugRev;
 result = (majorRev == theVersion.majorRev)
 && 
 (versionComparer == 
 theVersion.minorAndBugRev);
 break;
 };
 };
 };
 break; // out of default case
 };
 };//switch statement
 break; //to escape the while loop
 }; //if we found the app
 }; // if we got the process info
 }; //while
 
 return result;
}

Although external code modules are very simple to write, they often require a bit of research into parts of the Mac OS you may not have wandered into before. The Process Manager, for example, is something that many programmers never have to deal with directly. When you start to think about writing a context check, spend a little time with the documentation on E.T.O. (or comparable resource) - particularly including code snippets and Tech Notes. Often, you’ll find exactly what you’re looking for.

In this case, a while loop calls GetNextProcess and GetProcessInformation to check each process on the computer. (This is copied directly from an example in Inside Macintosh.) All that matters here are two values returned in the ProcessInfoRec (“info”): processSignature, and aProcessAppSpec which is the FSSpec of the application itself.

If a process signature (info.processSignature) matches the signature you’re looking for, you use the whichCompare value to refine your testing. A switch statement makes the code easier to read here. If whichCompare is compareSignatureOnly, you set the result to TRUE. In any other case, you’re going to have to check the actual version of the file.

Using the FSSpec returned in aProcessAppSpec, you open the resource fork of the application and retrieve 'vers' resource 1. You take the numeric version of the resource out, ignoring the other parts (the copyright string, etc.). Close the file and then compare the resource with the values passed into this function.

An important point to note is that you must open the resource fork with fsRdPerm access only. Also, in the bad old days before Preferences files, some applications wrote to their resource forks while they were running. (Some still do.) If you are working with such an application, untoward results may occur.

The variable result, initially set to FALSE, is set to TRUE if the appropriate test passes. As its final statement, the function returns the value of result.

Writing other external code modules

The structure of most external code modules used for context checking is generally the same as this one. Only the guts of the module (Listing 4) really changes from one context check to another. Minor adjustments to the headers (Listing 1) and main (Listing 2) are required, but they usually involve nothing more than changing method names for readability.

An AppleScript Coach Mark

In the case study here, you can see how you can ask the office manager to run WordPerfect and to check that the correct version is running. Now all that’s needed is to assist the user in creating an alias for WordPerfect and installing it in the Apple menu. That’s very straight-forward: just draw a coach mark around the WordPerfect application, and coach the user through the process of creating an alias.

Well, conceptually it’s very straight-forward. If you have asked your user to run WordPerfect, who knows if the WordPerfect icon is now visible on the desktop? Did the user launch WordPerfect by clicking on a WordPerfect document? By using an alias in the Recent Applications folder of the Apple menu? No, somehow or other you’re going to have to make certain that the WordPerfect application icon is visible and you have to be able to coach it.

You can define an AppleScript coach mark with a command like:

<Define AppleScript Coach> "WordPerfect icon",
 REDCIRCLE, "wp icon script"

If you write an AppleScript that will provide the coordinates of the WordPerfect icon (and make certain that it’s visible!) and save that compiled script in a file called “wp icon script” this line of code will work - provided that the script is co-resident with your Guide Maker source files at compilation time.

Like the external code module described above, the AppleScript is not particularly challenging to write. Its design is based on a simple premise: since the context check above allows us to make certain that a particular version of WordPerfect is running, the script can simply loop through the processes running on the computer until it finds WordPerfect. It can then ask the Finder to reveal the WordPerfect application file icon, and you can then find its coordinates and return them to AppleGuide so the coach mark can be drawn.

Here’s the script:

Listing 5: Coaching the WordPerfect Application Icon
(Wherever It May Be)

AppleScript: wp icon script

This script assumes that WordPerfect is running.  To do so, use the context check discussed above.

tell application "Finder"
 copy number of application processes to n
 repeat with i from 1 to n
    --the name is the short name
    if name of application file of application process ¬
 i = "WordPerfect" then
    --this is the full file name
    copy application file of application process i to x
 reveal x
 if application "Finder" is not frontmost then activate
    --remember that Apple Guide wants global coordinates
    copy bounds of selection to iconsRect
 copy bounds of window of insertion location to winRect
 set iconsRect to ((item 1 of winRect) + ¬
  (item 1 of iconsRect)) ¬
 & ((item 2 of winRect) + (item 2 of iconsRect)) ¬
 & ((item 1 of winRect) + (item 3 of iconsRect)) ¬
 & ((item 2 of winRect) + (item 4 of iconsRect))
 return iconsRect
 end if
 end repeat
end tell

Putting It Together

With this external code module and the AppleScript coach mark described above, it is very easy to write a guide file to assist the office manager in verifying that WordPerfect can run on a computer and that the correct version is installed. Having done that, you can easily locate the WordPerfect application icon to coach the user in creating an alias.

The guide file below actually does this.

Listing 6: The alias installation guide file

Alias installation guide file

This is the guide file in all its glory.  The final section - once the alias has been created, dragging it into the 
Apple Menu folder - is omitted since it should be the same as a number of such sequences in the Macintosh 
Guide file.  The first half of the guide file is pretty standard stuff.  
#Define formats and set default.  Note that the No Style formats let you
#use your word processor to set color, style, font, etc.  This is useful
#for hot text.

<Define Format>  "Tag", Column(6,0,54), "Espy Sans Bold", 10,  Plain, 
Black, Right, false
<Define Format>  "Body", Column(6,65,330), "Espy Serif", 10,   Plain, 
Black,Left, true
<Define Format>  "Full No Style", Column(6,11,330), "Espy Serif", 
 10, , ,Left, true

<Default Format> "Full No Style"

<Default Nav Button Set>  NONE

<Define Event>  "ReturnBack", 's***', 'help', 'gobk' 

#Define Prompt Sets and set default
<Define Prompt Set>  "default navigation prompts", "Click the right arrow 
to continue", "Click the left arrow to go back or the right arrow to 
continue", "That’s all, you’re done!","Do    this, then click the right 
arrow to continue"

<Default Prompt Set> "default navigation prompts"

<Version> "Installing an alias for a specific version of an application", 
"1.0"

#---------------------------below this line is specific to this guide file------------------------
#The external code module we created
<Resource> "contextCheck", ALL

#coach marks
<Define AppleScript Coach> "coach WP", REDCIRCLE, "demo coach mark"
<Define Menu Coach>  "coach makeAlias", 'MACS', REDCIRCLE, "File", "Make 
alias", RED, UNDERLINE
<Define Menu Coach>  "coach findFile", 'MACS', REDCIRCLE, "File", "Find ", 
RED, UNDERLINE

#context checks
<Define Context Check> "VersionApplicationRunning", 'apVr', 'MACS', SHORT, 
OSTYPE, SHORT, SHORT, SHORT 

<Startup Window> Presentation, "Alias installation"

<Define Sequence> "Alias installation"
<Define Panel> "Start"
 This guide file will:
 .  verify that WordPerfect version 3.1.0 is installed on your computer 
and can run, and
 .  assist you in creating an alias for it to place in the Apple 
 menu
<End Panel>

#Don't ask the user to launch WordPerfect if it's already running
<Skip If> VersionApplicationRunning(3,'WPC2', 3, 1, 0)
 <Define Panel> "Launch WP"
 <Format> "Tag"
 Do this
 <Format> "Body"
 To start, please launch WordPerfect -- either by double-      
 clicking on it or by double-clicking on a WordPerfect         
 document.
 <End Panel> 

<Start Making Sure> VersionApplicationRunning(3,'WPC2', 3, 1, 0), 
 "Oops: no WP"
 <Define Panel> "Select WP"
 <Coach Mark> "coach WP"
 <Format> "Tag"
 Do this
 <Format> "Body"
 Select the WordPerfect application by clicking once on it.
 <End Panel> 

 <Define Panel> "Make Alias for WP"
 <Coach Mark> "coach makeAlias"
 <Format> "Tag"
 Do this
 <Format> "Body"
 Now create an alias for WordPerfect by choosing Make Alias from the 
File menu.
 <End Panel>

 <Define Panel> "Moving the alias to the Apple Menu folder"
 Move the alias you have just created to the Apple Menu folder.

 (Don’t do this in a real live guide file! Coach the user      through 
the process.  This section is omitted here because it is used several 
times in Macintosh Guide.  Use the same logic as is used there.)

 <End Panel>
<End Making Sure>

<End Sequence> 

<Define Sequence> "Oops: no WP"
 <If> VersionApplicationRunning(0, 'WPC2', 3, 1, 0)
 <Define Panel> "Oops: wrong version"
 <Coach Mark> "coach findFile"
 <Format> "Tag"
 Oops
 <Format> "Body"
 The wrong version of WordPerfect is running.  Either locate another 
on the computer (using the Find File command) or install the correct 
version.

 Click OK when version 3.1.0 of WordPerfect is running.

 <Standard Button> "OK", Center, ReturnBack()
 <End Panel>
 <Else>
 <Define Panel> "Oops: no WP"
 <Coach Mark> "coach findFile"
 <Format> "Tag"
 Oops
 <Format> "Body"
 WordPerfect is not running.  Either locate it on the computer (using 
the Find File command) and run it, or install it and run it.

 Click OK when WordPerfect is running.

 <Standard Button> "OK", Center, ReturnBack()
 <End Panel>
 <End If>
<End Sequence>

Note that the context check is used with two sets of parameters. If the correct version of WordPerfect is not running, the Oops sequence checks to see if any version of WordPerfect is running and displays the appropriate message (no WordPerfect vs. wrong version).

Starting the Guide File

The last thing you need to do is to start the whole process going. In the example discussed here, you would most likely either have a diskette with the guide file or a folder on a network server that contains the guide file. All you have to do is start it running.

Apple Guide automatically builds the guide menu with the appropriate Apple Guide files for each application (and the Finder), but for solutions such as this, it is more common to launch the Apple Guide file using an Apple event. The following script launches any Apple Guide file:

Listing 7: Starting a Guide Gile from AppleScript

Apple Guide starter script

This script starts Apple Guide and then opens a guide file of the user’s choice.

AGStart
set theGuideFile to choose file with prompt "Where is the Apple Guide 
file to open"
tell application "Apple Guide"
 Open Database theGuideFile
end tell

Naturally you can hard-code the name of the guide file that you want to open, but asking the user to select the guide file not only makes this more general but also covers a potential problem. The AGStart command starts up Apple Guide in case it is not running. Since it takes a little time to launch Apple Guide, the user interaction of finding the appropriate file covers that time interval and prevents the script from getting to

tell application "Apple Guide"

before the Finder knows that there is an application “Apple Guide.”

Summary

While you may think of Apple Guide primarily as a help system for applications, you can see it is far more than that. Its step-by-step task-oriented interface, combined with context checks to keep track of the environment and the user’s actions make it an ideal delivery vehicle for solutions like the one shown here. The branching, persistent checks (<Make Sure>), and Oops sequences used in the guide file in Listing 6 provide a very sophisticated environment for the user.

When you add the fact that developing Apple Guide assistance is really very easy (once you have a clear conception of the task and the user), it’s an important tool for you to use in developing assistance and solutions for people.