Looking for a Responsive Content Dialog(ue)

One of the larger issues when trying to create a truly responsive site is the content. Or rather, “what to send to whom…” (I am not trying to coin the next Ajax, but I am lazy, so I’m going to refer to this as WTSTW (what stew?) from here on…)
 

The reason WTSTW is such a pain is simple: connection speed.  You can only fit so much turkey through the tubes at one time.  If someone is on a crappy connection (be it a mobile network, dial-up (yes, people DO still use that), satellite, DSL, cable, slow proxy server, doesn’t matter), 500kb worth of whatever is going to take longer than on a good connection.  Basic, right?  Good.

Phone Home, IE (sorry, Chrome, you just didn’t rhyme right…)

One of the first swings people took at improving speed across slow connections was to reduce HTTP Requests (the number of times a user’s browser asks a web server for something).  We now combine our CSS files into a single CSS file.  We do the same for our JS.  Then we crunch those files into un-(humanly)-readable code to squeeze every last unnecessary byte we can from them.  And we scrunch all our design graphics into a single image file.  Or we use CSS magic to create images out of thin air!

Where in the World is…

Next, we took advantage of several server techniques.  We now serve our site assets via a CDN so users in Mumbai didn’t have to wait for a roundtrip to Palo Alto to get an icon.  And we set Expire Headers and Last Modified dates so browsers don’t even have to ask for assets if they already have a current version.

And all of this is really good stuff, all proving to be really worthwhile!

My Phone is DYING!  But Nice Background Image…

Next, we started looking at the images we were serving people.  A JPG that is 400×400, still pretty small by desktop standards, is pretty big on a mobile phone, and can really clog the tubes on a slow connection!  So people started looking at responsive images, and there are some really clever ideas out there, from trying to create new elements to handle this, to simply using JavaScript to fetch what is needed, if anything at all.

Again, moving the right direction, though I’m sure we aren’t there on this one just yet.

Why is My Monitor Sideways?

Then came layout: what happens when a page designed for a 1280×1024 screen hits a 320×480 screen?  Or when that typical horizontally-oriented desktop layout hits a vertically-oriented mobile phone?  Well, @media queries soon became the darling of the ball, getting plenty of use, and, like any good drug, abuse.

You Can’t Do That Here…

Somewhere amongst all the above happenings came Progressive Enhancement, the immaculate offspring of Graceful Degradation, that says “start out doing dead-simple stuff, and if the user’s device can handle cooler stuff, add it”.  So, we started writing basic CSS and JS, then building on that in such a way that devices that could understand the new stuff would get it and use it, but the simpler devices would just run right past that stuff and still look okay, and still work okay, no-harm, no-foul.

Which is f-ing fantastic, exactly the way we should be doing things!  Right?

So, WTSTW?

But the real trick comes with content (and I’m using “content” to represent anything that appears in any page that ends in something like “.html” or “.php” or the like).  Should people on slower connections be forced to download all of the stuff that someone on a faster connection has to download?

This is the question that has been dancing around my head lately, in my spare time, like when I’m sitting on the bus or not paying attention to the movie I’m watching…

Well, it seems to me that something like Progressive Enhancement for content is needed…

The basic concept that I’d like to discuss is to make an initial page that is lightweight, indexable by search engines and readable by screen readers and devices with poor connection speeds, and can be enhanced into a better experience based on the device’s connection speed, screen size, and capabilities.

This is really the core of what has been talked about some time now as Mobile (or Content) First.  But how do you go about this, exactly?  I mean, sending a basic content file to someone on a Nokia phone makes a lot of sense, but to someone on a 24″ LCD with a T3 connection?  That seems like underkill to me, and besides, we do still want to make money and stuff, right?

Though still through a good bit of haze, I can picture something like a JSON “config file” of component URLs and horizontal and vertical DOM builds.  Once the proper components arrive, build both the horizontal and vertical layouts as DOM fragments, store both in memory so they could easily be switched on orientation change, and innerHTML the current orientation’s layout to the existing DOM.

Much the same way general assumptions are made using @media queries, assumptions could be made to create “standard blocks” of pre-built HTML that could be combined, minified and fetched as a single HTTP Request.  These standard blocks might also include the CSS and JS necessary for them on arrival, especially now that we have scoped CSS on the horizon…

The essential criteria to me would be:

  1. The main content must initially be in-page, so it is indexable by search engines, readable by screen readers, and viewable on primitive devices/connections
  2. As few files as possible are fetched, in a performant manner, so we are not killing the experience we are trying to save
  3. Maintenance should be minimal, so we aren’t spending 4 times the hours building and caring for our sites

This is Where You Come In…

As I’ve alluded to, this is far from a fully-developed thought, just ideas that have been bouncing around in my cranium, and I wanted to get a feel for what the smart people of the world thought…

Does this make sense?  What limitations / pitfalls would you see with this approach?  What improvements / alterations / adjustments would you make?

Thanks,
Atg

5 Responses to Looking for a Responsive Content Dialog(ue)

  1. Hey Aaron,

    Enjoyed your article! Please forgive the question if this seems really basic but, why do we need to have a ‘one shot’ website that conforms to all media? There’s a lot of waste as you mentioned and there doesn’t seem to be a need for a magic bullet when we can give experiences that can take advantages of the unique traits of each medium rather than a one-size-fits-all approach, no?

    I liked this infographic of NPR’s workflow where the CMS handles all of the data like you would with a normal MVC setup, and then tailor each media to its own strengths and weaknesses.

    I apologize if it sounds too simplistic, I may be missing something here as being newer to this conversation! Thanks for reading!

    Best,
    Brian

  2. aarontgrogg says:

    @Brian: Well, you certainly get the land-speed record for commenting… :-)

    There is nothing about that NPR graphic that looks simplistic to me, and I think that’s what I’m trying to get around, but maybe it’s simply moving the work from one poor bugger to another…

    To me, the reason for having a single shot is to minimize the number of moving pieces (systems, templates, processes, etc.) that are needed to publish a website. I realize that the experience of being on a mobile phone is completely different than sitting at a desktop: what you want, and need, are likely very different, and I think that plays into this as well.

    If you’re out-and-about with your fancy iThing in your hand, and you conduct a search for a movie title, you’re likely looking for the nearest theater showing the film, the next available show times, and possibly a way to buy tickets for that show, right now.

    On the other hand, if you’re sitting on your couch, flipping through your iPad, you might actually be looking for background info, reviews, actor bios, etc.

    So, I get the idea of “different device, different experience”, but I think we can manage all that in a similar fashion. And maybe it doesn’t matter whether the client or the server makes the decisions, but I think it is vital that connection speed, viewport size and device capabilities be a part of that decision.

    And I think one of the other ideas that perhaps I didn’t illustrate as well as I had intended was that the JS config file would be able to create varying DOM orders to better fit portrait versus landscape orientation, without having to duplicate content (something I have seen done).

    Again, thanks for the reply, exactly what I am looking for,
    Atg

    • @atg haha thanks for responding! yeah, with that graphic there certainly is a lot of infrastructure work to make something like that happen and work together.

      I like the idea of progressive enhancement for content, I guess the question, how does one consider which content is the ‘essential’ content that mobile users get and which content the desktop users get? In theory, don’t we all want to use as few words/constucts needed to get our point across anyway? Although certainly I tend to fail at that once in a while as well. :)

Leave a Reply

Your email address will not be published. Required fields are marked *