Software Design (CSC-223 97F)
Outline of Class 23: Introduction to Human Factors in Computing Systems
- Like many of you, I'm a procrasinator. In this case, it means that
I haven't finished reviewing your project proposals. I will do my best
to get them back to you on Wednesday. My quick scan suggests that more
detail would have been good.
- I'll try to get the outstanding homework assignments back by Friday,
but that's less likely.
- Thanks for participating in the web survey. I've made a few changes
to the course web and will try to do more (within time constraints).
If you're interested in what I did with it, see
the paper I wrote over break. Some of the results may appear odd.
I just realized (early this morning) that there were some problems with
the survey software, but those problems will be fixed in the final version
of the paper.
- There is a short
new assignment that
should be finished by noon on Wednesday.
- For this week, you should have read all of the Winograd book. We
may not discuss it explicitly, but you should be familiar with the
material contained inside. I'll get you next week's readings by
- Human factors in computing systems is the study of the interrelationship
of humans and computing systems.
- Usually, it is the study of the usability of computing systems
that is, how well they meet tasks.
- It's clear to most users of computer systems that what the
system does is not the only affect on usability; how it
does things (or, more precisely, allows the user to do things) is
- It is (or should be) a goal of most systems to be as usable for
their intended population as possible.
- Note that different products have different populations.
- The design of a product requires a host of decisions, both large and
- One large decision is the "virtuality" the system provides, such
as the dynamic spreadsheet world of VisiCalc.
- One small decision (but with large impact) is the ordering of items
- Some design is task-based: given a task, how do design choices affect the
complexity and time of the task.
- Tasks can be large, such as reformatting a document to meet different
- Tasks can be quite small, such as selecting a menu item.
- Task-based design makes it possible to compare related designs by
seeing which better supports the expected tasks of the system.
- Note that a design that is optimal for one task is not necc. optimal
for another task. For example, if we required all formatting to be
done with preselected style names (e.g., section heading, paragraph,
first paragraph, etc), then the reformatting task mentioned earlier
becomes nearly trivial. However, it may become more difficult or
time consuming to crank out memos that "look nice".
- Some design is feature-based: What features or capabilities does the
- These may be explicit: "By selecting spell, the system checks
the veracity of spelling in the document"
- These may be implicit.
- These may be basic (you can change fonts).
- These may be compound (your can reformat documents).
- There may be features not predicted by system designers.
- Since there are many domains, many types of users, and many types
of input devices, there are no hard and fast guidelines for the
design of user interfaces, or even the process of design.
- For example, there are good arguments for sticking with a standard
interface (e.g., Macintosh User Interface Guidelines) and arguments
for breaking that interface (e.g., KPT Bryce).
- One good rule is to involve users whenever possible.
- Here's a sketch of one reasonable process for design, applicable to
- Articular system's mission.
- Develop/profile background information
- Potential users
- Potential resources
- Suggested features and design
- Interview sample populations
- Refine features and design
- Specify and prototype
- Rather than listening to me lecture about design, we're going to attempt
a brief (week long) design experiment, which I've called
- In particular, we will begin with a high-level design statement,
refine the statement, develop list of features and users, interview
potential users, and go on from there. We will not implement the
result of our design.
- In summary, our goal is to Design a web usage analyzer.
That is, a tool for web authors, designers, and administrators to use
to better understand the usage of the pages at their site or subsite.
- Just so you know, a typical line from the log generated by our http
server looks like:
fubar.grin.edu - - [20/Oct/1997:13:23:12 -0500] "GET /~alpha/beta/
gamma/delta.html HTTP/1.0" 200 4834
- That is,
- The name or IP address of the machine that made the request.
- The time the request was made.
- The request (typically
GET put also
HEAD, and prehaps others).
- A result code (200 means success).
- The number of bytes transfered in response to the request.
- In groups of between three and five, spend about ten minutes coming
up with some short answers to the following questions:
- Who are the potential users of the system?
- What questions might they use the system to ask?
- What other uses might they make of the system?
- What new uses might the system suggest?
- How do we support those users?
- What features should our system provide?
- How do we present those features?
- Which, if any, "virtualities" are appropriate for this system?
- What resources do we need?
- In class, we'll attempt to come up with lists of the preceeding
issues for use in
- I'd like one of you to email me a summary of the lists we come up
with in class.
- You can view my answers
after you've developed your own.