Webreakstuff blog

Archive
Web-Applications

Evaluating product ideas, defining success

Evan Williams has a very good post on evaluating product ideas based on his previous experience (launching Blogger, Odeo – pretty much forgotten in that article – and Twitter). I’ve been thinking about a couple of products as well (have been for a while, actually), so the whole article sort of fell into place with my own criteria. Here are Ev’s:

  • Tractability: How difficult will it be to launch a worthwhile version 1.0?
  • Obviousness: Is it clear why people should use it?
  • Deepness: How much value can you ultimately deliver?
  • Wideness: How many people may ultimately use it?
  • Discoverability: How will people learn about your product?
  • Monetizability: How hard will it be to extract the money?
  • Personally compelling: Do you really want it to exist in the world?

To these I would add two other characteristics that I believe have a great impact on a product’s success: cleverness and trustworthiness. You know when a product is clever because you get the feeling of empowerment and delight. And trustworthiness (although perhaps difficult to assess initially) defines how people look at your product or service – if users can trust it, it is more likely that they’ll become engaged and use it often. People are often skeptical about things that dip into their personal affairs (think Facebook’s Beacon and why it sucks), but will feel at ease to engage and discover new things about a product if they trust it.

Ultimately, it isn’t easy to determine the likeliness of a product being successful by putting it to the test against a series of attributes – but it may help. I’m still a big fan of entrepreneurs following their gut and seeing where it takes them, but depending on the person, that might not be a good plan to stick to.

I definitely recommend you give Ev’s article a read if you’re an entrepreneur – you’re still here so chances are you’ll be interested. Unfortunately Evan still doesn’t allow comments on his blog, because I would imagine the discussion on such an article would be interesting.

Click here to read the full post!

Colored labels: small change, major difference

Gmail colored labels What a difference a small change makes. Gmail launched what has probably been my #1 wanted feature since I’ve started using it: colored labels. Labels were useful already if you wanted to archive content meaningfully, but without a visual cue their impact on the inbox wasn’t really significant.

Colored labels however, make a huge difference. If you’re smart about the way you use labels, you can create a system for your email to prioritize conversations, organize a task list, or go all out and build a proper GTD system out of it – all with the visual cues of colored labels, because they allow you to at a glance understand what email belongs where without reading the subject or even the label text.

What to take away from this

Minor differences like these visual cues are some of the things that define application experiences, and frequently (and unfortunately) are forgotten by developers and people building products. Products that are meant to help people manage assets in their daily life in particular deserve this special caring eye on them.

People building web applications need to ask themselves “How can I provide meaningful cues to help my users?”. These things (like the need for cues) are not found by chance – people do express the need for cues and helping paths all the time, we just need to care enough to listen and make changes.

Click here to read the full post!

Amazon S3 gets a SLA. Exhale.

A couple of hours ago Jeff Barr (senior evangelist over at Amazon) posted about Amazon S3′s new Service Level Agreement – which if you happen to run services on the platform (like we do here at Webreakstuff) is a pretty good piece of news. Ever since Amazon S3 (or Simple Storage Service) officially launched developers have been asking for an SLA in order to formally guarantee the service’s reliability and Amazon’s commitment to keeping it going.

Amazon Web Services

Some of the developers building applications with Amazon S3 have been asking us about an SLA, or Service Level Agreement. An SLA defines the minimum acceptable level of performance from a service along with some sort of penalty for not meeting expectations. A typical SLA actually defines a performance or reliability boundary which is somewhat lower than what the system is actually designed, built, and expected to deliver.

We know that many of our customers, including a multitude of teams within Amazon, are using S3 in mission-critical ways and need a formal commitment from us in order to make commitments to their own users and customers.

And the agreement looks good, too. Amazon will give you 10% service credit if uptime goes below 99.9% and 25% credit if it goes below 99% in a given month. Which tells you a lot about how reliable they believe their platform really is.

The agreement is in effect since October 1st, which means those of you who’ve wondered (for so long now) whether it would be a safe bet to host something on S3 can finally exhale. Now, and although I do trust Amazon’s reliability – I mean, it’s Amazon -, it’d be great to have an SLA for EC2 as well, but I assume that’ll be up when it officially launches.

Click here to read the full post!

iPhone-specific pages are a bad idea

Remember the old days when we were promised jetpacks, flying skateboards and the mobile web? Well we still haven’t got the Back to the Future gear but some would argue that devices like the iPhone do bring us closer to the internet, anywhere.

The iPhone gives you the best experience browsing the web on a mobile phone although contrarily to what some people seem to believe, that’s because it doesn’t need iPhone-specific pages to feel right. Apple did a terrific job at crafting a device that gives you the web (as it is today) in your hands. And that takes me to my main point: which is that designing pages exclusively for the iPhone is a dumb idea.

Dumb? But it’s the iPhone!

Here’s a hypothesis: Google launches their own mobile device, say, tomorrow – and it’s so beautiful you need to have it. In fact, it’s so amazing you’ll be throwing that iPhone out the window. Suddenly you get it, all those iPhone-crafted pages are suddenly useless, because they are built specifically with one device in mind.

The mobile web never really took up because designers tend to design for what’s closest to their hearts – and right now that’s the glassy phone with the Apple logo. As most people will tell you, being “closed” is a lousy way to get wide adoption – and this is just about as closed as you can get. Think about it, you’re designing pages specifically for a $599 device and expect huge visits? Oh, come on.

Design for the experience, not the device

A better idea is to design for an experience, not a specific device like the iPhone. Just like you design for desktop browsers by assessing constraints (like window size) and building an experience based on those constraints, why not do it for mobile devices in general? Truth is carefully crafted pages can actually display perfectly both on the desktop and the mobile web (iPhone or not).

The iPhone actually goes a very long way in making sure pages today work great. Instead of building a page specifically for the phone, why not one that gracefully scales to fit the device’s screen? It guarantees you’re not spending resources building for a specific device and effectively means you can focus on building one experience that’s maintained across all platforms. Give it a try.

PS: Have you also noticed how most of these iPhone-specific pages are trying hard to mimic Apple’s design too? Sacrificing resources and a brand just to make something blend in on one device is a lot worse than spending those resources on maintaining quality across the board.

Click here to read the full post!