Help mode -- opinions? issues?

[kennedy]

How do you all provide Help on your UI's?

IDEA 1) I started providing little round "?" buttons that would Show Message with help info. But Show Message restricts itself to short messages (5 or 6 lines) and I don't like when I have 4 "?" buttons up, one for each section.

IDEA 2) To solve the first issue, I can put the Help messages up in a separate layout. However, that takes the user out of context. Its better to popup the help off to the side so the user can continue looking at what they're getting help on.

IDEA 3) So, I am thinking of providing a "?" help button that sets a global to true,

and then all my buttons check that global and if true simply Show Message

with info about what that button does. That'll keep the messages naturally much shorter (so they fit), and would structure the documentation close to the command its documenting. And just one generic "?" button will do.

HOWEVER, good UI design would demand such a "mode-changing" button make a significant visual change... either the cursor changes to a big "?" graphic or the whole layout grays or the buttons all turn color... or something.

WORSE, this would only work easy on the buttons. Clicking on a field would still behave normally. And thus, I'd need to do something more to make that work decent.

IDEA 4) Searching this forum did find one idea on this: back in 2000 a newbie asked if there was a way to get Help Balloons to popup when you leave the mouse over something for a while. That would be sweeet... but it doesn't appear there is a mechanism to handle the mouse-over behavior. However, the one response could be adapted as a solution to the issues of IDEA 1 and 2 (put the help in buried fields in the layout itself, and then display the help by "entering the field")... though it wouldn't be the most obvious user mechanism.

QUESTION: How do you guys provide help on your UI's to your users???

Thanks for the insight/experience!

[SteveB]

I generally split an input layout in half (logically), either vertically or horizontally where I try to arrange the fields in logical groups. Lets say we've split the layout down the center. I put help buttons on both sides . If the user clicks the left help button, I transfer to a layout that has the help information in the right panel, with the left panel fields still active and enterable. Even if there might be 2 or more logical groupings of fields in the left panel, I'll show the help for all these groups. The help stays on the screen while the user fills in the data. When done with the help screen, I have a close box that takes them back to the original layout.

[LiveOak]

A couple of ideas. First, fields can be assigned scripts, there is nothing magical or unique about the "button" object in this respect. You can place notes behind transparent field e.g. "enter name here". Help message can be placed in any vacant area of the screen and turned on and off with either a calculated field or the portal hide trick.

-bd

[kennedy]

How about this idea:

I am currently keeping a blank area between my tab-bar and the main content. Its tall enough for a row of buttons to appear. When you go into Find mode, that's where the Find-related buttons appear.

So, I could have it when you hit the round "?" help button, that blank area displays:

"HELP MODE: Click on a button or field label to display help.

Click here to exit help mode and actually use those buttons."

And then all my buttons and field labels can have a check for being in Help Mode, and if so, they fill in a global HelpString, that replaces the above. So then the area says:

"HELP MODE: The XYZ button will do X on Y unless Z.

Blah blah blah. Click here to exit help mode."

The field that is showing that will be a button that when clicked, clears the HelpString and sets HelpMode to false.

ISSUE: If you click on a normal field and edit it and so on... it won't take you out of Help mode. If you click a button, you may just get help info... I guess that's okay.

ISSUE: I am probably limited to two long lines of help info... wouldn't want much more real estate than that reserved for mode specific stuff.

Thoughts? Issues? Opinions?

Sounds cool to me. (A bit like my beloved Lisp machine. ) Thanks!

[CobaltSky]

I suggest you consider the use of the 'Status(CurrentModifierKeys)' function as the point of access to your help messages.

Set all your fields as buttons with scripts attached, which run along the lines of:

If ["Status(CurrentModifierKeys) = 1"]

Show Message ["This field is intended to display the results of...."]

Else

Go to Field ["ResultDisplay"]

EndIf

Include a similar conditional statement on all of your button scripts so that if they are clicked with the shift key held down, they show an explanatory message rather than performing their usual function.

Then you only require a single "?" button, which displays the message "Hold the shift key down while clicking on an object on the screen to view help text about that object".

