How to manage event-based input in a modular user interface?

Question

User interfaces often consist of different input devices like buttons, input fields, dialog boxes, sliders and others. The event order generally determines the expected behavior, and this behavior often is not easy to catch in a simple rule.

Is there a generic approach to this type of problem?

As an illustration of how easily an interface can become complex, take an interface with 3 toggle buttons. If the behavior of a button click depends on the state of each button, 2 ^ 3 * 3 = 24 event cases are possible. If the behavior also depends on the event history, the number of event cases grows exponentially.

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

I found managing of focus a tricky issue here, often introducing undesired or counter-intuitive behavior.

user interface sketch

@Sagiv Now the dialog has event handlers on open and close that return focus to #txt (default behavior). The dialog also has a public function that is called by the editor in case of (2). Here I set a flag that prevents the default behavior. It works, but I dont want to have new plugins with dialogs have to implement the same thing, while at the same time I want to give the freedom to let them have their own functionality (for instance, image uploads for different CMS solutions) — Carlo Roosen, Jun 02 '12 at 09:53
Look into BackboneJS which is really good about controlling and sharing events within a UI. — AlienWebguy, Jun 03 '12 at 09:43
@AlienWebguy. I have studied backbone recently, and it does a good job. But as far as I see it doesn't solve my first 3 bullets. (maybe our comment was posted right before I updated my question, so no offend) — Carlo Roosen, Jun 03 '12 at 13:03
Sure it would - you can have each view listen to events of other views, but more importantly, they can listen to changes in the models and collections. This is what makes Backbone so great, one view can update a property value on a model and the entire UI will know about it and update themselves accordingly. — AlienWebguy, Jun 03 '12 at 18:37

score 1 · Answer 1 · answered Jun 02 '12 at 10:26

1

You can use the Mediator AKA Message Broker pattern to decouple the UI components (in general any type of application component), here two articles about it:

answered Jun 02 '12 at 10:26

Matteo Migliore

925
8
22

I am not sure, since in my case I have a central object, the editor, that could potentially manage all events already. My problem is merely to get all the events work correctly in different states of the entire system, where not all information is available at all times (eg, when the blur event is triggered on #text it is not even clear whether the mousedown on a button that caused it will become a click.(mousedown->mouseup->click) – Carlo Roosen Jun 02 '12 at 10:39
Your answer inspired me to come with my own, so +1 for you! – Carlo Roosen Jun 02 '12 at 11:47
Great :), send messages is the best way to expose functions from a UI component without know how the shell is composed. – Matteo Migliore Jun 02 '12 at 12:36
I modified my question for the remaining problem, how to manage events inside the central object – Carlo Roosen Jun 03 '12 at 08:43

Carlo Roosen · Accepted Answer · 2012-06-18T11:43:37.497

Getting my question right is part of the answer. My question is about a special case in which widgets are not only representations of data, but rather input devices for a shared piece of information.

An event dispatcher, as suggested by Matteo Migliore, has a different use. It is helpful in cases where the information flow is more linear: on the one side one or more objects that can fire an event and on the other side objects that listen to those events.

In my case, not only the managing of events should be centralized, but more importantly, also the managing of logic. This logic is characterized by several actuators influencing the same datasource in a way that can easily cause loops. In my case this datasource is: where is the focus and when should the editor be activated/deactivated.

The solution to prevent loops is to use an internal state variable and carefully design a mapping that translates each state + event combination into an action + new state. A basic implementation could look like:

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 needs some trial and error, but it easy to see which situation causes a bug, and then you can change the behavior for that situation alone. Also the console.log() function shows where you overlooked some combination of events that might cause unexpected behavior.

decision table for events/state

score 0 · Answer 3 · answered Jun 18 '12 at 11:42

The most generic approach that I can imagine, is to draw an event tree. A generic representation of a single branche of this event tree looks like :

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

Because different events are possible at each point, the event tree grows exponentially the longer the observed branches are. Fortunately often the the interface will return to some past state, e.g. after closing a dialog it will return to the start state.

Finding and modelling these return states is a creative process that is unique for each application. Naming each of these states is helpful. The intermediate result is an state/event/action diagram as sketched above.

How to manage event-based input in a modular user interface?

3 Answers3