Categories: Comments (0)
by Joel Aufrecht 12:00 AM, 05 Apr 2001
Previously posted at http://joel.westside.com/wsContentPublisher/story.view?RowId=12

First Session: Short Talks on Input by Hand, Eye, and Brain

The Two-Handed Desktop Interface: Are We There Yet?

Interesting idea, but what this boiled down to was a lefthanded person trying to make a fifteen-minute presentation out of the fact that he could use a mouse and keyboard maybe a little more efficiently than a right-handed person. No data, no experiment. Makes you wonder about the review panel. The point was still valid, though:

  • We use our non-dominant hand to lead action, to set the frame of reference, and for coarser actions
  • We use our dominant hand to follow, to work within the frame of reference, for fine action
  • The executive keys on the keyboard (enter, delete, insert, backspace, etc) are on the right side
  • so, if you're left-handed, you can mouse with the left hand and still hit useful keys with the right hand. If you're right-handed, you can't do this as well.

all in all, this struck me as a very Canadian presentation.

Natural Hand Writing in Unstable 3D space ...

A Japanese-English language barrier made this a bit tough. The bottom line was that it's hard to write or draw in midair. Using a prop like a wooden block makes it much easier. No real experiment or data, but at least this one was based on some actual mucking around in the lab.

Real-time 3D interaction with ActiveCube

A Japanese researcher has a set of cubes that snap together. Cubes include a camera, ultrasonic distance detector, light, buzzer, gyroscope, and so on. When you snap them together, a computer model of the block assemply updates automatically. I think we were all (metaphorically) looking at each other dubiously - what's the point? The point was make very effectively, however, when the demonstrator showed a video: First, he connects a light to the sensor. When he moves his hand towards the sensor, it gets a bit brighter. And in reverse. Then he hooks up a buzzer. Now, as he moves his hand back and forth, a piercing and unpleasant whine rises and falls. (In the background, a computer screen has faithfully recorded the presense of the buzzer module.) Then, he adds a vibrator module. Now a blinking, whining block contraption buzzs around on the laptop keyboard and table surface in the demo video, threatening to pitch over the side of the table, as the audience in the room finally loses it and we all burst out laughing. What we have here is a new form of chindogu, the 'un-useless invention'. http://info.pitt.edu/~ctnst3/chindogu.html. In response to a question, the speaker tried to list some possible practical applications but nobody was buying his ideas.

Solving Multi-target Haptic Problems in Menu Interaction

ok, this one was non-bogus. A scottish team worked on a force-feedback 3-d pen (a sort of robot arm with a pen at the end, called PHANTOM http://www.sensable.com/haptics/products/phantom.html) to see if haptics (the sense of touch) would help people navigate menus. Previous research has shown that Haptics does help the single-select case.

That is, if there is one button on the screen, and the subject has to move the mouse across the screen and click on the button, it helps if the button actually sucks the pointer towards it (via physical pressure on the pointing mechanism). However, this doesn't work for multi-select cases, because you have to drag the pointer across a bunch of sticky 'wrong choices.' One fix is predictive: guess which button the user wants and make the others non-sticky. But that takes a lot of horsepower and still can't be done well (and if you can accurately guess what the user wants to do next, why the hell are you making them drag a cursor around a sticky screen?).

So. They tested the Windows Start menu, requiring users to navigate a few cascading menus to pick the right item. In the control, there was no feedback. In the 'Haptic' case, each menu choice was sticky as described above. In the 'Adapted' case, the force feedback was orthogonal to the direction of movement and proportional to speed. That is, if you start moving horizontally, it gets hard to move vertically.

And the result, with 18 subjects, is that the 'Adapted' case was fastest and generally more accurate, compared to both the visual-only control case and the 'Haptic' simle sticky case. woo-hoo!

Vision-Based Face Tracking System for blah blah

Current systems of vision tracking are intrusive (you have to put something on your face), and take a while to calibrate. (an audience member later argued that these points are less valid now than they were a few years ago). This team devised a system for determining the face orientation (not the pupils) based on the corners of the eyes and mouth, which are easy to find and which have a constant geometrical relationship (as long as you are expressionless). They experimented and found that this system made it easier to control scrolling and zooming of a map application, but wasn't great for task switching. The demo video was actually a bit startling: the user leans forward and the map zooms in.

Nudge and Shove: Frequency Thresholding for Navigation in Direct Brain-Computer Interfaces

On the minus side, this presentation only presented something resembling experimental results for a few minutes at the end. On the plus side, out of the entire three-day conference, it was far and away the most intrinsically interesting subject, and the one most fundamentally appropriate to a conference about Computer-Human interface.

Melody Moore, a Ph.D. at Georgia Tech, claimed "We're the only team in the world approved by the FDA to implant sensors [of this type] in human brains." They have placed electrodes) into the brains of three subjects, all suffering from 'locked-in syndrome.' That is, they are a few of the 500,000 people worldwide who are essentially completely paralyzed, cannot live without continuous machine assistance, but are cognatively fully capable.

