thisismyjam.com 03/27/2008
 

It's always interesting to see new technology for sound. There's a huge opportunity for someone to create software that's better able to understand music the way a DJ might (BPM, key, etc) and automatically create a mix by beatmatching and cycling through the circle of fifths, for example.

thisismyjam.com tries to do that. It's a demo product built on The Echo Nest APIs. It's cool to see something like this on the web, but from my testing, it's about as good as existing software out there that's desktop-based or built into hardware like the Pioneer CMX-3000.

There's no reason why a computer can't eventually do the same thing a human DJ can. In the meantime, here's a quick mix I created with thisismyjam.

4 Comments
 
 

Do you take into account the hidden cost when making decisions? It's one of those areas where I used to fail miserably. I've learned to take it into account over the last couple years, but only recently was able to formulate the concept properly.

The idea goes something like this: Behind most obvious decisions is a non-obvious hidden cost, which can often outweigh the benefit of the "obvious" decision.

I stumbled upon a great real-world example in the drive-through to Taco Bell a few days ago. I realized that there was a flaw in the system: I could order, then drive up to the payment window, and not be able to pay. Taco Bell would likely throw away the food, and have to eat the cost. The system had a flaw. Engineers like fundamentally perfect systems, and that's a good thing.

But if an engineer had designed the drive-through, you would probably have to pay before they started making your food. Impossible to game, flaw destroyed. The problem is, what's the cost of the extra time involved in waiting until you receive payment before you start making the food? And what's the cost per meal wasted times the number of times that the customer is not able to pay? There's a reason they start making your food right away: It saves a ton of time, and people are able to pay most of the time.

Seems obvious, right? Then why do we still insist on requiring two password fields, one for verification? Or two email fields? Sure, a banking application might require this... but your average web app? You could look at it this way: What's the chance that someone will mistype both their email AND password, weighed against the drop-off in signups because of the extra form fields. You will drop a significant number of sign-ups with the added fields, but there will be a very small percentage of people who get both their email and password wrong.

Another pet peeve that PG originally pointed out to us: requiring email confirmation as part of the sign-up process. Email is notoriously unreliable, and often gets flagged as spam or not delivered. Why would you require an email confirmation as part of your sign-up process when there is a high probability that the email will never be received, and the user won't be able to sign-up? Maybe I'm in a computer lab and I get email on my laptop. Tough luck, I can't use the website now, when I want to -- I have to wait until I can check my email. Does that high of a percentage of people not supply their correct email address, that you need to require confirmation? And does having a confirmed email address outweigh the big drop-off in signups?

We've learned to take the hidden cost into account with Weebly. It can apply to across the board: Adding features weighed against the added complexity to your application, bootstrapping weighed against the loss in growth momentum, increased security weighed against the increased difficulty in using the application.

In a nutshell: each decision you make will have a negative counterpart. Even (and especially) the most obvious decisions. Figure out what that hidden cost is, and make sure it doesn't outweigh the original benefit.

7 Comments
 
 

Netvibes, I've loved you since day 1, but you've been getting progressively worse and worse. Please, shake off your aspirations of ruling in the hot buzzword categories -- stop trying to be a social network, that's not why I use you, stop trying to be the end-all-be-all of widget embedding (ditto).

I don't really care about your new releases (Ginger, Coriander, paprika or whatever), I just want to be able to log-in every day and check my news feeds. I don't want to have to go through a painful "migration process" -- sounds like something taken out of an enterprise software book, definitely not suitable for a consumer product. And I don't want to have to request an invite to said migration process, get the email, input the invite into netvibes, begin migration, and have to wait hours until the migration is complete.

What I would like is if you fix your most basic bugs that have been there since day 1, instead of developing world-dominating features. The bugs that relate to your feed reader, the core of your product. Like the bug where when I have a feed open and the feed refreshes since I've had it open, the stories I click on display the story a few places up. Or the bug where about 50% of my feed will start the "Loading..." process, only to go completely blank -- the rest of my feed is ok though! Only half of it goes blank when it tries to load, the other half loads properly. That is especially annoying to me. Or the fact that hitting "refresh" on your feeds is flaky -- I usually have to reload the page if I really want to get a refresh.

I'd be the first to understand that everybody has their bugs. But before embarking on these huge feature releases, can you please fix the small things that have been there since the beginning?

EDIT: check out the comments on this blog post and this blog post -- looks like there are a lot of unhappy people.

2 Comments
 
Skiing in Tahoe 03/13/2008
 
2 Comments