Welcome
We are a network of people that have come together to give you the tools you need to share knowledge and advance open digital society.
Why 'Barnraiser'?
When an Amish family needs a new barn their community gathers to build a barn in a single day, a tradition called barn raising. In building a barn together in a day they achieve something that no single family can do.
We share that spirit as we build for society.
-
The Barnraiser project is now frozen. All code is still available for free. A number of forks of the code projects have launched. To find out why, read on....
Barnraiser started back in 2003 when I was invited to Kosovo to teach a group of students in entrepreneurship. I soon realized that these students have no access to tools to allow them to share knowledge and collaborate. I felt that these tools were essential for young people in Kosovo to share ideas, start businesses and move the country towards independence. Whilst there I wrote AROUNDMe; a small Free Software tool to allow them to social network, blog and search. It also had a forum and a wiki for groups to collaborate. The tool very quickly gained a small gathering of volunteer developers and from that the project grew.
I was offered the opportunity to co-found a three year project to empower Swedish youth with the same tools. This project was fully funded and allowed for the employment of three people including myself. At the time, the thought of focusing on this project for three years was a dream, however it as a mistake. Whilst the project aims were good I found myself spending time with budgets, wages, organizations and most importantly, increasingly away from the founding objectives. The volunteers soon disappeared and we get caught up in code and business. Hindsight is a wonderful thing. What I should have done was continued to lecture and put time aside for Barnraiser or simply get a job somewhere with time to develop the project within work hours.
My underlying objective was to see an open social networking protocol, so that people owned their social networks. Look at the mobile phone. It is yours. You have your contacts on it. It is irrelevant to you as too which network or service provider these contacts are on. My goal was that you can create a social network in any platform (website, mobile phone) and share information amongst friends. You can take it wit you from provider to provider... network ownership stays with you.
I thought that the best project to piggyback on for this was the OpenID project. This takes care of identity. The social networking aspect would use OAuth. Using these two open protocols made sense to me. We could then take many small individualized softwares such as a personal blog, a group wiki or a twitter feel and share them amongst friends and groups of friends whom I wish to exchange interests and project ideas with.
Meanwhile FaceBook grew and a monopoly was quickly in place. Whilst I wish the people at FaceBook all the best I find myself staring a monster in the face. A private company is now able to influence millions of people whom do not own their social networks nor have any say in what that company does. The FaceBook privacy issues highlighted this. One day we may see FaceBook either innovate open protocols or see a consortium lead by the mobile phone networks crush FaceBook. - who knows what the future will bring.
Ola has gone on to work with LSU and I wish him all the best (and hope he takes some of our conversations to help other projects). Sebastian flourished as a developer and now with JamesList where he is up to all sorts of interesting things. I wish them both well and thank them both for their countless hours of sharing ideas and thoughts.
As for me, I moved to Bequia; a tiny island in the Caribbean and now work for a Yacht Club. The schools in Bequia have no working computers so any thoughts I had of teaching technology and entrepreneurship here were scuppered. I\'ve now started a swimming school (swimming, snorkelling and diving is my other passion). As I teach the kids to swim we talk about rights, responsibility, social networking, open society, opportunities and music. They continue to teach me. I\'m happy taking part in them learning to swim - one by one.
To everyone that supported Barnraiser, the volunteers spread throughout the world, those that downloaded, the Free Software Foundation and to all the students that I have had the pleasure to share my thoughts with, I thank you. It\'s been awesome – stay free.
Tom Calthrop -
I am very happy to announce the release of Dutch; our knowledge sharing network tool.
We stumbled across the idea of Dutch when we were playing a few weeks ago. We were looking at a way to share snippets of knowledge quickly - an example being links to web sites and videos. The idea is simple enough; can we create a tag and comment under it to create a tagcloud of knowledge.
Dutch gives you a simple way to make a tag (or a "network") under which you can post information and comment on other peoples information.
We give you a notifications screen where you can see activity from both networks you are a fan of and people you want to follow.
Dutch is free software and released under the GPL (version 3) license. Please visit the Dutch product page at http://www.barnraiser.org/dutch for more information, downloads, case studies, guides and a technical specification.
We want your feedback
Forums have all sorts of tools to moderate and manage dialog. Dutch has non of these. Networks can be made by anyone and added to by anyone. The most popular networks filter up to the top naturally. Please play and resist the immediate urge to compare it to a forum:) It is a lightweight product and we want to focus on the knowledge sharing and social aspects of the tool.
We want to know what you think of it and examples of how you would use it.
We want to know about bugs and features that you like / dislike.
One "feature" that is not yet fully developed is that you can plug-in URL parsers. We have one for DIGG which today is hard coded with a Barnraiser account and we have one for Youtube which is a hack and does not make use of their API. Type in a Youtube URL as a contribution and you'll see it parse that URL into a thumbnail and link. Obviously we need to make a little "parser manager" and open this up so that people can write parsers for all sorts of web services.
Feel free to post comments, thoughts or any other feedback below.
A big thanks to Sebastian Öblom and Tom Calthrop for developing Dutch.
Enjoy free software. -
Prairie is a lightweight OpenID based Internet identity server. Instead of registering at every web site with different username and password combinations you use your identity server to log you in.
Prairie is free software and released under the GPL (version 3) license. Please visit the Prairie product page at http://www.barnraiser.org/prairie for more information, downloads, case studies, guides and a technical specification.
We want your feedback
We wanted Prairie to be lightweight because it is easy to manage, customise and support when it is small. Prairie is 350KB without themes and language packs. It has 8 pages all of which allow themes to be added and templates to be customised. Added to that we have used Gettext making language packs easy to add and customise.
Whilst lightweight we wanted Prairie to look and feel nice to use. We have included two themes to choose from and a tool that allows account holder to make a nice graphic at the top of their profile page. So question 1; did we succeed in making Prairie look and feel nice to use?
Usability is important to us, but as an Alpha release we have not had time to test this yet. You may wish to read two earlier blogs about OpenID usability (the results of which are included in Prairie). Our goal is to make Prairie (and the OpenID authentication process) intuitive. Question 2; Is Prairie easy to use? Do you get stuck with any screens, fields or instructions?
OpenID authentication can assist visually impaired people. Imagine how difficult it must be today being faced with every web site offering a unique way to register. Giving them one authentication process to go through which is identical for every web site makes the web more accessible to them. We want to achieve this along with meeting all W3C web standards. This includes conformance level Triple-A of the W3C Web Content Accessibility Guidelines ensuring accessibility for people with disabilities. Question 3; Have we achieved this?
Lastly for those of you wanting to play with code, we have introduced a MAPTCHA test at registration and on the profile page "contact me" form to test if the person registering/contacting me is human. We went with MAPTCHA over CAPTCHA to reach accessibility levels that we were happy with (blind people cannot read characters displayed within an image). Our MAPTCHA is already being bypassed by spammers and we want to know how. Question 4; how to stop we stop our MAPTCHA from being bypassed?
Feel free to post comments, thoughts, answers or any other feedback below.
A big thanks to Sebastian Öblom and Tom Calthrop for developing Prairie.
Enjoy free software. If you would like to support free software then please take a moment to watch the 25th GNU Birthday video:
From all of us at Barnraiser "Happy birthday to GNU, happy birthday to GNU, happy birthday dear GNU, happy birthday to you.":) -
I wanted to find a simple RSS feed aggregation tool that allows people to add RSS and ATOM feeds to a social tool that would aggregate them into a simple web page for a workshop I was running.
SIDA (Swedish International development agency) asked me to run the workshop for 90 youth that they were about to send abroad to gain work experience from the developing world. I wanted them to blog and I wanted a way to aggregate those blogs into a single web page so that they could easily keep in touch with each others news and hopefully learn from each others experiences.
I could not find a script so I wrote a script that I have codenamed "bank". It looks up RSS and ATOM feeds from web pages (like blog pages), pulls out the latest entry and stores it. The stored entries are displayed on a web page.
I could easily add an RSS feed from the webpage so that you can get a single feed from a wide variety of sources.
Adding a login function would allow people to add feeds, hence you have a social aggregation tool.
You can find an example at http://bank.src.barnraiser.net... which updates every 15 minutes. What do you think? Good idea? Shall I develop it and open source it or should I put it in the bin?
Tom -
In this article I continue to publish the results of our usability tests along with recommendations for our software development surrounding OpenID implementation.
This is a simplified workflow chart of a typical OpenID authentication process from a users perspective. The areas marked "A" through to "F" identity usability pitfalls that caught out a vast majority of our testers.
From the top you see [Enter OpenID] which is a form field requesting the users OpenID identifier (typically something like http://tom.calthrop.info).
The first time you authenticate from a browser you are asked to login to your RP (your OpenID service provider or "relaying party"). In some cases your session is stored so that you do not have to log in again for a limited time.
The first time you authenticate to a website you enter a trust screen where your profile information is typically displayed. You authorize the transfer of this information back to the website. The typical form has options to "cancel" this authentication, "trust once" or "trust always". If trust always is selected the website is saved and you will no longer be presented with the trust screen when authenticating to this website.
Once complete you are returned to the website as logged in. Typically if this is your first login to the website you will be presented with a registration form that is pre-filled with the information you supplied from the trust screen.
Understanding the pitfalls
We will now go through the process step by step and examine where each pitfall lies. At each stage I make a recommendation on how to avoid the pitfall all of which naturally I recommend built into Prairie; our Internet identity server if it has not already been done.
The OpenID identifier
See point A in the diagram. We found that around 40% of people at some point (normally after they had not used OpenID for a while) entered their email address as their "identifier". I discuss this in part 1 of this series together with suggestions for prompting the user if an email address is entered.
Workflow variation
See points B and D in the diagram. Users expect repartition in process otherwise you introduce points of variation which can lead to points where the user experiences confusion of frustration.
The first point (B) often introduces some other decision point such as a "keep this session alive?" checkbox added to the login form. This adds confusion and misunderstanding.
Recommendation: Only have the username and password field displayed in the login form. Remove any "keep session alive" option or move it to a user account "power options" area in the form of "display keep session alive option at login" which sets a cookie.
Instead of a username ask the user for email and password.
The biggest issue here in terms of confusion is the way the process sometimes takes you to the trust screen and sometimes does not. This appears random to the user as many of them do not understand the underlying process of storing trust.
Trust Once versus trust always
See point D in the diagram. When you authenticate you have the option of saving the fact that you trust this website. This means that in future authentication you skip the trust screen. As noted above this appears random. Add to this that you have to go into some form of account page to unset that trust once continuous trust is given and you uncover a minefield of usability chaos.
Recommendation: Remove trust always and create a trust screen with two buttons; "cancel" and "proceed" on the trust screen which gives the user a clear and simple instruction to follow.
Profile data
See point D in the diagram. Apart from trust the greatest form of contention is with profile data. The user is more nervous about using OpenID because they see it as giving their identity away which is far more dangerous that giving a website their MSN password. Yes you read that right. Over 50% of testers felt this way. One of the main issues here is that their profile information is displayed to them along with big words like "trust always".
Recommendation: Remove all profile information and extensions from the OpenID authentication process and focus on it being "a simple way to authenticate with a website".
Post authentication process
See point F in the diagram. There are no usability issues with a user completing the process and finding themselves logged in. This is important because it is the main purpose of why we adopted OpenID (to return me authenticated to a website that now sees me as logged in).
When using OpenID to register wit a website many usability issues occurred. All users (100%) did not understand why they had looked at a form containing their profile information (in the trust screen), trusted or approved it only to discover that they are presented with a pre-filled registration form that contains all the same information as what they have just approved.
Recommendation: We move all profile information exchange to OAuth under a different process.
OpenID authentication Summary
If the above is enacted upon we are left with a vastly simplified process that logs a user on quickly using one username (their email address) and one password.
Moving profile exchange to a key based approach
We talk of keys and certificates as technologists, but it just so happens that the vast majority of people who have a computer also have a key that they use everyday to let themselves into their house. Explaining keys to people is easy. Whilst the profile exchange in OpenID is messy a key exchange from an OpenID RP to a website to access RP profile information is easy technically with OAuth and easy to explain to a user from a usability perspective.
Take the scenario that a website wants you to register. It asks you if you want to use your OpenID. You say yes and you are taken to your RP where you are prompted with "website X wants a key to look at your email, your nickname and your mobile number one time. Would you like to login and proceed?". You login then you get a screen where you can choose what to give the website. You press "proceed" and you are returned to the registration form. Behind the scenes OpenID authenticated and OAuth gave the website a use once key. The key was then used to access the profile information and pre-fill the form. This is an important difference in workflow because the website can for instance ask for a key to always look up your email address so that should you change your RP email address this address will be automatically updated by the consumer for the duration of the key lifetime.
Having a process that does this presents other opportunities such as message exchange (a key that allows the website to forward messages to my RP) and commerce (allow Amazon to look up my credit card details) which naturally via my RP places me in command of my keys and thus in a higher degree of command for profile, communications and commerce information.
Summary
I recommend that a different process is used for profile exchange and that OpenID is used purely for authentication at login.
Usability notes. Once we removed the skip login and skip trust screens and removed all profile information in Prairie we got a 100% success rate in the number of authentications performed without question, hesitation or confusion. -
I've never been presented to a person who forgot their email address. Quite a claim you may say, but when one presents themselves in business one tends to shake hands and hand over a business card with the email written on it. Next time you are in a meeting ask someone what their OpenID URi is. You'll probably get a blank stare followed by an answer along the lines of "oh, ehm, I only have Skype".
The email address although geeky looking is now part of our daily lives unlike the OpenID URi, hence the challenge for those of us involved in developing OpenID solutions is to provide helpful usability centric solutions to this challenge. Given that, I challenged myself; can I provide an organisation with a mechanism to authenticate with OpenID but use the employees email address and email password? Here is my approach along with usability notes from testing.
A typical business email address looks something like this:
firstname.surname@example.com
OpenID has a consumer which is the web site that you want to authenticate to. It asks you for your OpenID which is typically a URi that looks something like this:
firstname.surname.openid_server_example.com
The first thing to notice is that they look alike to the average employee which gives them a great opportunity to confuse them. There is a far greater chance that they will forget their OpenID URi as it is not ingrained in their minds as with their email address. Instead of forcing them to learn their OpenID we should allow and forgive them for putting in their email address as their OpenID URi.
Option 1: Allowing email addresses to be entered instead of a Uri
In the OpenID consumer script we can look for an email address and replace with with an OpenID URi:
<?php
$email = "firstname.surname@example.com"; $company_email_server_url = "example.com"; $company_openid_server_url = "openid_server_example.com";
$pos = strrpos($email, $company_email_server_url); $user = substr($email, 0, $pos-1); $URi = $user . "." .$company_openid_server_url; echo $URi; // will echo firstname.surname.openid_server_example.com
?>
We now had the URi back to the consumer and proceed with authentication as normal.
Option 2: OpenID assistance
With option 1 we have sort of shot ourselves in the foot because if your employees don't know that they have OpenID they do not get the full benefit of it (like being able to authenticate to an external website), hence my preferred method is to "guide" your employee in a helpful way.
Let them type in their email address but check for it:
<?php
$email = "firstname.surname@example.com";
$pos = strrpos($email, "@");
if ($pos === false) { $URi = $email; } else { $openid = str_replace("@", ".", $email); echo "This looks like an email address. Perhaps your OpenID is " . $openid; // return to form and prefill openid with $openid
}
echo $URi;
?>
If you find something that looks like an email address then suggest to them an OpenID URi equivalent.
Using their email password
On the OpenID server a form is included for the users password. Upon posting that we have both the URi (firstname.surname.openid_server_example.com) and the password. The password should match that of the users email password.
Checking username and password using LDAP
Many companies and organisations use an LDAP directory to hold email username and passwords. Here is an example of how to check using LDAP. Please note the code is here to demonstrate the idea simply. It is not robust nor secure.
The first bit of the email (firstname.surname) is the LDAP username so we need to get it.
<?php
$email = "firstname.surname@example.com"; $company_email_server_url = "example.com";
$pos = strrpos($email, $company_email_server_url); $user = substr($email, 0, $pos-1); echo $user; // will echo firstname.surname
?>
Once we have the username we can authenticate against the LDAP server.
<?php
// We connect anonymously and get username
$connect = ldap_connect($server, $port); $bind = @ldap_bind($connect);
$search = ldap_search($connect, "dc=corp,dc=sample,dc=com", "uid=".$username); $result = ldap_get_entries($connect, $search);
// We verify using password
$bind = @ldap_bind($connect, $result[0][dn], $password);
if (isset($bind)) { $search = ldap_search($connect, "dc=corp,dc=sample,dc=com", "uid=".$username);
$result = ldap_get_entries($connect, $search);
if ($username == $result[0][uid][0]) { echo "Authenticated."; } }
ldap_close($connect); exit;
?>
If you don't use LDAP and you have an IMAP server you can simply name a connection and if it returns true then the username and password is valid:
<?php
$mbox = imap_open("{localhost:143}", $username, $password); ?>
Once the username and password is checked as valid you can then continue with the OpenID authentication process as usual.
As you maybe aware, we have a new OpenID server in our lab called "Prairie". We are considering adding the LDAP server. Please let me know if this is something you would want because if we get a good level of feedback we'll add it. -
We have moved our web site today to use Roundhouse; our new social blogging tool. The community is also moved to http://build.barnraiser.org/ and is now built on Dutch; our knowledge sharing environment.
Just add a comment either below or in the "barnraiser feedback" section of our community if you have any feedback. -
One of Roundhouse's features (our social blogging tool) is that the content is optimized for Googles search. I just wanted to explain what this means.
When Google opened up their search site in the late 1990's they were immediately set apart because all the good sites always seemed to appear on the first page in the search results.
It was not long before website developers took interest in seeing if they could get their pages ranked further up the Googles search results, thus web development became influenced by Googles search.
People soon realised that the importance or "ranking" was affected by the number and quality of links to the page (called "backlinks"). If you link to a page you increase its ranking. This led to people quickly "swapping" links to their web pages. The modern day equivalent of this the the blogroll (the list of favourite blogs that you see on some blogs).
Adding links to your blog and asking others to link back to you is a human issue and thus does not affect us when we speak about Roundhouse and Googles search optimisation so what does?
The title tag
In the HTML that provides the markup for this page there is a tag in the head of the page called TITLE. Google gives this some weight. If you look up you'll see the top of your browser picks this up to name the window - You'll see it as Barnraiser: . We add the name of the blog and the title of the newest blog entry to the TITLE tag. This adds weight to your latest blog entry.
The link
Click on the title of this blog entry or the permalink button below it. You will see that the link has the title of the blog entry in it; in this case http://www.barnraiser.org/roun... . By placing the words in the link automatically become keywords that the search engine can index every time someone clicks on your link.
Hidden text
Many commercial web services include hidden text in the source of your web page. Google frowns upon such things because they think you are attempting to influence their search. Your site will not end up in the search results because of this. We include no hidden texts (developers comments and such like) in these pages.
The rest as they say is up to you so here are a couple of tips to authors.
Keyword density
Look at the following two sentences:
"This blog is about search engine optimization and the way we have coded for it."
"Roundhouse; our social blogging tool is written with Google search engine optimization in mind because we have developed Roundhouse for it."
The two sentences loosely say the same thing, but one include "Roundhouse" twice and one does not. Because the keyword density is higher on the later sentence Google will rank the keyword "Roundhouse" higher.
A word of warning, Google is clever. Don't write the same word 50 times in a row. Google looks to see if the words look like a real sentence. If Google thinks you are trying to influence the page ranking you will soon discover that you do not appear on search results.
Backlinks
If you include a link to a web page consider telling them. You may receive a backlink which will increase your page ranking.
Some further reading
Googles overview of their search technologies
Wikipedia describe "PageRank" in some detail
-
I've rejected advertising in the past because of two simple reasons. Firstly anyone creating a social website should not have advertising as their primary revenue generator and secondly it does not work as a primary revenue generator.
Taking Facebook as an example Valleywag.com reported that Facebook users click on an advertisement 0.04% of the time - yes, just 400 clicks in every 1 million views.
This however does not stop the high level of questions I receive about advertising and using it to sustain a project or website. Given that I am intrigued as anyone I have decided to place Google adverts on our home page and build network.
I will report back to you regularly with a status on that together with tips on how you can implement advertising in our product range.
Any revenues gained from Google adverts will go towards the costs of our hosting. -
Many people either working or volunteering for the organisation find useful snippets of information on the web. They in a moment of excitement send out an email to their colleges after which it is promptly trashed, forgotten and lost forever.
Information harvesting is often overlooked by organisations. Finding, researching and cross checking from the web is an ongoing process. Often people involved in this share new ideas or thoughts sparked by information they harvest from the web.
We wanted to create a tool that simplifies the catcher, retention and distribution of such information.
We came up with Dutch; a knowledge sharing network tool. Dutch is a part of our research to re-think the way we share knowledge on the web. Our goal is to create a fluid pool of knowledge shared amongst interested people based upon them working together in gathering information from the web.
If you are going to try it the best approach we've come up with is to gather your team and ask them which websites they like. If you are lucky as we were you get a wide variety of websites including social bookmarking, blogs and news services. Ask each member of your team to regularly post up information that they think will be of interest to the team. You should see pools of organizational relevant information form quickly.
There is a demo available from the Dutch product page. I welcome your comments and thoughts on the tool.
Free social software
- Dutch
Share information quickly and easily with Dutch; our knowledge sharing network tool. - Roundhouse
Import blog entries from the whole blogsphere into your blog stream with Roundhouse; our social blogging tool. - Prairie
Forget all those different username and password combinations once and for all with Prairie; our Internet identity server. - AROUNDMe
A collaborative networking suite.
Highlights
Tags
Bank * Blog * Prairie * Project closure * Social aggregation
Archive
- July 2008 (2)
- August 2008 (5)
- September 2008 (2)
- August 2010 (1)