Klepopotamus

You know it’s going to be a good one when a Facebook developer blog post starts with “At Facebook, our passion for serving users…”, so I wasn’t particularly surprised by this declaration that Facebook’s new policy aims to regulate the emotion of “surprise”:

Users must not be surprised by the outcome of an action they take.

Granted, everybody knows what they’re referring to. You click on a random tab in SuperPoke and suddenly you’ve accidentally notified your friends that you’re gay. Surprise!

I think it’s a dangerous trend to regulate the behavior of applications through anything other than technical means. Ultimately, the guidelines will be useless if they are full of arbitrary passages like this that are subject to interpretation. I now feel the need to sprinkle my apps with comments to avoid surprise — “Just so you know, when you click this button, the page is going to reload. Please don’t be surprised. Maybe grab a friend to calm you down in case you start getting nervous.”

 

I hate to be pedantic, but I find something lacking in the Mac OS X Dictionary’s definition of pedantic:

pedantic |pəˈdantik|
adjective
of or like a pedant : many of the essays are long, dense, and too pedantic to hold great appeal.

 

Marni: Brett Hilton recommended Baby Depot.

Scott: Is that a web site?

Marni: No, it’s someone I work with.

 

Especially early on, starting a company is about addressing one overarching concern that, if solved, will totally make everything so much easier.

When I first started thinking about SpotDJ, I had a job. Being a loyal employee not looking to get sued, I only worked on the project during nights and weekends. Which is to say, I didn’t really work on it at all. I can’t remember what was filling up all my free time back then, but I knew that I could build and launch a product if I just quit my job and devoted all that new found time to it; that was all that was holding me back.

After quitting the job, I realized that I couldn’t possibly go on without a cofounder. If I had somebody else, particularly someone who understood all that business stuff and could worry about money, everything would fall into place. Once I found a cofounder, I needed money. After all, I had quit my freakin job and hadn’t had a salary for weeks now! We were just one step away from success and that step was raising a small seed round.

Okay, round raised. Now if we can only find another engineer. Because it’s very risky to build something solo… Then we needed a designer, because I sure as hell can’t draw….

It went on from there, and still continues. There’s always just this one thing that’s keeping you from success. The only thing that changes is that eventually you figure out that once you get that one thing, there will always be another. Nothing really makes things that much easier — it just reveals the next challenge.

Up next: Your Friends Won’t Be the Rabid Beta Users You Think They’ll Be

 

When we write proposals for Facebook applications, we typically include definitions for the Facebook-specific terms we use, like wall, mini-feed, and notification. Facebook doesn’t provide much in the way of official definitions for these features, and new users are often confused by the similarity between the wall, messages, notifications, requests, and emails.

To clear up some of the confusion for people new to Facebook or new to Facebook applications, here is my unofficial guide to some select Facebook viral features. For each feature, I’ve provided a description, the “intended” usage, the common usage, and some comments. Note that for most features, there is no “official” usage so the “intended” usage is what I’ve distilled from talking to other developers, both inside and outside Facebook.

I’m putting this first because I know you’re busy starting a company and I can save you a lot of time by telling you to skip all the other tips and listen to this one. Or don’t. That’s the whole point.

When I, and later we, were first starting out, we sought a lot of advice. We talked to friends, mentors, other startup veterans, current founders, VC contacts, teachers, etc. Most of them had really good advice, but the problem was that we talked to too many people. For every smart person who gave a given piece of advice, we could find an equally smart person who said the exact opposite. I remember one drive down the Peninsula where we mapped out exactly who was in which camp on each issue.

The fact is that when people give you advice, they’re basing it on either something that worked for them, or something that went horribly wrong for them. If they never got to a million users, they’ll tell you, “Don’t bother building in scalability up front — just get the product out there.” If they were bought by Google for their caching technology, they’ll tell you, “Focus on the platform, keep the product simple.” On financing especially, you get advice all over the map. “Take as little money as possible to get to your next proof point.” “Take as much as you can right now in case things don’t work out right away.” “Don’t take money from the A-list VCs because they’ll pressure you into taking a bigger risk.” “Don’t take money from some no-name VC because it’s all about the smart money.”

