Archive for 2010

Here’s a quick update on Listening Room, which I first announced about 4 weeks ago.

First, the level of enthusiasm about the idea has been amazing. THANK YOU to everybody who’s tried Listening Room and expressed your love for it. It’s incredibly motivating to have real people using and enjoying my work.

Having real users has also exposed some bugs and design flaws. Originally my idea was that the server would just route bits between clients, and all the ID3 parsing, playback of different music file types, and seeking to the proper position in a song would happen in the client. But it turns out I was underestimating the difficulty of doing that reliably across browsers. So I’ve been gradually moving more functionality to the server, and last night I pushed an update that introduces transparent server-side transcoding with ffmpeg. Everything streams as MP3 now. Besides being well supported between HTML5 and Flash, MP3 has the advantage of being playable mid-stream. So now if you join a room while a song is in progress, your browser can start downloading from the current position in the song, instead of having to download the whole song and then seek to the current position. All of this has made playback a lot more reliable.

I’ve been iterating on the UI, too. Here’s Listening Room at the end of November:

And here it is on December 10. There’s the new design with sidebar, and instead of a big toolbar there’s just a mute button next to the page title. If you look closely, you can also see that the record has a groove in it which shows how long the track is:

Jump forward to December 20 and it’s getting a little closer to my original vision. There’s a record player, with an arm that tracks the current position in the song. Songs that have cover art are rendered as picture disks. The record is actually spinning while it’s playing:

It’s been a good month. Thanks again to everybody who’s spent time trying out Listening Room and putting up with the bugs. If you haven’t tried it recently, I encourage you invite some friends and listen to some music together. And stay in touch, I really appreciate the feedback.

Here’s something I’ve been working on: Listening Room. It’s a web app for listening to music with your friends. You get a few people in the same virtual room, and then you listen to music together. The music comes from the computers of the people in the room, and streams over the web. Everybody hears the same thing at the same time.

I started working on Listening Room maybe a month ago, as a toy project to play with node.js and HTML 5. It’s still a very immature (and buggy) project, but today I decided this was a good opportunity to put some Minimum Viable Product theory into practice. So I’m releasing it to you, my loyal blog readers, in its current raw, buggy, slightly embarrassing state. Try listening to some music with your friends, and let me know what you think. (For best results, use a recent release of Google Chrome or Firefox.)

Also, I’m planning on hanging out in the room ‘abe‘ when I have a chance, so feel free to drop in and say hi.

You know what always makes me feel a little nervous? Submitting text for processing.

Take this little example, for instance:

$ for file in *.txt; do mv $file "$file.old"; done;

If I’m typing that at a command line, my expectations that I’ve typed it exactly right the first time are pretty low. In fact, just now I had to try a couple times before I got everything right for that example (I forgot the “do” the first time, and then I had “for $file”). So just before I hit enter I always have a feeling of hope mixed with fear: I hope that I got it right, but I’m prepared to see a disappointing error message and have to try editing my input again before submitting.

Here’s another example:

Phone number:

Is that going to work when I submit the form? Maybe, but I’ve also had plenty of times when a form gave me an error message because I didn’t format the phone number right. So I’m not completely confident that my input is going to be accepted, even though it’s just a phone number.

Fortunately there’s a well known solution to this kind of problem: WYSIWYG. In a WYSIWYG interface, What You See Is What You Get. In other words, the input interface shows you what the output is going to be. So when you hit print in Word, you’re not crossing your fingers that your printout is going to have the right words in italics. You know those words are going to be italicized because Word is displaying them in italics right on your screen. WYSIWYG gives the user assurance that their input has been understood.

Unfortunately, web forms are usually not WYSIWYG. You’re typing into an input box and hoping that you’re not going to get any error messages after you hit submit. This is an unpleasant experience. A lot of web apps could be improved if the input provided feedback as you typed. Today, programmers might try to do some of this by showing error messages next to the input box in real time, or by making a custom UI control. But to me the ideal thing would be to have a nice text input box where I can use native keyboard shortcuts, copy and paste, and tab around, while still being able to have a visual indication that my input is (or isn’t) being understood.

