Tuesday, July 29, 2008

My IPod Touch Died

Sunday morning I'm mowing the lawn, it's working fine.  I come in and put it down on the kitchen counter, because the whole family's got an errand that needs doing.  The house is empty for the next two hours or so.

I come back, get iPod, go back outside to finish mowing the lawn.  Thing is dead.  No video, no audio, dead. 

The annoying part about touch screens at this point is that for an item that is powered off, there are very few physical ways to interact with it.  There are two buttons, basically.  So you either hold one, you hold the other, or you hold both.  And that's about all you can do.  None of those things makes my ipod come back to life.

I plug it in to the laptop, hoping that maybe it is a battery issue.  Nothing.  Doesn't even register.

I have an appointment at the Genius Bar today at 10:50.  Not sure what I expect them to do, unless they crack it open right there in front of me :(.

Startup School 08


Great videos here from Paul Graham's Startup School 08, including Paul Graham, Marc Andreesen, Jeff Bezos, Mike Arrington, and this programmer guy named David Hansson who apparently wrote something called Ruby on Rails ;)

DHH's talk is particularly fun, because he gets up and in the first two minutes says "We're not hiring and we don't want VC money." He then goes on to talk about the value of aiming to make a million rather than a billion, why the latter is darned near impossible but the former is a simple math problem.

One of the best parts comes at the end, when somebody says, "I'm at the terminal 14 hours a day.  How do you stay focused and motivated?  I find that my attention drifts to other things."

His answer flies in the face of all those caffeine-enhanced all nighters that you think are the key to getting you your billion.  And it makes you actually think that you might be able to do it, after all.

Thursday, July 17, 2008

Automatic SMS : Handling Authentication

I've been asked too many times to add SMS to our product, so rather than wait for the business spec I'm just going to go ahead and build it.  Our users are high school students who are trying to get noticed by colleges.  So an event in our system would be "Boston College noticed you."  I want that sent to the students' cell phone.

I get that I can ask the student for a phone number and a carrier, and from there create an email address which will enable me to send a message.  That's easy.

But how do you handle validation?  Say that the student enters a wrong number for one of any number of reasons (malicious, or inadvertent, or they just plain want to stop subscribing later).  Do you just take the number and start mailing it, and the only way to unsubscribe is to edit your profile on the site?  That only works if the person in question is the one who owns the phone number.  If I am sending messages to a phone number who does not want them, and that phone number does not have an account on my system, then there's no way for that person to get unsubscribed.

Is there a best practice for this sort of thing? I'm thinking that when the user first enters a number, we send a message to the cell phone with some sort of numeric key, and the user has to respond to that message.  That would be a standard email practice.  Just not sure if it's convenient on a cell phone.  It wouldn't fix the unsubscribe problem, but at least it would assure that only people who wanted the messages would be getting them, so presumably everybody getting messages would also have an account on the system and thus be able to go in and change their subscription preferences.

Wednesday, July 16, 2008

Seymour Papert


If you ever had the chance to play with LOGO as a child, or watch the Turtle robot run around the floor dragging its pen behind, then you owe that to Seymour Papert, the MIT professor who has pretty much spent his life researching how children learn (and, by association, how to make technology work for them). 

I had no idea that a motorcycle accident (he was walking, it hit him) had left him with a brain injury so severe that he couldn't walk, talk or read.  "His accident was worse than horrible for somebody whose life was the mind," said his colleague Nicholas Negroponte (lately famous for the One Laptop Per Child program).

If you're a geek, go read the article.  Without geniuses like Papert leading the way most of us would never have seen a PC in our childhood, or written our first videogames when we weren't even out of elementary school.

Why The Audiobook Industry Is Broken


All great points from Evo, whose Podiobooks.com site is trying desperately to change the face of how people get their audio content (although Audible.com gets all the press :)).  In order I prefer:  podcasts, individual downloads, audiobooks, ebooks, traditional books.  My rationale goes almost entirely toward the convenience of listening.  I like to listen while driving, or on the train, or walking.  Very hard to do that with a traditional book.  If I have the time to sit and read a traditional book, chances are I have the time to do something else, too.

When I have spare book money (like a gift certificate), I always go for the audiobook.  The first thing I do is rip it, which results in about 100 MP3s or so (one small file for every segment on every CD).  I then use my MP3->Audiobook converter to produce a single audiobook file, which I can play on my iTouch on "faster" mode.  The most time consuming part of that task is not even the ripping - iTunes has got that down to a 1-click function.  It's finding the files.  Most audiobooks do not bother to put the appropriate ID3 tags in their files, so half the discs will go under the Author name, some under the Book name, a few under Compilations....and then sometimes the tracks are labelled just Track 001, or Introduction - 01... The biggest pain is in finding and sorting them all.

But it beats the heck out of carrying around 10 CDs!

Monday, July 14, 2008

iTouch App Support : Review

Yeah, yeah, yeah, we iTouch owners get screwed by having to pay an extra $10 to get what the iPhone folks get for free.  I still don't want an iPhone, I'm happy with what I've got.