The best subject of the three has had electrodes in his brain for three years. One controls the X and the other the Y for a cursor. Glass capsules in thecortex communicate via FM with chips implanted in the scalp (outside the skull) and then to computers. He can move a cursor around the screen and type at 3 letters per minutes on a virtual keyboard (previously he used blinking to select letters - she didn't say what his speed was for that). Every time they experiment they ask him what he's thinking about while moving the cursor. One day, he said "nothing." This means that he controls the mouse with the same mental method that we use to move our own limbs. He has a "cursor cortex."

They are fully funded and approved for six more subjects and are looking for volunteers.

Second Session

I ended up skipping around, catching a half-hour each of three events, none of which really grabbed me. A workshop on Promoting Usability Practices within the Design Process was basic and boring. One useful bit: a list of other sources of usability defects

  • newsgroups
  • remote testing
  • product instrumentation
  • user group meetings
  • support/service
  • training
  • field reps
  • documentation writers
  • marketing

I caught a bit of something about animation, a prototype for combining Back, History, and Bookmark in one panel (good point: many users don't really understand how Back works. Browser back works on a stack model, not an absolute model, so it doesn't track branches, and this trips up users.), a vaguely interesting demonstration of a smartmoney.com feature where you draw a graph to query time-series data for best matches; and sat in the back for the end of The Impact of Mobile Technologies on Everyday Life (SMS hasn't taken off in this country because our teenagers already all have phones in their own rooms with free local calling, btw, and because the American pager network has been up and reliable for a long time). oh yeah, and "Text input is the fundamental problem" for mobile computing. I was pretty tired by this point.

Third Session

Information-Rich User Interfaces

this seemed promising but turned out to be fairly low-bandwidth (or I was just really tired) and I bailed partway through. Don't have "duh" help that just repeats text already on the screen. On the other hand, there's nothing so simple and easy that there's no meaningful help. For example, "First Name" - what if I have an umlaut in my first name? Examples are often the most useful, information-rich help. You can have data-sensitive help, such as "Your hard-drive is 50% full, ...." And also use-sensitive help, "You just hit six menu commands in the last 30 seconds. Perhaps you need help."

Information Scent

I missed most of this, but the bit I caught seemed promising, albeit strongly biased towards an academic perspective. Information scent is the amount by which a given page makes a user feel that they are getting closer to or further from what they're looking for. The idea is that you can somehow measure information scent (by hand, in these examples) and see how users follow it. Turns out (with the pretty nifty data and charts) that when information scent is poor, users jump to a lot of pages and go in circles. When it's strong, they zoom right towards what they want.

When scent falls below a threshold, users change something, either switching modes (such as to a search) or browsing from a different starting point.

Closing Speech

... was about universal access. A few good points:
  • Designing for universal access doesn't just mean designing for the handicapped. It includes compromised situations (noisy, like factory floor; distracting, like while driving; with one hand full; etc)
  • Frequently it's just not possible to serve everybody with one design. But don't give up on that before you've tried.
  • Many inventions (keyboard, ramps on curbs, forgot the others) were originally built for handicapped.
  • General population is getting older and older; universal access will only get more important.

More General Comments

While the conference body seemed to have gender parity (and participants from six continents), the various committees that went on stage to be applauded were still pretty unbalanced. And out of 3000 attendees, I counted less than ten black people.

It's pretty rare for usability to have true buy-in from management. I didn't see any real mention of continuous usability testing.

Categories: Comments (0)
by Joel Aufrecht 12:00 AM, 04 Apr 2001
Previously posted at http://joel.westside.com/default.view on April 4, 2001.

Overall, I'm enjoying the conference and think it's worth it. I keep bumping into the same people, some of whom I met at a dinner Monday for people on the CHI-WEB mailing list.

Assorted items

this may be the first computer-related event I've ever been to that had gender parity.

the IBM display didn't seem quite so amazing today. hmm.

Tried an eye-tracking system - camera below the monitor watches the eye to figure out where the pupil is pointing. It had some trouble with reflections from my glasses, and accuracy was iffy (within .5 inches at best; during text scanning it was a whole line off for much of the text). However, the reading pattern was extremely apparent in the plot of the X-axis movement: an obvious, repetitive stairstep as I scanned a word at a time, then ratcheted back to the next sentence. This pattern was apparent for two other people. The booth lady said that many stroke victims completely lack this pattern - their eyes simply don't know what to do. Also, kids with reading problems have obvious regression patterns - you can see where they go back and reread a word one or more times. There are now systems that can detect this and read the word out loud to the child. Like a parent .... *shudder* They've sold 250 to handicapped people and 50 to labs. Accuracy goes up when you can't move your head. I tried to use the eye-tracking keyboard and found it frustrating but doable - with training, practice, and quadraplegia, I probably could get fairly good. $18,000.

First event: Ethics in HCI

good panel discussion.

Existing ethics resources: ACM guidelines, American Psychological Society; medical guidelines. www.dialogdesign.dk/chi2001.htm has links.

Five situations were posed to the audience, with panel members arguing the two sides:

1) Studies show that, in order to develop, many types of communities need boundaries and exclusivity. Should you (the usability engineer) push for this functionality while building an online community system?
60% of the audience said no; 40% said yes. Audience comments: ethics are almost always situational, not absolute. In South Africa, there would be serious legal issues with an exclusion system.

2) Is it ok to overstate the severity of usability problems in order to get them fixed?
95% voted no.

