BarCampLondon3 - Day 1

The time for another BarCampLondon3 has rolled around, and I was lucky enough to get a ticket. We all turned up at Google's swanky offices in Victoria knowing we would have a good time, but not quite realising what a great time we were in for.

The organisation went very smoothly, the wifi was rock solid, there was more food, beer and snacks than even a BarCamp-load of geeks could consume (well, apart from the beer - it's the first time Google's fridges have been emptied, oops!)

As usual with an unconference, it was all about the sessions folks decided to give, and we were treated to some really thought-provoking and fun discussions. It was a shame that out of the 100 attendees, about 30 chose not to present. So the schedule was a little light at times, but that's not always a bad thing - nice to catch your breath every now and then! Jeremy marked up the timetable for us all to refer to easily.

The first session I went to was Tom Morris - Scraping Sucks - where he was giving us more usable alternatives to scraping HTML, namely doing clever stuff with GRDDL. He says it's much easier that way. As usual, I nodded sagely at the time, and then a couple of hours later, wondered what it was all about. Tom is a great geek, but he's several steps ahead of me when it comes to brain-wracking abilities :-) He's put up a page of GRDDL Profiles here - which lets you look at (X)HTML and with an XSLT transform, spits out XML/RDF which can be used as you want.
[Tom gets stuck in to his presentation]

Norm's Law
This was an excellent presentation from Mark Norman Francis. He gave us some very good reasons for doing code his way - especially for fostering interoperability betweeen different members of the team, or yourself coming back to code at a later date. Some points included:

• Use spaces not tabs
• Code goes no further than col 77
• No-one ever died from using too much whitespace
• Separate operators and braces - more of a cognitive burden to parse squashed up code
• Always indent by 4 spaces ONLY
• Line up assignments of variables (equals sign in the same place etc)
• Line up data tables too (arrays or whatever)
• Space keys out from brackets $vote[ $value }++; etc
• Space keywords out not functions
• Vertical rhythm - break bits up with comments for each sub part - make a story out of it
• Respect left-to-right comprehension
• K&R bracketing - opening brace should be tied to RHS end of line, closing brace should be on a new line - aligned with the starting coment
• Don't cuddle and else!
• One statement per line - you can easily miss the ";" in the middle of the line separating the two commands
• Break lines before operators - EXCEPT in JavaScript or it won't work
• Ignore operator precidence - use brackets to make it more "English readable"
• Use single quotes where possible - ' in PHP will just be stuffed in, " will make PHP parse the contents looking for variables
• Factor out long expressions and use intermediate variables (with english-sensible names) to break up
• Always use x on regexpressions
• Don't use camelCase! unless you're in JavaScript
• Systems Hungarian is harmful, Apps Hungarian is too
• All short variable names are harmful
• Use grammatical variable names and function calls
• Optimise for humans first! Machines - throw more hardware at it - but you can't refactor comprehension
• HTML indents use 2 spaces not 4
• Write the whole document FIRST before you do any CSS etc
• Insert Microformat classes
• Always use single quotes in attributes
• Inline CSS means you've done it wrong
• If it only works in JS don't
• VALIDATE
• Start with base stylesheets - reset, fonts, layout
• Use Uppercase tags in HTML
• Keep z-index below 50

[Norm - I can haz 4 skreenz]

Next up was a session about new developments from the BBC's web team:

BBC APIs First Look
PIPs is the system to list all broadcasted stuff - telly and radio

• bbc.co.uk/programmes
• Gives a list of all current programmes - by genre or alphabetically
• Nice URLs which can have .yaml or .json can be added for the feed in that format
• bbc.co.uk/programmes/formats
• Pid is the 8-character id for each episode - taken from user experience tests and will always be constant (never change)
• JSON and YAML are the two formats currently supported - XML coming? - RDF ontology has been produced
• RSS feed is coming so you could subscribe to know when "every episode of Doctor Who" is on
• Data model - "programme" can be brand, series or episode - an episode can have multiple versions (signed, extended etc) which then have broadcast (tv) or ondemand (iPlayer) times
• Historical data back to May 2006
• Can filter out to network (tv or radio) eg Radio4
• Next release (API stuff) in New Year
• http://catalogue.bbc.co.uk/ - is historical data - grand plan is to have them merged

DIY User Research - Leisa Reichelt
Leisa gave us lots of good advice on how to carry out some DIY user research - her premise being that it doesn't have to take days and days and cost big bucks - and often talking to more than half a dozen victims volunteers gives you diminishing returns. Leisa's slides are already available at the Slideshare BarCampLondon3 group.

Building Lifestream with Yahoo! Pipes - Cristiano Betta
I didn't take many notes as I was listening as I was actually playing with a real Yahoo pipe of my own and trying to follow along with what Cristiano had to say. I've been meaning to use Pipes to create my own Lifestream for some time, but had a quick go before and things weren't coming out as I wanted. Cristiano has done a series of excellent blog posts to get you going, or you can watch Tom Morris' video of Cristiano's presentation. Or view Cristiano's own Lifestream.

10 Things You Should Do In Project Management But Probably Don't - Gareth Rushgrove
Gareth's top ten tips:

1. Use Source Control software
2. Validate markup - XML, RSS, Atom and JSON
3. CSS validation
4. Broken Links! check them thoroughly - W3C Link checker
5. Performance - do you have metrics for measuring the performance - YSlow is a Firebug enhancement, httperf - use uptime checker too such as Pingdom
6. Maintainable Javascript - JSLint gives you good tips
7. Carry out Unit Testing
8. Carry out Functional tests
9. Asset Compilation
10. Building Scripts
    

More at morethanseven.net

Learning jQuery - Simon Willison
Simon gave us a lightining half hour tour of the jQuery Javascript library with great examples and succinct slides - you can get them from Slideshare. I've been meaning to beef up my JavaScript skills, and getting to grips with jQuery sounds like a good place to start.

