Dave McDermid

Featured on this weeks Boagworld podcast, talking about Headscape’s migration to Google Apps

http://boagworld.com/podcast/171

OK, so SXSW is great for meeting people, parties, twittering, eating out etc. But there were also some fine talks from excellent speakers and panels. Here is a summary of what I took away from this years southby.

Websites are so much more than print

Most websites are built like people design magazines, posters and books. Websites are built as pages and adorned with pictures and video. This is akin to early filmmakers drawing inspiration from the theatre. It was only when filmmakers got creative and allowed the camera to be part of the action instead of an audience member that the industry came into its own. Good example: skittles.com – Their site is a mashup of a twitter search, youtube channel, flickr search etc. This is brave, but cool.

Sitemaps and navigation. Traditionally they have always been deemed necessary, and from an information architecture point of view, they are very handy. Clients like them so they can organise their pages into a natural hierarchy. This is wonderful, except as a site grows, it breaks. Eventually there comes the realisation that content could be categorised in different sections. An event may appear on multiple listing pages. A photo may be part of several galleries. This fine when navigating a site from top to bottom, but who really visits a site and thoroughly works their way through the sitemap?

Most people arrive at a site from a search engine or link, jumping right in on a page in the middle of a sitemap. So where do they go from here? There can be multiple routes back up the navigation tree. What we have here people is many-to-many relationships. This is a tricky thing to consider when building a sitemap. So don’t. Think about content, think about tagging, think about related content. If you get the little pictures right, the big picture will take care of itself.

Inspired by Dan Willis‘ SXSWi talk.

Unnatural experiments in Web Design

Paul Annett’s talk on using clever design tricks to entertain, amuse and inspire visitors was in itself inspiring. Often we go to great lengths to ensure our sites are usable, friendly and don’t break. We rarely go the extra mile to add the “Ooh, that’s clever!” factor to a site. The value of this is also underestimated, and can transform a site that makes a client happy, to one they rave about. The flip side is that if a nicety interferes with the functionality of a site, the opposite effect can occur. Classic examples are Silverback, with it’s parallax vines, webleeddesign, with the scolling paint and kyanmedia (click the worm in the footer). The justification for the added flare can be found in the Kano Model of customer satisfaction.

Creating a great API

Thanks to Greg Pollack for the down-to-earth How not to Fail at Web Services. There are some really simple rules to creating a great API that many have failed to follow.

• The URL is for nouns
• HTTP method is for action (GET, POST, PUT, DELETE)
• pronouns (or ids) should follow regular nouns (or types)

Bad example: /get/users?id=1
Good example: /users/1

Due to browsers only supporting GET and POST, it’s fine to compromise by using POST and pass in the method as a value. This keeps the url clean, readable and semantic.

The Future

Naturally, there was plenty of people looking for someone to tell them they can stop “supporting” older browsers. The best practice is not to ignore older browsers, but if the client is happy, just give them a simpler layout / style. New browsers can then receive a progressively enhanced interface. No browser should be left unusable or inaccessible. Naturally, it is up to the client to decide how much time is spent developing for older browsers.

Accessible Rich Internet Applications. It is becoming increasingly popular to use AJAXian methods of document manipulation, and this can be confusing for both screen readers and screen reader listeners. Work is being done to improve the control developers have over marking content and content areas as dynamic or prioritise announcements.

CSS3 always makes for an impressive demo. I particularly enjoyed Opera’s demo of rotating and shearing iFrames, even though I doubt it has a real world use. The principle of having that level of control of elements is exciting. Microsoft’s approach to compatibility and standards with IE8 is kinda convoluted, but clever and probably ultimately the safest approach. We’re still in a transition period, remember.

When it comes to writing really helpful comments in code, the only important question is why. It’s all too easy to make a quick note of what or how the block of code may work, but usually this ain’t too tricky to figure out. Coming back to old code, it’s the though process behind the logic that you wish you understood.

Whether it’s Style sheets, javascript or .Net, at some point in the development decisions require thinking outside the box, or working in a counter intuitive way to solve a weird problem. This is the snippet of understanding that needs to be captured to ensure the next time the code is looked at, it makes a little more sense.

During particularly tight projects, particularly those for valued clients or high profile websites, there is often a tension between the project manager and the developer. This is my experience, anyway. The reason for this is pretty straight forward, and understanding this is key to a productive relationship. The project managers objective is to make the client happy. For them, this means keeping the developer focussed and on track to complete the work within the time allocated. For the developer the objective is less clear. On the one hand they must keep their project manager happy, by producing work the client will like, even be excited about. On the other hand, they have a responsibility to produce good, clean, manageable code.

The favoured approach is far too often the quick and dirty solution that gets the work done and paid for with a healthy margin. This is great until the project is revisited, and invariably it will. As average solution on top of average solution builds up, there comes a point when something breaks and there is no easy fix. Often, there is nothing the developer would rather do than scrap a bunch of code and rebuild it from the ground up. This is invariably time consuming, and frightening for the poor sod who’s job it is to test it all. There is also the consideration of who swallows the cost of this, as the client / project manager won’t see the immediate benefit of this kind of work, making it hard to justify.

The dangerous middle ground is the point at which trivial tasks become time consuming with unexpected repercussions and legacy code wrecks havoc with a beautiful solution. This guarantees stress for all involved and can strike fear into the heart of anyone threatened with involvement in the project.

So, what’s the solution? I had the first half of this post all planned out in my head, but now I’m kinda winging it. One solution is progressive deprecation. The strategy here is when tasked with implementing a new feature for project, to decide not only what needs to be built to fulfil the requirements, but what existing parts can be made redundant in the process. The process of evolution within a project critically must involve replacing old code with new, rather than just adding to what exists.

There is understandably a fear shared between the PM and the developer for work that stretches the scope of a job. At the end of the day, it boils down to the developer’s responsibility to look after his work. The projects I feel really good about are the ones where I’ve left the code in a better state than when I started. Often it’s tricky to convey this achievement to a PM, who is generally only interested in things that they can show off to the client.

This is where peer review among developers really comes into it’s own. I know from personal experience I write better code and make better technical decisions when part of a team. This is natural, it taps into the desire to show off and prove your worth to colleagues and when harnessed correctly can be powerful.

Thanks for reading, would be interested to hear your thoughts..

I’ve decided to experiment with a dead simple greyscale 3-column theme. I’ve decided I’m not ready for colour, and it’s pretty dull weather outside anyway. For now I’m focusing on getting the CSS and layout right. I’m planning on developing this into a very customisable, yet straight forward Wordpress theme to give away. Hope you like.