mindlets

Sunday, September 14, 2008

facebook and death

Just checked my Facebook profile. Once nice feature of Facebook is that it shows you the picture of 6 of your friends, picked randomly (or using some algorithm I have not figured out). I often use it to find out what so and so has been up to lately. All in all it's probably the feature I and many others use the most.

Today, my friend and former colleague Jonathan popped up. Jonathan tragically passed away earlier this summer, at the tender age of 39. Here he is, smiling with a beach in the background. After staring at it for a bit, I clicked and reread some of the nice things people had written on his wall. I also went through the pictures, remembered some shared moments, wondered how his family is dealing. I thought about writing on his wall, but did not really feel up to it. Maybe some day. In the end, I did not get less from visiting Jonathan's profile as I would from visiting anyone else's. Fewer news, but more remembrance and meditation perhaps.

This got me thinking. What happens to your profile when you die? In the case of facebook, it looks like it's business as usual. Everything works. You can actually send friends requests too.

Facebook used to take deceased people's profiles offline and changed the policy by popular demand. That's good. Perhaps a clearer indication of status could be provided, and some features, like messaging or friending, turned off at the request of the family or will executors.

Also, what happens after years of inactivity from the account owner? Some sites freeze or terminate your account if you don't use the site for a long time. Does facebook have such a policy? Will it? If so, will my deceased friends disappear from my profile without asking?

At some point social networks are going to have to deal with this question. Whatever happens, I hope facebook does not take my deceased friends away without asking me.

Labels: , ,

Friday, September 12, 2008

open hack 08

I was one of the lucky ones to participate in Yahoo!'s open hack day today. Yeah! I got a t-shirt, a thermos bottle, and a whole bunch of stickers. I got to learn some new stuff as well.

The goal of the 2-day event is mostly to introduce the latest API developments at Yahoo!, to the web developer community. Among the represented technos where flickr, fire eagle, yahoo's mail, music, search, geo, apis, and more. I could not see everything, and focused mostly on learning about Yahoo! Application platform, which the Yahoo! folks let us preview.

The general idea is this: 1. Centralize all the profile and social graph information currently help in the various Yahoo! properties. 2. Provide APIs to access all that good stuff. 3. Align these APIs with the opensocial spec whenever applicable.

As an opensocial application developer, the prospect of the giant Yahoo becoming the next opensocial container on the block is fascinating. This can potentially make myspace - the current behemoth - look like like an upstart.

Well, not so fast. There are a lot of tricky problems to solve, not the least of which is how you merge the relationships you have built on flickr, yahoo messenger, contacts, 360, etc... Still, this is very promising, so I decided to turn one of my zembly widgets into a yap opensocial application. Unfortunately, my initial excitement was quickly tempered by the following setbacks.

First, YAP does not take a gadget XML as input. Instead you have to give it a URL to the html page. No biggie. Juts give it the widget iframe link

Next obstacle: no external script is allowed. My widget used prototype.js methods, so I took out the prototype dependency and implemented replacements in my widget. Good thing I was not using much. I also had to inline in my widget the zembly gadget time (things-gadgets.js).

Next obstacle: YAP uses Caja... And Caja did not like many things about my widget. If you claim that your widget is xhtml, as in
<html xmlns="http://www.w3.org/1999/xhtml">

it will parse it as xml. It tripped on the first lower-than comparison in the script, thinking it was a new element.
if (cur < startIndex) {

The trick here was to convert the statement into a greater-than comparison.
if (startIndex > cur) {

Then Caja fussed about a bunch of javascript syntax issues. One Caja rule I ran against is the global scope leaking problem. Supporting Caja in zembly is going to require some work on the part of widget developers.

In the end, some of the caja errors where due to zembly the widget runtime, which I could not hack, so my first yap app never ran. I was able to turn my code into something caja compliant. In the process I found the caja test bed to be very useful.

Aside from hacking, another interesting talk was about an experiment by a Yahoo! team in building a complete app on myspace. Here is a summary of their findings was:

Pleasure:
* Documentation (opensocial, myspace)
* Plain standard stuff (no FBML, FBJS, or other proprietary language)
* ability to quickly move to another container

Pain
* unpredictable caching
* platform outages
* lack of communication regarding changes in platform
* inconsistent spec file support between containers
* UI load time. It takes time to go and fetch the data after load and it does affect the user experience. The team even suggested server-side UI rendering backed up with REST services calls, and combined with doing a document.write() in the gadget UI code.

Labels: , , ,