Sequential Hierarchical Menus

Finally, sometime in the late-70s, some very clever programmer came up with the idea of offering the user a list of choices. You could read the list and select an item from it the way that you choose a dish at a restaurant by reading the menu. The appellation stuck, and the age of the sequential hierarchical menu began.

The sequential hierarchical menu enabled the user to forget many of the commands and option details required by the command-line interface. Instead of keeping the details in his head, he could read them off the screen. Another miracle! Circa 1979, your program was judged heavily on whether or not it was menu-based. Those vendors stuck in the command-line world fell by the wayside in favor of the more modern paradigm.

Although the paradigm was called menu-based at the time, we refer to these menus as sequential and hierarchical to differentiate them from the menus in widespread use today. The old pre-GUI menus were deeply hierarchical: After you made a selection from one menu, it would be replaced by another, then another, drilling down into a tall tree of commands.

Because only one menu at a time could be placed on the screen and because software at that time was still heavily influenced by the batch style of mainframe computing, the hierarchical menu paradigm was sequential in behavior. The user was presented with a high-level menu for choosing between major functions as, for example:

1. Enter transactions

2. Close books for month

3. Print income statement

4. Print balance sheet

5. Exit

After the user chose a function, say 1. Enter transactions, he would then be prompted with another menu, subordinate to his choice from the first one, such as:

1. Enter invoices

2. Enter payments

3. Enter invoice corrections

4. Enter payment corrections

5. Exit

The user would choose from this list and, most likely, be confronted with a couple more such menus before the actual work would begin. Then, the Exit option would take him up only one level in the hierarchy. This meant that navigating through the menu tree was a real chore.

Once the user made his selection, it was set in concrete—there was no going back. People, of course, made mistakes all the time, and the more progressive developers of the day added confirmation menus. The program would accept the user's choice as before, then issue another menu to enquire: Press the Escape Key to Change Your Selection, Otherwise Press Enter to Proceed. This was an incredible pain, because regardless of whether you had made a mistake or not, you needed to answer this awkward and confusing meta-question, which could lead you to make exactly the kind of mistake you were hoping to avoid.

Such menu-based interfaces would be judged terrible by today's standards. Their chief failing was the necessary depth of the hierarchy. This was coupled with a striking lack of flexibility and clarity in dealing with their users. Still, they were better than command lines, where you had to remember each operand. Sequential hierarchical menus lightened the users' memorization burden, but forced them to laboriously navigate an archipelago of confusing choices and options (just like most Web sites do today). They, too, had to give way to something better.