2025-01-30 03:00:00
John Gruber has a post about how Google’s search results now require JavaScript[1]. Why? Here’s Google:
the change is intended to “better protect” Google Search against malicious activity, such as bots and spam
Lol, the irony.
Let’s turn to JavaScript for protection, as if the entire ad-based tracking/analytics world born out of JavaScript’s capabilities isn’t precisely what led to a less secure, less private, more exploited web.
But whatever, “the web” is Google’s product so they can do what they want with it — right? Here’s John:
Old original Google was a company of and for the open web. Post 2010-or-so Google is a company that sees the web as a de facto proprietary platform that it owns and controls. Those who experience the web through Google Chrome and Google Search are on that proprietary not-closed-per-se-but-not-really-open web.
Search that requires JavaScript won’t cause the web to die. But it’s a sign of what’s to come (emphasis mine):
Requiring JavaScript for Google Search is not about the fact that 99.9 percent of humans surfing the web have JavaScript enabled in their browsers. It’s about taking advantage of that fact to tightly control client access to Google Search results. But the nature of the true open web is that the server sticks to the specs for the HTTP protocol and the HTML content format, and clients are free to interpret that as they see fit. Original, novel, clever ways to do things with website output is what made the web so thrilling, fun, useful, and amazing. This JavaScript mandate is Google’s attempt at asserting that it will only serve search results to exactly the client software that it sees fit to serve.
Requiring JavaScript is all about control.
The web was founded on the idea of open access for all. But since that’s been completely and utterly abused (see LLM training datasets) we’re gonna lose it.
The whole “freemium with ads” model that underpins the web was exploited for profit by AI at an industrial scale and that’s causing the “free and open web” to become the “paid and private web”.
Universal access is quickly becoming select access — Google search results included.
Reply via: Email :: Mastodon :: Bluesky
Tagged in: #generalNotes
2025-01-29 03:00:00
Let me tell you about one of the best feelings.
You have a problem.
You bang your head on it for a while.
Through the banging, you formulate a string of keywords describing the problem.
You put those words into a search engine.
You land on a forum or a blog post and read someone else’s words containing those keywords and more. Their words resonate with you deeply.
They’re saying the exact same things you were saying to yourself in your head.
You immediately know, “This person gets it!”
You know they have an answer to your problem. They’ve seen what you’re seeing.
And on top of it all, they provide a solution which fixes your problem!
A sense of connection is now formed. You feel validated, understood, seen. They’ve been through what you’re going through, and they wrote about it to reach out to you — across time and space.
I fell in love with the web for this reason, this feeling of connection. You could search the world and find someone who saw what you see, felt what you feel, went through what you’re going through.
Contrast that with today.
Today you have a problem.
You bang your head on it.
You ask a question in a prompt.
And you get back something.
But there’s no human behind it. Just a machine which takes human voices and de-personalizes them until the individual point of view is annihilated. And so too with it the sense of connection — the feeling of being validated, understood, seen.
Every prompt a connection that could have been. A world of missed connections.
2025-01-28 03:00:00
This is a note to my future self, as I’ve setup HTML minification on a few different projects and each time I ask myself, “How did I do that again?” So here’s your guide, future Jim (and anyone else on the internet who finds this).
I use html-minifier to minifiy HTML files created by my static site generator. Personally, I use the CLI tool because it's easy to add a CLI command as an npm postbuild step.
Example package.json:
{
"scripts": {
"build": "<BUILD-COMMAND>"
"postbuild": "html-minifier --input-dir <BUILD-DIR> --output-dir <BUILD-DIR> --file-ext html <OPTIONS>"
}
}
All the minification options are off by default, so you have to turn them on one-by-one (HTML minfication is a tricky concern). Me personally, I’m using the ones exemplified in the project README:
--collapse-whitespace --remove-comments --remove-optional-tags --remove-redundant-attributes --remove-script-type-attributes --remove-tag-whitespace --use-short-doctype --minify-css true --minify-js true
So, for a site folder named build, the entire command looks like this:
html-minifier --input-dir ./build --output-dir ./build --file-ext html --collapse-whitespace --remove-comments --remove-optional-tags --remove-redundant-attributes --remove-script-type-attributes --remove-tag-whitespace --use-short-doctype --minify-css true --minify-js true
That’s it — that’s the template.
I use this on a few of my sites, including my notes site and this blog.
When testing it locally for my blog’s build, I:
./build
./build to ./build-mincp -R build build-min
html-minifier on build-min and compare the resulting folders in macOS finder.Here’s my results for my blog (2,501 items in ./build):
index.html file lines of code:index.html file size over the network:And the results for my notes (one big index.html file):
Reply via: Email :: Mastodon :: Bluesky
Tagged in: #html
2025-01-23 03:00:00
A note before we start: I don’t know how much of this I believe. I’m sketching out some feelings in this post and thinking through whether it actually makes any sense. I’d be curious where other folks land on this.
I’m not sure I totally understand this impulse we have on the web to override the default style and appearance of fundamental computing controls.
Everyone wants their own checkboxes, radios, and select menus that fit their brand.
But websites aren’t about you or your brand. They’re about the people you’re serving who have to use them, i.e. the users.
And their needs vary from one person to the next, based on their unique context and environment (operating system, device, etc.)
For them, a checkbox that’s visually and functionally uniform across every website is a good thing. It provides consistency and sets expectations — “Oh hey, a checkbox, I know how to use this. It looks and functions the same as a checkbox on every other website, app, or system preference on my computer.”
But where we’ve arrived on the web is consistency for brands is more important than consistency for end users.
Imagine a radio control in macOS. There are some design considerations in how that system-level control looks and functions that are unique to macOS.
For example, when a window loses focus in favor of another window, radio controls are de-emphasized visually because the user is now focused on something else in a different window.
This is a unique solution for a specific computing experience where multiple windows may be on the screen at the same time and, as the user shifts focus from one window to another, additional visual help is provided to emphasize and de-emphasize the user’s focal point in the user interface.
The beauty of leveraging a system-level element is that you’re tapping into these kinds of solutions which are tailored to solve problems unique to their context and environment.
Contrast that with a radio somebody re-implemented on the web to match their brand. I highly doubt many have taken into consideration a de-emphasized state for windowed computing experiences.
As another example, consider how the <select> element can break outside of the browser window because it is an OS-level control.
For example, have a list with a lot of options? A <select> element can provide users something your custom select never could: an adaptation to its environment, the operating system. If the browser window is small on screen (because, say, the user is trying to do something else within their computing environment like side-by-side windows) the <select> can break out of the browser window and accommodate more space.
Similarly, though perhaps not as advantageous, on mobile devices like iOS the <select> can break outside of the browser window. Something a custom element could never do.
Additionally, these native controls are incredibly forward looking. If new hardware or OS appears on the scene (see visionOS), how the <select> works is handled for you. When it ships, you’re up to date (vs. a design system where now you have to go consider how, if at all, things change for your entire system and every site it supports).
Business case: there’s no more economical way to ship websites than using the platform. You get outside engineering resources to build your UIs at no cost to you! Every component you build is a liability, so what’s the least you can do to deliver value?
I get it, there are trade-offs. But when building UIs, how often do we stop to ask: What’s lost when we refuse to consider the context and environment of our users because we instead force upon them the context and environment of our brand?
We extoll the virtues of a “design system” within our brands and organizations — consistency, familiarity, uniformity, all for our users! But once they leave the walled garden of our brand, it’s ok that they suddenly lose this privilege?
If the inconsistencies across design systems for basic computing controls were within our own organizational systems, we would be enraged! But since they’re across brands (e.g. websites), it’s fine? (Below is an example of radios and checkboxes and selects across various popular design systems.)
In the end, it’s the user who has to deal with these inconsistencies. But isn’t that what “systems” are meant to solve in the first place?
In other words, the default, un-styled, system-level controls for radios, switches, checkboxes, etc., are the original design system before our branded design systems overrode them.
Your organization’s design system lacks the sensibilities of your users’ platforms.
“We made our own radios! They’re great! They’re ‘on-brand’ and consistent across all our stuff.”
But they’re not consistent across all your users’ stuff.
In other words, you made a radio for your company without considering what makes a radio a radio on the computer it will be used on.
You oriented a visual and functional experience around you and your environment, rather than the person you’re serving and their context and environment.
And I just tend to think we’re losing out on something with that choice — to say nothing of its cost.
Disclaimer 1: I know I’m cheating here. Not all native system controls have been standardized in a way that serves the varied needs of complex applications. But, on the other side of this coin, a simple healthcare form that would be perfectly suited to some basic radio controls and a plain <select> menu instead rolls its UI for no other reason than to make it “on-brand” and it’s worse in almost every way: visually, functionally, accessibly.
Disclaimer 2: Yeah I know, this puts us as developers at the mercy of browser vendors and OS platforms and the paltry level of access they give us to system controls. For example, it’s still not easy to mark a checkbox with an indeterminate state in HTML alone. I get that. But perhaps if we spent more time advocating for these kinds of enhancements (instead of re-theming a checkbox for the nth time) maybe we’d get what we ask for?
Disclaimer 3: In case it’s not clear, I am not advocating every website everywhere should only use form controls provided by the web platform. The web is a big place, it’s silly to make universal statements for something so big. What I’m trying to do is bring attention to the fact that maybe you don’t need to roll your own. Maybe design systems should consider the computing context and environment of their users over the context and environment of their own brand.
Disclaimer 4: I get that system-level consistency is a kind of branded consistency. If you choose an Apple product, you’re choosing an Apple-branded experience for native form controls. I realize these things are not totally brand-agnostic. But consumers make a choice when they buy a computing device, and maybe we should honor that choice rather than try overriding it.
Disclaimer 5: Having disclaimers clears me of any and all criticism lol.
2025-01-21 03:00:00
You know what’s really helpful in solving my own problems? Writing them down, sending them to someone, and not hearing back.
You ever do that? For me, it’s a bulletproof method to solving problems.
It’s akin to those moments when you go to someone with a problem, you talk it through, you find a solution, you thank them for their help, and they say, “Well I didn’t even say anything, but you’re welcome.”
If I have a friend, co-worker, or collaborator who I know is on the other end of a chat box, typing out my problem and not hearing back from them can be a tremendous help.
Here’s an example of how it often goes:
Jim Nielsen, Friday at 12:53 PM
I’m having an issue where the deployment isn’t working. Failiures are coming from lines 123-125 of the build script...
Jim Nielsen, Friday at 12:59 PM
Oh, it looks like something changed in commit abc123e in the lock file...
Jim Nielsen, Friday at 1:02 PM
This is so weird, I hate troubleshooting this crap. Why is everything in the world garbage?
Jim Nielsen, Friday at 1:03 PM
Ok, I can’t figure this out. I'm going to need your help when you have a second.
Jim Nielsen, Friday at 1:09 PM
Oh hey, actually I think I know what the problem is...
Jim Nielsen, Friday at 1:11 PM
Ok, it’s fixed now. Nevermind, I don’t need your help. Thanks!
Co-worker, Friday at 4:03 PM
You're welcome, glad I could help!
In contrast, AI is too eager to respond back with something when nothing would be much more helpful.
Knowing another human is there to connect with — available, listening, but not speaking — has helped me many times as I express my thinking step-by-step.
So let me give you some relationship advice, AI. Sometimes you don’t need to say or do anything. You just need to listen.
Cool? Thanks.
Reply via: Email :: Mastodon :: Bluesky
Tagged in: #ai
2025-01-16 03:00:00
I took notes from Sean Voisen’s call for more hybrid tools. He speaks for a moment on generative AI and its inclusion into existing tools, but reading between the lines the insight I found was how our tools can trigger empathy for people and disciplines:
One of the greatest goals we can have for [making] tools…is that in expanding all of our respective capabilities, we do not replace our human teammates, but rather we participate more deeply in the creative process together.
A good tool improves your output.
A great tool improves your output and your understanding and empathy for others and their disciplines.
If designing tools is designing ways of being — “we shape our tools and they shape us” — then the tools we use together are shared ways of being. They facilitate us not only getting stuff done together, but being together. And that being can bring a better understanding of each other.
I don’t think that’s too crazy to assert, especially when you look at communities that coalesce around tools, like Clojure. People love their tools, and they identify with the principles they embody and the communities that support them.
Our tools are ways of being. How important, then, that we carefully consider their design as well as proliferate their diversity.
