When interacting with GUI, a user should be able to supply only valid events at any given time. Thus if an application requires a user to perform event A before event B, the interface should ensure that event B is not possible until event A has been completed. It can be achieved by making certain GUI elements disappear or become disabled.
Consequently, when a user interacts with a GUI, the GUI moves from one set of possible events to another. In other words, the user interface moves from one state to another and the state defines the set of possible events that a user can introduce.
The states and their transitions are described by a state machine model. State machines are sometimes used to model software when the identified state must be documented along with how it transitions from one state to another. In our case the states are the particular configurations of GUI with some of its elements switched off or on, while the transitions are user actions that triggers the GUI events.
Example
In our example we have a simple application that should generate a report from a given input file. The use case is as follows: user selects and opens file then the file is processed and loaded into the memory or database and finally the report is generated. As a result we can distinguish 3 GUI states: file opened, file loaded and report generated. The states and transition among them are presented in the figure. The corresponding code consist of functions which are assigned to particular events of the GUI. After executing a specialised code associated with every event, the further run is delegated to the gui_state() function which implements our state machine model of the GUI.
Summary
A state-based approach to user interface construction is not a new idea. The major drawback of the approach is the large number of states and event transitions when the GUI has more elements. From the other side state machine approach allows to have an orderly concept of GUI interactions which can be formally modeled and closed in one function.