Ok, the elevator pitch is pretty straightforward: Go Test It helps web developers to test automatically whether their site works correctly in different browsers. The technology works well and lots of people are using it successfully.

But how much does that really tell us? Is it really the web developers who need us, or should we aim at the testers, the user experience managers, the web content administrators, or the sysadmins? Are those people in big enterprises, small web consultancies or are they freelancers? Do they use PHP, Ruby on Rails or ASP.NET, and which JavaScript framework to they use? Do they have a dedicated QA team or do the developers do the testing themselves? Does their work have to be signed off by a client or are they doing it for themselves? How do they currently test their application, and how would we fit into their workflow? Do they develop websites for a particular industry, e.g. education, finance or healthcare? Do they need a big consultancy contract, do they require the product to be customised, or do they just want a straightforward self-service sign-up over the web?

It is simply not possible to serve all different market segments and niches at the same time. You’ve got to choose: resources are limited, and you’ve got to pick your battles wisely. But I am guilty of not properly thinking through the segmentation and figuring out the best way of targeting a particular niche.

For the Business of Software 2009, Joel Spolsky organised three startup workshops aimed at covering the main areas of difficulty faced by software and web startups: marketing, product pricing, and finding your first 100 customers. Exactly those areas in which I am guilty of negligence.

Neil Davidson and Simon Galbraith of Red Gate were in charge of the “finding your first customers” workshop, and they asked me to help them design the workshop. Since my startup is one of the companies in Red Gate’s “accidental incubator”, and it’s at the stage of finding the first 100 paying customers right now, Neil and Simon suggested that we use Go Test It as a case study for the workshop.

What we wanted to do is to ask a number of key questions about the market positioning of a product and aspects of the sales process — crucial questions for startup founders, but also questions which are easy to ignore if you focus too much on the technology. By discussing a case study in the workshop, the participants could practise thinking about and answering these questions in a fresh and unfamiliar context, and develop tools and techniques which they can apply in their own companies. We chose questions that are relevant to any early-stage B2B software company.

The workshops worked out really well, and so we would like to release the materials we created for this workshop under a Creative Commons license and make them available to startups everywhere. You can download the worksheet (PDF). I have also written up how we structured the workshop and what we learnt in the process.

Below I have added some notes to clarify what we mean with each of the questions. I give several illustrative answers for each, but please remember that they are not multiple-choice questions. The whole point of the exercise is that you come up with your own answers!

1. Sales objective: what are you hoping to get out of your customers?

   At first sight this seems a pointless question: of course you want your customers’ money! However, think about it a bit harder. Maybe getting some great case studies and testimonials is worth even more than the money, because they will help attract more of the right sort of customers. Maybe you really want feedback to help improve the product (feedback from paying customers is worth much more than feedback from free-riding users, because paying customers really care!), or maybe you want to learn about the sales process — what does your customer’s org chart look like, what are their key external relationships, and who are the key people you need to get onto your side? The things you can learn from a customer are potentially worth a lot more than the cash they hand over to you.

2. What is the pain point addressed by the product?

   A standard question, but worth revisiting from time to time, because the answer may not be as obvious as you think. In the case of Go Test It, the obvious answer is “needing to make sure that the site works in all browsers”. But ask yourself: why does it need to work in all browsers? To provide a good experience to all users, so that they continue using your site even if they are using an obscure or buggy browser? Or maybe it’s a matter of meeting a compatibility warranty given to a client, or passing certain acceptance tests? Is it a tool for people to cover their back within their organisation?

   Or maybe the customers currently do manual cross-browser testing, and their real pain point is actually the release cycle duration (very slow in manual testing), or the staff requirement (manual testing is too expensive), or staff motivation and turnover (manual testing is repetitive and boring, leading to low job satisfaction)?

3. What is the sales process?

   Startups often worry a lot about marketing (figuring out who to target and how to get on their radar), but neglect the following step: now that you’ve got people’s interest, how do you convert them into paying customers? Giving them a form to enter their credit card number is well and good, but what about people who trial the product but never quite get round to signing up to the paid version? Will some follow-up emails be sufficient, or do you need telesales people to get on the phone and talk to the customers? Do the customers require help importing their data into the system or even an integration project? Maybe you need to give demos or seminars at customers’ premises, or even learn to play golf?

4. What do you want your marketing to achieve, and how could you measure it?

   Your end goal is probably “get lots of paying customers”, but there are various possible intermediate goals along the way. Depending on your strategy, different things may be important. Do you want to maximise the number of free trials to which people sign up, or the number of newsletter signups, the number of Twitter followers or community members? Or would you rather focus on a small number of customers and optimise for high-quality leads and maximise level of usage? Do you want to go “viral” and maximise the number of referrals from each customer while minimising the time to referral?

   Intangible but maybe equally important aspects of marketing might be promoting a positive brand image, building a good reputation, and encouraging users to become passionate evangelists for the product. You might still try to measure these kinds of things by monitoring Twitter for keywords and informal surveys, but they are difficult to measure quantitatively. Whatever you want your marketing to achieve, remember that your resources are limited, and hence you should probably focus on two or three achievable and measurable goals.

5. What will you do to achieve your marketing goals?

   This is a question about marketing channels: how are you going to get noticed? Social media and online communities, comprising blogs, Twitter, LinkedIn, Facebook etc. are probably the most hyped these days, and for some market segments they are indeed an excellent marketing channel. But you could also consider networking in the right circles, PR (including connecting with influential bloggers and getting them to write about you), attending conferences and trade shows, creating publicity stunts, competitions and much more. Hey, even advertising isn’t dead yet.

6. How will you allocate money and time over the next 3 months?

   This does not have to be a detailed budget, but a quick sketch of a pie chart will help you to think consciously about your priorities and make them actionable. How much of your resources should be allocated to engineering, sales activities, various marketing channels, learning from customers, etc.?

7. How will you price the product?

   It’s easy for engineers like me to spend a lot of time thinking about pricing, because it’s more within our engineering comfort zone than most of the other questions on this worksheet. Yes, it’s important (that’s why we included it), but only in conjunction with the other answers. This is our only multiple-choice question, encouraging you to answer it quickly and move on.

   Do you want to publish the pricing on the website for everybody to see, or do you want prospective customers to contact you for a quote? Will you have a fixed price list, or will you negotiate pricing individually per customer? And the most tricky: if you can’t do flat-rate pricing, how will you split pricing into bands? By number of users? By length of tests? By level of usage? By availability of features?

8. What will you change about the product?

   Once you have settled on a particular market segment and strategy, certain limitations in the product will become apparent: maybe some additional features are needed, maybe the technology needs to be presented differently in order to fit with the users’ point of view, maybe some unnecessary features can be removed. The important point is that product changes should be informed by the market, not just a preconception of what users will want.

9. Top 3 things you must do in the next 3 months?

   This could be anything: marketing, sales or engineering activities. The key is just that these tasks must be actionable: it must be clear how they can be done and they must be feasible now. “Build a community of 1,000 people working in this field” is not actionable, but “set up a Facebook page, blog about it and invite all of our friends to it” is.

10. If your users are superheroes, what is written on their T-shirts?

    As a final question, remember that users are human beings too. They don’t particularly care about your product as such, but they probably care about things like doing a good job, looking good with their peers or boss, having a sense of belonging, getting to go home early, and making a difference. Your product should turn your users into superheroes: give them exceptional powers which make them proud! So proud that they will want to wear your product motto on their T-shirt. What will it say? (Hat tip to Kathy Sierra, inspiration for this question.)

If you can answer all of those, you will have covered a lot of ground and will have a pretty good idea of how your product fits into a particular market segment. And in case that wasn’t enough, here are three bonus questions from our drafts which didn’t make it into our final worksheet:

11. Which key factors determine whether a potential customer will convert?

    This question complements the sales process (question 3 above). If the sales process is about the actions you can take to convert interested people into paying customers, then this is about setting the right environment for conversions. What do customers care about? Is it the ease of integration with their workflow, the user experience, the amount of learning required, the level of support, references from other customers, key features, integration with systems they already use, reassurance that your company is not going to disappear overnight, or anything else?

