Facebook isn’t really all that much better or more convenient than having your own website, or sending emails or chats. But for some reason, Facebook (and Instagram) are where we post now.
Friday, December 21st, 2018
Sunday, July 8th, 2018
The title is quite clickbaity, but this is a rather wonderful retelling of web history on how Content Management Systems may have stifled a lot of the web’s early creativity.
Also, there’s this provocation: we like to rail against algorithmic sorting …but what if the reverse-chronological feed was itself the first algorithm?
Sunday, July 1st, 2018
Before social media monoliths made us into little mechanical turks for advertising platforms, we had organic homes on the web. We had pages that were ours. And they could look however you wanted. And you could write whatever you wanted on there.
There weren’t comments if you didn’t want them. There were no photo dimensions to adhere to. No 140-character limits. No BS. Or lots of BS. Either way, the choice was yours because you owned your site and you could do whatever you wanted.
Tuesday, June 27th, 2017
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.
The name is one of the reasons I didn’t look into PWAs 6 months ago. Can we change the name itself? 😎— Julian Gaviria (@juliangav) March 24, 2017
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.
I’ve seen too many devs assume PWA is a subset of SPA. We need to improve our messaging— Jake Archibald (@jaffathecake) June 4, 2016
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:
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.
Wednesday, June 14th, 2017
A pretty good summary of some key indie web ideas.
Monday, February 20th, 2017
What an excellent idea! A weekly round-up in audio form of indie web and homebrew website news. Nice and short.
Monday, November 28th, 2016
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”.
Sunday, June 5th, 2016
Why Get on the Indie Web?
In a word, autonomy.
- What is the Indie Web?
- How Can You Get on the Indie Web?,
- Where is the Indie Web? and
- Who is the Indie Web?
The Indie Web is made of people. It’s made by me. It can be made by you too. There’s no gatekeeper. You can join anytime without anyone’s permission. The Indie Web is made by everyone.
Monday, May 2nd, 2016
I’ve been on the web for most of my life, but, without a site to call home, I haven’t been of the web for far too long.
Wednesday, August 12th, 2015
Benjamin documents his experience at the first Brighton Homebrew Website Club: a most pleasant evening.
Thursday, August 6th, 2015
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.
Sunday, December 15th, 2013
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”?
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.
Having spent years working on both apps & sites, I think there’s a significant difference. Hard to explain doesn’t mean non-existent.— Cennydd Bowles (@Cennydd) December 6, 2013
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.
Ok, I’ll try. An app’s primary material is behaviour. A website’s primary material is information.— Cennydd Bowles (@Cennydd) December 6, 2013
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.
Friday, December 6th, 2013
Some excellent research from Chris, canvassing opinions on whether there’s a difference between web “apps” and web “sites”. His conclusion:
Almost none of the points above ring true for me. All I see are exceptions and gray area.
If nothing else, the fact that none of the proposed distinctions agree with one another show how pointless the phrase “web app” is—if people have completely differing ideas on what a phrase means, it is completely useless in furthering discussion …the very definition of a buzzword.
This leads me to think perhaps the “web app” moniker (certainly the newer of the two) is simply just a fashionable term. We like the sound of it, so we use it, regardless if it truly means anything.
But all of this is, I think, missing the more important point: why? Why would you want to separate the cornucopia of the web into two simplistic buckets? What purpose does it serve? That’s the question that really needs be answered.
If we could pin down a super accurate definition that we agreed on, even then it might not be particularly useful. And since we can’t, I argue it’s even less useful.
Tuesday, May 14th, 2013
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?
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.
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.”
Wednesday, December 5th, 2012
Don’t do it. Don’t click that button just one more time. Don’t.
Monday, January 2nd, 2012
What would Google+, YouTube and Facebook have looked like in 1997?
Friday, December 23rd, 2011
Burying physical copies of dead websites in a Croatian cave.
Tuesday, September 21st, 2010
Oh, what a lovely metaphor! What's your online home?
Thursday, January 21st, 2010
This is a work of genius. This... this is a joke ...right?
Sunday, March 16th, 2008
This was the best part of the best presentation at South by Southwest this year: Merlin Mann gives his spiel during Andy Baio's "Worst website ever."