November 30th, 2007 by adam

Andrew Chen has a great post on how people use Facebook and why MySpace pages are so ugly

I particularly liked the straightforward comparison between the opposing viewpoints on design, i.e.:

Facebook / Google / “modern” web companies:

  • Simple, Functional, Easy

Myspace / GeoCities / “poorly designed” web presences:

  • Lots of options - perceived as complicated
  • Entertaining - perceived as lacking a point
  • Layers of complexity - perceived as difficult

So. Scrapbooking. A $2.5 Billion industry, huh? Serious food for thought for game designers trying to think up ways to take advantage of Web 2.0, but struggling to break out of the boring “chat”, “friends lists”, and “character pages” ideas…

September 27th, 2007 by adam

“Often wrong, never in doubt” is the tagline on Marc Andreessen’s blog. With a recent post of his, on the “three kinds of platforms you meet on the internet”, I think the first part of that tagline is ringing true :P - Marc is talking nonsense with his claims that “[a Level 3 platform is] much better for the developer [than a Level 2 one]“

It’s great that he’s trying to “disentangle and examine the topic of Internet Platform”, but … seriously, there are good analyses and bad analyses, and this one rings jarringly false to me.

To save you reading the whole thing initially, here’s Andrew Chen’s summary:

The fastest summary:

* A Level 1 platform’s apps run elsewhere, and call into the platform via a web services API to draw on data and services — this is how Flickr does it.

* A Level 2 platform’s apps run elsewhere, but inject functionality into the platform via a plug-in API — this is how Facebook does it. Most likely, a Level 2 platform’s apps also call into the platform via a web services API to draw on data and services.

* A Level 3 platform’s apps run inside the platform itself — the platform provides the “runtime environment” within which the app’s code runs.

And which companies are working on Level 3 platforms, other than Marc’s Ning?

* Salesforce.com

* SecondLife

* Amazon (through AWS)

* Akamai

Which is fine, but I need to add Marc’s statement that

I call these Internet platform models “levels”, because as you go from Level 1 to Level 2 to Level 3, as I will explain, each kind of platform is harder to build, but much better for the developer. Further, as I will also explain, each level typically supersets the levels below.

  1. Are they monotonically harder to build?
    • Yes
  2. Do they typically superset the levels below?
    • Yes
  3. Are they “much better for the developer”?
    • Hell no

Marc has written a very programmer-centric post here. He’s identified that, technically speaking, the different classes of platform are “bigger” than each other and obey a transitive, non-commutative, superset relationship. Natural consequences of that are the first two items I hilight in his claims above.

But he’s then made the mistake of conflating this with *entirely unsubstantiated* business concepts of “better”. As the developer of one of these “level 3″ platforms he contends are “best”, it’s no wonder that he wants to believe that it is a *logical* conclusion that the business advantage comes forth just as the technical conclusions are logically sound. But wanting to believing a thing doesn’t make it true. And whilst I genuinely believe he could have provided a decent argument that makes it true *for his business*, I think it’s not only an illogical claim, but actually false, in the general case.

Specifically, I would like to know how a level 3 is “better for the developer” than a level 2?

And I’m sorry, but I’m going to stop calling them “levels”; they are only levels in a programming sense, not in a business sense, and to name them that way implies something is globally true that only applies to one aspect of them.

Going from class 2 to class 3, you:

  1. have to do more work
  2. pay more in ongoing costs
  3. provide no appreciable benefit to any user who is also a competent developer

To give an example of a valid way of making the “3 beats 2″ argument work is that you could argue that if your target-market is people who can’t write code at all then the third point above is irrelevant, and that actually you ARE adding value.

But for all the other users - and, let’s be fair here, Marc chooses *Facebook* as one of his examples of class TWO, not three; Facebook, where pretty much any idiot can (and does) write a facebook app within a matter of days or hours - point three above means you aren’t adding any value at all by moving to class 3.

Hosting is incredibly cheap these days, and developing basic functionality is incredibly easy - as mentioned, look at the proliferation of non-programmers and what they’ve done on FB. Reducing the dev cost and hosting cost over and above a level 2 platform seems to have very little actual point to it.

And, worst of all, with a level 3 platform, you make it into an “all-or-nothing” proposal, completely about-face from what has driven the proliferation of Web 2.0. You create a walled-garden of proprietaryness, where every user is dependent upon your ongoing existence. Facebook expressly does not do this.

Even when people use your service because they have no choice but to limit themselves to your walled-garden, you will scare away vast swathes of the best users because they will be rightly suspicious that yours is a proprietary platform that they cannot exist without.

I would rather contend that class 2 apps are the best of all. Why? Because:

If I develop an FB app, and FB disappears tomorrow, I can still run my app all over the web with almost literally no changes to code.

On the other hand (and I know many examples of where this has prevented people from using SL, even though LL have taken many steps to blur this and insulate people from the problem, including open-sourcing pretty much everything)

If I develop something in SL, and Linden implodes tomorrow … I lose my entire ability to conduct business.

I think it’s telling that even in Marc’s post it’s clear he was struggling to find examples of class 3 platforms. I think it’s disingenuous to even put SL in that category, since it is (as noted) moving so strongly and rapidly towards being something different - they’re even talking about allowing anyone to run the servers themselves. If they’re a poster-child for level 3 being “much better for the developer”, then why are they running full-tilt for becoming something that would only fit in his level 2?