12. What underlying need is satisfied by the product?

    We have already talked about the pain point above (question 2), which defines why there is a need for your product. However it can be insightful to look behind the pain point and figure out why it exists: the “need behind the need” in the words of Paul Kenny. When a customer buys this product, are they really buying reassurance (security, peace of mind, covering their back)? Or are they buying ego (competitive advantage, ability to overcome difficult problems)? Are they interested in convenience (making their life easier), saving money or reducing risk? This underlying need should determine the light in which you present your product and how you pitch it.

13. What would you consider to be success, and how would you decide whether to abandon the project?

    This is an interesting one: not many people talk about criteria for success and failure. Usually success is unbounded — you always feel like you could do better, no matter how well you are doing. And failure is something that is not talked about, as if merely contemplating it would bring about a jinx or induce an unwanted pessimistic vibe. However, if you have a quantitative criterion for deciding when to cut your losses, you avoid giving up too early just because you’re feeling down.

With all these questions, keep a few principles in mind:

• Resources are limited, so you should focus on the things which are likely to be most useful.
• “Just try it out” and “talk to our users” should be part of any strategy, but they are not strategies in themselves. You’ve got to know what you are looking for and what questions to ask the customer.
• Argue why the actions you chose are the most appropriate, given the product, the market and any constraints.

Download the worksheet (PDF) and an example we filled in (a contrived example based on the fast food industry — not model answers, just to illustrate the kind of answers we’re looking for). Please also see my separate post on how we ran the workshop.

Did you find this useful? Please leave a comment, subscribe to my RSS feed or follow me on Twitter!

Photo credit: John of Austin on Flickr; Creative Commons license.

Update (2009-12-18): Added scanned example worksheet.

The workshop was aimed at startup founders and was centred around the topic of finding your first 100 customers. There were also two other workshops: one by Dharmesh Shah on marketing, and one by Joel Spolsky on product pricing. Three rotating groups of startup founders participated, and each workshop happened three times, so everyone got to go to each one.

I was to help Simon and Neil, who wanted to strike a tricky balance in their workshop: they wanted maximum interactivity for the participants, but also provide enough structure for the workshop to make it more than just a chat. Together with Amir, and with advice from Pam of Innovia Technology we came up with this workshop format:

• In a workshop of 20–24 people, allocate people into 6 teams of 3–4 people each. That’s the ideal team size: large enough to get an interesting discussion going, small enough to give everybody plenty of “airtime”.
• The 90 minute workshop is split into about 10 minutes introduction, 45 minutes work in the small teams and 25 minutes presentation of results and discussion. (Yes, the numbers don’t add up. Some time is always lost in general faffing.)
• Each team analyses the same product, but applies a different strategy. That way, when results are presented at the end, everybody is on the same page, but interesting discussion points arise from different teams taking quite different approaches to the same problem. Neil and Simon suggested using my startup’s product Go Test It as case study since it is one of the companies in their “accidental incubator”.
• To structure the group discussion, we give each team a worksheet with ten key questions. The worksheet is printed on large-format paper (about A1 poster size) so that it can be filled in with marker pens and all team members can sit around it easily.
• Neil, Simon, Amir and I rotate around the room as facilitators. We don’t just ask “is everything clear?”, but stay long enough with each team to get involved in the discussion. If we feel they are getting side-tracked or missing an important point, we inject suggestions to get them back on track.
• There should be enough time for team members to get to know each other; the workshop serves a networking purpose as well as an educational purpose.
• Participants should learn from each other and develop new ideas and insights through bouncing thoughts off each other, not just off Simon and Neil. The Business of Software conference attracts many bright and motivated people, and with the right framework in place, there is a potential for the workshop to be a lot more than the sum of its parts.

We had put a lot of thought into the worksheet beforehand, trying to make it a comprehensive but concise summary of the key ingredients to successfully marketing and selling a product. We found that it worked very well, but we had to be very careful at the same time: those boxes on the sheet, designed with open-ended questions to gently lead the direction of the discussion, could easily become a counterproductive limitation.

