Tags: website



Progressing the web

Frances has written up some of the history behind her minting of the term “progressive web app”. She points out that accuracy is secondary to marketing:

I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer.

Personally, I think “progressive web app” is a pretty good phrase—two out of three words in it are spot on. I really like the word “progressive”, with its echoes of progressive enhancement. I really, really like the word “web”. But, yeah, I’m one of those smart-asses who points out that the “app” part isn’t great.

That’s not just me being a pedant (or, it’s not only me being a pedant). I’ve seen people who were genuinely put off investigating the technologies behind progressive web apps because of the naming.

Here’s an article with the spot-on title Progressive Web Apps — The Next Step In Responsive Web Design:

Late last week, Smashing Magazine, one of the largest and most influential online publications for web design, posted on Facebook that their website was “now running as a Progressive Web App.”

Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop (complicated stuff), right? I scrolled on and went about my day.

And here’s someone feeling the cognitive dissonance of turning a website into a progressive web app, even though that’s exactly the right thing to do:

My personal website is a collection of static HTML files and is also a progressive web app. Transforming it into a progressive web app felt a bit weird in the beginning because it’s not an actual application but I wanted to be one of the cool kids, and PWAs still offer a lot of additional improvements.

Still, it could well be that these are the exceptions and that most people are not being discouraged by the “app” phrasing. I certainly hope that there aren’t more people out there thinking “well, progressive web apps aren’t for me because I’m building a content site.”

In short, the name might not be perfect but it’s pretty damn good.

What I find more troubling is the grouping of unrelated technologies under the “progressive web app” banner. If Google devrel events were anything to go by, you’d be forgiven for thinking that progressive web apps have something to do with AMP or Polymer (they don’t). One of the great things about progressive web apps is that they are agnostic to tech stacks. Still, I totally get why Googlers would want to use the opportunity to point to their other projects.

Far more troubling is the entanglement of the term “progressive web app” with the architectural choice of “single page app”. I’m not the only one who’s worried about this.

Here’s the most egregious example: an article on Hacker Noon called Before You Build a PWA You Need a SPA.

No! Not true! Literally any website can be a progressive web app:

That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Alas, I think that many of the initial poster-children for progressive web apps gave the impression that you had to make a completely separate app/site at a different URL. It was like a return to the bad old days of m. sites for mobile. The Washington Post’s progressive web app (currently offline) went so far as to turn away traffic from the “wrong” browsers. This is despite the fact that the very first item in the list of criteria for a progressive web app is:

Responsive: to fit any form factor

Now, I absolutely understand that the immediate priority is to demonstrate that a progressive web app can compete with a native mobile app in terms of features (and trounce it in terms of installation friction). But I’m worried that in our rush to match what native apps can do, we may end up ditching the very features that make the web a universally-accessible medium. Killing URLs simply because native apps don’t have URLs is a classic example of throwing the baby out with the bath water:

Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.

If the goal of the web is just to compete with native, then we’ve set the bar way too low.

So if you’ve been wary of investing the technologies behind progressive web apps because you’re “just” building a website, please try to see past the name. As Frances says:

It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname.

Literally any website can—and should—be a progressive web app. Don’t let anyone tell you otherwise.

I was at an event last year where I heard Chris Heilmann say that you shouldn’t make your blog into a progressive web app. I couldn’t believe what I was hearing. He repeats that message in this video chat:

When somebody, for example, turns their blog into a PWA, I don’t see the point. I don’t want to have that icon on my homepage. This doesn’t make any sense to me.

Excuse me!? Just because you don’t want to have someone’s icon on your home screen, that person shouldn’t be using state-of-the-art technologies!? Excuse my French, but Fuck. That. Shit!

Our imaginations have become so limited by what native mobile apps currently do that we can’t see past merely imitating the status quo like a sad cargo cult.

I don’t want the web to equal native; I want the web to surpass it. I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!

Like Frances says:

Remember, this is for everyone.

Starting out

I had a really enjoyable time at Codebar Brighton last week, not least because Morty came along.

I particularly enjoy teaching people who have zero previous experience of making a web page. There’s something about explaining HTML and CSS from first principles that appeals to me. I especially love it when people ask lots of questions. “What does this element do?”, “Why do some elements have closing tags and others don’t?”, “Why is it textarea and not input type="textarea"?” The answer usually involves me going down a rabbit-hole of web archeology, so I’m in my happy place.

