This year’s dConstruct was a lot larger than I was expecting: the last time I went in 2006 there was a comfortable number of folks there, and it felt really friendly. I didn’t go in 2007 as it clashed with the Rugby World Cup opening game in Paris. But this year there were about 500 attendees who gathered at the Dome in Brighton for the event. I found it a little difficult to find people, even though I knew they were there, as there were so many folks milling about during the breaks.

Here are a few photos I took during the event:

[Above] Aleks Krotoski on Playing the Web: how gaming makes the internet (and the world) a better place. Listen to the audio (mp3).

[Left] Joshua Porter talks about Leveraging Cognitive Bias in Social Design. Listen to the audio (mp3).

Daniel Burka [below] talked about Designing For Interaction. Listen to the audio (mp3).

Next up was Tantek Çelik, talking at length about Social Network Portability and how Microformats can help you to take your friends with you to a new network. Listen to the audio (mp3).

The two Matts, Biddulph and Jones, [below] did a two-handed presentation called Designing For The Coral Reef. They talked about “delighters” – little things which are present in design which can really make the difference to the user experience. Listen to the audio (mp3).

Clearlefter Jeremy Keith wrapped up the event with a thought-provoking session entitled The System Of The World. There doesn’t seem to be an adio transcript of that available.

So, there’s been some weighing up of pro’s and con’s, and I’ve just booked the rugby trip! I figured that, even though I had a great time at last year’s d.Construct, since it’s an annual event, there’s always 2008 – whereas World Cups only come round once every four years – and the next one is in New Zealand – hardly a convenient hop across the channel!

The worse-case scenario would have been me prevaricating for so long that tickets to both events had sold out. So I thought it best to jump now and forever hold my peace

But first, I’d like to say what a great time I had at the conference. Some really informed and informative speakers; nice venue (apart from the pokey seats) and plenty of subjects to get the braincells working. And of courese, plently of opportunity to meet like-minded geeks for beer, chat and crazy golf!

Here’s some of my pictures taken around the after-party.

[Sunset over the wreckage of the West Pier]

[Bright On Neon. OK, bad pun]

[Ross and his Paps on the crazy golf circuit]

[Who ate all the pies? A conference-goer wishes to remain anonymous]

You can see all my d.Construct/Brighton images at Flickr.

I met some great people, amongst whom were:

• Ian Forrester
• Jeffrey Veen
• Jeremy Keith
• Olly Hodgson
• Robert Lee-Cann
• Ross Bruniges
• Sheila Farrell

The other great thing about the conference was the excellent backnetwork site – no problems if you forgot to get someone’s card; just look them up later, or read their aggregated blog posts and view their Flickr pictures, all in one place. Every con’ should have one!

Lastly, here’s a cheeky little desktop which I spotted during the first session of the day – great to stop the Over The Shoulder Snoopers?

[Stop Looking At My Screen!]

[Jeffrey Veen gets excited talking about his old job at wired.com]

Jeff Veen’s presentation where to start? He’s a very charismatic and engaging speaker, and this was no exception. You can download his presentation slides from his website. But here are a few bulletpoints.

Three criteria you should think about before producing a site:

• Viability – business case and reasons for building a site
• Feasability – can it be done?
• Desirability – do people want it?

[The best products are the most desirable]

Your site’s architecture and structure should always be extensible. Even if you start small, plan for expansion! Otherwise…

[What could happen to Amazon by the year 2050...]

Design faces global challenges, but even at a local level, terminology can vary widly. In the US, a survey was conducted to see what people asked for when ordering a fizzy drink. The results were pretty mind-boggling!