It’s strange how people fall into roles depending on the context: when faced with a worksheet and boxes to fill in, I could see some people instinctively falling back into a primary-school, do-what-the-teacher-wants-me-to-do kind of thinking. I don’t blame them; in a similar situation I would have probably behaved like that too. Fortunately, when we explicitly emphasised that we wanted people to brainstorm freely, to (literally) think outside of the box and not to take the questions too seriously, that barrier fell away and the ideas started flowing.

Some teams even redefined some of the questions, which is great — startups should always be questioning any apparent rules! But the worksheet was nevertheless helpful, because it gave a structure and a goal to each discussion, allowing the teams to maintain a swift pace and avoiding getting bogged down in minutiae.

As an aside, we asked each team to come up with a name for their team, and also to put their real names on the sheet. It’s a simple psychological trick which encourages the participants to take ownership of their work and thus care about it more.

Defining different teams’ strategies

We asked each team to consider Go Test It as a case study, and to examine different strategies for marketing and selling it. In principle, the technology is appropriate to any web development project, but the world of web development is too big as that we could market to all of it at once.

How do you segment the market and find a niche to focus on? Well, we came up with six different dimensions which you could use for segmentation:

• Segment by technology (e.g. using .NET, PHP, Rails, Django or Java on the server; and using jQuery, ext.js, YUI, Dojo etc. for the JavaScript)
• Segment by job role (e.g. developers, testers, user experience designers, web content managers, product managers)
• Segment by company type (e.g. agencies and outsourcing companies, startups, web-based software companies, non-software companies)
• Segment by company size (e.g. individual freelancers, <5 people, <20 people, enterprises)
• Segment by level of service (e.g. hands-off self-service, per-customer customisation, big consultancy projects)
• Segment by industry (people developing web sites e.g. for the finance sector, for healthcare, or for education)

We allocated one particular segmentation to each of the six teams, and asked each team to pick one particular segment based on their experience and interest. For example, we would allocate “segment by company type” and they might pick e-commerce retailers as their particular segment. That choice then determines their strategy for the rest of the session.

This approach of letting teams choose their own segments worked very well: there was of course some overlap between different teams’ results, but we also saw a broad spectrum of different approaches, including some really creative ideas. This allowed individuals to play to their strengths and bring in experience of their own businesses’ market segments, while at the same time keeping the workshop interesting and inclusive to everyone. I think we managed to strike a good balance here.

If I have a chance to run the workshop again, I think I will focus on improving the discussion phase of the workshop: potentially we could have made more of it by contrasting different approaches, and figuring out why some actions are appropriate to some strategies but not to others. Of course, you never know what the teams are going to come up with, so this is hard to plan in advance.

All in all, I think it was a very useful workshop for everyone, and the feedback we received was uniformly positive. If you have any thoughts, please leave a comment or drop me a note on Twitter.

Demoing alongside me were four other startups: CamVine, mbed, CycleStreets and WebTicketing. I thought that all of them had very slick, impressive and credible demos (and judging by the positive feedback I got, my own one seemed to go down quite well too). I had not seen most of them before, but the message they got across in just seven minutes was so powerful that I’m immediately convinced of their potential, and since the demo night I’ve even been going around telling other people how awesome these startups are. That’s powerful stuff.

So how do you make a demo which will convince others that you are great and that they should tell all their friends about you?

Well, first you actually need something substantial to show. A product, a web application, something which is new and interesting and solidly built. I don’t believe in vapourware demos; you’ve got to show the real thing. However, for most companies I know in Cambridge that’s really not a problem — many have very impressive products, they just don’t know how to communicate them.

Even if you have a great product, you can still wreck it with a bad presentation. I’ve seen that happen and it feels tragic, so please do yourself and your audience a favour and make it a good demo. It’s not that hard, and these are the guidelines I set myself when preparing my demo. They may not work for everybody, but they worked well for me.

1. Know what you’re going to say

When I was at school, the only role I was allowed to play in the drama club was to be the lighting technician at the back of the room — no chance anyone would let me near acting. That’s because I can’t remember scripts word-by-word for the life of me, and even if I could, I feel really silly when reciting learnt lines. Therefore I have no choice but to speak freely.

However, you do need to have a pretty clear idea of what you are going to talk about, and how long it is going to take, if you want your presentation to be slick. You do need a script in the sense that you need to decide beforehand:

• exactly which buttons you are going to click, and
• which topics you are going to address.

Then speak the whole thing out loud twice. I find twice is a good number because I get a good feeling for how long the demo is going to take — essential when the presentation is strictly timed! — but I don’t feel over-rehearsed and therefore silly either.

I like things to start with a few slides introducing the issues your product solves. This gives the audience a context and makes your solution look stronger. But I wouldn’t spend more than 20% of the time in Powerpoint/Keynote mode; for example, in a seven-minute presentation, you should be in the actual demo after about 80 or 90 seconds.

Embrace these time constraints. They force you to be clear and to-the-point. Twitter is so successful precisely because it forces you to be short; it wouldn’t have worked without the 140 character limit. The same is true in presentations and demos.

2. Make it work offline

Don’t underestimate this issue. There are almost always technical problems in any venue, and most usually they are either bad internet access or problems with the projectors. Bad internet access is the most common. There’s no point in relying on a 3G card either, because probably reception will be bad in the Faraday cage that is your demo venue, and if not, the network will be overloaded because everyone is tweeting. There’s no way round it: your app has got to work offline.

And even though you probably have a full development environment on your laptop on which you can run your app, there are plenty of places where you’re accidentally relying on internet access. Some of my favourites:

• You’ve copied and pasted the Google Analytics/UserVoice/whatever JavaScript snippet into your page. When you’re offline, that script won’t load until the network times out, and so the browser’s page load event doesn’t get fired until 30 seconds later. But all your funky graphical effects only get initialised when the page is fully loaded, and suddenly you have no animations, no Ajax, nothing! It’s almost like the 1990s!
• You want to demonstrate clicking a link from an email, which opens a particular feature in your application; however, that email you sent to the test account contains the production site’s URL, not the address on your local machine.
• You are relying on hostnames provided by a DNS server on another network.
• Some easily forgotten part of your infrastructure (your mail server, memcached, message queue, mashed-up web service, …) is not on your own machine.
• Your Delicious Bookmarks Firefox extension (or other) tries to connect to its home server via an SSL connection. Since you’re a new guest to the network, the wireless access point intercepts the connection and inserts its own login page; of course its SSL certificate is invalid though. The result? An annoying SSL certificate warning dialog which pops out of nothing every two minutes.

To make sure your application works offline, fully disconnect the network on your laptop (or even better: go to a café with a dodgy public WiFi that intercepts SSL!), clear your browser cache, and make sure every step of your demo still works flawlessly. Make sure you leave enough preparation time to fix things that don’t work — it took me the best part of a day to make Go Test It work without an internet connection! And I had to use, believe it or not, various entries in my /etc/hosts file and even an ssh tunnel to localhost (for remapping ports). Yes, a bit crazy, but it worked.

In the demo night on Thursday we actually had the projector problem rather than the internet problem. But you’re on the web, right? It shouldn’t be hard for you to demonstrate your application on someone else’s computer. Even the hardware guys, mbed and CamVine, pulled off their demos smoothly using a computer they had never touched before!

3. Make it 100% reproducible

An interesting demo probably involves manipulating data somehow, and once data has been manipulated, it usually doesn’t like going back into the state it previously was.

You, however, should be able to run your demo several times, doing exactly the same steps each time. That means after each run of your demo, you need a way of quickly and reliably getting back to square one. And of course you need a well-defined square one in the first place.

Your development database will probably contain lots of edge-cases: excessively long strings, weird international characters, and other oddities from the times when you’ve been testing error handling. That’s not what your typical user’s data would look like, so I suggest having a separate database for demo purposes, with selected and nice representative example data.

Then you must write down the steps for getting back to the starting state you expect at the start of your demo: the database records you need to delete or add, the files you need to restore, the sessions from which you need to log out, the cookies which you need to clear. Or even write a shell script to do that for you. The last thing you’d want is that you can’t demonstrate a key feature of your application because some old data from your last trial run got stuck in there!

