Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
serg
Semiotic Engineering Research Group
Simone Diniz Junqueira Barbosa [email protected]
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: