serg

Semiotic Engineering Research Group

Simone Diniz Junqueira Barbosa simone@inf.puc-rio.br

Departamento de Informática Rua Marquês de São Vicente, 225 - Gávea - 22451-900

Rio de Janeiro - RJ - Tel. (21) 3527-1500 r.4353 - Fax (21) 3527-1530

UISKEI: User Interface Sketching and Evaluating Instrument

USKEI is a tool for sketching user interfaces (UIs) and running “paperless prototyping” sessions

with end users. Developed in C#, it makes use of polyline simplification algorithms and a predefined

gesture vocabulary to help recognize the shapes users draw and turn them into user interface

widgets.

The user-designer can define several UIs and hold paperless prototyping sessions with end users

about the HCI solution being designed. The user can interact with the prototype in a presentation mode,

where each UI snapshot is presented with the associated actions the user may take. Depending on the

action chosen, a different UI snapshot will be presented, simulating the user-system interaction and thus

allowing an observer to gather invaluable feedback very early in the design process.

The tool has 4 modes of operation:

free drawing mode, in which the user is free to draw whichever shapes he wants, without having the

system attempt to recognize the shapes;

recognized drawing mode, in which the system attempts to recognize common user interface widgets

based on a gesture vocabulary as the user draws;

selection mode, in which the user can select any element to move, resize, rename, edit its states, edit

its actions, among other options; and

presentation/simulation mode, in which the user can navigate freely between the presentation units

(called Views) or interacting with the sketches themselves, using the widgets according to the

previously defined behavior.

Widget recognition

The current widgets that are recognized by the tool are the following:

2

The recognition works according to a predefined gesture vocabulary, as follows:

Behavior

The designer can define specific behavior to each UI widget, based on groups of conditions and

actions. The behaviors may be conditioned to the state of one or more UI widgets. For instance, a

behavior may be activated only when a checkbox is checked and a text field is current blank.

The possible actions associated to a UI widget are:

open view (as a popup window or substituting current view)

close current view

change state of a widget (e.g. check or uncheck a checkbox or radio button)

next state (switch the state of a widget to the next available one, e.g., change the text of a textbox to a

different text that contains errors)

change the visibility of a widget

enable or disable a widget

show message (according to a predefined type: info, warning or error)

Let us consider the following scenario: Vince, a user interface designer, needs to design a

registration page for a web application, together with its corresponding behavior and possible error

messages. The following snapshots illustrate the usage of the tool:

3

Vince starts by sketching the user interface using the

gesture vocabulary.

Next, he asks the application to recognize the sketch,

and obtains the following result:

Where necessary, he resizes or relocates each widget. He then edits the widgets’ labels, finishing the user

interface sketch itself.

Also, he draws a license agreement UI… and a home UI.

4

Next, Vince selects the register button in the registration

UI to define its behavior, which is to present error

messages for each problem in the form.

And the license agreement link to open a popup with the

corresponding UI:

Having finished with the first design sketches, Vince

decides to run the prototype in presentation mode, to test

its behavior.

Without filling in any fields, he presses the register

button, and a popup message appears.

Vince soon realizes that this is not a good UI solution.

He then changes the UI to reflect this solution, by

creating a new view with the error messages embedded

in the form itself, as suggested by best practices of UI

design.

He tests the prototype again, and obtains a better result

this time, moving easily through the UI sketches.

5

He tests the UI with blank fields. Then, he fills in the fields with the predefined data,

selecting a valid value for each…

and, after viewing the license agreement, … he accepts it.

He then submits the registration, and gets to go to the

home UI, completing this preliminary prototyping

session: