Solitude

I signed up to Dopplr, a social networking site for travellers, a good long time ago. After the to-be-expected initial flurry of activity, I can count on one hand the number of times I’ve logged into it. Most of those times were because a friend had noted that they were making a trip to Glasgow in the near future (it was the same friend on every occasion). To me, that’s not a particularly good amount of usage.

I think one of the biggest problems that Dopplr faced in its early (and critical) stage is that it is yet another social network at a time when people were starting to grow weary of signing up and amassing their friends again. Myspace and Bebo had already started to become less commonplace, and Facebook was taking over. Given that a lot of people viewed joining up to a general social network as a potential hassle, the chances of them joining up to a single-application social network was not going to happen.

That’s the lesson here: if you have only one particular domain of interest (whether travel, music, art, business etc), don’t try to build a social network around it. It takes a lot of people to get these things moving and by the very essence of operating in a niche, you are extremely unlikely to succeed in capturing much attention.

A better plan: let people use an existing social network to use your application. There’s much less friction that way. You only have to convince people that you’re worth their time, rather than having to do that _and_ convincing them to part with their time to help your application work.

Given the abundance of music in the modern age, it’s becoming increasingly difficult to find ways of getting music out to interested parties using traditional means. Most musicians don’t have the money or backing for widespread advertising and almost certainly couldn’t capitalise on it even if they did. Just because you’ve got a lot of posters or other advertisments out in the world doesn’t mean anyone is actually going to go and listen to your record. There are simply too many people trying the same strategy for it to be effective.

Rather than trying to convince everyone to listen to you in the hope that some might (the mass-market, lots of media approach), it’s probably a lot more fruitful to try the targeted approach.

Start by figuring out which other artists that you’re like and whose fans might like you if they had a chance to listen. It’s important that at this stage that you’re honest about who you sound like (you can’t trick people) and that you aim for relatively small bands (I’ll explain why later).

Got a nice little list of small artists drawn up? Go to last.fm and make a list of people who really like them, probably a hundred or so fans at first. Last.fm is going to be a gold-mine for this because:

• It’s full of people who care enough about music to actually document who they listen to (albeit passively),
• You can separate the hardcore fans from the people who merely listen to them occasionally.

Remember when you’re picking names for your list that you’re not aiming to hit everyone who likes any of the people that you think you’re like. You want to be selective, picking people who REALLY like as many of those artists as possible.

Got a list of people? Now write a relatively personalised message to each one, explaining why you’re contacting them, who you’re like, and that you’re a small artist who would like a small amount of their time. Give away a bunch of your free tunes and thank them for your time. My bet is that if you’re ever going to grow your fan-base that doing it in this way, with people who are engaged with following similar music, will be your best bet.

Why aim for smaller bands? Sure, you might think you sound like Radiohead, but promoting yourself to that fanbase won’t work: they’re too big and have too many fans. Trying to reduce the signal to noise ratio (the number of engaged to passive fans) is going to be too hard to do and, honestly, most of them won’t care about your music.

Now, take this approach and generalise. Whatever it is you do, whether it’s making webcomics, movies, art, anything at all, connect with the most engaged parts of the community that are most likely to like what you do, and enter into as personal a conversation as you can manage. If you try this, you can probably grow a decent community over time. This is obviously not the full story of how things like this can work (you can’t do a one-time, one-way communication and expect to get a fan) but it’s a better starting point than most people have just now.

When I first wrote about my Spotify Premium sign-up, back in Spotify: Week One, I had intended to do a quick update on how that was panning out each week until I had decided which way to go on a more permanent sign-up. As you’ve seen, that’s not really panned out.

I like Spotify. I like how fantastic it is for finding new music, being able to delve into recommendations you’ve had without a massive outlay. Several times over the last few weeks someone has said they like an album and I’ve been listening to it within minutes. That, to me, is excellent and almost certainly a game-changer.

The problem is that I don’t actually use it all that much. Several restrictions (that are outside Spotify’s control) make it less valuable to me:

1. Not being able to use it in the background. This is a killer for me. I only use Spotify on my iPhone and not being able to switch out to Notes or Tweetie is a real problem, as I do that all the time. I don’t like having to plan my usage of these other apps around the music I’m listening to and vice-versa.
2. Lack of decent 3G signal. I work in the city centre with a decent enough 3G signal, but still can’t get a good enough signal to stream an entire album. Typically, I’ve made it half-way through an album before having to pause to let the data catch-up. That’s not very useful.

Like I say, for these issues, Spotify is not to blame but I don’t feel I can live with them just now. I’m somewhat sad to say that I have not continued my Premium subscription, but may try it again in the future (if I Jailbreak, for example).

Many financial experts will tell you that when you save for something that it should be goal-oriented i.e. that it should be for something in particular. There are a number of things in the course of, say, a year that are worth saving up for, where there are no pay-monthly options, or those options come with particularly punitive rates and fees (I’m thinking various forms of insurance, bills etc). There are also usually items that people actually want to save up for: new cars, new furniture, new televisions etc. Whatever they context, people often want to save amount X for item Y by date Z.

In an ideal world, we’d all be excellent planners. We’d be able to set aside the right amount of money each month without any prompting, never dipping into it for other things unless absolutely necessary. In our far from ideal world, we’re not all great budgeters. People frequently pay for item Y from the last source of funds available to them before date Z.

It occurs to me that saving accounts could be a lot smarter in order to facilitate these kinds of transactions. For starters, let users deal with savings in the terms that they actually think. Rather than just being big pots that you move your money into, they should allow you to create many smaller but specific pots: one for each of the items that you are saving up for, with a label so you know exactly what it is for. The savings account should also let you specify how much is needed in each of these pots and the date by which you will need to have reached your goal. That means that at any point in time, you can then see exactly how close you are to achieving your goal.

Let’s go further: give the option of figuring out exactly how much you need to save for each item each month in order to reach your goal on time. Allow the user to automatically transfer that money in each month.

By modelling a savings account in the way that it would actually be used, you can facilitate much better user interaction. Rather than having to work out how close they are to a series of goals over a number of different dates, the account does the work for them. That’s a good thing.

Every Monday several online retailers that I’ve previously used tell me about their one-day only sales. That’s fine by itself, they can try and sell me things if they like; I can always ignore them or block them if I don’t like what I’m getting.

One of these retailers in particular used to be very focused. As I only ever bought gaming-related items from them, they would send me only gaming related materials. To me, that’s the right way of marketing your wares: have a think about what the user actually wants and see if you’re right. For a good while, they had my attention. Given the focus they had put on their emails, I’d usually go and look at the games they had on sale.

Lately, though, it’s been a lot less focused. When I click through onto their website, I no longer have the option of looking at just the items on sale that relate to my interests (in this case, the games on consoles I own). No, instead, they have all the items dumped into 30-odd item pages, with around 6 pages. To me, this is exactly the wrong way of marketing your wares: you’ve gotten my attention and then blown it by expecting me to scour through several pages worth of things I’m not interested in, for one or two things I may be interested in. I may see the first page, but it becomes increasingly unlikely I’ll go any deeper.

This is a pretty common problem: forcing users to do work to find the information they want. While you can prompt them to look at some things YOU want them to see, you can’t divert their focus from the things THEY want to see. Instead, as designers, we should be enabling them to find the things they want, to slice and dice their view of the data you’re handing them however they like. If that means categorisation, fine. If that means building a good search function, then do it.

Failure to focus attention is failure to design. If you haven’t done a good job of designing your information flow then users will begin to dislike your system without realising why. At that point, you’ve lost their attention.

It occurred to me a while ago while clearing out my wallet of annoying pieces of paper that, the vast majority of the time, receipts are largely unnecessary. Most of them you will never use, and either get binned or put into a filing system to never be seen again. The problem is, of course, you don’t know which ones you might need in the future. Will they already have that game you’re gifting? Will the new TV develop a fault? You just don’t know.

So, receipts: a necessary evil (and by “evil”, I clearly mean minor nuisance).

What can we do to improve receipts? First, if we must store them, then let’s make that more convenient i.e. let’s make the receipts digital. This could be relatively straightforward:

• Ask the customer for an email address and send it to that,
• If they pay by credit card, store their email address against it for later use (if you’re worried about security, hash the credit card details),
• If they have a store loyalty card, then use the email address tied to that,
• If they don’t have one or don’t want an email, fallback to paper-based methods.

Simple. As an extra convenience, it might be worthwhile trying to get credit card providers to store a minimal amount of secure data on credit cards. This is definitely possible (though unlikely) and would ease the first-time pain.

Additionally, if we’re doing this electronically, I’d also consider providing a machine-readable version of the receipt; a standard way of marking up sales information. If that were to happen, then you can start to build tooling. You can do all sorts of deep interesting tracking if you have your financial information available electronically. If you imagine the sort of thing that Wesabe do just now, then you can start to see where we could go from there.

Are there issues? Yes, absolutely. If you want to return something, you need to be able to get your receipt (not strictly true, but that’s how you do it easily). In the digital world, that would either mean a print-off or, I imagine, getting the ID from the receipt. That ID should be sufficient to prove that you own a product and bought it in the shop you were in as all the transaction details should be available. The shop would need to rescind the receipt based on the ID to prevent multiple people trying to use the same receipt but that wouldn’t be very hard.

Another issue is that smaller shops would have an obvious overhead to pay. Well, there are two outcomes here: they can not participate (keep things the way they are, which is absolutely fine), or get someone else to run most of the system as a managed service. There’s actually really very little of this that would be shop-specific so it would be easily built and sold on.

That’s another worthwhile point: it could start a nice little niche business. People supplying these systems and building tooling around it.

Now, technically, my understanding is that receipts are not strictly necessary under UK law at all, but are a de facto part of how sales tend to work. To that end, I think that making them digital would be reasonably beneficial. Just an idea.

In a discussion recently, I realised why image galleries on websites make me uneasy (by image galleries, I mean software like Coppermine, which is extremely polished). It’s not that I dislike the content, it’s often appropriate or useful. You often do need to see something, whether it’s a bunch of application screenshots or perhaps some pictures from a band’s latest tour. They have information to convey, and are worthwhile.

No, I finally realised that the issue I have with them is that they’re almost always completely hived off from the rest of the content. You have your all the interesting news on your site, you have the products you want to sell, you have your twitter account brought into the main site, but so often the image galleries are sat on their own. You’re either in the main site, or looking at the images, but never both.

Most websites are trying to tell a story of some sort. Bands are trying to communicate with fans, software houses are trying to showcase products, and bloggers are trying to put their own little view of the world forward (myself included). In order to tell a meaningful story, you have to realise that so much of the world and the way we perceive it is connected. You might have seen the latest tour news from some band you like, but you’re part of that story if you go see them, and the pictures of those shows are too.

By putting the galleries out on their own, they’re no longer in the same context as the rest of your story. They’re telling their own story. Sometimes that’s just fine, but more often than not they’d be better understood in a larger context.

It might just look like a bunch of gig pictures on their own, but have them tell the story of the particular gig they’re from, mix in your tweets from your fans, and any other media you can lay your hand on and you have a fair richer story. That’s much more compelling and interesting. You’ve gone from a bunch of discrete sources to a tapestry, something to build a legacy on.

Is it more work to tell a story than to put it into a gallery? Right now, probably, yeah. Is it worth it? Absolutely.

Since Java and the JVM are getting proper closure support, now is as good a time as any for me to dump some thoughts about functional programming onto the site. I’ve got a few posts in mind, but I imagine this will be a somewhat sporadic series. Anyway…

When I was first introduced to functional programming, as part of my degree course, I didn’t really understand it. Not that I didn’t do well at the course, it was one of my strongest modules that year, but I really didn’t understand the benefits and potential. It did seem unusually neat, producing fairly compact code (we were taught Haskell, unsurprisingly), but also fairly burdensome. Avoiding side-effects and assignment was just too foreign, and I didn’t have enough real-world experience to really get the point. So, for a few years, I just forgot about it and got on with programming in other languages (Java, C, PHP, JS, etc).