If you find that the show message dialog provides insufficient space, I suggest that instead, you create a global field (let's call it 'gHelpRef') in your main file, plus a related help file, where the global field is matched to a recordID field in your help file. Then set each script step (including the scripts attached to your fields) along the lines of:

If ["Status(CurrentModifierKeys) = 1"]

SetField ["gHelpRef", "17"]

Go to related record

Perform Script [sub-scripts, External: "helptext.fp5"]

Else

Go to Field ["ResultDisplay"] ...or other script steps, as desired.

EndIf

(where the number 17 is the record number of the record in the helptext file which relates to the particular item the script will be attached to)

The helptext file needs only two fields in each record - recordID and HelpText, one layout and a button (defined to halt the current script and then hide the window). The sub-script in the helptext file should run along the lines of:

AllowUser Abort [off]

Toggle Window [Zoom]

Refresh WIndow [bring to front]

Loop

Pause/Resume Script [ ]

End Loop

Because the sub script called from the main file will get stuck in a loop as soon as the help file is at the front, the help window will work like a dialog (will not allow the user to leave by clicking elsewhere - they will have to click on the button you provide in order to continue). However unlike a dialog, you will have control over the size and appearance.

[kennedy]

Thanks for the explicit response... you actually answered a few questions... like how do you implement dialog-like behavior... I've been thinking along those lines, but I figured one of you smart guys could tell me the *right* way. Thanks.

I hadn't thought of the use of modifier keys... good idea... I need to think what is more transparent... I see three options now... I'll come back to that...

Show Message doesn't provide enough text space... but going to a entirely different layout would, it seemed, be fairly disruptive and often occlude the thing you were trying to get help on. So, I went with a middle solution... I provide two lines of 10pt text all the way across my standard layout... about twice what Show message can hold... and it NEVER occludes anything. When not in use, the Help message space vanishes leaving a nice uncluttered feel. (I do use Show Message for my Find buttons that appear in the same area that my help text appears.)

Now to the UI design options you have given me:

1) Leave my buttons bringing up help when in Help mode. The user had to click into help mode and thus knows where the help text will appear. No need to use an extra hand to hold a modifier key and no need to remember which modifier key. And that leaves the modifiers for other "advanced" functionality on the buttons.

2) Switch to using a modifier (SHIFT) key to bring up help. I can have it automatically enter Help Mode (make the Help Text area visible). Once you learn it, then you can always get help with one click (well, one modifier key press and one click). Further, and more important, you can leave the help text visible and start doing the commands. Then when you're done with the help, you can dismiss it. That seems very useful, though it may also annoy some users if they forget how to make the help text go away or if they hit SHIFT-click accidentally.

3) Display help when pressing the modifier AND in Help Mode. So, its like #2, except it won't automatically make the Help Text visible... you have to explicitly hit the ? button to make it visible, and thus its far more likely you know how to dismiss it. But once you're in Help mode, you can continue working with help displayed.

Opinions on which is better?

Thanks.

[CobaltSky]

My vote would still go to number 2, provided you set it up so a shift-click on the help area itself produces text which explains how to make it go away.

[kennedy]

I agree... especially after I considered my Find buttons (which appear in the same area). The Shift-click approach allows me to use the same mechanism but with popup Show Message in that case. Nice consistency of feel, without having to spend a lot of real estate for absolute consistency. In general, I can be absolutely consistent with shift-click. AND it avoids having a "mode"... which I didn't mention before... a user who doesn't notice the help area after accidentally hitting ? might be totally confused when nothing works anymore.

For other readers, I used a slightly different test:

If ["Mod(Status(CurrentModifierKeys), 2)"]

which just tests for the shift key, no matter what else might be pressed. That will generalize better if I later start using the other modifier keys for advanced or alternate functionality. If true, then I set my global HelpText:

SetField [ "G::HelpText", "G::HelpForThisButton"]

where G is the relationship established to my Globals file.

Thanks for the feedback! I think its going to work great!

[CobaltSky]

A further note regarding the modifier key approach - I find it best to conduct a 'dual' test for:

Status(CurrentModifierKeys) = 1 or Status(CurrentModifierKeys) = 3

to trap for the possibility that the caps lock key is engaged. If you don't do this, help features won't work with the caps lock key 'on' (naturally) and users will (equally naturally) insist there is a malfunction .

[kennedy]

A further note regarding the modifier key approach - I find it best to conduct a 'dual' test for:

Status(CurrentModifierKeys) = 1 or Status(CurrentModifierKeys) = 3

to trap for the possibility that the caps lock key is engaged. If you don't do this, help features won't work with the caps lock key 'on' (naturally) and users will (equally naturally) insist there is a malfunction .

I thought about that... but for this, getting stuck in Help Mode because the caps lock key happened to be on seemed to be far more problematic. I'm sure an occasional user will complain that Caps Lock ought to work like shift for help... but they won't get mad. The user who spent 10 minutes trying to figure out why the program wouldn't do anything but change the help message because he didn't know the Caps Lock was on will be pissed!

And for those readers learning scripting, I prefer to use the following shorter test for both:

Mod (Status (CurrentModifierKeys), 4) # tests SHIFT or CAPS LOCK

Mod (Status (CurrentModifierKeys), 2) # tests SHIFT only

FWIW.

[DGMags]

For simple help with data entry, I think the "Invoices" sample file that shipped with FileMaker 4 used an effective technique. Clicking the help button switched you to a help layout which duplicated the data entry form from which you came. The background was lightened to distinguish it from the data entry screen, and the fields were set to disallow entry. On top of the form, simple yellow text boxes (like Post-its) and lines acted as a call-outs or balloons, pointing to and explaining the controls.

The user could simply toggle between the view in which they entered data and the view which offered explanations about the controls. The help view even showed the data they had entered so far. No muss, no fuss.

[kennedy]

To see the solution I ended up with, check out my Starter Template file in Sample Files:

http://www.fmforums.com/threads/showflat.php?Cat=&Board=files&Number=46219&page=0&view=collapsed&sb=5&o=&fpart=1

I use the Help Text area for several purposes, including status messages from scripts, as well as help on buttons. Just a follow-up, FWIW.

