Professional 20Java 20User 20Interfaces 20 2006.pdf

(26746 KB) Pobierz
Display organization
51
Figure 2.11
A simple dialog design
The interested reader can see (Mullet and Sano 1995) for an introduction to the art
of visual design of software user interfaces, or the classic trilogy from Edward
Tufte (Tufte 1990), (Tufte 1997), (Tufte 2001).
Abstract-Augmented Area for GUIs
Abstract-Augmented Area for GUIs (A3GUI or A3GUI) is a term that describes a
simple approach to the definition and general management of graphical user
interfaces. The key idea is to organize a GUI and all its underling dynamics
conceptually – user interactions, intended behavior, design requisites, constraints,
implementation and so on – by
areas,
that is, the ‘real estate’ of our GUIs.
A3GUI represents a GUI as a set of
augmented areas.
These areas are abstractions
over the real GUI that help the design, implementation, testing or any other aspect
of the GUI in which we are interested. A3GUI can be thought of as describing a
general mindset that is independent of the chosen UI design approach.
By the term
real GUI,
we mean one concrete execution of our application at a given
time. This will in turn depend on the surrounding context that may affect our GUI,
such as the current user, the OS on which the application is running, and so on.
All such context data can change the GUI’s behavior and appearance for a given
execution in a given situation. For example, a GUI may change depending on the
given locale, or show only specific features to specific users, depending on their
roles. We all deal with GUIs by managing abstractions of real executions.
Augmented areas, which for brevity we refer to merely as
areas,
are pictorial repre-
sentations of specific facets of the GUI (whole windows, panels or single widgets)
augmented with other information. Areas can be represented as paper sketches,
in electronic form as drawings, diagrams, bundles of files, UML 2.0 diagrams and
so on, or in any other convenient way. Areas can be visually nested inside other
11:26 AM 9 March 2006
c02.fm
1.0
52
Introduction to User Interface Design
areas, can be related to other areas, and documentation attached to them, such as
requirements, documents, the implementation’s Java classes, and so on. The need
is to provide a pictorial representation, a unique ID and an explicit or implicit set
of abstractions we are representing throughout the area in the real GUI. The
A3GUI concept also happens to dovetail nicely with modern OO GUI toolkits
such as those used to build Java GUIs.
The type and level of abstractions really depend on our purpose. For example,
Figure 2.12 shows a number of possible abstractions for a real GUI in a specific
execution context.
Figure 2.12
M
Some possible abstractions over a given GUI execution
A3GUI provides a formalized yet flexible framework for designing and managing
GUIs that helps to solve the conceptual twists that we commonly face when
defining GUIs at various levels of detail.
An example
Suppose we want to design a very simple GUI to display the bank accounts of
specific customers. We want to provide a list of all transactions recorded for a
given customer (which for simplicity are chosen outside our GUI). Only certain
11:26 AM 9 March 2006
c02.fm
1.0
Display organization
53
users may have access to transaction details: for example, if a clerk is inspecting a
customer’s account, we don’t want to allow access to customer-sensitive data.
For simplicity we can think our GUI as having only two requirements:
•
•
(R1) Our GUI has to show a list of all available transaction for a given
customer.
(R2) Depending on the role of the current user, only a small subset of a trans-
action’s details can be seen.
We start by devising the following areas
9
– see Figure 2.13.
Figure 2.13
A possible GUI representation in three areas (adopting functional
abstractions)
The following abstractions relate to each pictorial representation shown in Figure
2.13:
•
•
•
A0 represents the login functionality each user has to accomplish to access
the rest of the application.
A1 represents the access to all the functionalities provided by the main menu,
and also provides the list of available transactions to the user (fulfilling R2).
A2 represents access to the transaction details, available only for the given
role.
The diagram also shows some relationships between the various areas. These rela-
tionships express informally the intended navigation between the various areas.
We will use the same notation to express navigational relationships between areas
in the following figures also.
9.
In this example we use ‘A’ as a prefix for areas ids to specify that these areas came from
analysis, and are meant to capture requisites and decompose functional behavior only.
c02.fm
1.0
11:26 AM 9 March 2006
54
Introduction to User Interface Design
The areas shown in Figure 2.13 were the result of a functional refinement activity –
we can think these areas as roughly equivalent to the use cases for the GUI.
A further step is to refine the previous areas for the UI design, deciding whether
areas will become fully-fledged windows, or parts of other areas. A possible UI
design refinement step is shown in the following figure
10
.
Figure 2.14
A UI design refinement step
The following abstractions related to the pictorial representation depicted in
Figure 2.14:
•
•
D0 represents the log-in dialog.
D1 represents the main windows with the available commands and the list of
all the transactions for the chosen customer. Whenever the current user
(already logged in from D0) is not entitled to see transaction details, the
View
button is disabled.
D2 represents the pop-up modal dialog that appears whenever the user has
selected one transaction and presses the
View
button.
•
10. In keeping with the previous step of this example, we use ‘D’ to prefix areas ids, to specify
that these areas arise from UI design refinements.
11:26 AM 9 March 2006
c02.fm
1.0

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin