Just updated my CouchDB install guide as I discovered a problem with the install. Mostly my own fault for not checking the testsuite immediately after I installed but when I came to do that today, after discovering that none of my views worked, and even a temporary view was causing the CPU load on the VM to shoot up, I found that the testsuite wouldn’t run at all and would just lock up the page with high VM CPU load. I found the solution via serverfault under the title “CouchDB 0.11 on Ubuntu 10.04”

So, the solution is basically to shutdown CouchDB, put you  version of xulrunner-devel on your LD_LIBRARY_PATH as follows:

• $ sudo touch /etc/ld.so.conf.d/couchdb.conf
• $ sudo cat > /etc/ld.so.conf.d/couchdb.conf
• /usr/lib/xulrunner-devel-1.9.2.6 (NB. Check the version that you have installed!)
• <CTRL-D>
• $ sudo ldconfig

Now restart CouchDB and run that darn test suite!

Whilst I am on the subject of CouchApps, there is a typo in code listing 10-4 on page 171 of Beginning CouchDB which causes the javascript to not work. Specifically, if you get a message along the following lines in your browser’s error console:

$.CouchApp is not a function

You can fix this by  making an edit at the bottom of listing 10-4, in the last <script> line it should read:

<script src="vendor/couchapp/jquery.couch.app.js"></script>

instead of:

<script src="vendor/couchapp/jquery.couchapp.js"></script>

Notice the missing period between couch and app? Enough to stump a beginner for hours!

Addendum #1 – A missing $ in listing 10-6 for main.js on page 176 in the parseInt line:

var task_count = parseInt('#task_count span').html(), 10);

should be:

var task_count = parseInt($('#task_count span').html(), 10);

Well this was more effort than it should have been. I have been dabbling with Erlang for a while, and after struggling with MySQL, Tomcat and JDBC I was looking for an alternative web-app stack. CouchDB looks to be perfect, although sufficiently new that there is not a lot of documentation, both of the books available right now are OK, but not brilliant. In general I prefer the style of CouchDB: The Definitive Guide but prefer the examples from Beginning CouchDB. My personal preference with programming and software tool books is that they should provide detailed, hand-held, speak-to-me-like-I-am-an-imbecile walk-throughs of the most common basic use cases.

Anyhow, CouchApp looks like a great way to develop apps for CouchDB, although documentation is fairly sparse. The main problem I found is that the versions of Erlang and CouchDB available from repositories for both Ubuntu and Debian are way behind the cutting edge to the point that the examples in the books won’t run. I found that the best way to set up my CouchApp development environment is to completely avoid the repositories and build from source in a clean Ubuntu server VM using the following steps:

• $ apt-get update
• $ apt-get clean
• $ apt-get upgrade

We are going to be building some software so the following tools are useful:

• $ sudo apt-get install build-essential subversion git-core openssh-server

Install Erlang

• $ sudo apt-get build-dep erlang
• $ sudo apt-get install sun-java6-jdk
• $ wget http://www.erlang.org/download/otp_src_R14A.tar.gz
• $ tar zxvf otp_src_R14A.tar.gz
• $ cd otp_src_R14A
• $ ./configure
• $ make && sudo make install

Install CouchDB

• $ sudo apt-get build-dep couchdb
• $ sudo apt-get install xulrunner-dev libicu-dev libcurl4-gnutls-dev libtool
• $ wget http://mirrors.ukfast.co.uk/sites/ftp.apache.org/couchdb/1.0.0/apache-couchdb-1.0.0.tar.gz
• $ tar zxvf apache-couchdb-1.0.0.tar.gz
• $ cd apache-couchdb-1.0.0
• $ ./configure
• $ ./configure –with-js-lib=/usr/lib/xulrunner-devel-1.9.2.3/lib –with-js-include=/usr/lib/xulrunner-devel-1.9.2.3/include
• $ make CouchDB
• $make
• $sudo make install

Final Setup & Running CouchDB

• $ adduser –system –home /usr/local/var/lib/couchdb –no-create-home –shell /bin/bash –group –gecos “CouchDB Administrator” couchdb
• $ sudo chown -R couchdb:couchdb /usr/local/etc/couchdb
• $ sudo chown -R couchdb:couchdb /usr/local/var/lib/couchdb
• $sudo chown -R couchdb:couchdb /usr/local/var/log/couchdb
• $sudo chown -R couchdb:couchdb /usr/local/var/run/couchdb
• $sudo chmod -R 0770 /usr/local/etc/couchdb
• $sudo chmod -R 0770 /usr/local/var/lib/couchdb
• $sudo chmod -R 0770 /usr/local/var/log/couchdb
• $sudo chmod -R 0770 /usr/local/var/run/couchdb
• $ sudo ln -s /usr/local/etc/init.d/couchdb /etc/init.d/couchdb

Put xulrunner-devel on your LD_LIBRARY_PATH

• $ sudo touch /etc/ld.so.conf.d/couchdb.conf
• $ sudo cat > /etc/ld.so.conf.d/couchdb.conf
• /usr/lib/xulrunner-devel-1.9.2.6 (NB. Check the version that you have installed!)
• <CTRL-D>
• $ sudo ldconfig

Running CouchDB Manually

• $ sudo -i -u couchdb couchdb

Running CouchDB As a Daemon

• $ sudo /etc/init.d/couchdb start

Some of my more recent research has been into new, or at least improved, ways to make the web a more conversational place. In one sense it already is, we can link to stuff and we can comment on posts. This isn’t always sufficient though. In reverse order, not all sites support commenting and even when they do comment support on websites can still be done better than it is right now as it can be difficult to mine, evaluate and analyse the insightful comments. I feel that a web conversation works better when it is a part of the Web, a strand of conversation that interleaves the various sites spread across the web leading a person, whether a spectator or part of the conversation, to engage in chance discovery. Linking is the primary structure of the web. Hyperlinks enable us to create uni-directional links between one site and another, so that when we wish to refer to another site, for example, when commenting in our own blog upon a claim made in another, we link to that originating source site. These links are only one way however, so I can refer to another site, but they have to respond to me if the conversation is to be reciprocal. This does not however stop any other web users from responding to my post in any way that they see fit. This gives us a very egalitarian system, with minimal structure, in which the web itself supports conversation – it is up to the conversation’s participants to engage in it and make it happen.

A nice example of this kind of web conversation occurred with the recent discussion between John Gruber of Daring Fireball and Joe Wilcox of Oddly Together. This spat basically boiled down to the suggestion by Joe that Daring Fireball should allow comments on posts because otherwise Joe has to respond to Daring Fireball posts on his own blog and John’s response that “you write on your site; I write on mine“. I think that that is exactly how it should be and that the web is a better place for it. I think that comments enable an immediacy of response but they don’t guarantee that your response will stay in place. The only way to ensure that your response stays online is to post it in a place that you control with a link back to the original. Even better, if those two hadn’t disagreed then I wouldn’t have discovered this post about “Conversational Journalism” by Doreen Marchionni which to me echoes the argument that Alan Rusbridger made in his Hugh Cudlipp lecture (which I commented upon before).

There are also many sites that are primarily designed to support conversation such as the Web 2.0 sites like Twitter but for the most part these lead us into a walled garden, with poor support for conversational threads and, due to the limitations of microblogging, the increased use of link shorteners which, whilst not breaking the links in the web, certainly weaken its structural integrity. From the perspective of the Twitter business this makes sense, the lock-in part anyway, you want to be the only game in town, but from the perspective of the web, this is a systemic weakness because a huge portion of web traffic, much of the web conversation, is occurring on a single site, a single point of failure. This is not to say that I am “against” Twitter, far from it, I like the idea of microblogging and to me it provides the basis, but not a complete solution, for enhanced distributed web conversation. It is just that I prefer open and distributed systems to closed and proprietary ones – mainly because when things break, and things always break, you can’t fix them, you have to wait for someone else to do that.

The next stages, as I see it, are twofold:

1. to provide aggregation mechanisms so that we can get different views on the conversations, for example, following it in whichever direction we like, instead of just following the uni-directional links, or exploring a particular sub-thread of the conversation.
2. to provide new tools to make it easier to engage in the conversation.

The first stage can be accomplished by building upon the Argument Interchange Format, at least in the guise offered by its second version which includes support for dynamic argumentation structures, including dialogues, rather than just static, monological argument. By utilising open, distributed, web-conversation repositories to store meta-information about the relationships between conversational utterances, much like trackbacks and pings enable a form of bi-directional linking, we can start to build new interfaces to engage with and track the web conversation. The second stage will be accomplished by the tool-builders, a process that is partly happening already with the advent of tools to enable Twitter users to tweet from wherever they want and with new and improved blogging and microblogging platforms such as Tumblr and Posterous making it easy to create short posts as a part of the web conversation.

