Saturday, May 31, 2014

So You Think You’ve Built a Good Infinite Scroll

Animated GIF showing mouse and keyboard scrolling efforts with infinite scroll on Pew Research site.
So you’re saying there’s a chance … that I’ll make it to the footer.

Last week Derek Featherstone posted Automatic infinite scrolling and accessibility, a quick rundown of why having your page just keep going without user input to do so can be such a hassle for users. Also, don’t do it.

In the comments someone trotted out an example of his own automatic infinite scroll that he felt was effective and was developed with the user in mind. I got a bit ranty and suggested otherwise. That wasn’t as productive as it could be, partly because I was commenting on one example that other developers might feel doesn’t apply to their own efforts at similar implementations.

I think maybe this could all be made a bit easier by offering a quick checklist of what to test, expect, and review if you attempt your own version of an automatic infinite scroll. Here is my attempt at one, but please feel free to suggest others (or corrections) in the comments below.

1. Can the user hit “back” and return to the exact same place?

There’s nothing quite so infuriating as loading a few screenfuls of content, following a link, and then coming back only to find you have to reload those screenfuls of content all over again. Not only is it a waste of time, it’s a waste of bandwidth.

2. Is there paging for when the JavaScript breaks?

Everybody surfs without JavaScript while the page is loading, and that load time can be extended by network lag. In addition, broken third-party scripts can take down your own script. Can the user still get past page one if the JavaScript has fallen down?

3. Does the page have a footer?

Now you’re just being a tease. The user will never get there, so don’t lie by showing the footer and implying he or she can get there. You might as well just remove it. It’s at least honest.

4. Can a keyboard user access all other content on the page?

Unless the content that keeps updating is (or contains) the last focus-able element in the source order (the linearized version of your page), then a keyboard user (as well as screen reader users) will never be able to get to that content. Just like the footer you might as well remove it altogether.

5. Can you share a URL to a specific place on the page?

After you’ve gone a few screenfuls deep you may have found a few links of interest. Can you copy the address from the browser and email it (or even tweet it) and expect the recipient will come to exact state of the page (a few screenfuls in and with that content visible in the viewport)? Remember, an anchor is useless if it hasn’t loaded yet (or has been co-opted by your script).

6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?

Consider a list of news. After a couple screenfuls you might glean that each screen loads a week (or a month or whatever time period). You want content from a few weeks ago (or a few time periods ago). In a traditional paged navigation you could jump ahead a few screens to more quickly get further down the timeline. If your approach doesn’t afford users this control, you’re wasting your users’ time and bandwidth.

7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”

Keep your favorite memory monitoring tool open and load a few screenfuls. Then a few more. Then perhaps all. Take a look at how much memory this requires and then compare to available memory on other devices (such as smart phones). Remember that a mobile browser may reclaim memory by dumping other resources from working memory, potentially purging the rest of your site and its assets from the user’s cache, resulting in more bandwidth overhead and longer download times on subsequent pages.

8. Is there a way to disable automatic infinite scrolling and lean on standard paging?

Can the user easily disable the infinite scroll? Forget browser configuration acrobatics, instead look for a very visible single-click/tap option for the user to disable infinite scrolling and move on.

9. Have you conducted any user tests?

Before you roll this out, make sure some real users sit down in front of it. Nobody from your organization. Nobody who is an IT professional, developer, or whose paycheck depends on making you or your boss happy.

10. Are you satisfying a use case that has come from research or user request?

Did this feature request come from users, or the client? Or your boss? Or your desire to flex your scripting muscles? If you don’t have a compelling use case or feature request to add it, you may want to put your efforts toward features that truly have value, like print styles.

11. Do you have any analytics/tracking to measure success?

If you do decide to launch your perfect automatic infinite scroll feature, don’t forget to put some tracking scripts in place to determine how many screens deep your users go, and how often they click. There are other things you can measure (like if the footer ever gets clicks on that page). After all, success isn’t measured by you launching, but by whether or not it works well.

Update: July 14, 2014

Update: November 11, 2014

I left this list as a comment on the SitePoint article The UX of Infinite Scroll: The Good, the Bad, and the Maybe. Mostly because there is no good. There is only bad.

Update: February 13, 2015

Another post that proclaims the benefits of infinite scroll, with nothing at all to back them up: Infinite Scrolling: Pros and Cons It does list some issues, but it's a woefully short list.

Thursday, May 22, 2014

HTML5 Developer Conference Slides: Selfish Accessibility

2014 HTML5 Developer Conference

Today I had the pleasure of speaking at the HTML5 Developer Conference in lovely San Francisco. I presented on accessibility and how it relates to you as a current and future user with my presentation Selfish Accessibility. The full abstract:

We can all pretend that we're helping others by making web sites accessible, but we are really making the web better for our future selves. Learn some fundamentals of web accessibility and how it can benefit you (whether future you from aging or you after something else limits your abilities). We'll review simple testing techniques, basic features and enhancements, coming trends, and where to get help. This isn't intended to be a deep dive into ARIA, but more of an overall primer for those who aren't sure where to start nor how it helps them.

After submitting a couple drafts, and then some furious last-minute editing as some of the specs I referenced were tweaked a bit, I managed to squeeze out 89 slides in ~50 minutes. The slides are embedded below. There will likely be a video of the talk coming on the official site later, though I think they started the camera late.

