What it says

After some standard definitions, it hits on the interesting idea that the ‘effect’ or ‘benefit’ of an IT investment depends on how much the product is used x how good the product is. Implicit in this is that IT projects can deliver less (or I suppose in an hypothetical world more) than estimated depending on these two factors. I think it’s definitely true that IT projects try to focus on the latter point, while quite often disregarding the former point (at least in a B2B world – they’ll use it because they have to!).

I also think that the authors are right to say that IT products are expected to deliver benefit in themselves, without really thinking about what these benefits really are. And that’s where effect maps come in…

With effect maps, you work out your:

• Aim – the why, which is linked to business goals and sensibly, includes measurement points (aka metrics)
• Target groups – the who, which are people grouped by the way they’ll use your product (not just your standard segmentations)
• Usage goals – the what, which define what each group wants / needs / must be able to do (the book provides more detail on the difference between these)
• Actions – the how, which may cover both the IT and the organisational change to accompany it

There’s then a whole chapter on how to structure your teams and your work. But I really liked the three points it focused on under ‘Project work’, as these are quite often overlooked. The first is ‘target group analysis‘ or studying your users. Really useful, as what people really do, is often not what they say they do. The second is ‘interaction design‘. This is all the more obvious in B2C work, but the need for it becomes blindingly obvious when you do ‘usage tests‘. Steve Krug opened my eyes to these and I am still surprised at how silly users are much you can pick up from watching someone use your software for the first time.

As is often the case, the example (why is it in the Appendix?) really brings these ideas to life and stops it being just another framework in a textbook. And as is often the case, the map itself isn’t really that impressive, it’s more about the thought process that goes into producing it.

Does it work?

We tried this exercise at work but used mindmaps instead, and within an hour it provided a lot of clarity. You could clearly see the goals, how they would be achieved and then with some basic prioritisation – based on how well they contributed to the goal, then how long they’d take to build – you’d have iteration goals defined for you.

In summary

It’s definitely not the most engaging book I’ve read, but it does make you think about the wider effect your software is having. Many thanks to Gojko for passing it onto me.

Being a ‘product’ person, I decided on A, but it turned out to be a trick question. Kathy’s answer was D – themselves! You want people to say that they are good. Now this might seem a little bit strange, to focus on making your user / customer / player feel like a superstar. But it’s a subtly different way of thinking that has an unsubtly large impact.

As you might guess, this is all too obvious in games. If a game is too easy, you’ll feel like you didn’t achieve much and you won’t get any satisfaction. If a game is too hard, well, you feel pretty rubbish and if you’re me, abandon it. But with just the right amount of difficulty, you’ll feel like you’re improving, think you’re awesome and love the game.

One of the uses for our 5 computers is games and I like to try (at least once) the games my partner plays. The two that he spent the most time on over the last few years were World of Warcraft and Heroes of Newerth – and they were vastly different experiences for me. With WoW, it takes you by the hand and gently leads you from one level to the next. Before you know it you’re at Level 5 and wanting to do just one more quest. On the other hand, with Heroes, the best advice I got was to attack, but if you get hurt, run away as fast as possible (hardly heroic!). But running wasn’t quite my forte and I spent most of my time waiting for my hero to come back to life in the pool. To put it simply, WoW made me feel like I was good at games and Heroes made me feel like I sucked. Easy to guess which one I played longer…

With game and software design, it’s not only important to get the level of difficulty right, but also to help people improve. This could be through tips, by highlighting improving stats, or even by just giving them something achievable to aim for and celebrating when they do. But don’t underestimate the power of making people feel good.

There are people who play to hone their skills, so they can make big bucks in a ‘real casino’. Others enjoy socialising with friends, or love the satisfaction of beating someone else in a tournament. But for some, the game dynamics of Blackjack or Roulette are satisfying enough – and a look at behavioural game psychology explains why.

There are various ways players are rewarded in games and one of the most effective ways to keep players playing is through variable ratio schedules. Sounds impressive, but all it really means is that rewards are given more or less randomly (the variable part) according to how often you do an action (the ratio part). The classic example is the slot machine, where you put in money constantly, but don’t know when it will hit. Roulette is similar, particularly if you play the same numbers, as your number will come up if you bet consistently, but you don’t know when. And if you’re playing Blackjack using basic strategy or some pre-determined method, you’re also hitting a spot on the variable ratio scale.

So even without money, the very mechanics of the game reinforces repetitive behaviour.

Even if you only visit Facebook sporadically, you can’t have missed the bright, eye-catching posts about chickens, trees and mystery eggs. And despite Facebook’s constant evolution of the platform to stop this kind of spam, I suspect many Facebookers haven’t worked out or bothered to turn these messages off.

So why do games on social networks follow the trend of offline and then online businesses? Why do companies go for spam to acquire customers, rather than a Seth Godin permission marketing approach? I suspect the answer is that creating something worth spreading takes too long and is too hard. It’s much easier to fill the social networking streams with flyers, because even though you’ll annoy some, the brand awareness gained and the percentage of people who try it out of curiosity might (if you’re an early-mover with a big budget) just produce a runaway fad. But eventually, someone will put in the effort, whether it’s an established game company or some indie Flash developer, and then the farms will be foreclosed.

