Editing Transaction costs/Brainstorming

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.

* 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.

* 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.

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.

* 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., [http://digg.com Digg] or [http://reddit.com Reddit]). [http://slashdot.org Slashdot] 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.

* 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.

* 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.

* 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.

* 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.

* 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?

[http://www.instructables.com Instructables] is a website where users can upload photographs and instructuctions to help build devices or items or to do a particular task.

* 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 ===

* distributed proofreading

* different tools have been created and introduced which improve people's ability to contribute and speed things up.

=== Social Networking Sites ===

* possibly there are interesting barriers to contribution but things are complicated by the network effect that makes certain contributions more valuable with time

[http://www.kaltura.com Kaltura] is a online video editing and sharing website.

* 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 ===

* 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 ===

* 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 ===

* 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

* also, the fact that the resource is increasingly large makes

Flickr:

=== FOSS: Documentation ===

* 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 ===

* there seems to be a trend from PO files w/ CVS toward new system including web interfaces, Rosetta, and new centralized systems.