I’ve split the presentation I gave up into three separate blog posts, which I’ll be putting up over the next few days. This one will cover basic use of the navigator.geolocation API, with the next two showing you how to use the data that gives you to find out where the user actually is, and to plot that data using Google’s static maps API.

To start, I should explain that Beer Near Me was only ever intended to be used as a platform to be used to help me learn about the navigator.geolocation API and how it works. All the data that gets shown by the site was initially kind of secondary to me, as was the map that I use to show it off.

Of course, navigator.geolocation turned out to be far easier to work with than I expected.

Support for navigator.geolocation

The first thing to be aware of is that right now, support for navigator.geolocation is pretty poor. If you’re using Firefox 3.5+ or Mobile Safari you can use it out of the box, and you can turn on geolocation support in Chrome, but apart from that you’re plain out of luck. Since the idea behind Beer Near Me was to learn about navigator.geolocation that means that right now I’m not supporting any other APIs.

It’s not all doom and gloom though. There are implementations of the API available for use in other browsers as plugins – for example Geode will get you support in earlier versions of Firefox 3, and Google Gears opens up the ability to play with geolocation in some other browsers. There’s also Loki (a Skyhook based plugin) that will get you support over a whole bunch of browsers but uses a differently specified API. Of course, I’ve not actually used any of these, so your guess is as good as mine as to whether they are any good or not. I seem to remember Loki looking interesting a couple of years ago.

Finding a location

So, how to actually use navigator.geolocation? Well, a good place to start would be checking whether the browser supports it. We’ll do this in JavaScript, since that’s the only place we can reliably perform the check.

if (navigator.geolocation) {
    // do geolocation
} else {
    // say sorry to the user
}

Pretty simple. It’s your standard JavaScript functionality check. If we have the functionality available then we can actually do something with it.

navigator.geolocation.getCurrentPosition(
    foundLocation, // a user generated function
    noLocation,    // yup, user generated too
    {
        enableHighAccuracy: true,
        maximumAge: 1800,
        timeout: 30
    }
);

Here, we’re calling getCurrentLocation() with two callback functions and some options. Once the browser (and the user) has decided whether or not to return a location, either the foundLocation or noLocation functions that you get to write are called, and the user’s location is passed into them.

Before we get to those callback functions though, lets talk for a minute about the options we’re passing into getCurrentPosition(). Essentially, what we’re saying in the code above is:

Try to give me highly accurate positioning if possible. I’d like to actually know where I am.

Oh, and if you have a position cached that’s no older than 30 minutes, could you give me that immediately please? I know that kind of contradicts what I said a moment ago, but I know better than you.

And one more thing – if it takes you longer than 30 seconds to work out where you are, just give up. There’s a good fellow.

And that’s it really, with that little bit of code we’ve set up the browser to do some magic and try and work out where it is.

Watching for changes to the user’s location

The only problem with this is that the iPhone in particular seems a bit rubbish at following these instructions. The first result it sends back seems to be uniformly Not Good, and generally quite old. So what can we do about that? Thankfully, there’s an easy answer provided to us in the API – the watchPosition() function. This uses exactly the same parameters as getCurrentLocation() and can simply be dropped in as a replacement for it.

watchPosition does what you’d expect it to do. Instead of finding a location once, it will keep watching the user’s location and call the success function whenever the location changes. The thing that watchPosition() is most useful for though, is getting more accurate locations as the user’s device tries different location finding techniques.

You see, different devices will try and locate themselves in different ways. Some of the techniques they’ll use will be be quick, some slow, and some very expensive when it comes to battery life. For example, here’s what the iPhone does, as I understand it:

1. First, the iPhone will look to see if there’s a location cached in its memory and give you that if available.

2. If you’re still watching for new locations, it will then try and grab a general location from the cell towers it knows about.

   Depending on the number of towers available, this might give you really good, or really bad accuracy. For example, in Bedford (where I live), using cell tower triangulation I get an accuracy which basically covers the entire town. Not particularly useful. It is quick though, and doesn’t really cost much in terms of power.

