Saturday, October 25, 2008

BrightKite for iPhone.

The fact it took BrightKite and Loopt as long as it did to distribute their iPhone apps must be some indication as to how niche the market continues to be. That's a bummer because location is going to be the next axis upon which the web tilts. GPS devices in rental cars are the first sign of more of the general population being exposed to apps that do cool things with latitude, longitude (and eventually altitude). However, we're still a long way away from "mainstream" geocoding devices/applications.

Anyway, a few weeks ago I blogged about Loopt's iPhone app; I'm very impressed with Loopt's implicit take on my location, layered with my personal description of my location (sort of akin to BrightKite's "placemark"), it's a model that better fits in my brain. Tried as I did to suck my BrightKite friends into Loopt, I couldn't. I'd say 10% of the folks I invited are still using Loopt today. 60% of them like BrightKite's iPhone/app model better, and the remaining 40% were friends I was trying to introduce to mobile/location apps on their iPhones, and they're simply not interested (or just had an allergic reaction to Loopt).

BrightKite for iPhone
BrightKite's got some UI hurdles to get over. If you're wondering what the first two buttons you see do, checkout this description. Even my friends who were telling me how great BK was couldn't tell me what those buttons did. I still don't know what all the little "lock" icons on the screens mean. Those are all usability/first-version issues that are easily fixed; which is a good thing.

What I struggle with in general with BrightKite is it's take on "checking in." They've catered to those who want explicit, delineated, boundaries around sharing their location with others. That's my primary gripe with BrightKite for iPhone; I want an app that just "checks me in" implicitly (maximum one button click). That said, with geo-location in particular, most users do indeed want explicit control over sharing their location. I'm an aberration in this respect, and I know that.

Implicit & Explicit
The issue of whether to actually share one's location implicitly or explicitly aside (the case can easily be made for that to be an explicit operation), BrightKite's other features need to become implicit.

A toggle for auto "Find me" goes too far in trying to comfort the user. The raison d'etre for the app is to "find me" and because I have to explicitly share my location, just go ahead and "find me." I'll decide whether or not I want to have my location shared. Exposing this as a top-level UI element adds clutter and confusion to the experience. Bury this down in settings/preferences if users really want the option to turn it on/off.

I like the "snap to" concept, but again, to me that's just something that should "just work" and not be an explicit toggle that I can turn on/off. If you're trying to pinpoint me, and you have an idea of where I am, just use that idea. If I have to manually correct it, I will. Obviously use my placemarks as the first order match (which BrightKite confirmed they're doing already), but the relationship between "pick a place" (in the iPhone app) and "placemarks" (on the website) is unclear.

Proprietary messaging in apps today, particularly phones, is extraneous. Just direct SMS in the future please; no need to reinvent this wheel.

Where's the map? A social application based on geo-location screams for the primary UI metaphor to be map driven.

In conclusion...
All in all, the top half of the default screen of the BrightKite app, the "I am..." section, should just go away. All of that can be implicitly derived, either based on my past experiences (e.g. check-ins), or via matching on the backend. I think Loopt has nailed the UI metaphors and the right level of location/sharing abstraction. I think BrightKite is providing lots of privacy-level/visibility and control. Undoubtedly users are asking for that control, but privacy can be a rat hole and I'd be careful building an app around giving the user everything they want on this topic. Loopt's taking some risks in this regard, but I think they're the right risks. Ultimately the end-user will decide.

For now, I'm using both services, and I suspect I'll have to leave Loopt in the ditch pretty soon because most of my friends are using BrightKite. These are social applications and their usefulness is primarily driven by how many of your friends are using them. I'm just stoked that there's competition in this space. Amazing things will come from location enabled applications.

Wednesday, October 22, 2008

Job Applicant Rejection

Gnip has a lot of candidates applying for various roles we're hiring for, and that means lots of applicants won't make the cut; simple law of averages (not to mention a high bar). That means I have the unfortunate responsibility of letting many candidates know that things aren't going to work out. I've been doing this a lot recently, so I thought I'd write about the process.

We have the following hiring process at Gnip, each step dependent on the previous one going well:
  1. 1on1 phone screen. 30 minutes.
  2. 30-45 minute coffee/tea with the whole team. informal get-to-know-eachother. casual conversation about who we are, who the candidate is, and everyone gets a sense of technical depth and capability.
  3. 4 hour on-site pair programming session. heavy technical discussion, and coding session working on actual code that Gnip needs to deploy; feature, bug, or whatever.
  4. Job offer
If any one of the three steps leading up to a job offer doesn't lead to the next step, I communicate that fact to the candidate (usually over email). What gets said in that communication is generally never easy to say. Some candidates wind up not liking Gnip along the way, and for them, hearing that we weren't interested yields a sigh of relief as they got an easy way out of having to tell us they weren't interested after all. Often this isn't the case however, and I have the un-enviable responsibility of telling someone things aren't going to work out. 

Describing exactly why they aren't going to work out is not easy; "it's not you, it's me" doesn't fly. Folks always say they want the brutal, honest, truth (I know that's what I would want), but delivering that on too deep and analytical a level, can often open up a conversation the barer of "bad news" doesn't have time for. Sometimes a declined candidate will want to discuss why our perspective was wrong, or why they were having an off day.

If you're in the position of having to tell someone "no," it's important to be decisive, clear, and to bring closure immediately. I also feel it's important to provide constructive feedback so a candidate has at least some information they can use to understand why things weren't a great fit. Perhaps they have a misconception about how they project themselves, or their skill-set, that they may want to "fix." Giving them enough to go on, I feel, is helpful and important.

Monday, October 13, 2008

Loopt for iPhone; wow

If you don't want to see a grown man gush like a tween at a Britney Spears concert, stop reading.

I've been a sucker for the pairing of lat/lng based data/apps for many years. Threading location into the fabric of the web "only makes sense." From my first mashup with Google's Map API, to my Garmin Forerunner 305 (and associated activities) I've taken the Geo location bait; hook line and sinker.

The advent of a "location" API on the iPhone (firmware 2.+) warmed my heart as it coupled a device I love (and hate at times) with lat/lng. Sadly, the Apple AppStore has been shockingly slow to pickup location aware applications (aka developers haven't written good stuff, or if they have they've kept it off the AppStore). I was further blown-away at Flickr's continued inability to automatically geo locate images I take on my iPhone, into "my flickr map." That one continues to baffle me; especially given that the majority of mobile phone pics uploaded to Flickr come from iPhones.

While Loopt failed to email me when their iPhone app finally went live, I did pull it down yesterday, and I have to say it's the poster-child of iPhone integration.

The Review
Decoupling where I say I am, from the actual GPS location was brilliant. You may see where I am on a map, but I never actually reveal the abstracted sense of where I am unless I want to. Granted, you can deduce it within a few yards very quickly, the separation was a solid way of giving me control over where the software says I am, and how I characterize my location. For example, Loopt knows I'm at latX and lngY, but I get to label that how I want. That can be "in Boulder," or "at my house;" my choice. Subtle, but powerful line to draw.

Of course, full control over whether my location is automatically logged, or manual; a given when it comes to location sensing/publishing.

Integration with the iPhone's contact list and mashing it up with other known Loopt users was gorgeous. The "add friends" button gives me multiple options, one of which is "from address book." Clicking on that shows me who in my address book is already on Loopt, and I can just check them off and "invite" with incredible ease (or invite folks not already on Loopt of course). Apps like these are only interesting if a critical mass of your friends are on them (same old social app story here).

Search for restaurants/businesses has some great defaults right out of the box, and displays Yelp! reviews on map markers right out of the gate; very well done.

Fantastic UI layout with tabs illustrating just what matters to me: map (where I am, and where my friends are), list (same thing in list view), what's up (a textual/comment/picture view of what's going on, and an opportunity for me to leave a "notice"/message about what I'm up to). Clicking on various UI elements does what you'd expect. Great high-level UI abstractions and "at a glance" usefulness, with anticipated deep-dive when I want it.

Ping functionality "pings" friends: basically a way of saying "here's where I am... come join me if you want." Dirt simple, but powerful.

Messaging friends, leverages iPhone's native SMS client. Call'ing friends uses iPhone's phone. And on and on. Basically, whenever you think the app should leverage existing facilities, it does. Loopt avoided the constant pitfall of building everything yourself. As a result, it's a hallmark for iPhone, multi-service/API, integreation. You can imagine the "how do we build a great Loopt app for the iPhone" product brainstorm, and everything that got put on the whiteboard, got implemented.

Gone are the days where I have to explicitly "checkin" to a location via SMS. Too much typing. Location feels like it's just a part of my device experience now and I can choose to not say anything about where I am, or post comments about it and add pictures.

While we're all enamored with the progress of "web apps," Loopt's iPhone App is why client-side software (coupled with web services obviously) is often still the winning combination.

Can't wait to see Brightkite launch the next salvo. A high bar has been put in place.

Saturday, October 11, 2008

"If there's gold in them hills..."

"If there's gold in them hills, people will find it."

I'm sure that quote's been used many times relative to software applications, but it keeps coming up in my life so I thought I'd take a moment to blog about what it means.

If you knew there was gold in that hill over there, you'd go get it. Software's the same thing. If you know there's gold (meaning something really fun/useful) in an application, you're going to do whatever you have to do in order to use it. Obviously, that's a tad absolute, but bare with me. You'll pay money... you'll register for it... you'll fill out a profile... etc.

People spend inordinate amounts of time trying to streamline the barrier to entry to their applications. Minimizing registration processes and building entire API abstractions (e.g. Open Social) on top of social applications is a constant pastime these days, and it's eating up mass amounts of energy that is often better spent on your true value proposition. I'd like to suggest that if you believe the barrier to entry to your consumer facing application is either the user creating an account, or filling out their profile information (for the 100th time), your application isn't worth your target demographic's time.

Streamlining these processes (OpenID, oAuth, Open Social, and the like) is a nice-to-have feature, but it ain't going to make or break your product.

Think about the "real-life" parallels. You'll spend an hour in line at the Department of Motor Vehicles in order to get your driver's license so you can drive. You'll spend 15 minutes on-hold to get the concert tickets you really want. Users will spend large amounts of time to get to your product if it's worth it, so focus on your _product_, not the one-time chunk of time a user has to invest to get to it. I gave Fly Clear scans of my eye's iris, and my fingerprints in hopes of saving a few extra minutes in-line at the airport (not to mention the intense/lengthy application process).

User's have spent the past several years creating potentially hundreds of accounts to get to what they want online. For the truly worthwhile products (facebook, myspace, amazon, etc), they'll invest hours on their "profiles." These nuissances have become understood and are accepted patterns (unfortunately).

OpenID, oAuth, & Open Social are fundamental as infrastructure components, but don't get lost in your product roadmap thinking you need any of these to make or break your application. The only exception would be if your application's target consumption is within an environment that only supports these standards. Smart people are working to make these standards easy to implement. Smart people can implement them without much energy. But, again, if you're finding your spending a lot of time building these things into you product in order make your product successful, pack it in, and go find a different product idea.

Wednesday, October 1, 2008

Gnip 2.0, and feeling good.

Posts like this are not my style, but I can't contain this one. Last night around 10pm MDT we released Gnip 2.0. In the past 15 hours, we've gotten the following public feedback from our users (engineers), speculators, technologists, and various media. This feels.... good. Of course you can view the live stream of twitter comments about Gnip here.

Some great tweets:
  • from a guy in Switzerland that demonstrated Gnip to his Ruby user group just hours after we went live with 2.0. "demo is over. #gnip and #sinatra presented to #RubyonRailsUserGroupSwitzerland. Thanks to the developer of the #ruby-gnip"
  • "bit embarrassing, new Esendex SDK doesn't easily allow mock api for unit testing, Gnip have done a better job, update looms before public"
  • "way to go Gnip on the 2.0 release!"
  • "Gnip 2.0 hits the ground. C'est magnifique, no? ehhhhhh oui. Bien sur."
  • "Gnip: neue Version, kostenpflichtig für kommerzielle Anbieter"
  • "wow Gnip 2.0 pushing the full twitter public feed via XMPP, that changes things."
  • "A web troika story abut Gnip and content aggregation"
  • "Happy days, Gnip have updated their API. TIme to contribute to their C# library"
  • "Gnip 2.0がビジネスモデル付きでロンチ: 複数のSNS間でデータの受け渡しができるというサービスGnipが、今夜(米国時間9/30.. » link to TechCrunch Japanese アーカイブ » Gnip 2.0がビジネスモデル付きでロンチ"
Some great (perhaps a tad overzealous) comments from various media stories about the launch:
  • "Having read the documentation, this sounds pretty cool. I predict it will signal the death of rss feeds. Applications will essentially behave like live stock tickers rather than explicitly soliciting data feeds."
  • "Well done GNIP. You rock!"
  • "Congrats Eric at team! it’s the next gen of RSS. I finally get the name too."
  • "By the time other people even begin realize how they’ve embedded themselves into the very framework of the entire social web, they’ll be a billion dollar company. They’re going to get as big as the social web itself."
That's how releases are supposed to go. So lucky to be working with this team.