Session 21

Interaction with Menus

810:171

Software Systems

Exercise 31: Transparent Menus

Goals

1. To understand better the principles of menu selection.
2. To consider the role that experimentation can play in identifying the features of good user interfaces.

Tasks

Work in teams of three or four people based on assignment in class.

Most menus are separate from the rest of the user interface--either in a separate window or window pane, or pull-down at the top of the desktop. Occasionally, a system will use menus that "pop-up" almost anywhere on the screen, on demand. This approach offers flexibility at the cost of occluding the part of the screen under the menu.

Some researchers have experimented with transparent menus, which also can occur anywhere on the screen but which can be seen through. Transparent menus offer the same flexibility as more traditional pop-up menus, but they may also be more useful to the users, who can still see some or all of the window beneath the menu.

Create a list of questions that researchers should investigate. Your list should include issues that help identify whether transparent menus are a good idea at all and issues that help identify when to use them and how to design them. Use ideas from Sections 7.2-7.5 as well as any other ideas that your team thinks are useful.

Suggest a set of experiments that HCI researchers could run to help determine answers to the questions. Each experiment should give us some information about just the phenomenon being tested.

After you have created your list, use your collective knowledge from reading Chapter 7 and from using human-computer interfaces to predict answers to some or all of your issues. Be sure to justify your answers!

Results

1. Your group submits its list and its predictions.
2. We discuss the idea of transparent menus and what empirical research to support the idea might look like.

Summary of Exercise 31

Research and HCI

Transparent menus sound like a good idea to many folks in HCI. But will they work? We shouldn't just assume that an idea will work when we have a better alternative: go find out! Finding out requires us to think about the various issues that could conceivably affect the utility of the idea. When then need to do some research to find out. And don't worry if you aren't one of the folks who thinks that transparent menus sound like a good idea; skepticism can help you to ask necessary questions. Just be open to having your mind changed if the results of your research turn out differently than you expect!

HCI offers a wide open door for empirical research. As we have learned from Shneiderman's text, we can often measure the effects of interface constructs on usability and human satisfaction. To do such research well, we will need to step outside of computer science to draw on expertise from psychology and other disciplines.

Research and Transparent Menus

Here are some of the questions that you and past students have asked about the feasibility of transparent menus:

• Does the type of menu matter? (e.g., help menu, edit menu)
• Does the font, color, type face, or font size matter?
• Does the number of selections on the menu matter?
• Does the degree of transparency matter?
• Does the underlying background matter?
• Does the type of user matter?
• Does the type of task matter?

• Can the degree of transparency carry information to the user?
  (e.g., more transparent menus are less important)
• What is the ideal location for a transparent menu?
• What is the ideal distance for the menu from the user's action?

Much more complex combinations of factors may matter, for example, the relationship among background type, transparency level, and type face. Do some combinations work better than others? If so, why?

Predicting answers is okay. Indeed, it can be fun, and it is a natural part of being human. Furthermore, it may even be necessary in order to know how to make progress in the field. But ultimately confirmation in repeatable, reliable experimentation is better!

Some Results on Transparent Menus

Research reported in the paper cited above provides some initial results:

• Does the degree of transparency affect the user's response time or error rate? Yes, but not in all the ways we might expect. At >80% transparency, human performance drops off rapidly. At <50% transparency, human performance is quite good. Between 50-80%, performance is still reasonable. Most promising is that fact that at levels of transparency of 90% or less, users made virtually no errors; they were just slower.

• In another experiment, researchers replaced words on the menu with a palette of icons and then measured the user's mouse-click selection time. In this experiment, the type of background matters. Solid images or icons allowed for greater recognition than when text or line art constitute the background. The crossover point seems to occur at about 50% transparency.

Research and CS

Computer science tends to be analytical or theoretical, not experimental. All too often, CS research comes down to a simplistic form of engineering: "Look, ma, no hands!" :-( We should always be on the look-out for ways to support our work with empirical results that confirm our theories and analyses. Software lives in the real world, not on an academician's notebook.

You may not have good experimental design skills. If you limit yourself to CS courses, you will learn few, if any. That is even more reason to take a broad variety of courses outside the department: psychology, other social sciences, and natural science can all make you a better computer scientist.

Research and You

At OOPSLA last fall, an industry person said that one of at least three things that he looks for in new hires is experience doing research--even when the new hires do not work in a research lab. He said that, two years down the road, the project for which a new person is hired will no longer exist. The projects that do exist in the company will likely involve technologies that the student didn't learn about in school and which are on the leading edge of industry. The now not-so-new hire will need to learn quickly the details of an existing project, or maybe even "figure out what to do next". A research background indicates some experience with thinking about the future.

By the way, the other two things that this highly reputable industry representative looks for are:

• Has the student written at least one large, non-trivial program by him- or herself? Computer scientists write programs, and a programmer can't contribute to the company or his project team without contributing programming skills.

• Has the student studied the "literature" of computer science broadly and deeply? The literature of CS is its classic programs, texts, and research papers. Broad study means coverage of most of the areas that make up computing. Deep study means coverage of one area of computing well enough to know its most important questions and results and to master its most important techniques. Indeed, it probably doesn't matter at all which area you master deeply--the process of mastering one area will equip you with the experience and confidence you need to master any other.

So, the next time one of your favorite instructors asks you to write a challenging program on your or to study a chapter or paper or program with great energy, know that he really does have your best professional interests at heart! :-) [The same assignments also have your best personal interests at heart.]

Exercise 32: Designing a Non-Direct Manipulation Interface

Work in teams of three or four people based on assignment in class.

On my mind lately has been the administrative system that we use to release registration holds for computer science majors. The interface is okay for the time at which it was designed and the software environment in which it runs. But reading Shneiderman reminds me that it could be a lot better.

Design a new interface for the academic information database.

This collection of programs runs on a non-GUI system in which text-based menus and form fill-in slots are the only means of user interaction. For today, focus primarily on the advising end of the operation. Here are a few stories that your interface should support easily.

• Jane, a student, comes to her advisor. She is about to enter her last semester and has only two course requirements to satisfy. The schedule that she proposes consists of those two courses and an elective course in mathematics. The advisor wishes her well and removes the hold immediately.

• John, a student, recently changed his major to computer science. He has taken several computing courses over the last couple of years while working on his previous major. He'd like to graduate in three semesters. The advisor wants to examine the student's transcript, but neither he nor John has a paper copy. The schedule that John proposes for next semester may work, but the advisor isn't sure that it will satisfy enough pre-requisites so that John can graduate on time. He accesses the department's tentative course rotation to provide guidance.

• Bob, another student, hasn't decided which elective courses to take. The advisor reviews the department's tentative course rotation on-line and offers some ideas. Bob decides to sleep on the decision, so the advisor waits to release the advising hold until Bob sends him e-mail with his final decision.

Your product should be a set of pages showing the menus and screens that the user (the advisor) will see in the course of advising sessions. Use the material in Chapter 7 as a basis for your design decisions. Pay careful attention to the wording of requests, the order of menu options, the layout of the screen, etc. If your first drafts become messy from changes, re-write them. (Do parallel processing if necessary. You are a team!) Be prepared to describe your system and to defend its layout.