So far the new application directory is awesome, very pleased with it.  I do not love the new iTunes 7.7, in particular the "I'll just go ahead and back up your iPod whenever I feel like it" feature.  If you add apps on the device, then you have to sync them over to your PC (it tells you quite clearly that if you don't, it will delete them), and when that happens, it will do a backup.  So if you're in the habit like me of syncing at the last minute before you go home from work, you might find that your 30 seconds of budgeted time really takes 5 minutes  :(.

App management in general will be interesting, as these are treated as store "purchases" even if they are free.  There is no real way to test drive apps.  You purchase them on the device, they are automatically installed.  If you don't like it and delete it, you have to delete it from your desktop as well or it will just keep getting installed again.

So far the best game I've found is called Aurora Feint.  It's Bejeweled, but with a cool sort of "get points / level up / earn power boosts" RPG thing going for it.  That'll keep me busy.

Apple Remote is as cool as everybody says it is.  You get a WiFi remote control for iTunes!  So if you're close enough to your machine to use it as a jukebox (or if you have those remote speaker thingies), but you're not close enough to control the machine, well, now you can be.  Works seamlessly.  Highly approve.

On the downside, I still don't see a simple offline file management tool and/or PDF reader.  There are a couple of "ebook readers" but each seems to be just a client for one of the online services, and that's not what I want. I want to put PDFs on the device and read them when I'm not in a Wifi zone, why is that so hard?  There's an app called FileMagnet which seems to do that sort of thing, but because of the desktop client requirement it is Mac only.  That doesn't help me.

Overall I'm having fun.  I've downloaded a bunch of games for the kids (including the Disney card games, and the Jirbo series), and a variety of productivity apps including Evernote and Zenbe Lists.  WeatherBug is better than the standard weather app, and if you want IM, there's an AOL client that's good enough (though not great, but I don't use it much).

The best thing, really, is that the App Store exists on the device.  I never touched the music store on the device, and hated the fact that you could not download TV or Movies that way.  But by being able to get apps without being at your desk, I can try them out much faster.  That means that Apple gets more of my money, too.  (Speaking of which, the average price point for many apps seems to be coming in at $10, which is too high - I would have preferred half that.  But there are still plenty in the $3 and under range, if you look for them.)

Thursday, July 03, 2008

Design By Prototype

We've just started a new thing at my company and I'm hoping it's a success, as I'm kinda sorta right in the middle of it.

When a new feature for your product comes along, be it big or small, how does engineering find out about it?  What's the actual hand off that they're given to work with? A spec?  Use cases?  Screen shots?  Personally we've found (being a small company, < 10 tech people) that the perfect document  never gets written, first of all.  Not only can no one decide on the proper amount of detail to use, it doesn't really matter what's documented because if you find out in the last week of development that you didn't put in a feature (undocumented) that the product manager wanted, you're going to be doing it anyway.

One step removed from Word documents is "design by screenshot", which is basically what we live by now.  This is when the graphic artist mocks up what the feature will look like (whether that takes 1 shot or 20 depends on the feature).  This way, in theory, every non-engineer can look at it and say "Ok, now I know what I'm going to get, I know what to expect."

Many, many problems with this approach.  The two biggest are a) what you just drew may not make any sense technologically, and b) the engineer charged with coding the feature is now going to spend almost all of his time dealing with issues like "Can you move that widget 10 pixels to the left?"

So we're trying something different.  Not just "design by prototype", but "design by prototype in Rails."  This is where a single engineer (and sometimes, such as in this case, a front end guy) work on a fully functional framework of what the feature should look like.  Depending on your skills this could either mean "start with the HTML and work backwards to add functionality", or it could mean "start with the web services and slap a front end on it."  The idea is to have a finished product that makes everybody happy:

  • Everybody can see and interact with it.
  • It has a real front-end, in code rather than Photoshop, so all the "move it 10 pixels over" issues are out of the way early.
  • The engineer who'll make the real version gets most of those potential "And what happens if I click this?" questions answered in a way that screenshots and word documents could never do.

Now, some people might say "We've been doing that for years."  Here's the catch, at least how we're doing it.  The current product is in ColdFusion, and we're moving it to .NET.  So what am I writing the prototypes in?  Simple - Ruby on Rails.

If you write your prototype in the same language as your real product, the temptation is far too great to just roll it out the door as Version 1.0.    That defeats the whole purpose, because now either your prototype takes longer to build because you know that it's going live to customers, or else you're burdened for the next year or more trying to hack and patch it and arguing about why oh why you made such and such decision back then, when now six months later you can clearly see that this was the wrong decision.

By prototyping in Rails, we halt this problem in its tracks by making it impossible to roll the prototype into production.  We don't even have a Rails production environment.  The goal of the prototype is the hand off to engineering.  It's not to have perfect code, or final look and feel, although the closer you get to both, the better.  The idea is to do the coding equivalent of a wireframe, where you say "Ok, this app essentially has half a dozen major sections.  Here they are, and here's how the customer gets from one to another."  Repeat and enhance with as much detail as you have time for.  My handoff meeting is actually in a few hours, and I will keep tweaking on it until I walk into that meeting.  (I'm on a train with no net access at the moment, you see....)

It also gets everybody playing to their strengths.  I am not a great "enterprise architecture" guy.  Sure I can say "I realize that this feature here is best served with a web service," but actually implementing that service in a meaningful way?  There are guys better suited to that.  So in my prototypes I whip up a quick service in Rails (typically REST style) with the knowledge that the enterprise guys can just drop in their replacement.  Meanwhile I know that I have one developer as "user interface engineer", and five who will only do markup on pain of death.  So the UI guy is charged with getting the prototype's markup as complete as possible, allowing the coders to come in and just replace the moving parts out from underneath.  The UI guy can do it faster, and can work with the graphic designers sooner, so they're happier that they see what the finished product will look like in week 1, instead of tweaking things 10 pixels to the left while trying to do QA in the last week before shipping.

Personally, I'm having a grand time.  This is the stuff I love.