Recently I had a client come back with a rather odd request to completely eliminate scrolling on every page of their freshly minted Web site. This is intriguing I thought. 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 in an old Web browser that hadn’t been updated in years. 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 the Apple Pro Display XDR, with a whopping 6016 by 3384 pixels (20.4 million pixels) at 218 pixels per inch (ppi) —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.
…
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.