Snippets

Walking down an aisle in a library, I no more than glance at the vast majority of books shelved on either side of me. Only a madman would suggest that my disregard of these books should sanction their pages being torn out. Nonetheless, because research has shown that visitors don’t read the average Web page in full, and because the “success” of a page is more easily measured by user action than cognition, we are often encouraged to marginalize our writing in favor of visual signifiers or action cues.

Sure, most people will “bounce” your content, but if you really have something to say, don’t alienate the people who are willing to give your writing a chance. Good typography does justice to your words, and good wording does justice to your ideas. If readers are comfortable reading your type, then they will more likely be comfortable with what you are writing about.

One of the reasons I care so much about the web platform remaining open and accessible to new people who want to publish on and build things for the web is because of the route I took to get here.

As mentioned earlier, the W3C is celebrating their anniversary by inviting people to share stories of how they became involved in the web. In that spirit (and perhaps to encourage Smashing readers to share their stories), here is mine.

I had never intended to work with computers. I intended to become a dancer and singer, and I left school at 16 to go to dance college. My father is a programmer, however, so we were fairly unusual at the time as we had a computer in the house by 1985 when I was 10.

As a child, I liked typing in the code of “choose your own adventure” games, which appeared in books and magazines. I liked spotting the strings of text which would then show up in the game I would later play (usually, once my dad had fixed it up) on our Amstrad CPC464. I liked to visit the computer lab at Newcastle University, see the huge computers, and talk to the women who worked on them. Perhaps most importantly (and despite my arty interests), I never grew up thinking I couldn’t use computers. I just wasn’t especially interested.

[…]

Then I became pregnant with my daughter and had to leave the theatre. I was good at crewing and loved the theatre, but it was heavy and sometimes dangerous work with unsociable hours — not really a job for someone with a baby. I didn’t know what I would do, but I could type so I thought that perhaps I could type up essays for people. I was upsold to a computer — having gone into PC World looking for a wordprocessor. It was a Packard Bell 486 with a built-in 640×480 screen — a terrible machine that would allow me to either get the sound card working or the modem, but not both at once. I chose the modem and this is where my web story really begins. Even getting this modem working and getting the computer onto the Internet was something of a challenge and, once I did, I went looking for information about… babies.

I didn’t know anything about babies. All my friends were men who worked backstage in theatre. I had no support network, no family around me to help, and so I logged onto ParentsPlace and found people who didn’t mind my questions and were happy to help. At the time, there obviously was no Facebook. This meant that if you wanted to share photos and stories, you built a website. So among the forums about childbirth and toddler tantrums, there were people teaching each other HTML and sharing sets of graphics along with the code to place them. It was like typing out those “choose your own adventure” books again. I was amazed that I didn’t need anyone to fix my code — it just worked!

[…]

Before long, people would pay me to build them a website, and I felt that I should repay at least in some way for all of the questions I had asked. So, I started to answer questions in the forums. That was how it seemed to work. People would learn and move one step up the ladder, the new people would come in with the same questions and the people a step ahead would answer — all the while asking their own questions of those further along. I loved this. I could never have afforded lessons, but I had time. I could help others, and in return, people helped me.

[…]

I became interested in web standards essentially because it made no sense to me that we would have to build the same website twice — in order that it would work in both browsers.

For years, we studied teams rolling out new designs, to see if we could mitigate negative reaction to new releases and design changes. We studied hundreds of product and service rollouts. We watched and learned from the reactions of thousands of users.

When we dug into what those users’ reactions [were], patterns emerged. The users told us the changes inconvenienced them. They had no idea the change was coming and suddenly it was in their face. Users were upset because they were surprised.

They also told us the old version worked fine. Even when it took a while to get comfortable, they learned it. Many users mastered difficult-to-use designs.

Everything was different when the new version arrived. What they’d mastered before didn’t help them now. The company said it was an improved design, but they couldn’t see the improvements. Why should these users learn something new that doesn’t help them? Users were upset because they couldn’t see the value.