It’s not that the advice isn’t helpful, it’s just that following any one person’s advice is almost certain to be wrong. They started their company in a different time, a different space, with different constraints. You should listen to as many people as possible, but also realize that they’re not really giving you advice, they’re giving you their own biases. Many of the best advisers realize that and will be upfront — “…of course, that’s just what worked for me.” But if you’re talking to someone who doesn’t add that disclaimer, be sure to add it yourself as the advice enters your brain. Or don’t — that’s just what ended up working for me.

Up next: You Will Always Be One Step Away…

 

When I started a company a year and a half ago, I also started a list of things that would’ve been useful to have known ahead of time. My plan was to publish the list several years later in hindsight, but now that I’ve reached a nice round number (37) and half of my friends are starting companies, I thought it would be appropriate to start blogging a few of the less embarrassing ones.

I’ll be focusing on one item in each post, but don’t worry — after you read tip #1, you won’t have to read any of the others. Here are the first five I’m going to write about:

1. Don’t Listen to Me or Anybody Else
2. You Will Always Be One Step Away…
3. Your Friends Won’t Be the Rabid Beta Users You Think They’ll Be
4. It’ll Never Be “Obvious” in Six Months
5. Technical Cop-Outs are Lame

 

Many of the prominent blog posts and press pieces about OpenSocial have touted its use of open standards a key benefit for developers. Focusing on HTML and JavaScript is not only inaccurate, but it actually makes the platform less attractive for developers.

We Like FBML
As a developer, I am far more interested in coding in FBML than in HTML for the following reasons:

• It’s a superset. FBML isn’t a “proprietary language,” it’s a set of tags added to HTML that make it easier to write social apps. With FBML, I can show or hide elements of the page based on whether two users are friends — it’s a simple tag that Facebook handles on their side. If I were using HTML, it would be up to me to figure out if the two users are friends through an API call.
• It’s high performance. With FBML, I can add features and logic to a page without my server doing any work. This is because certain features of Facebook (ranging from friend links to wall functionality) are just built in and are reduced to simple view elements.
• It’s a view layer. If you knew nothing about CSS, you could still create an attractive Facebook page with an appearance consistent to the rest of the site just using the built in tags.

As a developer, FBML is handing parts of the logic of my app, most of the appearance, and offloading work from my server. OpenSocial, as we currently know it, offers none of these features and touts that gaping hole as a key advantage!

Facebook Applications Can Be Written with HTML and JavaScript
Even if you were convinced that a social application platform that requires nothing more than HTML and JavaScript was somehow desirable, you’d be wrong in saying that it’s not something Facebook offers. With an iframe app, or even an FBML app that only uses the HTML portions of FBML, you can essentially do the same things. If you needed to make API calls, which are done in JavaScript in OpenSocial, you’d either dip a bit into FBML and realize that it’s much easier than writing code, or you’d do it on the server side, where controller logic actually belongs!

OpenSocial is Java
I’m far from the first person to compare OpenSocial to Java, but I agree that the comparison is apt. When I was in high school and read about Java, I was excited that there would finally be a platform that would run all the world’s software regardless of the hardware and OS it ran on. Java made a huge splash but it took a long time for the reality to come anywhere near the hype. The challenge for OpenSocial will be to get real apps running in real containers in a way that resembles something more than some interesting demos. That plus a real security model would do the trick.

A Press Piece Masquerading as a Technical Feature
If Facebook developers aren’t excited about a platform that uses open standards, who is all the talk about open standards aimed at? Developers who haven’t written social apps yet? The ones who have been chomping at the bit with some really great ideas, but have been waiting on the sidelines because Ning didn’t have a platform yet? Obviously, it’s something that sounds technical, but it’s PR. Open standards sound good, proprietary language doesn’t. Which makes it too bad that…

OpenSocial Needs Its Own Markup Language
OpenSocial needs its own markup language to be successful. There needs to be a clean way for containers to extend that markup language and API calls in a namespaced and gracefully degrading way. It would be a significant change in the architecture of OpenSocial to do it, but I believe it’s necessary. Otherwise, all we’ve got are iframes — widgets with some small degree of integration into the container.