Geoffrey Moore

He was the conference opener and he certainly deserved the spot. Geoffrey talked about innovation and the difference between your core (your differentiator, your competitive advantage – in other words, what makes you money) and context (the other stuff you have to do to keep up or to improve productivity – which might even be mission critical). Once you divide everything into these two camps, it’s easy. Innovate on context just enough to get you by – then focus all your efforts on your core. So simple, yet such a useful way of thinking, particularly when it comes to prioritisation.

Kathy Sierra

I hadn’t come across Kathy before, but I wish I had. She had one premise, which she repeated in so many ways it couldn’t fail to get through our heads – make your users feel awesome! Yes, that’s it. It’s not about the killer app, it’s about the killer user. I was used to thinking about software from the user’s point of view, but this takes it a step further. And it makes sense. If software (like chocolate, alcohol, Disneyland – debatable?) makes you feel good, you’ll love it.

Ryan Carson

I respect Ryan for putting so much of his creativity and personality into his company, Carsonified. He made me want to start a company, just so I could make it a really fun place to work. He had a whole lot of tips, ranging from be creative to give back to the community to just hire a designer, but it was more the overriding focus on making it a great workplace that got me.

Conclusion

This is not to say that the other speakers weren’t brilliant (because most were). But these three stood out because:

• They had one point that they got across clearly
• The point was just so obvious and natural, it made you wonder why you didn’t think of it earlier

And to me, they’re the marks of a great speaker.

Highlights

• Recipe counts – see how many recipes each of your friends have; or for the competitive amongst us, see who has the most.
• Popularity of each recipe – see how many times have people “grabbed” their own copy of your recipes.
• Sort recipes – just added something and it’s disappeared to the bottom of the list? No more! Sort by latest and it’ll pop back to the top.

A handful of other little fixes, including: sitemaps, so your recipes will be found by search engines; see the latest recipes from everyone; and, pretty (long) recipe urls on the noise page.

Progress

In the last month we had 9 current users (accessed in the last month). And 51 total users referred. This highlights a continued need for improvement – since this essentially hasn’t moved from our figures in May (8 and 45 respectively).

Add a comment here or contact us on meltingfood to join or provide any feedback.

Highlights

• Tell everyone what you’re cooking / eating with Facebook and Twitter updates.
• Now follow anyone who has good taste (no need for both people to agree to a two-way friendship – ala Twitter).
• Descriptive (long) URLs so Rox’s Banana Butterscotch Pudding goes from http://meltingfood.com/recipes/397 to http://meltingfood.com/recipes/397-banana-butterscotch-pudding
• You can now sign yourself up – no need for someone to invite you.

There are also a couple of other tweaks like: not breaking your saved passwords; better input field alignment; no search engine scamming from dodgy links.

Progress

In May we had 16 unique visitors, June 110 – ah, the fun of Google Analytics. You can spend time slicing and dicing segments and achieving nought.

Add a comment here or contact us on meltingfood to join or provide any feedback.

* – Douglas Adams died so young :(

We apologise that the last release was substantially broken in Internet Explorer (now fixed).

Highlights

• Recipes can now be seen by everyone (no sign-up required).
• The recipe layout has been re-jigged to fit things in a little more snugly (hopefully less scrolling needed when your hands are covered in dinner).
• For Internet Explorer, the broken javascript is fixed and buttons should look a little prettier too.
• Opt out of email has been added – so we don’t disturb anyone.
• The recipe list and noise pages are slightly faster (cleaned-up some inefficient code).

There are also a couple of other tweaks, like using your whole name on your recipes – just to make sure people know who to thank.

Progress

We’ve got about 10 current users (accessed in the last month)! Yes that includes us, so back to 8 really ;)

Add a comment here or contact us on meltingfood to join or provide any feedback.

Highlights

• When searching for your friends, auto-complete drops down to help you.
• See friends of your friends (if your friends have any friends you can now see a list of those friends – clear?).
• More ajax-y responses (for the non-geek, when you delete your recipes, add friends or reject friends, you won’t have to wait for the page to reload).
• Slightly smaller pages (for the geeks, javascript framework change from Prototype to jQuery – more conducive to removing in-line js and forms).
• Google Analytics – so we get some idea of how people are coming to / using the site.
• Rough business plan.

There’s also a bunch of other minor bug fixes and improvements.

Progress

We’ve got about 8 current users (accessed in the last month)! And about 45 total users referred. This is without even resorting to nagging everyone we know (we’re keeping half in reserve ;p). Based on the business plan, this means we’re at 0.008% of the target (100k unique people per month :)).

But keep your eyes open in the next month… we’re eating our words and going public!

This is because your clever name doesn’t matter. There is a seemingly strong counter-argument, that goes “…but, brand is crucial – look at how much all those big companies spend to make you remember their all important name!”. This is true, however before the names existed (outside of their inventors heads), they weren’t special because they weren’t attached to something anyone cared about.