[CobaltSky]

Missed this one first time 'round also...

I thought about that... but for this, getting stuck in Help Mode because the caps lock key happened to be on seemed to be far more problematic. I'm sure an occasional user will complain that Caps Lock ought to work like shift for help... but they won't get mad. The user who spent 10 minutes trying to figure out why the program wouldn't do anything but change the help message because he didn't know the Caps Lock was on will be pissed!

The Status(CurrentModifierKeys) function returns the sum of all currently depressed/engaged modifier keys. Shift equals 1, Capslock equals 2, Shift+Capslock together equals 3.

The test I suggested was therefore not one that would cause the user to get stuck if the caps lock was down. The caps lock returns 2, not 1 or 3. The only way to get a 1 is with the shift key on its own, and the only way to get 3 is with both the caps lock and the shift key depressed.

My point was that with the dual test (1 or 3) the help feature would not be disabled whenever the caps lock was engaged.

And for those readers learning scripting, I prefer to use the following shorter test for both:

Mod (Status (CurrentModifierKeys), 4) # tests SHIFT or CAPS LOCK

Mod (Status (CurrentModifierKeys), 2) # tests SHIFT only

Use with caution. These tests are only useful if you want to test for shift or capslock in combination with any other modifier keys, as they will be triggered by a host of other modifier key combinations also.

For example, it is simply not true to say that "Mod (Status (CurrentModifierKeys), 2) tests SHIFT only", as it also tests positive (ie returns a non-zero value) for the following combinations:

Shift+Capslock

Ctrl+Shift

Ctrl+Shift+Capslock

Option(Alt)+Shift

Option(Alt)+Shift+Capslock

Option(Alt)+Ctrl+Shift

Option(Alt)+Ctrl+Shift+Capslock

Command+Shift

Command+Shift+Capslock

Command+Ctrl+Shift

Command+Ctrl+Shift+Capslock

Command+Option(Alt)+Shift

Command+Option(Alt)+Shift+Capslock7

Command+Option(Alt)+Ctrl+Shift

Command+Option(Alt)+Ctrl+Shift+Capslock

Mod (Status (CurrentModifierKeys), 4) returns a non-zero result for an even longer list of suspects.

[kennedy]

For example, it is simply not true to say that "Mod (Status (CurrentModifierKeys), 2) tests SHIFT only", as it also tests positive (ie returns a non-zero value) for the following combination

Ahh, the imprecision of the English language. Yes, when I said "tests SHIFT only", I meant it only depends upon the SHIFT key... if down, its true; if up, its false... no other key affects the test. I did NOT mean "it tests that ONLY SHIFT is down".

For this purpose, triggering HELP, I would want SHIFT to always mean "don't do it, just tell me what you'd do". So, then if I have special functionality on CTRL-click, doing SHIFT-CTRL-click should just tell me about it. That's *my* UI design preference, as I like users to feel safe requesting HELP on anything. But its certainly not the only reasonable design choice.

BTW, normally when CAPS LOCK is down, pressing SHIFT temporarily turns OFF capitalization... that is, CAPS LOCK reverses the polarity of SHIFT. So, for some things, the appropriate calculation would be to test for =1 XOR'd with =3. FWIW.

Anyway, thanks for clarifying... my comment may have confused someone.

[CobaltSky]

So, for some things, the appropriate calculation would be to test for =1 XOR'd with =3.

When more than one modifier key is depressed/engaged, Status(CurrentModifierKeys) adds the values and returns a single compound numeric value, either a 1 or a 3 (or whatever).

XOR is "true if either of the expressions (but not both) is true..."

There could be no call for XOR with Status(CurrentModifierKeys) tests, because there can only ever be one result returned in any instance.

[kennedy]

There could be no call for XOR with Status(CurrentModifierKeys) tests, because there can only ever be one result returned in any instance.

If I wanted Shift to reverse polarity when Caps Lock is on, then I would do:

Mod(Status(CurrentModifierKeys), 2) xor Mod(Status(CurrentModifierKeys), 4)

which would return true if SHIFT is down and CAPS LOCK is up, or if SHIFT is up and CAPS LOCK is down... but would return false otherwise (including the case when both are down). That would work the same no matter what other modifiers are pressed at the same time.

Alternatively, you could do:

Status(CurrentModifierKeys) = 1 xor Status(CurrentModifierKeys) = 3

if you wanted the above only if no other modifier keys are pressed; and false if any other modifier keys are pressed.

But I think we've probably beat this poor horse enough... every test suggested could have reasonable uses... just depends upon what behavior you're wanting.

Cheers.

[kennedy]

Please ignore that prior post... brain was not functioning... too little sleep last night... I see exactly your point...

In order to XOR the two bits, you must first pull out the two bits individually... which is what I had in my head I was doing... the proper expression would look like this:

Mod(Status(CurrentModifierKeys), 2) XOR (Mod(Status(CurrentModifierKeys), 4) - Mod(Status(CurrentModifierKeys), 2))

I am too used to playing with bitwise operators in C/C++ when given bitwise boolean values.

Cheers.