Quick links to two items I referenced in Q&A after my talk:

If you attended, thanks! Whether or not you did, make sure to grab the links throughout as well as on the references slides scattered throughout (though mostly at the end).

Update: August 6, 2014

Good news everybody! The video for my talk was just posted at the HTML5 Developer Conference channel on YouTube. For your convenience, I have also embedded it below.

Friday, May 2, 2014

On Hiding URLs in the Browser

This image is stolen directly from Allen Pike's post because I don't have time yet to make a proper one. It shows the same page URL as seen in the address bars of Firefox 29 and Chrome Canary 36.0.1951.

Two days ago news broke that Chrome was going to modify the address bar in the browser to hide a page's URL. Web developers reacted pretty swiftly saying it's a bad idea. The first one I saw was Allen Pike's Burying the URL, and then a thread on Hacker News.

My first reaction is that this is a terrible idea, for all the points listed.

My second reaction is different.

I'm a web developer. I rely on seeing the URL every day not only as part of my job, but also to consume content and understand its value. I've been championing human-readable URLs for 20+ years and have railed against platforms that don't use them. Non-human-readable URLs are still valuable to me, though probably not the typical user.

Whether I want to hack a URL to remove the tracking nonsense appended by buff.ly-style shorteners, posit the date of a blog post when the author hides publish dates, or make sure I am looking at the development version of a site I am building instead of the staging or production URL (which is hilarious to get wrong while trying to debug an issue), I see a lot of value in URLs.

I realize that many (most?) other users aren't using URLs the way I do. Sure, I have trained my parents to look for certain things in a URL, but for the sites they frequent, which are often news sites with long strings of nonsense in the URL, there isn't much value for them.

So besides web developers, is this really hurting the typical web user? Is our general outcry based on anything other than a variation on "looks great in my browser?"

I posted a tweet this morning that is getting some retweet action, but I'm not sure that people understand that I am framing the issue from my perspective, not the average user's perspective. If anything, it belies how little I want to be family tech support. The tweet:

At the same time, Patrick Lauke was on his own tirade about how, as developers, we aren't really typical users. A couple points from the stream:

URLs have been getting masked, obfuscated, or hidden for some time now. My mobile phone hides a URL as soon as I scroll down the page. My browser doesn't show the HTTP protocol unless it's HTTPS. Opera Coast has gone a step further as it appifies the web experience.

Opera Coast has hidden URLs all along (as I note in my review), and while I don't know how that's mattered to typical users, it was enough to make me stop using it. While it is possible to get to the URL within Opera Coast, it's a bit more of a hassle than I like.

In the case of Chrome, it will be one click (which is one more click than I would like) to show the full URL as this video (embedded below) shared by Mark Harwood shows (sorry, only MP4 for now):

If the hidden URLs feature does make it into a coming release of Chrome, we as web developers can simply disable it with a Chrome flag: chrome://flags/#origin-chip-in-omnibox.

At this point, my resistance to the change is that I am a web developer who consumes URLs and that I don't want to have to re-train my parents how to send a link (without using some nonsense "share" button). I'd rather not see URLs go away, but I'm a professional, I can sort it out.

Unrelated

App Links you say? Don't get me started on App Links.

Update: May 4, 2014: Related

Jake Archibald has shared his opinion in his post Improving the URL bar. As is often the case in technical discussions, the comments have a lot of good back and forth.

Jeremy Keith has his own response post, the mispronounced-yet-whittily-named URLy warning.

Remy Sharp offers an alternative to the proposed URL hiding in hist post On Chrome hiding URLs to protect users from phishing. In short, he tries to tackle the stated reason behind Chrome's desire to hide URLs without hiding URLs.

Not really related, but interesting nonetheless is this post, The Secret Messages Inside Chinese URLs. The post is really talking about domain names on their own, but in the context of the page-level URL discussion I think it's novel.

Update: May 6, 2014

Opera 21 has come out, and among its release notes is this nugget on URLs in the address bar:

We now provide an option to make Opera persistently show a page’s complete URL in the address field.

[…]

For more technical users who need to quickly see the entire URL at a glance, go to “Settings | Advanced: Show always full URL in address field” to view all of that “important” information.

In addition, thanks to a re-start of the conversation on Twitter Jake Archibald has found a study that, while not exactly addressing the entire topic, does address it in part: Does Domain Highlighting Help People Identify Phishing Sites? The non-paywalled PDF file was found by Manu Sporny. Some notes:

Our research asks a basic question: how well does domain highlighting work? To answer this, we showed 22 participants 16 web pages typical of those targeted for phishing attacks, where participants had to determine the page’s legitimacy. […] We conclude that domain highlighting, while providing some benefit, cannot be relied upon as the sole method to prevent phishing attacks.

Now to change gears again, for those who claim that browsers have always shown the full URL, I present the following evidence that it's not quite true: Lynx 2.8.1 (one of the browsers I used daily back in the old days, not as a novel testing tool).

A screen shot of Lynx 2.8.1 viewing a page at CNN with no visible URL, as well as no obvious way to display it.

Update: May 13

A couple more interesting reads have popped up. One is a more in-depth and sweeping discussion from Jeremy Keith that builds on his original post and equates the removal of relatively small features with the long-term removal of control from users: Seams

The other one I missed during my first update to this post. Nicholas Zakas argues that URLs are already dead.