3) Is it ok to condemn a site in an press interview based on opinion, not tested data? went 50/50 comments: immaturity and unprofessionalism are not necessarily unethical. argument: unprofessionalism is unethical. professional opinion carries weight and disclaimers are likely to be dropped by press.

4) You are usability testing a medical product which will be used by nurses. The nurse supervisors insist on 'taking the test' themselves first, and then observing while their nurses participate in order to 'make sure they do it right.' Should you proceed or not?
Yes argument: 1) the situation is already bad, so your test can't be responsible for making it worse. 2) you can manage the testing to compensate
No argument: 1) you have an overriding obligation to the participants (to not set them up to be abused) 2) the nature of the evaluation is clearly being misunderstood, so the situation is ambiguous 3) you will get bad data
95% voted No

5) The day before shipping, usability testing uncovers a potentially very serious (non-usability) defect. There are no showstopper usability problems. The next day, there is a go/no-go decision where all managers must agree to ship the product. If the product ships on time, all managers get a substantial cash bonus. Should you (the usability manager) agree to ship the product?
Yes argument: 1) the defect isn't a usability problem 2) it's better to ship anyway; why delay a product that many customers are waiting for due to a defect that won't affect most of them
No argument: no good notes
90% voted no

Closing comments

An alternative view to "adding shareholder value is the sole goal of a corporation" is that contribution to the public good is as or more important.
Ethical context is not constant over time - what was ethical at one point in time may not be later because standards change
Usability professionals (and presumably everyone) face ethical issues every day. for example, whenever writing a report on usability testing, you must decide what to include and exclude; what to emphasize. this will reflect personal biases.
legal comment: in a court of law, on a scale of one to one hundred, consent forms are worth about 15 points

Second event: Panel on Measuring Information Architecture

Five participants, all made positive contributions to the discussion. The presentations were all thought-provoking; everyone had a different opinion on what the panel was going to be about. I don't remember thinking that the discussion was a waste of time, but I don't have any real notes from it. Some time was wasted on 'what is information architecture?'

Jesse James Garrett, Adaptive Path