The poster site for this is del.iscous.us.com or whatever they’re called (del.icio.us – online bookmarking). Do you think when it launched in 2003, then was venture capitalised (2005), then acquired by Yahoo 6-months later, that it mattered that it was doing all the no-noes in naming: one, it was hard to spell; two, it was unrelated to the site’s purpose; three, it was not the standard .com; and four, it ridiculously used “del” as a subdomain. This liability is of such marginal importance that Yahoo didn’t even get around to buying the delicious.com name (I imagine at some outrageous price from the previous owner or squatter) until mid-2008.

So how did they get away with breaking so many rules?

1. People don’t speak as much anymore, so when someone mentions they found something cool, they send a link via email or Skype or IM twitter.
2. Google is search engines are used by so many people that the url doesn’t even matter – in fact, the first five results of my horrendous name-mangling effort above return people who have spelt their link text wrong – but still have the correct underlying URL.
3. By following rule two (unrelated to purpose) above – URLs like del.icio.us still work even if people did speak to each other (outrageously breaking rule 1), because it is a distinct and real word (despite the domain hack).

To sum up, whilst I’m not arguing that having an ideal (pronounceable, distinct, simply spelt, .com) domain name is useless – I’m saying that it needs to go back to the bottom of your to-do list again, and again – ’til you’re so successful you can trivially buy out or sue the nasty domain squatters – who you first thought “ruined” your grand idea.

Here’s an example

When you’re searching on most sites, you need to type in your search text, click on ‘Search’ and wait for the page to reload. We thought we could improve this with ‘in-place searching’. As this probably doesn’t mean much to anyone (as we just made this phrase up), let me explain:

I want to be able to search the site from any page, at any time – and I don’t want to lose my bearings. So I go to the obligatory search box at the top right hand part of the page and start typing… search results appear magically below, pushing the page’s text down.

For us, this was an improvement – a way to search from anywhere, without losing context. But when I actually tried to use it, it constantly confused me.

I would search for recipes from Joe’s profile page and get not only Joe’s, but everyone’s recipes in my search results. Or I would confuse the search result’s list of recipes with the real list of recipes the page was presenting. Or I just thought it wacky that the contents on the page I was on, jumped down the page.

Some of these could be hacked around, fixed through formatting, but none really removed the confusion – people expect search to be on a separate page. In trying to improve usability, the rule of building what people expected and were used to, was restraining us. But if you don’t build what people expect and are used to, how can you improve usability? We get caught in a vicious UI circle.

Of course there are exceptions

Obvious exceptions to this are situations where the UI was so horribly painful in the first place – take reordering as an example. Until relatively recently, there were no elegant solutions: you could click ‘up’ and ‘down’ arrows until the item in your list was in the right place; you could type in the ‘order’ of the item in the list as a number… but you couldn’t do the most obvious drag-and-drop of the item into its correct place until we got ’standard’ javascript libraries (such as prototype + script.aculo.us, jQuery, Dojo, etcetera – yes I know there were other drag-and-drop ’solutions’ before this).

So what do we do?

We ended up compromising (ok, it is a hack) – when you begin searching, other content on the page disappears, so you don’t get confused. But when you clear your search text, the content reappears. This gives us a faster search, but you lose a little of the context.

Maybe the way to break the vicious UI cycle is to focus on one small, incremental improvement at a time.

14 letters and 5 weeks later, my friend had conclusive evidence of how the process worked, along with a set of recommendations on how to improve it.

This approach is definitely not new and is used extensively in other forms. Mystery shoppers simulate real customers. And for something closer to home, ‘dog-fooding‘ is often discussed in the software development community.

Before all you process people throw your hands up in protest, I do admit there are some shortfalls to this method: it is best suited for customer-facing processes; it doesn’t cover all scenarios; it’s anecdotal rather than statistical – you won’t know if what you experience is the most common process. However you will certainly uncover gaps that need further investigation in the traditional way.

What you get is a real-life view of what your customers go through when dealing with your company. If you can record the process you’ll also get an artifact – physical letters, emails, recorded phone calls, screen captures – that you can transmit to your colleagues in a high-impact way. You’ll end up closer to the reality, than to the process that people thought existed. You’ll find out if your welcome letter arrives after the product, or your service takes months to get up and running. Can you handle the truth?

Taking advice from Pierre Francois, the elevator pitch for our website is, “it’s like Facebook, but for food” (just the trusted network part of Facebook – not everything like, ahem, stalking, that comes with social networking sites). But no, this post is not an invitation to join the site – it’s almost the opposite.

Although we do have dreams of extending our 2-person alpha user-base, we’ve made a decision to limit the number of new users to a couple per week starting with whomever happens to be visiting. But if people want to join your site, why restrict them?

