Life is a train which can easily, and probably does quite frequently, jump the tracks. Our paths are about as defined and predicable as ripples from a line drawn in the waves of a turbulent ocean.
I have often advocated designing websites to support as many screen resolutions and browsers as possible, including tiny mobile devices and text-based web browsers like Lynx (though I prefer Elinks myself). Whether I’m under-the-gun at work, or just designing a new WordPress theme for my blog, when time and resource constraints force me to decide on a minimum resolution I look for statistics to back up my choices. In a perfect world, all sites would be usable with all browser resolutions (and CSS would play nice with all browsers and 1px would be 1px… don’t get me started).
It wasn’t too long ago that a lot of people were still browsing the web with an 800×600 screen resolution. For most of us now though, the only time we see that screen resolution is when we don’t have the correct video drivers installed. W3CSchools keeps lots of interesting web stats based upon visitors to their site, including Browser Display Statistics. Here you can follow a clear trend to higher browser resolutions through the years:
This lead me to check my the visitor browser resolutions for this blog through Google Analytics. I’ve been keeping stats on this blog since September 2007 and with over 40,000 visits I figured I could get some good metrics:
These stats seem to indicate the same thing as W3CSchool’s stats: 1024×768 is a clear winner. This got me thinking though. How many of the popular sites out there are viewable in 1024×768? What about 800×600, or even 640×480?
Yet Another Window Resizer is an excellent Firefox add-on that allows you to easily resize your browser to various resolutions. I visited various popular sites and tested their minimum browser resolutions:
Clearly most sites have chosen to ignore smaller browser resolutions in favor of supporting only the most popular as a minimum. (Although this blog has a 1024×768 minimum requirement, the main content area is fully visible in 800×600.) The nature of the content presented by the site dictates a lot of the size requirements. For example, Google search presents textual content that can easily be (and most certainly should be) confined to a small area. In fact, the Google search results maintain a 640px width even when you’re using a much higher resolution (leaving a lot of white space to the right, but maintaining readability).
There is much to be said about textual readability on the web, but I’ll leave that for another post.
So there I was sitting in my C/Unix class at Harvard barely paying attention to the professor as he talked about HTML forms (!) when I heard him start talking about the history of the HTML radio button. I often wondered why they were called “radio” buttons so I shifted my attention and listened.
He started by trying to explain to a room full of people a third his age how car radios did not always have tiny touch-sensitive buttons and that they used to be single mechanical buttons that when one was pressed, the other would come out (much like the old cassette-based walkman’s).
This little fact fascinated me because I have been using HTML radio buttons for so long and until now, I have been so oblivious to the history behind their name. A quick search on Wikipedia confirmed my professor’s story:
A radio button or option button is a type of graphical user interface widget that allows the user to choose one of a predefined set of options. They were named after the physical buttons used on car radios to select preset stations - when one of the buttons was pressed, other buttons would pop out, leaving the pressed button the only button in the “pushed in” position.
A multi-touch color screen touchpad using the same touchscreen as the iPhone? It could replace the OS X dock and provide a whole new method of interacting with your computer! Fingerprint security device, electronic signature pad, an electronic sketch pad for better photo editing accuracy… the possibilities are endless!
Dialog is a really useful utility for creating professional looking dialog boxes and menus within a shell script. I’m working on a boot-time script that allows the user to make system-level changes before the system has fully booted.
When testing my script from the command line, the dialog menu looked fine. However, whenever I set the script to start during boot (update-rc.d myscript.sh defaults, on Debian-based systems) here is what the menu looked like:
UGH! It was barely usable. At first, I thought this would be an endlessly difficult problem to solve given my limited in-depth knowledge of Linux (I’m getting there!), but then I realized the main difference between the script running during boot and the script running after I had logged in was that my environment variables had not been loaded.
From the command line, I ran the env command to display all my current environment variables:
The three variables that caught my eye were TERM, SHELL, and LANG. After a little trial and error, I discovered setting the LANG variable fixed the display issues with dialog! I added the following near the top of my script:
export LANG=en_US.UTF-8
Now when my script loads during boot, everything looks correct:
