Wrod Game

The Wrod Game application displays anagrams of Portuguese words (see Figure 7.6a) and allows users to guess what the word is. For each correct word, players get as many points as the number of letters in the word. When players guess the correct word, the application displays the definition of the word (see Figure 7.6b).

(a) Main screen. (b) Results screen.

Figure 7.6: Screens in the Wrod Game application.

This application uses only two widgets: one textbox that is used for receiving the guessed words, and a button widget that allows users to skip the current word and ask for a new one. These widgets are permanent in the application, i.e., the application only creates these two widgets, and they are never deleted. However, the textbox widget is updated whenever the current word on the screen changes:

the long description of the widget is set to “What word is this:” followed by the anagram of the current word.

the three test applications. In this section, we discuss some of the aspects that were improved in the toolkit as a consequence of the development of these applications, and also some shortcomings we have detected.

Delayed synchronisation technique

In an initial version of the PuReWidgets library, programmers were required to explicitly send widgets to the IM, after they created or changed a widget. While programming the first versions of the Public YouTube Player, this soon proved to be a source of errors as it was easy to forget to send the widget to the IM. A better solution would simply be to automatically send a widget to the IM whenever any of its properties were changed (the base class for all widgets – PDWidget – could easily be altered to detect these changes). However, in many situations, configuring a wid-get means changing various properties, which would mean sending several sequential updates to the IM, using unnecessary network and server resources. To get the best of both worlds, we changed the Widget Manager component of the PuReWidgets library, introducing a delayed synchronization technique, where updates to a widget are only propagated to the IM a few seconds after the last change to the widget. In this technique, changing a property of a widget marks that widget as “dirty” in the Widget Manager and resets a delay timer. When the timer expires, all dirty widgets are sent to the IM. This allowed us to change the API of the library, removing the need to explicitly send a widget to the IM and, at the same time, minimise the network and server overhead.

Application parameters

While developing the Public YouTube Player application, it became obvious that there were application parameters that display owners should be able to config-ure. Although this is not directly related to the interaction or specific to public display applications, it makes sense to support application parameters in PuReWid-gets because these parameters are related to a specific instance of an application.

PuReWidgets provides functions to read and write parameters in the form of name-value pairs that are stored on the application’s server. Applications can provide an administration web interface that display owners can use to configure the various parameters for a specific application instance (PuReWidgets provides a template for this administration web page). Using these functions alleviates programmers from explicitly having to deal with di↵erent places and application instances.

Addition-ally, application parameters can be overridden by URL parameters, providing more flexibility in the way that applications can be configured.

Order of widgets in the dynamically generated web interface

The development of the Public YouTube Player application also pointed out the need to be able to have control over the order in which widgets are presented in the dynamically generated web interface. An initial version of the web GUI rendered widgets in an alphabetical order. However, when comparing the public display in-terface of the Public YouTube Player application and its web GUI, it was apparent that the di↵erent ordering of the widgets in the two interfaces could generate con-fusion. As a consequence, we introduced a widget parameter that programmers can use to explicitly define the ordering of the widgets in the web interface. Although this still does not provide full control over the layout, it allows for a more natural mapping between the public display interface and the web interface, which is of par-ticular importance for applications with many widgets, as in the case of the Public YouTube Player application.

Input state

The Everybody Votes application evidenced a shortcoming in our current imple-mentation of the web GUI that is not yet resolved: the inexistence of input state.

When users vote on a specific poll using the web interface, their answer is recorded by the public display application but not reflected on the web GUI itself. If, a few days later, users don’t remember their votes, they currently have no way of finding out (although in this particular application, users can always vote again in the same or in a di↵erent option: the application records only the last vote by a given user).

This problem also occurs with other interaction mechanisms, such as SMS, email, Bluetooth naming etc., and in these cases there is no obvious solution (users can always check their SMS or email message history, but this is not a practical solu-tion). The web interface, however, has the possibility of o↵ering a solution to this particular problem by recording the input data of some of the widgets, much like what happens in some web forms that are partially filled with our previously entered data. To be a flexible solution, applications should be able to define which widgets should keep their input state in the web interface. This feature is not yet imple-mented in PuReWidgets, but it is planned for a future version. Providing users with their interaction history in the web GUI is also a feature that may mitigate some of the problems associated with the lack of input state (this feature is described in section 8.2.3 – Interaction history in the web GUI).

Di↵erent widgets for authenticated users

The Everybody Votes application evidenced another possible enhancement: the possibility of accepting input from authenticated users only. Currently, applications

Rapidly changing widgets

While developing the Wrod Game application we realised another limitation of the current implementation of the web GUI: its inability to cope with rapidly changing widgets. In the current version of PuReWidgets, the web interface uses a polling ap-proach to periodically ask the IM server for updates about the application’s widgets.

This polling approach was used mainly to limit the number of used channels (persis-tent connections with the server) due to Appengine free quota limitations. However, for applications that change their interface frequently, by adding or removing wid-gets, or by changing the description of existing ones, this polling approach results in temporarily out-of-sync interfaces. We noticed this particularly in the Wrod Game application, which changes the long description of the text box widget to reflect the current anagram. Frequently, the anagram displayed in the web interface was not the same as the one displayed in the public display, leading to users submitting wrong guesses. This is not a major problem, as the text box on the web GUI does not necessarily need to display the anagram: users would most likely look at the public display to see the letters. Still, this problem may be addressed with persistent connections, making sure the web interface is updated at a fast enough pace. This solution, however, may drastically increase the number of channels used, as they will depend on the number of di↵erent users that interact with the display system.