Exclusivity
As we start out, we’re making a choice between being completely open to the public or expanding via our existing friendships. And we’re going for exclusivity – no one can join unless they’re invited by a current member: not only is it easier to build software targeted at ‘us’, we also want this as a point of difference – once you’re invited, your excellent recipes won’t be disparaged by random comments about how horrible it is that you eat baby cows or that everything tastes better with horseradish. Sure, this won’t create a top 10 ‘pop’ list of what’s hot in recipes, but a referral-only system means a higher level of trust and in turn, a higher quality of recipes (to your individual taste), on the site.

Personalisation
With 2 main users and 1 main developer, the feedback loop is small. Emails from alpha testers immediately create cases in Fogbugz, leading to a high level of interaction and fast feedback. For the initial group, we can pick up the phone and chat to get helpful feedback – as opposed to responses like “here’s what I think of you and your stupid site !*£$! £*%!$ £*%*” (translated as ‘you might want to get comfortable, this goes on for a long while’).

Pain minimisation
The best way to test software is to get new users to use it. Each new set of eyes highlights usability issues, identifies the most obvious bugs and generates new ideas. By adding a few users at a time, things can be corrected more quickly, so those early obvious bugs affect far fewer people than if we opened it up to all.

Can we handle it?
No. Well maybe we can scale from two to fifty without imploding, but it’s going to hurt a lot less to annoy some of our fantastic early adopters, than to turn away a flood of interest (shh, I know there isn’t a flood, but it’s poor manners to tell the emperor he’s naked).

PS: If anyone is super-keen to take a look, let us know and we’ll add you to the beta list.

A coding … what? Something Japanese – martial arts sounding. On being invited to this event I attempted to figure out what it was I’d been invited to, but first it gets worse. On the mailing list where this event is organised, I discovered that since no-one had volunteered to do it Kata style, we’d be doing a Randori Dojo. Upon reading the associated link I added Fishbowl discussions to the list of things I have no idea about – I’m sure you can imagine what a long list this has become through my lifetime.

Ah, now I think I’ve got it! The exercise goes a little like this – you sit trying to code whilst people break concrete bricks over your head – Shaolin monk style. I wonder how much my coding abilities will be enhanced by repeated concussion.

The slightly less bloody but more truthful version is that a Dojo is just a name for a group doing a coding training exercise (thus the martial arts references begin). A Kata is a prepared demonstration given by one individual to the group – the group presumably learns from the presenter’s approach, design and technique. The Randori format rotates each person attending through 2 programming (pair-programming) positions – 5 minutes in each spot.

Concrete bricks

I got a few things out of attending the Dojo: test driven development in action, complications and just how little code gets written in 5 minutes.

TDD – given the nature of the event, most people were pretty heavily influenced by the TDD kool-aid. However some of the little jibes “…ah, changing the test to match the code – brilliant!” helped to clarify in my head that ‘must write tests first’ actually means there’s no point writing tests that match your already written code – that is, write tests independently.

Complications – it was very difficult for some people to focus on the actual minimal details of the BankOCR training exercise and as an undirected group – well, let’s just say we went wandering off the map – people were worrying about classes that could validate their own input. It was the perfect illustration of the need to ruthlessly keep things as simple as possible (KISS) rather than trying to future-proof – there is no future, it’s a training exercise. Watching people use elaborate justifications in order to validate the one true path was jaw-dropping.

Benefits of concussion

Given that the final code was crazily wide and wild, it’s worth remembering that the point of doing ‘coding training’ like this is to learn something that can improve your real-life coding. I gained some confidence in my abilities by coding in front of full-time professionals. I learnt how much developers love the logical thinking tangents involve – and how dangerous this is when you actually want something done.

Doing it again

This was a first-time Dojo for many of the people who turned up, which made things a lot less productive than they could’ve been. I’ll definitely go back as I understand that as the group gets more cohesive, I can expect to learn more about programming techniques and gain more useful perspectives from the different approaches.

Related note: impressions from the guy who ran the show – http://isanchez.net/2008/12/05/impressions-of-the-first-open-coding-dojo/ (Yes, it takes me 7 weeks to write one post).

What’s your social style?

Based on research by psychologists Dr. David W Merrill and Roger Reid, with help from Dr. James W. Taylor, this tool assesses your assertiveness (whether you ‘ask’ or ‘tell’) and your responsiveness (whether you ‘control’ or ‘emote’) and puts you in one (or more) of the 4 boxes below.

Social Styles matrix

The analytical ones are precise and cool, but get bogged down in those pesky details – your typical techy. The drivers make things happen, but sometimes in an aggressive, bullying way. The expressives are great at drawing us in and selling the story – but will they stick to the story themselves? And the amicables – weak and wishy-washy, we try to make everyone happy.

Sure, I didn’t put the usual, positive spin on these categories, but you get the idea…

I could immediately identify people who fit into each of these categories. And not surprisingly, being an Amicable, the ones I find hardest to get along with are the Drivers – diagonally opposite, and most dissimilar to me.

So where do business analysts fit in?

Good question… surely they are Analytical – I mean, it’s in their job title! But then, they often have to organise people and get things done, so perhaps they are Drivers. Some might use their convincing Expressive skills to get buy-in. But a rough survey of the room told us that the majority were Amicables.

