the RV-8 with the Wright Bother’s monument in the background

I had the change to be a “flight of two” down to Kill Devil Hill aka Kitty Hawk aka First Flight. It wasn’t my first trip to the site but it was the first time I connected with another pilot en-route and transmitted as a “flight”.

The day was near perfect with some wind but it was mostly constant and predictable.

I started tracking the other airplane shortly after their departure from Princeton, NJ. I launched a little early of the intercept time to do a little local flying. Using the air-to-air frequency (123.45) we made contact but it took a few minutes to establish visuals and sync up. After that, it was an easy flight, clear of Norfolk and Oceania airspace but in contact for advisories.

The 3+ hour drive is about 45 minutes in our airplanes. Even “going slow” we still were entering the pattern for zero-two before we had gotten comfortable with our loose formation flight.

On the ground, we dispensed with the pleasantries (and the requisite inspection of each other’s airplanes) and checked out the pilot’s office. Then we headed up to the monument.

The National Park Service has a very informative website which contains all of the facts and history. Most of the same information is located on well placed plaques and information markers throughout the park. It makes for a casual and informative walk. Pilots will likely stare long and hard and the distances of those first powered flights. Most airplanes are not even off the ground in the distance of Orval’s longest flight!

Soon, it was time to depart. Before leaving, we each pulled our airplanes around to the spot in the accompanying photo – pilot, plane, and the monument the two brothers who started it all.

We launched in succession. I took the high road and the other plane took the low road. The low road had more favorable winds and better views but I like a bit of altitude on water crossings – even short ones of 20 miles. 45 minutes and I was enjoying a nice wheel landing back at 53VG.

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.

iPad in the office

I know a lot of people who have tablets and take them to work. I hear things like, “it’s great for meetings”. I suggest it can be great at your desk too.

I keep my iPad in a suction cup mount (
RAM makes a nice one). It is right on my desk. I find I often use if for what I all “interrupt tasks”. When I’m working a project on my desktop computer and I need some information such as a quick Internet search, run a calculator, accept a calendar invite and even read emails, I don’t want to interrupt my work environment so I do those tasks on the tablet. Even out company social networking has a tablet app.

The tablet is right below my main monitor so I can view them seamlessly.

Now, my tablet is an integrated part of my office setup.

Tablets aren’t just for meetings anymore!

I’ve discovered the ultimate kitchen hack for making ice cream – my grand mother’s peppermint stick ice cream recipe from 60 years ago! Yes, our grand parents were hackers but we won’t tell them.

The original recipe was simple enough. The base was:

• 1 [small] can of sweetened condensed milk
• 1 cup heavy cream
• 1/2 cup cold water

My hacked update is:

• 1 14oz can of sweetened condensed milk
• 2 cups whole milk

That’s right, just two ingredients. I put all of this in a 1 quart mason jar along with 2 tablespoons of instant coffee. Shake and toss in the freezer to chill (this may not be strictly necessary).

Pour the contents into an ice cream maker (the kind with the chilled cylinder work fine) and turn on the machine.

Now, if your kitchen happens to have xanthan gum handy – all good hacker kitchens should – slowly add *at most* 1/4 teaspoon while the mixer is running.

Depending on how cold the liquid is to start, you will have a smooth, decadent soft serve coffee ice cream in 15 to 30 minutes. Transfer to a plastic container and toss in the freezer to harden further.

This will go great with my cake-in-a-cup

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:

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.

clearly, someone did not read the memo

I’m not sure where things went so terribly wrong but we awoke this morning to snow on the ground and cold winds burning the skin off of our faces.

I had clearly sent out a memo right after Christmas telling everyone that winter had been canceled. I have a copy of the memo and the distribution list.

You can be assured that first thing Monday morning we’ll be looking into the matter and find out who ignored the notice.