Another thing which you should write down, if you haven’t already, is exactly how to get your development environment up and running after a reboot. For a full Go Test It development setup I need about a dozen terminal windows open, each running a different process with an arcane command line, each providing a different part of our infrastructure puzzle. When I’m under stress I probably won’t remember every command correctly. They are all documented, of course — on our wiki, which is only accessible on the web. Print it off beforehand.

4. Clean laptop setup

If you’re anything like me, you’ll have tons of files on your desktop, a whole host of applications running, alerts popping up from time to time, and more. Some of this might be confidential. None of this should be appearing on the large projected image of your screen.

The easiest solution, I find, is to have a separate system user account to which I log in only for demos. It is stripped down to the minimum:

• blank desktop,
• menus only contain the apps which are absolutely required,
• no unnecessary Firefox extensions (see the Delicious problems above),
• screensaver disabled.

When using the second user account, you can still stay logged in to your primary account at the same time, and have all your terminal windows and stuff open there. It makes sense though to shut down all applications which are not required for the demo: TweetDeck, for example, is a notorious memory hog, and it would be a shame if one of the pages in your demo suddenly takes 10 seconds to load because a shortage of memory caused Firefox, your application server or your database to be paged out to disk.

Also keep in mind that projectors typically have a resolution of 1024×768 — make sure you’ve tested in advance what your website looks like at that width.

If you need to press arcane key combinations on your laptop to enable an external monitor, make sure you know exactly what those keys are, and that you’ve tried them beforehand.

5. And now, enjoy it

With all that preparation, there is nothing which could possibly go wrong. Sit back, take a deep breath and relax. Public speaking is an honour and a privilege, something to be enjoyed and relished, not something to be nervous about. Do your best to be focussed and relaxed, speak loudly and clearly, and smile at your audience. And it will work like a charm.

I believe the talk was also recorded on video, and I will update this post when the video becomes available has been posted on Skills Matter’s website (also embedded below) — thanks for recording it!

Update (28 July 2009): I’m pleased to say that my talk also received 4.11 out of 5 points on SpeakerRate, clearly above the average of 3.92 out of 5 for that conference.

Note that the Invoicing Gem still isn’t Rails-specific — although the generator currently only works with Rails controllers and templates, the core of the gem depends only on ActiveRecord and can be used with framework components of your choice.

To demonstrate just quite how quickly the invoicing gem allows you to add commercial features to your application I decided that it would be a good idea to have no slides, but to spend the entire 25 minutes I was allocated to give a live demo. That is rather scary for a speaker because a million things can go wrong (and indeed several things did), but with a forgiving audience it ended up also being a lot of fun.

Skills Matter, who host the LRUG events, kindly recorded the talk and put it online. I have also embedded the video below:

It’s a bit hard to see exactly what I’m typing in that video, but you can follow the exact steps from the notes I wrote myself for that presentation, and the example application I used, cracktastic, is also on GitHub.

I have the feeling that I still need a lot of practise to improve my public speaking, but it’s not too dreadful either.

• Getting started with the Semantic Web – Get Semantic Wiki
• Freebase Parallax, a new user interface for browsing Freebase
• BBC programmes use RDF: e.g. Doctor Who – in RDF
• SIOC (Semantically-Interlinked Online Communities) is an ontology/vocabulary for expressing social links
• FOAF project
• Searching semantic web data sources: Sindice
• SPARQL/Update or SPARUL – for modifying RDF data stores
• POWDER – define sets of URLs?
• Simple Knowledge Organization System (SKOS) – simpler than ontologies, without inference?
• Rule Interchange Format (RIF) – define inference rules

(OMG mad W3C acronyms!)

I also heard Sian Clark of Yahoo speak about SearchMonkey at BCS Search Solutions 2008. This is a very interesting development, allowing site owners to annotate their pages with structured information (using RDFa or Microformats), allowing them to be presented more meaningfully in the search results. A great idea I think!

