Sub-dialogs and Toolbars
to Make Your Document "Customizable"

 Demo: Ctrl + right-click 

 Demo: IE only 

If you want to make your documents highly communicative, you should include as much interactivity as possible. Yet, all of it should be easily accessible, ideally even customizable. This article will show you an easy way to do that, with the least possible coding effort to the author (= you!).

Including Interactivity to your online document is not a merely technical problem:

You will know it by your own experience: Much more memorable is an information that you  acquired  yourself, by your own activity (be it rather  playful  or, for that matter, even slightly  exacting ) .

Then, however, each function should be easy to access:

What good is it to offer rich functionality, if the individual functions are hard to access?

Moreover, the controls for accessing the functionality should not occupy so much of the precious screen space that hardly any room is left for applying it!

Knack to get around that:  FloatingMenu  (see my article FloatingMenu - A Host of User Interactivity in a Nutshell)

There are, however, specific things to keep in mind for optimum use of a FloatingMenu. What does Including Interactivity really mean?

Including Interactivity

Drawback to a FloatingMenu (just as to menus in general):

To users unfamiliar with computing, it requires a new way of thinking:

• First, the desired function is buried somewhere deep down in any of the sub-menus.
• Then, when you're lucky, you find what you need, apply it - and then it's gone again.
• Some time later, when you need the same function once more, you have to rummage through all the sub-menus again.

Remember: With online documents in particular, you just cannot expect that every reader will know how to handle your menu!

=> Leave it to the discretion of your readers to  detach  (= move away) a toolbar or to  resize  it!

So, when they know of a function that they will need it again in the near future, they have it right at hand (sacrificing any part of the screen space that is not so urgently needed at the moment).
At any time they can move the toolbar to another place, resize it, or close it when it's no longer needed.
This is called to " customize ": To prepare anything such that all its 'customers' (in this case: readers) can modify the appearance according to their individual needs.

The toolbar introduced in this article has the following features.

Click a list item if you want to read more about it:

• Contents
• Detaching
• Moving
• Resizing
• Tooltips
• Auto-Scrolling
• Coding
• Semi-permanency
• reset all

Subdialog ó Toolbar

 Sub-dialog  and  Toolbar  compare as follows:.

 Sub-dialog : Any collection of controls for fine-tuning an interactivity, popping up when the mouse is moved over the pertaining menu item, closing when the mouse is moved over another item.

 Toolbar : Minor sub-dialog that can be  detached  from the menu, dragged to any other place, and resized if needed.

In detail this means: (Click the list item you want to know more about)

• Contents
• Detaching
• Moving
• Resizing
• Tooltips
• Auto-Scrolling
• Closing
• Semi-permanency

Contents

The contents of a sub-dialog or toolbar can be anything you think useful for providing interactivity. Anything you can code in HTML: Mainly <INPUTs, but also text, images, tables, etc.

For good  usability  you should be sure that the whole of contents elements is just what the readers will need for handling the interactivity you provided in your document: not less, not more.

A few ideas as to decide what elements should be included:

• Consider each of the situations from what a reader could arrive at your sub-dialog / toolbar.
• What will they know at this time? (No point in offering an input that the readers don't know what it's good for!)
• What will they expect to be able to do in your sub-dialog/toolbar? (Are all the inputs available they will need for that?)
• If applicable, try to make it out if specific  reader segments  are to be distinguished. For each segment, think about: What will they have done before they came to your sub-dialog/toolbar? Why will they have decided to open it?
• If you think that some inputs will be useful only for specific segments, make them optional: Only when a reader clicks a button, some additional inputs will pop up. (Does it make sense to lump those inputs together to an extra sub-dialog/toolbar?)

Detaching

A sub-dialog is a permanent part of the FloatingMenu. It is opened when the cursor is moved onto the pertaining menu item. Then the readers have the choice

•  to move the cursor onto the sub-dialog:  Then they can handle its elements in the respective way. Finally, when they click any of the closing buttons (usually "OK" and "Esc"), the respective action is performed and the sub-dialog is closed.
  (By an option  onmouseout=  you could make a sub-dialog performing any action once the cursor is moved out - see my article FloatingMenu - A Host of User Interactivity in a Nutshell.)
•  to move the cursor further on to another menu item:  Then the sub-dialog will be closed again. The effect pertaining to the other menu item will be triggered. (For the different kinds of menu items see FloatingMenu - A Host of User Interactivity in a Nutshell.)

