SDSU CS 580 Client-Server
Spring Semester, 2004
Some GUI
Previous    Lecture Notes Index    Next    
© 2004, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 26-Jan-04

References

Rettig, Marc. Interface Design When You Don't Know How, Communications of the ACM, Jan. 1992, Vol. 35, No. 1, pp. 29-34

Rettig, Marc. Prototyping for Tiny Fingers, Communications of the ACM, April. 1994, Vol. 37, No. 4, pp. 21-27

Domain-Driven Design, Eric Evans, 2004, Addison-Wesley

Patterns of Enterprise Application Architecture, Martin Fowler, 2003, Pearson Education

User Interface Design for Programmers, Joel Spolsky, 2001 http://www.joelonsoftware.com/navLinks/fog0000000247.html

Doc 5, Some GUI Slide # 2
Recommended Reading – Designing GUIs

User Interface Design for Programmers, Joel Spolsky, 2001 http://www.joelonsoftware.com/navLinks/fog0000000247.html

There is a printed longer version of the book. The on-line version is free and will get you started.
Design of Everyday Things, Donald Norman, 1990

This is an excellent book, is entertaining and only costs $12 new at Amazon. Anyone that designs or builds anything has to read this book.


These books do not cover the mechanics building a GUI. They do not cover which fonts and colors to use. They just get you started thinking about the really important questions related to GUI design.


Doc 5, Some GUI Slide # 3

Software Structure with UI & Database


Tiers – parts of program run on different machines

Layers – parts of program run on same machine


Layers

Presentation – Display of Data

Domain – Logic related to purpose of the application

Data Source – Communication with data source


Doc 5, Some GUI Slide # 4
Rule One

Keep the presentation & domain layers separate

GUI code should not contain domain logic


In simple cases different methods in one class may handle presentation and domain logic

A single method one does either presentation or domain logic


Can you test the domain logic with automated unit testing


Doc 5, Some GUI Slide # 5

Smart UI Pattern


“ the separation of UI and domain is so often attempted and so seldom accomplished that its negation deserves a discussion”

Eric Evans, Domain-Driven Design

The Pattern

Put all business logic into user interface

Divide the application into different small user interfaces

Use relational databases as back end

Use automated UI building and visual programming tools

Advantages

Disadvantages



Doc 5, Some GUI Slide # 6

Handling Domain Logic

Transaction Script


Each procedure (method) handles one request from the UI

Each database transaction handled by one procedure


Advantages

Disadvantages



Doc 5, Some GUI Slide # 7

Table Module


Each class represents one table in database

A request on the database is done through its table module

Advantages


Disadvantages




Doc 5, Some GUI Slide # 8

Domain Model


Use objects to model the domain

Develop application with OO design

Advantages


Disadvantages



Doc 5, Some GUI Slide # 9
GUI Clients & Servers

GUI Clients
Users do not care about the client-server protocol

Don’t expose the user to the client-server protocol

Build the GUI to help people accomplish a task, not just to perform the client-server protocol

Example: Current Restaurant server & Searching

The current protocol does not support finding restaurants based on two types of food

But a client can provide this function


Doc 5, Some GUI Slide # 10

Interface Design When You Don't Know How



Basic Rule for Good Visual Design

Hire a graphic/GUI designer



Doc 5, Some GUI Slide # 11
Basic Rule for Almost Everything Else

Painstakingly follow established standards

All major interfaces have published detailed standards for user interface design

Windows
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_the_user_interface_guidelines_for_microsoft_windows.asp

MacOS X
http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/index.html

Java
http://java.sun.com/products/jlf/

GNOME
http://developer.gnome.org/projects/gup/hig/1.0/

KDE
http://developer.kde.org/documentation/design/ui/


Doc 5, Some GUI Slide # 12
Mental Models & Users

Users don’t read the manual

The more text you put on the screen the fewer people will read it

Users have a mental model of how your program works

Make sure your program fits their mental model

Doc 5, Some GUI Slide # 13
User Interface Standards Manual

Produce standards manual for the project

Manual should address the following:



What symbols are there?
How do they relate to each other?
How do they relate to the things they represent?
How do they relate to the user?

Doc 5, Some GUI Slide # 14
The Process



Doc 5, Some GUI Slide # 15
Planning

Set a short time limit (4 weeks) on the planning process


Planning Documents

Document One

Defines design goals
Sets the direction for the work
Identifies open problems that need to be researched

Document Two

Project plan for next four months
Describe series of tasks, each no longer than two weeks


Document Three

Plan for user testing


Document Four

Definition of Iterative Process


Doc 5, Some GUI Slide # 16

Prototyping

Problems with Software Prototypes


Software Prototypes take too long to build and change


Testers tend to comment on "fit and finish" issues
Get comments on selection of colors, fonts and buttons
Developers spend time on colors, fonts and buttons


Developers resist changes

Managers resist change

Software Prototypes set false expectations

Single bug in a software prototype can halt a test

Doc 5, Some GUI Slide # 17

Lo-fi or Paper Prototypes

The Kit


White paper

Unlined
Heavy enough to endure repeated testing and revisions


5-by-3-inch cards

Use as construction material
Taking notes


Adhesives

Tape: clear, colored, double-backed, etc.
Glue sticks
Post-It glue
White correction paper


Markers

Colored pens and pencils
Highlighters
Fine and thick markers


Sticky note pads

Acetate sheets

Scissors, X-acto knives, straightedges, Band-Aids

White-out

Doc 5, Some GUI Slide # 18

Build A Paper Prototype


Set a short deadline

The prototype will be done by 4:00 this afternoon
Tomorrow at 9:30 we will demo the prototype
Just get a first pass on all aspects of the prototype
It will be "wrong" so don't spend weeks on it


Construct Models, not illustrations

Build the parts of your prototype so they can be used
The parts need to move around
User will use the model, must see the changes
On early models don't be picky - get ideas down
Later models can look "professional"


Doc 5, Some GUI Slide # 19

Preparing for a Test


Select your users

Know the demographics of your users
Educational background
Knowledge of computers
Typical tasks involved in their job
Can use "surrogate users"
People with same demographics of your users
Undergrads are cheap available labor
May wish to avoid actual customers, employees, friends, and family
Testers should represent the whole range of users
Do at least one in-house test with surrogates and one field test with typical end users

Prepare test scenarios

Practice

Doc 5, Some GUI Slide # 20

Conducting a Test


It takes four people to get the most out of a test

Greeter
Welcomes users
Puts users at ease
Users often worry about:
Flunking the test
Co-workers finding out how they did
Answering the question correctly
Have users fill out forms - experience profile


Facilitator
Runs the test
Gives users instruction
Gives user hand written tasks to perform
Encourage the user to express their thoughts
Elicit the user's thought during the tests
Makes sure test runs on time


Doc 5, Some GUI Slide # 21
Computer

Runs the computer
Moves the model in response to users "actions"


Observer

Takes notes
One observation per index card

Doc 5, Some GUI Slide # 22

The Test


Video tape the test

Before starting the test, explain the process to the user

Debrief the user after the test

During the test, don't:

Give user hints
Laugh, gape, gasp, or say "a-ha"
Don't display any reaction to the user's actions


Evaluate the Results


Go through all the notes taken during the tests

Use post-it notes to put comments on components of prototype that need change


Copyright ©, All rights reserved.
2004 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 26-Jan-04    Next