From perlman Mon Nov 25 10:03:29 1996 Received: by turing.acm.org; id AA32365; Mon, 25 Nov 1996 10:03:29 -0500 Date: Mon, 25 Nov 1996 10:03:29 -0500 From: Gary PERLMAN Message-Id: <9611251503.AA32365@turing.acm.org> To: tharon@hubcap.clemson.edu Subject: Re: Help keep UTEST alive Cc: perlman Status: R Dr. Howard, I want to convey my appreciation for your continuing support to the HCI community by your UTEST mailing list. While many lists go unused because of lack of activity or low quality, the UTEST list has consistently been a source of relevant information for people concerned with the usability of systems. Looking over my personal UTEST mailbox, I see that I have archived 54 messages from UTEST for future reference; I compare such archiving to marking journal articles for future reference, which indicates that UTEST is more useful to my work than many journals. I have found the UTEST list useful enough to promote it in one of my HCI Resources articles for ACM interactions magazine. An electronic copy of this article is available at: http://www.acm.org/~perlman/interactions/24-org.html I do not make much use of the UTEST web site, however. And based on a search of AltaVista's advanced query for: link:tigger.clemson.edu/utest it does not appear that too many people are linking to it. By comparison, AltaVista lists 300 links to: cis.ohio-state.edu/pub/hcibib Gary PERLMAN, OCLC Online Computer Library Center 6565 Frantz Road, Dublin, Ohio 43017 USA Voice: +1-614-761-5058 Fax: +1-614-793-0915 Email: perlman@acm.org WWW: www.acm.org/~perlman From tharon@hubcap.clemson.edu Mon Nov 25 10:09:55 1996 Received: (from tharon@localhost) by hubcap.clemson.edu (8.7.1/8.7.1) id KAA13290 for perlman@turing.acm.org; Mon, 25 Nov 1996 10:11:25 -0500 (EST) From: Tharon Howard Message-Id: <199611251511.KAA13290@hubcap.clemson.edu> Subject: Re: Help keep UTEST alive To: perlman@turing.acm.org (Gary PERLMAN) Date: Mon, 25 Nov 1996 10:11:25 -0500 (EST) In-Reply-To: <9611251503.AA32365@turing.acm.org> from "Gary PERLMAN" at Nov 25, 96 10:03:29 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R Thanks, Gary. Re the UTEST web site, actually, I've kinda tried to keep it a secret and deliberately haven't registered it with Yahoo, AltaVista, or other such engines. This is also true for the list. Besides hiding from spammers, one of the main reasons I've tried to keep them from growing is this resource consumption issue. I routinely catch grief from certain folks about the load UTEST puts on the mail server. Many thanks for your message! :-) Tharon Gary PERLMAN writes: > >Dr. Howard, > >I want to convey my appreciation for your continuing support >to the HCI community by your UTEST mailing list. >While many lists go unused because of lack of activity or low quality, >the UTEST list has consistently been a source of relevant information >for people concerned with the usability of systems. >Looking over my personal UTEST mailbox, I see that I have >archived 54 messages from UTEST for future reference; >I compare such archiving to marking journal articles for future reference, >which indicates that UTEST is more useful to my work than many journals. > >I have found the UTEST list useful enough to promote it >in one of my HCI Resources articles for ACM interactions magazine. >An electronic copy of this article is available at: > http://www.acm.org/~perlman/interactions/24-org.html > >I do not make much use of the UTEST web site, however. >And based on a search of AltaVista's advanced query for: > link:tigger.clemson.edu/utest >it does not appear that too many people are linking to it. >By comparison, AltaVista lists 300 links to: > cis.ohio-state.edu/pub/hcibib > >Gary PERLMAN, OCLC Online Computer Library Center >6565 Frantz Road, Dublin, Ohio 43017 USA >Voice: +1-614-761-5058 Fax: +1-614-793-0915 >Email: perlman@acm.org WWW: www.acm.org/~perlman > ----------------------------------------------------------------------- Dr. Tharon Howard e-mail: tharon@hubcap.clemson.edu Clemson University Voice: (864)656-3488 | FAX: (864)656-1345 MA in Prof. Comm. http://marvin.clemson.edu/tharon/tharon.home.html From uie@world.std.com Tue Mar 4 16:28:19 1997 Received: by europe.std.com (8.7.5/BZS-8-1.0) id QAA27289; Tue, 4 Mar 1997 16:30:05 -0500 (EST) Date: Tue, 4 Mar 1997 16:30:05 -0500 (EST) Message-Id: <199703042130.QAA27289@europe.std.com> X-Authentication-Warning: europe.std.com: daemon set sender to uie@world.std.com using -f To: perlman@turing.acm.org From: Majordomo@world.std.com Subject: Welcome to uietips Reply-To: Majordomo@world.std.com Status: RO -- Welcome to the uietips mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "uietips-request@world.std.com": unsubscribe Or you can send mail to "Majordomo@world.std.com" with the following command in the body of your email message: unsubscribe uietips Gary PERLMAN Here's the general information for the list you've subscribed to, in case you don't already have it: [Last updated on: Sat Feb 24 20:26:13 EST 1996] Welcome to UIETips. This discussion list is about designing user interfaces -- what works and what doesn't. A lot of the discussion on this list will be data oriented. We will focus on results from usability testing and other means of collecting data. We will also discuss techniques to collect data from your application's users. Usability testing, contextual inquiry, focus groups, and user myth realization are amongst the many topics. This list is an extension of Eye For Design, a newsletter published by User Interface Engineering. For a complimentary issue of Eye For Design, send your postal address to jspool@uie.com. Occasionally we will also post User Interface Engineering News. This regular posting is intended for our clients and friends to keep them posted on our lastest activities and things we've found of interest. It also allows us to let you know of upcoming events and the newest resources. To subscribe to UIETips, just send a message to UIETips-Request@uie.com. The only word in the body of the message should be SUBSCRIBE. If you have any questions, please feel free to contact Jared Spool at jspool@uie.com. From Majordomo-Owner@world.std.com Tue Mar 4 16:28:20 1997 Received: by europe.std.com (8.7.5/BZS-8-1.0) id QAA27287; Tue, 4 Mar 1997 16:30:02 -0500 (EST) Date: Tue, 4 Mar 1997 16:30:02 -0500 (EST) Message-Id: <199703042130.QAA27287@europe.std.com> X-Authentication-Warning: europe.std.com: daemon set sender to Majordomo-Owner@world.std.com using -f To: perlman@turing.acm.org From: Majordomo@world.std.com Subject: Majordomo results Reply-To: Majordomo@world.std.com Status: O -- >>>> subscribe Succeeded. From utest@hubcap.clemson.edu Tue Mar 4 16:56:06 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id QAA29714; Tue, 4 Mar 1997 16:55:54 -0500 (EST) Date: Tue, 4 Mar 1997 16:55:54 -0500 (EST) Message-Id: <199703042154.AA28049@world.std.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: jspool@uie.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: "Jared M. Spool" To: Multiple recipients of list Subject: Reprint: Integrating Other Applications X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO People have recently shown interest in developing new applications that leverage the functionality built-in to existing applications. The following is a reprint of an article that was printed in the November/December 1996 issue of Eye For Design. I thought you might find this of interest. (There is information on how to get a sample issue of Eye For Design at the end of this message.) - o - o - o - Integrating Other Applications by Will Schroeder Problem: Your application or web site needs some functionality. There's another product or site (either third-party or from your company) which already does what you need. Should you just integrate it with your application, or spend the effort to "reinvent the wheel?" Integration is a tempting solution, but we've learned that it can cause problems of its own. Recently, we tested three applications (a chemical compound database, a financial analysis package, and a process modeller) that extended their functionality by launching Microsoft Excel. We observed that users had some interesting problems users had with the integration of the two products. __________ A Drink from a Fire Hydrant Complementing your application with another feature-rich application is like getting a drink of water from a fire hydrant. Beware of creating learning hurdles when you integrate an application. In our tests, the users were familiar with Excel, and we still observed some Excel-related usability issues. If your users aren't proficient in the other application, or you just need a few of its functions, attempting to integrate it might place an undue burden on users. __________ Two Applications or One? As a designer, you must decide how tightly to integrate with the other application. Do you want the user to perceive the boundaries between the applications or to treat them as one? Most of the usability problems we saw pertained to the users' mental models of how the two products worked together. __________ Breaking the Mental Model Over time, users develop a mental model of how a product or site works. If any aspect of the integration changes the way the familiar product works, this can disrupt users' mental model. One product added a formula to the Excel Function Wizard to calculate and display a mathematical curve (in Excel, functions result in a number in a spreadsheet cell). After users completed this function, we asked them what they expected and they all said, "I'll get a number in a cell." When they got a 3D graph instead, they were surprised - the integration had broken their mental model. __________ Crossing the Boundaries In switching from one application or web site to another, the user crosses a boundary. Even if users are familiar with the place they're going, they can become temporarily disoriented if they don't realize where they are or how they got there. When we tested applications that put users into Excel, some users took a while to realize that they were in Excel, and a few even thought they had gotten into Excel by mistake! We've seen similar problems when applications use object linking and embedding (OLE) technology to provide in-place editing, or when web pages link to other sites. Even though parts of the screen change, users often don't realize that they are suddenly in a different context. __________ Methods of Switching One development team wanted the two integrated applications to look like one. They added commands to Excel's Window menu so that users could switch among the open windows in the two applications. This didn't work; users didn't look there. The team revised their design by adding a palette of icons for switching, and this worked better. We also saw that users who knew Excel would notice the addition of an icon to Excel's toolbar, but only if it was flagrant (in this case, large and red!). __________ Incompatible Data Types If functions in the other application don't work on all your types of data, you're likely to see problems. We saw many examples of users attempting to apply familiar functionality in ways that didn't make sense with the integrated product. One developer had added a feature to display chemical diagrams in Excel spreadsheet cells. In the usability test, he grinned ruefully when users tried to sort on a column full of pictures. Another example comes from Goldmine (a contact manager), which uses the Crystal Report Writer to provide its reports. The filtering syntax in the two applications are different - a filter written within Goldmine won't work in the report writer. Sometimes problems like this can be avoided by integrating an application behind the scenes. For example, a VBX called Formula One acts like an invisible spreadsheet, so developers can add spreadsheet capabilities to their application without making users learn another interface. We did see a pattern in users' expectations in a couple areas. Uniformly, users expected automatic data updating (where changes in the Excel data are reflected in the calling application, and vice versa). However, when we asked users whether they could load an Excel file directly into the calling application, users weren't sure whether the file formats were directly compatible. __________ Duplication of Functionality In some cases, it may make sense to duplicate some functionality from the other application if it avoids confusion. We tested a product which relied on Excel for printing, and therefore omitted a Print command from the product's File menu. Several users could not complete a printout task. Even though they knew that Excel was available, using it to print did not occur to them. We have also seen instances where users looked in Help in the "wrong" application, searching for functionality that was in the other application. But not all users searched in Help, so some simply concluded that the functionality didn't exist. - o - o - o - Eye For Design is published six times a year with articles on a variety of product design and usability issues. If you would like a complimentary issue mailed to you, just send your postal address to efd@uie.com. (Sorry, we do not have an email version available, yet.) Or, you can check out our website at http://www.uie.com. Hope you found this to be of interest. Jared p.s. We'll ship your complimentary issue anywhere in the world, as long as you tell us what country your from. ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (508) 975-4343 North Andover, MA 01845 fax: (508) 975-5353 USA http://www.uie.com ========================================================== From owner-cstg-l@VTVM1.CC.VT.EDU Tue Mar 4 17:10:31 1997 Received: from listserv.vt.edu (listserv.vt.edu [128.173.4.9]) by listserv.vt.edu (8.8.5/8.8.5) with ESMTP id RAA03876; Tue, 4 Mar 1997 17:03:22 -0500 Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (LISTSERV release 1.8c) with NJE id 5205 for CSTG-L@VTVM1.CC.VT.EDU; Tue, 4 Mar 1997 17:02:52 -0500 Received: from VTVM1 (NJE origin SMTP@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.2a/1.8a) with BSMTP id 7011; Tue, 4 Mar 1997 16:52:50 -0500 Received: from europe.std.com by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with TCP; Tue, 04 Mar 97 16:52:49 EST Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id QAA00813; Tue, 4 Mar 1997 16:53:06 -0500 (EST) Received: from [10.0.2.15] (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA25941; Tue, 4 Mar 1997 16:52:57 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <199703042152.AA25941@world.std.com> Date: Tue, 4 Mar 1997 16:51:43 -0500 Reply-To: jspool@uie.com Sender: CSTG-L DISCUSSION LIST Comments: Authenticated sender is From: "Jared M. Spool" Organization: User Interface Engineering Subject: Reprint: Integrating Other Applications To: CSTG-L@VTVM1.CC.VT.EDU Status: O People have recently shown interest in developing new applications that leverage the functionality built-in to existing applications. The following is a reprint of an article that was printed in the November/December 1996 issue of Eye For Design. I thought you might find this of interest. (There is information on how to get a sample issue of Eye For Design at the end of this message.) - o - o - o - Integrating Other Applications by Will Schroeder Problem: Your application or web site needs some functionality. There's another product or site (either third-party or from your company) which already does what you need. Should you just integrate it with your application, or spend the effort to "reinvent the wheel?" Integration is a tempting solution, but we've learned that it can cause problems of its own. Recently, we tested three applications (a chemical compound database, a financial analysis package, and a process modeller) that extended their functionality by launching Microsoft Excel. We observed that users had some interesting problems users had with the integration of the two products. __________ A Drink from a Fire Hydrant Complementing your application with another feature-rich application is like getting a drink of water from a fire hydrant. Beware of creating learning hurdles when you integrate an application. In our tests, the users were familiar with Excel, and we still observed some Excel-related usability issues. If your users aren't proficient in the other application, or you just need a few of its functions, attempting to integrate it might place an undue burden on users. __________ Two Applications or One? As a designer, you must decide how tightly to integrate with the other application. Do you want the user to perceive the boundaries between the applications or to treat them as one? Most of the usability problems we saw pertained to the users' mental models of how the two products worked together. __________ Breaking the Mental Model Over time, users develop a mental model of how a product or site works. If any aspect of the integration changes the way the familiar product works, this can disrupt users' mental model. One product added a formula to the Excel Function Wizard to calculate and display a mathematical curve (in Excel, functions result in a number in a spreadsheet cell). After users completed this function, we asked them what they expected and they all said, "I'll get a number in a cell." When they got a 3D graph instead, they were surprised - the integration had broken their mental model. __________ Crossing the Boundaries In switching from one application or web site to another, the user crosses a boundary. Even if users are familiar with the place they're going, they can become temporarily disoriented if they don't realize where they are or how they got there. When we tested applications that put users into Excel, some users took a while to realize that they were in Excel, and a few even thought they had gotten into Excel by mistake! We've seen similar problems when applications use object linking and embedding (OLE) technology to provide in-place editing, or when web pages link to other sites. Even though parts of the screen change, users often don't realize that they are suddenly in a different context. __________ Methods of Switching One development team wanted the two integrated applications to look like one. They added commands to Excel's Window menu so that users could switch among the open windows in the two applications. This didn't work; users didn't look there. The team revised their design by adding a palette of icons for switching, and this worked better. We also saw that users who knew Excel would notice the addition of an icon to Excel's toolbar, but only if it was flagrant (in this case, large and red!). __________ Incompatible Data Types If functions in the other application don't work on all your types of data, you're likely to see problems. We saw many examples of users attempting to apply familiar functionality in ways that didn't make sense with the integrated product. One developer had added a feature to display chemical diagrams in Excel spreadsheet cells. In the usability test, he grinned ruefully when users tried to sort on a column full of pictures. Another example comes from Goldmine (a contact manager), which uses the Crystal Report Writer to provide its reports. The filtering syntax in the two applications are different - a filter written within Goldmine won't work in the report writer. Sometimes problems like this can be avoided by integrating an application behind the scenes. For example, a VBX called Formula One acts like an invisible spreadsheet, so developers can add spreadsheet capabilities to their application without making users learn another interface. We did see a pattern in users' expectations in a couple areas. Uniformly, users expected automatic data updating (where changes in the Excel data are reflected in the calling application, and vice versa). However, when we asked users whether they could load an Excel file directly into the calling application, users weren't sure whether the file formats were directly compatible. __________ Duplication of Functionality In some cases, it may make sense to duplicate some functionality from the other application if it avoids confusion. We tested a product which relied on Excel for printing, and therefore omitted a Print command from the product's File menu. Several users could not complete a printout task. Even though they knew that Excel was available, using it to print did not occur to them. We have also seen instances where users looked in Help in the "wrong" application, searching for functionality that was in the other application. But not all users searched in Help, so some simply concluded that the functionality didn't exist. - o - o - o - Eye For Design is published six times a year with articles on a variety of product design and usability issues. If you would like a complimentary issue mailed to you, just send your postal address to efd@uie.com. (Sorry, we do not have an email version available, yet.) Or, you can check out our website at http://www.uie.com. Hope you found this to be of interest. Jared p.s. We'll ship your complimentary issue anywhere in the world, as long as you tell us what country your from. ========================================================== Jared M. Spool User Interface Engineering mailto:jspool@uie.com 800 Turnpike Street, Suite 101 (508) 975-4343 North Andover, MA 01845 fax: (508) 975-5353 USA http://www.uie.com ========================================================== From utest@hubcap.clemson.edu Tue Jul 29 09:40:18 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id JAA10762; Tue, 29 Jul 1997 09:37:39 -0400 (EDT) Date: Tue, 29 Jul 1997 09:37:39 -0400 (EDT) Message-Id: <33DDF1DC.9756A870@tripos.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: jgrant@tripos.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Joe Grant To: Multiple recipients of list Subject: Re: About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO I greatly enjoyed reading "About Face," and I found much of what he had to say as inspiring, and some of what he had to say as agitating. He speaks from his own design vision, and his vision of how our industry should radically change, and how we should let designers be the primary movers of the user interface. OK, here we go, from Chapter Two of "About Face", I quote: "There is a conflict of interest in the world of software development because the people who build it are also the people who design. If carpenters designed houses, they would certainly be easier or more interesting to build, but not necessarily better to live in. The architect, besides being trained in the at of what works and what doesn't, is an advocate for the client, for the user. An equivalent role in the world of software has not fully developed yet, although several groups are eyeing it jealously." Mr. Cooper and his book are not focused on studies or on usability testing to prove what works and what doesn't. This book attempts to put some language on UI design and establish some priniciples. Some "axioms" from the book, I quote: A dialog box is another room. Have a good reason to go there. All idioms must be learned. Good idioms only need to be learned once. Ask forgiveness, not permission. Consistency is not necessarily a virtue. Disks are a hack, not a design feature. Don't stop the proceedings with idiocy. (Good design is..) (h)ot, simple, and deep. Make everything reversible. Users don't make mistakes. Never bend your interface to make a metaphor. and............ User testing can never substitute for user interface design. end quote. As I said, he has different perspective than the one which relies on empircal testing to establish anything as valid. I value Mr. Cooper's perspective as an alternative and a complement to the one provided by usability testing. I found much to agree with and much to disagree with the book, and most certainly loved reading it. Sincerely, Joe Grant St. Louis, MO adam wrote: > I've been reading "About Face" and I have to say that I'm very > surprised by > it. I started making notes in the margin about the things that I found > > logically questionable or factually incorrect and now my book is > covered > with scribbles. I noted that our own esteemed Larry Marine gave it the > > thumbs up, which frankly surprised me. > > I'd like to know if everyone feels this mailing list is the correct > forum > to debate some of this book's comments, or if it falls outside the > mandate > of UTEST. I'm eager to see if other people find Cooper's ideas to be > as > consistently suspect as I have. > > (If I get some affirmative responses, but not enough to be comfortable > > discussing it on UTEST, then I'll just keep it a private email > discussion.) > > Cheers > adam > > O O O o o o + + + =3D=3D=3D-o--o-=3D=3D=3D + + + o o o O O O > datapanik - toronto, canada - info@datapanik.com > multimedia producer and developer > a responsible approach to building way cool software > http://members.aol.com/datapanik From utest@hubcap.clemson.edu Tue Jul 29 09:43:20 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id JAA32469; Tue, 29 Jul 1997 09:39:53 -0400 (EDT) Date: Tue, 29 Jul 1997 09:39:53 -0400 (EDT) Message-Id: Errors-To: tharon@hubcap.clemson.edu Reply-To: DICK_MILLER@HP-Vancouver-om10.om.hp.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: DICK_MILLER@HP-Vancouver-om10.om.hp.com To: Multiple recipients of list Subject: Re: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Item Subject: taking Cooper to task Adam: I think this is _exactly_ what this forum is for: discussion of issues related to usability. I hope that those who are moved to create ten-page discourses would keep them private, but I like the idea of airing contrasting points of view (I've just begun reading the book myself, and am curious about your issues). I vote yes. --Dick Miller ______________________________ Reply Separator _________________________________ Subject: taking Cooper to task Author: Non-HP-adam (adam@datapanik.com) at HP-Vancouver,shargw10 Date: 7/28/97 11:02 PM I've been reading "About Face" and I have to say that I'm very surprised by it. I started making notes in the margin about the things that I found logically questionable or factually incorrect and now my book is covered with scribbles. I noted that our own esteemed Larry Marine gave it the thumbs up, which frankly surprised me. I'd like to know if everyone feels this mailing list is the correct forum to debate some of this book's comments, or if it falls outside the mandate of UTEST. I'm eager to see if other people find Cooper's ideas to be as consistently suspect as I have. (If I get some affirmative responses, but not enough to be comfortable discussing it on UTEST, then I'll just keep it a private email discussion.) Cheers adam O O O o o o + + + =3D=3D=3D-o--o-=3D=3D=3D + + + o o o O O O datapanik - toronto, canada - info@datapanik.com multimedia producer and developer a responsible approach to building way cool software http://members.aol.com/datapanik From utest@hubcap.clemson.edu Tue Jul 29 10:52:18 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id KAA04030; Tue, 29 Jul 1997 10:49:52 -0400 (EDT) Date: Tue, 29 Jul 1997 10:49:52 -0400 (EDT) Message-Id: <3.0.32.19970729075524.007e24e0@sd.znet.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: LMarine@IntuitiveDesign.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Larry Marine To: Multiple recipients of list Subject: Re: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O At 02:02 AM 7/29/97 -0400, adam wrote: >with scribbles. I noted that our own esteemed Larry Marine gave it the >thumbs up, which frankly surprised me. Although I share many of the same agreements and disagreements as others, such as Joe Grant, I still hold fast to my comments about Alan's book. I was privy to a portion of the manuscript and asked Alan who his intended audience was and what his goals were for that audience. He states very clearly in the forward of his book that he wrote it specifically to provide programmers with tools to help them get a handle on the monumental task of designing interfaces. He also explicitly states that the book is not intended for user interface designers (read usability specialists). Given that, I feel that his book helps achieve a goal even we share, to educate the development community on the value of attending to and designing for the user. In this business we must remember that you cannot teach a pig to sing. It wastes your time and annoys the pig. Alan has approached the development community from their perspective, instead of forcing usability down their throats (which is pretty much how it is perceived if a manager brings us into their team). I agree that more than a few of the quotes are inconsistent with our perspective, but he didn't write it for us. Piaget's book on cognitive development in children is ripped apart by modern psychology folks, but they still regard it as a seminal work that fostered ever more research and understanding. Alan is not Piaget, but his book achieves similar success in the development community. More and more I hear developers talk about the book and discuss usability issues. This opens a rich dialog between us and the developers. In my opinion, although I don't always agree with the contents, the book still achieves success. Now, about that esteemed part... Larry Marine Intuitive Design ___________________________ Thinking [Outside of the Box] LMarine@IntuitiveDesign.com (760) 944-4575 From utest@hubcap.clemson.edu Tue Jul 29 11:54:59 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id LAA10296; Tue, 29 Jul 1997 11:51:55 -0400 (EDT) Date: Tue, 29 Jul 1997 11:51:55 -0400 (EDT) Message-Id: Errors-To: tharon@hubcap.clemson.edu Reply-To: DICK_MILLER@HP-Vancouver-om10.om.hp.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: DICK_MILLER@HP-Vancouver-om10.om.hp.com To: Multiple recipients of list Subject: Re: About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Joe: Thanks for kicking off the detailed discussion with a thoughtful beginning. I, too, value Cooper's book as one that causes me to think about what I believe. I'd take exception with (at least) a couple of Cooper's points you cited: 1. Users _do_ indeed make mistakes from time to time. More often, they do what they think is right, but which turns out not to be. I know I myself will once in a while press the wrong key or choose the wrong menu item, not because of a design defect, but simply because I wasn't paying attention to what I was doing. Cooper's point, I think, is to make such a strong counter-intuitive statement that one is forced to think about the idea behind it. In that sense, it works. 2. Maybe usability testing cannot substitute for good design, but I maintain that, just as importantly, design cannot substitute for thorough usability testing. I think both are needed. Well, there's my $.02 worth to kick it off... ---Dick Miller ______________________________ Reply Separator _________________________________ Subject: Re: About Face Author: Non-HP-jgrant (jgrant@tripos.com) at HP-Vancouver,shargw10 Date: 7/29/97 6:38 AM I greatly enjoyed reading "About Face," and I found much of what he had to say as inspiring, and some of what he had to say as agitating. He speaks from his own design vision, and his vision of how our industry should radically change, and how we should let designers be the primary movers of the user interface. OK, here we go, from Chapter Two of "About Face", I quote: "There is a conflict of interest in the world of software development because the people who build it are also the people who design. If carpenters designed houses, they would certainly be easier or more interesting to build, but not necessarily better to live in. The architect, besides being trained in the at of what works and what doesn't, is an advocate for the client, for the user. An equivalent role in the world of software has not fully developed yet, although several groups are eyeing it jealously." Mr. Cooper and his book are not focused on studies or on usability testing to prove what works and what doesn't. This book attempts to put some language on UI design and establish some priniciples. Some "axioms" from the book, I quote: A dialog box is another room. Have a good reason to go there. All idioms must be learned. Good idioms only need to be learned once. Ask forgiveness, not permission. Consistency is not necessarily a virtue. Disks are a hack, not a design feature. Don't stop the proceedings with idiocy. (Good design is..) (h)ot, simple, and deep. Make everything reversible. Users don't make mistakes. Never bend your interface to make a metaphor. and............ User testing can never substitute for user interface design. end quote. As I said, he has different perspective than the one which relies on empircal testing to establish anything as valid. I value Mr. Cooper's perspective as an alternative and a complement to the one provided by usability testing. I found much to agree with and much to disagree with the book, and most certainly loved reading it. Sincerely, Joe Grant St. Louis, MO adam wrote: > I've been reading "About Face" and I have to say that I'm very > surprised by > it. I started making notes in the margin about the things that I found > > logically questionable or factually incorrect and now my book is > covered > with scribbles. I noted that our own esteemed Larry Marine gave it the > > thumbs up, which frankly surprised me. > > I'd like to know if everyone feels this mailing list is the correct > forum > to debate some of this book's comments, or if it falls outside the > mandate > of UTEST. I'm eager to see if other people find Cooper's ideas to be > as > consistently suspect as I have. > > (If I get some affirmative responses, but not enough to be comfortable > > discussing it on UTEST, then I'll just keep it a private email > discussion.) > > Cheers > adam > > O O O o o o + + + =3D=3D=3D-o--o-=3D=3D=3D + + + o o o O O O > datapanik - toronto, canada - info@datapanik.com > multimedia producer and developer > a responsible approach to building way cool software > http://members.aol.com/datapanik From utest@hubcap.clemson.edu Tue Jul 29 13:22:51 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id NAA11972; Tue, 29 Jul 1997 13:21:53 -0400 (EDT) Date: Tue, 29 Jul 1997 13:21:53 -0400 (EDT) Message-Id: <9707291720.AA25252@maildig1.us.oracle.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: CZETIE@us.oracle.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: "Carl Zetie" To: Multiple recipients of list Subject: Re: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O --=_ORCL_44434014_0_11919707291121230 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" I largely agree with Adam. I found reading this book to be akin to panning for gold. You have to sift a lot of gravel before you find the nuggets ;-) The generous interpretation is that, in places, Alan Cooper was being deliberately provocative to get people thinking. Unfortunately, given his target audience, for many of his readers this may be the only UI book they have read, and they may not read as critically as more expereienced people might. regards, ------------------------------------------------------------------ The home of Developer/2000 is http://www-dev2k.us.oracle.com Carl Zetie czetie@us.oracle.com Manager tel: (415) 506 3497 Developer/2000 Product Management fax: (415) 506 7419 Product Direction Oracle Corporation, 500 Oracle Parkway, Mailstop 2op9, Redwood Shores, CA 94065 --=_ORCL_44434014_0_11919707291121230 Content-Type:message/rfc822 Date: 28 Jul 97 23:02:14 From:"adam " To:Multiple,recipients,of,list, Subject:taking Cooper to task Reply-to:adam@datapanik.com Return-Path: Errors-To:tharon@hubcap.clemson.edu Originator:utest@hubcap.clemson.edu Sender:utest@hubcap.clemson.edu Precedence: bulk X-Listprocessor-Version:6.0c -- ListProcessor by Anastasios Kotsikonas MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" I've been reading "About Face" and I have to say that I'm very surprised by it. I started making notes in the margin about the things that I found logically questionable or factually incorrect and now my book is covered with scribbles. I noted that our own esteemed Larry Marine gave it the thumbs up, which frankly surprised me. I'd like to know if everyone feels this mailing list is the correct forum to debate some of this book's comments, or if it falls outside the mandate of UTEST. I'm eager to see if other people find Cooper's ideas to be as consistently suspect as I have. (If I get some affirmative responses, but not enough to be comfortable discussing it on UTEST, then I'll just keep it a private email discussion.) Cheers adam O O O o o o + + + =3D=3D=3D-o--o-=3D=3D=3D + + + o o o O O O datapanik - toronto, canada - info@datapanik.com multimedia producer and developer a responsible approach to building way cool software http://members.aol.com/datapanik --=_ORCL_44434014_0_11919707291121230-- From utest@hubcap.clemson.edu Tue Jul 29 13:38:30 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id NAA17531; Tue, 29 Jul 1997 13:38:00 -0400 (EDT) Date: Tue, 29 Jul 1997 13:38:00 -0400 (EDT) Message-Id: <199707291736.NAA26629@hubcap.clemson.edu> Errors-To: tharon@hubcap.clemson.edu Reply-To: tharon@hubcap.clemson.edu Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Tharon Howard To: Multiple recipients of list Subject: RE: Taking Cooper to Task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O For those who've not put hands on the Cooper book, here's info about it. About Face : The Essentials of User Interface Design by Alan Cooper Paperback, 400 pages Published by IDG Books Worldwide Publication date: November 1995 ISBN: 1568843224 List: $29.99 For more info, see http://www.amazon.com/ ----------------------------------------------------------------------- Dr. Tharon Howard e-mail: tharon@hubcap.clemson.edu Clemson University Voice: (864)656-3488 | FAX: (864)656-1345 MA in Prof. Comm. http://hubcap.clemson.edu/~tharon/ From utest@hubcap.clemson.edu Tue Jul 29 13:55:44 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id NAA12869; Tue, 29 Jul 1997 13:55:34 -0400 (EDT) Date: Tue, 29 Jul 1997 13:55:34 -0400 (EDT) Message-Id: <0001AC14.@alltel.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: Jeff.Schwandt@alltel.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Jeff.Schwandt@alltel.com To: Multiple recipients of list Subject: Re: About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O I read "About Face" several months ago. I didn't take notes on the book but enough of it stuck with me to influence my UI designs. I found myself agreeing with most of what Mr. Cooper had to say. In fact, most of it really makes sense, especially if you really start thinking about things from the user's perspective instead of from the programmer's perspective. Sure, some of the things he proposes will be harder to code, but that's no excuse to not make the effort to make the user's life easier and their work more productive. Does anyone else have specific points that they strongly agree or disagree with, and why? From utest@hubcap.clemson.edu Tue Jul 29 13:56:49 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id NAA13918; Tue, 29 Jul 1997 13:57:09 -0400 (EDT) Date: Tue, 29 Jul 1997 13:57:09 -0400 (EDT) Message-Id: <199707291352_MC2-1BDF-615F@compuserve.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: Theo_Mandel@compuserve.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Theo Mandel To: Multiple recipients of list Subject: Re: About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Dick Miller wrote: 1. Users do make mistakes. That doesn't necessarily correlate to design flaws. 2. Both UI design and usability testing are needed. I agree with Dick's comments and talk about this in my new book. Larry Marine's comments that Cooper's book is written for programmers rather than interface designers doesn't change the content of the message. You don't just tell developers that good interface design is important and just tell usability professionals that usability testing is imperative. They are both part of the same team with the same goals: usable interfaces. Theo Mandel **************************** Theo Mandel, Ph.D. Interface Design and Development 8001 Two Coves Drive Austin, Texas 78730-3125 (512) 345-2259 Phone/Fax **************************** E-mail: Theo_Mandel@compuserve.com Web Site: http://www.concentric.net/~tmandel/ **************************** For information on my new book, "The Elements of User Interface Design" E-mail me or visit my Web site. Thanks! **************************** "You can use an eraser on the drafting table or a sledge hammer on the construction site" -- Frank Lloyd Wright From utest@hubcap.clemson.edu Tue Jul 29 13:59:15 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id NAA06038; Tue, 29 Jul 1997 13:58:02 -0400 (EDT) Date: Tue, 29 Jul 1997 13:58:02 -0400 (EDT) Message-Id: Errors-To: tharon@hubcap.clemson.edu Reply-To: adam@datapanik.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: adam To: Multiple recipients of list Subject: About Face - before we start tearing into it... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O I just want to clarify a couple of things before we start tearing into About Face. - There are indeed many good and provocative ideas in About Face, and I am pleased that it's around. I will recommend it (but only in the context of some other, less... erm... "self-assured" books). I have been reading it and using it to revamp an application interface that I've been designing, and it has proved quite useful in a number of respects. My concerns are more for some of the specific details he sites, a few of the more extreme opinions he clings to, and facts that I believe to be completely untrue. - I have nothing against the man whatsoever. How can I? I've never met him. My concerns are purely centred around the advice he is giving out. - Perhaps most significantly, I've not finished reading it yet. (It's slow going when you are filling the margins with notes). So I'd like to suggest that, where possible, people note specific passages and page numbers so that we can all look at his comments in context before ranting. And now, let the public stoning begin!! Cheers adam O O O o o o + + + =3D=3D=3D-o--o-=3D=3D=3D + + + o o o O O O datapanik - toronto, canada - info@datapanik.com multimedia producer and developer a responsible approach to building way cool software http://members.aol.com/datapanik From utest@hubcap.clemson.edu Tue Jul 29 17:27:05 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id RAA08753; Tue, 29 Jul 1997 17:27:45 -0400 (EDT) Date: Tue, 29 Jul 1997 17:27:45 -0400 (EDT) Message-Id: <9706298702.AA870222276@ccmail.viewlogic.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: cpeterson@ccmail.viewlogic.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: cpeterson@ccmail.viewlogic.com To: Multiple recipients of list Subject: Re: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O I agree with Larry Marine's comment about keeping the intended audience in mind. I have used the book and quotes from it sucessfully to sensitize developers to human factors issues. After all, I don't think Cooper's intention was to preach to the choir (i.e., us)--his blanket statements _do_ make you stop and think, and if you've never thought about usability issues before, it makes an impact. Especially with statements like "Users don't make mistakes," who cares if it's not technically correct? Developers are likely to make similar blanket statements like "the user should know how to do that." If a developer is going to deal in sound bites regarding usability, I'd much rather have it be sound bites that will ultimately help the user! Carol Peterson Human Factors Engineer Viewlogic Systems, Inc. cpeterson@viewlogic.com From utest@hubcap.clemson.edu Tue Jul 29 19:13:20 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id SAA22069; Tue, 29 Jul 1997 18:57:28 -0400 (EDT) Date: Tue, 29 Jul 1997 18:57:28 -0400 (EDT) Message-Id: <3.0.32.19970729154802.008f63c0@sd.znet.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: LMarine@IntuitiveDesign.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Larry Marine To: Multiple recipients of list Subject: Re: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O At 01:23 PM 7/29/97 -0400, Carl Zetie wrote: >provocative to get people thinking. Unfortunately, given his target audience, for many >of his readers this may be the only UI book they have read, and they may not read as >critically as more expereienced people might. My experience corroborates this contention. However, it invites the opportunity to suggest other books and discuss greater issues besides the technical side of user interface design. Unfortunately, there are still a large number of developers who have read the book and have never met a usability professional. I don't think Alan's book will be detrimental to the evolution of user interface design, but there is still much work to be done. Larry Marine Intuitive Design ___________________________ Thinking [Outside of the Box] LMarine@IntuitiveDesign.com (760) 944-4575 From utest@hubcap.clemson.edu Tue Jul 29 20:08:46 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id UAA24236; Tue, 29 Jul 1997 20:09:15 -0400 (EDT) Date: Tue, 29 Jul 1997 20:09:15 -0400 (EDT) Message-Id: <199707300008.UAA17926@hubcap.clemson.edu> Errors-To: tharon@hubcap.clemson.edu Reply-To: gottlieb@alpha.arcride.edu.ar Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: "Bernardo Gottlieb" To: Multiple recipients of list Subject: RE: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Este es un mensaje con mzltiples partes en formato MIME. ------=_NextPart_000_01BC9C63.04D9A8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgYWxsOg0KSSB0aGluayAgQWJvdXQgRmFjZSBpcyBhIHZlcnkgZ29vZCBib29rIGZvciByZWFk aW5nIGFib3V0IFVzZXIgSW50ZXJmYWNlIERlc2lnbiwgaXQgaXMgdmVyeSBjbGVhciBhbmQgZWFz eSB0byBsZWFybiwgSSBhbHNvIHVzZSBpdCBmb3IgdGVhY2hpbmcgc28gSbRkIGxpa2UgdG8gc2Vl IG1vcmUgYWJvdXQgdGhlIHNwZWNpZmljIHBvaW50cyB0aGF0IGFyZSBiYWQgb3Igd3JvbmcgYW5k IHdoeT8uIFJlY2VudGx5IHRoaXMgYm9vayBnYXZlIG1lIGFuIHVuc3VzcGVjdGVkIHV0aWxpdHkg KGl0IHdhcyB1c2VkIHRvIGNvbnZpbmNlIG15IGNoaWVmcyB0byBkbyBhIFdvcmtzaG9wIGFib3V0 IFVzZXJzIENlbnRlcmVkIERlc2lnbiBhdCBhIE5hdGlvbmFsIFVuaXZlcnNpdHkgYXQgbXkgY291 bnRyeSkuIFRoZSBXb3Jrc2hvcCB3YXMgd2VsbCBkb25lIGJ5IExhcnJ5IE1hcmluZSBmcm9tIElu dHVpdGl2ZSBEZXNpZ24uIFRoZSBXb3Jrc2hvcCB3YXMgdmVyeSBmaW5lIGFuZCB1c2VmdWwgZm9y IHVzIGFuZCBJIGdyZWF0bHkgcmVjb21tZW5kIHRoaXMuIEkga25ldyBoaW0gb24gdGhpcyBsaXN0 LiBTbyBtYW55IHRoYW5rcyB0byBhbGwgVVRlc3RlcnMgYW5kIHNwZWNpYWxseSB0byBvdXIgZnJp ZW5kIExhcnJ5Lg0KDQpCZXN0IHJlZ2FyZHMgDQpCZXJuYXJkbyBHb3R0bGllYiBmcm9tIEFyZ2Vu dGluYQ0KICANCiAtLS0NCg== ------=_NextPart_000_01BC9C63.04D9A8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MIDMuMi8vRU4iPg0KPEhU TUw+DQo8SEVBRD4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0x IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9JyJUcmlkZW50IDQuNzEu MDU0NC4wIicgbmFtZT1HRU5FUkFUT1I+DQoNCjwvSEVBRD4NCjxCT0RZPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPg0KPFA+SGkgYWxsOjwvUD4NCg0KPFA+SSB0aGluayAgQWJvdXQgRmFjZSBpcyBh IHZlcnkgZ29vZCBib29rIGZvciByZWFkaW5nIGFib3V0IFVzZXIgSW50ZXJmYWNlIA0KRGVzaWdu LCBpdCBpcyB2ZXJ5IGNsZWFyIGFuZCBlYXN5IHRvIGxlYXJuLCBJIGFsc28gdXNlIGl0IGZvciB0 ZWFjaGluZyBzbyANCkkmYWN1dGU7ZCBsaWtlIHRvIHNlZSBtb3JlIGFib3V0IHRoZSBzcGVjaWZp YyBwb2ludHMgdGhhdCBhcmUgYmFkIG9yIHdyb25nIGFuZCANCjxTVFJPTkc+d2h5Py4gPC9TVFJP Tkc+PFNUUk9ORz48L1NUUk9ORz5SZWNlbnRseSB0aGlzIGJvb2sgZ2F2ZSBtZSBhbiANCnVuc3Vz cGVjdGVkIHV0aWxpdHkgKGl0IHdhcyB1c2VkIHRvIGNvbnZpbmNlIG15IGNoaWVmcyB0byBkbyBh IFdvcmtzaG9wIGFib3V0IA0KVXNlcnMgQ2VudGVyZWQgRGVzaWduIGF0IGEgTmF0aW9uYWwgVW5p dmVyc2l0eSBhdCBteSBjb3VudHJ5KS4gVGhlIFdvcmtzaG9wIHdhcyANCndlbGwgZG9uZSBieSBM YXJyeSBNYXJpbmUgZnJvbSBJbnR1aXRpdmUgRGVzaWduLiBUaGUgV29ya3Nob3Agd2FzIHZlcnkg ZmluZSBhbmQgDQp1c2VmdWwgZm9yIHVzIGFuZCBJIGdyZWF0bHkgcmVjb21tZW5kIHRoaXMuIEkg a25ldyBoaW0gb24gdGhpcyBsaXN0LiBTbyBtYW55IA0KdGhhbmtzIHRvIGFsbCBVVGVzdGVycyBh bmQgc3BlY2lhbGx5IHRvIG91ciBmcmllbmQgTGFycnkuPEJSPg0KDQoNCjxQPkJlc3QgcmVnYXJk cyANCg0KPFA+QmVybmFyZG8gR290dGxpZWIgZnJvbSBBcmdlbnRpbmE8QlI+DQogIDwvUD4NCiAt LS08L0ZPTlQ+DQo8L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_01BC9C63.04D9A8C0-- From utest@hubcap.clemson.edu Tue Jul 29 20:30:19 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id UAA02091; Tue, 29 Jul 1997 20:31:12 -0400 (EDT) Date: Tue, 29 Jul 1997 20:31:12 -0400 (EDT) Message-Id: <199707300030.UAA30579@hubcap.clemson.edu> Errors-To: tharon@hubcap.clemson.edu Reply-To: gottlieb@alpha.arcride.edu.ar Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: "Bernardo Gottlieb" To: Multiple recipients of list Subject: RV: taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O ---- De: Bernardo Gottlieb Para: multiple recipients of list Fecha: Martes 29 de Julio de 1997 21:04 Asunto: RE: RE: taking Cooper to task >Hi all: >I think About Face is a very good book for reading about User Interface Design, it is very clear and easy to learn, I also use it for teaching so I4d like to see more about the specific points that are bad or wrong and why?. Recently this book gave me an unsuspected utility (it was used to convince my chiefs to do a Workshop about Users Centered Design at a National University at my country). The Workshop was well done by Larry Marine from Intuitive Design. The Workshop was very fine and useful for us and I greatly recommend this. I knew him on this list. So many thanks to all UTesters and specially to our friend Larry. > >Best regards >Bernardo Gottlieb from Argentina > > --- > From utest@hubcap.clemson.edu Wed Jul 30 04:09:59 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id EAA20493; Wed, 30 Jul 1997 04:09:18 -0400 (EDT) Date: Wed, 30 Jul 1997 04:09:18 -0400 (EDT) Message-Id: <33DEF619.772D@casema.net> Errors-To: tharon@hubcap.clemson.edu Reply-To: mverbeek@casema.net Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Marjolijn Verbeek To: Multiple recipients of list Subject: Re: About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O I too share many of the same agreements and disagreements as others, especially as Joe Grant. I have been reading the book since two weeks now and I find it quite enjoyable and easy to read. I am a Dutch student in Cognitive Ergonomics and what I like of the book, is that it gives me some insight in the practices of user interface design. In my educational curriculum, we mostly deal with very scientific issues. Because I will graduate in three weeks from now, I like reading about the practictioner's side of user interface design. Like others already said, About Face makes you think about why you stand for something or why you don't. This is how see it, and this is actually why I read About Face. It makes me see things in perspective. A quote which made some impression on me, is: "Most of us pay far too much attention to the technology used to implement computer solutions, which distracts us from the user. When we do focus on the user, we pay too much attention to the tasks that users engage in and not enough attention to their goals. (...) To create succesful, effective software, we must see that it achieves the user's goals. We can't ignore technology or tasks, but these elements are like salt on a meal: they make it palatable, but they don't nourish all by themselves" (page 14, first paragraph) Maybe you, as the practitioners in the usability field, would like to comment on this quote? Cheers, Marjolijn Verbeek From utest@hubcap.clemson.edu Wed Jul 30 09:42:35 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id JAA18648; Wed, 30 Jul 1997 09:42:52 -0400 (EDT) Date: Wed, 30 Jul 1997 09:42:52 -0400 (EDT) Message-Id: <3df43ea0@ccmail.marcam.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: George.Casaday@marcam.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: George.Casaday@marcam.com To: Multiple recipients of list Subject: About Face -- communication (possible new thread) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O I'm well into my second reading of About Face. I have also attended a half day seminar that Alan Cooper presented to an audience of software developers. Of course, much of Cooper's message can be debated. But there is one piece of *data* that is plainly true: Software developers are buying the book and listening to the message. About Face is a very compelling piece of communication. So here's a different viewpoint: Can we step back from the details of Cooper's design approach and see what we can learn from About Face about effective communication with software developers? I have some thoughts on the topic of what we can learn about communication with developers from About Face, and if others would like to pick it up, I propose thread parallel to the main About Face thread. Your thoughts? George Casaday From utest@hubcap.clemson.edu Wed Jul 30 14:14:40 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id OAA30222; Wed, 30 Jul 1997 14:11:59 -0400 (EDT) Date: Wed, 30 Jul 1997 14:11:59 -0400 (EDT) Message-Id: <199707301810.OAA05385@omicron.pair.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: terry@pantos.org Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: "Terry Sullivan" To: Multiple recipients of list Subject: About About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O My comments about About Face are admittedly based on an incomplete "skim/read" a while back. (Personally, I didn't find the book worth a "full" read.) And I come neither to bury Caesar, NOR to praise him. Cooper's message is right-headed. But my sense is that many of his basic choices for delivery and presentation undermine much of the value of his book. One of the most basic flaws of this work is that it relies very heavily on overstatement and generalization. "Axioms" are easy to remember, but they generally make a poor substitute for clear-headed analysis. I mean, even Newton's Laws are only valid in a certain context. There are indeed multiple errors of fact in About Face. And factual errors cost basic credibility, inevitably undermining any author's work. (I'm reluctant to start listing them, for fear of getting bogged down in details. But there are enough of them that they just aren't all that hard to spot.) Now, having said all that: I think this is still a somewhat useful book. What's useful about it is that it helps developers to begin to think in user-centric terms. It also serves as a basis for an ongoing dialogue between usability engineers and software engineers. And even if that's *all* it did, it'd be a worthwhile effort. (What I'm about to say may be equally distasteful to both software engineers and usability engineers. Let me couch my comments by saying that I speak as someone who's got a moderately credible foot planted firmly in each profession.) The current professional reality (at least in my experience) is that neither group is particularly good at understanding the perspective of the other. And neither group is particularly skilled at knowing when to "give a little." So, to the extent that About Face helps developers think outside their functional decomposition "box," and ideally leads to a richer, more substantive professional dialogue, I give it a "5." (Now if someone would only write the equivalent book for usability engineers. Despite Cooper's claims, it's not all that easy to build "DWIM" into software. And sometimes, it's just not worth the effort.) - Terry Sullivan From utest@hubcap.clemson.edu Wed Jul 30 22:06:26 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id WAA17564; Wed, 30 Jul 1997 22:06:20 -0400 (EDT) Date: Wed, 30 Jul 1997 22:06:20 -0400 (EDT) Message-Id: <"A72ZWYNGW125*/R=ABCNET/R=A1/U=DANCER COLLEEN/"@MHS> Errors-To: tharon@hubcap.clemson.edu Reply-To: DANCER.COLLEEN@a2.abc.net.au Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: "Colleen Dancer (02) 9333-1862" To: Multiple recipients of list Subject: Re: About Face X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Marjolin quotes: To create succesful, effective software, we must see that it achieves the user's goals. We can't ignore technology or tasks, but these elements are like salt on a meal: they make it palatable, but they don't nourish all by themselves" I feel the salt analogy is impractical. I would consider it more like the utensils eg pans, stove, knives etc. In other words it is very difficult to ignore technology. I suspect that most of us at some time have had to make decisions which are a compromise because of the technology, the technology often has a big impact in the real world. Sure we'd love it not to, the same as we'd love both money and politics to be irrelevant in design decisions, but life isn't usually like that. Cheers Colleen Dancer dancer.colleen@a2.abc.net.au From utest@hubcap.clemson.edu Thu Jul 31 21:35:18 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id VAA00482; Thu, 31 Jul 1997 21:34:52 -0400 (EDT) Date: Thu, 31 Jul 1997 21:34:52 -0400 (EDT) Message-Id: <3.0.1.32.19970731213332.006b3b30@209.36.70.2> Errors-To: tharon@hubcap.clemson.edu Reply-To: charlie@cognetics.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: charlie@cognetics.com (Charlie Kreitzberg) To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Alan Cooper and I had a spirited debate about the role of usability professionals, on the ASD (Association for Software Design) listserver. You can read the thread by pointing your Browser at: [Note: The thread begins with my posting "It's Time Our Voice Was Heard"] I emerged from this discussion with a belief that I was in agreement with his basic stance, which I would summarize as follows (my perception and in my words, of course he may not agree): "Creating a program requires both a technical design and an interactive design. Programmers produce the technical design, user-centered designers produce the interactive design. These are two different tasks of co-equal importance. The skills for both are related but not the same. Interactive designers create software interfaces and plan the interaction, software engineers create the technical design and program it." Cooper may not identify himself as a usability professional but he is one. His work in the design of visual programming is an important contribution to the state of interface design. Some have suggested that Cooper's stance is "opposed" to the usability professional community. I don't see this. Broadly, I see the usability community as consisting of interaction designers and measurement specialists. Both contribute to excellence in software design and both are required. Designers specialize in the design of human-computer interaction while measurement is a quality assurance process for the design phase, much as software undergoes technical QA. This is, of course, oversimplified. What we need to do as a profession is to establish ourselves as equal participants on the software development team. I think this is what Cooper is advocating when he separates design from programming. I think the ideas are ones which we should seriously consider. I would like to continue this discussion. The Lucid Computing Movement now has a listserver, courtesy of NIST (which has been a strong supporter of usability). I invite you to subscribe by sending an email as follows: To: Listproc@NIST.gov Subject: (optional) subscribe lucid your-name or, subscribe on-line by pointing your browser at: I would like to offer this list as a place to share ideas about who we are as a profession and how we propose to present ourselves and our services to the software community. Perhaps we can continue that discussion at UPA where I will set up a Lucid BOF meeting. Charlie ------------------------------------------------------------------------------ oo\ Charlie Kreitzberg (__)\ _ President \ \ .' /`. Cognetics Corporation \ \ / \ 51 Everett Drive 103B \ '" \ PO Box 386 . ( ) \ Princeton Junction, NJ 08550 '-| )__| :. \ (609) 799-5005 x235 | | | | \ '. charlie@cognetics.com c__; c__; '-..'>.__ DESIGN MAKES THE DIFFERENCE ----------------------------------------------------------------------------- From owner-cstg-l@VTVM1.CC.VT.EDU Tue Jul 8 12:59:48 1997 Received: from listserv.vt.edu (listserv.vt.edu [128.173.4.9]) by listserv.vt.edu (8.8.5/8.8.5) with ESMTP id MAA15046; Tue, 8 Jul 1997 12:53:42 -0400 Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (LISTSERV release 1.8c) with NJE id 9442 for CSTG-L@VTVM1.CC.VT.EDU; Tue, 8 Jul 1997 12:52:47 -0400 Received: from VTVM1 (NJE origin SMTP2@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.2a/1.8a) with BSMTP id 5303; Tue, 8 Jul 1997 12:42:46 -0400 Received: from wlp1.wl.wpafb.af.mil by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with TCP; Tue, 08 Jul 97 12:42:44 EDT Received: by wlp1.wl.wpafb.af.mil; (5.65v3.2/1.1.8.2/20Sep95-0402PM) id AA22534; Tue, 8 Jul 1997 12:43:28 -0400 Alternate-Recipient: allowed Auto-Forwarded: prohibited Content-Return: allowed Disclose-Recipients: prohibited Conversion: allowed Importance: normal Priority: normal Sensitivity: Normal X-Dmw-Body-Names: Supporting the null hypothesis X-Mailer: MailWorks 1.8-FT1 Message-Id: <970708124327.607@wlp1.wl.wpafb.af.mil.0> Date: Tue, 8 Jul 1997 12:43:27 -0400 Reply-To: CSTG-L DISCUSSION LIST Sender: CSTG-L DISCUSSION LIST From: Mike Snow Subject: Supporting the null hypothesis X-To: visual-l@vtvm1.cc.vt.edu To: CSTG-L@VTVM1.CC.VT.EDU Status: RO We are currently conducting a study in which we expect to show that performance of a group of pilots in one experimental condition is the same as that of a similar group flying in in another experimental condition. We intend to calculate power, set alpha relatively high (e.g., 0.20), and also intend to calculate and report confidence intervals. Given this, we've come up with the following questions: 1) Is there a commonly-accepted confidence interval (e.g., 5%) within which two samples can be said to be the same? 2) Is there a standard way of reporting confidence intervals within the human factors community? 3) Does anyone know of a reference published in either Human Factors or the annual proceedings (or even one of the APA journals) in which the authors statistically supported a conclusion that two experimental samples were NOT different? I will summarize and post any helpful responses I receive to these questions. Thanks in advance, Mike - ----------------------------------------------------------------------- Michael P. Snow, Ph.D. Vehicle-Pilot Integration Branch WL/FIGP, Bldg. 146 email: snowmp@wl.wpafb.af.mil 2210 8th St., Suite 1 phone: (937)255-6895 Wright-Patterson AFB, OH 45433-7521 FAX: (937)656-4547 From owner-cstg-l@VTVM1.CC.VT.EDU Tue Jul 8 18:17:07 1997 Received: from listserv.vt.edu (listserv.vt.edu [128.173.4.9]) by listserv.vt.edu (8.8.5/8.8.5) with ESMTP id SAA16782; Tue, 8 Jul 1997 18:15:20 -0400 Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (LISTSERV release 1.8c) with NJE id 5055 for CSTG-L@VTVM1.CC.VT.EDU; Tue, 8 Jul 1997 18:14:28 -0400 Received: from VTVM1 (NJE origin SMTP2@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.2a/1.8a) with BSMTP id 6330; Tue, 8 Jul 1997 18:04:26 -0400 Received: from FALCON.AL.WPAFB.AF.MIL by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with TCP; Tue, 08 Jul 97 18:04:25 EDT Received: from AL-Message_Server by FALCON.AL.WPAFB.AF.MIL with Novell_GroupWise; Tue, 08 Jul 1997 18:04:57 -0400 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-Id: Date: Tue, 8 Jul 1997 18:06:43 -0400 Reply-To: CSTG-L DISCUSSION LIST Sender: CSTG-L DISCUSSION LIST From: David Post Subject: Supporting the null hypothesis -Reply To: CSTG-L@VTVM1.CC.VT.EDU Status: RO Mike Snow - 7/8/97 12:43 PM writes: <<>> No. First of all, the standard procedure for comparing two sample means is a t-test or NP equivalent, depending on the assumptions one is willing to make about the sampling distribution. It is true, of course, that a two-tailed t-test at a given alpha is equivalent mathematically with computing a CI at 1-alpha for the difference between the two means and checking to see whether the range includes zero, but the t-test is more common. More importantly, though, there is no commonly accepted procedure for accepting the null. This point is discussed further, below. <<<2) Is there a standard way of reporting confidence intervals within the human factors community?>>> If you mean "is there a range that is used typically," 95% is most common in the social sciences (because the typical alpha is 5%), but one should establish a sound rationale for selecting the range in any particular case. If you mean "is there a standard format," I don't think so, but stating "the 95% confidence interval is xx-yy", for example, would seem like a pretty clear way to go. <<<3) Does anyone know of a reference published in either Human Factors or the annual proceedings (or even one of the APA journals) in which the authors statistically supported a conclusion that two experimental samples were NOT different?>>> I hope not. The odds of getting two identical samples via random sampling are virtually zero. Indeed, the odds of getting two samples with merely identical means (which is what I suspect you really mean) aren't much better. In any case, one does not need a statistical test to show that two sample means are different. They either are or they aren't. The null hypothesis does not deal with samples -- it concerns the populations from which those samples are drawn. The question addressed by the t-test is whether we can conclude that two sample means come from different population distributions, given the N and observed variance, plus the standard assumptions of the t-test. Because the sample means are nearly guaranteed to be different, one can nearly always reject the null by making N (and, hence, power) sufficiently large. Therefore, failure to reject the null is never justification for accepting the null. One can always attribute the failure to inadequate power. Because the outcome of traditional hypothesis testing is dependent on N, some scientists believe it's more meaningful to compute a probabilistic estimate of an effect's magnitude (i.e., a CI) and then assess the practical importance of that magnitude. In your case, the best procedure would probably be to decide ahead of time how large a difference is important and use a power analysis to estimate how large a sample you need to detect a difference of that magnitude reliably. It seems to me that you don't need to show that the populations are identical -- only that any difference that exists between them is probably smaller than some predetermined, negligible value. From owner-cstg-l@VTVM1.CC.VT.EDU Wed Jul 9 18:09:13 1997 Received: from listserv.vt.edu (listserv.vt.edu [128.173.4.9]) by listserv.vt.edu (8.8.5/8.8.5) with ESMTP id SAA13282; Wed, 9 Jul 1997 18:03:53 -0400 Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (LISTSERV release 1.8c) with NJE id 7462 for CSTG-L@VTVM1.CC.VT.EDU; Wed, 9 Jul 1997 18:02:55 -0400 Received: from VTVM1 (NJE origin SMTP@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.2a/1.8a) with BSMTP id 4364; Wed, 9 Jul 1997 17:52:50 -0400 Received: from wlp1.wl.wpafb.af.mil by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with TCP; Wed, 09 Jul 97 17:52:49 EDT Received: by wlp1.wl.wpafb.af.mil; (5.65v3.2/1.1.8.2/20Sep95-0402PM) id AA05144; Wed, 9 Jul 1997 17:53:34 -0400 Alternate-Recipient: allowed Auto-Forwarded: prohibited Content-Return: allowed Disclose-Recipients: prohibited Conversion: allowed Importance: normal Priority: normal Sensitivity: Normal X-Dmw-Body-Names: Supporting the null hypothesis -- update X-Mailer: MailWorks 1.8-FT1 Message-Id: <970709175332.852@wlp1.wl.wpafb.af.mil.0> Date: Wed, 9 Jul 1997 17:53:33 -0400 Reply-To: CSTG-L DISCUSSION LIST Sender: CSTG-L DISCUSSION LIST From: Mike Snow Subject: Supporting the null hypothesis -- update X-To: visual-l@vtvm1.cc.vt.edu To: CSTG-L@VTVM1.CC.VT.EDU Status: RO Greetings, I would like to thank all those who responded to my recent post regarding statistical support of the conclusion that two samples are equivalent. The following is an attempt to provide a distillation of the commentary: 1) One cannot prove the null hypothesis! This was the gist of many of the responses received. I would like to point out the careful NON-use of the word "prove" in my original post. However, the question remains: if one has collected data indicating (for example) that a new, cheaper method of doing something results in performance that is just as good as the old way, is there a standard way of reporting this to the human factors community? 2) There does not seem to be a widely-accepted or standard method of supporting the conclusion that two experimental conditions are equivalent within the human factors community, perhaps because the situation simply does not arise very often. Communications with HFES journal editors (past and present) and program chairs (past and present) indicate that papers attempting to show that two experimental conditions were equivalent have been rare. However, the following references may be helpful/interesting: Psychological Science, 8, pp. 1- 20, Jan, 1997 (thanks for the above to Mary Czerwinski) Biederman, I., & Cooper, E. E. (1991). Priming contour-deleted images: Evidence for intermediate representations in visual object recognition. Cognitive Psychology, 23, 393-419. Biederman, I., & Cooper, E. E. (1992). Size invariance in human shape recognition. Journal of Experimental Psychology: Human Perception and Performance, 18, 121-133. (thanks for the above to Tim from Iowa State) Design and analysis of bioavailability and bioequivalence studies, Shein-Chung Chow, 1992 (textbook) "Proving the null hypothesis in clinical trials", WC Blackwelder, Controlled clinical trials 3:345-353, 1982 "A new procedure for testing equivalence in comparative bioavailability and other clinical trials", Sharon Anderson & Walter Hauck, Communications in Statistics--Theory and Methods 12:2663-2692, 1983 "Bioavailability - A problem in equivalence", CM Metzler, Biometrics 30:309-317, 1974 Kim, J. S. (May, 1997). "Determining sample size for testing equivalence." Medical Device & Diagnostic Industry, pp. 114-115. (thanks for the above to Daryle Gardner-Bonneau) W.W. Hauck & S. Anderson (1992). Types of bioequivalence and related statistical considerations. Int. J of Clinical Pharmacology, Therapy, & Toxicology, 30, 181-187. (thanks for the above to Dave Post) 3) The medical community has produced an entire body of literature on bioequivalence (see above), and the FDA has set standards that drug manufacturers must meet when claiming that a generic drug is equivalent to a name-brand drug. In a nutshell, the performance of one drug must fall within a 45% confidence interval of performance of the other (performance measured by absorption rate, etc.). This info may be found at: http://www.fda.gov/cder/da/adpscb.htm 4) Although not widely-used, a good approach to supporting equivalence of two experimental conditions might be to set a priori standards of *practical* significance, and then calculating confidence intervals afterward to determine the probability that the means of the two samples differed by that much or less. I'd like to throw out the following question: If, when concluding that two experimental conditions are different, one reports the probability of incorrectly rejecting the null hypothesis (alpha), would it be incorrect, when concluding that two experimental conditions are not different, to report the probability of incorrectly accepting the null hypothesis (beta)? Thanks again, Mike - ----------------------------------------------------------------------- Michael P. Snow, Ph.D. Vehicle-Pilot Integration Branch WL/FIGP, Bldg. 146 email: snowmp@wl.wpafb.af.mil 2210 8th St., Suite 1 phone: (937)255-6895 Wright-Patterson AFB, OH 45433-7521 FAX: (937)656-4547 From utest@hubcap.clemson.edu Sun Jul 20 14:47:33 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id OAA16279; Sun, 20 Jul 1997 14:48:22 -0400 (EDT) Date: Sun, 20 Jul 1997 14:48:22 -0400 (EDT) Message-Id: Errors-To: tharon@hubcap.clemson.edu Reply-To: Tom.Dayton@Eng.Sun.COM Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Tom Dayton To: Multiple recipients of list Subject: Java style--not! X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO Dear U-Testers, On June 23 Mike Darnell from Netscape posted the question of whether there are style guidelines or standards for Java UIs. The only response I saw posted was Dick Miller pointing to the Web-posted white paper by Ludolph, Gentner, and Ryan=20 (http://www.javasoft.com/products/hotjavaviews/hjv.white.html). Dick referred to that white paper as being about "guidelines for Java applications." Here are my personal opinions, which may not be shared by Sun Microsystems or anyone else: Any UI style standard has a usability reason to exist only if it gives an individual user a consistent, predictable, look and feel for the user's _entire_ computer experience--for all software which that user uses. A practical limitation on such universal consistency is that there are several UI platform styles, with most machines being set up to support only one. Fortunately, most users use just one machine, most users of multiple machines use machines of the same type, and the relatively few users of multiple machine types mostly use just one machine type at a time. So UI style standards make sense at the level of UI platform--a style for all software running in any given UI platform such as CDE/Motif, OS/2, Windows, and Macintosh. The point is that any given user have a consistent, predictable _whole_ experience within a work session. Programming languages, development toolkits, and the like are merely technologies for enabling whatever user experience is desirable. They should not _drive_ the user experience. So they should not have their own UI style guides. The Java programming language, object classes, development tools, and all related technologies should support creation of software having whatever look and feel is present on the UI platform on which that software is destined to run. Therefore there should be no "Java" style guide any more than there should be a C++ style guide or any development toolkit's style guide. (Some Sun promotional literature says Java is "C++ done right.") Users do not benefit from look and feel consistency across software that shares implementation technology.=20 Users should not have to be aware of implementation technology. If a Java-implemented piece of software is intended to run on multiple UI platforms, Java should be used to create a different version of that software for each platform, each version having that platform's look and feel. One step toward that goal is the new release of the Java Foundation Classes, which make available a wide variety of run-time- switchable GUI controls compatible with the styles of GUI platforms such as Motif, Windows, OS/2, and Macintosh. (See http://java.sun.com/products/jfc for more info.) In my opinion, the white paper by Ludolph, Gentner, and Ryan does not contain any answers to the question about "Java" style. That white paper does contain answers to a _different_ question: "What is the style of the HotJava Views UI platform?" The HotJava Views UI platform does not yet have a published GUI style guide, so that white paper has to suffice for now as the HotJava Views UI platform's equivalent of the CUA, Windows, CDE, Motif, and Mac UI platform style guides. HotJava Views defines the user's entire experience by being an entire UI environment in which a user works while using a given machine (usually, but not necessarily, a Network Computer). So HotJava Views requires a UI style guide, whereas "Java" does not. If the Java-implemented software you are designing is not destined for running in the HotJava Views operating system, then you should ignore t= he=20 HotJava Views UI style. (Except that you might use it, along with other=20 platform style guides, for ideas to fill gaps in the style guide of your ta= rget=20 platform.) These are my personal opinions, not necessarily Sun's or anyone else's.=20 Please don't contact me asking for more info such as when a HotJava Views style guide will be written, because I'm not privy to such information. Tom Dayton SunSoft Usability Labs & Services tom.dayton@sun.com +1 (415)786-8579 (x88579) voice +1 (415)786-4096 fax Regular Mail: Sun Microsystems 901 San Antonio Rd., MPK18-107 Palo Alto, CA 94303 Urgent Delivery: Sun Microsystems 1601 Willow Rd. at Bayfront Expressway 18 Network Circle, MPK18-107 Menlo Park, CA 94025 From owner-chi-web@ACM.ORG Fri Jul 25 12:14:45 1997 Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA3032882; Fri, 25 Jul 1997 12:14:31 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 363892 for CHI-WEB@ACM.ORG; Fri, 25 Jul 1997 12:14:28 -0400 Received: from arbi.Informatik.Uni-Oldenburg.DE (arbi.Informatik.Uni-Oldenburg.DE [134.106.1.7]) by mail.acm.org (8.8.5/8.7.5) with SMTP id MAA3033068 for ; Fri, 25 Jul 1997 12:14:19 -0400 Received: by arbi.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Fri, 25 Jul 97 18:15 CST Received: by legolas.Informatik.Uni-Oldenburg.DE (Smail3.1.29.1) id ; Fri, 25 Jul 97 18:15 CST X-Sender: gorny@legolas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Organisation: University of Oldenburg - Address: D-26111 Oldenburg, Germany X-Department: Informatics Department X-Unit: Computer Graphics & Human-Computer Interaction X-Phone: +49 441 798-2065, Fax: +49 441 798-2155 X-Aliased: From Peter Gorny Message-Id: Date: Fri, 25 Jul 1997 18:15:58 +0200 Reply-To: Peter Gorny Sender: "ACM SIGCHI WWW Human Factors (Open Discussion)" From: Peter Gorny Subject: WWW-Frames and legal problems To: CHI-WEB@ACM.ORG Status: RO WWW-Frames and legal problem ---------------------------- In a German law journal (Neue Juristische Wochenschrift - Computerreport no. 4/1997, pp.224-228) a lawyer describes the legal problems of links in Webpages (Stefan Ernst: Rechtliche Fragen bei der Verwendung von Hyperlinks im Internet [Legal questions regarding the use of hyperlinks in the internet] ). The author inspects the problems arising from links with respect to the copyright (German, European, International) and concludes, that an author of a webpage with links to copyrighted WWW-documents does not violate the copyright. When a reader of that webpage follows the link and gets the page copied into the browser cache of his own computer, then neither this is a violation of the copyright (because it can be assumed, that the provider of the page puts it into the internet to make it available for the private use by unspecified indiviuals) -- the use of the material for none-private purposes, though, is still restricted. But imagine, that the author of the page offering the links to the copyrighted material presents the results in an own frame: then the authorship of the presented page might not be obvious anymore. That would constituate a violation of the copyright. In a special section the lawyer shows, that the use of frames may also violate laws regulating competitive actions in the market (German "Law against Unfair Competition"), since the readers of such a "foreign" page in a frame might get the impression, that the material was produced by the frame provider, who thus would gain unfair advantages in the market. The article concludes that the use of frames can be very dangerous for their providers, since they can never be certain, that a reader -- by clicking through several links -- might reach material protected by copyright or competition laws without getting aware of the fact, that the surrounding frame(s) have no direct connection. Also the regulations for the protection of personal integrity and the right on the own pictures could become applicable. Finally the article stresses the fact that material in the internet is globally accessible -- which in the legal sense means, that violations could be pursued at any place in the world (with internet access) after the local legal system. ---- My conclusion derived from these legal arguments: As far as I know, no browser shows the URL of the page in the frame outside the frame (except after a special request by the user). Therefore: Beware of frames! Otherwise you might risk to be sued from some place in the world for violating the local or international law. Peter Gorny ______________________________________________________________________ Prof. Dr. Peter Gorny Informatics Dept. - C. v. Ossietzky University Oldenburg Computer Graphics & Human-Computer Interaction Unit ______________________________________________________________________ Snail-Mail: D-26111 Oldenburg - Germany Telephone: +49-441-798-2901 or -4521 (Fax: -2155) E-Mail: Gorny@Informatik.Uni-Oldenburg.DE URLs: http://www-CG-HCI.Informatik.Uni-Oldenburg.DE/ http://www.OFFIS.Uni-Oldenburg.DE/ ______________________________________________________________________ From utest@hubcap.clemson.edu Tue Aug 5 10:29:43 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id KAA12773; Tue, 5 Aug 1997 10:28:04 -0400 (EDT) Date: Tue, 5 Aug 1997 10:28:04 -0400 (EDT) Message-Id: <33E73817.6EB413E5@tripos.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: jgrant@tripos.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Joe Grant To: Multiple recipients of list Subject: About Face / "Dispensing with the Disk Model" /Save & Undo X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO One of challenging portions of About Face for me concerned how much the common UI has forced most users to service the implementation model with respect to saving files. Alan Cooper argues that programs should automatically save for us, as opposed to training us to compulsively hit Control-S every few minutes. To me, this goes hand-in-hand with providing undo functionality that is vastly enhanced over what commonly we have today, which Mr. Cooper also espouses. He believes we should "(d)ispense with the disk model,'" and get rid of the "File" menu. People deal with "Spreadsheets," "Invoices," "Pictures," or, more generically, "Documents." In support of this, I have found that one of the toughest things in teaching novices of the current standard GUI environment is the File menu. When I do, I immediately get the feeling that I have to gloss over much about how the computer really works to get that person past the basic tasks of creating a new document and saving it in the right place. To do automatic saving and to get dispense with the forced exposure to the file system involves a lot of hard work on the UI that I believe most programs don't do today. Programs would need to save "garbage" data that users really would prefer to keep. For example, I might remember only a portion of a name or a phone number, but I would really like the program to keep it without me telling it to do so, and to know where it belongs. Database administrators would probably have a fit in even discussing some of these things. As for the multiple undo, we need to provide people intelligent ways to come back to any reasonable point in time with their work-in-progress, without requiring them to do many saves and to think of clever ways to name and save files. (i.e. *Icon_Project_v1*, *Icon_Project_v2*, *Icon_Project_Feedback*) "About Face" does a better job of explaining these topics......... I hope to only convey the basic idea. Any thoughts? Joe Grant St. Louis, MO From utest@hubcap.clemson.edu Tue Aug 5 13:57:56 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id NAA07214; Tue, 5 Aug 1997 13:53:40 -0400 (EDT) Date: Tue, 5 Aug 1997 13:53:40 -0400 (EDT) Message-Id: <3.0.1.32.19970805105040.00b73414@mail.cooper.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: alan@cooper.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Alan Cooper To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO Stuart, Thanks very much for your comments. I believe that you are very much on the right track. Here at Cooper Software, we don't do any programming. Nor, as far as I can tell, do we do much of the stuff that Usability Professionals do. However, our last three clients have each applied for multiple patents on conceptual design work we accomplished for them early on in the design process. I have the greatest respect for *ALL* of the difficult and complex disciplines that make up our industry. In the same way that the radiologist and the surgeon work together for the patient's health, the designer, the programmer and the utester must work together for the user's health. Yes, I am a DESIGNER. I am not a tester. I am not a programmer (although I've programmed a lot in the past). About Face was written from the designer's point of view for an audience of developers more than for anyone else. I'm working on a new book right now, and it is, once again, written from the designer's pov, but its intended audience is managers of software development, showing them how DESIGN can be just the tool they need to bring the development process under control. There are lots of viewpoints, professions, and skillsets that must work together to create breakthrough new interactive products. Right now, I believe that the DESIGN of complex interactive systems is the weakest discipline in the industry. I like to blaze new trails, rather than following after others. Therefore I work in the world of interaction design. Hopefully, others will soon follow. Thanx, Alan At 04:52 PM 8/5/97 +0800, Stuart Burnfield wrote: > >Charlie, you said: >> Alan Cooper and I had a spirited debate about the role of usability >> professionals. . . I emerged from this discussion with a belief that >> I was in agreement with his basic stance, which I would summarize >> as follows. . . >> >> "Creating a program requires both a technical design and an >> interactive design. Programmers produce the technical design, >> user-centered designers produce the interactive design. These >> are two different tasks of co-equal importance. The skills >> for both are related but not the same. Interactive designers >> create software interfaces and plan the interaction, software >> engineers create the technical design and program it." >> >> Cooper may not identify himself as a usability professional but he >> is one. . . Some have suggested that Cooper's stance is "opposed" >> to the usability professional community. I don't see this. >> [...snip] >> What we need to do as a profession is to establish ourselves as equal >> participants on the software development team. I think this is what >> Cooper is advocating when he separates design from programming. > >It struck me that you refer to 'usability professionals', while Alan >is careful in the book and in your summary to say 'the designer'. Is >this where the two of you part company? > >_Someone_ always does the design. It could be a trained, experienced, >full-time usability professional. It could be a guerrilla band of >technical writers, trainers and tech support people. It could be a >user-focused developer. Too often it just bubbles up from the >programmer's subconscious. > >Whoever it is, they need tools and techniques, a user-centred >approach, and a shared vocabulary with which to discuss and explain >design issues. Usability professionals should have these already -- >they don't need 'About Face'. The rest of us do. > >To give two examples: > >1. For two years I'd felt a growing unease over our product's user > interface. There was a deep problem, but I could only see super- > ficial symptoms to treat. > > The diagram on page 29 made everything snap into focus. The idea > of different models (implementation model, manifest model, mental > model) no doubt seems old hat and obvious to people in the field > but at the time it absolutely floored me. > >2. Some of us have spent too many hours tinkering with the wording of > error messages, thinking "at least we're improving things bit by > bit", when we were merely walking a little faster in the wrong > direction. > > "Make errors impossible" is exactly the right thing for someone > like me to read, to reset our thinking. The target (no errors) is > too far away to hit but it's the right place to aim. > >I thought Alan stated his position pretty clearly in the Introduction: > > "I wish I could say this book is for user interface designers, > and let it go at that. Most user interfaces are still designed by > programmers, an increasing number of whom are growing uneasy as > they glimpse the gulf between the skill set needed for software > construction and the skill set needed for software design. > Documentation writers, trainers and technical support people > increasingly share this same worry. It is for this growing > community of design-aware developers that this book is written." > >Charlie, I understand that through the Lucid movement you want to >promote user-centred design as a practice and a profession. For people >like me who have to be practitioners without being professionals, >'About Face' fills a need that would not be met by a shelf-full of >worthy reference books. I wouldn't want it to be the only book I >read (it's not) but for me it was an excellent start. > >Regards >--- >Stuart Burnfield >Functional Software Pty Ltd >mailto:slb@fs.com.au > > > ---------------------------------------------------------------------------- Alan Cooper, Cooper Software Inc * alan@cooper.com * vox: 415-855-0250 fax: 415-855-0251 * web: http://www.cooper.com 2345 Yale Street, Palo Alto CA 94306 "Trying to define yourself is like trying to bite your own teeth." --Alan Watts ---------------------------------------------------------------------------- From utest@hubcap.clemson.edu Tue Aug 5 19:22:46 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id TAA28232; Tue, 5 Aug 1997 19:18:10 -0400 (EDT) Date: Tue, 5 Aug 1997 19:18:10 -0400 (EDT) Message-Id: <3.0.1.32.19970805161206.00b7aff4@mail.cooper.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: alan@cooper.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Alan Cooper To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Steve, We do no programming. We do no prototyping. We DO create a few animations to show our clients and programmers details of complex interactions. These are usually Director hacks. Programming, even just prototyping, subverts the activity of design, in my opinion. Thanx, Alan At 11:21 AM 8/5/97 -0700, Steve Portigal wrote: >Alan Cooper spake: >> >> >> Here at Cooper Software, we don't do any programming. > >Do you do prototyping? Where do the lines cross? Do you mean that >you don't develop final code? > > > ---------------------------------------------------------------------------- Alan Cooper, Cooper Software Inc * alan@cooper.com * vox: 415-855-0250 fax: 415-855-0251 * web: http://www.cooper.com 2345 Yale Street, Palo Alto CA 94306 "Trying to define yourself is like trying to bite your own teeth." --Alan Watts ---------------------------------------------------------------------------- From utest@hubcap.clemson.edu Tue Aug 5 20:45:10 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id UAA08931; Tue, 5 Aug 1997 20:44:34 -0400 (EDT) Date: Tue, 5 Aug 1997 20:44:34 -0400 (EDT) Message-Id: <3.0.1.32.19970805204233.006af20c@209.36.70.2> Errors-To: tharon@hubcap.clemson.edu Reply-To: charlie@cognetics.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: charlie@cognetics.com (Charlie Kreitzberg) To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Alan: I'm pleased that this conversation is taking place. In your reply to Stuart Burnfield, you describe yourself as "a DESIGNER. I am not a tester. I am not a programmer (although I've programmed a lot in the past)". That is exactly how I would describe myself. I programmed for 16 years and have been an interactional designer for 16. And like you, I have a company that designs software. We do not program nor do we do usability testing. But I AM a usability professional because my core goal is to create usable software. My designs are user-centric in that I almost always weight ease of use, ease of learning or increased error prevention above technical considerations. And my interest in usability extends beyond the individual user to the relationship between the software product and the corporation in which it operates. I am not a usability tester. But I use usability tests as a quality assurance tool. My first encounter with UPA was at last year's conference. I was concerned that as a designer, I might not be welcomed. I was delighted to find an organization which welcomed and nurtured designers. I found the similar attitude at SIGCHI (which I had not attended in several years). There was a panel with Terry Winograd about design vs measurement; but the panelists could not find much to disagree about. I think that the usability profession is maturing, and two specialties are emerging: design and testing. This is a happy combination which, applied to software development, can produce excellence in interactional design. As a consultant, I am always taking the corporate pulse, and I have sensed a great change in attitude over the past year. CIO's have become receptive to the idea of design and usability as a goal. But there is powerful little design skill and instinct in the programmer community. And, as you note, those of us who become interactional designers stop programming. So where do we place our professional identities? For me, it is with the usability community. I see little need to define a profession of interaction designer separate from usability. But I do see risks in doing so. It is impossible for software engineers to learn about interactional design without a core focus on usability. HCI is, after all, 50% human. If we attempt to separate the design process from its quality assurance component, we risk compromising excellence. Best, Charlie ------------------------------------------------------------------------------ oo\ Charlie Kreitzberg (__)\ _ President \ \ .' /`. Cognetics Corporation \ \ / \ 51 Everett Drive 103B \ '" \ PO Box 386 . ( ) \ Princeton Junction, NJ 08550 '-| )__| :. \ (609) 799-5005 x235 | | | | \ '. charlie@cognetics.com c__; c__; '-..'>.__ DESIGN MAKES THE DIFFERENCE ----------------------------------------------------------------------------- From utest@hubcap.clemson.edu Wed Aug 6 02:47:20 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id CAA05345; Wed, 6 Aug 1997 02:44:11 -0400 (EDT) Date: Wed, 6 Aug 1997 02:44:11 -0400 (EDT) Message-Id: <19970806074448.AAB28964@124771104915> Errors-To: tharon@hubcap.clemson.edu Reply-To: rolf.molich@post3.tele.dk Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: rolf.molich@post3.tele.dk (Rolf Molich) To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO Alan, Allow me three questions in this very interesting discussion: 1. Is there any financially affordable software available that I can buy and that you can recommend as a practical demonstration of the use of your design tips and axioms? 2. If a usability test of a software dialog designed by your company showed a huge list of usability disasters, how would you react? 3. Do you consider "About Face" usable? Well, of course yes. Here are two arguments against its usability: The last page number in my copy is 580. Most of the examples are from Word processing - not from administrative data processing which I find most programmers doing. Regards, Rolf Rolf Molich DialogDesign Skovkrogen 3 3660 Stenlxse Denmark e-mail: molich@acm.org From utest@hubcap.clemson.edu Wed Aug 6 09:50:16 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id JAA25537; Wed, 6 Aug 1997 09:46:18 -0400 (EDT) Date: Wed, 6 Aug 1997 09:46:18 -0400 (EDT) Message-Id: Errors-To: tharon@hubcap.clemson.edu Reply-To: DICK_MILLER@HP-Vancouver-om10.om.hp.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: DICK_MILLER@HP-Vancouver-om10.om.hp.com To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO Rolf: = To reply to your question #2: = If I were to have that experience, that would cause me to call into= = question the process we used to arrive at the design and = implementation. I'd want to make sure that it was a user-centered = design process, and that the key users were involved. I'd also like= to = be sure that sufficient formative and summative usability testing h= ad = been incorporated in the process. Finally, I'd want to make sure th= at = we had tested the product with subjects who accurately reflected th= e = actual users of it. = If all those things were included, I'd be very surprised to see muc= h = in the way of usability disasters with the product. Such things = usually come from a "we know how to design this stuff" and "throw i= t = over the wall when done" approach. = --Dick Miller ______________________________ Reply Separator _________________________= ________ Subject: Re: Taking Cooper to task Author: Non-HP-rolf.molich (rolf.molich@post3.tele.dk) at HP-Vancouver,= mimegw10 Date: 8/5/97 11:47 PM Alan, = Allow me three questions in this very interesting discussion: = 1. Is there any financially affordable software available that I can buy= = and that you can recommend as a practical demonstration of the use of yo= ur = design tips and axioms? = 2. If a usability test of a software dialog designed by your company sho= wed = a huge list of usability disasters, how would you react? = 3. Do you consider "About Face" usable? Well, of course yes. Here are tw= o = arguments against its usability: The last page number in my copy is 580.= = Most of the examples are from Word processing - not from administrative = = data processing which I find most programmers doing. = Regards, Rolf = Rolf Molich DialogDesign Skovkrogen 3 3660 Stenl=B0se Denmark e-mail: molich@acm.org From utest@hubcap.clemson.edu Wed Aug 6 11:26:13 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id LAA08182; Wed, 6 Aug 1997 11:03:16 -0400 (EDT) Date: Wed, 6 Aug 1997 11:03:16 -0400 (EDT) Message-Id: <199708061454.AA06658@waltz.rahul.net> Errors-To: tharon@hubcap.clemson.edu Reply-To: stevep@rahul.net Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Steve Portigal To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O > We do no programming. > > We do no prototyping. > > We DO create a few animations to show our clients and programmers details > of complex interactions. These are usually Director hacks. Hmm. Sounds like prototyping to me....Again I'm not sure where the line gets drawn. > > Programming, even just prototyping, subverts the activity of design, in > my opinion. Prototyping makes an excellent way to communicate the specifics of a design to a client. Steve, quite willing to accept that a variety of methodologies is what makes the world go round, just musing aloud... From utest@hubcap.clemson.edu Wed Aug 6 12:07:55 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id LAA29648; Wed, 6 Aug 1997 11:58:16 -0400 (EDT) Date: Wed, 6 Aug 1997 11:58:16 -0400 (EDT) Message-Id: Errors-To: tharon@hubcap.clemson.edu Reply-To: DICK_MILLER@HP-Vancouver-om10.om.hp.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: DICK_MILLER@HP-Vancouver-om10.om.hp.com To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO Steve: It seems to me that it might be worthwhile to consider the analogy of a software designer to that of a building designer, i. e., an architect. For very small projects, the architect is unlikely to do more than just architectural drawings, but even then may do a rendering so the customer can get an idea of what to expect. For larger projects, I suspect they're likely, or even required to do some sort of mock-up, be it physical, or, in this cyberage, virtual. To bring the analogy to the software world, I would expect a designer to do at least some mock-ups of screens that have at least simulated functionality of navigation so that the customer can get a sense of the "look and feel" of the product. While this is certainly not usability testing in any sense, it seems to qualify as prototyping. I disagree that such prototyping subverts the activity of design. Webster defines "design" as "...to create, fashion, or construct according to plan." I maintain that prototyping can be very much a part of that process, especially in communicating the design to a customer. It also seems to me that the "animations" he mentions are nothing more than prototypes. If Cooper chooses not to prototype, he is certainly free to do so, and he seems to be quite successful in his profession. I'm suggesting that, while his approach is a valid option, there are other approaches that are equally valid. --Dick Miller ______________________________ Reply Separator _________________________________ Subject: Re: Taking Cooper to task Author: Non-HP-stevep (stevep@rahul.net) at HP-Vancouver,shargw10 Date: 8/6/97 8:03 AM > We do no programming. > > We do no prototyping. > > We DO create a few animations to show our clients and programmers details > of complex interactions. These are usually Director hacks. Hmm. Sounds like prototyping to me....Again I'm not sure where the line gets drawn. > > Programming, even just prototyping, subverts the activity of design, in > my opinion. Prototyping makes an excellent way to communicate the specifics of a design to a client. Steve, quite willing to accept that a variety of methodologies is what makes the world go round, just musing aloud... From utest@hubcap.clemson.edu Wed Aug 6 12:58:03 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id MAA32439; Wed, 6 Aug 1997 12:57:18 -0400 (EDT) Date: Wed, 6 Aug 1997 12:57:18 -0400 (EDT) Message-Id: <3.0.1.32.19970806092956.00b7a2e4@mail.cooper.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: alan@cooper.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Alan Cooper To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Rolf, At 02:47 AM 8/6/97 -0400, Rolf Molich wrote: >Alan, > >Allow me three questions in this very interesting discussion: Yes. I will allow you three, but only these three and no more. Promise? > >1. Is there any financially affordable software available that I can buy >and that you can recommend as a practical demonstration of the use of your >design tips and axioms? Not yet. > >2. If a usability test of a software dialog designed by your company showed >a huge list of usability disasters, how would you react? Clearly, this is a hypothetical situation. I would react by fixing things. However, I'd like to point out that this question misses the mark by many, many miles. The bulk of our work with EXISTING software is involved in eliminating dialogs. The bulk of our work with NEW software is involved with non-modal (ie. dialog-less) interaction. When you have taken a product from 100 dialogs to 3 dialogs, it doesn't matter NEARLY as much when the remaining three dialogs are sub-optimal. > >3. Do you consider "About Face" usable? Well, of course yes. Here are two >arguments against its usability: The last page number in my copy is 580. >Most of the examples are from Word processing - not from administrative >data processing which I find most programmers doing. Clearly, you have never had a book published. Nor, for that matter, have you ever had a major work of software published. You know that old lament "Look what they've done to my song, ma?" Well, it goes for books too, and goes double for software (see question one)! As someone once said, "If I had had more time it would have been shorter." Re" the "WP vs DP" examples debate: BULLBLEEP!! I cut my teeth in the IBM 360/370 world of business data processing when real men (persons?) coded with PUNCH CARDS and core dumps on green bar paper! Some of the more interesting design work I've done on personal computers involves corporate data processing and I can say categorically that THE PEOPLE WHO USE THE DP SOFTWARE AREN"T ANY DIFFERENT FROM THE PEOPLE WHO USE WP SOFTWARE! Good design relates to people more than it does to technology, so if the WP vs DP issue looms large in *YOUR* work, then it is a clear indicator of why a "usability test of a software dialog designed by your company showed a huge list of usability disasters". This is not a problem for us. Thanks again for asking these FINAL three questions. I'm sure that others on this list will constrain themselves to a more constructive discussion. Thanx, Alan ---------------------------------------------------------------------------- Alan Cooper, Cooper Software Inc * alan@cooper.com * vox: 650-855-0250 fax: 650-855-0251 * web: http://www.cooper.com 2345 Yale Street, Palo Alto CA 94306 "Always listen to experts. They'll tell you what can't be done, and why. Then do it." --Robert A. Heinlein. ---------------------------------------------------------------------------- From utest@hubcap.clemson.edu Wed Aug 6 12:59:33 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id MAA12388; Wed, 6 Aug 1997 12:58:35 -0400 (EDT) Date: Wed, 6 Aug 1997 12:58:35 -0400 (EDT) Message-Id: <3.0.1.32.19970806095013.00b8d71c@mail.cooper.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: alan@cooper.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Alan Cooper To: Multiple recipients of list Subject: Re: Taking Cooper to task X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: O Steve, In 1988, I wrote a PROTOTYPE. It took about four months of extremely hard work. It was about 25,000 lines of C code. It showed how to do several things that had never been done on a personal computer before IN A PRACTICAL MANNER (I'm sure each of the various pieces had already been breadboarded in university, one graduate student at a time). It demonstrated significant technical innovation. It demonstrated significant conceptual innovation. It was a proof that construction of the real product it represented was actually feasible. It was code-named Ruby. I demonstrated that prototype to Bill Gates in March of that year, and he purchased it from me. Combined with his QuickBasic, it was released two years later and became known as Visual Basic. It changed the way computing is done and affected almost every desktop product Microsoft sells. Earlier this year, we did some design work for a division of Sony. We spent about three days hacking together a Director animation to articulate the interaction of a complex bit of user interaction. The animation was a complete dummy, proving nothing. However, it was extremely useful in communicating the value of our conceptual design to the client. I understand that you are confused about terminology in the computer industry ("Again I'm not sure where the line gets drawn."). You are not alone. Many people aren't sure. However, that isn't because the distinction is an inherently fuzzy one. It is because it is in SOME practitioner's self-interest to blur the line. That is why I work very diligently to define terms for OUR WORK (http://www.cooper.com/articles/vbpj_perils_of_prototyping.html/). Ruby was a "prototype" because it proved that construction was feasible. For that same reason, the Sony animation was NOT a prototype, even though it was enormously useful and well worth the effort. There are a lot of people in the software industry who are using the term PROTOTYPE indiscriminately and debasing its role in our professional taxonomy. I find this unpleasant and counterproductive to the efforts of turning our craft into a profession. I can only attribute this to professional jealously on the part of related professions. Thanx, Alan PS. Upon inking the deal with Gates, virtually all of the Ruby code was thrown out and we began construction of the final version from scratch, keeping only the good ideas (there's more at: http://www.cooper.com/alan/father_of_vb.html/). That's what should happen to all prototypes. PPS. There's a difference between "willing to accept that a variety of methodologies" and being supportive of the growth of a brother profession. At 07:54 AM 8/6/97 -0700, Steve Portigal wrote: >> We do no programming. >> >> We do no prototyping. >> >> We DO create a few animations to show our clients and programmers details >> of complex interactions. These are usually Director hacks. >Hmm. > >Sounds like prototyping to me....Again I'm not sure where the line gets >drawn. >> >> Programming, even just prototyping, subverts the activity of design, in >> my opinion. >Prototyping makes an excellent way to communicate the specifics of a design >to a client. > >Steve, quite willing to accept that a variety of methodologies is what makes >the world go round, just musing aloud... > ---------------------------------------------------------------------------- Alan Cooper, Cooper Software Inc * alan@cooper.com * vox: 650-855-0250 fax: 650-855-0251 * web: http://www.cooper.com 2345 Yale Street, Palo Alto CA 94306 "Always listen to experts. They'll tell you what can't be done, and why. Then do it." --Robert A. Heinlein. ---------------------------------------------------------------------------- From utest@hubcap.clemson.edu Tue Aug 19 12:35:00 1997 Received: from hubcap (localhost [127.0.0.1]) by hubcap.clemson.edu (8.8.5/8.8.5) with SMTP id MAA31096; Tue, 19 Aug 1997 12:35:47 -0400 (EDT) Date: Tue, 19 Aug 1997 12:35:47 -0400 (EDT) Message-Id: <503A2A3C2932CF118D8800805FD44E180411873E@RED-68-MSG.dns.microsoft.com> Errors-To: tharon@hubcap.clemson.edu Reply-To: lesleya@microsoft.com Originator: utest@hubcap.clemson.edu Sender: utest@hubcap.clemson.edu Precedence: bulk From: Lesley Allan To: Multiple recipients of list Subject: RE: Seeking Questionnaire Design Guidelines X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Status: RO Another great reference book for questionnaires is: Questionnaire Design, Interviewing, and Attitude Measurement - A.N. Oppenheim, Pinters Publishers, 1996 From uie@uie.com Tue Jan 5 15:57:54 1999 Received: by europe.std.com (8.7.6/BZS-8-1.0) id NAA25651; Tue, 5 Jan 1999 13:44:50 -0500 (EST) Message-Id: <199901051844.NAA25651@europe.std.com> From: "Jared M. Spool" To: UIEtips@uie.com Date: Tue, 5 Jan 1999 13:16:21 -0500 Subject: Finally, A Usable Web Site -- UIEtips 1/5/99 Sender: uie@uie.com Precedence: list Reply-To: uietips@uie.com Status: RO UIEtips 1/5/99 _______________ Table Of Contents * Introduction * Message From The Editor * Feature: Finally, a Usable Web Site * Spotted in the Press * Upcoming Courses * New: Jared Spool's Brain Sparks * On The Road * Resources: Web Site Usability Book, Eye For Design, www.uie.com * UIEtips Subscription Information _______________ Introduction UIEtips presents our latest research and other information that developers need to design today's products. UIEtips is produced by User Interface Engineering, a product usability consulting firm based in North Andover, MA. Information on subscribing to UIEtips can be found at the end of this message. Visit our web site at http://www.uie.com. _______________ Message From The Editor Jared M. Spool Happy New Year from all of us at User Interface Engineering. 1998 was an amazing year for us at User Interface Engineering. Our User Interface 98 conference in Cambridge, MA was a record-setting success, as were all of our public courses. We published another six issues of Eye For Design with our latest findings. And our research taught us new things about software, documentation, and web site design. 1999 promises to be even better. We're putting the finishing touches on our new presentation series: Brain Sparks, in which Carolyn Snyder, Tara Scanlon, and I will present to you our latest insights. We've got a public course scheduled almost every month in the Boston area or San Francisco. And we're bringing the User Interface 99 conference to San Francisco on April 12-14. In our courses and presentations, people often ask us for examples of good web sites. We're happy to report that we've found one: the CNN site. In our feature article, we describe the site's design characteristics that we believe contribute to its success. Of course, if you want to know more about the successful elements of web pages, then you'll want to come to our next Web Sites that Work: Designing with Your Eyes Open course (in San Francisco on February 1-2 or Cambridge, MA on March 29-30). As usual, if you have any questions or comments, please feel free to drop me a note at jspool@uie.com. Jared _______________ Feature: Finally, A Usable Web Site It's easy to find examples of unusable web sites, but we're happy to report that there are some usable ones out there too. We've recently been looking at the CNN site (http://www.cnn.com) to understand why it seems to work so well. Our informal tests show that users get around this site easily, despite the large amount of content. We've noticed that this site has many of the characteristics that our research has shown to be correlated with user success. > Content, Content, Content Significantly, the site's designers have given users real content from the first screen: the lead story and descriptive links to other important articles - actual information - are at the top of the home page. Our research has shown us that users more successfully use a site when they quickly encounter links that point directly to content. These so-called "content links" (a term we coined) help users more than what we call "category links," which point to pages containing primarily other links. The CNN site immediately gives users dozens of content links in the form of article headlines. > Redundant Links Users more easily find what they're looking for if each page has redundant links to the same place. A link is like a keyhole through which users glimpse the page beyond. Redundant links (that usually have different words or images) give users multiple keyholes into the same room, with a different context for each link. CNN uses redundant links well. For example, the World News summary page typically includes many different links that go to the Middle East news page. One is in a map of the world with different colored areas for each region, one is in a heading of top Mideast stories, and another is in the left panel. Different users will choose different links - but all the links take them where they want to go. Those who understand the CNN site's structure may immediately choose a link in the left panel. Users who want a geographical place, but aren't sure what CNN calls that area, can click on the map. Users interested in articles related to one of the top stories can click on the heading. > Groups of Links CNN also has lots of groups of links, something we've also found to be associated with success at finding information. Each news summary page uses a physical grouping to help users eliminate things they're not interested in and quickly decide if they're looking in the right place. On many sites, vague topic headings make it difficult for users to predict what kinds of content they'll find under that heading. This could have been an issue on the CNN site, which uses 20 different headings such as "World," "Science & Nature," and "Health." However, CNN's editors provide descriptive sample headlines (which are also links) under each category to help illustrate what's there. Users who don't understand what's in the "Fringe" category quickly learn - headlines like "UK man accused of stealing 1.5 million Mars bars," or "Death Styles of the Rich and Famous" show the kind of offbeat stories this category contains. > Long Pages On many of the less successful sites we've tested, users end up pogo-sticking: repeatedly clicking on a topic, realizing it's not the right one, hitting the back button -- and then starting again. As described above, the CNN site alleviates pogo-sticking by including several descriptive headlines under each topic heading. This gives users a preview of what they'll find in that category: World News, Sports, Middle East. The CNN site also avoids pogo-sticking by putting more content on each page. CNN's home page is often more than 10 screens long, but users we've tested don't mind scrolling through such long pages -- they only focus on groups that are important to their immediate goal. > Little White Space CNN's pages are packed with content, having relatively little white space. This corroborates another of our research findings: Too much white space is not a good thing. Users have little problem finding the information they want on dense pages like CNN's, where the designers have used grouping to organize the content. > No Decorative Graphics In our research, we've found that graphics have little effect on users' abilities to find information, and the CNN site demonstrates this. This site doesn't use images for navigation. Except for the CNN logo and a couple of small advertisements, the pages are mostly text. All the other images in the site are used to convey content, such as the picture of Bob Livingston that accompanied the story about his resignation. > No Searching Needed The CNN site effectively eliminates user searches. There's a search engine keyword box on every page, but the site's organization seems to encourage users to find and click on links instead of searching. This is probably good news: We've found that users who resort to search engines are successful only 30% of the time, compared to 52% successful when they avoided the search engine. We have a theory that users go to a search engine when they don't find the links that will lead them to their information -- in effect creating their own links. There's no need for this behavior on the CNN site. In short, the CNN site illustrates our belief that using the concepts we've uncovered in our research can work in practice on a large site with rich, constantly changing content. _______________ Spotted in the Press A review of our report, "Web Site Usability: A Designer's Guide," appears in Dr. Dobb's Electronic Review of Computer Books http://www.ercb.com/ddj/1998/ddj.9811.html. (Note, however that in this review the price of the report is greatly exaggerated -- it now only costs $29.95 and you can order it from our web site at http://www.uie.com.) _______________ Upcoming Courses We've been listening to you -- and we've responded. Thanks to all your requests, we're bringing our three most-popular courses to the West Coast! We've also added dates on the East Coast. These courses are: * Web Sites that Work: Designing with Your Eyes Open San Francisco, CA: February 1-2, 1999 Cambridge, MA: March 29-30, 1999 If you've enjoyed reading about our research findings in UIEtips, then you'll love this course -- two days filled with what we've learned about web sites. You'll actually conduct experiments on many of the sites we've evaluated and test your own site against our findings. (Send mail to WEBCOURSE@UIE.COM with SEND INFO in the subject line to get a detailed course description.) * Product Usability: Survival Techniques Andover, MA: February 8, 1999 San Francisco, CA: March 15, 1999 This is our flagship course. In a single day, you'll learn everything you need to know to get startedconducting usability tests and building paper mockups. The competition is the best part. (Send mail to COURSES@UIE.COM with SEND INFO in the subject line to get a detailed course description.) * Techniques for Complex Applications Andover, MA: February 9, 1999 San Francisco, CA: March 16, 1999 This course delves into the difficulty of building complex applications and web sites. You'll learn from our experience in working with some of the most complex applications on the market. (Send mail to COURSES@UIE.COM with SEND INFO in the subject line to get a detailed course description.) > Special Deal! If you sign up early for two days of courses, you can attend Jared Spool's Brain Sparks absolutely FREE! -- a $99 savings. See the detailed course descriptions or visit our web site for details. For more information on any of these courses, you can send mail to the addresses shown above, visit our web site at http://www.uie.com, or call us at (800) 588-9855 or (978) 975-4343. Register early; these courses are filling up fast. _______________ New: Jared Spool's Brain Sparks Back-to-back presentations, like flint and steel, guaranteed to set your mind on fire! Join Jared Spool, Carolyn Snyder, and Tara Scanlon, as they present the latest findings in software, documentation, and web site usability. Usability: McGyver Style Embedding Knowledge into Design February 3, 1999 San Francisco, CA March 31, 1999 Cambridge, MA The Secrets Of Successful Usability Tests In Search of Product Excellence February 10, 1999 Andover, MA March 17, 1999, San Francisco, CA Each day contains two presentations. Only $99 each day: includes handouts, continental breakfast, and a special gift! Send mail to BRAINSPARKS@UIE.COM with the words SEND INFO in the subject line for details, including how you can attend Brain Sparks absolutely FREE! _______________ On The Road User Interface Engineering's consulting team spends a lot of time traveling. Sometimes, you can catch us while we're in your neighborhood. If we have the time, we'd love to stop by and see what you're doing or possibly even give a short presentation about some of our latest research. Here's a brief summary of some of our upcoming travel and what we'll be discussing: Boston, MA - March 1, 1999 Seybold Seminars (http://www.seyboldseminars.com) Jared M. Spool Building Usable Web Sites (Tutorial) Seattle, WA - February 24, 1999 WinHelp Conference (http://www.winwriters.com) Jared M. Spool Text, Links, and Videotapes: What We Know About Online Reading Waterloo, Ontario: - February 11-12, 1999 Society For Technical Communicators, Western Ontario Chapter Jared M. Spool Product Usability for Documentation Professionals We may be coming to your company. Here's a list of some of the places where we'll be speaking. If you work at one of these companies, please call or e-mail us for information on how to attend these sessions. Citrix (Ft. Lauderdale, FL) Filenet (Costa Mesa, CA) IPSOS-ASI Interactive (New Orleans, LA) SaskTel (Regina, Saskatchewan) Plus, remember that when we're not traveling, you can find us hovering around our home base of North Andover, Mass. _______________ Resources: Web Site Usability Report, Eye For Design, www.uie.com In the process of doing our work, we collect a tremendous amount of information on what makes products and web sites usable. Here are three resources that we've made available: Book: Web Site Usability: A Designer's Guide It's commonly accepted that graphics, color, and whitespace are among important elements of a successful web site. However, it turns out that this may not be the case after all. This report sets those ideas on their head. "Web Site Usability: A Designer's Guide" is a 155-page report based on our observations of the struggles and successes of more than 50 users as they searched for information on nine popular web sites. (To get a sample chapter and ordering information, send mailto:web@uie.com with the words "SEND CHAP-1" in the subject of the message.) Eye For Design If you like what you read on UIEtips, you'll love Eye For Design, our bi-monthly newsletter containing tips and techniques for developing excellent products and web sites. You'll read about the latest research we've done on how to build usable applications. (For a complimentary issue, send your postal address to mailto:efd@uie.com.) http://www.uie.com Here, you'll find articles on many things, including how tabbed dialogs can get designers into trouble, using paper prototypes to manage risk, how to spoon-feed conceptual information using tips and hints, and a comprehensive UI bibliography from Chauncey Wilson of WilDesign Consulting. _______________ UIEtips Subscription Information To get the previous issues of UIEtips: Send the phrase SEND UIETIPS in the subject of a message to archives@uie.com. To remove yourself from the list: Send the word UNSUBSCRIBE in the body of a message to UIEtips-Request@uie.com. To add yourself to the list: Send the word SUBSCRIBE in the body of the message to UIEtips-Request@uie.com. Questions? Send mailto:tips@uie.com. (c) Copyright 1999 User Interface Engineering 800 Turnpike Street, #101 North Andover, MA 01845 phone: (978) 975-4343 fax: (978) 975-5353 http://www.uie.com mailto:uie@uie.com