September 21st, 2007 by adam

(Only a couple of these are java-specific, but this is a.k.a.: “How to make Facebook Apps using Java - part 3″)

(I assume you’ve already had a look at part 1 and part 2? They’re more beginner-oriented)

Bugs, Misconceptions, and Subtle Features

Interfacing with Facebook’s servers is pretty hard, considering how seemingly trivial the interface is. Obviously the almost total lack of documentation is mostly to blame for this, but some of it is just common bugs that have yet to be fixed.

So, here’s ten things I’ve found whilst fiddling with the API, and some of the nicer features that may not be immediately obvious even if you do read the docs provided by FB (you should go read all of them, but … there’s some bad organization and layout, so it can be a chore reading the mega-long HTML pages, with many of the API features having just blanks for description fields :( ).

(more…)

September 3rd, 2007 by adam

The entire switch here is to think of these websites not as collections of features or products, but rather manufactured experiences that are designed to be compelling wastes of peoples’ time ;-) — Andrew Chen

http://andrewchen.typepad.com/andrew_chens_blog/2007/08/reward-schedule.html

August 13th, 2007 by adam

In the first part, I covered a very high-level, idiot-guide to getting started with writing a Facebook app in java. This part will cover the details of how to architect your own code for basic Facebook authentication, and include code samples you can use to get up and running more quickly. It will also explain in more detail precisely how Facebook’s servers interact with your code, and what you can expect (and what their servers expect of you!).

NB: if the quoted source code is unreadable because it disappears off the edge of the screen, select it and copy/paste (or view source of the page to see it). The most useful stuff is put together into one class you can download here - source code for FacebookLoginServlet.java.
(more…)

August 2nd, 2007 by adam

I wrote a game last weekend, for Facebook. Writing the entire multiplayer persistent game took a day and a half; getting it to integrate with Facebook is taking several days. Mostly, the problem is that Facebook hasn’t - yet - provided user-guide documentation, and there are plenty of bugs in their system. Without docs, you have to guess whether a “nothing happens” is due to your mistaken guesswork, a bug in FB, or … a bug in your own code. That’s fine, but it takes time, lots of time.

Google kept giving me zero hits for any of the problems, or even any java-focussed docs (just one link to a FAQ on an issue that seems to be a bug that was fixed a while ago. That’s all). So, as I solve the various problems that come up, I’m writing about them.

Platform

First thing to be clear about: if you want to write FB apps using java, you’ll be using Enterprise Edition (J2EE). The way FB works *requires* you to provide a webserver for your app. Whilst its true that java can run in the web browser, that’s a completely different way of using java - for this, you’re going to have to find a server, and install J2EE (it’s the same as standard java, just has lots of extra libraries, only a few of which you’ll need to use).

Facebook Apps: how they work

This diagram shows a very simplistic summary of the different URL’s you are asked for when registering a Facebook application, or are used when serving an App. Note that FBML is served entirely internally in the FB server, it does NOT make a request to your web server.

Basic explanation of facebook servers

First step: Registering your Facebook Application

Assuming you can find yourself a webserver/J2EE server to run your app on, and have a domain name for it (or the hosting provider gives you a default domain-name - you don’t HAVE to buy one just for your app), the first thing to do is register the app with Facebook. This just reserves the name of your app, and gets you the login details you’ll need before you can do ANY testing or development.

This process is actually nicely documented (and is also very simple - although the huge scary forms they ask you to fill in are very poorly explained, there’s a only a few fields you actually *need* to fill in). Don’t follow the list of things on that page literally, see the differences below that you want to make.

For the URL’s you need to fill-in, you’ll be making a servlet for each. So, work out the URL for each of the servlets (depends on how you setup your J2EE server), and have them ready to give to FB.

So, to summarise:

  1. Create a Facebook account if you don’t have one, and login
  2. Add the “Developer” app to your account (link is here)
  3. Go to your Home page on FB
  4. Click on the Developer app in the sidebar to go to the main centre for all your Developer activity
  5. Make a new application, and fill in the form it presents you with (make sure you do at least:
    1. App name
    2. Callback URL (see the example app)
    3. Canvas page (see the example app)
    4. iFrame (not FBML)
    5. Post-add URL (see the example app)
  6. Save the api-key and the session-key that it now displays for the newly-created app - you’ll need them to do any coding

First test: Can Facebook display your Application?

Create the various servlets on your server (callback, postadd, and canvas) and make each of them return basic HTML that just says “callback servlet”, “postadd servlet”, or “canvas servlet”).

Open a new browser window, and type in the canvas page URL from FB, something like: http://apps.facebook.com/yourApplicationName

You might be asked some security stuff by FB, but once you’ve got past that you should then see a Facebook page with the navbars etc, but just a big empty space in the middle with the test “callback servlet”. If so, congratulations, you’ve got your app basically working. Now comes all the hard stuff…

If not, first check that your servlet is even working, by copy/pasting the callback URL from your FB application setttings (click Edit Settings to re-load the form you submitted) into a browser window, and seeing if you can get the page. You’ve probably got a typo in the URL you gave FB. If the “callback servlet” text doesn’t come up on its own, without all the FB stuff, then your J2EE server is misconfigured or broken. Time for you to go find some Tomcat / jBoss / etc tutorials and get your J2EE working…

Part two…

Now you can move on to part 2 of this series, covering the details of how to authenticate with Facebook and start doing interesting work, including sample source code.