Wow, where did the last month go? I am recently back from the second Argument Interchange Format (AIF) meeting which was held at the Dalmunzie Hotel in rural Scotland. The list of delegates to this meeting read like a who’s who of online argumentation researchers – people who are developing argumentative tools which, in some way, communicate argumentative information between themselves and to their users.

All in all the meeting went well. We achieved the aim of writing a first draft of a specification for the second AIF which includes fixes for many of the problems we have discovered since the original format was specified and introduces some new elements that many of us have noticed were glaringly omitted from the original. In terms of running and organising the event, there were some things that went really well such as:

• Ensuring that all delegates prepared a position statement beforehand so that rather than meeting and starting with “what are we going to talk about” we got straight to the job of discussing the next version of AIF.
• The first night over dinner we all wrote questions onto post it notes that framed the sorts of things that we were interested in. These were used to create a number of topic/discussion groups (which later became major organising elements of the paper draft) and whittle the 23 delegates into a manageable number of working groups with shared interests.

Other things of course worked less well, for example,

• 23 computer scientists using Google Docs to collaboratively edit documents is fine. Except when you are in rural Scotland where your internet feed is provided via two-way satellite communications which are very quickly saturated, and suffer from fairly high latency anyhow.

Some lessons learned:

• Google Docs works quite well for collaboratively editing documents. Who knew? It even works well if you are using it to collaboratively edit LaTeX source, although obviously you don’t get to compile it to anything useful or check source errors within Google Docs.
• Make sure that people aren’t editing offline then copy-pasting into the Google Doc, as each time they do this they reintroduce the same errors that you just got finished fixing. (This one caused both myself and John to swear quite a bit)
• If you are working with LaTeX then don’t forget to install it onto your laptop before you go as you then have to shell into a remote server which has a working LaTeX environment in order to compile the aforementioned LaTeX source into a PDF.
• Set up a local network using a small wireless access point and make some shared directories available on a small server such as a mac mini so that you are not transmitting all that data over the hotel’s network all the time. We caused the Hotel to have to reset their router several times over the course of the meeting.
• Investigate collaborative software, such as Gobby, or a versioning system such as Mercurial that can run on the local server to keep track of the collaborative edits rather than relying on Google Docs. Although Google worked reasonable well I still had to go through the following steps to get a PDF generated:

1. Download the document from Google Docs as a txt file & save it as .tex file
2. Run the tex file through dos2unix
3. Get rid of any final non-printable ascii characters using the following:

   $ tr -cd '\11\12\15\40-\176' < file-with-binary-chars
    > clean-file

4. Compile as usual.

My favourite element of the new specification is the inclusion of support for dynamic argumentation. I had attended the meeting with a clear personal plan to ensure that the AIF2.0 include support for dialogue and I was assigned to the working group on dialogue with Bart Verheij, Raquel Mochales , and David Glasspool. One of the things that quickly became apparent was that thinking of the AIF in terms of monologic and dialogic argument was quite limiting and that other researchers had quite clear needs which wouldn’t covered by an AIF which accounted for just arguments and dialogues. Instead what we developed was a model that saw the core AIF, version 1.0, as a model of static arguments and AIF2.0 as including both this as well as dynamic extensions that enable us to model not just dialogue but also other aspects of dynamic argument such as representing the order of argument elements for when analysing rhetorical and presentational aspects of an argument (thanks Raquel) and the history of the construction of an argument (thanks David).

There is an article over at ACM Interactions magazine that suggests that design should be applied to work interactions and that discussions, meetings, and relationships should be designed in the same way that we design other processes, products, and experiences. The aim of the article is actually less about designing dialogues in the sense that I think about it, for example, taking an existing dialogical situation and aiming to improve the way that the dialogue progresses to meet tangible goals, and is more akin to reconciling the different traditional approaches taken by designers on the one hand and business innovators on the other. Designers, nowadays, typically take an ethnographically based and user-centered approach to developing a solution. Businesses on the other hand often still utilse a document-centric approach, revolving around spreadsheets, charts, and powerpoint slides. The article suggests that design innovation will often not survive the business process and that it is the design of the meeting at which the designers and business folk meet which causes much of the problem. Rather than meeting with the aim of taking forward the most promising innovative solution, what is more likely to occur is that the design will fall prey to business decisions that have already, to some degree, been made. A fait accompli that leads to limited options:

“Reject it outright, accept it but do something to mitigate the damage, and accept it publicly but work privately to keep it from ever seeing the light of day-all tried-and-true processes for dealing with folks who want your sign-off but not your collaboration.”

