The Social Bazaar

Vic Gundotra at Google IO keynote yesterday declared that the web had won. It is the dominant programming system. He then went on to introduce a host of new technologies. What does this mean for us in the real world of app development?

1. Mobile apps will eventually be web apps. (no more developing separately for Symbian, Iphone and Blackberry). Mobile browsers will soon be able to talk to native mobile features like the accelerometer, GPS and calling.
2. Web apps will be faster (browsers are getting faster through processing javascript quicker, allowing local data storage) and will compete head on with heavier and heavier desktop apps (think Google Photo Editor, Google Project and so on)
3. Geolocation is coming –  we’ve filtered information now by its popularity (Google / Digg), and by what our friends think (Facebook) and next we’ll filter by its proximity to us (Geolocation).

Obviously I care more about a friend or celebrity popping into a bar in the next road to me than I do about someone on the other side of the planet. Accurate, reliable geolocation services (see Firefox 3.5) are just around the corner for the mass market and will see a new way of filtering information.

For the techies out there here are a few links and notes to get you excited:

1.  HTML 5 will be in Firefox 3.5 and Chrome soon – looks cool – allows tag and enbaling pixel based layouts (draw a diagonal line). They showed a cool demo of rotating a playing video with a javascript transform.
2. 3D engine will be in browser natively so you can access with javascript
3.  Web Elements allows you to drop code snippets (like a comment wall) onto your web page really easily
4. App engine now supports Java – Manuel Lemos has managed to get PHP running on app engine as well
5.  Geolocation is going to be in and working in Firefox 3.5

Nudge has been beta testing the Spotify music player for several months now. It’s greatest strength is the ability to share songs and even entire play lists with a single URL.

Rather than send songs around in cumbersome 3Mb files you can simply send a 20 character URL. This will revolutionise the discussion around songs. Now every blog and web site that refers to a song can link its readers directly to the tune in question.

So…. now we’re at the end of the day – you probably need to chill out a bit? Well why not try this super cool Nudge says unwind playlist from the team here at Nudge (you’ll need the Spotify player to play it). Listen to Matt‘s Radiohead track, Paulius’s Red hot chili’s or my Mika version of Relax. The in-house DJ prize goes to Iskandar who found the gorgeous Samba Da Bencao.

I have a couple of invitations left so email me if you want one and start listening to the coolest music from the boys at Nudge.

Update 9 October 2008 – All invites now used up – Phil and Matthias I hope you enjoy!

On my amiando ticket to a techcrunch event on Thursday that I printed from my PC I found there was a funny deranged chess board pattern in top right corner.

Sticking my camera barcode reader onto it I found I could “read” it and discover the underlying number.

Turns out its called a “QR Code” and is a type of mobile phone friendly bar code.

It works by scanning the code into your phone which converts into either a long number, a telephone number or web address.

To try it use the QR Code above:

1. See if your mobile phone supports QR Codes (Nokia N82, N93, N93i, N95, N95 8GB, E66, E71, E90 or 6220 Classic)

2. Go to applications / Barcode

3. Open your camera shutter

4. Point it at the QR code at the top of this post until it registers

5. Go to the URL and see the funny picture.

I tried this for the first time today and it worked fairly well.

I guess this would suit an offline media campaign where you want to direct response to a complex URL.

So say for example say I was advertising Mamma Mia on DVD I could include the following QR Code on the billboard. 

In theory it will let you Pre-order Mamma Mia on DVD for £12.98 and save £9.01.

Unfortunately I found that this particular QR code was too big for my phone to read. It’s also a bit fiddly to get working in real life. Let me know if you have more luck!

However it does save on typing and is faster than typing out a long URL on your mobile phone.

To create  your own QR Code go to http://qrcode.kaywa.com/

I’m often asked to define what I mean by “social media”.

Here’s what I came up with in the heat of a live radio interview with Pooja on Westside Radio on Friday. (skip to minute 30:30)

Social Media is editorless content prioritised by popularity.

It is articles and programmes that have been published by individuals directly to friends and the rest of the world without going through an editor.

The filtering and prioritising role, traditionally done by an editor, is achieved by monitoring the popularity of the article. The more people that read it the article, comment on it, agree with it and pass it on – the higher that article appears in the list of social media items.

A great way to see this process in action is at Digg where you can see the headlines ordered in terms of popularity by all the members.

Update: 25/Feb/2009 – “prioritised editorless content”

Great to see twitter in use at the BBC’s new “Today Programme” website

Micro-blogging is the generic name for the twitter phenomenon.

Your twitter account is a micro-blog with small updates from your daily life – things you spot, what you’re up to. You send “tweets” via web or text message to update it. Friends “follow” your twitter blog to see what you’re up to.

It’s biggest usage is in Facebook statuses where users micro-blog what they’re up to “Toby is cleaning the house, Toby is watching the football” and so on. Often these are more twit than wit but they are a popular way of staying in touch with friends without actually talking to them.

It’s very early days for micro-blogging but it’s likely to be as influential as blogs but in the friend space – I tried a quick test with “Toby wants to know what digital camera to buy” Within minutes two friends (not techies) had responded with suggested product choices. Micro-blogging might be the right tool to bring my friends and their experience with me when I visit the shops.

You can get a competitive edge in web applications from the foundation language you use to make them.

Facebook, WordPress and now much of Yahoo is built on the PHP computer language, now the fourth most popular in the world. Pretty good for something that has been a community initiative from the word go.

At the PHP London conference yesterday, I was asked to give a talk (slides) on the Framework I’m using which is called CodeIgniter (CI).

CodeIgniter’s big benefit is that it is light to run and simple to learn. As a Facebook app developer, I love using it because it means I can deliver top quality Facebook apps quicker and faster than my competitors (apart from those that use CI too!)

It went head to head with a couple of other Frameworks called Zend and Symfony. Zend has been around for a while and Yahoo are backing the Symfony horse.

It was interesting for me to see the other frameworks (Zend and Symfony) which looked heavy, complex and slow in comparison to the super sleek CI.

In the debate, CodeIgniter fared pretty well – it’s main downsides noted by delegates were that it was PHP4 rather than PHP5, and that there was a fractured community around it (many former CodeIgniter developers left the CI community last year to create a “fork” of the main code called KohanaPHP).

The former turned out to be a non-issue as you can make CI a PHP5 only framework, while the latter is a niggle that needs addressing. Perhaps after a few summit meetings the two communities (CI and Kohana) might be persuaded to join forces for CodeIgniter 2.0. It would also be good to see a couple more big web names back CI as their framework.

Personally I didn’t see anything ‘better’ in the other frameworks, so I’m sticking to CodeIgniter for now. Each of the 300 developers at the conference will no doubt make up their own mind.

I gave a talk last Friday at a Microsoft Research workshop on online social networks, in Cambridge, UK (pictured) about Facebook.

In it I described the Facebook social utility as made up of three key technologies. By understanding these three you can succeed in the online Web 2 world.

The key three are:

1. Facebook Social Network – Facebook’s social network we’re all signed up to because it’s easy to use, clean and has features that are light but powerful. Popular for adding friends, sharing photos, organising events and chat. This is the Facebook most people think about and use daily.
2. Facebook Platform – the ground breaking developer technology that allows me to write games that Facebook users can instantly play with their nearest and dearest. Games have led the way but more useful applications are on their way.
3. Facebook Sweep– the 48 hour news “sweep” checks all your friends mini-feeds for interesting stories and publishes the few that it thinks you’ll be most interested in to your newsfeed home page.

Of them all I recommend a renewed focus on the sweep. I see the Sweep as a technology to rival Google’s PageRank – it socialises my news (shows me stuff relevant to me and my friends), it throttles the news (shows me only the most interesting news) and it learns my interests (I give it explicit and implicit feedback).

The organisations that understand and conquer Facebook Sweep will indeed be the winners on the web’s most popular new media channel. This is because my personal newsfeed is the most important page I go to when I want a head’s up on all that’s new and important in my world. If you and your brand are not here, then you aren’t anywhere…

I explained API’s in an earlier post, now, as someone who works with several APIs it’s time to put down my top ten features every API needs. If you’re working on a web 2 application and you haven’t thought about your API yet, then this is for you.

If you still need an analogy think of a railway station designer – you are making platforms for the trains to use. Everyone uses common elements to make it work – railway time, signals, timetable boards, track guage, platform numbers and so on. These are the building blocks of a good API – common standards and terms.

So, my top ten, in reverse order:

10. Provide good libraries and example code - it’s obvious but so often missed. You can’t just write your API and stop there – do the developer’s work for them and provide a class library and example app. Nothing gets us coding and using your API faster.

9. Fast Perfromance – no-one likes a slow coach, this is as true for platforms as for applications. If our application is fast we don’t want your platform to slow us down.

8. Use jargon – Jargon exists for a reason – to make sure we are all talking about the same thing. I’d rather learn new jargon FQL, FBML (et al.) than have to continually deal with long winded explanations of how the new technology differs from an old one.

7. Use jargon consistently – if a view is a list in your world keep using the word view for a list, don’t suddenly flick and use the word view for a viewing window. One word = one job.

6. Reduce the features- keep it simple, just have one way to do things. The more options there are to an API the harder it is to learn.

5. Version your platform – I know this is a contentious subject but versions really do help – even if you take the Microsoft approach of 16 digit version numbers. If you’re doing nightly builds then make this visible – there’s nothing more frustrating than seeing your app work one day and fail the next and you don’t know whether it’s your own slack code or that the platform has moved underneath you.

4. Add a Sandbox – Paypal’s developer Sandbox is absolutely wonderful, Facebook have some API and FQL tools that work. Give us ways to test our apps properly.

3. Support a developer forum - we learn best from others who have been there. Most API issues I solve by seeing how others who hit the same stumbling block did it – don’t forget to add a really good search engine.

2. Be a responsive tech team – if you put up a post on the forum or a bug in the tracker – you want a response asap. By the time a software project has got to the actual developers every day counts, this is the coal face and time waiting for the API team to get back is a real bind. Sometimes you can’t progress your code without their response.

1. Believe in Up-to-date documentation – if your documentation falls behind your API forget it, the worst phrase I see from API developers is “implemented but not documented” – well what use is that? Put in place a Wiki and get your developers to make updates if needed.

The nitty gritty of Web 2.0 is all aboutthe “API” – that’s short for Application Programming Interface.

API’s are the new doors into software programmes and web sites that allow other software programmes to “talk” to them without human interaction.

If you imagine the software as a big building, then the front entrance would be the “user interface” (where we all use the software i.e. when we browse the web), then the “application interface” is like the delivery entrance, where deliveries are sent. It’s another door to the same building but for a different type of building user. In this case its a door made for other computers instead of people.

An Application Programming Interface (API) allows other software applications to put information in, get information out and use services as if they were real users. For example the Google Maps API allows other applications to send a list of longitude and latitude coordinates and it will return a map with markers on each of those coordinates. Check out this Google Map ‘mash-up’ of World Bank country data to see what APIs can make easy.

APIs are not all created equal – some are wonderful and some are downright difficult to use.

As a web 2 programmer I deal with APIs on a daily basis. In my next blog post I’ll explain some of the ways to evaluate whether an API is any good, before you decide to use it.