I’ve just finished a new website for The Salmon Farm airport (53VG). It was a much larger undertaking than expected but it has a few very important tricks up its sleeve.

First, the site is fully responsive, meaning it works on desktop browsers, tablets, and smartphones with equal grace. It is resource efficient so even on typical cell phone coverage, it will perform well – the total data load is under 100KB.

For pilots, the METAR weather is live from an airport less than three miles away.

For those who have seen prior projects, the biggest deviation is that Fly 53VG is not a WordPress site. The decision was not because it was difficult. On the contrary, I recently finished a 501(C)(3) site that is also responsive and coupled to WordPress as its content management system. I chose to keep this site simple since the odds are high that I will only update a small section of it with any regularity. The "Advisories" box will get updates to runway conditions and flight hazards. Each section is represented by a different PHP file and my iPad has a nice FTP client with a built in editor so making those small changes will be quick and easy.

But wait. There’s more !

There is a complete introductory video of the traffic pattern for both runway 03 and runway 21. The video gives an overview of the airport and includes full length video animation flying the traffic pattern with inset video footage from an aircraft. There is the complete sequence for both runways. This training video gives a pilot’s eye view of what to expect when flying into 53VG. For those with good internet bandwidth, the video is available for download at different resolutions.

I jumped on the whole Responsive Design bandwagon thinking it was the right answer to format and layout. After multiple projects, I can say it is and it isn’t.

"Not everything is a nail so not all installations should be completed with a hammer." unknown

I’ve just completed a review of my web projects for the past 12 months. They include blog designs, some pro bono projects, a marketing site, and several mobile web applications. This was all as background research to writing a chapter on Responsive Web Design for an upcoming guide I have been asked to contribute.

Web Applications and Web Content are different

Obviously applications and content are different but making a determination as to which you have is not always black or white. Here are a few questions to ask:

• does your web project have "navigation" vs "controls" ?
• does content change dynamically ?
• is it bad if content scrolls out of view ?
• does important information fall "below the fold" (aka requires scrolling to view) ?

Web content benefits from responsive design – both for mobile devices and desktop browsers. Web applications do too, but need to address both horizontal and vertical layout. It is why web applications on mobile devices have UI elements such as fixed headers, stationary tool bars, slide shelves, and scrolling regions rather than scrolling pages. (Imagine for a moment if your word processor menu scrolled away.)

A customer designing a monitoring station with alerts, a map, and updating information does not want any of that to scroll away, just because they are looking at only one portion of the information. Lower priority information is collapsed rather than completely out of view. High priority information is always visible. And controls don’t move around – global controls stay in one place and context centric controls stay with the associated content (e.g. map controls and filters stay with the map and if the map is moved or collapsed, the controls follow).

It’s not always an obvious choice – content or application. Facebook’s web team initially said it was content while its mobile team said it was an application. Eventually the web team agreed. Two examples prove this. First, the status bar at the top use to scroll away, not is is fixed at the top for both web and mobile app users. A second example is how comments are handled for photos. The old method would allow the image to scroll away if there were lots of comments, not the image stays and the list of comments scrolls along the side of the image, maintaining context.

There are some relatively easy solutions. The first is to prioritize content. High priority content gets fixed locations and it never gets lost off screen. Status bars, notification badges, and contextual icons make good use of limited space at the top of the screen. Similarly, the sides and bottom can also receive fixed bars and controls. Regions of the screen can be frozen for content that should never be out of view. Sliding tool shelves & filter bars  and window shades can bring UI elements and information into view and then collapse out of the way to preserve screen real estate.

There is a growing desire to build web applications. There are several benefits – they work on various operating systems without change; they can be faster to develop and faster to update – all users se changes without installing new software; there is the expectation they will work from desktop to mobile; and there is a growing population of developers with web skills.

Building once for desktop, tablet, and smart phone is an achievable goal with a number of the current JavaScript UI frameworks.

In conclusion, there is no silver bullet for all web design. Web content sites have a different set of design criteria from web applications. Responsive design is only part of the solution and is equally applicable to both camps. My suggestions:

1. Identify your project first. It is not easy to shift from a content paradigm to an application.
2. Use one of the JavaScript UI frameworks for building web applications.
3. Implement a responsive layout – for both content sites and web applications – to support both desktop and mobile devices.

One topic not addressed here is the concept of widget layout frameworks. I’m just not ready to add that to this mix and for most projects, it is unnecessary complexity.

Most web page layouts today are either fixed width or fluid width. And to be honest, most rich layouts are fixed width. The reason is that fluid widths are more difficult to create and less predictable when it comes to how text and graphics will flow. A good fluid design is not easy and almost always imperfect.

Responsive Web Design is more work but renders more predictably than fluid designs. The truth of the matter is that responsive web design is still a significant amount of work compared to the fixed width layouts.

I recently completed a website design for a not-for-profit. The design called for branding, sponsorship recognition, information updates, photos, and basic legal corporate content.

Here is a quick breakdown of work estimates:

	Fixed Width Layout	Responsive Design
Logo and graphics work	12 hours	12 hours (and a few seconds)
Sponsors strip	2 hour	10 hours
multi-column layout	1 hour	4 hours
photos strip	30 minutes	5 hours
Conversion to CMS theme	2 hours	6 hours
	17.5 hours	36 hours

 

Nearly all of the extra time was dealing with spacing and layout within the CSS. Even thought I started with the Skeleton Boilerplate, and I used jQuery Cycle to rotate through the sponsors, there was a tremendous amount of work.

In nearly all of the cases, the work was getting all of the graphics to flow to the right places under all of the cases – large browser windows, tablets, and smartphones with rotation between landscape and portrait.

Lets look at the sponsorship strip as one example. There are currently 29 graphics (one is duplicated to make it 30). The graphics start out six across. If this were a fixed layout, we’d be done. However, to be responsive, the strip is broken into two halves that stack when the screen is narrow. The graphics further scale down on small screens. The graphics need to space themselves out dynamically. In the end, what might have been formatted with about 12 HTML statements and 4 CSS definitions turns into 30 HTML statements and 24 CSS definitions. Since there was no margins available in some of the responsive layouts, it also meant more testing and bug fixes. Thus, the task went from 2 hours – where most of that work was choosing and testing JavaScript slider options – to 10 hours with a lot of layout debugging.

The photo strip was just as bit an issue. The subtle different to the sponsors strip is the edge-to-edge display of the sponsors. The photo strip falls within the content area and requires the edge gutters.

A designer who has done fixed width layouts and has read about responsive design would think it possible to use any of the various Grid 960 layouts. The problem is many templates are coded to 16 columns (Skeleton included). Given the various layouts used for this project – 2 column, 3 column, 4 column, and 6 columns, a twelve column grid was better. The need to support gutters and no-gutters means most elements were duplicated with different values. Adding edge-to-edge support adds yet more wrinkles and thus more CSS.

The solution to this type of project is using LESS or one of the other CSS pre-processor languages that can be compiled.

Is Responsive Web Design worth it ? That depends. If you don’t have mobile users, then it may not be a worthwhile venture. Just don’t count on not having mobile users:

"access to the Web through mobile devices has nearly doubled every year since 2009" – Dan Graziano, BGR

- and –

"Mobile web browsing will become more popular than web browsing on desktops in 2014" – Mary Meeker, Morgan Stanley

The good news is that after your first Responsive Design, you have a pretty full tool box and experience.

This is geek-dom. All geek-a-phobes, anti-geeks, geek-aholics, …. move along, there’s nothing to see here. Still with me ? Sorry to hear.

Today was a day of writing technical documentation. Not the most fun I get to have at my job but it needed to be done and everyone else took a giant step back when I wasn’t looking. Most of the text came along pretty well but then I hit the need for a UML Sequence Diagram. First, I should say that "U-M-L"  must be missing a letter because it clearly is a four letter word. Second, I didn’t know I needed a sequence diagram when I started out.

I needed to find a drawing tool that could create these obscure but very specific pictures. It had to be simple. Really simple. BRAIN DEAD SIMPLE! Did I mention it needed to be simple? I found the answer at websequencediagrams and it could hardly be simpler. But I am getting ahead of myself.

Let me tell you a story. It starts in a man cave, starkly lit by the light of a large window. In the distance you can hear a dog snoring … (wait, let’s try that again) … In a dark corner, you can hear the most horrific sound; so loud it would wake the dead ! … (there, that’s better) …

… for geeks only, the story continues in the sequence diagram included

I’ve wondered what all the excitement has been about Twitter. It’s not new by internet standards and yet I had not used it. So, I gave it a whirl. I ended that joyride last night. I posted a tweet saying ” no thanks”. Here are my thoughts and experience.

• Twitter has a very large user base
• Twitter is great for posting status updates and short commentary
• Twitter is used for mostly for transient content
• Twitter can be used as a marketing tool (this may not be for everyone)
• If you miss a tweet, it is not the end of the world
• Twitter lets you be aware of the daily minutia of your Twitter-friends

