AWD Using Device Detection

Searching for ‘Adaptive Web Design’ (AWD) on yields a variety of results, not all of which imply the use of device detection. At the time of this writing, wikipedia’s page on the topic is a mere stub.

AWD Without Device Detection

In his book Adaptive Web Design, Aaron Gustafson discusses general principles of web design, but does not mention device detection — at least not in the first edition. (I have not yet read the second edition.)

Articles describing the difference between AWD and Responsive Web Design (RWD) at and assert that the difference relies on breakpoints, stating that AWD uses them but RWD does not. However the responsive themes I have seen rely on breakpoints in media queries to determine which CSS rules to use to layout the markup served to the browser.

These articles all imply that all web servers deliver the same content to all browsers, regardless of the device type.

AWD With Device Detection

My understanding and use of the term coincides with this article, which answers the question, “What is Adaptive Web Design.” Their answer maintains that it involves serving content selectively, depending on the device.

In my mind, with AWD it is the server rather than the browser that adapts to the device.

This technique implies some sort of device detection. Software does this by processing the
user agent
(UA) string that your browser sends to the server in the request.

Your User Agent String

You can see the UA string that your browser sends to servers at The page includes a table that breaks it down and describes the information it contains.

Chrome.Com has a page written for developers describing the UA strings it sends to servers, based on the device being used (Android or Apple).

Note that the server has access to this information even when you are in a private or incognito window.

RESS and “Dynamic Serving”

Another term for this sort of technique is REsponsive Web Design with Server Side Components (RESS). (I am sorry, but this acronym does not appeal to me, for a number of reasons, so I prefer not to use it.)

Given the name, this of course implies some sort of responsive design. My three sites fall into this category, but my online interactive resume, which uses device detection but no media queries, does not.

Google calls this technique “Dynamic Serving,” and offers a page offering tips for doing it properly.

Media Queries

Interestingly, it is possible to use media queries to serve different css files to devices, based on their characteristics, for example, the screen width. I for one would prefer (but have not used) this technique to responsive techniques that send the same content to all devices and rely on the browser to decide how present this content.

Mobile users may be surprised to learn that sites using RWD actually send content, then use media queries to hide it.

Saving Bandwidth

For me, the bottom line is we should not be sending content to someone — especially if they are on a mobile device — only to hide it. If your phone has a tight data plan, or you live in an area where that sort of thing is expensive, then I am sure you will agree that doing so is downright irresponsible.

But based on the apparent popularity of RWD techniques, apparently that’s just me.

The Conscientious Programmer

Because of previous experiences, I always take great care to try to write clean code that is easy to maintain.

These efforts have paid off! I have always received positive feedback — and at worst (best?) a helpful pointer — from colleagues who have reviewed my code.

As this short essay and this page on Stack Overflow demonstrate, there are plenty who agree with me in this respect.

Is Conscientiousness Obsolete?

As things change more and more quickly, some people might assert that being careful is no longer important, because today’s technology will soon be obsolete. More and more we see this, as technical debt increases to the point where legacy systems require total replacement.

This is certainly a valid point, and we need to be mindful about how much time we spend chasing an idea down a rabbit hole and trying to make things just exactly perfect.

Not So Fast!

Another side to this idea is that, because things change more quickly, it is our professional responsibility to help others embrace this change by writing more maintainable code.

As the trend away from full-time employment towards temporary gigs continues, it becomes more important for the next person — whose experience may be vastly different from our own — to be able to quickly understand how the current system works, so they can quickly make the desired changes.

My Personal Preference

Obviously, I can see merit in both sides of the debate.

But to be perfectly honest, I prefer to be conscientious, perhaps because it’s in my nature (I grew up with a lot of guilt).

When done with a project, I like to feel good about what I’ve done. I like to be confident I’ve done a good job and didn’t just “hack something up” to meet a deadline — not that there’s anything wrong with that — provided it’s what the customer wants.

Preventing Misunderstandings

Here are some techniques that can help alleviate possible misunderstandings when it comes to quality:

  • If you are planning to replace a system and just need a very few minor but important changes made, be sure to state this up front, so that we know that in this instance quality is unimportant.
  • Setting a fee for the finished product, based on its value to the customer, is preferable to paying for work by the hour. The set fee scheme alleviates the risk of unwillingly paying more for “high quality,” which can be difficult to define and in some cases even be totally undesired.
  • Stating up front that your company is on a strict budget and at this time cannot afford any extra expense for “high quality.” If you are interested in improving things once the company’s finances stabilize, this is good to know, because we can leave “TODOs” in the code to help the next person.
  • Building a “quick and dirty” prototype. A true prototype should be built with the intent of discarding it and starting over from scratch, if and when it proves the viability of your ideas. If you think the prototype might go into production at some future date, be sure to mention this up front.

In my experience, few clients will say they do not care about high quality, but their preference makes itself apparent in other ways, which can be unfortunate.

Direct communication is always preferable to nuance — which is easily lost when working remotely.

Over-Thinking or Due Diligence?

I like to take my time when solving a problem. More than once I’ve coded up a complicated solution, only to take a look at it and figure out a much simpler way to do the same thing.

To some, this is over-thinking. To me, it’s due diligence.

I like to come up with multiple solutions and pick the best one, rather than rush to implement the first idea, even though the initial solution might be sub-optimal.

Communication is Key

Moreover, if I am working for you on an hourly basis and you prefer I deliver an end result that might be something less than “just exactly perfect,” please state this up front.

Properly communicating your preferences allows me to keep an eye on the finished product and deliver an optimal result, regardless of whether we agree on what exactly constitutes “high quality.”

Run These Sites From My Home

One of my favorite sites is BuiltWith.Com. It will tell you plenty about this site, but one thing it doesn’t know is that I run it, and several others, from my home.

Geek Pride and Land Lines

I am very proud of the fact that I have a static IP address and run these sites out of my home. My internet provider is Forethought.Net, and the ability to host sites is included with my internet connection and land line.

Land lines may be old-fashioned, but this is the sort of offer I cannot refuse.

Well-Rounded Cheapskate

I assure you that in running these sites I do everything that needs to be done. This is partly because I like to be well-rounded, but mostly because I am a cheapskate.

I also assure you that I do not consider myself an expert in any of these tasks. For one thing, I dislike the term “expert” in any context, and for another, I am always open to ways to improve on my processes. One reason I dislike the term is because an “expert” would never question their own abilities….

If you’re interested, some of my more important processes and tools are available in my jmws_accoutrements repository on github.

“Everything” Means Everything

In case you do not run any websites out of your home, here is a list of what I mean by “everything:”

  • obtain static ip
  • conceive the types of sites I want to host
  • purchase domain names
  • buy the requisite hardware
  • configure the home network
  • install requisite operating systems and software and keep it up to date
  • learn the technologies needed to create these sites
  • actually do the work of creating these sites
  • create databases and site users with sufficiently secure credentials
  • imagine, organize, write, format, and post content
  • keep up-to-date backups of code and content
  • configure the server, ensuring it is secure
  • deploy sites to server, along with updates as they become available
  • design, write, test, and maintain programs to add any functionality that is missing out of the box
  • keep up-to-date with industry trends
  • document programs written
  • document deployment and other important processes
  • register the sites with google
  • comply with any requests google makes concerning security and searchability

If this looks like a lot of work, I can assure you that it is.

Favorite Practices

In addition to saving me money, a big advantage to doing things this way his lets me find out first hand what type of work I like best.

I like the programming best, and the writing and design tasks are close behind that. Testing and deploying are not quite as fun, but I don’t have to do them much, and I am too much of a cheapskate to be willing to pay someone else to do it, so we do what we have to do.

