Building Responsive Data Visualization for the Web. Bill Hinderman
Читать онлайн книгу.
suffered from web performance and connection problems similar to those of the early (~1996) stages of the consumer Internet.
Zakas continues, explaining that mobile devices have “high-latency connections, slower CPUs, and less memory” than their desktop counterparts. These devices have slower download request and response times, and need to account for the latency of wireless data transmission.
As a result, we, as developers and designers, must rethink web applications, which were previously geared toward these desktop experiences with wired connections, fast CPUs, and almost endless memory.
In terms of building apps for this evolving state of the web, you should keep several considerations in mind. The following sections describe not so much rules or limitations, but rather ergonomic “tent poles” that should guide and support how you craft the user’s web experience.
Let’s start with the most obvious: Phone screens are considerably smaller than computer monitors. Although it’s impossible to pick a standard mobile screen size, a good rule of thumb is to start supporting content around 320px (20em at 16px) wide, and grow upward as the content can support it.
Coupled with small screen size for any main content is the lack of real estate available for all the navigational tools we take for granted when using big screens.
Compared to a desktop screen, every scrollbar, notification, or menu that remains fixed on the page takes up a much higher percentage of total available space. As such, we must find new navigation patterns to smartly hide content while keeping it discoverable when necessary.
Mobile devices, when not connected to Wi-Fi, run on far inferior networks than their desktop older siblings. While these devices have improved and will continue to improve, we cannot assume parity between mobile and desktop browsing. As such, large images, heavy JavaScript libraries, or piles of content being forced onto the user will cause painful slowdowns.
People expect their web browsing to be fast. We have gotten used to the speed afforded us on broadband networks. In fact, Nielsen Norman Group research (www.nngroup.com/articles/response-times-3-important-limits/) has shown that:
1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
Google suggests that people expect websites to load in under two seconds (googlewebmastercentral.blogspot.com/2013/08/making-smartphone-sites-load-fast.html), and that site abandonment rates skyrocket as load times climb past this number. Speed is actually ranked as the number one reason for abandonment on e-commerce websites.
As an example: I live in Chicago, which is not a tiny city. Twice a day, during my commute, I have no Internet connection while I am underground. Despite this relatively short inconvenience, I regularly notice myself becoming very annoyed that I can’t refresh my tweets.
When data providers have faster networks, it’s safe to say that they will charge for them. Access and bandwidth charges (or overages) can be crippling, and, as with speed, every kB you add to your web experience has a tangible cost to the user.
Mobile browsers have gotten much more advanced in the past few years, and a large portion now run a version of Webkit – an open-source browser rendering engine. However, as with any web development, testing on a real device is the best way to determine support.
Finally, the physical environment of a mobile user is far less standardized than that of a desktop user. In the case of the latter, they are at a desk, or perhaps at a coffee shop, pretending to work on their manuscript.
Conversely, the mobile device user could be anywhere – at that same desk as the desktop user, trying to give directions to a cab driver, checking a map while mountain climbing, or looking up stock quotes while lying in bed.
To wit: When was the last time you went to the bathroom without your phone?
As you have seen in the preceding sections, there are a number of unique challenges in designing for the web. As more classes of device, more screen sizes, and more capabilities show up and disappear in devices, it’s up to you to decide just how much time and money your team is willing to put into optimization.
Take a breath, though. There is a whole slew of benefits unique to the mobile web. Just as the rise in devices has complicated our lives as designers and developers, it has also unlocked the Internet itself to a massive amount of consumers, and grown the medium into something far greater than the hypertext pages of 1990.
Let’s start with the obvious again: There are many more intuitive, built-in ways to interact with a smartphone than with a computer. Every way that you can touch, pinch, swipe, and tap a screen can be mapped to a different interaction, or behavior.
More important, these devices have been enabling more and more of their hardware to access browsers in recent years, including the camera, the microphone, accelerometers, and notification systems.
Internet-enabled mobile devices are also leaps and bounds cheaper than the total running cost of owning a desktop computer, broadband service, and a place to put said computer with said service.
To that point: In early 2012 I was doing research for a medical software company in rural India. In my two weeks there, I never saw a computer outside of the hotel or one of the hospitals that I visited. However, even in a farming village two hours outside of Chennai, I would have been hard-pressed to find anyone without some level of smartphone, and other members of the trip remarked that 2G service was everywhere.
Let’s now reconsider the mobile user’s context. We don’t know for certain where they are located. However, that’s not relevant to us.
We do know that they are using a device with a smaller screen (where real estate is scarce), somewhere between an edge cellular network and Wi-Fi, potentially dealing with bandwidth premiums. Building their experience, we can start to take all of these limitations as inputs to the user’s end goal. We know that they are on a specific website to do a specific task, and we have at our disposal a large variety of interaction and navigational tools with which to help them do that thing as quickly and efficiently as possible.
Who cares if they’re in the bathroom?
Mobile device users now represent the majority of all users. Those of us who work with data visualization sometimes assume that a large portion of our content can still be tailored to larger, more capable screens, but we do so at our own peril.
The visualizations we create and the web applications in which they live are now consumed on devices from 320px of width to massive 5120px-wide retina screens. Therefore, we have to ensure that our content is consumable on as many devices as possible.
Because it isn’t possible to service all of them, it’s important to identify the ones that matter most to your own subject. I encourage you to do some tracking of your own website’s most frequent user agent and screen resolution ranges. Focus on optimizing for 80 % of your user base, or even 50 %. It may be smaller than you assume.
Mobile Web Design
For years, web teams have designed and built for the desktop. Mobile, if considered, was an afterthought, or a port of the desktop version. The truth is, this made perfect sense for a long time – users weren’t yet there, browsing the web on mobile phones was painful, and carriers controlled access to the web on their devices. What’s more, network speeds were so abysmal at first that it was nearly impossible to