User Preference Layout

You can find the demo for this article on bulletproofpixels.com. It would help to take a look at the demo before reading.

A good prerequisite to the material I present here is the article "Adaptive CSS Layouts" on Smashing Magazine. When I write entries that include full fledged examples like this one, I tend to make some general assumptions about you, the reader. In other words, my details don't always get as granular as some would prefer.

The afore mentioned article presents great ideas in creating fluid layouts and is a highly recommended read. Another very recommended read on the subject of layouts is the article "Fixed vs. Fluid vs. Elastic Layout" also found on Smashing Magazine. It was this article that got me to thinking of maybe a different approach to a UI that could be selected by the user with a single click and adapt not only the layout scheme (fixed vs. fluid) but also at the same time the font size. I left 'elastic' layouts out of the equation because in my opinion this method's caveats are too problematic to be real-world practical. Of course more time spent working on the pros and cons of this method might reveal a bulletproof strategy - the subject of another post maybe?

My idea is really a simple one, and no doubt has been tried before. But, whereas other articles tend to focus only on the layout and general content (paragraph text), I wanted to try my idea including other forms of content that presented a bit more challenge, as I am faced with such granular details on a daily basis.

The basic premise is this - choose several schemes that include a layout type (fixed vs. fluid) and a font size that is a good fit for each layout. For my purposes, I chose the following scenarios.

Two fixed widths, drawn from current statistics of browser resolutions in use at the time of this article, then a fluid layout that would lend itself to the mercy of the user's particular resolution. For an added challenge, I wanted to include a layout optimized for mobile devices as well. While my mobile version does not necessarily follow convention (e.g. the use of an "m" subdomain), I draw an assumption that the site is far less complex in its functional requirements and content types than might be more realistic.(For the record, bulletproofpixels.com uses this simplified strategy due to the simplicity and small quantity of its content.) The particulars of each of these scenarios are:

• Accessibility Level 1 - Content width fluid based on a resolution higher than 1024x768 (57%)
• Accessibility Level 2 - Content width of 1024 pixels based on a 1024x768 resolution (appx 36%)
• Accessibility Level 3 - Content width of 800 pixels based on an 800x600 resolution (appx 4% - I group all laptop resolutions in this area bacause I believe there is a trend toward more and more people having either both a desktop system and a laptop, or only a laptop due to their versatility)
• Mobile Version - Content width fluid with content layout optimized for viewports down to 233 pixels in width

The transition from one layout to another is accomplished by simply changing the class name on the body tag. I set up dependencies in the CSS to switch the appropriate declaration values for each scenario. Because the class name switching is accomplished using JavaScript (jQuery to be exact), there were a couple of additional dependencies I had to create to make sure the page is fully functional without JavaScript enabled and also avoid presenting content that is useless without it. For this demonstration this includes the left column expandable link list arrows and the accessibility bar itself. In regard to this and the fact that, without JavaScript enabled, the user may not select another layout, the default layout can be adjusted in the body tag class attribute to accommodate your particular user-base needs. One could also provide a server side solution as well that can be removed by JavaScript (allowing a more robust solution to maintain the functionality all around).

With CSS disabled, the user will get the raw content in a "naked" UI. For optimization in this scenario, the source is ordered such that the user will get the primary navigation, the main content, then the ancillary (left column) navigation and content (in that order). One caveat I left in my demonstration page is that with CSS disabled and JavaScript enabled, the user will still have the left column and accessibility controls available which do not function correctly. The fix for this is to construct these elements dynamically and add them to the DOM with JavaScript, but I did not want to take the time to write this code for this demonstration. In a real world application, however, I would highly recommend doing so.

One of the more interesting explorations was scaling the images on the page for each layout. While this may not always be either desired or practical, I could not resist adding this challenge to the mix. Except for the mobile verison, the masthead logo was left at a fixed size so its scaling would not rob the primary content of real estate in the view port. The only other images on the page include the small arrow bullets in the left column, which are functional, and the Coca Cola advertisement in the left column. I felt the arrows were important to scale because they are not only visual cues but are also independently functional. If a user has a need for enlarged content, it should be assumed that increasing the size of small functional elements would also be helpful i.e. and accessibility issue to address.

Also, before I forget, I should mention how I achieved the equal height, properly scaling left and right columns (in particular the background color of the left column. Since the column widths are percentage-based relative to the width of the parent container, all I had to do was (rather arbitrarily) come up with a possible maximum width I would expect the page to ever be viewed in (3200 pixels wide won). Next I created a background image (to be repeated on the Y axis) divided by the same percentages as the column widths. I then set its positioning to the same "left" position as the left column. Voila - instant equal-height, non-content-dependent columns.

Keep in mind that what I present here is in some ways math-intensive (everything is percentage based) and requires some amount of gradual tweaking to get things "just right". To accomplish a similar strategy successfully, there should be a lot of up front thought and planning. I suspect it would be near impossible to retrofit an existing site with these features.

The most fun here was the unanticipated (though it should have been) effect of scaling the cola ad. It's width is set in the CSS (the width and height image tag attributes were not used, which in reality is a usability issue related to performance - if there are a lot of images on the page, this strategy is probably not a good idea) as a percentage of the parent container. If you have the browser expanded to the width of your monitor and select mobile, the results are interesting. Shrinking the width of the view port to its intended size for the mobile setting adjusts the image accordingly of course.

You may view all of the supporting CSS and jQuery in the head of the demonstration document. I hope this post has been enlightening and inspires further improvements to these ideas. Thanks for reading.