This really does make sense when you think about it. Contrary to popular belief, a business analyst’s main job is to communicate (oh, I do like to harp on about this ;). Not to draw pictures or write documents, but to communicate. And for this you need to be people-oriented. You can’t often use force or power to get stakeholders to bend to your will.

Does this grid really help?

For me, when I gain an understanding of different ways people think, it helps me to work with them better, often because I realise why we’ve been conflicting (apparently it’s not just because they’re an idiot). For Analyticals, be precise and build their trust. With Drivers, stick to the point and forget the small talk. With Expressives, go along with the big idea and fit yourself into it. And the Amicables… just remember to be nice to us!

The bigger, the better?

According to closely-held tradition, developers produce code and working software; BAs product documents. Documents demonstrate to the outside world that yes, we have been doing work, as well as chatting. The bigger the document, the more work it looks like we’ve done.

But when you have a spare 30 minutes, try reading a document your colleague wrote. Or pull out a document you wrote a year ago. Even with hyperlinked cross-references, concise summaries and systematic tables, it will take a whole lot of mental re-arranging before you gain a decent understanding of the software (if you don’t have a document handy, you can bang your head against the wall repeatedly, to get the same sensation).

Software is complicated. It has rules, interfaces, data and more; and business analysts have an understanding of how it all holds together. Putting our understanding into a document that caters to different audiences invariably results in large, unwieldy documents that no one wants to read.

The record of a journey

There’s no question that the typical BA-produced document is the outcome of hard work. But it can’t be allowed to remain the defining work a BA does. Instead, I suggest the documentation should be the BA’s personal record of their journey. I say personal, because there is no ‘one correct way’ to document and these documents depend on the writers’ background, skills and understanding of the software.

We gain our understanding through long workshops, painful negotiations and endless conference calls, then distil this into something orderly and logical. But the real value of our work is our understanding, not the document itself. Looking at it from this perspective, it’s rather egotistical to expect people to gain the same understanding from our travel notes.

Dusty notes in a strange script, or bi-lingual speaking guide?

I am not advocating doing away with documentation – there is no doubt it is necessary. But when your target audience is not yourself, make sure you are communicating in the best way for them. Don’t simply point at your dusty travel notes. You are not answering questions by pointing ever more vigorously!

Currently I communicate with developers and users through a combination of conversations, diagrams, screenshots, spreadsheets and automated acceptance tests – whatever illustrates my point best. And I build up a record on a wiki page of everything I learn. It is publicly accessible, but not publicly advertised. I know where to find anything on my wiki page, but I don’t expect others to. It’s all organised and recorded so it can be picked up by someone else, but this should be treated as an emergency ‘hit by a bus’ situation not the norm.

When a developer asks a question, it’s tempting to direct them to the documentation. Yet that is like handing a foreigner a map to find your local pub, instead of just walking with them around the corner. Less time and effort for you, but a lot, lot more effort for them to get an adequate level of understanding.

So let’s concentrate on the understanding – and leave the writing to the real masters.

Inconsistency

When your solution in one area is inconsistent with every other area in a domain, it’s a clear warning sign that you may be over-engineering. This is a problem because software users rely on consistency to make sense of what goes in the black box that is their computer. When they hit a button, they know an action will be taken. When they go to a new page, it will have the same layout. When a calculation is done, it will be done in a similar way to other calculations. Inconsistency has its place, but you should be aware that it may leave your users in confusion.

One scenario focus

Often these complexities are the result of only looking at one scenario in detail. One of the most useful skills of an analyst is the ability to look at all the scenarios a piece of software ’should’ cover, then to abstract a way of covering 80% of them. If one calculation is much more complex, then it most likely gives priority to one scenario above all others. In my example, the solution solved a scenario that happens once in a year – it’s an important scenario, but it has overshadowed slightly less important, but more frequent situations.

Harder to work with

In my example, the ‘different’ calculation requires additional processes and integration points to the other calculations. Firstly, this creates much more work for the developers. (We’re lucky to have smart developers, so it’s all possible). It also makes the system harder to work with once development is over – special consideration is required when you are adding, changing and maintaining features. Even with a range of super-automated-tests, the fallability of humans (magnified by the fallability of my memory) makes errors more likely in the future.

But what if all this extra complexity is required and just wasn’t thought about enough to begin with? I agree that this is completely valid, just that you need to be sure that the impact to users, developers and all others is considered.

Let’s use authors for our hypothetical, specifically me. I just wrote a book titled “How to genetically engineer shorter necks – No giraffe should be an outcast” in .pdf format (I didn’t, but this is my hypothetical). Now there are two people who want to (or ‘have to’) read it: my two hypothetical friends, Ms Fan in Australia and Mr Groupie in the UK. In our new ‘IP free’ world, Mr Groupie can buy the book and would have the complete legal freedom to copy it. So he emails it to Ms Fan and for her, it’s just as if she bought the book herself – no torn covers, dog-eared pages or delays for postage that accompany the ‘old-fashioned’ style book.