[I'd like a can of coke/soda/pop/other (delete as appropriate)]

Terminology can be important when labelling application functions. What happens when internal jargon creeps in – or is it megalomania taking over?

[Create New Country?!?!!]

Understanding Your Visitors is a crucial step in putting together a useful, usable website. Using simple stickie notes to group together functions vs what users are trying to achieve (card sorting) can show up gaps in both directions:

[Mind The Gap mapping]

Top half maps user tasks and bottom half maps website features – the trick is not to have gaps either way. No point wasting resources engineering something that nobody wants, but completely ignoring a facet of the site that is not currently available but users are crying out for.

Finally, Jeff pointed out that it’s much more expensive to change your mind (add new features) the closer you get to launch. Proper user research means you are not wasting time, money and resources by going up the wrong garden path.

• Folksonomy is the result of personal, free tagging of pages and objects for one’s own retrieval.
• Tagging is done in a social environment (it’s shared and open to others)
• The act of tagging is done by the person consuming the information

These tags are important because people will use their own vocabulary to tag, which is meaningful to them. Tags can add perspective or context, and can make up for missing meta data.

The interesting things happen when you see tags in relation to the

Dual Folksonomy Triad:

[Thomas explained The Dual Folksonomy Triad]

People tag something within their own sphere of interest, but can then use that tag (in the form of a tag cloud search) to pivot and find material which other people have tagged in a similar fashion. Bonds and communities can form around these social groupings. Try following a tag trail in Flickr – you might be surprised where you end up!

There is always a tension between Consumer/Folksonomy vs Businees/Taxonomy. A business might wish to call their latest widget by the model name, MyFantasticWidget. But real consumers out there often refer to it quite differently, with emergent vocabulary. They might want to call it “DeadCoolWidget” instead. Business ignore such folksonomy at their peril.

I hope Thomas will post his slides to his blog in due course.

[Derek waves his arms and steadfastly refeses to use the phrase "web 2.0"!]

Derek is an accessibility expert who is trying to get the message across that, even in a web2.0 world, accessibility should still be a goal, and and achievable one.

The web now is moving towards functionality and applications, and away from the document-centric approach. To make apps accessible, it is vital to separate the app into three distinct areas:

• Content (eg semantic, standards-compliant XHTML)
• Presentation (CSS does all the hard work)
• Behaviour (javascript, AJAX or other behavioural language)

All too often, 1 and 2 are adhered to, but 3 still remains buried in the page, and therefore accessibility issues begin to kick in. What happens when someone doesn’t have JavaScript enabled? Can they still see the content, etc.

One common example Derek mentioned was the default text you often find in a search box, which some JavaScript removes when the element gets focus. What happens if you’re a blind user who fills in the box, tabs to the next form element, decides to tab back to the first, and can’t understand why the text they thought they’d typed had disappeared!

Fix senarios – either make the JavaScript check, and ONLY removed the default text, but retain the user-input text. Or, perhaps don’t use default text at all, but instead use a Tool Tip on the form element to give some more information.

Similarly, validation error messages should always appear near the form control they validate. If you put it at the top of a page, and a user has the screen hugely magnified, they will never see the error text as it’s well out of their portion of the viewport. Perhaps changing the background colour of an element which fails validation could also be useful.

So if it’s easy to get such simple things wrong, what about applications using AJAX which can be very complex? The answer is, wherever possible, to try and make the content linearised within the page by setting tab orders etc to “lead” users through their application journey in a sensible way.

Tabindex=”-1″ might sound like an invalid value, but it is supported by IE and Firefox. It can be programmatically, as it does not show up in a tab set, but you can use it to force focus onto an element.

Drag and Drop interactions are great for the mouse-enabled community, but pretty hopeless for those only using a keyboard. So don’t make it the ONLY way of doing something. Also, make the “hit area” of links or things to drag as large as possible, so that users with impaired mobility don’t have to be so accurate with their mouse movements.

Poor old Aral drew the short straw and was in the “graveyard shift” straight after lunch. I think he got us all on his side straight away by holding his hands up and coming clean:

["Don't shoot me, I'm a Flash developer!"]

Now I must confess that I’m no Flash guru. I have built one site with Flash5 (it was a long time ago!) and did a minimal amount of ActionScripting for that, but Aral’s knowledge and experience was way beyond mine! So I didn’t take too many notes, I just tried to watch and keep up

• He gave a quick overview of Flex 2
• Lets you declaratively design iterfaces by using MXML
• MXML is XML
• Scripting uses ActionScript3 (which is ECMAScript4)
• Looks like Java, smells like Ruby
• AS3 is optionally typed, and a dynamic language
• Compile MXML and AS3 to SWF bitecode
• Each MXML tag represents an AS3 class
• SWF bytecode executes in the Flash Player which is a virtual machine
• Flex2 SDK is cross-platform and free
• FlexBuilder2 is a visaul IDE based on Eclipse, costing ~£370
• There’s Flex Data Services and Server
• RPC and real-time communication, video and audio streaming
• There are also open source alternatives like Red5, AMFPHP and openAMF

Styling is applied with CSS. Data can be consumed via the following formats:

• REST (see previous blog post)
• XML-RPC
• SOAP
• JSON
• Flash Remoting (= binary JSON)

For more information, see Aral’s website and download his presentation.

Jeremy was very enthusiastic about the fun he’s had meddling with APIs. He started off by explaining little about REST. I thought, “oh, no, something else I don’t know about” but it turns out that REST is pretty much what the “normal” web is all about:

REpresentational State Transfer

• The application state and functionality is devided into resources
• Every resource is uniquely addressable. With HTTP, this is done via a URL.
• It’s a stateless client/server protocol: in HTTP, each message contains all the information necessary to understand the request when combined with the state at the resource.

Huh? Well, that more or less describes bog-standard web stuff: links, images, pages etc.

Then there’s SOAP, Simple Object Access Protocol

Jeremy compared the APIs for four major sites which he has experimented with, and rated them for power, documentation (help) and his measure, “joy” of use. The results were as follows:

• Flickr: power=9; docs=8; “joy”=9
• Amazon: power=8; docs=8; “joy”=8
• Delicious: power=6; docs=6; “joy”=6
• Upcoming: power=6; docs=6; “joy”=6

Maps often seem to be the most popular API for experiementation. Mashing mapping with other data feeds gives excellent geo-tagged information. What happens if you drop a 100KT bomb on the Corn Exchange, Brighton? Enquiring minds want to know…

[Mashed - that's what most of Brighton would be if you dropped a 100KT bomb on the Corn Exchange]

The oft-cited Chicagocrime.org site, a prime example of mapping + other stats, was actually written before the GoogleMaps API was released! Sounds like hard work. Other geo-tagged fun sites included:

Overheard in New York + Google Maps = Overplot

[take care on 52nd and Lexington - watch out for the cannibal vegan!]

Gawker + Google Maps = GawkerStalker

[where are all the celebs to be found in NY?]

And finally, the most important point is that your mashups are only ever as good as your data. What happens if you look up Brighton with Yahoo maps instead of Google…

[oops! what happened to Brighton?]

Jeremy pointed us to some useful resources for getting started with APIs:

• Programmable web tells you what’s out there to be mashed
• dapper lets you create a service from any website – DIY API?
• microformats and all that they can achieve for you
• mapstraction provides a common API for Google, Yahoo and Microsoft mapping

References from Jeremy’s slides are available on his website.

Paul and Simon gave us a quick overview of the APIs and offerings available from Yahoo.

[Paul and Simon, a Hacking Double Act]

There were many examples of mashups given, some of which included:

Flickr + Yahoo Maps = geotagged photos

One of the most interesting aspects was Yahoo’s Hack Day (Mash Up Or Shut Up), which is held about once a month. Dreamers, coders and hackers from all sorts of disciplines get together to prototype possible new products. There are only two rules, apparently:

1. Build a prototype in a day
2. Demonstrate to your colleagues

Basically, for internal and external projects, web services and APIs allow us to build new products faster, and helps innovation. Some products demo’d at a hack day have been in user testing in under a week! This just wouldn’t be possible without published APIs.

The Yahoo Developer Network has loads of information for people wishing to utilise the APIs for:

• Search
• Spelling suggestions
• Term extraction (generating tags from parsed text)
• Output formats such as XML, serialised PHP, JSON
• Flickr
• Maps

etc.

Letting your API out into the wild can lead to some very surprising results! How about fully-draggable Pirate map, courtesy of Justin Everett-Church.

[ Yarr! ]

Or perhaps you need to find a picture from Flickr which matches your sketch – you need Retrievr

[Pimp up my sketch]

All the presentation slides are available at Paul Hammond’s website.

Jeff’s presentation went into some depth about the range of web services available from Amazon. There’s an enormous range, mainly concerned with:

• E-Commerce (Amazon E-Commerce; Historical Pricing)
• Infrastructure (Simple Queue Service (SQS); Simple Storage Service (S3); Elastic Compute Cloud)
• Web (Alexa Web Information Service; Alexa Top Sites; Alexa Site Thumbnail; Alexa Web Search Platform)
• Workforce/Workflow (Amazon Mechanical Turk)

[here's Jeff, doing his stuff]

Business Models

The AWS offerings have various business models. The free one is the basic Amazon eCommerce API. Some of the ones I found most exciting were where developers had taken the Amazon catalogue and presented the data in really original ways:

liveplasma is a search and “discovery” engine which relates music of similar types. It has a fab flashy-feel interface and is quite off the wall in design – but still eminently usable. Go and have a play!

[liveplasma's view of interconnectedness, for the Rolling Stones]

hivegroup help you filter the myriad of technology available out there in a very graphical and interactive way. Follow the steps at their website and you’ll see what I mean. Here are a couple of screenshots:

[basic search for digital cameras brings back a colourful display, grouped by manufacturer. The text filter at the bottom can whittle things down further]

[mouse-over a product and a summary panel about the item pops up]

Fixed Monthly Fee service was the Historical Pricing (Amazon Marketplace sellers can find this useful for realistic pricing of their goods for sale).

Usage/Resource-based pricing is used for the resource-heavy services such as S3, Simple Queue Service, Amazon Mechanical Turk.

Mechanical Turk

Mechanical What? It’s basically a web service API for computers to integrate “artificial artificial intelligence” directly into their processing by making requests of humans. It generates a HIT – Human Intelligencd Task. The worker gets paid per task completed; you get the data you require. Such as – does the photograph I show you contain a human being? Most people would be able to say yay or nay in under a second – but a machine would take much longer and probably not always arrive at an answer.

Mechanical Sheep

So, OK, you have access to this service. What should you use it for? Well one guy asked people to draw a sheep, facing left. Why? Why not?! He collected 10,000 sheep at a rate of just over 11 per hour. You can see them all
at The Sheep Market. Here’s a screenshot of my favourite woollyback:

[baaaaaaa! Sheep #10,000 is a black sheep, of course]

There are some thoughts on d.Construct’s first presentation. I’ll add some more soon.