Creating interactive help system navigation within your databases.
When a database becomes more complex and powerful, there is often a need to provide some kind of help messages or a full-blown help system to explain some of the choices.
There are basically two kinds of underlying structures that you can use. Each one has its advantages and disadvantages.
Which you use depends mostly on what it is that you want to put on the layout.
The critical question about the layout is, “How many graphics do you want, and do you need flexibility to put them in lots of different positions?”
Layout-based Structure
If the answer is yes, then you would probably want to use what I think of as the “layout-based” structure. It is layout-based because every page is a new layout. All of the work, placing graphics and typing, is done in Layout mode. You only need a single record.
The advantage of this method is that it is fairly simple to understand and very flexible to lay out. You can do pretty much whatever you want.
You can make each layout whatever size you want, using Toggle Window Zoom to shrink-or-expand-to-fit.
The navigation system is also fairly simple. Whenever you come to the help system from another file, you will need the script in the original file to pass the specific number or name of the layout you’d want to end up on, via a Constant=1 relationship, setting it into a global field in the Help file.
If you used the same name as the layout in the original file:
Set Field [“Help Constant Rel.::Layout Name g”,”Status(CurrentLayoutName)”]
If not using the same name:
Set Field [“Help Constant Rel.::Layout Name g”,”Your Help Layout Name”]
then,
Perform Script [External, “Help File”]
You’d target this script in the Help file:
Exit Record/Request
Go To Layout [“Layout Name g”]
Toggle Window [Zoom]
Halt Script     (optional, sometimes needed)
I would tend to go for the name, as you may later decide to change the order, or delete one of the layouts, which would change the number of all those above it. Of course, you could just remember not to do that.
You see, it’s a hard-coded system. That is one of the disadvantages. Another is that at some point it might get to be kind of a big file, with so many layouts and graphics. I don’t know what the limit of the number of layouts is, or even if there is one, but I imagine it’s pretty high.
This method is probably the best choice for a simple help system.
It has one major shortcoming, and that is that the text cannot be searched.
Navigation within the Help file would also be more primitive.
You could use the new Design function to populate a field to use as a basis for a value list of the layouts.
Set Field [“Layout Names”,”LayoutNames (HelpFile)”]
Attach that value list to the Layout Name g field, to choose which layout to go to. But that would be about it, unless you want to make a whole bunch of buttons and other layouts to put them on.
Record-based Structure
I have come up with a different kind of system entirely. It is “record-based,” much more like a regular file. There is roughly one record for every layout in the other files that needs a help screen. Some layouts (in the other files) may get split up into 2 help screens, or 2 may share the same; but both of these situations are unusual and require extra scripting.
Layout with Graphics Container Fields
The main disadvantage of this method is that there is somewhat less flexibility of layout, especially for graphics. My help screens tend to be mostly text, so that’s not a big problem for me. You can also create extras layouts for different graphics layouts; like in the first method.
In that case, rather than paste graphics directly onto the layout (as you would do using the 1st method), you would create a couple of container fields (regular, not globals) to paste into. Remember you’re using records, so each one might want its own graphic(s).
List View Layout Help Screen
In one solution I created a couple of different layouts with large graphics container fields as bars at the top and bottom. By pasting screen captures of the Header and Footers into those fields (in Browse mode), I was able to simulate the actual layout the help text was describing.
The help text was in its own field in the large middle space of the layout.
I captured only the first row of the Body list, as the rest were all the same.
All of the buttons on the real layout were visible; but of course they didn’t do anything (which was good).
Most of the action in List View layouts (buttons, etc.) is in the headers and footers, so this method works well for those layouts.
Form View Layout Help Screen
For “Entry” or Form layouts, you could create a container field that covered the whole screen, then paste in a screenshot. It would look just like the original.
Of course, that wouldn’t be much help, would it? You need to type your help text into a screenshot first, in a graphics program, then paste the whole thing into the container field.
Graphics Screenshots
A useful technique for this is to take a picture of a selection, using crosshairs. This is easy to do, at least on later OS’s. You probably know about Cmd-Shft-4, to make a PICT file of a screen selection. Just add the Control key and it’ll put the picture on the clipboard instead.
This allows you to capture any of the FileMaker screen in Browse mode.
You can then paste it onto a drawing document in something like AppleWorks. It’s very useful to draw a background square of the same size and color of the receiving container field. You can then assemble separate pieces and know just what it’s going to look like.
In the case of the Form view screenshot, you could add little text boxes to describe things, then paste the whole thing into the container field.
Advantages of Records-based Files
Another great advantage for me was that I was able to automate the creation of new records, and most of the navigation, by creating only a few scripts.
By adding a couple of extra steps to “create a record if there isn’t one,” I’m able to create the help file screens as I go. This allows me to work on it as I’m developing the other files, bit by bit, then organize it later.
This last feature, the ability to easily organize the Help file into separate “chapters” with navigation is easy in a records-based file, but difficult in a layout
based one.
Also, as I said, since the text is in a field, it is searchable. Text typed in Layout mode is not.
Navigation
Both of the methods could use a very similar navigational system. The main difference would be in the last steps: in the layout-based method it would be Go To Layout, a different layout almost every time; in the other it would be Go To Related Record.
(Well, the 2nd method could go to different layouts too, but it would generally be same one, the Help Text layout.)
In both cases the information they would use would be held in 2 global fields, passed from the file they came from, File Name g & Layout Name g.
I can see that I better get down to some specifics here; there’s only so much you can convey with words. I will describe method 2, records-based help.
Help File
In the Help file, create the 2 global fields just mentioned above. Also create similar regular text fields, File Name, and Layout Name.
Now 2 more fields, both concatenated (put together) calculation fields:
File|Layout Name c = File Name & Layout Name
File|Layout Name gc = File Name g & Layout Name g
(I use my own “suffix-based” naming system. “gc” in this case means “calculation field using global fields,” to me anyway. It’s so they still sort alphabetically, but I can tell them apart easily.)
Create a self-relationship between them.
File|Layout Name gc = ::File|Layout Name c
This allows me to go directly to a particular record. Each has its own File|Layout Name c.
While you’re at it, create another relationship, in this file (I’ll tell you later).
File Name g = ::File Name
One more field, a Constant=1 calculation field. Most files should have this.
Other Files
After creating the Constant fields (above), create relationships between each and its counterpart in the Help file.
Message Balloon
Now we’re about ready for the script to go to the Help text. But I like to display a message first when someone clicks on a Question mark icon. This allows a quick display of about 3 short lines of text. This may be all the person needs.
There are also a couple of buttons. The 1st button on the right is the default “OK,” which simply dismisses the dialog if you don’t tell it to do anything else.
The 2nd button is “Cancel” by default, but I change it to “Help!.”
I attach this 2nd choice to a script that goes to its record-screen in the Help file. Unless there are unusual situations, all the message scripts in a file call the same Help–> script.
But, each Question mark will display a different message, it needs its own little script (though you could use the same one on different layouts).
Each is formatted as a Button, with its script attached.
The 1st step in each script is:
Show Message [“Whatever you want to say”]
If [“Status(CurrentMessageChoice) = 2”]
Perform Script [“Help –>”]
End If
Because all the messages call the same Help –> script, you can just duplicate one to create another. The only thing you need to change is the message text.
Sometimes you might not want to tie a balloon to the Help file. In that case, just delete the “Cancel” or “Help!” text, so there’s no Message Choice 2; they’ll only get the “OK” button, which just dismisses the message.
Space Bar Tip (Optional but useful)
Highlight the step in the script, hit the space bar to open the message dialog, then hit Clear and start typing.
This trick works on lots of other steps, to open the first dialog (If, Go to Field, Set Field, Copy, Comment).
It also works to transfer a highlighted step from the Steps list (on the left) over to the Script list.
Example:
Open ScriptMaker; the Steps are outlined (Tab toggles), type “t” (highlights Toggle Window), hit the space bar to transfer.
Hit “t” twice to select Toggle Status Area (this only barely works in v.4; not very responsive, but better than nothing).
Try it. Your wrist will love you (esp. if you have one of these “pucky” mice).
I label all the message scripts with what layout they’re on, what they’re about (1
2 words) and an extra word “Message,” putting them all at the bottom of the Scripts Menu so they’re out of the way and don’t get mixed up with the other scripts.
This may seem overkill, but sometimes you change something in the program, and you need to find that message later and change it.
Help–> Script
This script lets the Help file know which record to go to, by setting the file name and layout name into its global fields.
It is specific to each file; the first step sets the file’s name into the global.
The layout name is dynamic and will set itself.
Set Field [“HelpFile::FileName g”, “”Contactss””]
Set Field [“HelpFile::LayoutName g”, “Status(CurrentLayoutName)”]
Perform Script [Sub-scripts, External: “HelpFile”]
Comment [“Go to Text <–Files”]
Help File: Go to Text <–Files Script
Enter Browse Mode []
Exit Record/Request
Go to Layout [“Text”]
Toggle Window [Zoom]
If [“IsValid(File|Layout gc::Constant)”]
Go to Related Record [Show, “Self\FileName g”]
Go to Related Record [“File|Layout gc”]
Else
New Record/Request
Set Field [“FileName”, “FileName g”]
Set Field [“LayoutName”, “LayoutName g”]
Go to Field [“TextContents”]
End If
The globals have already been set from the other file, but you need to Exit.
If [“IsValid, etc.”] checks to see if there is a record for this layout.
The File|Layout gc field is related to the File|Layout c field, which uniquely identifies each record.
If there isn’t a record for this combo it makes one; it fills in the identifying names, so the next time you click that Help message button in the other file, it will come back here.
A great feature of this method is that you don’t have to do anything at this point. You can just return to the file, and come back later to write the help text. Its space will be waiting; you can even search for empty records.
The reason for the “Go to Related Record [Show, “Self\FileName g”]” step is to first locate all the records for that file. It’s just a nice step so you can let people know how many there are and easily navigate between them with arrows.
The next step does not have the “Show” box checked, so the set remains.
Return –>Files
My basic philosophy of Help files is that, no matter how much moving around you do once you get to the Help file, when you click a Return button, you end up back in the original file where you left it.
It’s OK to explore the Help file, but you don’t want to lose your place in the regular files.
I used to have a long script in the Help file to return to the proper file. It used a series of “If” steps. You can’t “Go to File [“File Name”] in FileMaker, or even “Go to Related Records [“Relationship Name (from a field)”]. The file name has to be typed in for each file. Each “If” group has to be duplicated for each new file.
If [“FileName = “Contactss”]
Perform Script [External, “Contacts”]
Comment [“Refresh, Halt Script <–Help”]
End If
If [“FileName = “Jobss”]
etc., etc..
Then someone on the mailing list came up with the simple obvious solution.
Just hide the darn Help file! Duh.
Toggle Window [Hide]
Attach it to an icon. That’s it. You’re back wherever you last were.
I’m not sure how this would play out cross-platform, as I’ve heard Windows has a nasty habit of minimizing your windows when you leave them; so the one you left might be shrunk. In that case, use the If steps and Toggle Window [Zoom], Halt Script when you get there.
The simple Toggle Window [Hide] also doesn’t work so well if you let people open the Help file all by itself. When they click to return, there will be no window left open.
Go to a Specific Layout from Help (Optional)
You’d also need the “If” steps if you wanted to ignore my philosophy, and go to the file and the layout connected to the specific Help text you were reading.
The file name would have to be hard-coded, but the layout name could be set into a global in the Help file.
After you were in the other file, you could reach back (via any relationship) to get the Layout Name g and set it into a local global Layout Name g field.
Other File Script:
Set Field [“Layout Name g”,”Help Constant::Layout Name g”]
Exit Record/Request
Go to Layout [“Layout Name g”]
Organizing the Help File
As I said, one of the advantages of the records-based method is that you can better organize the Help file.
You can create a kind of “table of contents,” using a portal based on a self-File Name g relationship.
Put the global File Name g field over a portal based on the relationship. Field Format it as a Pop-up List, using values of the File Name field.
Choosing a different file name will show its records (Layout Names) in the portal.
Put a button over the Layout Name to run a script to Go To Related Record [“Self-File Name”].
Graphics in the Help File
The Help file can also be used as a graphics storage file for all the other files, for common buttons, etc., holding the graphics in global fields on a Graphics layout, accessible via a Constant=1 relationship to the Help file.
One good reason to do this is that it allows the other files to be saved as Clones. All global fields in those files would be lost at that time.
The Help file hopefully doesn’t ever need to be cloned. Just in case, you can keep a regular layout graphic of the button in there too.
If you have another file for a Main Menu, a 1-record file, then it would be better to keep the graphics in regular container fields in that file.
The Question Mark is special. The question marks that you see in all the other files are actually just one field in the Help file. It is a related field, not local to the other files. I just pasted it in from the Help file, then re-targeted it (by double
clicking). In the Help file, it is an unstored calculation field, with a container result, Question Mark c.
The original Question Mark graphic sits in a hidden global container field, Question Mark g. You can paste whatever graphic you want in there (of the same size or smaller). I made it big and clunky for visibility.
The calculation to show it depends on a value in the global number field, Question Flag. It is Field Formatted as a checkbox on the main layout.
This allows a “preference” choice to hide the Question marks in all the files with one click. The messages still work if you click in the right place, which is either a bug or a feature; let’s call it a feature 🙂
Best of Both Worlds
It’s quite easy to combine the two methods, for the ultimate in flexibility. Use the records-based method, but create a few special layouts in the Help file for items that don’t belong to any layout in particular in the other files, that are more of an overview of the whole system.
Examples of this would be large graphics, such as flow diagrams showing the system itself, long dissertations about the general purpose and use, or graphic “snapshots” of various reports possible, etc..
Each of these could get their own layout, with buttons for navigation, a separate system from the one for the records, in its own space on the main Help screen.
Or they could just have special Go To Layout steps.
By the way, all these navigation techniques could apply to other things than help files, for those of you in quest of the omniscient omnipresent “Back” button.
And that’s all folks.
Fenton Jones
Fenton Jones is a FileMaker database designer and consultant, based in San Diego, CA. FileMaker is a cross-platform rapid-development tool for affordable relational databases. If you have need of a FileMaker Pro expert, please be sure to visit his home page at http://www.fentonjones.com
Leave a Reply
You must be logged in to post a comment.