Introduction to Graphical Human-Machine Interfaces
Weekly Discussion Questions

[Week 1] | [Week 2] | [Week 3] | [Week 4] | [Week 5] | [Week 6] | [Week 7] | [Week 8] | [Week 9] | [Week 10] | [Week 11] | [Week 12] | [Week 13] | [Week 14] | [Week 15]
Weekly discussions are carried out on the newsgroup rpi.courses.Spring97.GHMI. You should make sure that you post comments for each week's discussion question. Discussion questions often relate to the weekly readings or to other material discussed in class.

Below is a reverse chronoglogical list of the weekly discussion questions.

  • Week 15 (04/28/97)
    Please post your own discussion questions regarding any of the papers presented this week.

  • Week 14 (04/21/97)
    Please post your own discussion questions regarding any of the papers presented this week.

  • Week 13 (04/14/97)
    CSCW question to be announced

  • Week 12 (04/07/97)
    This week we have been looking at papers on the use of non-speech and speech sounds in the user interface.

    Here are some things I hope that you all get out of these papers/discussion:

    • Sounds can be used to effectively display information or make information available that might otherwise be missed if information was displayed only visually.
    • Ineffective use of sounds can make the interface worse (e.g., annoying, confusing, etc)
    • You must design your sounds just like you design for things you display visually. Sounds which mean something (even if they are abstract at first) work better than those that do not mean anything or are hard to learn. Two approaches to designing sounds are: earcons and auditory icons.
    • Sound (and speech) are useful to not just the visually impaired but even to able-bodied users. Think about using sounds for PDAs with smaller displays, interfaces to computers via your cell phone, or other situations where the use of a display or a keyboard might not be possible.
    • How we perceive information in sound is a big research area. There are many people doing research in this area. Sounds have been used to creating visualizations, this is called data sonification. One such group of researchers is ACM's SIGSOUND forum.
    • As speech recognition becomes even more widespread, user interface designers will need to learn how to build applications that make effective use of speech. As some of you have pointed out in your questions, speech systems are slower to use than typing at a keyboard, due to the slow nature of speech itself. Researchers must find ways to make speech systems natural and comfortable to use (not necessarily as fast as keyboard entry, so long as the user perceives the system is operating quick enough).
    The other thing I hope you get out of this discussion is that, as user interface designers, you want to design systems that are usable by a variety of users. It is not economically viable to take a very visual interface and decide later that you want it to be accessible to blind users. That might mean re-designing your system from scratch! Better, would be to DESIGN FOR DIVERSITY from the start. Of course, it depends on who your TARGET AUDIENCE is, but systems which can support a wide ranger of users (from young to old), with varying capabilities (motor impaired, visually impaired, hearing impaired, even speech impaired) will better integrate into society as a whole.

    Clearly, re-implementing existing applications and making them more visually-impaired friendly is not the best way to go. This is why researchers have been studying systems like Mercator which allow us to make a whole platform of applications (e.g., X Windows) accessible using a screen reader. However, this means that the X protocol must make available some information so that the screen reader can figure out what is going on visually.

    Another approach is to figure out how to design systems which can display information in more than one way, without the use of a screen reader, for example. If designers created applications which were "presentation independent", but then at run-time a suitable presentation was chosen for that user. This is the kind of work I am doing for my PhD with the use of metawidgets, which contain multiple representations of information in various modalities.

    To wrap up our discussion of the use of audio and/or speech in the interface, I thought I would post some of the questions that you all put on your index cards.

    Please take a few minutes to post your comments on any (one or more) of the questions. Feel free to also comment on any of the comments I made above or other thoughts you have about auditory/speech interfaces.


    If you are interested in learning more about this system, please see TV Raman's web page that discusses Emacspeak: http://www.cs.cornell.edu/Info/People/raman/emacspeak/emacspeak.html

    See also the Emacspeak FAQ: http://www.cs.cornell.edu/Info/People/raman/emacspeak/faqs.html

    Those of you that are avid emacs users know that you can do lots of things from inside emacs: browse directories, read mail, read news, browse the web, run a shell, compile and edit various programming languages, etc. So if you use emacs a lot, emacspeak works with any application that runs inside emacs.

    Here are some questions you all posed:

    E1. This seems very limited how. How could you standardize it so that it works for more than just emacs?

    E2. Can you think of any additional users for this system besides use by the blind/visually impaired?

    E3. Could something such as emacspeak be applied to any platform or environment? Such as a PC or Macintosh running Windows 95 or System 7? {Note: on the Emacspeak web site Raman talks about how he uses it with his terminal emulator and on the linux console}

    E4. It doesn't seem to make economic sense to convert applications to be visually-impaired friendly one-by-one. Wouldn't it make sense, though, to create a toolkit to facilitate this I/O mechanism?

    E5. Can users talk back as opposed to using the keyboard to respond to the application?

    E5. Does this system represent pictures w/voice? If _not_ is there any ideas on how to do this ? I am not exactly clear how this system "displays" the calendar?

    E6. Creating a totally sound based interface is invaluable for the visually disabled, but because of the time needed for speech, I would think imagine that such interfaces would be slower to use. What methods might be useful to accelerate this process?

  • Week 11 (03/31/97)
    This week we have been looing at visualization techniques. Let's try applying some of these techniques during this week's discussion question. Suppose you are developing visualization systems for the following:
    • Shipment tracking and planning. Like UPS and FedEx, your company is trying to get ahead of this market by using proprietary software to track customer shipments. How would you design a visualization system to track shipments in progress and monitor congestion of your shipping routes? Your company has an impressive fleet of trucks, planes, and trains.

    • Crime statistics. As a member of a Federal task force on crime you are constantly bombarded with data from cities throughout the country. You have dumped all of this data into a huge database but now want to find some way to look at all of it. You want to be able to find out which crimes are on the rise, which cities have the worst crime rates, which crimes are spreading, and which cities have been able to reduce the amount of crime. How would you design a visualization system to help examine all of the data?
    Post your ideas for designing each of these visualization systems.

  • Week 10 (03/24/97)
    Now that we have an understanding of web usability -- what makes a web site design good or bad -- let's look for examples of good and bad Web sites. Your goal for this week's discussion question is to find an example of

    (1) a good, usable web site, and
    (2) a bad web site.

    For each site, post the URL and explain why the web site has a good or bad design.

  • Week 9 (03/17/97)
    In class, we have been examining the capabilities of higher order tools for user interface development. We have examined prototyping tools, interface builders, application frameworks, user interface development environments. We have also seen new techniques, such as demonstrational interfaces and constraint systems, which can be used to create highly interactive graphical tools (e.g., Garnet).

    This week let's discuss the strengths and weaknesses of these higher order tools. What do you like about them? What are they good for? What do you not like about them? What needs to be improved?

  • Week 8 (03/03/97)
    You all now have some experience creating user interfaces using the X toolkit and have an idea of what programming using a toolkit is about.

    From a programmer's persepctive, consider the strengths and weaknesses of toolkit programming. If you could create a user interface tool that made developing X toolkit applications easier, what do you forsee that tool being able to do? What kinds of tasks would the tool help the programmer with. In the coming weeks we will look at some higher level tools.

  • Week 7 (02/24/97)
    We now have some idea of what characterics a good user interface should have. We have seen guidelines and heuristics to aid the development of high quality, usable, user interfaces.

    This week let's discuss bad user interfaces. Think of the user interfaces you use. Give us an example of a bad user interface and one reason why you think it is bad.

  • Week 6 (02/17/97)
    With the short week and the pleasure of having to write a program using the X Window System, we thought we'd share an old post from rec.humor.funny concerning X by John R. Murray.

    (I don't know how old the joke is, but Murray appears still to be at SCRI, so if some brave soul wants to ask him, please post the results here. His home page is www.scri.fsu.edu/~murray/.)

    You are welcome to share comments or questions about X, or to devise creative additions to the list at the bottom of this post. But don't feel obligated to respond to this message.



    First, we computer folk had the terms software and hardware, then firmware, then a number of other -ware terms came into usage, such as freeware, shareware, vaporware and others. To add to the ever-growing list of -ware terms, I would like to propose this one:

      Vacuumware: n, software which was written specifically to fill a void in the industry, especially software which is successful more due to how well it fills that void than due to anything else, like usability or utility.

    I believe it may have been Dennis Ritchie who said (about X) "Sometimes when you fill a vacuum, it still sucks." X is a prime example of vacuumware, and in fact inspired the term.

    John R. Murray murray@indigo2.scri.fsu.edu
    Supercomputer Computations Research Institute

    X windows. A mistake carried out to perfection. X windows. Dissatisfaction guaranteed. X windows. Don't get frustrated without it. X windows. Even your dog won't like it. X windows. Flaky and built to stay that way. X windows. Complex nonsolutions to simple nonproblems. X windows. Flawed beyond belief. X windows. Form follows malfunction. X windows. Garbage at your fingertips. X windows. Ignorance is our most important resource. X windows. It could be worse, but it'll take time. X windows. It could happen to you. X windows. Japan's secret weapon. X windows. Let it get in *your* way. X windows. Live the nightmare. X windows. More than enough rope. X windows. Never had it, never will. X windows. No hardware is safe. X windows. Power tools for power fools. X windows. Power tools for power losers. X windows. Putting new limits on productivity. X windows. Simplicity made complex. X windows. The cutting edge of obsolescence. X windows. The art of incompetence. X windows. The defacto substandard. X windows. The first fully modular software disaster. X windows. The joke that kills. X windows. The problem for your problem. X windows. There's got to be a better way. X windows. Warn your friends about it. X windows. You'd better sit down. X windows. You'll envy the dead.

  • Week 5 (02/10/97)
    In the second in-class exercise you and others in your group came up with various designs for slider widgets. Tell us one of the issues your group discussed while designing your sliders. Also, from the sliders you have seen from the other groups, tell us which one was most appealing or innovative to you.

  • Week 4 (02/03/97)
    In class, we have been looking at aspects of window systems and various ways user interfaces can be implemented for them. One way is to program using a toolkit. Toolkits contain libraries of 'widgets' -- scroll bars, buttons, toggles, etc -- which can be used to construct the user interface for an application.

    For this week's discussion you are to bring to our attention two different widgets:

    (1) Pick a widget that you have seen used on existing applications that run on today's graphical user interfaces (i.e., X Windows, Macintosh, Microsoft Windows, etc) and tell us what the widget is best used for. One example might be a text edit box which allows the user to type in a string.

    (2) For your second widget, come up with a NEW widget, one that you do not believe you have seen before. Tell us what you envision the widget being used for.

    For (1) try to mention a widget that someone else has not already brought up. Let's see how many different widgets we can come up with.

  • Week 3 (01/27/97)
    We have seen how the use of metaphor can sometimes lead the user into coming up with a faulty model of the system. The use of the post office/mailbox metaphor was not an appropriate metaphor for the voice mail system because it did not accurately reflect the fact that messages might be delayed to their destination.

    This week let's discuss different metaphors used in software systems.

    Think of different software systems you have used in the past. Try to determine the metaphor that was used. Was it appropriate or inappropriate?

    If you cannot think of a software system, come up with a new metaphor and suggest for what applications it might be useful for when constructing the user interface.

    Post your findings to the newsgroup.

  • Week 2 (01/20/97)
    Norman discusses many examples of everyday objects that are hard to use. Usually because the mapping from the control to the function is not apparent, or because the complexity of the device is so high that the user cannot figure out how to achieve the desired task.

    Look around your home (apartment/house/dorm), your car, and on campus for things which have bad mappings or lots of complexity that make them hard to use. It could be a household appliance, an electronic gadget, a software program, or whatever. Find one example to share with everyone for this week's discussion.

    Tell us what you found and why it is hard to use. And then tell us how you would design the device/object differently.

  • Week 1 (01/13/97)
    In 1945, Bush's envision of the MEMEX was, indeed, before its time! List and discuss features and ideas from MEMEX that are present in today's systems. Also, discuss ideas and concepts that have not yet been achieved with current technology. If you were to build a MEMEX today, how would you do it? What technology would you use?