7.11. UNDO
The obvious thing to do is to replace every arrow −→ in a state diagram with a symmetric arrow
←→ so that the user can, for any action, go back to the state the system just came from. This is
what we did in one of the first changes to the statechart above, so the user could undo accidental
channel changes. In fact a symmetric arrow like ←→ is actually two arrows (as it were, drawn ever
so close together) and by our rules for drawing diagrams, it requires two labels, one for each action
and it ought to be obviously two arrows.
Suppose the action is called a, then the original arrow would have been a→ between whatever two
states the action applied to. When the user undoes the action a they do something we might call aˆ,
then the double-headed arrow really should be drawn in full as
28
Perhaps you are thinking of buttons? Instead the user interface might be toggle switches. The
switch can be up or down, and the action is the user flicking the switch; then a and aˆ become up and
down. This is easy to draw, and looks nicer if we orient it so that up is up and down is down:
Up Dow
29
P28
We’ve discovered something rather fundamental. If you design a system that requires actions that
the user may want to undo, then a really easy and reliable way to do this is for those actions to be
associated with toggle switches. It is worth pointing out that ordinary buttons can simulate toggle
switches, and on some gadgets a pair of physicaly close buttons are often arranged so that they look
and behave like a toggle switch.
Let’s now prove a fundamental theorem, and one of deep importance. Suppose we have a system
with s two-position switches, what is the largest number of states it can have? It’s easiest to imagine
we have built the largest system with s switches, and we are going to add one more switch: how many
more states can we squeeze in? To all of the states in the largest system with s switches we can attach
a double headed arrow. The other end of this arrow would be wasted if it went back to one of these
states; instead it can point to a new state. Obviously by adding another switch, we can extend our
state diagram by exactly doubling the number of states. (If we more than doubled the number of
states, there would be some new states without arrows.)
If a system has no switches, it can do exactly one thing, namely whatever it is doing (and we have
no way of changing its mind). A no-switch system has one state. With one switch it will double its
number of states to two; with two switches it will double again to four; and so on. If there are ten
switches, the most number of states that can be controlled with be 2×2×2×2×2×2×2×2×2×2,
which is only 1024. In general, we can write this as 2s, and of course 210 = 1024.
Although ten switches is a decent number of switches, a thousand states is quite a small number
compared with the number states we’ve been used to dealing with in this chapter. Which means
switches are not a universal solution.
Here’s a statechart for a system which looks like four states. Now we know that it represents 24
or sixteen actual states if we drew it in full, without taking advantage of the statechart shorthands.
28dharrow.pdf
29updown.pdf
/ 133

10.8. TOOLS TO SUPPORT USER MANUALS
Look at the ? entries in this table: these are the only parts of the microwave cooker’s state machine
specification that the user manual required. Amongst other comments: the clear button doesn’t seem
to be helping much! (Probably Jonathan’s specification does not say what clear really does: it probably
clears a numerical timer setting that he wasn’t interested in.) Nevertheless, our generating a manual
and then automatically going back to the specification has exposed some potential bad design. If this
sort of manual is a good idea, then the clear button as presently defined is a design feature that needs
better justification.
Here is an extract from a manual generated for a more complex system, the JVC video recorder
from the last chapter again:
In the following states (play a tape fast forward; pause playing a tape; play a
tape fast backward) you can press

Play
to play a tape.
If you are playing a tape, but have paused it, additionally you may:
Press

Forward
to fast forward.
Press

Rewind
to rewind a tape.
In the following states (play a tape fast forward; play a tape fast backward) you
can press

Pause
to pause playing a tape.
If you are playing a tape fast forward, you cannot do anything else.
If you are playing a tape fast backward, you cannot do anything else.
This chunk of the manual would be ‘inside’ a section explaining how the buttons  Operate
(the badly
named switch on and switch off button) and  Stop/Eject
work, since they can be used at any time.Many other sorts of manuals can be generated too, and by creating them by programs systemat-
ically we can guarantee their correctness. We can also use the technique of going back from a good
manual to reappraise the specification. After all, if we have a good user manual, then the bits in the
specification that aren’t apparently needed are immediately suspicious features!
10.8 Tools to support user manuals
. We’ve shown how to write some ghastly English user manuals, lengthy but completely accurate and
correct user manuals. Unfortunately users probably wouldn’t find the manuals very helpful even
though they are correct: users need principles, rather than a manual that is so long it’s become a
usability issue all of its own.
P40
We can use such automatically generate sketch manuals to help technical authors to write better
and more accurate user manuals. We would write a program like the one we used above to generate
accurate but perhaps not best English into a database. The technical author’s tool would look a bit
like a multi-window word processor: one window would show generate manual — correct but maybe
not good English — and another window the current bit of the manual that the technical author is
writing. The technical author would rephrase the English in their window, and perhaps group sections
of the automatic manual together if they could think of a more concise way of describing them as one
idea. This manual writing tool would have a button that simply prints all the nice text the technical
author has written. And to be really useful the following features would be needed:
Warn if there are any sections of the automatically generated manual that the technical author
has missed using.
If the device design is changed, we would reuse the tool and it could automatically find all of the
manual sections that potentially need changing. The technical author might decide that they
don’t, but they would certainly like to be shown all sections they have written that possibly
need revising. So, each section the technical author writes needs a checkbox, so they can be
‘checked out’ as being OK when the specification changes.
/ 209