Good design and lower latencies
I just met one of the engineering gurus who works behind the scenes at Google optimizing network operations that ultimately are responsible for the amazing performance millions of users assume when they do a Google search.
Search: “pizza” About 688,000,000 results (0.17 seconds) -Google.com
The Google engineers measure and refine minute operations in fractions of milliseconds across thousands of servers to achieve these stunningly low latencies. But is it really a big deal to receive my search for “pizza” in 0.17 seconds vs. waiting 0.5 seconds? Maybe not just once, but over the course of hundreds of searches that millions of others do per week around the world, it is a huge deal. In total these few milliseconds saved can account for hours, days, even years of productivity. Blazingly fast response times engendered by ranks of network engineering gurus are indeed a big reason why Google is number one in search.
But when it comes to interface design and page layout, the tech industry still tends to view the UI as a superficial skin, a bucket list item that “pretties up” the appearance of software functionality, like makeup on a supermodel.
Of course, there are many other engineering aspects behind Google that make it a great search engine, like the algorithm-driven quality of results, but for the sake of simplicity let’s compare this one aspect of engineering — performance at scale — to a single aspect of UI design — readability at scale — for the value each brings.
For example, I’ll refer to just one minute principle of good type design. It’s a scientifically validated fact that the optimal line length for text readability is 50 — 65 characters per line, including spaces. If a line of text is too long the reader’s eye will have a hard time focusing on the text. This is because the length makes it difficult to get an idea of where the line starts and ends. And it can be difficult to continue from the correct line in large blocks of text. If a line of text is too short, the eye will have to travel back too often, breaking the reader’s rhythm. Too short lines also sap readers’ energy, making them begin on the next line before finishing the current one (hence skipping potentially important words). Also, the human mind is energized when jumping to the next line (as long as it doesn’t happen too frequently). At the beginning of every new line the reader is focused, but this focus gradually wears off over the duration of the line (“Typographie”, E. Ruder). There are contextual variations on this rule, including for headlines and excepting pull-quotes or illustrations carved into graphs that actually encourage brief interruptions in order to contribute supplementary, often graphical, information to the point of an article. But is it really a big deal that each line of text I read on a Web product is an iota easier to consume because it is constrained to an optimal line length? Well, I read thousands of lines of text per week and there are billions of users reading billions of lines of text on the Web and mobile devices. Text readability and the hundreds of other aspects of human interface design result in a user experience with less latency and equal vast gains in productivity at scale.
So, the Google network guru and I are worlds apart in what we work on, but our goals are practically identical and the results are equally meaningful. Page design and human accessibility is a huge deal for performance and accessibility when considering human factors. Afterall, we humans are the subjects technology is designed to serve.
If you disagree, please evaluate my article here for readability compared with what you see on Google News’ or Wikipedia’s “liquid” layout. Then, repeat this a billion times or so to approximate a world of users doing the same thing.
Originally published at jsn.io on March 24, 2012.