OpenSocial is an Opportunity
I’m annoyed at this one aspect of how OpenSocial is being positioned, but at a higher level, I still think it’s a good idea with lots of potential. I don’t believe for a moment that developers will be able to write once and run anywhere if their app has any interesting functionality. But I also don’t think it’s necessary to have 100% parity on all containers. The best thing about Facebook apps is how well they integrate with Facebook. To write a really good OpenSocial app, it should be focused on particular containers and integrated with the unique features those containers offer. I’m also glad to see other networks start to open up and offer a little healthy competition against Facebook’s platform. As Facebook app developers, we’ve already received inquiries about OpenSocial development and intend to pursue it aggressively. Should be pretty easy — it uses open standards!

 

Working creatively with APIs is one of the things that makes software development fun. APIs exist mainly to allow third parties to add functionality to software that the original authors don’t have the time, interest, or creativity to do on their own.

Most APIs are built to limit functionality, or more kindly, at least to encourage certain types of functionality over others. For about a year, I wrote software that worked with the iTunes API, which can be summarized as follows:


getTrackTitle();
getArtistName();
play();
pause();
stop();
nextTrack();
previousTrack();


The iTunes API was clearly designed by committee. A bunch of people reserved a conference room with the noble goal of designing a way for other programs to interface with iTunes. They ended up talking about all the things that they had to prevent other applications from doing. Most likely, the concerns they enumerated included usability, security, piracy, loss of control, loss of revenue, and ongoing support.

As a result, most applications that use the iTunes API are glorified remote controls. The deeper integration that you see in products like our SpotDJ Classic and iLike are, put simply, total hacks. We used the APIs in ways that it was neither designed or intended for. As a result, we spent a lot of time futzing with undocumented hacks and less time building great new features.

When I start looking at a new API, I generally begin with two things. First, what do the sample apps do? Second, what are the API calls? Most of the time, this gives me a pretty good sense of what the designer intended. When the Facebook platform was released, it only resulted in more questions. The reference app for developers was called “Footprints.” It was an app so simple and uninteresting that I don’t even remember what it did. It largely served to educate developers about Facebook’s novel approach to developing add-ons for a web site — specifically, a REST-based API to obtain information from the service with a custom query language and a homegrown markup language to leverage the existing user interface and functionality of the site. The documentation was sparse, and completely unwritten in some points. It failed to answer basic questions like “What is a ‘wall’? How do people invite other people to use my app? What’s the best way to do X? Is it okay to do Y?”

Whether by design, through evolution, or just happy coincidence, the Facebook API inspires rather than limits. Instead of sitting down and making a list of use cases that they wanted to prohibit, the Facebook developers most likely listed the different parts of their system and brainstormed how to expose them to developers. I’m sure that examples of possible applications were discussed, but the smartest move was recognizing that the truly valuable applications were the ones that Facebook itself hadn’t yet thought of.

When we work with clients on Facebook applications, one of the approaches we use, either internally or with the client, is to focus on a particular part of the API and brainstorm ways that it could be used for their application. Note that this wouldn’t work so well for an API like iTunes (”Let’s do something really unique with pause();!”) but it works quite well with the Facebook API (”What do feed items mean for a game?” “How can we use a profile action to encourage replay?” “How will users want to stay connected via the mobile API?”)

As the API has grown and thousands of apps have been released, best practices have emerged along with novel implementations that stretch the boundaries of the API and inspire developers to further explore what’s possible. At the same time, a developer community has built out documentation, frameworks, and guidelines that Facebook itself supports and encourages. As other networks release their own APIs or implementations of OpenSocial, it will be interesting to see which ones limit their developers and which ones take the less prescriptive approach and really foster creativity.

 

In the UN’s list of oppressed peoples, Condominium Developers are somewhere below adorable kittens. Yet I recently found my politically inactive self speaking in favor of San Francisco’s 7 Hills Developers at a recent Board of Supervisors meeting.

