 |
« | Week of Oct 19 | < | Individual Entries | > | Week of Nov 2 | » |  |
 |
 |
Why Trusting Pretty Web Sites Is Rational
internet, society & sociology
November 01, 2003, 10:41 PM
Paul gave a lecture in CSCW yesterday on the topic of economic analyses of reputation systems. One of the points he discussed relates to an earlier post of mine on how people judge the trustworthiness of web sites. The upshot of that post was that the quality of the site that was most relevant to its perceived trustworthiness was how pretty it looks, that this is bad, and people are dumb (implied).
Turns out that conclusion is wrong. Paul presented an economic analysis that explains why a rational, self-interested actor should choose to pay attention to things like the visual appearance of a site. The argument goes like this:
- Imagine a marketplace which, like most marketplaces, has some number of high-trustworthy sellers and some number of low-trustworthy sellers. Imagine you are a buyer. You have to decide who you are going to buy from, but you don't know, a priori, which sellers are which.
- Consider the position of the sellers. Both types of sellers have some interest in sending signals to buyers that they are a professional, trustworthy organization that deserves your business. These signals may include trust-focused advertising campaigns and/or spiffing up their website design.
- The high-trustworthy sellers know that any money they invest in sending these signals will attract customers who will be satisfied with their transaction and will continue to be customers of the business. Thus, they invest a good deal of money into making their website attractive.
- The low-trustworthy sellers know that money they invest will only have a limited return, since they can't scam you forever (eventually you'll find out that they are violating your trust) and then they will lose your business. So they will not invest as much money in making their website spiffy, since the rate of return for them is lower than it is for the high-trustworthy sellers, and thus the market is against them.
- So as a buyer, you have reason to believe that a site with a spiffy visual design is trustworthy, since high-trustworthy organizations have a greater interest in spending their money on such pursuits. Therefore, it is perfectly rational to associate an attractive visual design with trustworthiness (even though it is hardly a strict guarantee).
Of course, as several people pointed out in class, this "ideal" model doesn't hold true in all markets. For instance, this model assumes that it's easy for a buyer to end a relationship with a seller as soon as he realizes the seller is untrustworthy. But this isn't always the case; for instance, in apartment rental markets, buyers must generally sign year-long leases that commit them to staying with the same landlord even if the landlord reneges on his responsibilities. And even after that year is up, the expenses of moving may keep many tenants in situations they otherwise wouldn't accept had they known before they moved in. So, like any general economic analysis, you have to think about which conditions it will hold under and which conditions it will not.
Still, it's an interesting counterpoint to my more cynical earlier comments.
OK/Cancel on Focus Groups
usability
October 31, 2003, 03:54 PM
Today's OK/Cancel comic has some nice discussion from Kevin and Tom about the benefits and problems with focus groups.
At first, I wasn't too fond of OK/Cancel. The art is nice but I rarely find the comics fall-down funny. But I'm really liking how they use the comic as a point of departure into interesting discussions about important usability issues. So, with that in mind, I'm ready to throw in my 0.02$ and recommend that you read their excellent site.
It'd be nice to see some other usability / interaction design / user-centered design oriented webcomics, though. I'm thinking something Dilbertesque that pokes fun at management and programmers (although maybe that would hurt my touchy-feely, lets-bring-all-the-disciplines-together movements :).
Posted by KC on November 01, 2003 at 08:37 PM
Thanks for the link Rob. We definitely have some of the stuff you mentioned in store but we're also torn on the whole touchy feely movement. You saw how outraged the misunderstood developers were in "Kicking the Llama" and that was a milk jab at best. Believe me, we have enough in our repertoire to go full on.
Another part of me is fighting to not make the dumb manager who doesn't understand HCI too common because it reeks of cloning Dilbert. I would love any discussions and ideas you might have for strips tho. Shoot me an e-mail sometime.
Email Rob:
The Open Source and Usability Problem
software development, usability
October 31, 2003, 01:56 PM
As regular readers are aware, for the past few months I've been working on the problem of bringing improved usability techniques and practices to open source software. Since the beginning of the project, my perspective on the problem has changed quite a bit, so I wanted to record where I stand now.
When I initially confronted this problem, I mostly considered it a problem of selling standard user-centered design practices to the open source community. But as I explored the problem more fully, I started trying to bring what's unique about open source (community involvement in the software development process) into user-centered design. That's opened up a whole new can of worms.
From my current perspective, here's the open problems that need to be addressed to fulfill the vision of an open source community that produces truly usable software:
- Collecting data collectively - Both in the user research stage and the user testing stage, members of the community must go out into the world to examine user behavior. This research may feed into persona development, contextual design models, usability-related change requests, etc., which are then (hopefully) used to guide design. There are lots of issues relating to how to encourage people to contribute this data, how they will collect it with potentially no budget, how you know you can trust their data, etc.
- Collaborative, remote design - Interface and interaction design require a high degree of collaboration and is an inherently highly visual process, unlike programming. These qualities make it difficult for effective design to occur over the text-based and often asynchronous remote communication mediums preferred by most open source projects. What changes need to be made to effectively support design, both in tools and processes? Moreover, effective design requires involving team members who have training in design and usability. What skills are required and how will these new skills be brought into the community?
- Selling user-centered design to open-source communities - Many open source communities don't see the need for user-centered design. These communities need to be sold on the concept of UCD as well as the particular process and technology changes necessary to bring it about.
- Selling open source to designers and usability professionals - This same sales pitch has to be made the opposite way. Very few designers and usability professionals participate in open source nowadays, for some good reasons. We must make people with these skill sets more aware of open source opportunities, convince them that its worth participating, and show them that their participation will be valued.
- Connecting people with skills to projects that need those skills - This is a problem that exists in some open source projects even without the usability aspect. If a team finds they don't have the necessary skills to build a particular part of the system, how do they connect with people who have these skills? This calls for an open source "job market". I believe this has been tried before, but I can't remember where I saw it.
- Incentives for usability professionals to contribute evaluations - With open source programming, there are direct incentives for participation, since you work has a direct impact on the quality of the project. With usability, benefits may be less tangible and thus more thought may be needed to provide the necessary incentives.
- Incentives for developers to address usability issues - Developers often work on open source projects to enhance their skills with technologies and to add features they personally find useful ("scratch an itch"). But neither of these incentives would necessarily lead them to implement features that help improve learnability of the product for novices, for example. How can we convince developers to work on issues they don't personally care about?
- Providing mechanisms for feedback to the team on usability problems - To encourage greater user involvement with the development process, open source projects may be able to leverage mechanisms for allowing users to report usability problems while using the software system. How can we provide for this interaction without burdening the users, and how can we convince developers that the data is useful and must guide design?
I've been toying with the idea of applying to a PhD program to work on this problem, since I'm realizing that tackling even one of these issues may take years. The jury is still out on that thought, however.
Email Rob:
The Glider and Design
design
October 29, 2003, 11:00 PM
Eric Raymond has proposed an emblem to represent hacker culture:
The image depicts the "Glider" pattern from the Game of Life. The glider is notable because it is the simplest pattern that moves.
I'm not thrilled with the idea of a "hacker emblem", but perhaps that's just because I don't particularly identify myself with the hacker culture. I like the logo, though, because of the glider's effectiveness and elegant simplicity. It's a nice visual representation of the concept of minimalist design, or "the simplest thing that could possibly work" (often invoked in the form of the KISS principle). I don't know about everyone else, but I often have problems following this directive, so keeping its representation around as a reminder strikes me as a good idea.
Email Rob:
Online Community Currency Analysis
internet, society & sociology
October 29, 2003, 09:42 AM
The ever-insightful localroger has an article on K5 analyzing comment moderation system currencies (like Slashdot's Karma and K5's Mojo) and providing some design recommendations for improving these virtual economies.
Although I'm filing this under Meta it is not a specific suggestion for immediate changes to Scoop. Rather, it is a set of ideas I've been mulling over based on what e-community engines like Scoop, Slashcode, and various web BBS packages are all trying to become, and how the next generation might do it even more effectively.Whether you call it Mojo, Karma, "Standing," or something else, all content rating feedback systems have some sort of currency. While there are many different ways of acquiring and spending such capital, nobody seems to have implemented an economy varied enough to be robust. And this is the key to building a system which can be stable in the long term.
Some of Roger's ideas seem good and others need work, but he's on the right track. We should be doing more of these comparative analyses and reasoning about the effects of community features on the social structures they're supposed to be supporting.
Analyzing Roger's ideas using the social science design principles we're developing in CSCW is left as an exercise for the reader.
Email Rob:
Email Rob: