The visual anatomy of wordconfusion.com (see below for complete diagram)

I’ve been reading (and writing) a lot of code recently and wanted to share a graphical technique for understanding an alien codebase.

Code can be hard to follow, especially if you didn’t write it, and even more so if you are new to a language. Web apps are particularly hard to follow since they consist of several layers, each containing multiple technologies (HTML, CSS, Javascript, plus the intricacies of whichever MVC web framework you use).

I’ve been trying to get back into programming recently with Python and Django. To that end I’ve been doing a number of online tutorials. I find these easiest to follow when the tutorial guides you, incrementally, through the writing of an app so you can grasp the code a piece at a time. A couple of my favourite tutorials on this “incremental” type are James McGaw’s Beginning Django E-Commerce, and Ayman Hourieh’s Django 1.0 Web Development. The catch is that such a tutorial takes a long time, both to read and to write. Its also hard to get a quick overview! Call me impatient (-;

Other tutorials throw you right in andpresent a ready-built web app. An excellent example of this is John Jarvis’ Django/Jquery tutorial – Making a Flashcard Game. John introduces a whole suite of web technologies – Django, Jquery, HTML and CSS, tied together with ajax calls, JSON, Django templates and Dynamic HTML. Its a lot to take in, and John does a fine job explaining it. However, I still found myself losing the plot in the blog posts, and eventually ended up printing out the code, scribbling all over it, and sketching an intricate diagram of how all the pieces fit together. It was only when I had a complete diagram of the flow from initial load to Game Over that I started to get it.

You can see a (slightly tidier) version of my diagram below. Its not meant to be a complete representation of the codebase, but it does help you grok how the game flow propagates left-right and back again through the layers (HTML/CSS – Jquery and click handlers – ajax calls – Django views, templates and models).

A visual anatomy of the jarv.org Django/Jquery Flashcard game (click pic for full size PNG)

If you are struggling with a codebase, give it a go. It does take a significant amount of time, but should greatly improve your understanding. If you are learning Django, definitely check out John’s Making a Flashcard Game tutorial. I hope this diagram helps you follow along more easily. If you are writing a tutorial, or documenting a codebase, consider throwing a diagram in!

Here are a few of the key concepts which sketching up a diagram like this helped make a lot clearer for me. I’m sure they are obvious to you old-hands out there, but they weren’t to me. Perhaps they aren’t to you?

• Many newbie web apps consist of distinct calls to the server to display separate web pages. In contrast, here there is one web page, consisting of a framework of DIV elements which are revealed and hidden in turn as the user navigates through the flow. The hiding and showing is done by Dynamic HTML controlled (mostly) by client-side Javascript.
• Much of the game logic is in Javascript, a language which does not have the most intuitive syntax. Sketching out the flow reveals the intertwined set of click handlers and functions which make the game work. Huh, Javascript isn’t actually that nasty!
• One exception to the above is that the “Game Over” logic on whether to display a new High Score is contained in a Django template.
• I’m a UX person. I like to track a user engagement from start to finish. Try doing this in the code. Yuck! Here you can see it at a glance.
• Some of the JQuery game logic hits the Django back-end, however the main game loop does not.
• Not all AJAX calls/responses are the same! Some return JSON, some return HTML of  part – or all – of a page. Again seeing some examples of this visually laid out in the overall application flow – helped make things clear.

Disclaimer: this posting is completely based on John Jarvis’s excellent Django/JQuery web tutorial. Go do it!

 The Voices in Their Head: Crowdsourced Live Usability

It can be challenging to run a group UX review, even when the participants know each other.  There is always someone who talks endlessly, raising nitpicks and alienating other team members, others who talk too little, and those at their back who are miles away doing their email.

Its also hard to cover all the material in an allotted time, particularly if a long interaction flow is being reviewed. I remember one usability inspection at Google where the aim was to review a 5-step signup process. Sounds easy, but we didn’t even make it halfway since we got bogged down with the visual design of the first page. This was a particular problem since the real usability and conversion challenges weren’t until the penultimate billing step.

For these and other challenges, its important to have a strong facilitator to keep things focused, constructive and rolling.

Its even more of a challenge in a room of 50+ strangers who – in a limited time period – want to give critical (and hopefully constructive) feedback on a product they haven’t seen before. This is the situation I find myself in San Francisco’s UX Eye for the Developer Guy Meetup, which I help run with – amongst others – Luca Candela, Ben Morrow, and Jenny Morrow. At “UX Eye”, startups in need of UX loving, are invited to present their product to a large group of UX practitioners including designers, researchers, and engineers.

When I run these sessions, its my job – as the facilitator – to keep things focused so as to cover all the material, to get as much input as possible from both loudmouths and those more softly-spoken, share some useful UX principles and methods, and hopefully be entertaining in the process.

Introducing The Voices In Your Head Protocol

My favourite approach for a group UX review is based on a simple protocol I call “The Voices in Your Head” (VIYH). Its an odd name for a UX methodology, but bear with me, all will become clear. A VIYH session consists of a modified usability test with one participant at the front of the room, systematically interrupted with audience input from the masses. This balance of methods – usability and group feedback – has several benefits:

1. A well-moderated VIYH session is a very efficient way of systematically reviewing a complete interaction flow in a room of 50 strangers in a limited time. “Impossible!” you cry, well read on.
2. The product team and audience gets to see an approximation of a one-on-one think-aloud usability session, glimpse some live moderation techniques, and observe actual user behaviour in the product. It still surprises me how few startups observe people using their products and are effectively “developing blind”. Getting feedback from a large audience can be stressful, but the product teams always learn something new and enjoy the experience. In fact, many of our participating startups are inspired to do user research themselves.
3. The audience is forced to watch and think about actual user behaviour before conveying suggestions. I find this encourages deeper analysis, and a stepping beyond “visual design nitpicks” to more fundamental issues (for example, “the colour scheme is terrible” versus “the user can’t find the call-to-action to sign-up”).
4. The whole process is a lot of fun – especially for the facilitator. See the catchphrases below.

How to run a VIYH Session.

Before the Session

As the facilitator, be sure to review the product in advance. This allows you to confirm the interaction flow to be reviewed, indeed make sure its ready to be reviewed(!), and come up with a scenario and persona for the usability session. In most cases, these are very simple. The persona tends to be simple as “a 20-30yo white collar worker who is not very tech-literate” (i.e. unlike everyone in the room), whilst the scenario might be “You have heard about product X from a friend. Go and find out about it, and sign up”.

Brief the startup team to make sure they don’t interrupt and inadvertently prompt the audience. I always encourage them to take good notes since the feedback often comes thick and fast.

If you are truly presenting to a roomful of strangers, chat some up beforehand, and select a suitable usability participant. Select someone focused and confident, but able to follow instructions. That last bit is important.

Schedule at least 40 minutes per product. This should be enough for an intro, a 4-5 step interaction flow, and closing discussion.

Starting Off

First things first, find a volunteer to be the usability participant and ask them to leave the room.  Then invite the Startup to give a two minute overview of the product so the audience have a reasonable idea what it is, and what specific UX-related questions they have. Ideally the audience would be completely fresh just like the participant. However, I find that an up-front overview helps keep things relevant and to time.

If the audience has limited experience in UX, and in particular in doing UX reviews, I present a quick checklist of things to look for. For example:

1. Try and stay in the mindset of our target persona. You understand acronym soup, would our target persona?
2. Is it obvious from the landing page what the product is? (with no background introduction).
3. Follow the user’s actions, rather than looking around the page. Focus on the areas of the screen which get the user’s attention as they complete their task.
4. Are there clear calls to action for completing each step of the task at hand.
5. KISS.
6. Is the wording concise and clear? (This is often an overlooked aspect of UX for a busy startup).

Brief the Participant

Now its time to get going. Invite the test subject back into the room. Tell them who they are (the persona) and the scenario (what it is they need to do).

Next the crucial bit. Tell the participant that you want them to go through a step at a time. At each step you’ll ask them what they would do next to achieve their goal, and to think-aloud through their decision process. Tell them they are allowed to move around with their mouse, but ask them not to click anywhere until you say (this step by step approach is derived from the Cognitive Walkthrough UX Inspection methodology). Depending on the sense of humour of the participant you might want to reassure them that its the product being tested, not them. Or not. I like to keep things light-hearted and relaxed, and find a joke about how “all the data collected will not leave the room” goes down well.

Brief the Audience!

Don’t forget about the audience. They have a key role too. Tell them that its important not to shout out and prompt the user. In fact they also have personas to act out. They are going to be “the voices in the user’s head”. At each step of the session, they will silently watch the participant do their thing. When the participant is finished, the audience then get their chance to give feedback on anything and everything. Tell them that as “Voices” they are continuously working in the background, but only speak when they are told to do so. There’s a lot of them after all, and the participant has a small head. Lastly, these Voices are not nitpickers. They like to pipe up if they see something they like, as well as raising areas for improvement.

Step 1: The Incoming Channel: google.com

I like to start the flow before the participant even sees the product. As facilitator, there is a very important point to make here – that the user’s experience starts before they get to your website. SEO, SEM and other marketing channels are UX too.

• Typically I start off on google.com and ask the user to do a search to start their task, and review the corresponding search results. After, the user has indicated which result they would click, open it up to the audience for 30 seconds of SEO, SEM and product naming suggestions.
• This is handy for getting some initial feedback on the name of the product and how easy it is to spell, a frequent challenge in these days of a cluttered DNS name space.
• After 30 seconds of group discussion, tell the Voices to ssshhh. Ask the participant to click on their search result and/or type in the URL directly.

Step 2: The Product Landing Page

Now we get to the meat of the session as we start to look at the product. On each page (i.e. each step of the follow), the review proceeds through 2 distinct phases: (1) the usability participant speaks, and (2) the voices (the audience) speak.

First the participant gets a minute to look at the landing page and decide what they would do next to complete their task. The facilitator should follow standard usability interview practice. Let the user have some uninterrupted time to think and act. Prompt them to think-aloud and/or stay on track as need be.

• If anyone from the audience says anything, ask them to be quiet since they are well-behaving “Voices in the participants’ head”. Depending on your style, you might like to shout at the audience and/or tell them to “shut up” in a mock stern voice. A cow bell can come in handy too.
• Occasionally the participant has no idea what to do. They may not even know what the product is! This is of course great feedback for the product team. Let the participant “suffer” for a while, before asking the Voices for a suggestion as to what to do next.

When the participant has indicated what their next step would be (just indicated mind you remember you’ve ask them not to click), its the audiences’ turn. Ask the participant to freeze, and open up the proceedings to the audience:

• Have some fun. Go drill sergeant on them if they are being quiet. Typically, I have the opposite problem and have to ask the Voices to put hands up and speak in turn. Cut them off after 20 seconds so you can get input from as many people as possible.
• Since the whole audience is contributing, make sure people speak clearly. Don’t be afraid to ask them to stand up.
• Voices are not allowed to interrupt other Voices.
• Watch the clock. Particularly for less important pages with obvious issues, try to keep the group review concise. You can allow a few minutes more for the key steps with the main UX issues.
• When time is up, tell the Voices to be quiet. Its time to give the participant control of their head again.

Step 3: Onto the next product page

And now its back to the participant. Unfreeze them. Congratulate them for listening quietly to the voices in their head, and ask them to do their intended action. Again prompt them to think-aloud, and stay on task.

• If they get completely stuck, get a suggestion from the the audience, or give them a clue. Hopefully you as the pre-briefed facilitator know what the desired path is.
• Again if the voices speak up, tell them to be quiet. Surely they must have got the message by now?

When the participant has said what they will do next, open it up again to the audience again. If not all of the would-be commenters had time to speak in the previous step, they will now be champing at the bit! Remember to watch the time.

Repeat Step 3

Keep cycling between the usability test, and the Voices until you are out of time, or more ideally have completed the interaction flow.

Close the Session

Finish the proceedings by asking everyone – participant and audience – what they see as the top issues and any recommendations for the startup. As facilitator, guide them to focus on the big significant issues – a nice exercise in issue prioritization.

Finally, I invite the startup to say a few words. Typically they are overwhelmed (positively!) with feedback, and have filled several pages with notes. There are always a few fresh surprise issues and ideas new to the team.

Conclusion

I find “The Voices in Your Head” protocol allows a facilitator to get a lot of focused feedback on an interaction flow in an efficient manner, balancing task focus and some objectivity (the poor user at the front), whilst giving everyone a chance to speak and have some fun in the process!

Let me know how it goes if you try it. And if you want to see it in action, swing by the next UX Eye for the Developer Guy Meetup in the SF Bay Area.

Thanks to Braden Kowitz for help with the smiley graphics!

Django is getting me down. I want to love it. You see, I love python but its so hard to do some seemingly trivial stuff:

• Getting my AJAX POSTS past Django’s inbuilt CSRF filtering still isn’t working (see my previous post). My suspicion is some interaction between Django, Passenger, Dreamhost but I don’t know for sure. PHP just works. Does this mean PHP is inherently less secure? Answers on a postcard please.
• After far too long faffing, my pal Jeff gave me the sage (and retrospectively obvious) advice to try it all on a local dev server, to bypass all the weird hosting interactions. This should be easy right? Heh. After even more time faffing, it turns out that static file serving for CSS, JS etc. doesn’t work out of the box with Django’s  built-in dev “runserver”. It turns out you need to jump through a bunch of hoops to get it working! WTF?

I’m starting to get a bad feeling about Django … I’m going to take a peek at web2py and also considering a shift to Rails.

Ah the joys of coding – hitting your head against something which appears so easy but is actually quite fiddly. All the more painful after having some fun with the Google maps Javascript tutorial and feeling Javascript was quite easy.

So what was the something? Making an AJAX POST from some Javascript to a Django service. I was working merrily along following Daniel Stocks’ very readable “AJAX in Django with JQuery” tutorial. My mistake: skipping over his note about CSRF protection.

The code was super simple:

In Javsacript, on a link click, make a call using the ajax post JQuery convenience function, with a callback to display the returned message on the webpage:

 $("#doajaxgetcall").click(function() {
 $.post("http://www.django.unburnout.com/xhr_test/",
 function(data) {
        $("#ajaxtest").append(data);
    });
 });

On the server, check HTTP request and send back a message:

def xhr_test(request):
    if request.is_ajax():
      if request.method == 'GET':
        message = "This is an XHR GET request"
      elif request.method == 'POST':
        message = "This is a XHR POST request"
      return HttpResponse(message)

The result? <Nothing> on the click, a 500 in the JS console, a 500 in the server log, and an arcane error in the Passenger logs

[error] [client 24.4.69.35] ModSecurity:
Output filter: Failed to read bucket (rc 104):
Connection reset by peer

Fix as per the Django project docs on CSRF (thanks Daniel – I’ll read properly next time). You need to manually catch AJAX POSTs and make sure a HTTP header is set to the value of the server-supplied CSRF token. Lots of other people have been reporting this issue … Django need to improve their documentation me feels.

Code to insert in your Javscript (explanatory comments mine, original docs here):

    // intercept AJAX messages
    $(document).ajaxSend(function(event, xhr, settings) {

      ...

      // Main: if message is not using a safe method (e.g. GET)
      // but is from the same origin:
      // set request header to be CSRF cookie value
      if (!safeMethod(settings.type) && sameOrigin(settings.url)) {
	        xhr.setRequestHeader("X-CSRFToken",
                getCookie('csrftoken'));
      }

    });

Oh, and another morale of working with Django. Allegedly you don’t need to restart the server, each time you edit some code. But running on Passenger on Dreamhost you do (sometimes).

touch $PASSENGER_ROOT/tmp/restart.txt

Day 1: finished Peepcode’s Javascript+AJAX tutorial. Good stuff. Always wondered what JSON stood for. JavaScript Object Notation … a human-readable data format for associative arrays. Nice.

Then, after some battling, a victory. I finally got my friend Tim’s android app prototype working using the MacOS Android cmd-line dev tools. This was surprisingly non-trivial since the Google docs are somewhat scattered. Plus I had skipped through them. In retrospect, the eclipse plugin may have been easier, but the ol’ UNIX shell scripter in me wanted to “install from first principles” (-;

Anyway, here are my steps:

1. Install the SDK
2. Set your shell’s PATH variable to include the location to your $SDK_ROOT/tools folder.
3. Important yet easy to miss (as I did): The installed SDK does not include the platform images for the various versions of the Android OS. You need to install these manually using the management app which comes with the SDK: Run the android app from the cmd-line, select “Available packages”, and download the SDK Platforms you need. I went with 2.3.3 for my friend’s app, I also got 1.6 which my prehistoric (3yo) original Google phone is limited to.
4. From the command line, check the packages are available - android list targets. Keep this list handy.
5. Then create Android virtual devices (AVDs) for each OS level you want to run in the emulator: android create avd -n testavd -t 1 [the -t flag corresponds to the ID listed by the previous 'list targets' command]. You can also create or view these devices in the “virtual devices” tab of the android GUI.
6. Run the emulator! At last! emulator -avd testavd [I CTRL-Z into the background, go and have a cup of tea - its slow]
7. When it finally loads, the emulator should look like an Android phone. Navigate to the Phone Settings, and make sure the following option is enabled: Settings > Applications > Unknown sources (enabled)
8. cd to your $SDK_ROOT
9. Load your app: platform-tools/adb install ./SECRET-ANDROID-APP.apk
10. Bingo! If the app does not appear, try restarting the phone.

Next: django vs. Rails

The time has come. You see, I used to code. Indeed it used to be my career. Then I got involved in UX, learned the joy of prototyping, and now I don’t code. Well to be exact – I’m rusty. Oh, I can still hack scripts in python (mostly log analysis and text processing), and websites in HTML/CSS with a bit of JQuery.  I can quickly grasp coding/technical concepts while chatting with real engineers. And I’ve done a fair few Rails / Python / PHP tutorials. Still, every time I want to build something, it feels like I’m starting from scratch.  Its time to get my hands dirty again. And keep them dirty.

I’m setting myself a challenge. In 100 days, get up to speed with the state of the art in web technology. I don’t expect to be a full-time coder again but I want to be able to quickly engineer basic interactive web/mobile prototypes.

Why? Why not just build click-through mocks? Well …

1. Engineering is fun and I miss it (even the debugging, sometimes …)
2. I don’t want to be one of the people with a CS degree who don’t code anymore. There’s lots of us out there!
3. Who knows I might join or start a startup sometime soon, and more hands-on coding skills would be handy

Its not going to be a consecutive 100 days. However, I’ll try and do at least 2 days a week. Each “day” will be accompanied with a brief blog post outlining what I did and why, and maybe a helpful hint or tip for people doing the same. My stretch goal: add to stackoverflow or similar discussion websites as and when I manage something and can contribute to online “solutions” (many of which are lacking).

Any tips/hints to tutorials/languages/frameworks appreciated! Else maybe I’m past it. What do you think?

Here’s my current hit list, and current skill level. I acknowledge that its quite varied. First I want to try a range of stuff out. Then towards the end I’ll focus so I’ll have a basic toolkit for prototyping. Thats the plan.

Languages

I intend to focus on python as my foundation. However I’m open to learning a new language if I need to. That might be Ruby or Javascript – we’ll see. I’ve dabbled in both but never achieved what I’d call “conversational competence”.

Web application framework

I want to get up to speed with an MVC web framework. I’ve dabbled in 3. I’d like to say I can develop in one. Here’s the shortlist:

• Ruby on Rails (I did the excellent tutorial by Michael Hartl and produced a nice little twitter clone. However, I got bogged down deploying it to heroku, and Rails is so arcane! Expect a post or two!)
• Django/Python web framework (recently did tutorials, but got stuck with some fiddly stuff like handling AJAX POST calls within the CSRF filter framework. Expect a post on that too)
• PHP: Hello World and basic database calls
• Google App Engine (python), just a bit of hacking with my pal Lindsey.

Web standards

Any web work requires a reasonable understanding of HTML, CSS. Again, I can hack. The “code” I produce is as ugly as hell. I can do better. Also I keep forgetting my CSS selector syntax. It’d be nice to remember stuff like that in my head.

 Admin/Infrastructure/Deployment

Along with the above languages, frameworks, and standards – any self-respecting developer has to know his database admin, source code control, and how to deploy. Django I’ve got running on Dreamhost as a first baby step.

Basic Mobile App development

Android or iOS? I want to play with both. My first post is actually going to be about getting the emulator working on MacOSX (which is not as trivial as you might expect).

I just completed my first triathlon, the Wildflower Half Ironman and wanted to share my experiences. Plus I might try to talk you into doing something similar for Team in Training.

Ready to go

A Great Cause

Firstly, I have to say a big thanks to all my supporters. At the time of writing (May 2011), I’ve raised $4425 for the Lymphoma and Leukemia Foundation. Thankyou! – and if you haven’t donated, its never too late (-; My inspiration for running was my dear friend Chris Hubbard (known to his friends as “Cobol Chris”) who sadly passed away from lymphoma in 2004 aged only 36.

I ran with Team in Training’s San Francisco and Marin Spring Triathlon team – 80 or so people from every walk of life who earned an incredible $300,000. Nice one, guys! In return for raising the readies, Team in Training looked after us with a great training programme over about 12 weeks, including swim coaching, sports nutrition (what to munch), sports psychology (what to think) and even triathlon gear (what to wear). I’ve run, biked and swum all my life and dare I say I considered myself “vaguely competent” in all three. How little I knew. In all three areas, I really benefitted from the coaching – completely overhauling my freestyle stroke, cycling nutrition, and running cadence. As a team we were further inspired by a number of honoree teammates who’s own life’s have been touched by cancer.

The entire Spring, from the first training sessions, through many a bar night, scavenger hunt, beer pong tournament, our first “BRICK” transitions, the practice triathlon, and Wildflower itself was an amazing experience, and one I’d recommend it to anyone. TNT trains for 3 distances, Sprint, Olympic and Half Ironman – so whatever your ability, there’s a level for you.

Anyway, on to the course.

The Course

Wildflower happens every May at Lake San Antonio in Central California. If that sounds hot, you are right. If you throw in some hills and head wind, its even more fun. I did the Half Ironman distance:

• A 1.2 mile swim in Lake San Antonio
• A 56 mile bike around the lake through the beautiful, albeit hilly, Coastal Range
• A 13 mile half marathon back at the lake, including the renowed Pit of Despair (which luckily was where our supporters did wonders)

The Start and the Swim

I have to say that I felt nervous about the start – we’ve all seen videos of triathlon starts with competitors pushing and shoving in a maelstrom of wet suits, keen to get a start on their fellows. I’m pleased to report that this was a lot more civilised than I expected. Every competitor wears an ankle tag which allows their time to be recorded at key stages through the race. This means that if you aren’t in the mood to push and shove, you can hold back for 30 seconds and allow the excitable rugby types to get going without losing time or an eye.

The start was also split by age – I was in the Men’s 35-39 age group. Here’s a video of the Woman’s TNT Olympic traithlon wave the next day to show you what a triathlon start is like, a pushy start, followed by the more laid back.

The swim itself was definitely the toughest part of the race for me, swimming is not my core strength. Our open water training was in Aquatic Park in San Francisco so the lake was a lot warmer than we were used to, although wetsuits were still required. The race had its own challenges including a strong headwind for the outbound leg causing a significant chop, and quite bit of forest debris in the water. I remember at one point throwing a branch out of my way! Total time: 43 minutes, not bad.

The Bike Ride

Working on my tan on the bike

After a quick-ish wetsuit-off / suncream-on transition, I was off on the 56 mile bike ride, heading clockwise around Lake San Antonio. The key for me here was not overdoing it so I would have energy left for the run, drinking plenty so as not to get dehydrated, and enjoying the view. Did I mention the view? The scenery is spectacular across the Coastal Range, particularly on the descent from the Mile 40 Nasty Grade. The bike ride actually passed fairly quickly, it certainly didn’t seem like almost 4 hours. Unlike other long rides, I didn’t break for more than 2 minutes to reapply suncream so the training clearly made a difference. Thanks TNT. Total time: 3 hours 56 minutes.

The Run

Most people dislike this stage. For me, it was actually a relief to start running since I was getting a tight back on the bike (I strained my back earlier in the week). By now it was super hot, so I continued to drink plenty, although I’m not sure I can touch gatorade ever again (they were the race sponsor so had lots of freebies). Since running was my strongest of the three stages, it was nice to overtake some of the older athletes who had overtaken me on the bike, as well as a few of my younger team mates who had started earlier. Total time: a very respectable 2 hours 6 minutes.

Halfway point high fives

The Finish!

This was quite the relief after almost 7 hours of exertion. Here’s a video of me finishing (approx 3 minutes and 30 seconds in, wearing a blue cap!). It was an incredible feeling, especially with the roar of the crowd including many of my team mates.

Total times:

• Swim: 43 minutes
• Transition 1 (wetsuit off, suncream, bike helmet and shoes on): 6 minutes
• Bike: 3 hours and 56 minutes (including helping out a team mate with a puncture and a suncream break)
• Transition 2 (running shoes on, cheese sandwich, energy gel and yes, more suncream): 7 minutes (getting slower!)
• Run: 2 hours and 6 minutes (a respectable time, in the top 40%)
• Total: 6 hours 58 minutes

What are you waiting for?

Go on you know you want to! Sign up for Team in Training. If you don’t fancy the triathlon, they also do marathons, hikes and many other events. Give me a shout if you want to chat about the particulars.

Having been an engineer in a previous life, I’ve been a long advocate of the RTFM response when asked a silly technical problem:

RTFM = “Read the F****** Manual”

• Where the third word can be anything starting with F depending on your mood, the inquirer, and so on. It could be “fantastic”, “friendly”, “frightful”, you get the idea …

Now of course there’s often good reasons why people don’t RTFM. Manuals tend to be anything but fantastic, indeed they are often the point of last resort, and its all too easy just to bug the local techie. Hence the F words. Some people try and make manuals easier to use, but its often the better idea to focus on making the product as easy to use as possible. In the ideal, no manual will be required. Which brings us on to User Experience …

Working more recently in the field of UX, I’ve missed having an RTFM. How should UX professionals respond to engineers or product teams when asked a silly question about visual layout, product requirements, or the usability of a feature? The answer to such questions inevitably involves some aspect of talking to your users, perhaps doing some research or looking at your metrics, talking to your customer support team, and/or “getting out of your office” [Steve Blank]. All too often we respond with some polite, constructive suggestion, UX professionals are above all diplomats in dealing with the world.

Now here’s some additional context: you’ve just been interrupted, you are probably trying to get some work done, and you might want to “wind up” the enquirer “a wee bit” too (British slang alert). I wanted an acronym to rival the catchiness, the supreme pithiness, the playful dismissiveness of RTFM. Hence I give you TTYFU.

TTYFU = “Talk to Your F****** Users”

• The the third word can be anything starting with F depending on your mood, the inquirer, and so on. Again it could be anything from “favourite” to “fearsome” or “frackin’”. The joy of this is you can tune it to the moment.

Now TTYFU can involve a lot of time and effort, especially for a small boot-strapped startup with no time, no money, and no users. Perhaps they are also a bit shy? However it doesn’t have to be expensive and time-consuming. Here’s a talk that I recently gave at UX Eye for the Developer Guy, and Angelpad, which introduces TTYFU as an RTFM for UX and Usability, and sketches out a “guerilla research” technique for doing some TTYFUing without involving any users. Sound a bit crazy? Read on. You might recognize yourself as one of the smiley faces (direct link to preso):

Give TTYFU a go! Let me know what response you get.

Also, what does TTYFU equate to in your native language?

Acknowledgement: Thanks to @DaveMcClure (who else?) for encouraging the placement of an F in TTYFU. Ever the UX “diplomat”, I was initially considering TTYU, but in my user testing to date the F makes all the difference!

I’ve been called an Apple fanboy in the past, and its true, I am. In particular, I respect and enjoy Apple’s fantastic design and the way their products tend to provide a great user experience for their customers. However, myself and many others have been very disappointed with Apple Ping. Complaints have included limited artist coverage, lack of social features, poor integration into existing social networks, and the lack of a web front-end.

As well as these product-level complaints, I was surprised to see that Apple Ping fails on a number of fundamental areas of usability. Is this really the same Apple that brought us MacOS and the iPhone?

In this post, I’m going to go step by step through an important part of Ping’s Social UI, the user flow of responding to a “I want to follow you” request. I will highlight some usability issues, and suggest quick fixes. I’ve emboldened the most severe issues.

The fact that they weren’t caught in advance suggests to me that there was a lack of user testing and QA. Apple will be okay of course, I bet they are working on this right now. However a startup making similar mistakes would simply fail. Hence, this write-up so that others can learn from the UX mess that is Ping.

Onto the “I want to follow you” flow, let’s start with the initial email notification.

Step 1: Email Message

Although Apple Ping doesn’t provide a web front-end, it does forward follow requests to your email account (see screenshot below).

Critique and suggestions:

• The visual design here is Apple’s signature grey. This combined with the minimal content means that the email comes across as bland and uninviting. I’d like to see at least a splash of colour, possibly a logo, along with some minimal background on what “following” entails. What is the key social feature which accepting this request enables? Sharing playlists or recommendations? Spell it out to help educate new users.
• I’d encourage Apple to include a picture of the requester to add some of the  context which is typical in facebook and twitter invites. Its almost as if Apple is trying to suppress the “social” aspect of Ping (more on this later).
• The main call to action is an uber-technical WebObjects link. A human-readable call to action link (e.g. “confirm”) is much easier to scan. The full URL can be included as an alternative down below in the small print.

Step 2: Launch Application Popup

Since the Apple Ping UI is in iTunes, the user must launch this separate application to view the request. The following screenshot shows the dialog box which appears on MacOS when you click the WebObjects link.

Critique and suggestions:

• An important aspect of user experience is satisfaction and delight. Like the email, this web interstitial page is yawn-inducing. How about an Apple Ping logo? or some supportive text highlighting exactly what is happening? Why are we going to the iTunes store? Are we buying something? At a minimum this web page should mention Ping.
• Generally such inter-app navigation (and dealing with corresponding security issues via dialog boxes like this) entails an awful, clunky user experience. It takes me back to Windows circa 1993. Fortunately, if the user clicks “Remember my choice for itms links”, they do not see this dialog again. To make this more likely to happen, Apple could draw more attention to the checkbox area by rewording it in terms of the use case at hand, “For future Apple Ping links …”. I also wonder if they could use a more meaningful “.itunes” extension instead of the abstract “.itms” (iTunes Music Store).
• The dialog box default choice (iTunes) is highlighted in grey which is easy to miss. I’d like to see a clearer highlight.

Step 3: Sign in to access Ping

Each time I respond to one of these follower requests I need to sign in again to iTunes. Albeit annoying, this is a sensible precaution since your Account may include credit card information. There’s one great design element here, our first iTunes/Ping branding!

Critique and suggestions:

• Repeat (albeit secure) logins are annoying to the user. I wonder if Apple could cache “Ping” logins (a la a website cookie) and only force a complete sign-in if the user is trying to spend some money in iTunes?
• Apple Ping doesn’t seem to have its own logo, the blue icon is generic to iTunes. A specific Ping logo could be used to provide consistent branding from the email through the rest of the flow.

Step 4: Welcome to ping

Signing in to your Apple Account, takes you to the familiar environs of Apple iTunes.

Critique and suggestions:

• I’m going to ignore for now the quality of the recommendations of “artists to follow”. Lets just say that 5 of the 6 don’t appear anywhere in my iTunes library and I would rate 3 as being “offensive to my taste”. Where is Apple getting these recommendations from?
• Back onto the “Follower request” flow: where is the follow request? The user is forced to “hunt and peck” to locate it in the “PING” panel top right. Strong recommendation: the user should be taken directly to the functionality to accept or deny the follower request!

Step 5: Follow Requests

Clicking on the “Follow requests” label takes the user to a “Follow Requests” sub-tab of a Ping People page.

Critique and suggestions:

• Focusing on the main task at hand, Apple seem to have done a good job, in that we can confirm or ignore the request.
• My key UX critique on this page concerns how it fits into the overall iTunes IA. This page is effectively 4 levels down iTunes -> Ping -> People -> Follow requests. Standard IA practice is to include some navigational breadcrumbs. Here they are scattered around the UI (e.g. ping is in the top and left-hand navigation, and the panel itself is not branded Ping).
• Its also not clear how to navigate from here to the rest of Ping’s functionality. Note the right-hand PING panel from Step 4 has disappeared. I’d like to keep this up for continuity and context.
• Furthermore, look at where “Follow requests” and “People” appear in Step 4’s “PING” panel – as peer items. Apple Ping’s IA family tree needs some tightening up.

Step 6: Follow request confirmed

I’ll stop moaning about IA for a second, and approve the request (-:

Critique and suggestions:

• Oh, Apple! Couldn’t you come up with something a bit more exciting than grey italics to reflect the completion of this action? Surely completing these 6 steps warrant something a bit more rewarding.
• More seriously, what about follow-up calls to action? What have I earned from approving this follower request? Can I browse her Apple Ping page?
• Apple is missing a key element of “Social” functionality here. How can I “follow” Maria back? I was expecting an easy way of doing this but there is none. Apple here are taking a Twitter approach, leaving it to the “newly followed”, to decide whether to return the favour and follow back. In contrast, Facebook friend invites are bidirectional relationships – if I friend someone, they by accepting my request implicitly friend me back. Its not clear to me that Apple has chosen the right model here, especially for invites between individuals.

Lets move on, assuming I want to follow her back.

Step 7: I want to follow back

I click on her name and am taken to her profile page.

Critique and suggestions:

• There are several issues here. Primarily, there was more information about Maria on the “follow confirmation” page than on her actual profile, e.g. email address.
• Also, all her profile activity is marked private since I’m not following her. This feels broken to me. I’d encourage Apple to experiment with a bidirectional follow model, especially between friends.

Step 8: Confirm request to follow

I click the “Follow” button, a popup appears.


Critique and suggestions:

• The dialog is noting that Maria will be able to view my name, photo and email address. Minor nitpick: Maria can already see a bunch of this info since she’s already following me.
• More significant suggestion: throughout all of this following interaction, I’m still not sure what following gives you. What functionality does it give me? I’d like Apple to spell it out. This is crucial for all new users of a social network, and not just those picking out usability do’s and don’ts.

Step 9: Confirm

I click the “Request” button on the dialog box.

Critique and suggestions:

• Although its good there is some feedback – “Request sent” – this is another bland grey italic bit of feedback. I’d like some clear calls to action as to next steps … What about adding some more friends? What about adding some bands? Can I send Maria a message? (she’s following me after all). What do I do next? This page feels like a dead-end.

I decide I want to grow my network.

Step 10: Click on the People link in the “PING” panel

In the interests of getting some more followers, I click on People. Uh-oh … can you spot the issue?

Critique and suggestions:

• The friend I’ve just sent a follow request to has a Follow button next to her! Instead, I would have expected a “Follow request sent” status. Did my request really get sent? It turned out that it had been, I clicked the “Follow” button to confirm, which refreshed as the “Request sent “ message I had originally expected. So its not a deep bug, but it is a UI bug the presence of which indicates to me that Apple have not done all the QA they perhaps could have. Google would have stuck a Beta label on Ping. But Apple doesn’t do that …

Summary

Many of these issues are not in themselves too serious, but added together they result in a clunky, amateur-ish interaction flow. I wonder how many users drop out along the way? I’d encourage Apple to fix some of these issues and track the associated conversion metrics. I suspect they’d see some dramatic improvements.

Most serious are the design issues which directly inhibit the growth of the Ping social network. For Ping to compete with the rich features and mature communities of last.fm, iLike, MOG and (dare I say) MySpace, Apple needs to take a careful look at the ease of interaction around social features. It needs to be as easy as possible to grow your social network. In terms of the following request flow, the most serious issues are:

• Step 4: the lack of a targeted destination for responding to the follow request in the iTunes/Ping UI in Step 4
• Step 6: lack of calls to action to explore Ping and grow social network after approving the follow request

After several years of doing systematic page-by-page UX audits at Google and more recently independently with startups, I continue to be surprised at the number of significant UI issues which can be caught with this time- and cost-efficient technique. If you’d like a UX audit for your own product please get in touch at r@richardboardman.com. If a design-obsessed company like Apple has this many issues with this small part of the Ping UI, how many issues does yours product have?

Image credits: Remixed from JD Lasica’s original.

Having just set up a tech consultancy, I’m pleased to confirm that the process of setting up a business in San Francisco is relatively straightforward. So far anyway (check in with me again at tax time).

That said, there’s still a few hoops to jump through. Here’s my rundown of the steps involved in setting up a consultancy in San Francisco – including paperwork, training, coworking and networking.

Initial homework

Any business advisor (once you pay them) will tell you the first thing to do is decide what you want to do. Is it something you will love doing? Do you want to do it full time? Part time? Who else is doing it? Whats the competition like? Sole proprietorship? Partnership? LLC?

I’ll assume you’ve got all this nitty-gritty done and you have your heart set on what your business will entail. If you haven’t, Freelance Switch has some useful suggestions.

Name, name, name

The name you choose for your business is an important early decision. Initially I went with “Richard Boardman Consulting”, but I plan to change it to something more exciting in the future.

Whatever you decide, don’t hand about. Especially if your business domain is “a la mode”. You need to check the business name is available to register legally, as well as grabbing the corresponding domain name, linkedin and twitter accounts etc.

Some useful tools include:

• FBN search for checking your legal business name is available
• UD Namecheck will check social media usernames, domain names, and trademarks for you via one quick search.
• Domai.nr for checking domain names, and links to domain registration services. Tip: decide who you want to host your website through and register with them to save some cash, and avoid domain transfer feeds. Personally, I like Dreamhost.
• Twitter (say no more).
• Linkedin (facebook for business) – super useful for collecting recommendations and publishing your resume.

Initial paperwork

Ah, the hallowed corridors of City Hall. I actually found sorting out the paperwork to be rather good fun. However, don’t leave it to the last minute since there are deadlines relative to when you start business. Also, have a book or game on hand as you navigate between the lines in the various departments.

Here’s my recap of whats involved:

• Step 1 (before you go): Double-check the name you want is available with an FBN search.
• Step 2: Once at City Hall, start at the SF Office of Small business in Room 110 – they have all the forms, and will talk you through the process
• Step 3: Register your business at the Tax Collector’s Office (Room 140), and pay the registration fee, within 15 days of starting business. Forms available at sfgsa.com.
• Step 4: File a Fictitious Business Name (FBN) Statement (otherwise known as Doing Business As or DBA), at the Office of the County Clerk (Room 168) within 40 days of starting your business.
• Step 5: Publish an announcement of your new business in an officially sanctioned newspaper. I went with the SF Chronicle since I’m of the generation who still get a kick out of seeing their own ad in a real paper. There are cheaper options filing with random east Bay papers you’ve never heard of. Make sure their fee includes the “filing fee” to confirm your filing with the authorities.
• Several weeks later you will receive a cool certificate of business which you can display in your place of work.

I would also check the other available checklists for the official (and much more wordy) word:

• SF Office of Small business’s own list (not the most usable)
• Office of the SF County Clerk’s list
• Another DIY checklist for an LLC (steelandsilicon.com)

Bank account

Once you get your business registration receipt from City Hall, you can then take this to your friendly local bank. I used Wells Fargo since they have cowboys on their ATMs (a concept which is inherently amusing to a Brit).

Training

There are a plethora of OWCA’s (organizations with crazy acronyms) who you can tap for training:

• The SF Office of Small business don’t do training themselves but have lots of info on others who do. Swing by when you are doing your paperwork at City Hall.
• The SF office of the Small Business Administration (SBA) is where I would go next. They have an excellent eventbrite-driven events list which covers training from SBC, SBDC and SCORE. I attended their “Starting a consultancy business” (3 hour) and “How to Start and Manage a Small Business” (one day) seminars. Both were good foundations, kept me awake, and covered the basics of accounting, legalese, business plans and marketing. $80 well spent.
• The Small Business Development Center of Northern California (SBDC) have an extensive lists of events, which are included in the SBA’s much easier to use website.
• SCORE offer free mentoring to new small businesses.
• San Francisco’s City College (SFCC) offer many business related courses.
• The Renaisance business center has more in-depth training, included a 14 week intensive business class for new entrepeneurs.

There’s also plenty of more technical/startup-y/Web 2.0 training around. Checkout the networking newsletters below for pointers.

Coworking space

Perhaps you want to work from home? Perhaps like me you want to mix it up, working from home, cafes, and an office. One great office option is that of coworking spaces, of which San Francisco has many. As well as being good value, they tend to be chock-full of freelancers and startups and so are great for networking. Pbworks.com provides a comprehensive overview and highlights some of their pros and cons.

• Having tried a few, my favourite is Nextspace on 2nd Street. Its not the cheapest but the location is perfect (2nd at Market), and the facilities are modern and well laid out. Its the kind of place where one could happily take a client back to for a meeting (unlike one or two of the others who need a spot of paint!).
• Citizen Space is a cheaper option, which you can wheel your bicycle right into, albeit with a harder to access under-the freeway location.

My tip is to hunt around – most of the spaces have a “try us free” deal so you hang out for a day and see how you like it.

Broadcasting

This is where the pre-registered twitter account and domain names comes in! If you haven’t registered yourcoolnewbusinessname.com yet, grab it quick!

• Setup your email address. Reserve yourcoolnewbusinessname@gmail.com as a backup. However, its more respectable to use name@yourcoolnewbusinessname.com.
• Set up  your yourcoolnewbusinessname.com homepage. I recommended Dreamhost for hosting and WordPress for setting up a site. You’ll have some static pages and a blog up and running in no time at all.
• Set up a Linkedin account. Network. Collect recommendations from your previous positions.
• Get tweeting (but don’t spam). I set up separate personal and business accounts. Forward your useful business tweets to your Linkedin account. You get the idea.

Networking

In terms of networking and meeting leads in the tech sector, there are a load of meetups in San Francisco. Some of my favourites include:

• Failchat – hearing from founders how they messed up their startup. Get there early for free beer.
• Lean Startup Circle – run by my good friend, Rich Collins. Sometimes they have free beer.
• SF New Tech – free beer unconfirmed.
• SF Beta - no free beer )-:
• Browse around on Meetup.com for plenty more. Also, its worth perusing the coworking spaces such as Parisoma since they host a lot of events.

If you are working in the internet startup field, there are a couple of excellent newsletters to subscribe to which overview many of the events:

• Web Wallflower
• Startup digest

Miscellany

Other bits and pieces

• Death and taxes n’ all that: talk to your favourite tax professional so you’re not surprised by anything down the road. The number 1 tip from mine: use your business credit card for all your business-related transactions for easier records keeping later.
• Get organized: the second thing my tax professional told me was save everything – receipts, bank paperwork, city hall memorabilia, your newspaper cutting. Go and buy a ring binder.
• Business cards: you have choices of cheap options or cool options. I started off cheap, but I’m going cool as you read.

No doubt there’s more surprises in store … let me know anything I forgot!