We also saw many instances where users didn’t react negatively to changes. Often, they didn’t react at all. We saw new designs that didn’t affect the users’ behaviors and they didn’t pay attention to it.

In these cases, the changes were often not noticeable. Sometimes the changes were small and isolated. Yet, we also saw users seemingly not notice several updates with extensive changes. (In more than one instance, an entire application’s infrastructure had been rewritten without a single user noticing.)

In cases when the design changes were noticeable, the designers gave the users control to switch when they wanted. The designers showed why the change was valuable to the users. And the designers made the transition easy by taking the knowledge and experience their users already had with the product into account.

RAIL is a user-centric performance model that breaks down the user’s experience into key actions. RAIL’s goals and guidelines aim to help developers and designers ensure a good user experience for each of these actions. By laying out a structure for thinking about performance, RAIL enables designers and developers to reliably target the work that has the highest impact on user experience.

Every web app has four distinct aspects to its life cycle, and performance fits into them in different ways:

Summary

RAIL is a lens for looking at a website’s user experience as a journey composed of distinct interactions. Understand how users perceive your site in order to set performance goals with the greatest impact on user experience.

• Focus on the user.
• Respond to user input in under 100ms.
• Produce a frame in under 10ms when animating or scrolling.
• Maximize main thread idle time.
• Load interactive content in under 5000ms.

FastDom works as a regulatory layer between your app/library and the DOM. By batching DOM access we avoid unnecessary document reflows and dramatically speed up layout performance.

Each measure/mutate job is added to a corresponding measure/mutate queue. The queues are emptied (reads, then writes) at the turn of the next frame using window.requestAnimationFrame.

FastDom aims to behave like a singleton across all modules in your app. When any module requires 'fastdom' they get the same instance back, meaning FastDom can harmonize DOM access app-wide.

Application lifecycle is a key way that modern operating systems manage resources. On Android, iOS, and recent Windows versions, apps can be started and stopped at any time by the OS. This allows these platforms to streamline and reallocate resources where they best benefit the user.

On the web, there has historically been no such lifecycle, and apps can be kept alive indefinitely. With large numbers of web pages running, critical system resources such as memory, CPU, battery, and network can be oversubscribed, leading to a bad end-user experience.

While the web platform has long had events that related to lifecycle states — like load, unload, and visibilitychange — these events only allow developers to respond to user-initiated lifecycle state changes. For the web to work reliably on low-powered devices (and be more resource conscious in general on all platforms) browsers need a way to proactively reclaim and re-allocate system resources.

In fact, browsers today already do take active measures to conserve resources for pages in background tabs, and many browsers (especially Chrome) would like to do a lot more of this — to lessen their overall resource footprint.

The problem is developers currently have no way to prepare for these types of system-initiated interventions or even know that they’re happening. This means browsers need to be conservative or risk breaking web pages.

The Page Lifecycle API attempts to solve this problem by:

• Introducing and standardizing the concept of lifecycle states on the web.
• Defining new, system-initiated states that allow browsers to limit the resources that can be consumed by hidden or inactive tabs.
• Creating new APIs and events that allow web developers to respond to transitions to and from these new system-initiated states.

This solution provides the predictability web developers need to build applications resilient to system interventions, and it allows browsers to more aggressively optimize system resources, ultimately benefiting all web users.

Attaching an event handler/listener to window or document’s beforeunload event prevents browsers from using in-memory page navigation caches, like Firefox’s Back-Forward cache or WebKit’s Page Cache.

Creates a new empty DocumentFragment into which DOM nodes can be added to build an offscreen DOM tree.

[…]

DocumentFragments are DOM Node objects which are never part of the main DOM tree. The usual use case is to create the document fragment, append elements to the document fragment and then append the document fragment to the DOM tree. In the DOM tree, the document fragment is replaced by all its children.

Since the document fragment is in memory and not part of the main DOM tree, appending children to it does not cause page reflow (computation of element’s position and geometry). Historically, using document fragments could result in better performance.