The last one is what killed it for me. I welcome a tool that lets me stay more aware of my family and friends. The catch is that only 2 of my friends were on Twitter (or they were the only ones whom I could find on Twitter). Neither were very active.  (One only tweeted once during my experiment.) I followed a number of acquaintances but I found the tweets (aka twitter messages) grossly out of balance. One contact was tweeting 20 or 30 times a day and others were tweeting 1 or 2 times a week. The difference in the tweet content was hugely disparate. I found myself “silencing” those with “twitter diarrhea”. (I hate to say it but I can almost bet there is a cute internet / Web 2.0 word for that issue.) Also, the interface had a fundamental flaw for me. Twitter lends itself well to mobile devices with simple text messaging (SMS). Unfortunately, I have a phone service that has such poor coverage that I could not use the phone most of the time. Not only could I not tweet very easily, but I would get bombarded with stale tweets when I finally did get a signal and then most of that was the “twitter diarrhea”.

So, I concluded that Twitter has a few basic requirements for it to be useful and addictive.

• there must be a critical mass of your friends, family, coworkers, etc. on Twitter
• there must be some level of consistency among your Twitter followings and followers
• the Twitter service must not impede your usage
• your access to Twitter must be ubiquitous

When these elements break down, so does Twitter’s “pleasure factor”. (Again, I hate to say it but I can almost bet there is a cute internet / Web 2.0 word for that characteristic). It’s hard to make a habit of something that is not pleasurable – diet, exercise, staff reports, house cleaning, etc. For me, Twitter was a chore and for anyone who has seen my office, I’m not much on doing unpleasant chores. I get them done but they tend to pile up for a while and then get worked on en-mass … “rince and repeat”. Twitter does function well in that mode.

If I had had good mobile service and if there had been 6 or 8 or 15 people I wanted to stay connect to *and* who were on Twitter *and* were using it in a somewhat moderate traffic pattern, then my little experiment would have likely turned out differently. I will repeat this experiment in 12 months and see if I get different results. (Unless of course, Twitter is passe’ by then.)

There are two answers to the question of “what’s the difference between RSS and ATOM ?” First, there is the technical answer. Second there is the end-user answer. I’ll start with the second.

For the vast majority of end-users today there is very little difference between RSS and ATOM. Both are used as means to get access to information and in nearly all cases that information has been formated into “feeds”. I took a look at my blog statistics and was actually surprised by the ration of RSS to ATOM readers – 250:135. Now, my blog is not a hot bed of traffic so these are small numbers but to be honest, I would have thought RSS was much more prevalent. For technical reasons, which I will get to in a moment, the growing use of ATOM is a good thing.

So, what is the technical advantage of ATOM ? Let’s start by thinking of ATOM and “second generation” RSS. This is not precisely true but many of the reasons for ATOM were direct results of issues that were hard to address with RSS – mostly because RSS was already widely used. In short, it’s hard to change RSS because is is so popular. It may seem strange but that is a big part of why ATOM was initially created. So, “out with the old, in with the new”. We have ATOM.

The big change with ATOM is the focus on interoperability and reuse. For simple feed readers, this is not really important, but ATOM is increasingly being used for computer to computer interactions – data sharing. The more controlled the data format, the easier it is to make two completely separate computers “play well together”. Further, computer programs were no longer just “reading data”. They also wanted to have a method for creating new data, performing updates, and even deleting data. (For the lay person, the technical community call this CRUD for Create, Read, Update, and Delete.) So, the ATOM specification describes the use of HTTP methods GET, POST, PUT, and DELETE. Most system, prior to ATOM, only used GET and POST. For more details, you can get a quick understanding by reading the draft. An advantage of ATOM and it’s use of simple HTTP operations is that most of the internet is already optimized for these types of things. When we consider the billions of internet actions that take place every day, “optimizing” is a big-big challenge so the more that can work with the current internet, the better.

What can you do with ATOM and the HTTP operations ? You could write a blog. More important, you could edit a blog. You could search for a list of artists who have recorded a particular song or search for songs that contain a lyric. Then you could select one title and pay for it and get a link to download it. You could have you computer at home automatically publish updates to your friends or co-workers. You might have a little measuring device in your hot water heater or your air conditioner that provides electric usage to the power company. The power company might send new settings to your hot water heater or air condition to make it conserve electricity. A website could get news from the Associated Press news wire, relevant photos from Flickr, clips from searching blogs, and video from CNN and loads it all into an electronic news paper that refreshes every morning just as your coffee pot finishes brewing. This last one is partially here today using Feed Journal to create a PDF of your blog interests, formatted like a newspaper and the sent to a Kindle digital book and with the structure of ATOM, the reality of the individualized digital newspaper is a programming exercise a high school student could do in less than a day.

---

Disclaimer: I’m sure, for the technical reader, this post has been a big let down. It may even have been so simplistic that it misrepresented a few things. But technical explicitness was not the the focus. The focus was the “internet minus 1″ generation – those people struggling with what their kids are talking about when they explain the computer and the internet. Everyone needs to get up to speed and even a rickshaw can go 100 miles an hour if you accelerate it enough <grin>