3. If the cell tower triangulation wasn’t awesome then the iPhone will gather information about all the WIFI hotspots it can see.

   This data gets sent to Skyhook, which does a whole bunch of triangulation and sends back a result. This is obviously slower than just hitting the cell towers, but it can give you a really accurate result depending on where you are (better than GPS in some built up areas).

4. Finally, if you’re still looking for a location, the iPhone will fire up the GPS.

   This is expensive, slow, and drains the battery, so is left as a last resort. It generally gives the best quality results though.

So, you see, things aren’t necessarily as simple as asking for a position. A whole bunch of stuff can be going on in the background, and grabbing the best location the user’s device knows about as time goes on can be very useful.

Using the location we’ve found

So, now that we’re requesting a location, what do we do once we actually get one? Lets have a look.

foundLocation = function(position) {
    // position.coords.latitude
    // position.coords.longitude
    // position.coords.accuracy
    // and more…
}

As you can see, the function we call on location finding success gets passed a single parameter – position. This object contains a coords object, and a timestamp representing the time the location was determined. It’s the coords object we’re interested in right now, since that contains the latitude, longitude and accuracy (measured in metres) of the user’s current location – all the information a grown chap could need for finding some beer. Other applications might make use of the altitude, heading and speed information, but that’s not vital when looking for beer, so I’m ignoring it for now.

Putting it all together

Quickly putting all this together, here’s some JavaScript you can copy and paste into a page to see this all in action.

/*global document, navigator */
var beerLocation = {
    foundLocation: function (position) {
        beerLocation.setPara(
            "Lat = " + position.coords.latitude + 
            ", lon = " + position.coords.longitude + 
            ", accuracy = " + position.coords.accuracy + "m");
    },

    noLocation: function () {
        beerLocation.setPara("Boo! You didn't share your location!");
    },

    noGeoLocation: function () {
        beerLocation.setPara(
            "Sorry, but your browser doesn't support geolocation.");
    },

    setPara: function (text) {
        var p = document.getElementById('location-info');
        if (!p) {
            p = document.createElement('p');
            p.id = 'location-info';
            document.body.appendChild(p);
        }

        p.innerHTML = text;
    }
};

if (navigator.geolocation) {
    navigator.geolocation.watchPosition(
        beerLocation.foundLocation, 
        beerLocation.noLocation,
        {
            enableHighAccuracy: true,
            maximumAge: 120000
        }
    );
} else {
    beerLocation.noGeoLocation();
}

Alternatively, take a look at it in situ and in action on my geolocation test page. The location shown by this page will keep updating as you move around or your device’s accuracy improves. For best results, try it out on an iPhone.

And finally

And that’s how easy it is to find a user’s location and keep updating it. You just need to do something with the latitude and longitude once you’ve found it.

In Beer Near Me I do two things with the location once it’s been found – I tell the user the street address of the location, and I display it on a map. And, of course, I’ll be writing about how I’m doing that in the next couple of posts.

I didn’t go to last year’s Social Media Camp. I only heard about it a couple of days before it was due to happen, and frankly at the time I was dissuaded from going by the general murmurment of my peers that anything to do with social media would be “gash”. That said, the blog posts that I read afterwards sounded like the talks and presentations that happened would have been very relevant to my interests, so I made a promise to myself that I would do my very best to go next time.

So I went.

Now, Social Media Camp London ’09 was only the second *Camp that I’ve been to that was focussed around a niche subject (the first was GameCamp – I hope there’s another one of those this year). One of the things that I loved about SMC was that there were very few people there whom I already knew. I like to try and talk to new people at these events, which can be a bit of a problem when everyone already knows each other. No such problem here!

The talks themselves were universally great, with each one offering their own insight into an area that the speaker felt strongly about. I must admit, I felt really quite bad about my “How to make awesome broken biscuit cake” presentation — whilst the cake was well received, I didn’t think the presentation fit that well into the topic at hand. If I’d made more of the “if you offer people something, they will come” angle, then I’d have been happier with things — as it was, the presentation felt like it would have been more at home at a standard BarCamp.

