Procedures and alternative input

A procedure starts from a known state and ends with a result the reader can check. Name that result in the heading. State the supported product version, platform, and prerequisites when they affect the steps.

Write the main path

Give the reader one dependable route through the task. Number actions that must happen in sequence, and start each step with an imperative. Name the location before the action when the current location is unclear.

Keep one action per step. Its immediate result can follow in the same item: the reader should not mistake an automatic response for another instruction. Include the final action that commits the change, such as choosing a command or applying a setting, when the task requires it.

Separate independent actions even when they occur in the same dialog. Use a menu path only for a real sequence of menus, not as shorthand for several unrelated controls. Preserve displayed labels and explain exact input outside any punctuation that the reader should not type.

There is no universal maximum number of steps. If a sequence is difficult to follow, divide it at meaningful results and give each stage a useful heading. A one-action task can be a sentence; it does not need a numbered list.

Put conditions before decisions

Place prerequisites before the procedure and warnings before the affected action. A recovery instruction arrives too late if it follows the destructive step it could have prevented. Keep necessary conditions in the main sequence instead of hiding them in a note.

For an optional action, say when it is useful and mark it optional before the instruction. For mutually exclusive choices, explain which condition selects each branch. Resume the common sequence where the branches converge.

Distinguish failure from partial completion. Tell the reader which result to inspect and what to do if it differs. Suggest a retry only when repeating the action is a supported recovery and does not duplicate a submission or lose work.

Document input methods accurately

Describe the task or resulting state when it works across input methods. Name a gesture when performing that gesture is the point of the instruction. “Select the glyphs” states a result; “Drag a selection rectangle around the glyphs” teaches a particular method.

Use the interface action terms consistently. Do not substitute select for press when teaching a physical keypress, or imply that every pointer action has an equivalent touch gesture.

Keep the most useful method in the main sequence. A short alternative can follow the affected step. If the entire procedure differs by platform or input method, give each version a clear scope and its own sequence. A shortcut reference can collect verified alternatives without interrupting every task.

Test the keyboard route and its focus order where keyboard access is supported. A visible access-key marker does not prove that the documented sequence works on another keyboard layout. Do not invent shortcuts to fill a table.

Worked example

This exercise describes a fictional application. Its export dialog provides the controls shown below and refuses to overwrite an existing filename. Those assumptions belong to the exercise; they are not FontLab product facts.

Export a PDF

Open the document you want to export.

1. Choose File > Export.
2. Choose PDF in the Format menu.
3. Enter a filename in Name.
4. Choose a destination folder in Destination.
5. Click Export.

The PDF appears in the destination folder. If the application reports that the filename already exists, enter a different name to keep both files.

The heading identifies the result, the introduction states the starting condition, and the final sentence supplies a check and a supported recovery. Each action uses a control from the exercise brief.

Test the written procedure

Follow the exact steps from the declared starting state. Use the written labels, values, and paths instead of filling gaps from memory. Check optional branches, cancellation, likely failures, and the final result against the documented scope.

If the environment is unavailable, record that limitation in the review. Do not call a procedure verified because its grammar or Markdown passes a check. See developer examples for executable code and command testing.