The suggested alternative is to adopt an approach used by Procter & Gamble. At least two weeks before the yearly  strategy-review meeting proposals have to be submitted to the CEO who would prepare questions about the proposals, The presidents responsible for each proposal were then limited to three pieces of paper that they could take to the review meeting as a basis for the defense of their proposal. This process meant that rather than sitting through presentations defending the proposals, and inch-by-inch, getting buy-in from various other presidents until a safe proposal could be agreed, the proposals had to be discussed and the presidents had to engage in a dialogue about the future strategy. Until this point:

“Rather than engaging in dialogue, executives had devoted their time to bulletproofing arguments, then advocating and defending them. Dialogue was different, foreign, and unnerving. Only after two or three cycles did the presidents come to see how invigorating it was to engage in dialogue about what could be rather than what is.”

By redesigning the meeting process it is suggested that there can be a profoundly positive effect upon both the participants and the organisation as a result of applying design thinking.

I saw this short post over at experience matters which introduces the experience wheel, an analysis tool used at LEGO to describe experiences so that the good and bad aspects can be easily seen. Obviously this has the advantage of enabling a designer to target those areas of the experience that are less good and therefore raise the floor of the experience. What I particularly like is that the entire experience can be summed up in a diagram of (essentially) constant size because all steps of the experience are arrayed around the perimeter of a circle. Other than that, pertinent aspects are that the relevent aspects of the experience are described in the center and that the extent of the experience is surveyed not just during but also before and after. This suggests that we should also be taking into account external factors, such as events along the same timeline as the experience, but not technically a part of it, which might have relevance.

Dan Lockton, he of the Design with Intent toolkit, has set out what he describes as 11 gambits for influencing user behaviour. These include:

1. Challenges & Targets – Give users something extra such as a defined goal that gives them a buzz for taking part.
2. Unpredictable reinforcement – Don’t let the users get complacent – they shouldn’t be expecting a treat just for taking part
3. Scores & Ratings – Feedback that shows where in the pack you are
4. Levels & Progression – Goal oriented users are fulfiled by levelling up
5. Rewards – pat on the head, ’nuff said. Closely related to the idea of challenges and targets
6. Playfulness – Encourage participation by offering a fun play element
7. Storytelling – Engage users through narrative
8. Gaps & Voids – Leaving deliberate voids that the user can’t help but try to fill
9. Roleplaying – Allocating roles for the user to fulfill
10. Collections & Aquisitions – take advantage of the hoarding nature of people
11. Birth a Meme – Plan ahead for the design being shared and spread around

I like how many of these ideas overlap with the explicit techniques used by game designers to keep gamers playing that I discussed recently. Particularly: challenges, unpredictable reinforcement, scores, progression, rewards, aquisition, and roleplaying, are all techniques that game players and designers are used to. The difference is though that these gambits are not about creating games but guiding behaviour in users of other systems.

Playfulness is obviously a core element of any game design process, or at least it should be, but is sorely lacking in many approaches to designing and building interactive systems.Playfulness could actually be one of the most powerful elements to creating a new user experience to which the users persistently return. Birthing a new meme is interesting and is a technique that obviously has great potential but that we don’t know enough about the mechanics of yet to reliably spawn meme creating systems. The Japanese seem to be good at spawning memes but this approach is still quite hit and miss, either an idea has legs or it doesn’t, at least for now. The most interesting idea in the list that is new, has immediate potential, and seems tractable is the idea of leaving gaps and voids in the system that the (possibly more anally retentive) users feel an irresistable urge to complete

In her TED talk, Jane McGonigal hypothesizes that the pursuit of the “epic win” is one of the prime motivators for gamers who sink many hundreds, if not thousands, of hours into their game of choice. She suggests that when we design games that are aimed at tackling a real world problem or achieving some real world goal we need to take advantage of the incentive to participation that the epic win represents. I think that it is particularly in the context of world-changing hard problems that this approach represents another tool in the arsenal.