But enough with the self-flaggelation…

There were two things which stuck out at Social Media Camp as “not good” things — the number of no-shows and the number of empty slots on the grid.

As Vero pointed out in her post, there were a lot of no-shows. She did the sensible (but scary) thing of overbooking the event, but there were still a good few spaces available on the day. No-shows are something that happen at every *Camp, and it’s been talked about many times before. People not showing up means that other people that would have liked to have come couldn’t, which is no fun for anyone. That said, I personally liked the numbers at this event — it didn’t feel overly crowded, but likewise it didn’t feel too small.

One of the important things to note about Social Media Camp was the number of people there who’d never been to a *Camp event before. From experience, I know that they can be a nerve-wracking experience the first time. “Will people like what I have to talk about? Will I get jeered off-stage? Will everyone already know what I have to say?” I signed up for the first two London-based BarCamps, got a ticket, and then handed it back a few days before the events for those very reasons. It was scary. I finally made it to BarCampLondon3 though, presented, and loved it. I’ve now been to pretty much every BarCamp I’ve been able to get to, presenting at each one. That first hurdle is a difficult one to get over, but once you’re over it you feel great.

So, with all the newcomers to *Camps at Social Media Camp it was unsurprising that there would be a few people who felt unconfident to present. That’s okay, but there are some extra things that could have been done to help combat this (Kat has written a post about this already, and the excellent comments are well worth reading through).

The first thing that could be done (which Vero says happened more for the first Social Media Camp than this one), is to educate about the presentations before the Camp itself. By making a firm but friendly assertion that everyone should present, that if no-one presents there will be no *Camp, and by giving examples of a range of different presentations that people have made in the past the whole thing can be made a lot less scary.

The other simple thing to do is to provide a slot for lightning talks (5 minute talks, rather than the normal half-hour slot), and let people know about it before the event. This then gives newcomers who are less confident about their presentations an easy way to contribute something small and less scary than a full half-hour’s amount of material. At most of the BarCamps I’ve been to recently, someone has taken it upon themselves to take over one of the rooms for a session or two to run lightning talks. Unfortunately, I only remembered about this towards the end of the event this time, when it was far too late to do anything about it.

One other possible way to combat non-presenters that’s been mooted is to have a special room that’s just for newcomers to give them a “safe area”. My only worry with this suggestion is that it could lead to a feeling of segregation and that newcomers have to present there, rather than it being a place they can present if they want to.

Overall, Social Media Camp London ’09 was a great event. I’ll definitely be back next time. I met a whole bunch of great new people who I just wouldn’t have met otherwise, and I came away feeling re-invigorated. Roll on the next one.

Which reminds me — I haven’t actually answered the question in the title of this post — why did I go?

It was pointed out to me a couple of times during the day that I am primarily a developer. In my day job I don’t try and build communities, and I don’t interact with users. At home though, I very much do (or at least I should). I run The Ten Word Review, a site where you can review anything you want as long as you do it in exactly ten words. Usage of the site has primarily grown organically, and I’m obviously interested in looking after the community that’s grown around the site. So that’s why I came, and I’m glad I did.

Some of you might know Broken Biscuit Cake by its alternative name, Fridge Cake (or by its posh name, Tiffin), but whatever you call it you quite probably made it way back when you were at school. That’s when I first came across it, and it soon became a favourite to make when we had a few biscuits left over in the biscuit tin that didn’t seem to be getting eaten.

After my presentation yesterday, lots of people asked me how I made the cake, and whilst there’s a photo set on flickr with the instructions, I thought it would be nice to condense them all down into a little broken biscuit cake recipe here as well. So, here goes.

To make Broken Biscuit Cake, you’ll need the following (but don’t forget to hack it to make it nommy to your own tastes):

1. 250g biscuits. I like chocolate covered ones, but you can use anything. It’s good to have a mix of types and textures.
2. 300g milk chocolate.
3. 150g dark chocolate.
4. 100g unsalted butter.
5. 150g golden syrup.
6. 75g raisins.