[Simon talks about jQuery's Ajax capabilities]

Ask Them Anything
For the final sessions of day one, Norm and friends held an Ask Us Anything panel - just a bit of silliness to round off the proceedings before dinner. The guys from the Londonbubble did a live stream of the session to their mogulus chatroom, and it all got a bit recursive when this was put up on the main screen behind the guys:

[Behind you!]

The chatroom folks even got to ask a question or two - and Ross got a marriage proposal from a lady named Picki which he had to graciously decline!

[Ross, Norm and Ryan answer the online questions]

And so to dinner... but that's for another post.

BarCamp Day 1 - Afternoon Sessions

Tom Scott on Open Source Incremental Backups For Windows
Tom's presentation was useful for those who want to manage incremental backups for Windows in a sensible way. His full presentation is available here: http://www.thomasscott.net/barcamp2/

I backup my system less often than I probably should (photographs aside, which get saved in at least 3 places regularly - I'm paranoid!). So perhaps I should take the time to have a go at this myself.

Meri Williams on Project Management For Busy Geeks
Meri's talk started with the Basic lifecycle of a project. Few projects go through the whole lifecycle properly. The Big Secret is that, for smaller projects, PM is all about Initiating, Planning & Closing (and not worrying too much about execution and control). Planning should NOT be about planning a step by step guide - but something that helps you understand what you're doing. And communicating this to stakeholders. She also mentioned that lots of projects are not closed properly - haven't we all been plagued by customers that just won't go away but pester by saying "can you just do this bit extra?".

[Meri's running order]

Leisa Reichelt on Design Consequences
Leisa's was a hands-on session where she demonstrated her techniques for initial brainstorming of site layouts and designs. We all had to break out the pen and paper (and post-its!), and "mock up" a screen to show the BarCamp Schedule (the real thing was done the low-tech way as you can see):

[Day 1 Schedule - done the low-tech way - but it works very well]

Then we talked about what we'd done and why. It was nice to get away from the computers for a bit, and everyone had fun explaining how they had implemented their solution to their neighbour.

[Andy and Nat listen intently to one BarCamper's version of the schedule solution]

Robert Lee-Cann on Over-Engineering Is Fun!
Leeky's presentation was a light-hearted and thoroughly enjoyable look at solutions to problems which have been hugely over-engineered, and he wondered if this was a typical trait of geeks in general?

[right, Leeky having a geeky- brained moment]

Problem: Is the coffee machine full?
Easy Solution: get off your butt and go and look
Geek Solution: we all know where a bit of over-thinking can get us: webcam trained on the coffee maker

[below: The man needs coffee!]

Problem: Who's going to make the tea round?
Easy Solution: Press-gang someone into doing it
Geek Solution: Web-based ordering of drinks, LED display in the kitchen showing the round required, online voting afterwards to see how well it was made!

Confessions:
Having described the above solution which is in use at his work (!), he asked us all if we would like to confess our most ludicrous over-engineered solutions. Some of the best were as follows:

• Meri - private IRC channel to decide the flavour of your pizza before ordering it - used by people living in the same house
• John - set up a telly, Freeview box and video transmitter in one room and a reciever in the other room - when they could have run a cable through the wall!
• Brave Geek: had written 112K JavaScript file to write a whole web page on the fly, built in the days of Netscape 3 and IE3! He got a round of applause for that one!

Pitch An Idea
The final part was for the audience to come up with a solution to the perennial problem of putting the loo seat up or down in the bathroom. Many outrageous examples were put forward, which ranged from having a finger-print recognition pad on the loo door, so the loo "knew" who was about to sit down, to weight/position sensitive pads just in front of the loo, so it knew if gents were standing or sitting down! All great fun.

Andy Budd on The User Experience
Andy started by talking about the early desktop interface, when abstracting the interface made it easier for "non-tech" users. At the time, it was revolutionary. Similarly, Joe Bloggs doesn't want to learn Unix to use their iPods. People DON'T read the manual. No wonder we say RTFM so often.

We learn by experience - programming DVD recorder is very similar to programming the video. So the building blocks are there and users learn the metaphores. It makes it important not to break common interaction habits.

Users learn new technology by exploring - you switch it on and start clicking buttons to see what happens! So make buttons look like buttons. And make sure it's not fragile so that inexperienced users can't break the system with one click.

Modern life constantly demands our attention. How easy is it to send a text while crossing the road? Rarely do people give your application 100% of their attention. Design it to make things easy, as people are adept at multitasking.

Make error reports blindingly obvious. It's a great place to make the user experience a good one - as soon as something breaks, you want immediate service or fix, or at very least, a human-readable error message. Don't make users feel stupid when they do something wrong.

[I'm no dunce]

Usability is all about making technology easier to use. Plan user experiences carefully. Create wireframe storyboards - think how filming is never done without paper mockups. Then test it on REAL users. Can be as simple as chatting to coffee shop customers - feed them donuts and buy them a coffee and get their feedback on your site - one day user testing, low budget - anything is better than nothing.

UCD is sometimes confused with Business Centred Design or Marketing Centred Design. You should not have to deal with politics. But we all know how hard that can be. Designing with a focus on business unit function is also horribly bad. Technology Centred Design - designing around our own technical ability - we do it that way because we can - is also a no-no.

Get out and talk to the users - find out what they're trying to do with your site. Users don't just want to know what the weather is going to do for the sake of interest, they are more likely to need to know if whether to take an umbrella with them today!

Build up Personas for each broad type of user. Design with these in mind. Very easy isn't always best - maintain a balance. Sites or games companies know about flow - you lose time when you are interested in something.

Starbucks are masters of the "coffee experience" - which is why we are willing to shell out 3 quid for a cup coffee!

Lastly, he made the point that the iPod would probably fail user testing. People buy into the brand. You might struggle through learning the interface, but you're willing to learn it because your friends tell you it's a cool gagdet. So for the right brand, people are willing to take the time to learn new ways of working.