So back in the real world (temporarily only – I quite like the idea of at least two devotees), most authors get their books into book stores via their publisher. However, once devices like the Sony Reader and Amazon Kindle take over from dead-wood books, physical distribution is replaced by the giant copying machine in the sky (aka the internet). As you saw above, without IP laws, the author is not the only distributor, but every reader of the book is also a potential distributor – very effective indeed.

So what’s left for our book publishers to do? Umm, they could serve as a pool of authors’ resources to protect authors rights – that is, sue individual people who try to get hold of a free copy of the book. They could also do a whole series of innovatively ineffectual DRM schemes, like requiring the handful of die-hard paying customers to send a secret code via SMS every 15 minutes that they want to keep reading the book they just “bought” (I mean licensed in 15 minute blocks)… thus guaranteeing that the free, albeit illegal, copy remains far superior in every aspect.

Clearly, if we have no IP laws, then the traditional role of book publishers ceases to exist. Yes, other services such as editing and promotion are still useful, but they become independent services unbundled from the defunct distribution process that currently ties it all together.

But do I really want everyone to get my book (hard work) for free, I hear you asking? Am I really that foolish a person…? The answer is no, but we’ll tackle that next week…

“It’s the what?”, I asked. “Why are the cats wearing pyjamas?”

At first I thought my friend was crazy. Then I realised that I had been living in under a rock and was the only one who didn’t know this phrase. It turns out that ‘cat’s pyjamas’ is a 1920s phrase for ‘a wonderful or remarkable person or thing’, or in Wikipedia’s more restrained language, something ‘beneficial’.

Later that week, I was reading a book on the train and it talked about a product being the cat’s pyjamas. Immediately, this phrased jumped out at me – not just because I now knew what it meant, but also because I’d heard it recently and it was familiar to me.

Permission marketing

I recently heard Seth Godin speak at the Business of Software conference in Boston. (He’s an absolutely amazing public speaker… you must try and see him speak if you get a chance). He brought ‘permission marketing‘ (the opposite of ‘interruption marketing’) to the world’s attention, which is centred around obtaining customer consent to receive information from a company. I was recently reading Paul Hawken’s ‘Growing a Business‘ when I came across a chapter describing how ‘the customer must give your business permission to sell to him’. The familiarity of Seth’s phrase ‘permission marketing’ made the concept stand out for me, among the many other illuminating thoughts Hawken shares.

So what can we learn from these random stories?

Have a conversation about your product, write a story about your idea, encapsulate your point in a phrase. The next time someone hears the same words, it will stand out in their mind. Keep doing this and it won’t just seep into their consciousness like advertising does, but it will ring a bell in their head. And once it’s familiar, you’ll have the attention you seek.

The wisdom of crowds

While reading about a presentation at Agile 2008, I stumbled upon a theory by James Surowiecki, professing that groups can often make decisions that are better than those made by any single member of the group. Digg and Reddit already make use of this by allowing the collective web audience to highlight and vote up pages they find valuable. But why not extend this to all users and all pages, building it into the way we use the web?

Getting to France

I was recently looking for a cheap way to travel to France for a skiing holiday over Christmas. The obvious choice was a plane, but the numerous connections required, the ridiculous level of security at airports and the idea of getting up at 3am to make the flight, made us consider other options. Surely there must be an overnight bus?

I searched for various combinations of ‘bus’ ‘overnight’ ‘France’ ’ski’ ‘please’ but nothing came up. Then I tried overnight trains and came up with more hits. However as the tickets aren’t released for another month, I found lots of pages with data from 2005… useful if I could time travel back to 2005, but not at all helpful now.

So I’d have to wait another month to get more information about timetables and prices but I wanted to do something now to help others in my situation. I can’t ‘anti-bookmark’ it in Delicious. I can’t ‘unlink’ to it so it comes up lower in Google searches. But wouldn’t it be good if I could vote it down (possibly in the browser) and then this information could be linked in some magical way to my search terms, to help others who futilely tread in my footsteps?

Making it work

I know you’re thinking that others have already addressed this. But I’m envisaging two differences:

1. Voting down as well as voting up: sure, this is not the most positive way of viewing things, but I don’t want others to waste time trawling through something I’ve already been through. Many list-based websites already allow you to do this, but they serve targeted content. Which brings me to the second point…
2. I want this to apply to all web pages: whether it’s built into the browsers, Google… wherever; it needs to apply to all content.

Can cheap voting further enhance search results or does relying on higher cost linking (ala PageRank) have an intrinsic value that supersedes voting? Alternatively, could we just accept that an open wiki approach is the only chance to keep highly rated content up-to-date?

Anyone who puts 10 seconds thought into this will probably note that this is expected. As this conference consisted of primarily software developers, that dramatically reduces the number of females, and as many of the attendees were also start-up owners, this reduces the number even further. But why is software, and particularly the business of software, such a male-dominated environment? From my rough count, men accounted for around 97%, not the 70-90% you’d expect from a software company. Is it really all nurture?

