I had a chat with some people from Name.com while I was in Denver for An Event Apart. Here’s a few minutes of me rambling on about web development and the indie web.
Saturday, February 10th, 2018
Friday, October 27th, 2017
Amber shares her story of becoming a web developer and a public speaker. She is an inspiration to me!
Monday, September 4th, 2017
Here’s Amber’s great talk from the great Material conference last month in Iceland.
Amber Wilson worked in the field of Psychology for many years and is now a budding Web developer at a design agency in Brighton. New to Web development, she is continually eager to improve her skills.
(The silhouettes of Jessica, me, and Joschi in the front row make it look like Mystery Science Theater 3000.)
Wednesday, July 5th, 2017
I frequently see web developers struggling to become better, but without a path or any indication of clear direction. This repository is an attempt to sharing my experiences, and any contributions, that can help provide such a direction.
It’s broken down into four parts:
- 10 Domains of Web Development
- Events and Interaction
- Internationalization / Localization
- Understandability / Content
- Interviewing for Web Developers
- Productivity for Web Developers
- Web Training Hierarchy
- Level 1 - Writing Code
- Level 2 - Accessibility and Security
- Level 3 - Architecture
- Level 4 - Innovation
I don’t necessarily agree with everything here (and I really don’t like the “rockstar” labelling), but that’s okay:
Anything written here is open to debate and challenges are encouraged.
Friday, June 9th, 2017
Talking with the tall man about poetry
When I started making websites in the 1990s, I had plenty of help. The biggest help came from the ability to view source on any web page—the web was a teacher of itself. I also got plenty of help from people who generously shared their knowledge and experience. There was Jeffrey’s Ask Dr. Web, Steve Champeon’s WebDesign-L mailing list, and Jeff Veen’s articles on Webmonkey. Years later, I was able to meet those people. That was a real privilege.
I’ve known Jeff for over a decade now. He’s gone from Adaptive Path to Google to TypeKit to Adobe to True Ventures, and it’s always fascinating to catch up with him and get his perspective on life, the universe, and everything.
He started up a podcast called Presentable about a year ago. It’s worth having a dig through the archives to have a listen to his chats with people like Andy, Jason, Anna, and Jessica. I was honoured when Jeff asked me to be on the show.
We ended up having a really good chat. It’s out now as Episode 25: The Tenuous Resilience of the Open Web. I really enjoyed having a good ol’ natter, and I hope you might enjoy listening to it.
‘Sfunny, but I feel like a few unplanned themes came up a few times. We ended up talking about art, but also about the scientific aspects of design. I couldn’t help but be reminded of the title of Jeff’s classic book, The Art and Science of Web Design.
We also talked about my most recent book, Resilient Web Design, and that’s when I noticed another theme. When discussing the web-first nature of publishing the book, I described the web version as the canonical version and all the other formats as copies that were generated from that. That sounds a lot like how I describe the indie web—something else we discussed—where you have the canonical instance on your own site but share copies on social networks: Publish on Own Site, Syndicate Elsewhere—POSSE.
We also talked about technologies, and it’s entirely possible that we sound like two old codgers on the front porch haranguing those damn kids on the lawn. You can be the judge of that. The audio is available for your huffduffing pleasure. If you enjoy listening to it half as much as I enjoyed doing it, then I enjoyed it twice as much as you.
Sunday, February 12th, 2017
A nice straightforward introduction to web development for anyone starting from scratch.
Thursday, July 7th, 2016
Ten of us reminisce about where we were and what we were doing a decade ago.
Ten years ago I was writing on my blog. Lots of other people were writing on their blogs back then too. That would soon change, though. Twitter and Facebook were picking up steam and soon they’d be luring bloggers away with enticing and seductive short-form convenience. I’ve stubbornly continued writing on my own site. I fully intend to keep on writing there for the next ten years too.
Friday, June 10th, 2016
I think I’ve gotten tired of Google telling me “This is how you have to build websites now.” Or Apple coming down from the mountain once a year saying “Here are the two new products you will buy this year.”
A wager on the web
Jason has written a great post about progressive web apps. It’s also a post about whether fears of the death of the web are justified.
Lately, I vacillate on whether the web is endangered or poised for a massive growth due to the web’s new capabilities. Frankly, I think there are indicators both ways.
So he applies Pascal’s wager. The hypothesis is that the web is under threat and progressive web apps are a solution to fighting that threat.
- If the hypothesis is incorrect and we don’t build progressive web apps, things continue as they are on the web (which is not great for users—they have to continue to put up with fragile, frustratingly slow sites).
- If the hypothesis is incorrect and we do build progressive web apps, users get better websites.
- If the hypothesis is correct and we do build progressive web apps, users get better websites and we save the web.
- If the hypothesis is correct and we don’t build progressive web apps, the web ends up pining for the fjords.
Whether you see the web as threatened or see Chicken Little in people’s fears and whether you like progressive web apps or feel it is a stupid Google marketing thing, we can all agree that putting energy into improving the experience for the people using our sites is always a good thing.
Jason is absolutely correct. There are literally no downsides to us creating progressive web apps. Everybody wins.
But that isn’t the question that people have been tackling lately. None of these (excellent) blog posts disagree with the conclusion that building progressive web apps as originally defined would be a great move forward for the web:
- Yet another blog about the state and future of Progressive Web App by Ada Rose Edwards
- Progressively less progressive by Andrew Betts
- Progressive web apps – let’s not repeat the errors from the beginning of responsive web design by Michael Scharnagl
The real question that comes out of those posts is whether it’s good or bad for the future of progressive web apps—and by extension, the web—to build stop-gap solutions that use some progressive web app technologies (Service Workers, for example) while failing to be progressive in other ways (only working on mobile devices, for example).
In this case, there are two competing hypotheses:
- In the short term, it’s okay to build so-called progressive web apps that have a fragile technology stack or only work on specific devices, because over time they’ll get improved and we’ll end up with proper progressive web apps in the long term.
- In the short term, we should build proper progressive web apps, and it’s a really bad idea to build so-called progressive web apps that have a fragile technology stack or only work on specific devices, because that encourages more people to build sub-par websites and progressive web apps become synonymous with door-slamming single-page apps in the long term.
The second hypothesis sounds pessimistic, and the first sounds optimistic. But the people arguing for the first hypothesis aren’t coming from a position of optimism. Take Christian’s post, for example, which I fundamentally disagree with:
End users deserve to have an amazing, form-factor specific experience. Let’s build those.
Never make any decision based on fear.
Thursday, May 26th, 2016
A heartfelt call to web developers to consider the needs of the many and varied people trying to use what we build.
It is about making products that serve all users equally. It is about putting ourselves in others’ shoes. It is about trying to imagine the frustration and difficulty of using our products when the conditions aren’t what we’re used to. It is about being human.
Friday, April 29th, 2016
Eric asked me some questions and I was only too happy to give some answers.
Monday, April 25th, 2016
Chris’s homage to I, Pencil.
I, Website, am a complex combination of miracles.
Tuesday, April 5th, 2016
Wednesday, December 2nd, 2015
This seems like a decent endeavour:
A collaborative research project aimed at designing better tools and practices for learning web development.
Wednesday, August 26th, 2015
Whatever works for you
It’s an interesting idea that I could certainly imagine being useful in certain situations such as dynamically updating an interface in real time (it feels a bit more “close to the metal” to reflect the state updates directly rather than doing it via class swapping). But there are many, many other situations where the cascade is very useful indeed.
In short, my response was “hey, like, whatever, it’s cool, each to their own.” There are many, many different kinds of websites and many, many different ways to make them. I like that.
I find that a little disheartening. Chris has written about the confidence of youth:
Discussions are always worth having. Weighing options is always interesting. Demonstrating what has worked (and what hasn’t) for you is always useful. There are ways to communicate that don’t resort to dogmatism.
There are big differences between saying:
- You can do this,
- You should do this, and
- You must do this.
My take on the inline styles discussion was that it fits firmly in the “you can do this” slot. It could be a very handy tool to have in your toolbox for certain situations. But ideally your toolbox should have many other tools. When all you have is a hammer, yadda, yadda, yadda, nail.
Like I said on the podcast, it’s a big web out there. The idea that there is “one true way” that would work on all possible projects seems unlikely—and undesirable.
“A ha!”, you may be thinking, “But you yourself talk about progressive enhancement as if it’s the one try way to build on the web—hoisted by your own petard.” Actually, I don’t. There are certainly situations where progressive enhancement isn’t workable—although I believe those cases are rarer than you might think. But my over-riding attitude towards any questions of web design and development is:
Thursday, July 9th, 2015
The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack
Tuesday, June 30th, 2015
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
Sunday, June 28th, 2015
Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.
Wednesday, June 3rd, 2015
Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.
Wednesday, May 20th, 2015
When I give talks or workshops, I sometimes get a bit ranty. One of the richest seams of rantiness comes from me complaining about how we web designers and developers are responsible for making the web a hostile place. “Stop getting the web wrong!” I might shout, like an old man yelling at a cloud. I point to services like Instapaper and Readability and describe their existence as a damning indictment of our work.
Don’t get me wrong—I really like Instapaper, Readability, RSS readers, or any other tools that allow people to read what they want when they want it. But think about their fundamental selling point: get to the content you want without having to wade through the cruft. That cruft was put there by us.
So-called modern web design and development is damage that people have to route around.
(Ooh, I can feel myself coming over all ranty and angry again! Calm down, Jeremy, calm down!)
Now there’s a new tool to the add to the list: Facebook Instant. Again, I think it’s actually pretty great that this service exists. But once again, it should make us ashamed of the work we’re collectively producing.
In this case, the service is—somewhat ironically—explicitly touting the performance benefits of not going to a website to read an article. Quite right.
The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight.
Business development deals have created problems that no web developer can solve. There’s no way to make a web page with a full-screen content-obscuring ad anything other than a shitty experience.
My least favorite online game these days: finding the “X" that closes the nearly ubiquitous website popup for newsletter signup or video ad.— Jason Kottke (@jkottke) May 18, 2015
How to browse the mobile web: Navigate to site Close modal popup (if you can) Decline native app offer Close top banner Close bottom banner— Justin Palmer (@Caged) April 21, 2015
Now you might be saying to yourself “Well, I’ve never made a bloated web page!” or “I’ve never slapped loads of intrusive crap over the content!” I’d certainly like to think that I can look at my track record and hold my head up reasonably high. But that doesn’t matter. If the overall perception is that going to a URL to read an article is a pain in the ass, it hurts all of us.
Not only is the web not fast enough for apps, it’s not fast enough for text either. …on mobile, the web browser just isn’t cutting it. … Native apps provide a better user experience on mobile than a web browser.
On the face of it, this is kind of a bizarre claim. After all, there’s nothing inherent in web browsers that makes them slow at rendering text—quite the opposite! And native apps still use HTTP (and often HTML) to fetch content; the network doesn’t suddenly get magically faster just because the piece of software requesting a resource doesn’t happen to be a web browser.
But this conflation of slow websites and slow web browsers is perfectly understandable. If it looks like a slow duck, and it quacks like a slow duck, then why not conclude that ducks are slow? Even if we know that there’s nothing inherently slow about making web pages:
You don’t need Facebook to deliver your text faster than you can. Remove all unnecessary cruft and make your site blazing fast.— Nat Buckley (@thatnatbuckley) May 15, 2015
My hope is that Facebook Instant will shake things up a bit. M.G. Siegler again:
At the very least, Facebook has put everyone else on notice. Your content better load fast or you’re screwed. Publication websites have become an absolutely bloated mess. They range from beautiful (The Verge) to atrocious (Bloomberg) to unusable (Forbes). The common denominator: they’re all way too slow.
There needs to be a cultural change in how we approach building for the web. Yes, some of the tools we choose are part of the problem, but the bigger problem is that performance still isn’t being recognised as the most important factor in how people feel about websites (and by extension, the web). This isn’t just a developer issue. It’s a design issue. It’s a UX issue. It’s a business issue. Performance is everybody’s collective responsibility.
I’d better stop now before I start getting all ranty again.
I’ll leave you with some other writings on this topic…
Tim Kadlec talks about choosing performance:
It’s not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.
Jim Ray points out that “we learned the wrong lesson from the rise of mobile and the app ecosystem”:
The web doesn’t suck. Your websites suck.
All of your websites suck.
The lousy performance of your websites becomes a defensive moat around Facebook.
Go read the whole thing—it’s terrific:
This is a long-standing debate. Except it’s only long-standing among web developers. Columnists, managers, pundits, and journalists seem to have no interest in understanding the technical foundation of their livelihoods. Instead they are content with assuming that Facebook can somehow magically render HTML over HTTP faster than anybody else and there is nothing anybody can do to make their crap scroll-jacking websites faster. They buy into the myth that the web is incapable of delivering on its core capabilities: delivering hypertext and images quickly to a diverse and connected readership.