Skip to main content

The Responsive Web: Every Screen is Different

Visalia Direct: Virtual Valley
August 6, 2012 Deadline
September 2012 Issue

The Responsive Web: Every Screen is Different

Websites should be viewable and usable on as many devices and computer screen sizes as possible. That sounds obvious and simple, but designers know that it is increasingly difficult to anticipate how people might visit a website.

If you have a website for your business or organization, you should test it on a smartphone, a tablet, a laptop and a variety of computers with a mix of screen sizes. Testing a website on one computer with three or four browsers is insufficient, though that remains an important aspect of testing a website.

No longer do we sit at 800-by-600 or 1024-by-768 screens to explore the Web. As a designer, this is frustrating. As a smartphone owner, I’m thrilled I don’t need a computer to read news headlines or read book reviews.

I’ve always tried to design websites that work well for most users. Before 2006, I designed websites for myself and others using a table-based template that was 760 pixels wide. Then, I purchased a laptop with a 1440-by-900 pixel screen. My websites had more “margin” than content.

Like many designers, six years ago I adopted a fluid approach to website design using the emerging cascading style sheet (CSS) standard. A “fluid layout” means that columns of content were set to percentages of the screen width. If you have a wider screen or adjust the size of your browser window, the columns expand to fill the available space. The fluid layout approach is flexible, but a design that works well for most screens can be a visual disaster on narrow or extra-wide screens.

The arrival of CSS 2 permitted designers to stop using table-based designs, which were difficult to maintain. Tables were meant for tables of data, but in the early years of the Web they were the only way to create a design grid. With style sheets, it became possible to design a website with “division containers” that are far more flexible than tables.

Before CSS 2, you couldn’t set “maximum” and “minimum” design widths, so tables remained popular among designers. Using a maximum and minimum width allows a designer to restrict the size of containers within a fluid layout. Designers quickly embraced CSS 2.x to craft pages that looked great on screens from 800-pixels wide to 1920-pixels wide.

While the maximum and minimum settings help designers, this approach still assumes visitors to a website are using screens within a range of pixel widths.

I encourage you to visit a few websites and experiment by resizing the browser window. If your browser is full-screen, do the columns of text and images cover the full width of the window? If you reduce the browser to only a portion of the screen, how does the website change? Good websites should adjust when you change the browser window.

Still, a fluid layout using containers can have problems.

My wife’s monitor is wonderful if you want to edit two-page magazine spreads using InDesign. But some websites look strange on her screen. Text that appears as a nice visual paragraph on my laptop occupies a single line on her screen. This is a problem when a designer assumes he or she is wrapping text around photos or illustrations.

On the designer’s computer screen, the text and graphics might have resembled a great newspaper or magazine layout. But, the designer’s screen isn’t going to be the same as every screen a Web visitor might use. Personally, I find large screens to be the most challenging for an effective design. Like many designers, I limit maximum widths to 1800 pixels simply because wider widths make creating a pleasing layout difficult.

Small screens are a problem, too. Most people do not use the Web on high-resolution monitors, which is why it is still safe to limit widths. But, people love their small devices. My wife uses an iPhone and an iPad. These devices have small screens, with changing widths depending on how you hold the devices. Paragraphs can fill the screen. Think about your daily routine. Do you check various websites and services on your phone? A tablet? A small netbook computer?

If you are designing a website or paying a designer, you need to test for the reality that smartphones, tablets, laptops and desktop computers seem to have an infinite variety of screen sizes. If you consider big-screen televisions and other devices with Web access, the challenge is even more complex.

Your business or organization cannot afford to ignore the changing habits of Web surfers. Without at least a range of screen resolutions, what is a designer to do?

Thankfully, the CSS standard is evolving, along with the HyperText Markup Language (HTML). Today, HTML5 and CSS3 (notice there are no spaces) feature significantly improved design capabilities. Most Web designers are thrilled these standards have replaced HTML 4.01, XHTML 1.1 and CSS 2.1.

Enter the art of “responsive Web design” using HTML5 and CSS3.

Responsive Web design combines the power of grid-based design theory with aspects of fluid layouts. Blocks of content flow based on the screen width, while maintaining their own integrity. The variation permitted with CSS3 and HTML5 gives designers the ability to create websites that respond to the user, instead of forcing the website visitor to scroll wildly around to find information.

When you visit a responsive website, it works well on almost any screen or device. This is because the designer creates blocks based on the smallest screens, approximately 320 to 480 pixels wide. For narrow screens, blocks are “stacked” vertically. On a smartphone, the result is a long but readable screen you can navigate easily.

On larger screens, a row of blocks is aligned horizontally. After the screen width is reached, blocks start on the next row. Designers can also set maximum and minimum sizes for these blocks of content.

I encourage designers, and those paying website designers, to learn the basic concepts of responsive website design. There are many websites on the topic, naturally, and there are some good books. Use your favorite search engine to locate “CSS responsive Web design.”









Comments

Popular posts from this blog

MarsEdit and Blogging

MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail

Learning to Program

Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor

Learning to Code: Comments Count

I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.