The web is so much bigger than the little boxes we try to put it in. The web is good at many things and not great (yet) at others. The web is a snowball rolling down hill, absorbing other technologies along the way. The web is an interactive window across space and time, a near instant connection to anyone on the planet. The web is something different. I wish we’d see the web more for itself, not defined by its nearest neighbor or navel-gazing over some hypothetical pathway we could have gone down decades ago.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
This is absolutely brilliant!
Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!
It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
The first 22 years of the web platform were revolutionary. The open, accessible, and feature-rich applications that exist on the platform continue to drive the global economy. The next 5 years look like they’ll be filled with more innovation and growth than ever.
The web will be the platform of the Next Big Thing. Not just as the distribution network many see it as today; the web platform will deliver the most innovative experiences. They’ll be innovative not just for how they use new technology, but also because of how easy it will be for new users to experience.
Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
- the “app shell” model is not the only—or even the best—way of building a progressive web app, and
- always, always, always render from the server first.
James gives—if you’ll pardon the pun— hands-on advice on making sites that consider motor impairment:
- Don’t assume keyboard access is all you need
- Auto complete/Autofill
- Show me my password
- Allow for fine motor control issues
- Don’t autoplay videos
- Avoid hover-only controls
- Infinite scrolling considerations
- Be mindful of touch
- Avoid small hit targets
- Provide alternate controls for touch gestures
Far from being a niche concern, visitors with some form of motor impairment likely make up a significant percentage of your users. I would encourage you to test your website or application with your less dominant hand. Is it still easy to use?
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.
Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) – Smashing Magazine
I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.
It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.
Ensure that your class names never go out of sync with your style declarations with this one simple trick:
Take any CSS rule you want to apply, replace : by -, and dots by -dot-, and you get the name of the corresponding universal css classname.
The only thing missing is immutability, so I would suggest also putting
!important after each declaration in the CSS. Voila! No more specificity battles.
Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.
Did I mention that it’s free?
Well, I’m convinced.
On universal design: “We’re reframing disability as an opportunity.”
One day someone will write a history of the Internet, in which that great series of tubes will emerge as one long chain of inventions not just geared to helping people connect in more ways, but rather, to help more and more types of people communicate just as nimbly as anyone else.
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
Scott writes an absolutely spot-on skewering of the idea that progressive enhancement means you’re going to spend your time catering to older browsers. The opposite is true.
Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.
A nice look at responsive design, progressive enhancement, and the principle of One Web.