So to make that possible I just started a new mini-project, which I’m calling Rich Text Input.

The goal of Rich Text Input is to provide an enhanced text input box that uses HTML formatting to give feedback about how the user’s input is going to be interpreted. It’s not a rich text editor – the output is still plain text, and behind the scenes the user’s input is still going to a regular <input> element. The purpose of the rich text formatting is to give the user feedback, and give them confidence that their input is going to be understood as intended.

Here are some possible uses:

• syntax highlighting code snippets
• validating credit card numbers, phone numbers, and zip codes
• styling email addresses and tags

If you wrote some code to round-trip the input to the server (like search engine auto-suggest inputs do today), you could do some even more interesting things:

• a tag list in which the color of the tags represents how “hot” they are
• a search engine input where special operators like site:fettig.net are highlighted in a different color

The current code is not at all ready for production. But it demonstrates the concept, and I hope to have it ready for production projects soon. So check it out and let me know what you think of the idea. The project page is here, and the code is on GitHub.

As of last week I’m no longer working for Google. I’m on my own, and I’m excited about it.

Being at Google was a great experience, and I’m grateful for it. I learned a lot, got to work with some great people, and enjoyed the feeling of being smack-dab in the center of the tech industry. But after three and a half years I was itching to have more time to experiment and work on my own projects. So I decided it was time to move on.

Over the next few months I’m going to work on a couple of ideas for products I’ve been thinking about. I’m looking forward to doing some full-stack web development again. There’s also a bunch of interesting technologies that I want to get up to speed on, including html5, MobileSafari touch events, geolocation, node.js, Redis and other NoSQL databases, and more.

I’m also considering taking on some contract work. For the past 5 years I’ve been doing lots of serious Javascript programming, and from talking to people it sounds like experienced Javascript experts are hard to find. So if you need outside help on a Javascript-intensive web application, feel free to check out my resume and get in touch.

I’m really looking forward to this next phase of my career. Exciting times. Stay tuned.

I think the Nexus One is a great mobile device (as a Google employee I got one at the end of December and I’ve been using it as my full time phone ever since). It was officially announced today, but in all the coverage I haven’t seen anybody talking about what a good deal it is in terms of total cost of ownership if you buy the phone without service.

Here’s a breakdown of the total cost of ownership in both cases. The subsidized Nexus One costs $179, with a $79/month plan. The phone without service costs $529, $350 more. But then you can sign up for T-Mobile’s “Even More Plus” plan, and get the same 500 minutes + unlimited data and text messages or $59/month ($20 cheaper).

So, over 24 months you save $480 in service charges, more than making up for your extra $350 investment up front ($130 net savings). Plus you’re contract free and in position to sell your Nexus One on EBay and/or jump ship to another carrier when a newer, shinier phone comes along.

The savings are so substantial that you’d even come out ahead if you put the $350 extra on your credit card at 20% interest and put the $20 a month savings towards your credit card bill (you’d have the $350 balance paid off after just 21 months). To put it another way, if you go for the subsidized plan it’s like you’re borrowing $350 from T-Mobile, and then paying it back over 24 months at a roughly 30% interest rate.

One last comparison, total cost of ownership numbers over 24 months:

Nexus One (no plan) + T-Mobile Even More Plus (unlimited text messages, 500 minutes): $1969
Nexus One with bundles T-Mobile plan (unlimited text messages, 500 minutes): $2099
iPhone with AT&T iPhone plan (choice of 200, 1500, or unlimited text messages, 450 minutes): $2000 / $2240 / $2360 (depending on text messaging plan)

Update: billshrink.com has a chart comparing total cost of ownership of various smart phones, including the Nexus One, but they don’t seem to be using the Even More Plus plan prices.