There seem to be many people arguing against this approach however (commenters in this thread [boing boing] and this one [ massively ]), some taking the idealistic approach that gamers should just stop playing games and should get out into the world and solve those hard problems directly. The problem is that this has not, and probably will not, happen. Others take the approach that because “I Love Bees” or “World Without Oil” are not their kind of game and are less fun than say World of Warcraft, then the whole approach will come to nothing, not realising that what McGonigal has been doing over recent years is to peform the fundamental research and develop the theoretical basis that will underpin the dynamic for participatory games that affect the real world. Finally, others are not seeing that there is more to gaming than playing the latest console game. For some gaming is about rolling the dice and playing according to the rules, for others gaming is about playing with the rules themselves to see what unintended consequences stem from them, for others, gaming is about saying, “to hell with the rules lets just play”. It is this final sense of play, and to a lesser degree fun, as prime motivator, that set McGonigal’s conception of games apart from the others. It is less about the rules and more about the interaction. When you see this you then see that there is already an interplay between the real world and the game world, for example, we can take real world situations and model them formally using games ,as I do with my research into dialogue, or we can do as McGonigal has, take real world situations, such as a looming oil crisis, and associated problems, such as getting people both to care and to become involved, and build a game that raises participation, inspires dialogue, poses possible solutions, and ultimately attempts to the fix the problem. These two approaches are essentially sympathetic and could be unified;

1. taking a problem,
2. using a formal model to characterise the problem,
3. playing with the formal model, assuming a linkage back from this to the real world, something that is rarely direct
4. affecting the problem by manipulating the game model rather than working directly

It is steps 3 and 4 that McGonigal is really looking at here, using the game abstraction from the real world problem to inspire, structure, and scaffold involvement rather than as a way to withdraw from involvement. Once you see this you also see parallel approaches being carried out elsewhere, for example, the Play Decide dialogue card games which are being developed to support public engagement and understanding of real world issues like, climate change, nanotechnology, neonatal screening, stem cell research, and xenotransplantation, to name but a few.

I am sure that eventually McGonigal’s ideas will underpin or at least inspire games that affect the real world on a large scale. This is not happening yet but what is described is the vision for how we can take something that is essentially about withdrawing from the real world, which is gaming, and turn it on its head, so that that withdrawing from the real world causes you to simultaneously become intimately involved with it.

The world has had problems ranging from difficult, to tough, to hard, for many years and yet it is still a minority of people who get involved and try to fix them. The vast majority are happy to let others fix the world for them. McGonigal’s approach potentially brings many new eyes into focus on these problems and lets the owners of those eyes get involved, via game playing, without getting involved, although possibly many gamers who become as intimately aware of the problem as the games allow will also get involved for real.

I noticed an article today, the “5 creepy ways video games are trying to get you addicted“, that outlines some of the methods used to create addiction in gamers and thought that there is an insight here into methods that we should be aware of when designing persuasive technologies. The  methods discussed are as follows:

1. Treating the gamer as though they are a rat in an Operant Conditioning Chamber or “Skinner box” and giving them carefully scheduled rewards to ensure that they play the game for a long period, important with subscription type business-models, and crucially, that the players continue to play the game through less fun or more repetitive parts. This approach relies on making players conform to certain patterns of activity through carefully arranging time, activity, and rewards, which can be combined in many ways to produce the required behaviour patterns.
2. Exploiting the natural hoarding tendencies of humans alongside of the additional tendency of gamers to treat game items as real  to turn game items into food pellets, just like the rats get in the box. Given that a player expends time, effort and skill to obtain them, they have value. Game items are now considered to be real by some courts, insofar as they can be bought, sold or stolen, and therefore an industry has grown around producing and marketing these things.
3. Exploiting the idea that the next one might be the winner. This is the equivalent of getting the rat to keep pushing the lever even if there isn’t a treat available every time. People relax if they know that there is a reward each time they perform a given action, so variable ration rewards are used to make you keep trying, just in case.
4. Getting you to keep pressing the lever involves a number of techniques; Increasing difficulty so that whilst it is easy to get started and earn your first pellets, the period between rewards grows; Getting rid of places where you can disengage from the game without losing at least some of your progress; Punishing the player for incorrect behaviour, if they fail to press the lever at the correct intervals then they are punished.
5. The game fills a void in the life of the user. This is the real kicker because it means that the game is providing something to the user that is better than what they have outside of it. This is based upon a combination of: autonomy, the game being able to choose what they do, complexity, so as to avoid boring repetition, and a connection between effort and reward, so that the player can see the results of all of that grinding work. The reason that these work to addict people to games is that the designers aim to provide some combination of all three factors which is better than the combination of those factors in the players real life or job.

Of course the real secret to applying these techniques is to not make it obvious that they are being used. The whole point is that the correct combination of all of these factors is what earns a game like EverQuest the title EverCrack yet the players don’t feel manipulated.