Hotel de Sens

I undertook a Bachelor of Business Systems degree in Australia and at that point, the mix was 50/50. As a course that prepared you for consulting, (and continuing to flog the dead-horse of stereotypes), I guess the geeks did Computer Science or Software Engineering and the more business-inclined females went for a Commerce degree. But even from the seemingly even starting point of my Business Systems course, the guys drifted towards programming roles and the girls towards analysis and business roles.

There have been many, many debates on this topic and I know it comes up frequently on geeky message boards (How can I possibly get a girl? I’ve done the maths and it’s 1,000,000:1!). I suspect that the closest scientific answer goes along the lines that men are better at mathematical problem solving (arguably more similar to software development) and women are better at mathematical calculation (arguably more similar to management). But the ‘nurture’ stance and the fact that still more women than men take on child-rearing responsibilities are also contributing factors.

As for starting up a business, Noam Wasserman touched on gender differences in his talk on Rich vs. King. He found that while male and female entrepreneurs are both after power, influence and autonomy, men are more likely to pursue financial goals, whereas women are more altruistic. Perhaps this also contributes to the number of males in the business of software.

These are not overly persuasive arguments. So ignoring these minor natural differences of each sex, is it simply traditional and institutional habits that need breaking? Or does it go further back to child-rearing? What will it take to bring more women into this field?

[* The speakers were definitely much more wow-worthy (than the toilet queues) and posts on the knowledge they shared will follow...]

Identity for a web application means you need something unique to tell Sally and Timmy apart. This unique thing needs to be pretty short otherwise it’ll be immediately forgotten (don’t even think GUID – they aren’t funny, even trying to read one hurts). So why not just use “Sally” for Sally and “Timmy” for Timmy. I think most of us have heard this one before or read some amusing anecdote about how Timmy Jones born 29th February 1964 was denied entry into some country because some other Timmy Jones with the same birth date did something naughty.

Usernames can be short and the user can decide what name he goes by. Timmy prefers “TJ” anyway, so it’s win-win… Ah, not quite in this case, as “TJ” is already taken. So swearing softly under his breath, Timmy tries again: TJ1, nope; TJ64, system lags for a bit before “Sorry, username TJ64 is already in use”. In a bout of frustration, TJ ends up with the simple username of “TimmyJones64_OldSouthWestStreet_FavouriteColourBlue” (he even had to use the UK spelling of “colour” as the US style “color” was already taken).

Next up, the system is going to mandate that he enters an email address – which happens to be, wait for it, a globally unique identifying string: timmyj64@gmail.com (facebook is one of the big guys to realise this). Sure, Timmy still has an ugly username for gmail. However, on our site he uses his email address instead of being forced to make another different ugly username just to keep track of a few recipes.

But, but, what if Timmy decides to ditch gmail and returns to the familar comfort of hotmail instead? (Ah, the good old days of pointless home pages. Inboxes… Only a madman starts their email to look at their inbox.)

No problem, just make it extremely easy for him to change his email address and make sure it’s updated in the right parts of the system.

But then there’s re-authentication. Yes, you’ll have to reconfirm via some new email activation code when someone changes email addresses – but you had to do that anyway. You are allowing people to change email addresses, right?

OpenId? Sorry, I thought I heard one timid voice in the crowd. OpenId is an awesome idea however it’s not (yet) so pervasive that we can ditch our own user management and go OpenId exclusive. That’ll be a good day though.

To summarise: use email instead of usernames as your unique identifier. By letting people optionally add a real name or their actual nickname, you can drop usernames from your application entirely. Just keep making software that tiny bit smaller and less painful.

How can one real user beat hordes of hypothetical companies ready to pay anything for your software? To start with, I seem psychologically incapable of caring what an imagined person or, even more so,  an imagined company *might* want one day – that is, if the stars align correctly and you slip through the corporate software sales process (think feature checklists and friends in the right places). In fact, the only reason I’ve been able to develop anything inside a corporate that I was proud of (note: proud = positive difference to a real person and sharing the excitement) is because I’ve been in positions where I build things to directly help the people I work with every day.

However, back to the point (temporarily I’m sure). With one user in the same room, we can talk, share the problem and see the software used in a real scenario. This gives me a tiny chance of avoiding creeping featuritis. For example:

Geek: “Wouldn’t it be better if we had wiki-like versioning for recipes?”

Non-geek: “Ah sure, that would be cool – I wouldn’t ever have to worry about losing anything.”

Geek: “But what would be even better is if we had multiple users having different views of the same recipe but able to incorporate snippets of each other’s changes as desired.”

Sounds somewhere between good and insane (in the membrane, insane in the brain [Cypress Hill]). Thinking about it from the hypothetical perspective, it’s very easy to think that this would be a really cool feature and we all know that cool feature = people love your software and $.

However, when you mention this to your one real user, she gets really quiet and her eyes glaze over, as she’s too polite to say “Sorry, I think I must have misheard you… you want to spend the next 6 months building a distributed source control system into a recipe site – so I can enter text!?!?” (Her exact unspoken quote).

