Tags: nav

46

sparkline

Meet swup

This looks like a handy library for managing page transitions on sites that are not single page apps.

Here’s the code.

I’ve said it before and I’ll say it again, but I really think that this handles 80% of the justification for using a single page app architecture.

page-transitions-travelapp

A demo of page transition animations by Sarah—she’s written about how she did it. I really like it as an example of progressive enhancement: you can navigate around the site just fine, but with JavaScript you get the smooth transitions as a bonus.

All of this reminds me of Jake’s proposal for navigation transitions in the browser. I honestly think this would solve 80% of the use-cases for single page apps.

Focusing on Focus Styles | CSS-Tricks

A deep dive into the :focus pseudo-class and why it’s important.

A Tale of Two Rooms: Understanding screen reader navigation | The Paciello Group

A nice analogy to help explain what it’s like to navigate with a screen reader—and how much well-structured markup can help make it easier.

Improving the Accessibility of 24 ways | CSS-Tricks

Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.

Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.

Creating accessible menus-Part 1

James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.

jakearchibald/navigation-transitions

I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.

Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.

How much storage space is my Progressive Web App using? | Dean Hume

You can use navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.

Progressively Worse Apps

This article makes a good point about client-rendered pages:

Asynchronously loaded page elements shift click targets, resulting in a usability nightmare.

…but this has nothing, absolutely nothing to do with progressive web apps.

More fuel for the fire of evidence that far too many people think that progressive web apps and single page apps are one and the same.

Sticky headers

A three-part series by Remy looking at one interface pattern (a sticky header) and how his code evolved and changed:

  1. Sticky headers
  2. Smooth scroll & sticky navigation
  3. CSS sticky nav & smooth scroll

Using the aria-current attribute – Tink

The aria-current attribute is very handy and easy to implement. Léonie explains it really well here.

CSS Mega Dropdown | CodyHouse

I’m no fan of mega menus, and if a site were being designed from scratch, I’d do everything I could to avoid them, but on some existing projects they’re an unavoidable necessity (the design equivalent of technical debt). In those situations, this looks like a really nice, responsive approach.

The Future of Browser History — Free Code Camp

I’ve been thinking about this a lot lately. It feels like a user’s browser history is an incredibly rich seam of valuable information just waiting to be presented in a more interesting way.

Completely CSS: Progressively Collapsing Navigation | Kenan Yusuf

One way of implementing the growing/shrinking navigation pattern—an alternative to just shoving everything behind a hamburger icon.

turbolinks/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

During rendering, Turbolinks replaces the current body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, persist from one rendering to the next.

Here’s the mustard it’s cutting:

It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.

This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.

A couple of alternatives to the hamburger menu | Kenan Yusuf

Two (similar) patterns for responsive navigation that don’t involve sweeping everything behind a hamburger icon.

When I’ve experimented with auto-overflowing horizontal patterns like this, I’ve found that a judiciously-placed box shadow can give a nice affordance.

Temporary Constellations — Buckley Williams

This is a really lovely project by Dan and Nat—Christmas cards featuring the fleeting invisible constellations formed by the mesh of GPS satellites within which our planet lies.

Histography - Timeline of History

A nice navigable timeline of historical events from Wikipedia.

The Hamburger Menu Doesn’t Work - Deep Design

Building on Luke’s research, James outlines the problems with hiding navigation behind a hamburger icon. So, to be clear, the problem isn’t with the icon, so much as the way it is used as a cupboard to shovel all our messy navigation issues into.

Thoughts on Pagination

I’ve been thinking about this a lot lately; alternate ways of paginating through the past e.g. by day instead of by arbitrary amount.