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