Nutshell: make expandable explanations
Nicky Case has made an implementation of Ted Nelson’s StretchText that works across different domains.
Nicky Case has made an implementation of Ted Nelson’s StretchText that works across different domains.
Collection of common CSS mistakes, and how to fix them.
I like the way this is organised: it’s like “code smells” for CSS. Some of them will probably be familiar, in which case, you can dive in and find out what’s going on.
It is very disheartening to read misinformation like this:
A progressive web app is an enhanced version of a Single Page App (SPA) with a native app feel.
To quote from The Last Jedi, “Impressive. Everything you just said in that sentence is wrong.”
But once you get over that bit of misinformation at the start, the rest of this article is a good run-down of planning and building a progressive web app using one possible architectural choice—the app shell model. Other choices are available.
Tracy’s new book is excellent (and I had the great honour of writing a foreword for it).
Programmers, developers, marketers, and non-designers — want to become a better designer? This short book has everything you need.
The foreword to the self-published short book about design for non-designers.
Whenever I dipped my toe in the waters of the semantic web, I noticed there were two fundamentally different approaches. One approach was driven by the philosophy that absolutely everything in the universe should be theoretically describable. The other approach was far more lax, concentrating only on the popular use-cases: people, places, events, and that was pretty much it. These few common items, so the theory went, accounted for about 80% of actual usage in the real world. Trying to codify the remaining 20% would result in a disproportionate amount of effort.
I always liked that approach. I think it applies to a lot of endeavours. Coding, sketching, cooking—you can get up to speed on the bare essentials pretty quickly, and then spend a lifetime attaining mastery. But we don’t need to achieve mastery at every single thing we do. I’m quite happy to be just good enough at plenty of skills so that I can prioritise the things I really want to spend my time doing.
Perhaps web design isn’t a priority for you. Perhaps you’ve decided to double-down on programming. That doesn’t mean foregoing design completely. You can still design something pretty good …thanks to this book.
Tracy understands the fundamentals of web design so you don’t have to. She spent years learning, absorbing, and designing, and now she has very kindly distilled down the 80% of that knowledge that’s going to be the most useful to you.
Think of Hello Web Design as a book of cheat codes. It’s short, to the point, and tells you everything you need to know to be a perfectly competent web designer.
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 slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
Laurie Voss has written a thoughtful article called Web development has two flavors of graceful degradation in response to Nolan Lawson’s recent article. But I’m afraid I don’t agree with Laurie’s central premise:
…web app development and web site development are so different now that they probably shouldn’t be called the same thing anymore.
This is an idea I keep returning to, and each time I do, I find that it just isn’t that simple. There are very few web thangs that are purely interactive without any content, and there are also very few web thangs that are purely passive without any interaction. Instead, it’s a spectrum. Quite often, the position on that spectrum changes according to the needs of the user at any particular time—are Twitter and Flicker web sites while I’m viewing text and images, but then transmogrify into web apps the moment I want add, update, or delete a piece of text or an image?
In any case, the more interesting question than “is something a web site or a web app?” is the question “why?” Why does it matter? In my experience, the answer to that question generally comes down to the kind of architectural approach that a developer will take.
That’s exactly what Laurie dives into in his post. For web apps, use one architectural approach—for web sites, use a different architectural approach. To summarise:
I’m oversimplifying here, but the general idea is:
That’s sensible advice, but I’m worried that it could lead to a tautological definition of what constitutes a web app:
The underlying question of what makes something a web app is bypassed by the architectural considerations …but the architectural considerations should be based on that underlying question. Laurie says:
If you are developing an app, the user ideally loads the app exactly once — whether it’s over a slow connection or not.
But if you are developing a web site consisting of many discrete pages, the act of loading goes from a single event to the most common event.
I completely agree that the architectural approach of single page apps is better suited to some kinds of web thangs more than others. It’s a poor architectural choice for a content-based site like nasa.gov, for example. Progressive enhancement would make more sense there.
But I don’t think that the architectural choices need to be in opposition. It’s entirely possible to reconcile the two. It’s not always easy—and the further along that spectrum you are, the tougher it gets—but it’s doable. You can begin with progressive enhancement, and then build up to a single page app architecture for more capable browsers.
I think that’s going to get easier as frameworks adopt a more mixed approach. Almost all the major libraries are working on server-side rendering as a default. Ember is leading the way with FastBoot, and Angular Universal is following. Neither of them are doing it for reasons of progressive enhancement—they’re doing it for performance and SEO—but the upshot is that you can more easily build a web app that simultaneously uses progressive enhancement and a single-page app model.
I guess my point is that I don’t think we should get too locked into the idea of web apps and web sites requiring fundamentally different approaches, especially with the changes in the technologies we used to build them.
We’ve made the mistake in the past of framing problems as “either/or”, when in fact, the correct solution was “both!”:
We don’t have to choose. It might take more work, but we can have our web cake and eat it.
The false dichotomy that I’m most concerned about is the pernicious idea that offline functionality is somehow in opposition to progressive enhancement. Given the design of service workers, I find this proposition baffling.
This remark by Tom is the very definition of a false dichotomy:
Assumptions are the problem. Whether it’s assumptions about screen size, assumptions about being able-bodied, assumptions about network connectivity, or assumptions about browser capabilities, I don’t think any assumptions are a safe bet. Now you might quite reasonably say that we have to make some assumptions when we’re building on the web, and you’d be right. But I think we should still aim to keep them to a minimum.
Tom’s tweet included a screenshot of this part of Nolan’s article:
As Benedict Evans has noted, the next billion people who are poised to come online will be using the internet almost exclusively through smartphones. And if Google’s plans with Android One are any indication, then we have a fairly good idea of what kind of devices the “next billion” will be using:
- They’ll mostly be running Android.
- They’ll have decent specs (1GB RAM, quad-core processors).
- They’ll have an evergreen browser and WebView (Android 5+).
- What they won’t have, however, is a reliable internet connection.
That’s just one nit-picky example, but what I’m getting at here is that it really isn’t safe to make any assumptions. When we must make assumptions, let’s try to make them a last resort.
You don’t have to choose between progressive enhancement and a single page app/progressive web app/app shell/other things with the word “app”.
Progressive enhancement is an architectural approach to building on the web. You don’t have to use it, but please try to remember that it is your choice to make. You can choose to build a web app using progressive enhancement or not—there is nothing inherent in the nature of the thing you’re building that precludes progressive enhancement.
Personally, I find progressive enhancement a sensible way to counteract any assumptions I might inadvertently make. Progressive enhancement increases the chances that the web site (or web app) I’m building is resilient to the kind of scenarios that I never would’ve predicted or anticipated.
That’s why I choose to use progressive enhancement …and build progressive web apps.
Andrew picks out his favourite bits from this year’s Google I/O, covering web payments, CSS containment, and—of course—Service Workers and progressive web apps, although he does note (and I concur):
I wish Google would focus as much attention on ‘normal’ sites that perform navigations as they do on so called ‘app-shell’ (which is just a new name for single-page apps, as far as I can tell), but then many people will be building SPAs and these recipes will make those apps fly. In news publishing we seem to flip flop between traditional page navigations and SPAs, but I’ve never found a SPA news site (or a native app) that I really like more than a normal website. Maybe a really good progressive web app will change that. But I’m not convinced.
Still, as he says:
All this really just underscores how flexible ServiceWorker is and that with it we can disagree on what the right solution is, but we can all get what we want anyway.
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Do you want to know what the truth is about shrimps? They’re the idiots of the sea! One time I saw a shrimp just swim right into a rock.
Incredibly, you have to manually download and run this patch for Shellshock on OS X: it’s not being pushed as a security update.
But the new U2 album? That’s being pushed to everyone.
A nice little round-up of some techniques for dealing with trolls in online communities. I must remember some of this stuff for The Session.
An offhand remark I made on Twitter spurs Dom on to do a whole lotta research on character encoding in class names.