First and foremost, if you like dark mode, if you like light mode; you do you, friend. I do not want to persuade you to change your aesthetics. I'm just always trying to learn more about the world. To better understand what's going on and what we think we know about it as a species. Easily one of the best things from this talk is knowing about the terms positive and negative polarity when talking about this. Using those terms to search for information really seems to help.
That out of the way, hope you find the talk fun and informative.
First of all, love this design. Retro-web is such a fun metamodern punk aesthetic. Every one of you make me smile when I load pages like these. Bonus points when it's blended the aesthetic with modern information design to make it still easy to follow and parse.
Second, go view the source code. Great touch!
Onto the meat. I hate being right about things like this. Called this back in 2024 when I explained Why I Removed My XSLT Feed Template.
For the record, I don't support this move. Breaking backward compatibility as a systems programmer is just burning down other people's work. Without an immensely good reason it's just arson.
How'd I call it? I was looking at the condition of the MDN docs around these coupled with what I know of software pop culture as a sign that nobody building browsers thinks XML is worth supporting anymore.
I'm not one for the conspiracy presented here though. I think it's just out of fashion which has become the arbiter of all that matters in software development. "Is the brand of the things I build, and the brands of the things I build with in fashion or not?" It's rich kids keeping up with the Joneses.
It always makes me roll my eyes when the people responsible for this sprawling mess of what is technically the web "standards" go on parades around small corners of the swamp to exclaim, we're cleaning up www subdomains! Never mind they've stuffed an entire Bluetooth stack, DRM, multiple database technologies, over two dozen media codecs, shader programming and more into the web ecosystem. Those three characters gotta go.
Same here. Doesn't matter that browsers still have to parse and support XML by way of XHTML. It's XSLT processing that broke the camel's back. Better force every piece of software that's used that spec into costly rewrites because I don't like it.
RSS will still work just fine in most readers. I think even most browser based readers are doing backend processing of the feed text to turn it into HTML instead of using the browser's XSLT parser to render them. I could be wrong though. Sorry I don't have any good reader suggestions here. I just built and maintain my own for personal use.
If you've been using XSLT on your feed to make it look great in a browser, or worse still, built entire mission critical applications leveraging XSLT, I feel for you. I won't rehash my thoughts on either side of that choice, however, if you think you want to, I think you should be able to count on the web platform remaining a platform instead of just being whatever some Googler thinks being a platform means that week.
In any case, all the more reason I'm bullish on a project like Ladybird. With fewer than seven competitors it's easy to get consensus on what you'll impose on the rest of society. Not only that but here you've got two of the three on the take of the third. Monopolization is really good at completely divorcing you from the problems you cause for everyday people.
Just a fun anecdote filled piece all about how to build good user interfaces. Excellent read. Well worth your time, even if you're versed in the subject.
To recap the highlights:
- A user interface is well-designed when the program behaves exactly how the user thought it would.
- Every time you provide an option, you're asking the user to make a decision.
- Users don't read the manual.
- Users can't control the mouse very well.
These are mostly reformulations of well known UI design guidelines:
- Jakob's Law: Users spend most of their time on other sites.
- This one's unique. Partly not interrupting a user. Partly not abdicating the design part of design. Partly not adding controls only a few people want.
- Paradox of the Active User (Carroll & Rosson, '87).
- Fitts's Law: The time to acquire a target is a function of the distance to—and size of—the target.
Sure this uses many more words for less than is covered by the Laws of UX website. The stories and examples are just fun to read though. Having vivid stories to remember can significantly improve how many of these abstract concepts you remember when you're working on UI.
This is the conference talk behind The Documentation System. This is my all time favourite framework for organizing documentation on a project. It builds a little 2x2 matrix based on practical versus theoretical and studying versus working to categorize documentation. Really helps provide clarity on what you're writing and where it should go.
There's often times to break with this strict breakdown. For example I love having a dedicated page to talk about the project explaining what it is and why you should care at the top of the documentation and outside this structure. FAQs also tend to sit outside just to be really easy to find. It's fine to break with this structure when it makes sense, but having this as the backbone of the documentation has really improved splitting documentation up. To try and stop having stream of conciousness dumping documents.
I would strongly suggest not throwing everything out and starting again. Just start by adding this structure to your project and link (don't move) the existing documents that already fit this structure. That's already a lot of work and doesn't destroy what you have before you've fully built the replacement. Next, you need to build buy-in. If people are going to keep writing documents the old way (usually randomly in wherever they think makes sense) then you'll never converge. Getting buy-in from the team about this system means all new documentation will be built starting from these viewpoints. Even if the folder structure is later abandoned, just having these use cases in mind when writing documentation prevents making information soup.
Once all that's done you can then begin refactoring documents as you update them, splitting them into new documents inside each of the relevant sections. Over time, if you have analytics, you should start to see more and more people reading documents from the new sections and less from the old. Whenever you see a document outside this system being used often, refactor it into the system. If you don't have analytics on your docs, you probably should. It's invaluable to help find what documentation is having a real impact and what documentation isn't.
