You're Offline
You're Offline
A
truly responsive website should adapt to all kinds of situations.
Besides different viewport sizes, there are other factors to consider. A
change in connectivity is one of them.
Earlier this week, I was
sitting in a train on my way to speak at a local meetup. InterCity
trains in Austria all have WIFI now, so I was doing some last-minute
work on my slides online. Train WIFI being what it is though, the
network wasn’t exactly reliable. The connection kept dropping everytime
we went through a tunnel or too many passengers were logged on.This is quite a common scenario. People are on the move, network coverage can be poor, internet connections fail. Luckily, we can prepare our websites for this and make them more resilient by building them offline-first.
Offline support is awesome, however your users might not be aware of these capabilites - and they shouldn’t have to be. In some cases they might not even know that they’ve gone offline. That’s why it’s important to communicate what’s going on.
Chances are not every part of your site will work offline. Certain things may not be cached, others may require server interaction. This is fine of course, but the interface should reflect that. Just like a responsive layout adapts to changes in viewport size, your offline-optimized site should adapt to changes in connectivity.
Checking for Offline
The key ingredients here are theoffline event and the navigator.onLine property. By combining them, we can check for network changes and react accordingly.Here’s an example of a simple connectivity check:
let isOffline = false;
window.addEventListener('load', checkConnectivity);
// when the page has finished loading,
// listen for future changes in connection
function checkConnectivity() {
updateStatus();
window.addEventListener('online', updateStatus);
window.addEventListener('offline', updateStatus);
}
// check if we're online, set a class on <html> if not
function updateStatus() {
if (typeof navigator.onLine !== 'undefined'){
isOffline = !navigator.onLine;
document.documentElement.classList.toggle('is-offline', isOffline);
...
}
}
online
event, there’s a slight possibility of false positives: A user might be
connected to a network (which is interpreted as being online), but
something higher up might block actual internet access. The offline event is a bit more reliable, in the sense that an “offline” user can be expected NOT to have access.Get Notified
Now we want to display some kind of notification to offline users, so they know what’s going on. This can be done in a number of ways; however I would recommend usingaria-live regions to make it accessible and have screen readers announce the connection change as well.Using such a notification bar is pretty straightforward. First, define an element to display messages on your page:
<!-- notification container -->
<div
class="notification"
id="notification"
aria-live="assertive"
aria-relevant="text"
hidden
></div>
aria-live
attribute tells screen readers to announce changes to this element.
“assertive” means it will interrupt whatever it is currently announcing
at the time and prioritize the new message. The aria-relevant tells it to listen for changes in the text content of the element.You can extend the handler function from before to populate the notification area whenever you detect that a user has gone offline:
function updateStatus() {
...
const notification = document.querySelector('#notification');
if (isOffline) {
notification.textContent = 'You appear to be offline right now.';
notification.removeAttribute('hidden');
} else {
notification.textContent = '';
notification.addAttribute('hidden');
}
}
If you’re reading this on my site, you can see a version of these notifications in action if you simply switch off your WIFI for a second. Go ahead, I’ll wait.
If you’re somewhere else or your browser doesn’t support service worker / offline events, here’s how this could look:
Telling the User what’s available
Notifications are a good start, but it would be even nicer if we could give the user some visual indication of which parts they can actually use offline, and which not.To do this, we can loop over all the links on page load and check their
href against the cache. If they point to a cached resource (e.g. will work offline), they get a special class.const links = document.querySelectorAll('a[href]');
Array.from(links).forEach((link) => {
caches.match(link.href, { ignoreSearch: true }).then((response) => {
if (response) {
link.classList.add('is-cached');
}
});
});
offline
event fires, we toggle a class on the body and visually disable all
links that aren’t cached. This should only apply to URLs, so we can
ignore tel:, mailto: and anchor links..is-offline {
/* disable all links to uncached pages */
a:not(.is-cached) {
cursor:not-allowed;
pointer-events: none;
opacity:.5;
}
/* ignore anchors, email and phone links */
a[href^="#"],
a[href^="mailto"],
a[href^="tel"] {
cursor:auto;
pointer-events: auto;
opacity:1;
}
}
Offline Forms
Another way we might use this is to prevent users from filling out forms. Most forms pass data to the server and require a connection to work, so they won’t be very useful when offline.What’s worse is that users might not know there is a problem until it’s too late: imagine filling out a lengthy form and finally hitting the submit button, only to find a network connection error page and all your inputs gone. That’s frustrating.
/* Disable Forms when offline */
.is-offline form {
position:relative;
opacity:.65;
cursor:not-allowed;
pointer-events:none;
&::after {
content: 'Sorry, you\'re offline.';
display:block;
position:absolute;
top:50%;
left:50%;
transform:translate(-50%, -50%);
color:#FFFFFF;
background-color:#2D2D2D;
padding:1rem 2rem;
}
}
If you’re doing this, remember to suppress “submit on enter” as well, and make sure the user knows why submitting won’t work at the moment.
Further Reading
- Intro: OfflineFirst.org
- Google Developers: Offline Storage
- Jake Archibald at I/O 2016: Building offline-first PWAs (Video)
评论
发表评论