1

Pertemuan 12Interface

Matakuliah : M0446/Analisa dan Perancangan Sistem Informasi

Tahun : 2005

Versi : 0/0

2

Learning Outcomes

Pada akhir pertemuan ini, diharapkan mahasiswa

akan mampu :• Menunjukkan Interface

3

Outline Materi

• User dan Sistem Interface

• Pola User Interface

• Menentukan pola user interface

4

Aktivitas utama dalamAnalisis Application Domain

5

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.

6

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.

7

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

8

Sub-activities in Interface Analysis

9

Tailor Usability to Context

• Usage is relative to usage context

Usage context Desired properties

Technology

Routine tasks Fixed, well-

structured tasks

Efficient Reliable

Activation of functions Fixed defined dialogue Menu and command

driven manipulation

Non-routine tasks

Varying problem solving tasks

Flexible to use Easy to learn

new functions

Manipulation of objects Loosely defined dialogue Direct manipulation

10

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?

11

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)

12

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

13

Form Filling

• Advantages– Simplified data entry– Requires modest

training– Makes assistance

convenient– High level tools allow

for easy programming

• Disadvantages – Consumes screen

space

14

Command Language

• Advantages Flexible– Appeals to “power”

users– Supports user initiative– Convenient for

creating user-defined macros

• Disadvantages– Poor error handling– Requires extensive

training

15

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

16

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

17

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.

18

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

19

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

20

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.

21

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

22

Read External Device Pattern

• Read either regularly or dependent on an event

• Memory object can just be the model object

23

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

24

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.

25

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

26

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

27

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