The simple message – one real user gives you a small chance to continually work at cutting away the deadwood that will otherwise overwhelm and kill your project.

The problem with the way most templates are used is that a single template is designed to encompass a humungously broad range of vaguely related scenarios. Matching this vast, vague template beast to any specific focused software development project I have ever worked on is a painful exercise both for the writer and the reader (on the off-chance your audience tries to read it). Software projects vary substantially: one project may be process focused; another may revolve around the UI; and, yet another may involve purely back-end processing. Sometimes people forget that templates are intended as a starting point, a guide or cue and should never become a rigid exercise of filling-in a form without regard for the purpose of the writing in the first place.

A much better approach is the (seemingly) lazy one – document the least amount you can survive with. Despite stereotypes about business analysts, we don’t have endless amounts of time to write tome after tome, so if no-one will read it, I’m not writing it.

So how do you know what is enough? For me, this depends on the content and the people I’m writing for. To describe a process, a diagram is often sufficient. For complicated business logic, written (or executable) rules may be more effective. When my target audience is a team of senior web developers, I’m not going to detail obvious web validation, it’s a given.

I was recently asked by a developer if I could provide two wireframes for each screen. One ‘clean’ one which showed the controls, the other also showing the controls, but annotated with rules and validation. I have no problem with this. For me it doesn’t make much difference if I am communicating these rules in a table, as notes or verbally. As long as my audience gets the picture, I’m happy.

There are some advantages to this unilateral approach. Firstly, it’s much quicker to write on your own – no waiting for a glacially slow editor. Secondly, for a contentious topic (or even a seemingly uncontentious topic), a coherent argument makes much better reading than a schizophrenic arguing from every viewpoint. Thirdly, a personal voice can be lost in the noise of differing writing styles when there are too many contributors.

The flip side? In this era of increasingly cheap collaboration, co-writing can help you flesh out and improve your ideas before you release them into the wild. When I’m ranting about “software and process patent insanity” or “why an imperfect wiki is better requirements than a perfect document”, I might notice that my co-author has fallen asleep – in turn saving you from a great deal of pain. Having a peer means the old-fashioned benefits of a newspaper editor, relevance, accuracy and hilarity, are gained. And (not that there are any), but any weaknesses and quirks are identified and ruthlessly squashed.

So this is it, right here – one blog, two writers.

I love ideas that make you think – those classic light bulb moments. Not ideas which slip out the backdoor of your head before you’ve even finished reading. But the the ones that ring a little bell of clarity, that seem so obvious you can’t believe you didn’t say it yourself.

The Internet is a gold mine of these ideas. Information is supposed to be instant, at your fingertips. You don’t need to physically gather a group of like-minded friends together, invest hours in a book or a movie, to feel inspired. But that accessibility is also the problem. Unlike in book publishing and the movie business, the barrier of entry is so minimal, that it’s easy for  people (like me) to put up a post and add to the growing debris mountain. I joined a secret group recently and was so overwhelmed by the amount of activity on the site that I didn’t know where to begin contributing, for fear of repeating thoughts voiced 30 pages (or years) ago.

Power to the people

So how do you wade through all of this? When you’re a child, it’s easy. You absorb everything and rapidly assemble sequences in your mind. But when you’re an adult and those thoughts are set, you tend to simply re-arrange rather than build new sequences. To change your thinking when you find a golden idea requires conscious effort.

The huge, unwieldy ball of mostly horrifically bad ideas used to be funnelled (and maybe censored a little or a lot) by gatekeepers. With the power of traditional leaders diminishing, who or what will take over? You will, and since I’ll be reading it you’d better not be letting garbage through. With the internet, we all become not only the content providers, but also the funnel. Finding valuable content is really now our responsibility.

Tagging

Yet it’s not easy. Digg, delicious, networking groups – these tools all help. But unless you stumble across an amazing idea or have time to spend hours searching for one, it’s more likely you’ll find it through a recommendation. However for recommendations to be effective, they need to come from someone who values similar things and can offer a different perspective.

Pushing the funnel analogy too far – the sizes and numbers of funnels is crucial. If there was one big funnel that let everything through to cater for each individual, the value of the funnel is defeated. Similarly, if every individual had their own funnel, the value of a group of people is lost. So both specialisation and diversity are required, which is no easy task – this is where the simple beauty of tags really lies. Multiple tags on a blog post funnels it to diverse destinations, but the choice of words different people use allows for maximum (limited only by language) specialisation.

What your tags say about you

When you forward a post to someone, you’re saying to them, ‘This is what I think about you – what I think you like’. But you are also saying something about yourself, especially if you qualify your recommendation. ‘This is good, but it rambles a bit’ refines what you value even further.

It’s the same with tagging, voting, inviting and other tools of a community. They are all subtle ways of declaring ‘I’m a fan of…’, of showing others a part of you. In the Web 2.0 world, you are what you tag.

References

How Adults Learn