Computer Science and Software Engineering 371

Software Requirements and Specification

Fall 2005

Exam 3 Review Solution

1. From page 12 of the Interaction Design text:

a. Developing alternative designs that meet those requirements.

b. Building interactive versions of the designs so that they can be communicated and assessed.

c. Evaluating what is being built throughout the process.

2. From page 47 of the Interaction Design text:

This is manipulating-and-navigating. According to Ben Schneiderman, who invented it, the benefits are:

a. Helps beginners learn basic functionality rapidly.

b. Experienced users can work rapidly on a wide range of tasks.

c. Infrequent users can remember how to carry out operations over time.

d. No need for error messages, except very rarely.

e. Users can immediately see if their actions are furthering their goals and if not do something else.

f. Users experience less anxiety.

g. Users gain confidence and mastery and feel in control.

3. From pages 94-95 of the Interaction Design text:

In theory, OO and ID should give the same answers here, in the sense that our goal in OO is to make objects function the way users and others would want them to function to accomplish their goals, and OO analysis and design are supposed to model and enable that. So, if the users want to see how and why some device or feature works when they push a button, we can provide that kind of user verification and make those functions transparent via OO methods.

However, if we apply just the idea of whether or not making things “transparent” is a good idea, in OO design and programming, then we see that it’s not the same as the concept of transparency in ID. OO is all about simplification via information hiding, making it as obvious as possible what everything does while making invisible how they accomplish that. OO is inherently a land of magic widgets. So, following those rules, an equivalent interface should hide everything from the user except the intended paths. We would assume that the designer knew exactly what should be public and private, and not let the user see the private stuff, for fear of their messing it up.

In the situation we are requesting you consider here, maintenance, it is likely that this OO approach would not work so well, because, after all, things are already messed up, and the person fixing is likely going to have to pick through some amount of information, looking for a cause. The necessity for the designer following the OO model to anticipate legitimate use, and to close off unintended uses, would seem counterproductive.

In ID, the idea of design transparency really is that there is an “easy to understand system image…providing useful feedback in response to user input and easy-to-understand and intuitive ways of interacting with the system.” Additionally, the transparency concept says the designer should provide “the right kind and level of information in the right form,” including clear and easy-to-follow instructions,” … and “context-sensitive guidance, set at their level of experience.” This design idea of transparency might in fact be a very good thing for a maintenance user, to help make clear what is going on through revealing the most important things – bringing those to the user’s attention as they try to fix the software. But the ID person would surely account for the fact that the route followed toward a successful fix could not all be anticipated by the designer.

So, if the question is, how does this compare with what you could call OO transparency? The answer is, they are a lot different!

4 From page 112 of the Interaction Design text:

a. Lack of adequate bandwidth has plagued video communication, resulting in poor-quality images that frequently break-up, judder, have shadows, and appear as unnatural images.

b. It is difficult to establish eye contact (normally an integral and subconscious part of face-to-face conversations) in CVEs, video conferencing, and videophones.

c. Having the possibility of hiding behind a persona, a name, or an avatar in a chatroom gives people the opportunity to behave differently. Sometimes this can result in people becoming aggressive or intrusive.

5. From page 149 of the Interaction Design text:

Ideally, error messages should be treated as how-to-fix-it messages. Instead of explicating what has happened, they should state the cause of the problem and what the user needs to do to fix it. Schneiderman’s recommendations are:

a. Rather than condemn users, messages should be courteous, indicating what users need to do to set things right.

b. Avoid using terms like FATAL, ERROR, INVALID, BAD, and ILLEGAL.

c. Avoid long code numbers and uppercase letters.

d. Audio warnings should be under the user’s control, since they can cause much embarrassment.

e. Messages should be precise rather than vague.

f. Messages should provide a help icon or command to allow users to get context-sensitive help.

g. Messages should be provided at multiple levels, so that short messages can be supplemented with longer explanations.

6. Full user immersion, and the strengths thereof: Almost all of Ch 6 argues that the ID development cycle must cycle because of the error-prone nature of learning about users and how they will use the system. Thus, they don’t know what they want until they use it, and what are the odds the thing you developed is it, unless they got to see it ahead of time? This is a lot like XP, where designs are exposed to users throughout the development cycle. The related aspect of XP is that designs are improved continuously. Some good things about their common recommendation for user involvement are these:

a. While it’s true that users will continue trying to add-on new features, they also will react strongly to the usability of what they see at each point, a preview of their reaction to the real product. And,

b. They can’t do this critique until they see something. Just talking about it, for example, isn’t close enough to the real thing for most users’ “judgment” about that to kick-in.

Then also add at least one way XP development model and the recommended ID model of Chapter 6 would differ:

Differences between ID and XP models: These methods really aren’t the same, because XP tries hard to get a feature “right” and then go on to develop another feature, with most of the upgrade being refactoring and other internal change to support growth. But it’s close! ID people would argue that, even with XP, you are unlikely to get it right the first time, on anything new involving users. So the reasons for wanting such close user interaction are similar, if not exactly the same.

7. The problem is that user closeness guarantees a continuous flow of new requirements. The developer distance guarantees they want something to stop and think about, then work from. And there is a limited channel of communication between them (probably you!). Possible ways to resolve the problem (many from you):

1. Get users to agree to a set of baselined requirements, after which changes are formalized and cost more. They may be convinced this is a good idea because their stream of changes is preventing project progress.

2. Get the users and developers closer to one another. For example, a user “representative” onsite where the developers are, or regular “developer visits” to the customer’s shop.

3. Talk everyone into an incremental plan, so that the developers can proceed with something!

4. Set up a JAD-type workshop where they all work together for a few days to get it right.

5. Educate the users so they know better what they want.

6. Get users and developers into an “exchange” program where they learn more about each others’ cultures informally.

7. Get something working fast, then show it to the users to get them to focus on perfecting that part instead of wildly new stuff.

8. Developers could work on some non-user-related aspects of the system while you’re trying to work this side of the project.

8. One intent would be to market high profit items to a very wide audience at the same time! To get people to put up with such things (like the dancing pig), the actual free information people are looking for must be high quality and easy to use. Aside from the pig, the other suggestive features are a mixture of helpful tips (like finding “what’s nearby”) and much more targeted ads (like the car rentals).

“Wizard of Oz” has a human replacing some of the computerized interactions here, during prototyping or test marketing. A Wizard of Oz for this screen might ask people to say what locations, products or services they are interested in relative to this map, and then pretend to offer those up to a focus group, etc. In this way, MapsOnUs might discover that people looking for this address really want to see next a map of the Rose-Hulman campus, for example.

Another alternative would be to see how users use physical maps, and try to emulate that, or get users to tell the human observer what they are looking for, and what else they’d like to see.

Having humans in the loop might tell MapsOnUs whether or not they need to move to a more direct interaction model, such as users get with Yahoo Maps, for instance (with landmarks shown directly on the map).

For such a graphical application it’s certainly more difficult to have a human behind the scenes inventing new things, which several people mentioned.