Pertemuan 12 Interface Matakuliah : M0446/Analisa dan Perancangan Sistem Informasi

advertisement
Matakuliah
Tahun
Versi
: M0446/Analisa dan Perancangan Sistem Informasi
: 2005
: 0/0
Pertemuan 12
Interface
1
Learning Outcomes
Pada akhir pertemuan ini, diharapkan mahasiswa
akan mampu :
• Menunjukkan Interface
2
Outline Materi
• User dan Sistem Interface
• Pola User Interface
• Menentukan pola user interface
3
Aktivitas utama dalam
Analisis Application Domain
4
Terminologi
• Interface: Fasilitas yang membuat model
sistem dan function dapat berinteraksi dengan
actors.
• User interface: Interface untuk users.
• System interface: interface ke sistem lain.
• Usage context: The application domain
characterized by actors and use cases.
5
User Interface
• Are very important: they can make or break
system use and benefit realisation.
• Needs to carefully fit the usage context.
• Need to be designed carefully - small details
multiply difficulties with usage.
• Need to account for the different kinds of
users with different skills and capabilities.
• Very difficult to design without feedback generally must be tested with users.
6
Systems Interface(s)
• May need interfaces for non-human actors, i.e. other
systems
• Not commonly used for administrative systems
• More common for monitoring & control systems
– direct sensors in the environment - e.g. temperature
– direct intervention, e.g. motors, switches
– may also input or output from other computer
systems
• Need to design and make sure that these technical
connections can be realized
7
Sub-activities in
Interface Analysis
8
Tailor Usability to Context
• Usage is relative to usage context
Usage context
Desired
properties
Technology
 Routine tasks
 Efficient
 Fixed, well Reliable
structured tasks
 Activation of functions
 Fixed defined dialogue
 Menu and command
driven manipulation
 Non-routine
 Flexible to use
tasks
 Easy to learn
 Varying problem new functions
solving tasks
 Manipulation of objects
 Loosely defined dialogue
 Direct manipulation
9
Study the Usage Context
• Study both human actors and use cases
– Does the individual user solve several tasks in
parallel?
– Does the user move physically while working?
– Is the work often interrupted?
– Are certain use cases significantly different from the
typical use cases?
– Do certain work tasks require a quick response from
the computerized system?
– How is it ensured that the users notice when the
computerized system performs a signal function?
10
Explore User-Interface Patterns
• A user interface usually mixes several
patterns or styles
• Four main patterns/styles
– menu
– form filling
– command language
– direct manipulation
• (also natural language)
11
Menu Selection
• Advantages
– Shortens learning
– Reduces key-strokes
– Structures decision
making
– Allows easy support of
error handling
– High level tools allow
for easy programming
• Disadvantages
– Risk of too many
menus
– Slows the frequent
user down
– Consumes screen
space
– Requires rapid display
rate
12
Form Filling
• Advantages
– Simplified data entry
– Requires modest
training
– Makes assistance
convenient
– High level tools allow
for easy programming
• Disadvantages
– Consumes screen
space
13
Command Language
• Advantages Flexible
– Appeals to “power”
users
– Supports user initiative
– Convenient for
creating user-defined
macros
• Disadvantages
– Poor error handling
– Requires extensive
training
14
Direct Manipulation
• Advantages
– Immediately visible
result of interaction
– Useful for both casual
and frequent users
– Can be extremely
efficient
• Disadvantages
– Effort required to
develop
– Difficult to invent
meaningful icons,
symbols, etc., unless
can rely on standard
objects
15
Dialog Style:
Function-Oriented vs Object-Oriented
• Is the interface primarily based on functions or
objects? Need both, but which choose first?
– I.e., does the user choose the function first, then
choose the object or vice versa?
• Function-oriented dialogues are better for routine,
automated work
• Object-oriented ones are better for varied
individual work tasks as they give more flexibility
– But, usually require more development time and effort
16
Some Guidelines
• A dialogue needs to be simple, natural, and
consistent.
• Requirements placed on the users’ memory
need to be minimal.
• Feedback must be informative and constructive.
• Errors must be prevented.
• Detailed discussion is beyond the scope of this
unit.
17
Determine User-Interface Elements
• Representations of objects in the model
– Many possibilities: icons, fields, tables, diagrams,
windows
– Need a clear & consistent system of representations
• Activation of functions
– Buttons, menu screens, pull-down/pop-up menus
– Also need support for visualisation and feedback
– Needs to be consistent and fit within the dialog
pattern/style
• Result is a list of user-interface elements
18
Describe Interface Elements
• User Interface:
– General effect: colours, fonts, types of
menus, types of icons, default positions
– Navigation: dialog linkages between
buttons, menus, screens, windows, etc.
– Computer screens/windows/forms, etc.:
layout, interactivity, consistency
– Outcome of activity is screen/form designs,
navigation diagram and other descriptions
19
Evaluate the User Interface
• A User Interface cannot be constructed bottom
up without experiments using prototypes.
• Should be a carefully controlled process using
the five sub-activities.
• Planning needs to lead to concrete evaluation
and quick development with efficient tools.
• Preparation needs to determine how collaborate
with users, ensure realism, and select good
example tasks that enhance feedback.
20
Explore Systems Interface Patterns
• Consider what/how data should be sent to and
received from other systems (if any)
• Other systems may be
– simple external devices: sensor, switch, or motor use
simple read or activate device patterns
– complex computer systems: need a communication
protocol which may be supplied or need to be
designed
21
Read External Device Pattern
• Read either regularly or dependent on an event
• Memory object can just be the model object
22
Interaction Protocol
• A protocol defines command facilities supporting the
possible use cases for a system by another
• Is agreed upon by designers of the two systems (unless
one has already been designed/built!)
• Specify a pattern for interaction using a list of commands
for each side and their expected responses
– Separate protocol item named for each command
– E.g. Request some info or Prepare to accept info
– Commands may check the state of the other system
23
Determine and Describe the
Systems Interface Elements
• What other computer systems will the system be
connected to and exchange information with?
– What protocol(s) will be needed?
• Will the system be connected directly to the
problem domain through external devices?
– What external device read or write interfaces are
needed?
• Result is a list and specification of each.
24
Evaluate System Interfaces
• Protocols can be tested on pencil and paper by
working through use cases
• Ultimate test is that the physical connections
actually work
– If there is any doubt, these connections need to be
tested as early as possible
– Build and test technical feasibility prototypes
25
Principles of Interface Analysis
• Tailor usability to the application domain
– need to know who the users are and in what situations
the computerized system will be used
• Experiment and iterate
– interfaces are complex and interact with users in ways
that can’t be anticipated
– experiments need to be planned, efficient, and realistic and likely will be repeated
26
Principles of
Interface Analysis (2)
• Identify all interface elements
– Important not to leave anything out!
– Details can be supplied/determined later, as long
as the basic structure is clear and coherent
27
Download