Let's drop ‘Responsive’ from Responsive Design

In a meeting a while back, a client who had their web site built on a shoestring asked me with a slightly panicked expression: is my web site ‘Responsive’? I looked at the site and squished the browser around some and saw rudimentary things happen to the layout. It didn't look great. The only answer I could give to try and appease the anxiety of said client was 'a bit’.

It did make me start to question what Responsive Design was and question all the current 'attempted' classifications around fluid, reactive and adaptive, etc. I won’t go into the detail here, but you can use the interweb to find out more :

The truth is that there is no one answer and the lines between fluid, responsive and adaptive design are blurred and ever changing in a world which is producing devices of varying dimensions and capabilities faster than people can pour buckets of ice over their heads.

Responsive Design is not an end state, it is a process which tries to deal with many challenges of building web applications that can be viewed from your phone through to your TV through to gigantic projections on one side of the Grand Canyon (should it be so lucky).

The challenges are centered around these areas:

A pragmatist’s view: What is Technical Architecture and how do you do it?

As a Technical Architect in a digital agency I am often am asked what the role actually means or does. This question comes from everyone including Technical Architects (TAs) and one that is actually quite difficult to answer. The reason for this is that the definition of Technical Architecture in the real world has a very broad scope and is different in different companies, projects and from person to person. It is often becomes a religious argument what being a TA means or what the best way of doing it is. Forgetting best practices, patterns, methodologies, techniques and opinions just for a minute, here a broad view ‘what’ a Technical Architect does and ‘how’ they do it. I'll even look at why in some cases. I'll leave where and who up to you.

Web application development is transforming, but that doesn't mean everything has to change

The way we build web and mobile device applications is changing fundamentally. What this change is - in a nutshell - is application code moving from the server to the client. The server being big computers sitting in a data centre somewhere and the client being a modern day browser. To explain this further, let’s call the old way of building web sites as web 2.0 and the new way as web 3.0.

In the past, when web 2.0 was all the rage, web sites were built with a lot of server side code written languages such as c#, php or java. This code ran on various web server application platforms such as Microsoft ASP.Net. The code ran on the server and spat out HTML which was rendered on a browser and allowed the user to interact with the application. There was probably was a bit of JavaScript but none of which was essential to the application doing what it needed to do.

Out of the Search Darkness

"A harrowing tale of one man facing his search daemons"  Sergey Brin

9 out of 10 technical projects which fail is because of badly thought out and executed search. Okay, that number is a piece of fiction; but, my hopefully empathetic friend, that is how I feel; because yet again I am fighting the same old user experience battles when it comes to designing search.

I think the root cause of search atrocities is, like most heinous and tyrannical acts, due to ignorance combined with wild ambition. Let's stuff everything cool we've ever seen on any site that I've ever dun a search on and then it should be wickid, yeah? No. What about fuzzy.. No. What about nice mix of facetted did you means? No. What abou... No. No. No.

Now, before I cast myself in a dubious light of technological pessimism and creativity bashing egotism, let me take you down the river on a journey of exploration and discovery into tech rash's top dos and donts when designing and building search.