Download Lecture 1 - People.cs.uchicago.edu

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
CSPP 533
Instructor: Tom Hayes
[email protected]
Course web page:
http://www.cs.uchicago.edu/~hayest/cspp535
Course mailing list: cspp535@cs
Course directory:
/stage/classes/current/cspp535
Course Goals
What makes a good interface
Best practices for writing one
Get hands dirty
o
Programs to show off
Textbooks
A Java GUI Programmer’s Primer
by Fintan Culwin
Assignments
Posted on the course web site.
Due on the specified date.
Changes & clarifications announced on
course mailing list
Mostly programming assignments:
electronic submission
Some written assignments: due in class
Course Project
Graphical “windows” interface to Linux
file system
Open-ended
Minimum requirements TBA
Final Exam
Probably about 1 ½ hours, during one
of the last couple lectures
Mostly theoretical
Will cover concepts from class and the
reading
Why UI?
Software does not exist in a vacuum



Productivity
Ease of use
Salability
Why this course?
Want good UI
Hard to write good UI
Good way to gain expertise in OO
design and execution
Hone project management skills
Example: SquarePuzzle
A simple application program:
SquarePuzzle.java

Text-based interface
GUI version
Code is in 3 files now:
SquarePuzzle.java (application)
SquarePuzzleDisplay.java
(presentation/
translation)
SquarePuzzleApp.java
SquarePuzzle.java API
GUI Design
Object-Oriented (OO) approach

Modularity
 Clear Division of Code into Pieces (Modules)

Encapsulation
 Modules can’t play with each others privates

Abstraction
 Simple, consistent Interfaces,
complex, changeable Implementation

Inheritance (Design Hierarchies)
GUI Design II
Front End (UI) must be separate from
Back End (Application)



Flexibility (upgrades, extensions, ports)
Maintainability
Elegance
 Natural choice of modules
 User view: form vs. functionality
 Cleaner code
GUI Design III
Take this one step further:
Presentation, Translation, Application


Object-Oriented approach leads us to think
of the front-end components as objects, to
which functionality is attached.
Form (Presentation) vs. functionality
(Translation) within the UI.
PTA: components
Presentation

What the user interacts with directly.
Translation

Controls the behavior of the program in
response to user actions.
Application

Core functionality
Presentation-Translation- App
event
method
invocation
User I/O Pres
Trans
App
method
value
invocation
returned
Note: Other arrow-labels are possible
Machine
Finite State Automata (FSA’s)
A model of computing in which the
machine (or automaton) has finitely
many states. At any given time it is in
exactly one state. Each possible input
event causes the machine to change
states in a fashion which depends only
on its current state.
Diagrams for FSA’s
start
States are labeled boxes/ovals.
Input Events are labeled arrows. E1


S1
Arrow points from old state to new.
(These may be the same)
One arrow out from every state in which
the event can occur.
Start is indicated by black circle.
End states have no arrows out.
Yes
No
E3
Maybe
E2
S2
E4
E5
FSA for tennis scorekeeping
A
A WINS
40-0
A
30-0
B
A
15-0
start
B
40-15
A
B
B
A
0-30
B
B
A
0-40
B
B
A
A
B
A
Deuce
A
15-30
0-15
Adv A
B
A
15-15
0-0
A
30-15
B
A
A
B
A
Adv B
15-40
B
B
B
B WINS
State Transition Diagrams
A visualization tool for programming.
Like diagram for FSA except



“States” do not completely describe the
state of the machine
Events may cause different state changes
depending on additional conditions
Events may have side effects
Similar to old-style flow-charts
UI design issues I
Mental processing requirements



learning time
concentration required
user errors (minimize)
Allocation of functions



user
program
other programs
UI design issues II
Mental models of system operation


user expectations
interface consistency
 may limit extensibility

physical analogies
 continuous representation
 reversibility
 event-driven style
UI design issues III
Evolving user sophistication



Choice vs. Confusion
Multiple paths
Customization
Varied User Environments



Multiple Languages
Cultural References
Special User Needs/Handicaps
Start of Lecture 2 Material
Events (intro, SUN)
Event Listeners (more advanced, SUN)
Event passing model
Three key players:



Event generators
Events
Event listeners (a.k.a. event handlers)
More flexible than message-passing via
method invocation.



One-to-many (broadcast)
Many-to-one (can do this with method invocation)
Combinations of the above
Events and GUI’s
Multiple views of information can be
simultaneously updated
Easy to support multiple input paths
(different ways for user to achieve same
result)
Java GUI Components
Sun’s Visual Index to Components
Window: JFrame, JPanel,
LayoutManager, JDialog
Menu: JMenuBar, JMenu, JMenuItem
Button: JButton
Display: JLabel
Guide to Components
Title link takes you to Sun’s “how-to”
page for each component. This contains
links to the component API, demo code,
and related pages.
My additional comments and links are
below.
Swing Component Hierarchy
Object
Component
JTextComponent
Window
Container
Dialog Frame
JComponent
JDialog JFrame
AbstractButton
JButton JMenuItem JToggleButton
JPanel
JMenu
JFrame
Good parent class for an app.
By default, hides on close. Must
override to destroy.
Primary sub-parts: Titlebar, Menubar,
ContentPane
JDialog
OptionPane subclass is handy,
disposable.
Design choices: Modal or not? Also: Is
this dialog necessary or annoying?
(Quit? Are you sure? Really?)
LayoutManager
Controls how Components are added to a
Container. This should be used for almost all
positioning needs.
FlowLayout is default. GridLayout also very
easy to use. BorderLayout, CardLayout,
GridBagLayout more complex but sometimes
useful.
Nest Panels inside one another to achieve
complex layout effects.
After all that…
How to make a combination
component/applet/application.
JFrame
MyClock
MyClock
app
pres
trans
main
Object
ClockApplication
cal
incHour/Minute/Second
setHour/Minute/Second
val
getHour/Minute/Second
int
“tick”
addActionListener
removeActionListener
tim
ActionEvent “tick”
listener
listener
listeners
JPanel
ClockPresentation
ClockPresentation
translator
setHour/Minute/Second
val
listener
addActionListener
removeActionListener
listener
hourButton
minButton
secButton
ActionEvent “increment”
listeners (ClockTranslators)
Object
ClockTranslator
app
ClockTranslator
clockapp
clockpres
pres
actionPerformed
ActionEvent e