Skip forward a few years, and as a reasonably experienced coder, I often found myself frustrated at the languages I was using. I would always try to make my code as neat and compact as I could, trying to minimise any wasteful re-use. If two classes were vaguely similar, then I’d look to find the common elements and make the differences abstract. Joel Spolsky talked about this when covering Javascript.

That’s all well and good but without certain key language features you can only get so far. The very constructs that hold the language together (loops, ifs, locks etc) are often the part that are either impossible or very difficult to abstract. This revelation brought me back to functional programming.

I now realise that the core of functional programming is freeing yourself from the constraints of the language, using different higher-order functions to express yourself more clearly and succinctly. A necessary consequence of this is lack of side-effects, and that’s a GOOD thing.

Stick around, I’ll be covering a number of libraries and ideas that make life simpler for the functional programmer.

I try to avoid anything remotely political on this site, for many reasons, but I feel it worthwhile discussing some of the issues around Peter Mandelson’s Digital Economy Bill: one of the most wrong-headed political policies I’ve seen in the technology space.

In this country we, by and large, have a solid basis for our justice system: we are all innocent until we’re proven guilty. Suspicion of committing a crime is not good enough, it must be proven beyond a reasonable doubt. The upshot of this is generally positive. We can’t be accused of something and be punished for it, without proof that we actually did it. This is a fundamental right that allows us the liberty we enjoy.

Importantly, you also can’t be tried by the victim of a crime. If you are accused of stealing from someone, that person cannot serve on the jury, nor can anyone with an obvious bias. You have the right to a fair trial by a jury of your peers.

If we did not have these rights, then it would be all to easy for society to be manipulated by scaremongers and sociopaths, the idiotic and the greedy. One accusation, and you’d be finished. This is not a hypothetical. In our past, we tried people as being witches with no evidence, just an accusation. This has happened before.

Now, the media industry is in a difficult place. They’re making less money than they used to, and want to blame piracy for their failing business models, rather than adapt. That’s a whole deep dark hole of debate by itself, but is not what I want to talk about today.

No, I want to talk about the Digital Economy bill. As a way of stopping the perceived threat of piracy, the Digital Economy bill will give media companies the right to accuse people of copyright infringement and have them disconnected from the internet. Think about that for a second: the accuser gets to blame anyone they like and with no evidence of copyright infringement, have a punishment inflicted upon them.

No trial, no right to see the evidence against you and fight it. You’re presumed to be guilty. This is, of course, the opposite of how justice works at present. We’re basically putting justice into the hands of very large companies to protect their revenue in the way they see fit, whether they are right or wrong. We’re handing liberties over to commercial interests for no benefits.

To me, that is very wrong and I hope you join me in signing the petition to stop this very wrong policy.

For more views, Open Rights Group have a great site up called Three Strikes.

As someone working in technology, I’m faced with a fairly moving landscape. The number of new technologies and ideas that pass through my domain of interest make is so that the skills that I had yesterday might not be useful today, and are probably going to start looking silly tomorrow.

A necessary outcome of that is that technologists rely a great deal on different forms of training material, from full-on seminars to simple tutorials and APIs. It strikes me that a great amount of this material, perhaps the majority, is terrible; lacking the ability to convey meaningful lessons to the reader.

Ignoring the material which is underdeveloped or simply inaccurate, my experience tells me that the next worse kind of material is that which runs through a series of steps: do x, do y, do z, you’re done. While this is certainly better than no material at all, it doesn’t help build any understanding, and that’s the key to any successful tutorial. If you build understanding, you’re doing a much better job.

Rather than simply run through steps, take the time and patience to indicate the goals. What will each step achieve, how exactly does it achieve that goal, and what other outcomes are there in slightly different circumstances? Each step should be there to help build understanding of your domain (by which I mean the fundamental components and ideas underpinning your subject matter), and in doing so ensures that the reader will be able to reason about your domain for themselves much earlier.

An extraordinarily good example of this is something like the Spring Framework manual. Each section introduces concepts with worked examples, alternatives, and consequences. The outcome is that given a small amount of time working with Spring you can fairly well reason about a new class that you’ve never encountered.

Always build on the domain understanding, always underline core concepts and always teach underlying principles, rather than simply stating steps.