This move by Yahoo starts giving a first convincing answer to the chicken-and-egg problem of the semantic web: “why would anybody bother to annotate their data in a machine-readable way?” There has got to be some reward attached to it, and doing search engine optimisation (SEO) for Yahoo is a very good reason for creating some semantic metadata! (It’s unlikely to really fly until Google also adopts the idea, but surely that’s just a matter of time.)

What I wonder about: what attempts will there be to parse structured data out of unstructured data sources? There are a few companies doing more or less this, for example Globrix extracts structured information about properties (rent or buy, location, price, number of bedrooms and bathrooms, etc.) from plain text descriptions on estate agents’ websites, and Mydeco extracts structured information about furniture (type of item, colour, width/depth/height, weight, retailer’s location, etc.) from similar unstructured text. There is no technical reason why they couldn’t release that information in a machine-readable RDF format, although there may well be commercial reasons for them wanting to keep it to themselves.

Here are the slides from my presentation:

(View on SlideShare or download as PDF)

I had some very good conversations with several people after this presentation, amongst others Jonathan Melhuish who pointed out that about two years ago there was a start-up called Autoriginate, founded by Patrick Lightbody, which aimed to provide a hosted on-demand Selenium-based testing service called HostedQA. HostedQA does not appear to exist any more in its current form, and I only found a bit of information about Autoriginate and HostedQA in the Wayback Machine.

I’m not completely sure what happened to HostedQA, but the evidence suggests that Autoriginate was acquired by Gomez and became what is now their Reality Check XF product.

We use Selenium quite a bit now, and I know that it’s a bit of a hassle to set up so that it works neatly; so one might think that I should be attracted to buying their solution. I don’t mind paying for tools which make us more productive (we pay for Highrise and FogBugz, for example), but somehow Gomez looks very unappealing to me. At least part of that is because they don’t provide pricing information on their website, and don’t have a sign-up button. A while ago I was considering them and actually tried quite hard to find out more from them. They were not particularly responsive by email, and they made me speak to two of their people in a phone conference for 20 minutes before they would tell me how much they charged! Maybe that sort of sales strategy works when selling to large enterprises, but for small development houses like ourselves, the attractiveness is zero. Bizarre. Maybe their technology is fine (if they did acquire Patrick Lightbody’s work it may even be very good), but for me they are irrelevant because of their sales methods.

The weekend has been full of new ideas, so I will just jot down a few bullet points and links to some of the most interesting things before I forget.

Coworking, social connections between freelancers:

• The Werks, a coworking organisation in Brighton
• Coworking worldwide on the Coworking Wiki

Semantic Web, managing structured/interconnected information (thanks to Tom Morris for most of these links):

• ONEIS has an interesting-looking approach for storing internal information within an organisation — simple and flexible at the same time.
• DBpedia has extracted structured information from Wikipedia, put it into RDF form and allows various ways of navigating and displaying the information.
• Don’t implement your own RDF parser (it’s really quite complicated). Use Jena (Java) or Redland (C).
• Use N3 (Notation 3) when writing RDF by hand to avoid XML syntax madness.
• FOAF – description of personal connections using RDF. I heard of ages ago, but only gradually beginning to appreciate how useful it may be. (Social networking without being locked into particular sites?)
• VoCamp (Vocabulary Camp), a BarCamp-style meeting in Oxford where people get together to define ontologies for specific subject areas. Another camp planned in London for November?
• Fresnel is a language to describe how to display semantic web data.
• The National Library of Sweden makes its catalogue available in RDF. E.g. Pippi in RDF/N3 and RDF/XML.
• The Linking Open Data dataset cloud diagram (linked from linkeddata.org)

Tags: barcampbrighton3

But about everyone and anyone has written a review of it already, and there is no need for me to add yet another one. Still, there’s something special about it. If I mention the words ‘mobile’ and ‘user experience’ to anybody in conversation, I almost inevitably get ‘iPhone’ back. Why?

“First Apple made the hype, and released the hype as a product. Then they released the iPhone as the follow-up product.”

– Charles McCathieNevile (Opera Software) at FoM2007