But there’s only so much time at Codebar each week, so it’s nice to be able to point people to other resources that they can peruse at their leisure. It turns out that’s it’s actually kind of tricky to find resources at that level. There are lots of great articles and tutorials out there for professional web developers—Smashing Magazine, A List Apart, CSS Tricks, etc.—but no so much for complete beginners.

Here are some of the resources I’ve found:

  • MarkSheet by Jeremy Thomas is a free HTML and CSS tutorial. It starts with an explanation of the internet, then the World Wide Web, and then web browsers, before diving into HTML syntax. Jeremy is the same guy who recently made CSS Reference.
  • Learn to Code HTML & CSS by Shay Howe is another free online book. You can buy a paper copy too. It’s filled with good, clear explanations.
  • Zero to Hero Coding by Vera Deák is an ongoing series. She’s starting out on her career as a front-end developer, so her perspective is particularly valuable.

If I find any more handy resources, I’ll link to them and tag them with “learning”.

Brighton Homebrew Website Club

I really enjoyed the most recent Indie Web Camp in Brighton. Some of us were discussing at the event how it’s a shame that it only happens once or twice year, considering how much everyone manages to accomplish at each one.

Well, to help keep the momentum going, Charlotte and I are going to start running a Homebrew Website Club meetup here in Brighton. It’ll take place every second Wednesday in the auditorium—or, if that’s not available, the Clearleft office—here at 68 Middle Street from 6:30pm to 7:30pm (although myself and Charlotte will be there from 6pm so feel free to show up early).

There’s no set agenda to these meetups. Simply put, it’s a chance to work on your personal site or side project while in the company of either people doing the same thing. We can help each other out, or just have a chance to chat and compare notes, very much in the spirit of the original Homebrew Computer Club …but applied to your own website.

The first Brighton Homebrew Website Club meetup is on Wednesday, August 12th. It would be lovely to see you there.

Defining the damn thang

Chris recently documented the results from his survey which asked:

Is it useful to distinguish between “web apps” and “web sites”?

His conclusion:

There is just nothing but questions, exemptions, and gray area.

This is something I wrote about a while back:

Like obscenity and brunch, web apps can be described but not defined.

The results of Chris’s poll are telling. The majority of people believe there is a difference between sites and apps …but nobody can agree on what it is. The comments make for interesting reading too. The more people chime in an attempt to define exactly what a “web app” is, the more it proves the point that the the term “web app” isn’t a useful word (in the sense that useful words should have an agreed-upon meaning).

Tyler Sticka makes a good point:

By this definition, web apps are just a subset of websites.

I like that. It avoids the false dichotomy that a product is either a site or an app.

But although it seems that the term “web app” can’t be defined, there are a lot of really smart people who still think it has some value.

I think Cennydd is right. I think the differences exist …but I also think we’re looking for those differences at the wrong scale. Rather than describing an entire product as either a website or an web app, I think it makes much more sense to distinguish between patterns.

Let’s take those two modifiers—behavioural and informational. But let’s apply them at the pattern level.

The “get stuff” sites that Jake describes will have a lot of informational patterns: how best to present a flow of text for reading, for example. Typography, contrast, whitespace; all of those attributes are important for an informational pattern.

The “do stuff” sites will probably have a lot of behavioural patterns: entering information or performing an action. Feedback, animation, speed; these are some of the possible attributes of a behavioural pattern.

But just about every product out there on the web contains a combination of both types of pattern. Like I said:

Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

Now you could make an arbitrary decision that any product with more than 50% informational patterns is a website, and any product with more than 50% behavioural patterns is a web app, but I don’t think that’s very useful.

Take a look at Brad’s collection of responsive patterns. Some of them are clearly informational (tables, images, etc.), while some of them are much more behavioural (carousels, notifications, etc.). But Brad doesn’t divide his collection into two, saying “Here are the patterns for websites” and “Here are the patterns for web apps.” That would be a dumb way to divide up his patterns, and I think it’s an equally dumb way to divide up the whole web.

