Outline of Class 23: Introduction to Human Factors in Computing Systems

Miscellaneous

• 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 Wednesday.

Introduction to Human Factors

• 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 also important.
• 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 small.
  • 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 in menus.
• 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 standards.
  • 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 system provide?
  • 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 some situations.
  • 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
  • Repeat

Project Clio

• Rather than listening to me lecture about design, we're going to attempt a brief (week long) design experiment, which I've called Project Clio
• 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.

The goal

• 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.

A resource

• 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 POST, HEAD, and prehaps others).
  • A result code (200 means success).
  • The number of bytes transfered in response to the request.

Small Group Discussion

• 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?
  • Are the logs enough?

Reports from Groups

• In class, we'll attempt to come up with lists of the preceeding issues for use in the assignment.
• 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.