This presentation was off the mark: he was claiming to argue that the quality of Information Architecture isn't quantifiable, but was actually arguing that current machine measures of IA are unacceptably bad. And even that point is debatable in my opinion. He tried to make the point by creating a parody of website guidelines: what would a typical website guideline look like when applied to a textbook. (paraphrasing from memory) between 12 and 19 chapters, each between x and y pages, with a certain ratio of pictures to text, etc. His point was that this is ridiculous, but I actually disagree - I don't think that that kind of restriction for a textbook is silly at all. Or rather, it's a good starting point for anyone who doesn't know any better. Once you understand both the subject domain and the way your readers will use your textbook (comprehensive class, pick and choose, reference; undergrad, advanced researchers, practitioners) then you can break the rules. He also argued that the reason to quantify IA is to justify the work at all. I think this is a terrible point; you should quantify IA in order to find out if your current IA works or not, and to find out how to improve it, not to justify your profession. Mr Garrett clarifies: "I didn't argue this point. A questioner from the audience suggested it; I agreed that justifying the value of doing information architecture was important, but I felt quantification was not the best way of making this case."

The only points in his presentation that I liked were, The user's key question is, will clicking this link get me closer to what I want and Language, more than anything else, is the user's primary cue. I'm not sure I agree 100% with the second point, as location, format, page shape, and other factors can all overwhelm language, but it's worth arguing.
Fortunately, he was better in the panel discussion than in his misguided presentation.

Marti Hearst, Assistant Professor at School of Info Mgmt and Systems, Berkeley

"I believe most aspects of IA quality can be quantified, and that new tools are needed ...." She had a useful chart:

by Joel Aufrecht 12:00 AM, 07 Apr 2001
Previously posted at http://joel.westside.com/wsContentPublisher/story.view?RowId=11

Advanced Usability Testing

