Transaction costs/Brainstorming
- format rst
General Thoughts
=====
- There is an important distinction between contributions that are simply giving something to a community and something that is creating something and giving it to a community.
- Small transaction costs play a more important role in deterring small
contributions than large ones.
- Up-front or visible costs are more likely to deter contributions than
costs only visible after the contributor has made a significant investment of work. A CAPTCHA shown after a wiki edit will deter less contributions than a CAPTCHA shown before a contribution.
- Since many projects work as communities, barriers to an initial
investment are of primary importance because participation in a community creates additional incentive to contribution.
- Many communities want to increase transaction costs to contribution --
especially initial activation costs -- as a way of avoiding low quality contributions from less skilled or dedicated contributors.
Example Communities, Projects, or Contexts
=================================
Wiki Contributions: WYSIWYG Editing
The success of wikis is, in part, credited to a lowering of the transaction costs associated with contributing to a website. Part of this is in terms of the lack of authentication prior to contribution -- even in situation where the are pseudononymous logins -- and a default, immediate, live status for all contributions.
Another important aspect of wikis lowered costs is the fact that changing or adding to a wiki is done by editing "wikitext" which, for many new users, is easier than editing HTML. "What You See is What You Get" (WYSIWYG) editing is the ability to edit wikis using a more familiar word processor-style WYSIWYG interface. Since this interface is more familiar to most users, the initial contributions is easier for many users. Since users do not need to check or preview their work to ensure that rendering is appropriate and expected, general costs are lower.
General thoughts:
- There is large wikimedia community discussion about WYSIWYG editing nd
its value in lowering the start-up costs and necessary knowledge to contribution on a wiki -- most particants seem to assume this is a godo thing.
- There should be good evidence on the impact of WYSIWYG editors into
wikis from existing wikis with published information. I would assume that we see an increase in contributions -- especially from anonymous users and especially in the form of small edits.
- It seems possible that certain types of contributions are more likely
by people using WYSIWYG editors and their effect will be uneven. Certain types of contributions (e.g., contributions from experiened users or perhaps larger contributions) will be less likely to be deterred by the use of WYSIWYG.
- Certain types of contributions (e.g., templates) do not have support
in WYSIWYG editors. I would not expect to see an increase in these types of contributions from a WYSIWYG editor.
Related thoughts:
- The choice of markup language might have an impact on contributions --
some markup languages are probably more difficult and have higher costs associated with them than others. The choice of a particular and easy type of markup may make things easier or more difficult for users.
- Additionally, the presense of documentation on edit screens may
increase the likelihood of contributions from anonymous uses. Alternatively, it might simply increase the number of incorrect contributions from users who make mistakes. Potentially that could be followed by additional contributions to fix them.
Since one poor contribution might imply additional contributions, the raw number might be hard to measure.
Wiki Contributions: Per-Section Editing
There's been a huge amount of effort in the Mediawiki community that has gone into creating and tweaking per-section editing. Most wikis provide a simple edit button that allows users to edit just one page. Per section editing lowers the cost by placing edits buttons throughout the page and letting users edit only a subsection of the page. This reduces the costs associated with finding the edit buttons and then with finding the correct location to make the change in the resulting wikitext.
General thoughts:
- The per-edit reduction in cost is not going to be constant. Some edits
(e.g., edits in small pages) are likely to be as easy with per-section editing.
- There's been a lot of experimentation with different placement of edit
buttons on both Wikimedia wikis and in a variety of other places and there is probably good data that can be taken. Different placement of buttons may have different costs associated with it.
- Logged-in users use different skins which change or override the
placement of these buttons. This is probably small and should be detectable.
- The cost is in usability. To determine and quantify the cost, we'd
need to run a usability study but this could probably be done.
- An experiment could be run by that employed different skins that place edit
buttons in different places and then watch how contributions happen or do not happen. However, comparing different articles seems slightly risky and the edit count for any particular article is going to be different. Perhaps on aggregate this could work.
Rating of Comments/Stories
Some of the earlier forms of user contribution to website was in the form of rating and moderation information. This can come in several forms including binary raiting ("good" or no comment) or in up or down ratings (e.g., `Digg <http://digg.com>`__ or `Reddit <http://reddit.com>`__). `Slashdot <http://slashdot.org>`__ style rating asks users to rate contributions from other users by raiting them on a scale of -1 to +5 and giving the option of attaching a multiple-choice justification. Other forms of rating (e.g., eBay style feedback) may give simple users the ability to give simple (e.g., 1 line) free-form feedback or longer form feedback.
These different methods have higher and lower usability costs associated with them. It is extremely easy to click a button and more difficult to select something form a list.
One could run an experiment that swapped in different methods of making an identical contribution on a site that already practices raiting (e.g., selecting a score between one and five) with different usability costs associated. I would expect to see an increase in the modes that were easier (one click) over methods that required two or three clicks.
General thoughts:
- Different stories or comments might elicit more or less feedback.
Ideally, this would need to be run in parallel so users were asked to rate identical content in different ways.
- Again, this falls back into usability space which has the potential to
be "fuzzy" in that it has different effects on different groups of users. Perhaps, because the action is so small, this effect is minimized compared to some of the other wiki examples.
- Contribution in this case be tightly controlled so that each
contribution is of exactly the same size (e.g., one rating point). The effect of even small transaction costs would be large because the size of the transaction cost is large next to the size of the contribution. It would be very hard to measure the effect of these on similar larger contributions.
- Since the effect that contribution might be higher or lower depending
on the number of other contributors (people might be more interested in rating a comment that was previously unrated), this should be controlled for.
- A very simple model might include: a select box where users select
something. a Reddit/Digg style button, a text box wen people enter, etc. The cost (in time) of each of these methods would be counted in a usability study or based on the number of clicks necessary to make a contribution.
- It should be clear to users what the cost are up-front.
Wiki Contributions: Mandatory Logins
Several wikis have been open to contributions and then moved, either for selected articles or as a whole wiki, to requiring login information. In many situation, this login information is pseudonymous -- users do not need to give any personal information. The effect is that login becomes a simple cost.
General thoughts:
- The cost associated with logins may not apply equally to all users of
wikis. The fact that logins are pseudonymous is not successfully communicated to all logins and is communicated to almost no users before they go the create user page. Not all users will be as comfortable creating a login for a variety of reasons.
- The best way to look at this would be to examine wikis that started
out open and then instituted a login requirement at some point in the wikis life.
Additional options:
- Another related option would be to compare the effect of logins that
require email confirmation with those that do not. I would be assuming, as I think is probably safe, that the vast majority of people editing can also recieve email.
CAPTCHAs
CAPTCHAs are an common transaction cost associated with contributing to wikis, forums, or blog comments. They come in a variety of forms. The most common is an image-based CAPTCHA where contributors are asked to decode an image of distorted text. CAPTHCAs are very simple "Turing Tests" which are designed to allow a piece of computer software to distinguish between a human user and a script. They exist to block automated spam of wikis, websites that allow contents, and other forms of user generated content.
General thoughts:
- CAPTCHAs provide a simple cost that will, given a particular CAPTCHA,
be roughly equivalent.
- CAPTCHAs do not present a cost that is equal to all users
(e.g., blind people find CAPTCHAs completely impossible since they cannot see the images).
- My sense is that CAPTCHAs more difficult is likely to increase the
likelihood that a user will fail the CAPTCHA but unlikely to make it take much more time.
- CAPTCHAs, at least as they are frequently employed, provide a
post-facto cost to most users. Users will usually invest in their comment or wiki page before they even consider the CAPTCHA or know that they are installed.
- A user could be asked to solve a series of CAPTCHAs or could fail one
CAPTCHA (intentionally) or be given an ambiguous CAPTCHA and asked to solve more. This could happen before a contribution. Many users might give up and decide that it was not worth the contribution. However, if CAPTCHAs were obviously impossible, users might become frusterated. If CAPTCHAs were not ambiguous enough, users might assume the system was broken for not accepting known correct answers and give up for that
- Use of such a comment in blog comments would be tricky because people
may be more or less likely to comment on a particular article or issue if it is more interesting. If use on blogs were to be done, it would have to done on a large sample of different blogs over a period of time and would not be connected to a the work of particular posts or particular authors. Using it multiple times on a single article seems suspect because a single blog post is unlikely to get a very large number of comments.
Page Loading Times
Page loading times, including slow times, are a common cost in time associated with contributing to many web-based systems. Delays of other types may be common in other communities.
General thoughts:
- one could create a wiki that takes a variable about of time to "load"
the page for edits. this would be reasonably straight forward and would certainly deter people from contributing
- on caveat is that after a certain period of time (maybe 30 seconds),
people will be likely to conclude that something is broken
- one effect might be reduced contribution over time. the contribution
times should be slow enough that people will not assume things are broken but likely that they will not want to contribute
- what if a warning sign warned people of the cost up-front?
- might people simply choose to defer?
Instructables, etc.
`Instructables <http://www.instructables.com>`__ is a website where users can upload photographs and instructuctions to help build devices or items or to do a particular task.
Similar projects including WikiHow and Appropropedia.
General thoughts:
- people are going to do the innovation or contribution in any case.
the important question (determined by transaction costs) is whether or not they are going to give back to the community)
- people don't usually create something so that they can put it on
instructables. they create something because they need it and then decide to share it or reveal it completely voluntarily
- this has interesting parallels to free software communities
Project Gutenberg
General thoughts:
- distributed proofreading
- different tools have been created and introduced which improve
people's ability to contribute and speed things up.
- there have been a series of important process modifications
Social Networking Sites
General thoughts:
- possibly there are interesting barriers to contribution but things
are complicated by the network effect that makes certain contributions more valuable with time
- to balance the above, one would need map growth and take it into
account when looking at the effect of a reduction in a cost to either joining or participating in the network
Kaltura
`Kaltura <http://www.kaltura.com>`__ is a online video editing and sharing website.
General thoughts:
- the basic idea behind the site seems to support the idea: kaltura
reduced the cost of creating and editing video from existing videos and to sharing these with others. the result is that many more people are creating and sharing.
- it's not clear that this is really a more open, distributed
contribution community yet
FOSS: Bug Reports
General thoughts:
- submitting bug reports to free software projects can be either more
or less difficult depending a series of factors including the choice of tools, the nature of the questions asked, etc.
- this generally seems to support the idea that lowered costs improve
contributions because groups have specifically built costs into certain tools with the goal of reducing the number of bug reports or limiting them to those with a certain set of skills.
Open GIS and OpenStreetMap
General thoughts:
- there are several different ways of contributing to OpenStreetMap.
- participants say they want more difficult tools because it restricts
contributions to more technical users who are likely to produce high quality data
- participants say that they want the costs to making different types
of contributions to be easier or more difficult and use usability as a sort of knob to turn up or down in order to blog contributions
FOSS: Patch Contribution
General thoughts:
- costs associated with contributing a patch to a free software project
include access to source code: Karl Fogel says that anonymous CVS is one of the most important innovations for free software.
however, this did not make free software accessible, although it reduced the costs to viewing and making an initial investment
Photo Sharing and Photo Collection Building
- contributions to commons (mostly in the form of uploading
photographs) has become more difficult in that contributors are now asked to provide an increasingly large amount of metadata
- however, i don't see there as being a real move toward keeping out
these contributions
- perhaps, these barriers are post-facto (you've already taken the
picture and even already uploaded it before you are asked to provide extra information)
- also, the fact that the resource is increasingly large makes
contributions to common seem increasing valuable to potential
Flickr
- the marginal cost on making certain contributions increases the likelihood of contribution. people who switch to mass uploader tools (is this marked somewhere?) probably upload more since the cost of uploading a picture is reduced -- probably not tied into usability
contributors
FOSS: Documentation
General thoughts:
- a wholes series of projects have moved from cvs style models into
wikis lowering the costs to many users. of course, much of those costs is learning something new (not having to learn something new makes accepting contributions from a larger group much easier)
FOSS: Software Translation
General thoughts:
- there seems to be a trend from PO files w/ CVS toward new system
including web interfaces, Rosetta, and new centralized systems.
- again, the variable cost is usability and, again, familiarity with
the cost is rough
Other Potential Areas
===========
- contributions on forums (many of the same costs as wikis) - contribution on a mailing list - answering questions in Launchpad? - participating in a QA site - writing a review/opinion on an item online
