Which One: Responsive Design, Device Experiences, or RESS?

Reading this post reminded me of a little experiment I started about 6 months ago to try and implement smarter ways for doing RESS (Responsive Design + Server Side Components) based application development.

Before you read on, I’d encourage you read Luke’s writings on the topic of RESS. But if you don’t want to, then as I understand it basically boils down to combining the proven techniques of responsive design with some device specific rendering done on the server side to account for those “edge cases” where responsive design just doesn’t cut the mustard.

Unfortunately, server detection techniques generally rely on the broken model of User Agent detection or sniffing. Even with large extensive device user agent databases like WURFL, I believe it to be a very broken technique. It’s something that we have thankfully gotten out of the habit of in client-side code, but in general the User-Agent is one of the only pieces of information available that provides some clue about the client device and browser that is currently accessing the site.

There has to be a better way

There is – well at least I believe there is. And it’s not that complicated either.

Let’s start by talking about something we are all familiar with – attempting to access a part of a website that requires you to be logged in:

In the case where you are logged in, you will be transmitting a session cookie to the server, it does a few checks and balances on the session and all being well displays you the page you were after.

In the event that you don’t have a valid session cookie, the server renders (or redirects you to) a login page and you go through a login process and once successful are returned to the page you originally requested.

Now let’s take that pattern and apply it to a device capability detection (or devcaps) scenario:

A server receives a request to view a particular web site or web application page. In this initial request the server looks for a “DEVCAPS” cookie that links to a device capability profile that is stored on the server.

At this point the server creates a device capabilities profile and provides the client with a cookie that it should use in subsequent requests.

I know that the technique is not without it’s caveats (a reliance on both Javascript and cookies, for example) but I believe it’s something that is definitely worth exploring further. Certainly from where I sit, I see the issue of Javascript not being available on devices becoming less of an issue while device capabilities fragmentation will only continue to grow.

More information on DevCaps

As I mentioned at the start of the article, I started a Github repository a little while ago to try and collect my thoughts, and also a reference implementation in node to validate that the process actually works.

Try it out!!

While it’s not hosted on a bullet-proof server, and it’s far from a bullet proof implementation, we’ve stood up a demo page that shows how the technology works and you can try it out on your own device:

http://devcaps.sidelab.com

If you have any feedback or ideas then feedback would be great, and if you are interested in using the technique to implement your next cross-device application then feel free to get in touch and perhaps we can do something together

A little while ago, I probably would have just put this in the too hard basket, but thanks to some excellent work from TJ Holowaychuk we have a little XHR library available called SuperAgent. While it’s still early days for SuperAgent, it does a bang up job of offering both an in-browser replacement to jQuery’s $.ajax function and also various http client libraries in Node (with request being my personal favourite).

With SuperAgent available, it opens up a couple of possibilities for getting a CouchDB client library that works in both the browser and in Node:

1. Fork nano, and replace request with SuperAgent
2. Build a new experimental CouchDB library

Being a sucker for experiments, rightly or wrongly, I went for option 2. And lo, SuperComfy (early docs here) was born.

It is similar in feel to nano, with a few exceptions and additional features:

• REST methods are as purely mapped as possible. SuperAgent does a good job of this, and SuperComfy doesn’t break that good work. For the most part, this is something nano does as well, with the exception of things like insert instead of put.
• Based on the requirements of Steelmesh 2.0, SuperComfy has some pretty nifty functionality that allows you to redirect writes to another database. Very useful in cases where you have a replicated environment and would like to avoid replication conflicts…

If you are feeling a little wild, feel free to take SuperComfy for a spin, and let us know your thoughts.

In it’s current form, Steelmesh is designed to take a NodeJS application (with a specific file structure) and replicate that application across a network of machines using CouchDB’s excellent replication. This has proven to work exceptionally well and application deployments in a Steelmesh environment are definitely orders of magnitude easier that what you would experience through manually updating multiple servers.

While I might be wrong, I think using CouchDB for package distribution has greater potential in the long run than the currently very popular method of git based deployment. The current implementation of NPM is a great example of how CouchDB can be used for application distribution to great effect.

What we want to do for Steelmesh 2.0 is enable application distribution for languages over CouchDB using the same general principles as we did for Node in Steelmesh 1.0. This is obviously going to be a little bit of work, and we are only in the planning stages now, but it would be great to get feedback and comment around this if you have any ideas.