This was a full-day tutorial at the Seattle Center, put on by the Nielsen Norman Group as part of their User Experience World Tour. The instructor (who was excellent) was Rolf Molich, a principal in the Danish usability consulting company dialogdesign (dialogdesign.uk). The class was based in large part on the results of CUE-2, a study on the usability testing and reporting of nine professional and student teams who volunteered to participate. They tested Hotmail.com in late 1998, and CUE-2 compares their findings and methodology (http://www.dialogdesign.dk/cue.html). The class covered Evaluation Methods, Creating Test Tasks, Identifying and DDescribing Usability Problems, and Communication Results. There were about forty people; dunno how many were in the beginner class. My notes presented here are a random mishmash of observations, quotes, and paraphrases.

General notes

It's hard to compare usability methodology because many companies do not share methodology. Although Microsoft participated in CUE-2 (they own hotmail.com, the tested site), they abruptly stopped participating at some point after the study, and now clam up with "it's Microsoft policy not to discuss internal results of usability ...." Mr. Molich interpreted this as the lawyers finding out what was going on. I agree, but I don't think Microsoft (and other companies) are trying to hide their methodology as a competitive advantage. I think that they are reluctant to discuss it because either results or practices could turn into a PR disaster. I also think that this is a cowardly misguidedly conservative approach.

Heuristic evaluation will find less than half of the problemsThe personal opinions of usability professionals are not worth much. Even the professional opinions of the best are usually wrong. The only way to find out if Function X on Site Y is usable is to watch typical users try it. On the other hand, even a heuristic evaluation that finds only half the problems on a site is still finding a lot of problems, and is almost certainly cheaper than user testing.

CUE-2 Results

  • Nine teams found a total of 310 problems with hotmail.com.
  • Only one problem was critical - a confusing 'password hint' page
  • Most teams spent ~100 hours and used one person. (Teams included Sun, SGI, consultants, et al)
  • One team did a questionnaire of 50 users. This team found very few problems, and missed the most critical problem. Unattended usability test don't work. An unattended test is "participant carries out tasks without being observed, and reports problems found."
  • 75% of all problems were found by only one team.
  • No problems were found by all nine teams, or even eight. Only two problems out of 310 were found by as many as six teams.
  • Web usability results are non-reproducible. This may because most web sites are so bad that there are so many problems that no one test can even find the majority of the big ones.
  • Nobody can differentiate the student reports from the professional reports.

What's a usability problem

  • User error, user preference, user attitude, user comment.
  • (from http://www.ucc.ie/hfrg/resources/qfaq1.html) ISO 9241 standard, part 12, defines usability in terms of effectiveness, efficiency, and satisfaction.
  • break down related problems into 'smallest discrete problem,' a problem which can be fixed without affecting any other usability problem.
  • severity scale:

    • 0: (not in the tutorial - just my opinion) User abandons the site/product; or security hole
    • 1: Severe. User cannot complete a task. User completes a task incorrectly without noticing (either could be a zero if the consequences are catastrophic)
    • 2: Important. User is delayed or upset completing a task.
    • 3: Cosmetic. (My personal opinion is that if it's cosmetic, it's a normal bug, not a usability bug)

    Usability Tasks

    • Don't use system-oriented terminology like register. Don't use slang. Don't use humor (it isn't funny when you can't do it). Don't use personal references ('send mail to your mother' - instead use 'a friend').
    • Base tasks on user goals, not system features
    • Get rid of hidden clues. Hidden clues include exact vocabulary matches between tasks and web site labels; the mere fact that a task can be achieved with the product at hand. Use indirect tests when necessary.
    • To test something more realistic, use real loads: thousand-message inboxes, slow connections, etc.

    Performing the test

    • If a user has flailed for 8 minutes, they're not going to get it (this number is anecdotal, comes from apps testing, and may be too high)
    • (I asked the group how long a typical test went). Rolf proposed 10 min for prep, 60 min for testing, 20 min for debrief and asked for a show of hands of who was doing something significantly different. Nobody raised their hand.
    • Ask standard questions after each task for better results (people remember recent successes and discount the struggling once they succeed "I'm sure it would have been easier for someone else - it just took me a while to find it.")
    • Q: what about tester in room versus tester in other room? A: I always do tester in room for social reasons - it's more humane.
    • When doing a paper test, have a third person to manipulate the paper and "be the computer"
    • Prototypes should be cross-functional efforts (dev, design, graphic, et al)
    • some people take notes by computer instead of paper
    • Nobody had any suggestions on how to better integrate help testing. Useful comments: "Testing whether or not somebody uses help is different from testing where or net help is useful." "Better to check logs to see if anyone uses help."
    • Display tester limitations ("Sorry, I can't type that fast.") to make user more comfortable
    • tell user in advance that some tasks may not be possible. Then, set an impossible task very early in the test. This helps reset the user's mindset back to something more realistic, namely that in the real world, you don't know in advance if the product you are using can do the task you need.
    • Put a super-easy task first to make the user more comfortable
    • avoid tasks that build on each other. If the user cannot complete one, the others are harder and (even if you have a fallback rigged) more stressful.
    • Don't test your own baby as you won't be objective - very easy to insert your own bias at many points in the process.
    • Good phrases
      • "Here's what the designer intended. How could we make that clearer?"
      • "I must be stupid." "Everything I've seen you do makes perfect sense to me. It's just that this system isn't designed that way."
      • "Don't tell me, show me." (Tip 4: avoid user opinions.)
    • Bad phrases

      • "Yeah, we thought about that."
      • "Yeah, we tried that and it didn't work and here's why..."
      • "Lab," "Experiment," "Research," "Test Subject." Instead, "Usability Evaluation"
      • "I'll show you a good way to do that." Instead, "How should we change the interface to avoid the problems you had."
    • When you hint, you will help more than you intend. Some labs have a strict "no hints" policy and just move people on to the next task.
    • Discount Usability Testing Mr. Molich advocated this methodology. The idea is, "strive to optimize the cost/benefit ratio."
    • Should you videotape? In general, no, because analyzing results takes much too long. Instead, take notes while it happens. Ask the user to stop for a minute if a lot of stuff happens at once. You will miss things, but it's unlikely you'll miss anything important (if it's important, it will happen more than once). Reasons to videotape include: proving your results to people who don't think a user would actually say X. Emphasizing the consequence of usability problems.

    Testing with Advanced Users

    • When testing with advanced users, the user should provide the task whenever possible.
    • Have users bring typical tasks. "What are the last three things you did with this product?" "Can you defer your normal tasks for a few days and then do them here in the test?"

    Reporting

    • The users of a usability test are the developers. Make sure that the usability test and results are themselves usable.
    • Usual result of a usability test is a report: 8-12 pages, no more than 40 defects. Doesn't seem to be much iterative usability testing.
    • some people advocate tracking usability problems in the bug system
    • include severity for each issue.
    • Report should include: description of specific problem. Description of principle violated. Description of general problem, and notes on where dev/test should look for other instances of same problem.
    • Reports should have plenty of positive items - perhaps one positive item per problem. (N.B. In my opinion, this is a structural problem. Should a usability test produce a list of problems to fix, or a validation that the site enables users to accomplish their goals? This is analagous to the same problem in quality assurance/control: you must start by testing all the things that a program is supposed to be able to do, and marking (as bugs) where it cannot; then, you can go digging for bugs. So, how can you report results in terms of validation - "10 basic users tasks; most users can accomplish N tasks with avg time X and error rate Y." Mr. Molich suggested a color-coded results grid.)
    • The point of usability testing is to find and correct usability problems. Therefore, reporting is as important as testing.
    • Having developers observe tests is crucial. It will help developers think like users and thereby code more usable functions. Testing should be located somewhere convenient to developers, not to users or the tester. (Although I agree on a pragmatic level, I'm a little uncomfortable endorsing gratuitously developer-centric thinking.)
    • There was discussion of the KJ method and consensus-building among developers. I didn't take good notes because it isn't really relevant our continuous usability improvement process. (it's a way to sit down after a test and get everyone to agree what to fix)
    • Should problem descriptions include proposed solutions? Yes, because it helps developers and helps show that the reporter understood the problem. No, it short-circuits other possible solutions.
  • Differentiate between expert opinions, user opinions, and user findings.
  • Discuss the main findings immediately after the tests.

    Assorted notes

    • eye-tracking isn't necessary, because there's still more than enough low-hanging fruit - problems that can be found without eye-tracking
    • A typical test of a web site, from scratch, is ~US$5,000 - $10,000, 50-80 hours.
    • Beware of habits that produce data you never use
    • A useful error message always says what to do next.
    • You should be able to repeat an error message to the user's face.
    • videotape yourself to see how you do as a test manager
    • Have yourself tested by a usability consultant (coach) every two years
    • Controversial rule of thumb: "Five users can find 75% of all problems, and since you'll never be able to fix them all anyway, that's enough." Instead, "The first five users will probably find 75% of the problems for a particular task set for a particular version."
    • Tip #27: "Keep the number of participants low so that you are just as interested in your final participant as in the first participant."
    • Mr Molich's conclusion from CUE: Many of the problems are caused by lack of knowledge about elementary rules for usable design. More focus on prevention; less focus on testing.


     INDEX

  • Complexity of ContentHighCatalog (IA most useful here)Information system
    LowBrochureService Site
    LowHigh
    Complexity of Application

    (Mecca et al., ACM WebDB'99, http://www-rocq.inria.fr/~cluet/WEBDB/procwebdb99.html)

    She identified a number of components that have been labeled Information Architecture

    • Information Design: Categories and labels
    • Navigation: The paths through data
    • Graphic Design: The visual presentation of everything else
    • Interaction Architecture: The system (rules, metaphor) by which users interact with the computer (Not sure this was on her list, but I heard it elsewhere and it fits here)

    (Newman & Landay, DIS 2000, http://guir.berkeley.edu/pubs/)

    A major trend on the internet which massivly impacts IA: pages of content served from a database. This has a very positive consequence for IA: access can be instrumented. It's getting much easier to collect reams of data about exactly how people look for information, and about how successful they are looking for your information in your system. "We need to measure to learn what works and what doesn't."

    She riposted Garrett's parody of her team's webpage guidelines: "Measuring the surface properties can accurately predict how people rate web sites."

    Ms. Hearst adds, "More information on our empirical usability assessment work can be found at http://webtango.berkeley.edu. Thanks! Marti "

    Nick Ragouzis, consultant (Interfacility)

    Lazily hyperkinetic and demanded complete attention to keep up, but clearly a member of that rare species, "non-bogus consultant." Disclaimer: Ragouzis used language very precisely and accurately, and I'm probably butchering not just his prose but his actual points, since my notes are fairly low-fidelity and don't catch when he was being sarcastic to make a point, etc.

    Paraphrase from his written statement: Practitioners of HCI are utterly ignorant of research. But "over decades, without a credible basis for defining or measuring the whole or human experience, they have garnered an astounding quantity of success. ... requires only the ability to innovate ... and to deliver user-perceptible value. ... Abandon quantification, and may the fittest win."

    "[IA] isn't a research domain, it's an applied domain. ... IA isn't intrinsically valuable. IA quality improvements are verifiable only via customers' perceived value. What is your strategy: differentiate yourself from your rivals, show affinities with your partners; enjoy the competitive power of a well-positioned follower; sustained rate of growth relative to rivals.

    What does a plan to achieve mediocrity look like? Maintain parity; do what 90% of the competition does; follow the de facto standards; follow the "X will address 75% of users" recommendations; get improved conversion rates upon launch.

    Shiraz Cupala, Microsoft (managed Office web site)

    This guy was so caffienated he made Ragouzis look sleepy. He advocated tying traditional IA metrics to standard business metrics.

    IA measures
    QuantitativeQualitative
    Task Success Rate
    Time on Task
    # of categories, labels
    Satisfaction
    Frustration
    confusion

    for-profit goal: sell products. Metrics: Revenue, referrals, subscriptions, brand loyalty

    non-profit goal: spread knowledge. Metrics: memberships, subscriptions, registrations, cross-links/references

    Now we can do surgical tracking. Here are results for Front Page 98:

    • Millions of promotional items
    • ~100,000 views of information page on microsoft.com
    • ~10,000 views of registration page
    • ~2,500 downloads of evaluation copy

    After removeing the registration requirement, and shortening the info page, got +10% downloads. However, lost a lot of email addresses (which could be used to [spam] notify people when release version was ready); calculated that overall, would get 2-4x more revenue with fewer email addresses vs more anonymous downloads. of course, the cost of experimenting, measuring, and figuring all this out could be greater that the delta in revenue.

    The way to measure information architecture quality is to perform surgical tracking to determine if changes in IA improve business-goal-oriented metrics.

    Gary Marchionini, Professor, School of Info. and Library Science, UNC

    "I do believe we can measure the usability and effectiveness of a design for very fine-grained characteristics such as number of clicks to task, mouse-travel distance, ... I am skeptical that we can have a standardized overall measure of IA effectiveness.

    We can take some fine-grained measurements, for some criteria, for some tasks, for some people, at some point in time. For example, path length, vocabulary, reading level; and post-hoc aggregate data such as hits and referring links.

    Overall, IA quality is qualitative. We can measure a few discrete acts, such as retrieve/buy/print/verify, because they have clear progress indicators and stopping points. We can't measure things like Explore/Browse/Learn/Read, because they don't have clear progress indicators or stopping points; they are continuous acts.

    Q & A

    Why are we still talking about this, when IA is already a well-understood discipline? Because we stopped treating users as computers and started treating them as people.

    How to test large site IA before building a site? Exploratory methods don't scale. Two first things when building a new web site? What do users want? What does the site owner want from users?. Usability is cyclical; IA is ongoing; entire org should do both. Usability has artifacts and checkpoints. Can't test IA in abstract; need examples. relationship between db design and IA? db is an implementation issue which doesn't/shouldn't directly address user needs.

    Third event: Short talks on Interaction Techniques

    A French researcher made a fairly incomprehensible and somewhat desultory argument that Fitts' law (Fitts' law essentially says that, when moving things (objects, mouse pointer, finger) from one point to another, the time it takes to do so accurately goes up (I think) exponentially with distance and target size.) is wrong. something about relative vs absolute measures. Each slide made sense but it didn't add up to a coherent point.

    A common rule of thumb is that computers must react in <100 milliseconds in order for users to perceive response as instantaneous. A researcher at (somewhere in the Midwest) tested this for five common tasks (pulldown menu, buttons, typing text). They found that, to a good degree of confidence, half of all users (23 person sample size) consider <190 msec to be instantaneous for buttons/menus, and <150 msec for text entry. However, you probably need to aim for <80 msec (more research to pin this down) or some sizable fraction of users will still detect delay.

    It's very hard for computers to measure error in text entry, because of extra characters, transposition errors, etc, that make direct string comparison useless. Also, users want to correct as they go. York University researchers applied the Levenshtein (think Gene Wilder) String Difference, which was originally developed to measure errors in genetic transcription. They reprocessed some data that had taken someone a day to measure manually, and found that results seemed to match. This talk was interesting but seemed somewhat chintzy to me as they hadn't done any actual experimentation, just fiddled with other people's data.

    IBM researchers presented data on how to set up tap keyboards for efficiency. A blend of alphabetical and efficient design was almost as good for (theoretical - they didn't actually train anyone) trained users (41 WPM predicted vs 42 for purely efficient) and was somewhat easier to learn and faster for novices. In the course of a fifteen-minute test, users (sample size of 12) went from 8 to 9.5 WPM for the most efficient keyboard and 9 to 10.2 for the semi-alphabetical keyboard.

    Problems with head-mounted HUD:
    Binocular rivalry. If one eye sees a terminator-style display and the other normally, the brain will alternate between the two at random, unpredictable intervals, producing a patchwork image.
    A transparent display (text in the foreground, reality in the background) produces visual interference.

    Experiments showed a 37% difference in ability to read and work between best case (standing near a blank wall) and worst case (tv screen in background)

    Last event: SIG on Socially Adept Technologies

    Some researchers from Canada are trying to start up some sort of interest group within CHI for Socially Adept Technologies, an umbrella definition for systems that adapt to social context, situations, emotions, personality. Example applications: computers that make small talk to build trust with users. Computers that feign emotion to make users more comfortable.
    Issues:

    what are the ethical boundaries? Should a computer pretending to be human require a disclaimer? If the user figures it out, they are pissed (research shows). If the user doesn't figure it out, are they harmed?

    Anecdote suggests it is possible to reliably tell if a user is introverted or extroverted based on a 200-word speech sample. (aside: other studies clearly show that users react better to computers that display the same behavior pattern as the user)

    "Someone's going to do this. It should be us, since we'll do it ethically and openly."

    It's generally accepted that people react to anything that displays intelligence (and even to plenty of objects that don't) as if it had human characteristics. Therefore, socially adept concepts won't go away if ignored.

    What is socially adept technology? Is it a set of guidelines for usability design (such as, computer should not do things that would be rude if a human did them)? Is it active technology, such as profiling users on the fly and changing dialog text and behavior to compensate?

    We should study this because it will illuminate human-human interaction issues from a new angle.

    Computers can respect social expectations without behaving like a person.

    Studies show: users behave as if a computer's time is worthless. A computer's apology is worthless. A computer's sympathy is worthless. A computer's empathy may not be worthless.

    Categories: Comments (0)
    XML

    Joel's Blog Categories

    China (2 items)
    Denmark (22)
    Danish (11)
    Commentary (55)
    Quotation (129)
    War (22)
    Singapore (223)
    Public Finance (21)
    Institutional Analysis (15)
    Brain (5)
    Managing the Public Sector (15)
    Global Issues and Institutions (20)
    Non-State Actors in Governance (17)
    Leadership and Dynamics of Communication (12)
    Good News (92)
    Reviews (51)
    Baseball (30)
    Policy Analysis and Programme Evaluation (10)
    Urban Transport Policy (1)

    Actions

    Add entry
    Draft entries

    Archive

    April 2001
    S M T W T F S
    4  5  7 
    10  11  12  13  14 
    15  16  17  18  19  20  21 
    22  23  24  25  26  27  28 
    29  30           
    August 2008
    July 2008
    June 2008
    May 2008
    April 2008
    March 2008
    February 2008
    January 2008
    December 2007
    November 2007
    October 2007
    September 2007
    August 2007
    July 2007
    June 2007
    May 2007
    April 2007
    March 2007
    February 2007
    January 2007
    December 2006
    November 2006
    October 2006
    September 2006
    August 2006
    July 2006
    June 2006
    May 2006
    April 2006
    March 2006
    February 2006
    January 2006
    December 2005
    November 2005
    October 2005
    September 2005
    August 2005
    July 2005
    June 2005
    May 2005
    April 2005
    March 2005
    February 2005
    January 2005
    December 2004
    November 2004
    October 2004
    September 2004
    August 2004
    July 2004
    June 2004
    May 2004
    April 2004
    March 2004
    February 2004
    January 2004
    December 2003
    November 2003
    October 2003
    September 2003
    August 2003
    July 2003
    June 2003
    May 2003
    April 2003
    March 2003
    February 2003
    January 2003
    April 2001

    Notifications

    You may request notification for Joel's Blog.

    Syndication Feed

    XML

    Recent Comments

    1. Joel Aufrecht: from a senior roboticist
    2. Jeff Davis: Source?
    3. Kathryn Schild: quick question
    4. Tai Yan Lim: Trip Back Home - Joel
    5. José Rodrigues: Hello
    6. Guan Yang:
    7. Erika Graffunder: Canada
    8. Erika Graffunder: Per capita emissions
    9. Erika Graffunder: Policy - should you keep evaluating or focus on solutions
    10. Erika Graffunder: Ch 3