UNIT 3

Implementation support, Evaluation

Techniques, Universal Design & User
support
 ELEMENTS OF WINDOWING SYSTEM
• with the elements of a windowing system, which provide for device independence and resource sharing at the
programming level.
• Programming in a window system frees the programmer from some of the worry about the input and output
primitives of the machines the application will run on, and allows her to program the application under the
assumption that it will receive a stream of event requests from the window manager
• Will describe more details of windowing systems used to build the WIMP interface
• The first important feature of a windowing system is its ability to provide programmer independence from the
specifics of the hardware devices
• WIMP interface as an interaction paradigm pointed out its ability to support several separate user tasks
simultaneously. Windowing systems provide this capability by sharing the resources of a single hardware
configuration with several copies of an abstract terminal
• The window system must also provide a means of displaying the separate applications, and this is
accomplished by dedicating a region of the display screen to each active abstract terminal. The coordination
task then involves resolving display conflicts when the visible screen regions of two abstract terminals
overlap
• In summary, we can see the role of a windowing system, as providing:-
• independence from the specifics of programming separate hardware devices;
• management of multiple, independent but simultaneously active applications
ARCHITECTURES OF WINDOWING SYSTEMS
• implement and replicate the management of
the multiple processes within each of the
separate applications.
• This is not a very satisfactory architecture
because it forces each application to
consider the difficult problems of resolving
synchronization conflicts with the shared
hardware devices.
• It also reduces the portability of the separate
applications.
• provides the most portability, as the management function
is written as a separate application in its own right and so
can provide an interface to other application programs that
is generic across all operating systems.
• referred to as the client–server architecture
PROGRAMMING THE APPLICATION
• on programming the actual interactive application corresponds to
a client in the client–server architecture
• Interactive applications are generally user driven in the sense that
the action the application takes is determined by the input
received from the user.
• The first programming paradigm is the read–evaluation loop,
which is internal to the application program itself. The server
sends user inputs as structured events to the client application. As
far as the server is concerned, the only importance of the event is
the client to which it must be directed. The client application is
programmed to read any event passed to it and determine all of
the application-specific behavior that results as a response to it.
• The application has complete control over the processing of
events that it receives.
• The downside is that the programmer must execute this control
over every possible event that the client will receive, which could
prove a very cumbersome task.
• The other programming paradigm is
notification based, in which the main control
loop for the event processing does not reside
within the application. Instead, a centralized
notifier receives events from the window
system and filters them to the application
program in a way declared by the program.
The application program informs the notifier
what events are of interest to it, and for each
event declares one of its own procedures as a
callback before turning control over to the
notifier. When the notifier receives an event
from the window system, it sees if that event
was identified by the application program
and, if so, passes the event and control over
to the callback procedure that was registered
for the event. After processing, the callback
procedure returns control to the notifier,
either telling it to continue receiving events
or requesting termination.
 WHAT IS EVALUATION?

• need to assess our designs

• test our systems to ensure that they actually behave as we expect and meet user
requirements.
• Evaluation should occur throughout the design life cycle, with the results of the evaluation
feeding back into modifications to the design.
 GOALS OF EVALUATION

• To assess the extent and accessibility of the system’s functionality

• To assess users’ experience with the interaction
• To identify any specific problems with the system
 EVALUATION THROUGH EXPERT ANALYSIS: COGNITIVE
WALKTHROUGH
• require a detailed review of a sequence of actions
• the sequence represents a segment of the program code that is stepped through by the reviewers to check certain
characteristics
• the sequence of actions refers to the steps that an interface will require a user to perform in order to accomplish
some known task.
• The evaluators then ‘step through’ that action sequence to check it for potential usability problems.
• the main focus of the cognitive walkthrough is to establish how easy a system is to learn
• Learning through exploration.
• you need four things:
1. A specification or prototype of the system.
2. A description of the task the user is to perform on the system.
3. A complete, written list of the actions needed to complete the task with the proposed system.
4. An indication of who the users are and what kind of experience and knowledge the evaluators can assume about
them.
 HEURISTIC EVALUATION
