How to manage input events in a modular user interface?

Question

User interfaces often consist of various input devices, such as buttons, input fields, dialog boxes, sliders, and others. The order of events usually determines the expected behavior, and this behavior is often not easy to catch in a simple rule.

Is there a general approach to this type of problem?

To illustrate how easy an interface can become complicated, take an interface with 3 toggle buttons. If the behavior of pressing a button depends on the state of each button, 2 cases are possible 3 * 3 = 24 cases. If the behavior also depends on the history of events, the number of events increases exponentially.

As an example in real life, look at the wysiwyg text editor I'm working on. I select the focus / blur event in the editor to enable / disable the editor. Some buttons (widgets) immediately return focus to the editor, while other buttons open a dialog. In the image below, the arrows indicate where the focus should go when clicking on the interface element.

I found focus control a difficult problem here, often introducing unwanted or counterintuitive behavior.

Answer 1

The right question is part of the answer. My question concerns a special case when widgets are not only representations of data, but rather input devices for the general part of information.

The event manager, as suggested by Matteo Millore, has a different application. This is useful in cases where the flow of information is more linear: on the one hand, one or more objects that can trigger an event and other objects that listen to these events.

In my case, not only event management should be centralized, but more importantly, as well as logic management. This logic is characterized by several actuators acting on the same data source, which can easily cause loops. In my case, this data source: where is the focus, and when the editor should be activated / deactivated.

The solution to preventing loops is to use an internal state variable and carefully develop a mapping that translates each state + combination of events into an action state + new. A basic implementation might look like this:

switch (eventdescription) { case 'click_in_txt': switch (state) { case 'inactive': activate(); state = 'active'; break; case 'plugin_has_focus'; close_plugin(); state = 'active' break; default: console.log('undefined situation ' + state + ' / ' + eventdescription); } ... } 

This approach still requires trial and error, but it’s easy to understand what situation is causing the error, and then you can change the behavior only for this situation. In addition, the console.log () function shows where you missed some combinations of events that might cause unexpected behavior.

Answer 2

You can use the AKA Message Broker Broker template to separate the user interface components (in general, any type of application component), here are two articles about this:

• Javascript mediator pattern
• JavaScript mediation template

Answer 3

The most general approach I can imagine is to draw an event tree. The general view of one branch of the event tree is as follows:

 (start state) -> [event] -> <action> -> [event] -> <action> ... 

Since different events are possible at each point, the event tree grows exponentially, the longer the branches are observed. Fortunately, often the interface returns to some state, for example. after closing the dialog, it will return to its original state.

Finding and modeling these return states is a creative process unique to each application. Naming each of these states is helpful. The intermediate result is a state / event / action diagram as indicated above.