A toolbar, however, first behaves just like a sub-dialog. However, when the cursor is moved onto it and the left mouse button is pressed (without releasing it!), the toolbar can be dragged to any other place in the client area of the screen. (That's called "to  detach  the toolbar".)

Once a toolbar is detached, it assumes a different behavior:

• At any time a toolbar can be moved to any other place in the client area of the screen.
• As well it can be resized, rearranging the contents elements automatically.
• To each contents element you can provide tooltips to give the readers a hint.
• Auto-Scrolling will make sure that the toolbar is available wherever the reader scrolls to.
• A toolbar can be closed, thus making it part of the menu again.
• For extra reader friendliness you can make toolbars semi-permanent.
• To save your readers' nerves, it might be a good idea to include an item  reset all  in your FloatingMenu.

Moving

At any time a toolbar can be moved to any other place in the client area of the screen. To do that, move the cursor onto the toolbar. When the cursor is  move  (), press the mouse button and, without releasing the button, move the mouse. The toolbar will move along, until you release the mouse button. (That's called "dragging".)

If you happened to move a toolbar at any unfortunate place, you can easily "reset" it:

• Move the cursor onto the "close"-button in the upper right corner of the toolbar, until the cursor turns to  hand  (). Press the left mouse button.
• The toolbar will disappear. When you launch the FloatingMenu again and move the cursor onto the pertaining item, the toolbar will pop up again just like a sub-dialog. Now it can be detached or resized again.

Resizing

At any time a toolbar can be resized, thus rearranging the contents elements automatically. To do that, move the cursor to the inner side of a toolbar border. When the cursor turns to a  resize-arrow (N, S, E, W, NE, SE, SW, or NW), press the mouse button. Now, without releasing the button, move the mouse. The respective toolbar border will follow the cursor, until you release the mouse button. When the toolbar is getting too narrow to accommodate all the contents elements in one row, the last element will automatically move down, and vice versa.

If you happened to resize a toolbar to any unfortunate size, you can easily "reset" it:

• Move the cursor onto the "close"-button in the upper right corner of the toolbar, until the cursor turns to  hand  (). Press the left mouse button.
• The toolbar will disappear. When you launch the FloatingMenu again and move the cursor onto the pertaining item, the toolbar will pop up again just like a sub-dialog, in the same size it was before closing. Now it can be detached or resized again.

Extreme cases you can remedy by reset all.

Tooltips

 Tooltips  are brief hints as to a contents element (what it is good for, notes how to handle it, etc.) Usually they are 1-line only, but you can give multi-line hints by separating the lines by "\n".

Tooltips are popping up when the reader moves the cursor onto a questionable contents element and has it rest there for about ½ seconds. It is displayed for some 5 seconds, unless the cursor is moved away before.

You can easily add tooltips to a contents element. For example:

• To a button, add attribute  ALT="…" :
  <INPUT type="button" ALT="…" … >
• To any other contents element, you can add a provisional tooltip as follows:
  1. Make sure that in the <HEAD> part of your online document you have the lines
     <SCRIPT SRC="OnlineComm.js"></SCRIPT>
     <LINK REL=stylesheet HREF="OnlineComm.css">
     (Usually you will have them anyway, if you want to apply the features described in this article.)
  2. Prepare a <DIV> holding all the information you want to give as tooltip (bracket it in <NOBR> … </NOBR>):
     <DIV id="…" CLASS="tooltip" STYLE="display:none">
     <NOBR> ... </NOBR> <!-- tooltip text -->
     </DIV>
  3. To the code representing the contents element, add an attribute  onmouseover="Tooltip(…)" 
     
     <DIV id="…" CLASS="tooltip" STYLE="display:none" onmouseover="Tooltip(…)">

Auto-Scrolling

Online Communication is different from writing on paper (see my article Online Communication - unlike Writing on Paper). One major difference is the limited screen size. On paper you can easily explain something extensively; then you can ask the reader to try it exterior to the printed document.

In online documentation the demo will - or, at least, "should" - be integrated in the text. At any time the readers can click a button combination and have the demo right at hand. But what good is it if they used the demo before already, detached a toolbar, and now they need just that toolbar again?

Therefore, a detached toolbar is made auto-scrolling:
It comes along automatically, wherever the reader scrolls to.
(This is true until the toolbar is closed.)

• Press the Ctrl-button and right-click. A FloatingMenu will pop up. When you move the cursor over its  Subdialogs  and  Toolbars  items, the pertaining sub-dialog/toolbar will appear. (Unless that toolbar was detached before, but then you will have it on screen already.)
• Move the cursor onto any toolbar and drag it away from the menu.
• If you want, you can  Ctrl+right-click anywhere on the white background - the menu will be closed. The detached toolbar is still on screen.
• Now, scroll to any other place in the document. (You can do that any way you like: By the arrow keys, the  PgUp- or  PgDn-key, by clicking in the screen's scroll bar, by dragging the screen's scroll bar thumb, by jumping via the SectionMenu in the upper-right corner, or by clicking on any of the internal links.) The detached toolbar will always follow, ever again to be located at the same place on screen.
• When you are finished, you should close the toolbar. Then it will be part of the FloatingMenu again. Otherwise it will always be on screen - and might obstruct your reading. (If you have several toolbars detached, reset all might be good for you.)

Auto-scrolling is working even when you link to a document with toolbars from an other document, be it to its top or to any inner section: All detached toolbars will have the same layout as when the document was closed before.
(This will take noticeable time, of course. So you should do that only if you are sure that your readers have computers with some performance!)

Closing

• The toolbar is closed, setting free the parts of the online document covered before.
• Invisible, the toolbar becomes part of the FloatingMenu again.

Semi-permanent Toolbars

Now, when the session is about to be closed, the locations and dimensions of all the detached toolbars will be memorized. Next time the document is opened, all of them will be restored just as they were before. They are working the same, as well:

1. They can be moved or resized,
2. they are auto-scrolling again,
3. when they are closed they will become part of the FloatingMenu again,
4.  reset all  works with them as before
5. when the second session is closed, their locations and dimensions will be memorized again.

reset all

A FloatingMenu with detached toolbars lying all over the place is a very powerful instrument to handle a host of interactivity. Yet for readers it is also but too easy to hurt themselves, with all the screen cluttered up with unwanted toolbars. To clear it up would be a nerve-racking ordeal.

So it just seems fair to provide a menu item  reset all . By clicking it,

• all the detached toolbars are closed
• the toolbars are resized to their original size
• the toolbars are becoming part of the FloatingMenu again
• the FloatingMenu is closed

 Result:  All the screen is clear again, offering the online document only, with the demo being hidden and in its original state.

The reader can continue as if nothing had happened.

Coding

In the <HEAD>-section of your document you need to include three code lines:

In file  Toolbar.js  there are many different functions included to help you in easy coding of sub-dialogs and toolbars. In addition, many of them can be combined. So in the demo I could have implemented an enormous number of sub-dialogs and toolbars.

However, what's the point of providing such a complex demo? This would only have had a deterrent effect!

Therefore, when you press the Ctrl-key and right-click anywhere in this article, a FloatingMenu is popping up with just one sample of each of the following methods (click on the list item you want to know more about):

1. SubDlg_functions
• Hard-coding
• Open Coding
• All-in-one Coding
2. Toolbar_functions
• Hard-coding
• Open Coding
• All-in-one Coding

Coding: Html_Functions

Coding sub-dialogs and toolbars can be done most efficiently by combining several pre-coded functions plus, if needed, some hard-coded HTML.

The most frequently needed contents elements have been pre-coded as Javascript functions generating the respective HTML code. Consequently they have been named with a prefix Html_ and a word indicating the contents element. Currently there are three classes of Html_Functions:

1. Html_Button()
2. Html_Select()
3. Html_OkEsc()

Click the item about which you want to read more.

Coding: Html_Button()

This function generates the HTML-code for implementing a button:

Coding: Html_Select()

This function generates the HTML-code for implementing a select or combo box:

Coding: Html_OkEsc()

This function generates the HTML-code for implementing a button pair: an  OK  button and an  Esc  button.

Coding: SubDlg_Functions

A sub-dialog can be coded most efficiently by functions

• SubDlg()
• SubDlg_Button()
• SubDlg_Select()
• SubDlg_OkEsc()
• SubDlg_End()

Function to generate the HTML-code for a button within a sub-dialog.

E	The parameters are the same as with function  Html_Button()

Function to generate the HTML-code for a select or combo box within a sub-dialog.

E	The parameters are the same as with function  Html_Select()

Function to generate the HTML-code for a pair of  OK  and  Esc  buttons within a sub-dialog.

E	The parameters are the same as with function  Html_OkEsc()

Function to complete a sub-dialog declaration introduced by function  SubDlg ()

E	Not to be used for all-in-one coding.

SubDlg_: Hard-coding

<SCRIPT>SubDlg(title,id[,options])</SCRIPT>
… … …  <!-- HTML code of contents elements -->
	:
<SCRIPT>SubDlg_End()</SCRIPT>

<SCRIPT>SubDlg(title,id[,options]);
…; …; …;  <!-- pre-coded functions -->
	:
SubDlg_End()</SCRIPT>

An example of this kind of coding you'll find when you spy on the source code of this article and search for  dlg0 .

SubDlg_: Open Coding

You might find it a bit awkward that, like in hard-coding, you have to carefully distinguish standard HTML code from pre-coded functions. So you have to watch out where a <SCRIPT>…</SCRIPT> bracket is needed.