• a guideline that can guide a design decision or be used to critique a decision that has already been made
Nielsen’s ten heuristics
1. Visibility of system status:- Always keep users informed about what is going on, through appropriate feedback within reasonable time.
2. Match between system and the real world:- The system should speak the user’s language, with words, phrases and concepts familiar to
the user, rather than system-oriented terms. Follow real-world conventions, making information appear in natural and logical order.
3. User control and freedom:- Users often choose system functions by mistake and need a clearly marked ‘emergency exit’ to leave the
unwanted state without having to go through an extended dialog. Support undo and redo.
4. Consistency and standards:- Users should not have to wonder whether words, situations or actions mean the same thing in different
contexts. Follow platform conventions and accepted standards.
5. Error prevention:- error messages is a careful design that prevents a problem from occurring in the first place.
6. Recognition rather than recall:- Make objects, actions and options visible. The user should not have to remember information from one
part of the dialog to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
7. Flexibility and efficiency of use:- Allow users to tailor frequent actions.
8. Aesthetic and minimalist design:- Dialogs should not contain information that is irrelevant or rarely needed
9. Help users recognize, diagnose and recover from errors:- Error messages should be expressed in plain language (no codes), precisely
indicate the problem, and constructively suggest a solution.
10. Help and documentation:- Few systems can be used with no instructions so it may be necessary to provide help and documentation.
 MODEL-BASED
• provide a means of combining design specification and evaluation into the same framework
• Design rationale provides a framework in which design options can be evaluated
• Dialog models can also be used to evaluate dialog sequences for problems, such as
unreachable states
USING PREVIOUS STUDIES
 USER PARTICIPATION
1. Laboratory studies
2. Field studies
 UNIVERSAL DESIGN
• the process of designing products so that they can be used by as many people as possible in
as many situations as possible.
• this means particularly designing interactive systems that are usable by anyone, with any
range of abilities, using any technology platform.
• This can be achieved by designing systems either to have built in redundancy or to be
compatible with assistive technologies.
• An example of the former might be an interface that has both visual and audio access to
commands;
 UNIVERSAL DESIGN PRINCIPLES
1. Equitable use:- the design is useful to people with a range of abilities and appealing to all. No user is excluded
or stigmatized
2. Flexibility in use:- the design allows for a range of ability and preference, through choice of methods of use
and adaptivity to the user’s pace, precision and custom.
3. Simple and intuitive to use:- regardless of the knowledge, experience, language or level of concentration of
the user. The design needs to support the user’s expectations and accommodate different language and literacy
skills.
4. Perceptible information:- the design should provide effective communication of information regardless of the
environmental conditions or the user’s abilities.
5. Tolerance for error:- minimizing the impact and damage caused by mistakes or unintended behavior.
Potentially dangerous situations should be removed or made hard to reach. Potential hazards should be
shielded by warnings
6. Low physical effort:- systems should be designed to be comfortable to use, minimizing physical effort and
fatigue. The physical design of the system should allow the user to maintain a natural posture with reasonable
operating effort
7. Size and space for approach and use:- the placement of the system should be such that it can be reached and
used by any user regardless of body size, posture or mobility. Important elements should be on the line of sight
for both seated and standing users. All physical components should be comfortably reachable by seated or
standing users
 USER SUPPORT
• There are four main types of assistance that users require:
1. quick reference
2. task-specific help
3. full explanation
4. tutorial.
 USER SUPPORT REQUIREMENTS
1. Availability :- The user needs to be able to access help at any time during his interaction
with the system. Eg opening a help window
2. Accuracy and completeness:-
3. Consistency:- online help = paper documentation
4. Robustness:- help system itself should be robust, both by correct error handling and
predictable behavior. The user should be able to rely on being able to get assistance when
required
5. Flexibility:-
 APPROACHES TO USER SUPPORT

1. Command assistance
2. Command prompts
3. Context sensitive help
4. Online tutorials
5. Online documentation
6. Wizards and assistants