Using a Horizontal Web Site Layout

A friend recently wrote to me regarding an issue with Web site layout. Of course, I’ve dealt with Web design issues in a number of my booksmost notably C# Design and Development and Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. If you look at most Web sites today, they all have three serious problems:

 

  • The line length is too longforcing the eye to work extra hard to read the material because the eye loses track of the line and actually making it tiresome to review the material.
  • The page contains too much material, which makes it tiresome for anyone working with a screen reader to listen to all the material before finding the one bit of information actually required from the site.
  • The use of vertical scrolling is contrary to the historical use of horizontal scrolling. If you look at how people worked with scrolling in ages past, it was always horizontal, making it easier to read the material.

She even sent me two articles that describe the problem in greater detail. The first article is entitled, “Are Horizontal Website Layouts the Wave of the Future?” and points out that research shows that most people don’t even read the excess material on a Web site. If nothing else, the strong research showing that my efforts are being wasted would tend to make me rethink my design. The second article is entitled, “Horizontalism and Readability” and it places more emphasis on the historical approach to horizontal layout, rather than focus on modern research. I tend to prefer tested approaches to presenting information when I can get them (new ideas are fine for someone else to test).

Of course, a Web site is not the same as printed material. Trying to equate the two could very well be a mistake. Here is my take on how the mediums differ:

 

  • The method of presentation differs. You’re not relying on paper, you’re using a video screen of some sort and that does make a difference in how the reader perceives the material.
  • The environment differs. I don’t usually sit in my easy chair next to the fire when I read materials online. I’m normally in my office in a formal work environment.
  • The approach to reading differs. My paper reading environment is relaxed and long term. It’s nothing for me to spend an entire day reading a good book. My online reading is more like a sprintI find what I need quickly and never read for more than a half hour at a time.
  • The technology differs. When I read a book, I get print in one size. So, if the print is less than appealing or causes eye fatigue, I’m just stuck with it. My browser allows me to change the font size a Web site uses so I can make the print eye friendly. In fact, I can even use a CSS file to change the typeface and other features for some Web sites.

The obvious question now is whether the two environments differ enough that considerations normally made for paper don’t apply to Web sites. My thought is that creating Web sites with smaller amounts of material, eye friendly design, and shorter columns are all great ideas, but I’m not completely sold on the idea of horizontal scrolling. What is your take on this idea. Let me know at John@JohnMuellerBooks.com.

Inheriting Someone Else’s Code

In my book, “C# Design and Development,” I propose a lot of management techniques that could apply to any language. In fact, I’ve used the techniques in this book successfully for years with Visual Basic, C#, IronPython, C++, and PHP, among many others. The idea behind the concepts in this book is to create code that performs well from the outset and is easy to maintain when changes are required. In today’s environment, you can count on changes at some point. There are many reasons to expect changes:

 

  • The business is bought by someone else and the code must be integrated into a new system.
  • A change in some other component necessitates a change in the application (such as the changes in Vista and Windows 7 security).
  • The business has grown and now needs new features to support its customers.
  • Modifications in the law mean changes to the way the application interacts with data.
  • Technology changes in such a way that the application no longer works properly.

In fact, the reasons for change are endless. I could probably continue writing reasons for change for hours and not cover even a small number of them. The point is that applications will change at some pointit’s simply a matter of time.

If you’ve written code for any time at all, you know that feeling in the pit of your stomach when you discover the perfectly lucid comments you wrote at the time you created the application are no long lucid now. Worse still, the documentation you put together doesn’t tell you what you did and why. Still, after a few hours of looking at your comments and documentation, you can usually begin to fit the pieces together of an application you created because you can recreate the thought patterns you had when you designed and wrote it in the first place.

However, what happens when you’re part of a team or you’re working on an application that someone else designed? Now there isn’t any way to “get back into the groove” of what you did in the past. The thought processes are foreign, so the comments and documentation have to be as comprehensive as possible. Even with great comments and documentation, it’s going to take a while to get up and running with the code.

The longer it takes you to recreate the ideas that went into creating the code, the longer the project update languishes and the more extreme management’s position becomes. The only thing that management knows is that your application (the one you inherited from someone else) is costing the business money. Not only is there a cost associated with the update, but the delay costs the organization money too. Users who have to fight with an outdated application are always unhappy and aren’t productive. So, what techniques can you use to become productive as quickly as possible? That’s what I’d like to know as well. Obviously, reading the documentation and comments are two pieces to the puzzle, but what other techniques do you use?

I’m currently putting an article together that discusses this topic in detail and I’d like to hear about your techniques. If you’ve ever been frustrated by someone else’s code, write me at John@JohnMuellerBooks.com. I’ll let you know when the article is published on Software Quality Connection