Session 2

Orientation to Interfaces


810:171

Software Systems


Recap Exercise 2: Understanding Ways to Evaluate Software Systems

In Exercise 1, we identified kinds of software systems and some criteria by which software can be classified. In Exercise 2, you are taking this idea forward by thinking about the kinds of criteria available to us.

Be sure to name your various groupings of the criteria. A good name can capture the essence of the grouping. Finding a good name can help you to understand why you made the grouping in the first place...


Summary from Exercise 2

The most common distinction made was "human" versus "technical", where "technical" variously indicated administrative concerns, developer's concerns, and purchase concerns. "human" usually meant "relating to the user".

Many of your groupings of criteria hint at why some dimensions you considered last time seemed prone to broader agreement within your teams than others, and why some dimensions seemed to make for easier classification.

Some students have made another interesting distinction that I characterize as "now versus later". Which of these dimensions matter now, and which matter in the future. What is neat is that this distinction depends in part on how we define "now", and so can be many distinctions in one!

A couple of different approaches to classification were:

Under many schemes, some criteria rightfully belong in multiple categories.

You are creating a framework for analysis, a set of standards and terms to use when analyzing software systems. Much of our work this semester, based on Shneiderman, will do the same thing--with a particular focus on human interaction with programs.

On an exercise like this, there is no "right" answer, but some answers are better than others. "Better" might mean "more complete", "better explained", "more helpful", etc. The value you get from doing the exercise is not getting the right answer, but understanding the question and understanding what you should be thinking about when trying to answer it.

How should you go about this? You could work off the top of your heads, collectively brainstorming groupings that seem meaningful to you. When you use this approach, often the most valuable part of the exercise is in trying to give a meaningful name to groupings that seem so intuitive.

Unfortunately, brainstorming and intuition can take you only so far. If nothing else, they tend to be limited by your own experiences, which are incomplete and often not representative of the whole community of software user. That's where your reading assignments can help. Study the text, and then try to apply what you've read. That's the best way I know of to learn the textbook material anyway. And the readings give you some objective basis for guiding your thoughts.


Toward a New Perspective on Software

The content of this course differs somewhat in emphasis from other computer science courses. Here are the key ideas:


Exercise 3: Beginning to Design and Evaluate Interfaces

Goals

Now that we have thought about the criteria by which software can be judged, we want:

  1. To consider how personal experience colors our views of what makes a good user interface.
  2. To get a feel for what we do and don't know about interfaces, so that we have a framework within to work throughout the semester.

Tasks

Work in the same teams to do the following:

  1. Design an interface for a [word processor OR web browser]. Assume that your target audience consists of [novice OR expert] users. Do not feel bound by any interface you have ever seen before. Let your imaginations run wild!

    Document your design with pictures, descriptions, and anything else that you think gets your ideas across to someone not in your team. Be sure to write your names at the top, as well as the type of system your interface is for.

  2. Hand in your design to the instructor and receive in return another team's design.

  3. Critique the design you have been given. Identify the strong and weak points of the design. Be fair and constructive.

    Do not write on the other team's design. Write your critique on a separate page, but be sure to identify the team whose design you evaluated.

At the End

  1. Turn in your critique and the other team's design.
  2. If time is available, one or more groups will present their work.


Summary from Exercise 3

Questions to ask yourself:

Your experience shapes your view of the world. But you are not equal to your software's users. One goal of this course is to give you tools for evaluating software that allow you to step outside the strightjacket of your own view of software.

A recurring theme: The fact that there is no right answer does not mean that all are answers are equally good. ...

Think of this as the pre-test week ...

On a more mundane note: How you write up your results matters! Other people have to be able to read them, even if that other person is only me.


Eugene Wallingford ==== wallingf@cs.uni.edu ==== January 11, 2000