Widgets and Events

PuReWidgets provides support for the various interaction tasks defined in chapter 5, in the form of widgets.

4In reality, PuReWidgets o↵ers also a library for server-side code, but for simplicity’s sake, at this point we focus on the web client library.

Figure 6.4: PuReWidgets’ library components.

When users interact, widgets trigger an interaction event by invoking the callback function that the application registered when the widget was instantiated. The data associated with the event will be di↵erent for each widget, but most data is common to all widgets:

user id An user id assigned by the IM, that uniquely identifies the user.

user nickname A human-readable name for the user that can be publicly dis-played.

widget object reference A reference to the internal program object that repre-sents the widget.

widget option id The widget option id that was targeted by the user input.

widget specific data Generic object with widget specific event data.

Currently, PuReWidgets provides the following set of widgets.

Button A button widget allows users to trigger actions in the public display ap-plication. The interaction event generated by a button is a simple triggered event, with no widget specific data. The default graphical representation of a button (see Figure 6.5) displays a button label and the reference code.

Figure 6.5: Default graphical appearance of a button.

List box The list box widget allows users to select among a set of related items.

The high-level event generated by a list box identifies the selected item through the widget option id. Graphically, a list box has the appearance of a box with a title and a set of vertically arranged item names and corresponding reference codes (see Figure 6.6).

Figure 6.6: Default graphical appearance of a list box widget.

Text box A text box widget allow users to input free text. The interaction event generated by a text box contains a text string corresponding to the user’s input, in the widget specific data. Graphically, a text box is depicted as a standard single line input field, with a label and reference code inside. It has also a flashing cursor at the leftmost side (see Figure 6.7).

Figure 6.7: Default graphical appearance of a text box widget.

Upload An upload widget allows users to submit media files to the public display application. The high-level event generated by these controls includes an URL to the uploaded file⁵ so that the application can then download and use the content.

Figure 6.8: Default graphical appearance of an upload widget.

5PuReWidgets handles di↵erent forms of file uploading. If the upload includes the file contents (for example as an email attachment), PuReWidgets will store the file contents and provide ap-plications with a temporary URL for the file. If the upload consists already of an URL for a file, PuReWidgets simply passes it to the application.

Figure 6.9: Default graphical appearance of a download widget.

Check-in Check-in controls allow users to signal the application that they are present. In this case, the high-level event is just the identification of the user that has just checked-in. Check-in widgets are di↵erent from the other widgets in that their input is not directed specifically at a single application, but instead to a place:

when users check-in in a place, every application that instantiated a check-in widget will be notified.

Figure 6.10: Default graphical appearance of a check-in widget.

Widget registration

In order for the IM to be able to route user input to the correct application and to be able to generate the web GUI, widgets must be registered in the IM. The regis-tration process itself is hidden from the application and is done automatically by the PuReWidgets library, when a widget is instantiated or changed by the application.

To register a widget, the following information is sent to the IM:

ids The place id, instance id, widget id, and option ids, are all sent to the IM.

widget type The type of widget corresponds to the interaction tasks defined in chapter 5: select, entry, download, upload, or check-in, or user-defined type.

This is used by the IM to adapt its behaviour in response to a user input and to provide di↵erent graphical representations in the web GUI.

short description A short description (e.g., one to three words) of the widget’s meaning in the context of the application.

long description A longer description (several words) of the widget. The short and long descriptions (and the control type) are used by PuReWidgets to render an application’s widgets in the web GUI. These descriptions are meant to provide context to the widgets, since, in these cases, the user does not have the context of the other elements of the application.

list of option short descriptions A short description of the various options.

list of option long descriptions A longer description of the various options. As with the widget’s short and long descriptions, the options’ short and long descriptions are used mainly to provide context to alternative renderings of the application’s widgets.

list of suggested reference codes (Optional) Each option will be assigned a unique reference code by the IM. This field allows applications to suggest which ref-erence codes they would like to have. PuReWidgets will try to honour these requests but it may not be able to do so if the suggested reference code is already in use.

icons Widgets can have an icon for each widget option. Icons are specified as a URL where the icon can be found.