Almost a year ago I did a quick post titled “Post full feeds. Please” - and I was serious. At the time (it really wasn’t that long ago but it seems like ages in the internet), about 60% of blogs were full feeds, and the number grew steadily. Now it seems we’re getting back to summaries everywhere (much due to the advent of ads in blogs), and that feels like regressing. Here’s why.

My process with RSS feeds is as follows:

• I don’t have much time, thus
• I don’t read all posts on all the blogs I subscribe to.
• I scan my news reader for things I care about and read them
• If I have something to say, I click through to the page and comment
• Whenever I see summaries, I think “no time to click all stories to figure out if I care, so I unsubscribe”
• I click the “unsubscribe” button

Some people have time to spend reading whole posts - most people don’t. And most people don’t care about most posts anyway, meaning the overall satisfaction resulting in clicking through every single post to get one important piece of information is extremely low. And like most people, I choose not to be unsatisfied.

We’re at a time when information overload is at its peak. RSS is being used by millions of people because it makes sense - it relieves us from having to visit every single site we care about to get the news we want. If it doesn’t do that properly and publishers don’t understand our needs as users, we don’t need to stick around. We can move to people who get it. Right?

Last week we quietly launched Goplan on an invitation-only basis, in order to test the ground for our collaboration (or coordination, as I know some would prefer) web-based application. Some may wonder why we decided to take things slow and avoid having the application show up on sites like Techcrunch, Solutionwatch or Postbubble (by our friends at ACS) - time for some explaining.

The long explanation

Scale: There are obvious problems with launching web applications with a bang - problems we avoided with our model. By taking things slow (inviting some people and letting them invite their own friends) we saw organic growth, instead of uncontrolled chaos. We gave people enough freedom to use the app and share the love with their friends and by doing so, we were able to monitor our technical status and predict the necessary assets for the future.

Satisfaction: We are fans of the “release early, release often” model of agile development, and live by it. Small numbers means measurable feedback and quick response. By limiting ourselves to around 250 users for the first week, we managed to get the right feedback and act upon it, by releasing daily updates to our feature set and fixing the issues we encountered along the way. That made people happy, and one happy planner beats a few thousand unsatisfied users.

Personality: In one of Amy Hoy’s fantastic presentations, she mentions how when something goes wrong with software, people blame themselves. In an application built to help people manage their work better, there was no way we could let that happen. Being advocates of the human side of software, we stood by the users by trying to understand their problems, and incorporating the solutions into the software. Saying “we’ll make it better” beats saying “no” most of the times. And hey, we’re humans.

Decisions: There are decisions we haven’t done yet. How we should price the application, if we’ll have it available in any way other than a hosted service, etc. By taking it slow, we can hear what people have to say. Who besides the target audience can clue us into what’s best?

Can we help you too?

So, having explained why we decided to take it slow (we didn’t ignore your invitation requests - seriously), we want to have you on board as well. We’re ready to send new invitations to Goplan, so if you really really want to get an invite, email us at goplan@webreakstuff.com and ask. We’ll listen - we’ve been doing it a lot, lately. Which is a good thing, trust us.

There’s an underlying beauty in the objects we use throughout the day. They were conceived, meticulously prepared by someone (who we’ll call the designer) - especially for us. We become attached to these objects because of this underlying purpose of making us feel special. We know, even subconsciously, when someone paid attention to our experience as a user.

This is true in many of the things and gadgets we use today. Think of the iPod as an example: the navigation, how it works and particularly how it feels - it has clearly become an object of desire, and its not all because it can play mp3. It is easy to say the work of the industrial designer, interaction designer and graphic designer are usually recognized by the general public.

Online user experience?

I wonder if that’s true for those of us who take part in designing online experiences. How attached do people become to their online experiences, and how much do they realize that there was probably someone thinking about them all the way through its creation? Are user experience designers background players? Do we stand behind and observe, react and enhance experiences without being noticed?

There are no conclusions to this short story, only one question:
When was the last time you felt attached to anything coming to you from a computer?

As you’ve probably noticed if you read the previous post, Goplan launched a while ago. If you look closely however, you may notice we didn’t call the launch a beta like it seems most people would assume (this is web 2.0, right?). Here’s the reasoning behind that decision:

Beta software has been labeled that way in the past few months because it’s a trend. You launch something you feel isn’t quite “ready” so you tag it as something that gives the user the idea that it may fail. This is mistake number 1: if you launch software and are passionate about it, avoid having it boil down in the hands of the user. You should focus on making it work, not excuse yourself using by using the “b” word if it doesn’t.

Launching web applications is a risk - a risk you have to take, as the developer. Calling the product a beta doesn’t alleviate that. Fact is, if it involves people’s assets or (even) a small part of their lives, the risk is on you. Launch it if it solves a problem, not if it creates several. Any other decision would be mistake number 2.

If its a test, call it a test, and a beta isn’t a test. Lets face it, we’re never sure something will work right. We’re never sure the way we thought about something is the way most people would - and that makes testing a necessity. But make it clear that you are still unsure about certain things, that people can trust you’ll listen, and that you’ll avoid whatever mistake number 3 might be.

Just don’t label your web applications beta.