It's life Jim, but not as we know it

2011-12-26

A Tale of two Sites

Lately I've been contributing to charities using their websites to donate money directly - rather than hand money to a chap on the street. 
The experience has been interesting to say the least. As you would expect, some websites are poorly designed, unnecessarily complicated and make it very difficult to donate. One website I used was actually misleading - getting the user to set up a monthly subscription when the user thought they were going to make a one off payment (if you didn't see the check box with the small print..). 
Most website design guides focus on layout/composition, colour, texture, typography and imagery.  Modern web designs will have you focus on social aspects - such as design for sign-up, on-going participation, collective intelligence and sharing. I'm not going to dig into these topics (it's easy to look up) - but the good and the bad are exemplified in the two examples I've chosen to illustrate the experience.


I will apologise here for making an example of the bad (the Leukemia & Lymphoma Society) - but in doing so I hope this will be seen as constructive criticism that will have a material effect on direct website donations. 


Remember: my objective is to donate money, quickly.


The Bad:  Leukemia & Lymphoma Society


This site is confusing. The site serves 4 purposes - informs users,  get donations, get visitors involved and providing practical support for sufferers of blood cancers. 







I'll highlight some of the main issues
  • Objective: the intentions of the site are hidden or downplayed.  The "Donate" and "Resource center" links do have a prominent place on the page - but are easy to miss and could be better promoted.
  • Readability : small font, small controls, poor contrast and branding all affect the readability of the site. The multi-toned brown background with blue text serves no purpose and detracts from the readability of the text.  The tiny navigation controls are a challenge for anyone using a mouse (never mind a finger on a tablet or phone).
  • Structure: there is no page structure and information is arranged haphazardly across the page. There are no clear regions on the page for the 4 objectives of the site. 
  • Content: the content on the site is misplaced. First the "contact and information specialist" - sits in the middle of the page - (when on most sites it would be at the bottom) - and there is no clear indication of why you need to contact a specialist. The second issue is the news feed - that mixes up genuine news with requests for users to get involved.
  • Social: Focus on sharing or communicating to others is a small icon bar at the foot of the page. 

Once you click the Donate link - you are navigated to a second page full of text and links. Unfortunately the donate page reads like a contract. 
True, there is more to giving than through an online donation - but how much do you lose by forcing the user to read through this and click again to donate? 
All that text makes the site less engaging. 



The Good : Water.org


By contrast, water.org is a much simpler and easier to use site.







  • Objective: clearly identified with two large buttons on the top of the screen - "Donate" and "Get Involved". 
  • Readability : big font, big controls make this site easy to read and navigate around. branding is kept to a minimum and does not dominate the page or style.
  • Structure:The page cascades down giving you more information as you work down the page. The page is laid out like a tabloid - with the headline dominating the center of the page, and the lower half of the page being simply structured in 3 columns.   
  • Content: the content on the site is well structured. The 3 columns have a clear purpose - facts, news and follow on actions.
  • Social: The foot of the page is dedicated to sharing. the badge is large and difficult to miss. It boldly says "Follow Us" and asks you to engage.

















When you click the "Donate" button on the page - you are taken to a page to capture your credit card details to make a donation. Simple. 
Instructions to donate by other methods are also displayed on the screen.






Design matters in everything. Whether the site is an internal intranet or a public site - take time to focus on the objectives of the site and try to incorporate the good elements of web page design. Don't try to inflict your personal or corporate style on others if that detracts from the objective of the site.





2011-05-14

Google Fusion Tables

One of my favourite sessions at Google I/O this year was the Visualisation of data in Google Fusion tables.  The ease with which a non-technical person could create an interesting analytic is awesome. Empowering the user in this way allows the user to spend more time on surfacing key points instead of having to worry about the mechanics of creating the visualization. Enjoy !



The Google Maps Styling website is located here

2011-02-20

Product Kaizen: Observing how users interact with products to drive future enhancements

I discovered two new things today. Not big things, mind you, but very helpful.

1. Typing '@' in a Facebook comment stream immediately brings up your friends list and starts filtering your text as you type

2. Selecting text from an error message in Adobe Flex and hitting right click brings up a menu that has 'search in google' as the first option.

Both are great examples of observing user behaviour after the product has shipped and using those observations to drive improvements to the product. Most user testing occurs during the design cycle (in agile) or after the code has been written (lets face it - in waterfall development) - but rarely post production.

In the Facebook example, people have been typing '@' to direct a comment towards a specific friend in a discussion thread. The use of '@' in this way carried over from Twitter, at least that's why I started doing it.
In the Adobe Flex example, people getting error messages would select the text from the error message, paste the message in a Google search, where they would most likely find a) other people who had the problem and b) solutions to the problem they encountered. (that's how I found the feature). It's not surprising, as most product documentation falls short on "problem diagnosis with corrective actions", so the user community fills the gap.

Both cases sound obvious at first, but you will be amazed at how these things get overlooked by traditional software companies. Web analytics, deployed to understand user behaviour in Enterprise Applications is still a novelty.
In these use cases, at some point, the product organisations observed a repeatable pattern occurring with the use of the product; they looked at the pattern and determined there was a way to optimise the product as a result.
But how did they recognise the pattern in the first place? Where did the pattern start?

We start by recognising events. An event is an occurrence within a system or domain. In our case, it is something that has happened within the application. Many events are beyond our scope of interest and do not require any reaction. The events that are of interest to us are called 'situations'. A situation is an event occurrence that we determine requires a reaction. Through observation we see that there are certain conditions in which the situation arises. It may take some time to determine what the conditions are, (some could be co-incidental) - so iterative testing is required to ensure that the conditions we will watch for are appropriate.
Finally we must determine what the appropriate behaviour, that is, the reaction, of the application to the situation; these are the actions. The actions need testing to ensure that they are appropriate and not a nuisance. Remember Microsoft Clippy?

Disclaimer: The following is just hypothetical. The description is how I would have determined the outcome and may or may not reflect what really happened.

Back to our Facebook use case. At some point, it was observed that there was a frequent use of the @ symbol (and not used in the context of a domain address). The Situation-Event-Condition-Action can be described as follows:

Situation: Significantly high use of @ symbol across all user comments.
Event: @ symbol is entered
Condition: user is entering comments in the comment box

Determining the action requires observation. We need to understand what the user does immediately after typing the '@' symbol in the comment box. In some cases there may be no action that you can predict with high probability. However in the Facebook case, at some point it would have become clear that users were typing the name of a friend after the '@' symbol. After some analysis, it would be recognised that the text typed after the @ symbol was data that was already stored in the friends object.

Action: display list of friends as the user is typing characters immediately after the @ symbol.

This would require some modification or addition of the relationship between the comments object type and the friends object type in Facebook. (I'm guessing that is how they have structured the objects in FB).
The end result is that the user has a much improved experience when typing a comment and addressing a specific friend. The enhancement enables the user to complete the task in a shorter time period. Additionally it reinforces the value of maintaining your friends list in Facebook.

This type of analysis is not limited to small user gestures - but can be applied to any interaction. Ask yourself this question, does your Enterprise Application help you or encourage you to manage or maintain your data in this way?
If you are looking for an asset in an ERP application or a contact in a CRM application - will the application provide hints, links or smarts to help you complete the task you are undertaking? Chances are you are looking for that asset because there's a fault (or an order) that needs addressing - or you are looking for a contact because you need to make a phone call or follow up on an inquiry. So did you have to carry out two steps or one to get the job done?

2011-02-05

Quick start: Add Google Analytics to your Adobe AIR application in 4 easy steps



Preamble
I've been an advocate of Adobe AIR since I used the eBay "San Dimas" application (AIR was called Apollo, San Dimas became eBay Desktop). The potential to modern, build rich and smart client applications that have all the benefits of a web application (automated application updates) but the elegance and simplicity of a desktop application (native desktop integration) is a great option for developers who want to build modern client/server applications.
Recent developments by Salesforce (database), Amazon (email) and Google (XMPP) only strengthen the value of using AIR for rich client applications backed by cloud based Enterprise services. (AIR doesn't solve everything and modern browsers such as Chrome and Safari have comparable capabilities through their support for HTML5 ).

One of the downsides of using Adobe AIR, and Flash in general, has been the lack of support for Google Analytics. It was something that we severely lacked when we built the desktop gadgets at Oracle (for Siebel and CRM OnDemand). While we could track the downloads from the Oracle site, there was very little else that we could do (short of putting logic into the gadgets themselves to writeback to a web service) to track basic statistics such as how often a gadget was used, what features were used etc.
Lately I've been working with Adobe AIR for Android and have the same requirements for mobile application development.

The wait is over...
The recent addition of the AS3 library for Google analytics now enables any AIR/Flash developer to add Google analytics to their code and gain the same insight that web developers have enjoyed for years. And the other good news is, it is just as easy to add tracking to your mobile or desktop application as it is for a traditional web application.

Get up and running in 4 easy steps

1. Download the tracking library here

2. Add two import statements (tracking class, interface that the GATracker implements) and declare a tracking variable


com.google.analytics.GATracker;
com.google.analytics.AnalyticsTracker;

public var tracker:AnalyticsTracker;

3. Initialise the tracking variable with your Google Analytics tracking token (replace "UA-123-4567" with your own token).


private function onComplete():void
{
tracker = new GATracker( this, "UA-123-4567", "AS3", false );
}

4. Start tracking.


public function onButtonClick():void
{
tracker.trackPageview( "/hello/world" );
}

In this example, every time a user clicks the button, a virtual pageview of "hello world" is sent to the Google Analytics tracking servers.

That's it, you're done!! Of course in your mobile or desktop application you don't have pages etc., but the great thing is that the mechanism is so flexible that you can choose to implement based on your own needs. I used the simple URL scheme to map specific modules and actions.

This post is just enough to get you started. If you want more information, the Google Project can be found in the Google Projects Labs section here.

Brilliant work by the folks who worked on this !! Many thanks !!