SDSU Client-Server Programming
Spring Semester, 2005
Some GUI
Previous     Lecture Notes Index     Next     
© 2005 All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated March 9, 2005

CS 580 Client-Server Programming

Spring Semester, 2005

Doc 5 Some GUI


Software Structure with UI & Database    

Smart UI Pattern    

Handling Domain Logic    

Transaction Script    

Table Module    

Domain Model    

Interface Design When You Don't Know How    


Problems with Software Prototypes    

Lo-fi or Paper Prototypes    

The Kit    

Build A Paper Prototype    

Preparing for a Test    

Conducting a Test    

The Test    

Evaluate the Results    



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





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




Recommended Reading – Designing GUIs


User Interface Design for Programmers, Joel Spolsky, 2001


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.




Software Structure with UI & Database


Tiers – parts of program run on different machines


Layers – parts of program run on same machine





Presentation – Display of Data


Domain – Logic related to purpose of the application


Data Source – Communication with data source




Rule One


  1. 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 does either presentation or domain logic


Can you test the domain logic with automated unit testing




Time Date Domain Layer


public class TimeDateClient


    private static final char CARRIAGE_RETURN = (char) 13;

    private static final char LINE_FEED = (char) 10;


    String server;

    int serverPort;


    public TimeDateClient(String serverNameOrIP, int port)


        server = serverNameOrIP;

        serverPort = port;



    public String date() throws IOException


        return sendMessage("date");



    public String time() throws IOException


        return sendMessage("time");



    public String sendMessage(String message) throws IOException


        Socket serverConnection = new Socket(server, serverPort);

        writeMessage(message, serverConnection);

        byte[] result = readMessage(serverConnection);


        return new String(result);




Time Date Domain Layer


private byte[] readMessage(Socket serverConnection) throws IOException


        UpToFilterInputStream in = new UpToFilterInputStream(

                new BufferedInputStream(


        byte[] result = in.upTo(LINE_FEED);

        return result;



    private void writeMessage(String message, Socket serverConnection)

            throws IOException


        OutputStream out = new BufferedOutputStream(


        out.write((message + CARRIAGE_RETURN).getBytes());






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






  1. High and immediate productivity for simple applications

  1. Little training need by the developer

  1. Short development time for small modules






  1. No reuse – code gets duplicated

  1. Integration of applications difficult

  1. Very difficult to add new functionality to existing application

  1. Difficult to build complex applications




Handling Domain Logic1

Transaction Script


Each procedure (method) handles one request from the UI


Each database transaction handled by one procedure




  1. Simple to implement

  1. Easy to follow how things get done




  1. No reuse – code gets duplicated

  1. Very hard to handle complex operations

  1. Does not scale well




Table Module


Each class represents one table in database


A request on the database is done through its table module




  1. Easily maps to the database

  1. Reflects the database structure – once you know the database schema, you know the table module logic





  1. Difficult to handle complex domain logic

  1. Database schema is reflected in application structure





Domain Model


Use objects to model the domain


Develop application with OO design




Scales well with complexity




Overly complex for simple solutions

Need to map object model to database schema (structure)




GUI Clients & Servers


GUI Clients

  1. Used to get work done

  1. Good when they help people get work done



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: Time Date Client



Protocol has two messages

  1. Date

  1. Time


Client has one button to get time & date



Interface Design When You Don't Know How



Basic Rule for Good Visual Design


Hire a graphic/GUI designer





Basic Rule for Almost Everything Else


Painstakingly follow established standards


All major interfaces have published detailed standards for user interface design


  1. Windows

  1. MacOS X

  1. Java

  1. GNOME

  1. KDE





What Makes a Good GUI?


A user interface is well-designed when the program behaves exactly how the user thought it would



Example - Deleting a file on a Mac


Move it to the trash can!



How do you unmount floppies & external hard drives?


Move it to the trash can


But users think this will delete or erase it



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


Users think the trash can deletes things


User Interface Standards Manual


Produce standards manual for the project


Manual should address the following:


  1.     Lexical Structure

What symbols are there?


  1. Syntactic Structure

How do they relate to each other?


  1. Semantics

How do they relate to the things they represent?


  1. Pragmatics

How do they relate to the user?



The Process


  1. Plan ahead

  1. Use bite-sized chunks

  1. Abandon the waterfall life cycle in favor of iterative design

  1. Conduct user testing early and often

  1. Focus on the users' needs and involve them in the process

  1. Come up with good, testable usability goals

  1. Hire a graphic designer






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





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



Lo-fi or Paper Prototypes

The Kit


White paper



Heavy enough to endure repeated testing and revisions



5-by-3-inch cards


Use as construction material

Taking notes





Tape: clear, colored, double-backed, etc.

Glue sticks

Post-It glue

White correction paper





Colored pens and pencils


Fine and thick markers



Sticky note pads


Acetate sheets


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





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"




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





Conducting a Test


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




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





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






Runs the computer


Moves the model in response to users "actions"





Takes notes


One observation per index card



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

1 See Fowler 2003

Previous     visitors since March 9, 2005     Next