This is a clever use of the
srcdoc attribute on iframes.
Archive: August 8th, 2019
This is a clever use of the
Earlier this year, at Indie Web Camp Düsseldorf, I got replies working on my own site. That is to say, I can host a reply on my site to something on another site.
The classic example is Twitter. In fact, if you look at all my replies, most of them are responding to tweets (I also syndicate these replies to Twitter so they show up there just like regular tweet replies).
I’m really, really glad I got replies working. I’ve been using this functionality quite a bit, and it feels really good to own my content this way.
At the time, I wrote:
So I’m owning my replies now. At the moment, they show up in my home page feed just like any other notes I post. I’m not sure if I’ll keep it that way. They don’t make much sense out of context.
I decided not to include them on my home page feed after all. You’ll still see them if you go to the notes section of my site, but I decided that they were overwhelming my home page a bit. They also don’t show up in my RSS feed.
I’m really happy that I’m hosting my replies, and that I’ve got URLs for all of them, but I don’t think I want to give them the same priority as blog posts, links, and regular notes.
The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.
I’ve just been adding
loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.
I recently wrote about a web-specific example of a general principle for choosing the right tool for the job:
I was—yet again—talking about appropriateness. Use the right technology for the task at hand. Here’s the example I gave:
Surprisingly, I got some pushback on this. Šime Vidas wrote:
Based on my experience, this is not necessarily the case.
Going from server-side rendering and progressive enhancement via JS to a single-page app powered by a JS framework was a enormous reduction in complexity for me (so the opposite of over-engineering).
(Emphasis mine.) He goes on to say:
My main concerns are ease of use & maintainability. If you get those things right, you’re good and it’s not over-engineering.
There’s no doubt that maintainability is a desirable goal. And ease of use for the developer is also important …but I think they pale in comparison to ease of use for the end user.
To be fair, the specific use-case I mentioned was making a blog. And a blog is a personal thing. You can do whatever the heck you like on your own website and don’t let anyone tell you otherwise.
So I probably chose a poor example to illustrate my point. I was thinking more about when you’re making websites for a living. You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.
As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time.
That’s why I responded to Šime, saying:
Your main concern should be user needs—not your own.
When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.
Before considering your ease of use, and maintainability, consider users first.
In fairness to Šime, he’s being very open and honest about his priorities. I admire that. I’ve seen too many developers try to provide user experience justifications for decisions made for developer convenience. Once again I recommend Alex’s excellent article, The “Developer Experience” Bait-and-Switch:
The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.
Now I worry I wasn’t specific enough when I talked about choosing appropriate technology:
Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand.
I should have made it clear that I was talking about what is appropriate or inapropriate for users. I think I made the mistake of assuming that this was obvious, and didn’t need saying. I’ll try not to make that mistake again.
If you’re in that situation—you are being paid money to make websites, and you are making technology decisions—I urge you to remember Charlie’s words: it isn’t about you.
Replying to a tweet from @jesslynnrose