Recently I had a client come back with a rather odd request to completely eliminate page scrolling on every page of their freshly minted Web site. Please restrain yourself and resist the urge to burst into spontaneous uncontrollable laughter. This is 2013 right? Are they looking for an old school Flash site type of experience? Did I miss something during our design review? Not likely.

It’s easy to dismiss inquiries of this variety as random client eccentricities or just plain archaic thinking. Quite often though, the client’s device or software may be the culprit. In any case it’s important to find out more because an unhappy client is not a return client.

“Page fold” as it’s commonly referred is essentially the viewable content area users can see on their screen without having to scroll. Naturally this vertical footprint can vary significantly from one screen or device to the next.

In my client’s case it was learned they were reviewing their site on an old 1024-by-768 pixel screen in Internet Explorer 7, with perhaps 3 or 4 rows of browser tool bars and bookmarks (though I was unable to confirm the latter). It then became clear why they were asking for their site to be “resized”, a rather drastic measure considering we had just finished developing the first iteration of their staging site.

Page fold has long reared its semi-ugly head in the digital design process. If anything, with the growing variety of devices and screen sizes available today this issue isn’t going away anytime soon. Consider for a moment the opposite end of this equation: a client reviewing their new Web site on an Apple Thunderbolt display, a whopping 2560-by-1440 resolution. What then?

A designer’s best course of action in dealing with issues of this nature is to find out exactly what the client is looking at their site on. That is, screen resolution, browser, OS —gather as much information as possible. Then explain the prevalence of other screen sizes and how you naturally designed their site to accommodate the widest possible audience and followed best practices with regard to UI, UX, and visual design. If necessary, cite screen resolution statistics to provide further context. Most clients will appreciate it if you take the time to explain the rationale for such decisions made throughout the design and development process.

Digital design professionals should take these matters quite seriously and feel obligated to help guide and educate clients on the established design principles that have become inherent conventions of the Web experience.

No, this ‘eliminate-page-scrolling-thing’ isn’t the most bizarre request to come across my plate of late.

Let’s talk about the scourge of PDFs.

Clients reviewing design comps in Adobe Acrobat Reader—yes, multi-page PDFs are convenient—is probably more of a revision inducing liability than most digital designers would let on. Acrobat and browser-based PDF readers like the one in Chrome and Firefox tend to display PDFs at scaled sizes. By scaled I mean design mock-ups may be displayed above or below their actual size (1:1 pixels), for instance 66.7% of the original comp size.

Obviously this scenario obscures design feedback from the client and opens the door for comments resembling: “the text and navigation are too small” (or too big), “the images are too big” (or too small), and the pièce de résistance: “the logo is too small” (funny, rarely do clients ever complain their logo is too big —but that’s another story).
These are design revisions that arguably could have been avoided had the client been given the opportunity to review their site design comps directly in their Web browser without Acrobat or a similar image preview application arbitrarily distorting the comps.
In short, much grief can be avoided by employing a simple HTML-based viewer located somewhere on your Web server.

…

I’ll leave you with one final design quandary to consider.

A client recently came back expressing “colour” discrepancy concerns with their newly launched Web site. Keep in mind this client had signed-off on the look and feel design comps several weeks prior.
As it turns out, this client was printing-off Web pages, in colour, presumably from their $99 office ink-jet printer (make and model, it doesn’t really matter) citing gross colour discrepancies between the original design comps they had signed-off on and what they were now seeing on paper.

Maybe cyan ink cartridge #2 was down that particular day. Maybe the printer heads were clogged and needed cleaning. Maybe the paper itself was an insufficient weight ill suited for colour graphics printing. Maybe the client’s printer software was configured to draft or ink economy mode.

Regardless, the question you might be asking is: why print out Web pages on paper in the first place? Yes, incredibly, people still do that. Yes, a print-optimized CSS can help alleviate layout problems or unnecessary ink usage on paper, but why not just refrain from printing and save a tree or two in the process. A cheap tablet computer makes the paperless-office-of-the-future a reality and will probably cost less than a typical office printer (long term) when considering the ongoing costs associated with ink refills and paper stock.