And that’s all you need. Making the cake is as simple as combining the ingredients together like this (and it only takes about 20 minutes all told):

1. Put the biscuits in the sandwich bag, seal, and hit with a rolling pin until broken. It’s important to scream whilst you do this.

   Make sure the pieces are broken up nicely — you’ll want lots of crumbs and a few pieces about half the size of your finger nail. The crumbs are important to make sure that everything binds together later, and the larger pieces give you a little bit of extra texture in the finished cake.

   I find it’s a good idea to hit the bag on one side for a bit, then turn it over and try the other side too.

2. Break up 150g of the milk chocolate and all of the dark chocolate and place it into a mixing bowl. Chop the butter into pieces and add that to the bowl too. Finally, take the golden syrup (it’s about a third of a tin) and add that to the bowl too.

   Run the spoon you use to add the golden syrup under a hot tap first to heat it up and make the golden syrup slide right off it.

3. Whack the mixing bowl into your microwave on high for a minute or two. When it comes out the chocolate and butter will have started to melt and the golden syrup will have degenerated into a thin liquid. It won’t look particularly pleasant. That’s okay though.

4. Use a spoon to mix the chocolatey, buttery, syrupy mixture together. Just keep stirring it for a couple of minutes.

   Don’t stop once everything’s combined into a simple liquid though. If the mixture looks liquidy then you need to keep stirring. Once the mixture begins to come together and take on the consistency of a sloppy warm fudge then you’re done.

5. Pour the broken biscuit bits into the mix, along with the raisins. Mix everything together until you get a nice gooey chocolatey mess.

6. Grab a baking tray and cover it in clingfilm.

   Make sure you get the clingfilm as smooth as possible. If it’s a bit kinky then it’ll get trapped inside the cake and you’ll have difficulty getting it out when you come to take it out of the fridge later.

7. Place the cake mix into the baking tray.

   My advice here is to not dump it all into the tray in one go. Instead, try putting a few blobs of the mixture around the tray. The less you have to move around when you press it down in a minute, the less the clingfilm will get kinked up.

8. Once the cake mix is all in the baking tray, press it down with the back of the spoon. Make sure the cake is nice and compacted, and that it properly fills the tray.

9. Put the cake in the fridge. It would probably be sensible to cover it so that nothing else contaminates it.

10. Break up the remaining 150g of milk chocolate into a bowl, and melt it in the microwave as before.

11. Remove the cake from the fridge and pour your melted chocolate on top. Smooth it over the top to cover everything. You wouldn’t want to upset someone by giving them a slice that wasn’t covered in chocolate, would you?

12. Put the cake back in the fridge and walk away.

13. Let a couple of hours pass.

14. Turn out the cake. The clingfilm will be stuck to the bottom, so pull it off, making sure none is left behind.

    My technique for removing the clingfilm is to pull it vertically, rather than horizontally. I find this helps to stop it from tearing and leaving bits behind.

15. Cut the cake into little pieces. I find that each cake makes about 30-40 pieces, and that due to its density, a bit heavy knife is preferable for cutting it.

16. Put all the slices into a nice tub, and put that back in your fridge for nomming at your leisure. Reward yourself with a slice now.

    Due to the nature of this cake, I advise keeping it in the fridge. Chocolate, golden syrup and butter melt at low temperatures, and the cake gets pretty sticky if you leave it out in a warm place.

And that’s that — it’s all pretty easy really, and really tasty too. The scary part though, and probably something that everyone at Social Media Camp won’t want to hear is the number of calories this cake contains. An entire cake contains roughly 5800 calories, making each slice 145 calories of awesome chocolatey goodness.

Om nom nom.

As with all the London-based BarCamps that have occurred so far, this one was heavily oversubscribed. When signup opened, tickets vanished in the blink of an eye and plenty of people were upset that they hadn’t managed to get a place. Eagerness to be involved was so high that the first ever BarCamp London Spillover was organised as a one day event to let some of the people who had wanted to be there have their own mini event.

