Scrolling Through Time

Scrolling Through Time

Kim MacCormack Leesburg, Virginia, U.S.

TWElvE yEARS Ago, my team was hired to develop a web application as a subcontractor for a graphic design firm. We were to have no direct contact with the customer. All of the requirements were relayed by the client to our prime contractor, and then passed on to us in a series of random emails.
One email concerned the screen resolution our artists should use. The previ- ous standard had been 640×480, but more current research suggested that the web site should support up to an 800×600 resolution. (Today the most common screen resolution is 1,024×768.) Even though this was an experienced design firm, its formal requirements (which we never saw) to the customer stated:
The layout of each page will conform to a fixed 800-pixel width standard and 600-pixel height standard.
If we had seen this requirement, we would have immediately corrected the statement to read, “The layout of each page will conform to a fixed 800-pixel width standard, to support up to an 800×600 monitor resolution.” Since we had worked on many websites, we knew that the most important dimension was the width. Users hate scrolling horizontally, while vertical scrolling is con- sidered one of the realities, if not advantages, of using a browser. However, evidently this valuable truth was never conveyed to the customer.
The content this novice website customer provided for each web page was huge. As a result, very few pages could be completely viewed (lengthwise) on a 15-inch monitor set to an 800×600 resolution. One had to scroll vertically.

Not realizing we would have to be miracle workers to make this oversized content display on a single screen, the end-user customer got very upset. They blamed our prime contractor, the design shop. In return, the design shop refused to pay us. According to them, we “did not meet the requirements as written.”
From that experience, I have learned the danger of poorly constructed, writ- ten requirements and how they can be used against you. It is important to always document your assumptions and insist on reviewing and signing off on requirements with the end-user, not just with a middleman.
Fortunately, agile project management practices have alleviated some of these issues. By recognizing the importance of nose-to-nose interfaces between the developer and the real customer, we have evolved to collectively creating User Stories, and prioritizing features based on the business value they will provide to the customer, rather than requirements lists. A one- or two-week iteration process means we have early and frequent feedback, and the opportunity to clarify customer expectations.
Twelve years later, I have run into almost exactly the same situation with a client who is highly concerned about vertical scrolling, even though he wants large amounts of content on the page. Luckily, with the way we run projects today and the lessons I learned from my past experience, we resolved this issue quickly and set realistic customer expectations without the chaos of the past.