About three blocks from our house is an abandoned paint store. The parking lot is fenced off and overgrown with weeds. Its perimeter is littered with broken bottles and random trash. Last week, I saw a guy taking a piss there in broad daylight. It’s a blight in every sense of the word — even the building itself is a 50’s stucco monstrosity that replaced what was originally a tasteful early 1900’s combination of shops and apartments.

Land is valuable, so of course somebody owns this property. It was sold to 7 Hills, which planned to tear down the paint store and build something more in the original style of the neighborhood with a large storefront (Walgreens) at the street level and condos above. Through working with the neighbors, they spent a year or two refining the plan and agreeing to improve the surrounding sidewalks, plant trees, provide 24 hour security, and change their plans to improve traffic flow.

Of course, it’s San Francisco so no matter how liberal you are, there’s somebody who’s even further left. In this case, lots of people. The Mission Anti-Displacement Coalition is a group whose agenda is to preserve/restore the affordability of the Mission District for the people who have historically lived there. A worthy goal, but sought in an entirely bizarre way. After the condo plan was approved by the Planning Commission, the MAC filed an appeal with the Board of Supervisors, claiming that the Environmental Impact Report had failed to take into account the social impacts that the new development would have.

There is some precedent for this. Apparently in an earlier decision, the Board overturned the Planning Commission’s approval of a project by saying that it would upset the social characteristics of the neighborhood. That decision, if it were allowed to be repeated, would set the precendent that every Planning Commission approval was subject to the Board’s opinion on social impacts, something clearly impossible to quantify.

Support was strong on both sides and not as racially divided as one might think. Arguments supporting the project:

• The site is a high crime area because it has been neglected
• The developer has worked with the community and made many concessions
• Nobody is being displaced — no housing units are being torn down
• The development exceeds the required number of below market rate (BMR) units
• There is no reasonable alternative being proposed

Arguments against the project:

• There are several Walgreens within spitting distance
• This is an opportunity to build a new Day Laborer center and 100% affordable housing
• Luxury condos do not belong in the Mission
• The plan is inconsistent with the city’s overall plan for the Eastern Neighborhoods

The last point in the arguments against was something I was not familiar with. Apparently the city is in the process of adopting an overall plan for neighborhoods such as ours, and apparently it involves lots and lots of low income housing. But it’s not formalized yet and I’d be surprised and terrified it meant that we could *only* build low income housing, so I fail to see its relevance.

Here’s something interesting though: Last year, the owners of the property said that they’d entertain any reasonable offer for someone else to buy the property and build an alternative project. The crux of the argument that the MAC was making was that they had the support to build a 100% affordable housing project, yet nobody was stepping up saying that they had the funds. And the owner of the property said they had received no reasonable offer. So I fail to see the relevance.

It was a tedious and tense Board of Supervisor’s meeting. I left work early to attend and got home around 11pm. Supporters on both sides were organizing community members as they arrived, giving out stickers in support of the project and arranging translators as necessary. There were a large overflow room where you could watch the debate and a play area set up for children.

Voting was postponed because public comment took so long. As I was sitting there watching this, I was both proud to live in San Francisco, where people are politically active and the process is so open, and embarassed. After all, anywhere else in the country, replacing a drug dealing corner with a 24-hour store, more lighting, and housing opportunities for middle income wage earners, would be a no brainer. In most places, the city government would probably kick in a few bucks to get a developer on the project. When I spoke, towards the end, I didn’t really add anything that hadn’t been said 100 times already — choose a Walgreens over an abandoned lot. For me, that’s all it came down to.

So two weeks later, the board meets again to vote. The rumor was that it was pretty close. In the blink of an eye though, it was over. Supervisor Ammiano (our district’s supervisor, who accepted the appeal) made an argument against the project, then another Supervisor (I forget who) called for a vote and it was over — by one vote, the project can proceed. I have to wonder what actually happened behind the scenes. I’m assuming that all the supervisors knew how all the other supervisors were going to vote ahead of time. The supervisors in that immediate area *had* to vote against the project or it would look like they didn’t care about the largest minority (majority?) population of their district. There was probably an element of “Let’s make sure this passes so it doesn’t set a precedent, but I’m going to vote against it.”

So that’s a little taste of San Francisco local politics. Hopefully it’s the last time I get involved.