Maybe the right question should not be why the iPhone is so good, but rather why the handsets of much more established manufacturers are so bad (in some respects, notably usability). Some interesting insight came from Tom Hume and Marek Pawlowski on a FoM2007 panel discussion:

• The mobile handset industry has a structural problem. The manufacturers are very focused on R&D and on features, and within a single company there may actually be different groups advocating different technologies and features, all competing to be integrated into the next line of handsets. The design process is fundamentally bottom-up, rather than starting from high-level requirements and working down towards the features. The result is a user experience which consists of a bundle of fairly detached features, and is not at all consistent or well structured.
• Another problem with handset manufacturers is that they are extremely risk-adverse. This is because managers’ bonuses are calculated based on the number of defective handsets returned to the manufacturer — a direct incentive to make their products robust and reliable. So far it sounds good. The problem is that there are certain features which carry a higher risk, but have potentially huge benefit — the most notable one being automatic software updates — and these features get omitted too. Currently it is still the case with most handsets that once it has left the factory, its software is never updated. As phone software begins to become extremely complicated and time to market is extremely short, major bugs in the software are inevitable. And without software updates, those bugs will only be removed if you manually update the firmware (which hardly anybody does), or when you get a new phone.
• Finally, handset manufacturers don’t usually have their own retail (or have you seen a Nokia store anywhere?). They sell through the mobile operators, and entrust the sales process to people completely outside their control. Moreover, since they don’t have much direct contact with consumers, they get hardly any useful feedback about their products which could feed back into the design cycle. Instead, they just continue to produce more and more phones based largely on speculation of what people actually want.

All three points are different with Apple. The user experience is clearly the most important part of their design, and features are secondary. They regularly update the software, and in fact they have already released a number of improvements which would have never reached the previously shipped devices without this update facility. And they have their own shops, in fact a whole fan base which they actively nurture — what better way to learn how to improve the next version?

And the model clearly works. The iPhone really is a pleasure to use, the experience is consistent and well thought out — it simply feels right.

But what will its longer-term effects be?

The iPhone is just one product, and even if Apple’s highly optimistic sales forecasts were to come true, they would still have less than one per cent market share. I think that the true value of the iPhone lies not in itself, but in the knock-on effects which it is having on the whole mobile ecosystem:

• It has raised the bar in terms of design and usability, and other manufacturers will be rushing to improve their own designs similarly. (For example, Nokia announced a similar touch screen user interface only a few weeks ago.)
• It is helping enormously to raise awareness for the mobile internet — people are beginning to see the potential in having internet and web access on the go.

These effects are both rather good, and although I probably won’t be getting an iPhone myself anytime soon, I think these are very good developments.

• The mobile market is HUGE. Seriously. Billions of people worldwide have mobile phones, and more people worldwide access the web from mobile devices than from desktop or laptop computers. By 2010, half the world’s population is expected to be subscribed to the mobile web. A lot of this is driven by developing countries, where mobile is a far better solution for communication than a fixed-line telephone infrastructure. But it is also a growing trend in the developed world.
• A great user experience is absolutely essential if you want to get people to use your services mobile. The mobile user’s attention is extremely limited: unlike on a computer or a television, where people are more likely to patiently try to come to terms with bad usability, mobile users have plenty of other things to do. If they can’t immediately and very quickly find or achieve what they want, they are gone immediately. Mobile content must therefore be extremely clearly and intelligently structured, presented in an engaging way, glanceable, simple, and be fluid to interact with.
• Communication is key. People want to talk, create, share, explore — not just passively consume. A mobile is always with you it, it where your life is happening, it is a point of creation and lies in a rich context. The future possiblities for the social use of mobiles is something we can only just begin to envisage.

Amongst the speakers, possibly the most keenly awaited was David Burke of Google, who was the first to present Google’s new Android platform in Europe. See this post for more on his presentation.

Finally an interesting quote, very much in rhythm with the drum I am bashing:

 ”Mobile users are ready and willing to engage with their favourite brands on mobile devices.”

– Matt Millar, Director of Mobile and Devices EMEA at Adobe