I greatly enjoy writing little scripts to help with deployment-related tasks, and am currently porting my bash scripts to python. (You can see these scripts in the bin directory of my jmws_accoutrements repo.

Because I am the only one using these experimental extensions, at this time it’s not really worth it to me to automate testing for this work. Kudos go to Drupal though for integrating automated testing out of the box.

Flow Is the Best

Ultimately, as I have learned in some of the online classes I’ve taken MOOCs, I love any type of work that involves flow. The linked-to article at defines flow as being in a “state of effortless concentration and enjoyment.”

As you might imagine, working on my own for free can lead to occasional procrastination. That’s actually fine, because I always find that once I get going and into the flow of things, it can difficult to stop.

Moreover, “it’s all good,” and I greatly prefer any of this sort of work to at least 99% of the other occupations out there!

A Passion for Maintainable Code

Thanks to a book, named Code Simplicity, I finally realized one of the main things I love about programming so much.

Finally, after many years, I have discovered my passion! And that is: writing code that is easy to understand and maintain, and this boils down to keeping code as simple as possible.

The book analyzes the value of software, the effort needed to maintain it, and the desirability of the changes, even though we cannot be sure what the nature of these changes might be.  And it comes to the conclusion that all code needs to change eventually, and the future cost of making these changes is more significant than the initial cost of development.

The book made me realize that the real cost in software is not in the development of it, but in the maintenance.  By taking a little extra time and ensuring that code is maintainable, in the long run we save money.

And that is what I really enjoy about writing software.  Once I get a program to work once, I don’t like to stop there, the way some people do.  Instead, I like to take the time to look at what I’ve written and ask:

  • Does it make sense?
  • Could what it does be done any more simply?
  • Is there any cruft, any dead, unused code?
  • Will a new person understand it, quickly and easily?
  • Will a new person fix or enhance it, quickly and easily?
  • Will I understand it, quickly and easily, if I need to change it, in the middle of the night, a few years from now, or both?

To tell the truth, I actually have at times felt guilty about taking this extra step.  After all, the program works, why spend more time on it?  And of course there are times when I haven’t been able to take this extra step, and have regretted delivering something that I am not very proud of, something I know could be better, if only there was a bit more time.

This blog contains stories about the benefits of well-designed, easy to maintain code, and the hazards of poorly-designed, difficult to maintain code.

But I still encourage you to buy the book.

The GROJA Program

I wrote the GROJA program in Graduate School. GROJA stands for Graphical Representations of Jungian Archetypes.

Given the results of a questionnaire, the program draws an image of a person’s personality. The resulting image represents a person’s preferences, based on the four pairs of opposites that Carl Jung describes in his Description of the Types.

I wrote the first version in LISP and it ran natively on a PC. Since then I have used PHP to write three online versions. For details see the About page at

Due to security concerns, this program is no longer online. But I am able to run the most recent version locally. You can find a gallery of images in the Gallery at SeeOurMinds.Com.

When Coworkers Complain

My first programming job was writing code in an Assembly language for NCR Century minicomputers, called NEAT 3, for a trucking company.  For the record, the first day of my career was the Ides of March in America’s Bicentennial year: March 15, 1976.

We wrote the code on paper forms using pencils, used a key punch machine to punch cards, which were then read into one of the computers when the computer operator was able to get around to it.  We had two computers, and each had only two partitions, and only one of the partitions was capable of “cowpiling” programs.  (Our operator, Al, had a rather cynical sense of humor!)

Along with some enhancement and bug fix tasks, for example, changing the number of digits needed to represent a terminal – the equivalent of a primary record key in today’s terminology – from two digits to three, I remember working on a system to process claims for items damaged during transit.

And along with some other people, I worked with a woman whom I will call Carol, who was constantly complaining about how hard it was to understand the programs she had to make changes to.

This made a huge impression on me!  The last thing I would ever want to be is the type of person my coworkers complain about!

Specifically I remember her complaining about how the original author managed tables.  NEAT 3 provided a mechanism for iterating through tables, but the original author of the programs Carol was working on was too smart by half to use it.  Instead he  chose to “bump registers,” which means he would:

  1. store the address of the current row in the table in a register
  2. process the current row, saving the new values if required
  3. add a literal offset, such as 123, to the register, to access the next row in the table

So when Carol wanted to add or remove a field to or from the table, or change the size of an existing field, she had to find all occurrences of the current offset (123 in the example above) and change it to the new size.

That means that Carol had to find every piece of code in the entire system that iterated through these values, and update that offset, every time the length of the table changed.  In all of today’s modern programming languages, all a programmer should (!!!) have to do is change the contents of the table – which we hope should be defined only once – and they should be good to go.

This might not be so bad, if we had an Integrated Development Environment (IDE) or even a fancy text editor like vi (aka. “six“) but we were using punch cards.  Yeah.

The lesson I learned from that experience is that writing programs with an eye towards maintainability can not only help keep future programmers from being aggravated and hating you, but also save your employer a lot of money down the road!

As this recent post on slashdot, and even more so the responses to it show, Carol’s situation was hardly unique, or by any means antiquated.

When coworkers complain, valuable lessons can be learned!

The C Programming Language

The Assembler, Fortran, Snobol, Cobol, PL/1, and Pascal books are all gone, but I still have this one, “The C Programming Language,”   by Kernigan and Ritchie, affectionately known as “K & R.”

And I just want to say one thing about it, and that is, there are a lot of different indentation styles, but when it comes to server-side programming languages, I for one do not care for the “K&R braces” style.  It’s not consistent!

Servers and Browsers

When it comes to server-side languages like C, PHP, and Java, I prefer the Allman Style, and it’s nice to know I am not the only one.  White space and consistency are important!

However, when it comes to browser-side code — and CSS: I am looking at you — I find myself using the K & R style. This is, of course, because there is very little need to nest CSS, and hence no need for the ambiguity (and I admit it is very slight) we see in their book.

Java and JavaScript

At first this left me in a bit of a quandary when it comes to everyone’s new darling, JavaScript. Because JS works hand-in-hand with CSS, it’s only natural to follow the same policy.

So for S&G I started using the K&R-style braces on some JS. I hereby admit that it is working well!

For one thing, I am learning it does indeed have some appeal when working on large projects. This is because we typically have many windows open so real estate is at a premium.

And for another, most, if not all, text editors and IDEs these days make it easy to find pairs of matching parentheses. So wake up to find out that consistent vertical alignment of braces is no longer of high importance.

Mixing Styles

Moreover, using both styles this way actually has a bit of an advantage, because it is immediately and glaringly obvious whether I am working on server or client code. My plan is to continue using this hybrid policy, at least until I start using Node.js, anyway….

My First Code Review

My second job was writing IBM Mainframe Cobol programs for the City of Richmond.

I started out making some changes to some existing programs: enhancements and bug fixes, nothing major.  We had Systems Analysts then who were familiar with how the programs worked and who would spec out the changes quite thoroughly.

Then I got to write my very first entire program.  I was so proud of it!

During this time I’d identified a couple of colleagues as being sharper than the rest (mainly because the were not part of any of the gossip gangs).  So I asked them what they thought of my program, hoping that they would like it, because I had learned at my previous job that maintainability is important.

They tore my little program to pieces.  I thought I might cry — but I didn’t.

They taught me how to use structured programming techniques to organize my code.  Many mark Edsger W. Dijkstra’s famous paper GoTo Statement Considered Harmful as being the beginning of structured programming techniques, but it is much more than using Perform statements instead of GoTos.

Because it strives to read like English, Cobol does not have the syntactical mechanisms that many other languages do, control structures that allow developers to break things down and organize code into components.  So they showed me how to precede all functions with three- or four-digit numbers, that would reflect the function’s place in the flow of logic.  Although foreign to me at first, after seeing how it worked, it made a lot of sense.

As it turns out, I learned more in that hour than I did in many of my classes at school!