Then the day of BarCamp London 5 came, and a lot of people who had managed to get tickets didn’t bother showing up. Anecdotally, between 40 and 75 people just didn’t come. If those people had handed back their tickets prior to the event that could have let a lot of the people who went to Spillover come to the main event. Not turning up is just not cricket. Part of the fun of a BarCamp is the diverse number of people who attend and contribute to the event. Not turning up just dilutes that horribly.

I’m not the only person who feels this way. In fact, chatting to people over the weekend it was a common theme. Various people were mentioned who have done this on more than one occasion, and the general feeling seemed to be that something should be done about this trend before it continues. Maybe that would involve naming and shaming. Maybe a blacklist to stop no-showers from signing up during the first couple of rounds of tickets for the next BarCamp? Maybe charging a nominal fee to attend, like BathCamp did, would be a way to make sure people turned up? I don’t know what the answer is, but I really don’t want this trend to continue.

What I do need to applaud the organisers of BarCamp London 5 for though was the large number of newbie tickets. New people and diversity are the lifeblood of BarCamps, so it was fantastic seeing them going the extra mile to bring new people in. Likewise, the sponsors were great and a special “shout out” has to go to MyMuesli who provided some awesome custom muesli for breakfast on the Sunday morning which seemed to go down incredibly well.

I had a great time at BarCamp London 5, and I look forward to the next one. The only thing that could make it better would be if everyone turned up next time!

So, what changed?

Firstly, moo has an API now. Previously if I’d automated the image creation process for the Ten Word Moo Cards that’s all I would have been able to do, and then I would have had to upload them all myself. So, having an API allows me to press a button in one place and magically have a set of cards created for me. Awesome.

Secondly, in his talk, Stefan mentioned that the revenue sharing for cards, stickers etc that people bought would be set at 15%. Now that’s pretty damn high. Not only that, but it will be applied retroactively, since they’ve not actually got the payment stuff working yet.

The final thing that’s pushed me into finally making the cards is that there’s a prize for the best hack on the Moo API that came out of the BarCamp – a little handheld camcordery device. Obviously, I’d quite like to win that.

So, I made a “Ten Word Moo Card Creator”. It takes the best rated reviews from The Ten Word Review (where you can review anything you like as long as you do it in exactly ten words) and creates moo cards from them. If you want to create cards purely based on the reviews that you have written, you type your username into the textbox below. That’s it, simple really.

There are, of course, a couple of caveats. The first is that it might take a little while getting to Moo’s website after pressing that button. That’s because up to 30 images are being created, and each one needs to determine the optimal font-size for the review it contains. We’re not talking hours here, but it might take a few seconds.

The second caveat is that I haven’t set any default text for the back of the cards or set a default crop. The reason for this that if you set a crop then Moo steps straight over the cropping step of its wizard, which unfortunately is also the place where you choose whether you’d like to discard any of the images that you’ve chosen. Likewise, if I set some default text on the back of the card, then Moo seems to take this as a directive that the user wouldn’t want to edit that themselves and puts the cards straight into the user’s basket. In this instance the user hasn’t even been able to see what the cards look like on Moo’s site before they arrive in their basket.

Of course, if I’m wrong about these caveats, and I can add default text to the cards whilst still allowing the user to enter the flow on Moo’s website at the image cropper stage, that would be fantastic.

Overall, the Moo API is pretty easy to use. There are rough edges, but it isn’t a finished thing, and it’s not at a 1.0 release yet, so it’s utterly forgivable (as long as developer comments are taken onboard, and I’m convinced that they will be). Hack around at it like I did, and see what you can make.

Hmmm, I just remembered that I while back I wrote a Moo Sticker Speech Bubble Generator. I should really hook that into the API too, shouldn’t I? One day. One day…

These are the slides I put together for my talk:

If you just want to download the Code, go right ahead. If you want to know more about the project, read the WikiSlurp Project page.