What I’m getting at here is that, rather than trying to answer the question “what is a web app, anyway?”, I think it’s far more important to answer the other question I posed:


Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think by making the distinction at the pattern level, that question starts to become a bit easier to answer. One possible answer is to do with the different skills involved.

For example, I know plenty of designers who are really, really good at informational patterns—they can lay out content in a beautiful, clear way. But they are less skilled when it comes to thinking through all the permutations involved in behavioural patterns—the “arrow of time” that’s part of so much interaction design. And vice-versa: a skilled interaction designer isn’t necessarily the best at old-skill knowledge of type, margins, and hierarchy. But both skillsets will be required on an almost every project on the web.

So I do believe there is value in distinguishing between behaviour and information …but I don’t believe there is value in trying to shoehorn entire products into just one of those categories. Making the distinction at the pattern level, though? That I can get behind.


Incidentally, some of the respondents to Chris’s poll shared my feeling that the term “web app” was often used from a marketing perspective to make something sound more important and superior:

Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

Approaching things from the patterns perspective, I wonder if those same feelings of inferiority and superiority are driving the recent crop of behavioural patterns for informational content: parallaxy, snowfally, animation patterns are being applied on top of traditional informational patterns like hierarchy, measure, and art direction. I’m not sure that the juxtaposition is working that well. Taking the single interaction involved in long-form informational patterns (that interaction would be scrolling) and then using it as a trigger for all kinds of behavioural patterns feels …uncanny.

By any other name

I’m not a fan of false dichotomies. Chief among them on the web is the dichotomy between documents and applications, or more broadly, “websites vs. web apps”:

Remember when we were all publishing documents on the web, but then there was that all-changing event and then we all started making web apps instead? No? Me neither. In fact, I have yet to hear a definition of what exactly constitutes a web app.

I’ve heard plenty of descriptions of web apps; there are many, many facets that could be used to describe a web app …but no hard’n’fast definitions.

One pithy observation is that “a website has an RSS feed; a web app has an API.” I like that. It’s cute. But it’s also entirely inaccurate. And it doesn’t actually help nail down what a web app actually is.

Like obscenity and brunch, web apps can be described but not defined.

I think that Jake gets close by describing sites as either “get stuff” (look stuff up) or “do stuff”. But even that distinction isn’t clear. Many sites morph from one into the other. Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

I think there’s a much more fundamental question here than simply “what’s the difference between a website and a web app?” That more fundamental question is…


Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think this same fundamental question applies to the usage of the term “HTML5”. That term almost never means the fifth iteration of HTML. Instead it’s used to describe everything from CSS to WebGL. It fails as a descriptive term for the same reason that “web app” does: it fails to communicate the meaning intended by the person using the term. You might say “HTML5” and mean “requires JavaScript to work”, but I might hear “HTML5” and think you mean “has a short doctype.” I think the technical term for a word like this is “buzzword”: a word that is commonly used but without any shared understanding or agreement.

In the case of “web app”, I’m genuinely curious to find out why so many designers, developers, and product owners are so keen to use the label. Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

In his recent talk at Port 80, Jack Franklin points to one of the dangers of the web app/site artificial split:

We’re all building sites that people visit, do something, and leave. Differentiating websites vs. web apps is no good to anyone. A lot of people ignore new JavaScript tools, methods or approaches because those are just for “web apps.”

That’s a good point. A lot of tools, frameworks, and libraries pitch themselves as being intended for web apps even though they might be equally useful for good ol’-fashioned websites.

In my experience, there’s an all-too-common reason why designers, developers, and product owners are eager to self-identify as the builders of web apps. It gives them a “get out of jail free” card. All the best practices that they’d apply to websites get thrown by the wayside. Progressive enhancement? Accessibility? Semantic markup? “Oh, we’d love to that, but this is a web app, you see… that just doesn’t apply to us.”

I’m getting pretty fed up with it. I find myself grinding my teeth when I hear the term “web app” used without qualification.

We need a more inclusive term that covers both sites and apps on the web. I propose we use the word “thang.”

“Check out this web thang I’m working on.”

“Have you seen this great web thang?”

“What’s that?” “It’s a web thang.”

Now all I need is for someone to make a browser plugin (along the lines of the cloud-to-moon and cloud-to-butt plugins) to convert every instance of “website” or “web app” to “web thang.”