Yesterday I spent all day in a cinema full of design system nerds. Why? To attend Patterns Day 3. Eight speakers shared their knowledge: some zoomed out to see the bigger picture, others zoomed in on the nitty-gritty.

It was nice to be at another Patterns Day, after I attended the first and missed the second. Thanks Clearleft and especially Jeremy Keith for putting it together. In this post, I'll share my takeaways from the talks, in four themes: the design system practice, accessibility, the technical nitty-gritty, and communication.

The day's venue: the Duke of York's cinema

The design system practice

Design system veteran Jina Anne, inventor of design tokens, opened the day with a reflection on over a decade of design systems (“how many times can I design a button in my career?”) and a look at the future. She proposed we find a balance between standardisation and what she called “intelligent personalisation”.

On the other hand, we aren't really done yet. There are so many complex UX patterns that can be solved more elegantly, as Vitaly Friedman showed. His hobbies include browsing postal office, governmental and e-commerce websites. He looks at the UIs they invent (so that we don't have to). Vitaly showed us more breadcrumbs than was necessary, including some that, interestingly, have feature-parity with meganavs.

Yolijn van der Kolk, product manager (and my colleague) at NL Design System, presented a unique way of approaching the design system practice: the “relay model”. It assigns four statuses to components and guidelines, which change over time on their road to standardisation. It allows innovation and collaboration from teams with wildly different needs in wildly different organisations. The statuses go from sharing a need (“Help Wanted”), to materialising it with a common architecture and guidelines (“Community”), to proposing it for real-life feedback (“Candidate”), to ultimately standardising an uncontroversial and well-tested version of it (”Hall of Fame”).

Jeremy Keith hosted the event

The technical nitty gritty

Two talks focused on design problems that can be solved with clever technical solutions: theming (through design tokens) and typography (through modular scales with modern CSS).

Débora Ornellas, who worked at Lego (haven't we all used the analogy?), shared a number of great recommendations around using design tokens: to use readily available open source products instead of inventing your own, publish tokens as packages and version them and avoid migration fatigue by reducing breaking changes.

Richard Rutter of Clearleft introduced us to typographic scales, which, he explained, are like musical scales. I liked how, after he talked about jazz for a bit, the venue played jazz in the break after his talk. He showed that contrast (eg in size) between elements is essential for good typography: it helps readers understand information hierarchy. How much depends on various factors, like screen size, but to avoid having to maintain many different scales, he proposed a typographic scale that avoids breakpoints, by using modern CSS features like clamp() (or a CSS locks based alternative if you don't want to risk failing WCAG 1.4.4). I suggest checking out Utopia to see both strategies in action.

Accessibility, magic and the design system

The power of design systems is that they can make it easier to repeat good things, such as well-engineered components. And they can repeat accessibility, but there is a lot of nuance, because that won't work magically.

Geri Reid (seriously, more conference organisers should invite Geri!) warned us about the notion that a design system will “fix” the accessibility of whichever system consumes it. Sounds like magic, and too good to be true? Yup, because what will inevitably happen, Geri explained, is that teams start using the “accessible” components to make inaccessible things. Yup, I have definitely seen this over and over.

To mitigate this risk of “wrong usage”, she explained, we need design systems to not just deliver components, but set standards and do education, too. At which point the design system can actually help build more accessible sites. For instance, if components contain ARIA, it's essential that the consumers of those components know how to configure that ARIA. In other words, design systems need very good documentation. Which brings me to the last theme: common understanding and why it matters.

Mitigating misunderstandings with better communication

The theme that stood out to me on the day: design system teams commonly have to deal with misunderstandings. Good communication is important. What a cliché, you might say, that's like anyone in any job. Yes, but it's specifically true for our field: design systems force collaboration between such a broad range of people. That includes similar-discipline-collaboration, like between designer and developer. Débora explained what can happen if they don't work together closely, or if breaking changes aren't communicated timely.

But it's also about wider collaboration: a design system team also needs to make sense to other departments, that have specific requirements and norms. Including those that don't really grasp all the technical details of front-end componentisation, like marketing or (non-web) brand teams, or the people who can help sponsor or promote the project. Samantha Fanning from UCL focused on this in her talk on “design system buy-in”, which she had a lot of useful tips about. She recommended to involve other departments early to do “co-design” rather than presenting (and surprising) them with a finished product. She also shared how it helped her to add design system work as extra scope onto existing projects, rather than setting up a design system specific project.

In her talk, Mary Goldservant of the Financial Times, also touched on the importance of communication. She shared how they got feedback from stakeholders and manage expectations, while working on a large update to Origami, the Financial Times' brilliantly named design system, that includes lots of changes, like multi-brand and multi-platform support.

Wrapping up

It was nice to hang out with so many like-minded folks and learn from them. A lot of the challenges, tools and ideas resonated. Once again, I've realised our problems aren't unique and many of us are in similar struggles, just in slightly different ways.

---

Originally posted as Breadcrumbs, buttons and buy-in: Patterns Day 3 on Hidde's blog.

Reply via email

Companies are rushing to add generated AI capabilities to their products. Some promise to produce front-end components for you. Is that even possible, given the nature of accessibility and the nature of generative AI? And is it desirable?

The short answer is no, to both questions. The risk: that our rush to technlogical solutions comes at the expense of users.

To find out why, let's consider: how is the process of building an accessible component different between humans and machines? And what are the ethics of our tendency to reach for technological solutions?

The human approach

Let's look at the differences in process first. A human who writes accessible front-end code, writes (mostly) HTML elements and attributes based on:

• their understanding of specs and how they work together (including HTML and WAI-ARIA)
• what they intend to convey
• what they know about how assistive technologies interpet the code they write
• knowledge of browser and assistive technology support
• looking up the syntax and applying it correctly

(Leaving aside all the useful templating languages and orchestration libraries)

So they translate what they or their designer counterparts want to exist into something that works according to those intentions in a browser. Intentions are a key word here. Conveying author intentions accurately and understanding user needs is essential to accessibility.

They are likely also involved in writing CSS for things like colours, typography and spacing, which can all affect whether websites have barriers for users. And add JS for interactive stuff, managing state(s) and more.

The machine approach

A tool that generates code using language models basically predicts lines of code based on statistical likelihood, a bit like an autocomplete. If the output happens to be high quality, that's, in principal, coincidental. A systems' success rate can be (and is usually) increased by training models specifically with very good examples. In some cases, systems get very close to high quality, because they have enormous amounts of training data. For accessibility, this data is hard to get by—most of the web has accessibility problems: what we can see in the automated tests of the WebAIM Million is just the tip of the proverbial iceberg.

While humans map intentions to interactive content and apply their understanding in the process, LLMs don't have intentions or understanding. They just output blobs of text that matches some input best. I think this is fascinating, impressive and often akin to magic. And the output can look (and sometimes be) production ready and high quality. But it's unsurprising that the output can also contain problems. And as reasonable web developers, we've got to look at the problems we create.

To make this more concrete, let's look at v0, Vercel's LLM-based code generator product that the Vercel CEO announced as:

v0.dev produces the kind of production-grade code that we'd want to ship in our own @vercel products.

(From: tweet by Guillermo Rauch, 12:15 AM · Sep 15, 2023)

I mention this specifically, because I think claims like “production-ready” are an overestimation of the technology and an undervaluation of the need for humans. Which has real-world effects on people.

When I read “production-grade”, I read “accessible”. I had a brief look at the first six components in the ”featured“ section of v0, I found WCAG violations and accessibility barriers in each.

Examples of barriers in each

• in math learning app example: buttons marked up as links, progress indication that was only visual with no text alternative, heading marked up as div
• In kanban board example: list of items not marked up as list, column headers with low contrast, overlapping text on zoom
• in accessibility helper example: overrides existing shortcuts, icons not marked as decorative
• in terminal UI: buttons not marked up as buttons
• in pricing table: icons not marked up as decorative, button with insufficient contrast
• in music player example: various buttons not marked up as buttons, some buttons not available with just keyboard, buttons without accessible names

This isn't a full conformance audit, I just listed the first few things that stood out. I don't mean this as an attack, I just want to show exactly how common accessibility issues in LLM output are.

You might say it's not all terrible, and that's true. I also found lots of markup that makes things accessible, for instance headings that are useful to navigate in various tools, good contrasts and useful + valid ARIA. But that same level of accessibility often exists on websites that didn't involve LLMs. Lots of websites have fairly useful headings, good contrast on many elements and valid ARIA. It's the bits where those things aren't in place where web UIs create barriers for people with disabilities. It's the nuance that matters.

The self-confidence issue

In Can generative AI help write accessible code?, Léonie Watson looks at the output of three other generative AI tools (ChatGPT, Bard and Fix My Code). Like me, she found things that weren't terrible, things that were actually helpful and things that constituted accessibility issues. But Léonie points out a different problem: these tools thend to present themselves as authoritative. Regardless of whether they are. She explains:

Other than the generic statements about the need to check its responses, none of these generative AI tools gives any hint that their answers may not be correct or provides any recommended resources for checking".

In contrast, most good blog posts and resources about accessible coding have a lot of nuance in them. They usually can't recommend one authoritative solution that is guaranteed to work at all times (what definition of “work” would they use?). And that reflects making accessible interfaces in general. It involves rabbit holes. There are generally multiple ways and multiple least bad outcomes to balance between.

Ok, but can LLMs at least be partially useful?

Maybe the problem of authoritativeness could be solved. We could tune these tools to output responses that don't present as mansplainy know-alls. But that still leaves us with other problems: inaccessible suggestions, lack of intention and understanding and lack of innovation.

Falsehoods and hallucinations

LLMs give inaccessible suggestions, as demonstrated in the examples I shared above and in the examples in Léonie's post. If these falsehoods are a consequence of training data, that could be improved with different training data (emphasis on “in theory”). But it's also due to “hallucinations”, a problem inherent to the tech that research shows is inevitable. They make wrong stuff up. Output may be nonsensical. At the expense of users. That can't possibly be an improvement to the status quo: even without “AI” there are plenty of accessibility tips on the web with specific bugs or issues, automating the addition of falsehoods and hallucinations to the mix seems absurd.

Lack of intentions

LLM tools don't have intentions, and intentions are necessary for (most) “accessible coding”. In his post Why doesn't AI work for producing accessible code, Alastair Campbell explains accessibility is not an average. That makes it incompatible with statistical methods to make suggestions.

Lack of innovation

While there are lots of open source component libraries, many UI patterns and their implications haven't been invented yet. Their assumptions dearly need testing. Relying on LLMs for suggestions means relying on (remixed) existing knowledge, so it's unsuitable for making new patterns accessible.

These three reasons make me wonder: are LLMs useful at all in assisting us in building accessible front-end components? If there is a use, it's probably in helping developers discover resources that do contain nuance, not in code suggestions. Maybe there are also uses outside of component code, but that's for another post (see also Aaron Gustafson's Opportunities for AI in Accessibility).

The focus

Probably something for a post on its own, but I feel I should mention here: a focus on trying to find a “fix” or “solution” for accessibility constitutes a misunderstanding of what accessibility is about. When we make websites, the onus is on us to make them accessible. If we want to try and outsource that work to a tool (that we can't trust), we put the onus on disabled users (see also: disability dongles).

As Adrian Rosellli wrote in AI will not fix accessibility, accessibility is about outcomes, not outputs:

Accessibility is about people. (…) When we target output versus outcomes, we are failing our friends, our family, our community, and our future selves. We are excluding fellow humans while we try to absolve ourselves of responsibility. (…)

Eric Bailey posted:

Thinking AI will "solve" accessibility is a bad frame stemming from a technoableist mindset.

The industry seems to me hoping for a magic, binary solution (…) Personally, I'd look to the social model of disability for guidance here: what exactly are we looking to "fix" and why?

In summary

Is the nuance that accessibility usually needs generatable? I think not. Not reliably, anyway. If you take away one thing from this post, I hope it's this warning: LLM-based tools can't be the magic bullet for writing accessible component code that they promise to be. Because nuance, understanding and conveying intent are inherent to accessibility, LLMs cannot be of great help with the accessibility of component code. In addition, they hallucinate inevitably and tend to pose as authoritative while outputting (occassional, but real) falsehoods. The latter can be dangerous and is likely to come at the expense of users.

My suggestion to developers who want help building accessible components? Use a design system that's well tested with people, that is well documented, and that (at least) attempts to capture the nuance. Or get involved in building one. Not everyone wants to do this nuanced and precise work, not every organisation has the budget. That's fine, but let's not suggest it can be automated away, magically. Let's value the human effort that can make web products actually great.

---

Originally posted as “AI” and accessible front-end components: is the nuance generatable? on Hidde's blog.

Reply via email

The amount of content on the web is so large, that it's tricky to find the stuff worth reading. One of my strategies is to follow people I trust and read what they share. For anyone with interests similar to mine, I've opened a Links section on this website, too (with it's own RSS feed).

My plan is to publish no more than a couple of links per day (if any). They will mostly be related to technology and/or ethics. I have taken inspiration from many others, like Jeremy's Links section. Mu-An inspired me to use Shortcuts as a tool to create links and notes.

Why?

The reason I want to publish links on this site is mostly for selfish reasons. I've posted links on social media for a long time, but in the black box of algorithms, it's hard to recover them after time passes. I want to at least try and have some sort of system for organising and archive my interests (tags… I'm adding tags).

I also want to try and experiment with shorter, quicker posts.

How: low treshold publishing with a Shortcut

I read mostly on the go, when on public transport or waiting for an appointment. This means I usually am not logged into a CMS or near a computer where I can do version control. This site doesn't use a CMS, but I have (Markdown) files in version control that I populate a static site from. To appear on my site, links shared would ultimately need to exist as Markdown files in a specific folder.

This is what I wanted for my link sharing system:

• Very minimal effort
• Should work on all devices
• Should draft a note with both currently selected text and a link to the page, named after that page
• Should also include the current date in the draft and let me title the note
• Should place my draft somewhere that I can move to my site quickly

What I ended up with is an Apple Shortcut that takes the current text selection, page name and page URL on a given page in Safari and creates a blob of text with current date, selection and link prefilled. When I run it while in Safari, a popup opens with something like this prefilled:

--- 
tags: []
date: 2024-01-10
---

> // Selected text

(From: [Name of the page](link to the page))

I can then write some context around the link, optionally add a comma-separated list of tags and then save the file. The filename becomes YYYY-MM-DD-.md, where I can write a title for the post after the date. My site generator grabs that title from the file name.

At the time of writing, I haven't figured out how to then get this file in git, so I save it in a specific folder, requiring me to manually drag it into my site whenever I do reach a computer. That works fine for now, I don't write that many anyway.

Summing up

I'm looking forward to continue doing this for a while, and hope the low treshold publishing will make it so easy that I actually will. Check out /links to find out what I've posted so far.

---

Originally posted as Sharing links on Hidde's blog.

Reply via email

In the nineties, Clippy lived inside the Microsoft Office suite. It was an avatar of an actual paperclip that would interrupt your writing with tips. Did it provide lots of value? I can't remember. I recall there were good easter eggs. But I don't think it really fixed our productivity in some groundbreaking way. A cute relic of the past, in a time where a lot less people were using computers daily.

Fast forward to this week. I used the current version of Microsoft Word, on the web, to write a thing for work. I wrote a headline. Let's say it was “Marketing 2024”. You won't believe what happened next. A blue circle appeared next to the headline. When I hovered over it, it asked me if I wanted it to insert an image. “An image?”, I thought, somewhat surprised. Was this what the future looked like? Did Clippy return? It certainly got in the way of my writing. When I obliged, it put in a random image that felt very marketing-plan-y. It also showed me a gallery of other images for me to pick instead.

A blue dot appears. When clicked, it inserts an image into the writing flow

It left me with lots of feelings, the main one being how unnecessary all of this was. All that computing power!

The “AI” feature I described assists with images, but Microsoft are rolling out Copilot across many of their products. It can also write new text, or improve existing text in ways you specify, the kinds of features we've seen large language models provide. Copilot is a clever name, and a clever framing of what these chatbots can do: they're not the main driver, that's you as a user, but they can be there alongside you.

And yet, I'm not convinced these features are helpful. They interrupt a flow, the actual content production. And they're actively pushed onto users, from in-software notifications to promotional webinars. If that push is successful, everyone in the world will have to put up with the fruits of these features. It's to be seen what those fruits are: content that is better, content that is more superfluous or a bit of both?

User need?

Do these features empower users? They appear to, from the onset. Of course, a lot of the world's marketing plans look very similar, people probably already copy pasted them from one another or used boilerplates. This just makes recycling old ideas available through a different interface. It makes it easier to make something to that seems ok.

But ultimately, is it the right kind of support? Personally, I want software to push me not towards reusing what exists, but away from that (and that's harder). Whether I'm producing a plan or hefty biography, push me towards thinking critically about the work, rather than offering a quick way out.

To be fair, Word has some features today that help you improve content, but mostly to correct style, grammar and punctuation (nice!). Well, and, I'm not making this up, to help remove “sensitive geopolitical references”.

I did ok on formality and sensitive political references

Writing as trying to discover something new

When I write or (publicly) talk, I hope to write or say something that is relatively unique. Obviously, I don't have the illusion I actually do, unique things are rare, everyone's always iterating upon the work of others. But to at least try to find a new perspective is the point of most writing (if it's meant for reading or convincing). That's what we're all trying to do, right?

Whether it's marketing copy, a techy blog post, a stage play or a philosophical treaty, would anyone set out to produce something similar to what already exists? Would the stage play sell tickets if it sounded like the same old? Would your product sell if you use the same copy as your competitor? (Ok, that last one happens all the time)

Discovering new ways is central to creativity. When Miles Davis recorded his groundbreaking album Kind of blue, he gave musicians scales and melody lines, and asked them to improvise. They hardly practiced and did not know the music inside out before they started. Herbie Hancock explains this made the whole album a lot more spontaneous:

Miles' idea was that… he wanted to capture the spirit of discovery in the music. (…) He wants to capture discovering the music on the record.

(in: The making of Kind of Blue, 6:22)

I recommend that video, it's full of people who understand music and this music in particular. They try and explain some of the creativity of this particular piece.

Of course, most writing doesn't have to yield a creative masterpiece. But it's probably that sense of discovery where, like making music, writing gets most interesting. For writers and for readers. More than recycling old and making grammatical and stylistic improvements (quite useful), writing assistants could drive us in the direction of discovery more.

Unnecessary “AI”

It's not just for fun that I'm calling “unnecessary” on this feature (and who am I to judge, or, frankly, who do I think I am?). This is feature that people probably worked on hard and that some users may find very useful. But still, it's worth considering the need. Large language models, that most “AI” features are based on, cost a lot of computing power, both training them and running them. The training also involves a lot of (underpaid) labour of people, who classify content to make the magic work. And then there's all the knock-on effects on society of having harms perpetuated and being stuck with lots of content that nobody thought was worth writing in the first place.

We've got to think about whether or not the features we build with this are actually useful, actually unnecessary or somewhere in between. We don't have to add “AI” to every product, even in an industry where we see investors push for that, we can choose to do otherwise. (</man-yelling-at-cloud>). One company stood out thinking about this especially carefully in the last while: iA wrote Writing with AI.

---

Originally posted as Clippy returned (as an unnecessary “AI”) on Hidde's blog.

Reply via email

Wait, what, it's only a week until 2024? Time for what has become a yearly tradition… in this post, I'll review some of my 2023 in work, conferences, reading, writing, listening, music and learnings.

Note: like my posts about 2022, 2021, 2020, 2019, 2018 and 2017, this post is mostly ‘highlights’, lowlights left out intentionally.

Work

The work year was different than usual: my full time job (first in 10 years or so) ceased to exist and I switched back to freelancing.

Freelancing

In July I joined the NL Design System team (almost) full time. We support a community of web specialists from across the Dutch government to create open-source components and guidelines for all. I joined as an accessibility and developer relations specialist. Now I'm PR/communications lead, with still some time for accessibility (but none for devrel). The project is very much up my ally. I really like the colleagues. I also feel fortunate to bring my experience into this team. And, of course, just as fortunate to have made it once again into a team where I get to learn lots from the others (and all of the design system, government, accessibility and development experience between them).

Outside of NL Design System, I did some in-house workshops, talks about the web and web accessibility, and the occasional WCAG audit.

Volunteering

I continued in Open UI CG, mostly scribing, learning and then conveying some of the work to developer audiences in blog posts and talks. It's still one of my favourite meetings of the week.

Other volunteering didn't work so well. I joined the marketing team of my local solar energy community, made plans but found no time to properly work on them and left. I also joined the CSS WG as an Invited Expert, a long time dream come true. But so far, I only managed to join one meeting and only marginally kept up with emails and issues. Let's say between when I said yes and when it was official, a lot changed at work and I wanted to spend more time with family. I hope they don't revoke my status just yet and hope to start prioritising my WG involvement sometime in 2024.

Conferences

Last year, as the popover attribute started to make its way into browsers, I hoped I would do a talk about the nitty gritty of building popovers (repeating the phrasing I used last year). That happened. I wrote that talk and took it to a number of events. In addition, I made a new talk called “ARIA, The Good Parts” and did a 10 minute rant for the IAAP-EU called “Will tools save us?”.

At CSS Day, I met the hotel cat once again

All my talks in 2023:

• Shifting left: making accessibility easier, by doing it earlier at a11yTalks (online)
• “Dialog dilemmas and modal mischief: a deep dive into popovers and how to build them”, I like long names, what can I say? This popover talk happened at JSNation (Amsterdam) (7 minute edition, with transcript), CSS Day (Amsterdam), Front Conference (Zurich), HalfStack (Vienna), Covent of Wisdom (Eindhoven) and React Advanced (London)
• “ARIA: the good parts” at Paris Web (Paris, obvs), NDC (Porto) and WeAreDevelopers (online)
• “Will tools save us” - introduction to a panel for IAAP-EU's celebration of the 3rd anniversary of the Web Accessibility Directive (Brussels)

I also attended Beyond Tellerrand in Düsseldorf and State of the Browser in London.

Reading

I read a bit less than in the last year, most of them while on holiday or travel (see: full reading list if you like book covers). These are some books I can recommend:

• Just Human by Arielle Silverman (auto biography), in which she shares her own experience being blind within the context of society, from the moment she was born to the age of 36. Learned a few things about the workings of ableism.
• Make me one dimensional by Sang Young Park (novel). Murder mystery, friendships and growing up.
• Doe zelf normaal by Maxim Februari (non-fiction), on the role of “datafication” in society. Original, clear, funny at times, witty.
• Le Perfezioni (De perfecties) by Vincenzo Latronico (novel). On gentrification, Berlin, millenials.
• Tomorrow and tomorrow and tomorrow by Gabrielle Zevin (novel). The videogame industry, sudden success, weird relationships. Was told this is ‘a TikTok sensation’, but won't let that ruin my feelings about the book or my liking it. Consumed this as an audiobook on a few long drives.
• Binge by Douglas Coupland (short stories), 60 (!) stories, loved most of them, easy to read in between other tasks.

Music

Saw more live music than in the year before (yay, thanks to babysitters and being more ready for their help as a family). I got lucky that the artists I listened to also toured near me on the right dates, so I got to see:

• Little Simz, at North Sea Jazz. Was spectacular. Would have loved a full band, vocals etc, but even without that it was great. I was introduced to her No Thank You album, worked my way back through Sometimes I Might Be An Introvert and Grey Area, and now I'm all in Stillness in Wonderland, it was a fantastic musical rabbit hole.
• James Blake, at 070. I don't understand how he makes music (how do synthesisers work?), but the new album is great and sounded excellent live. Some fans knew it was birthday, so we all sang.
• Esperanza Spalding, also at North Sea Jazz. I'd not heard of the fairly sexist song ‘Girl Talk’, but the way she performed it with Fred Hersch was awesome (see Girl Talk on YouTube).

I also listened a lot to De Jeugd van Tegenwoordig, Sault, Sef, WIES, Massive Attack and Typhoon.

I made a live music log to track concerts publicly (inspired by Vasilis).

Writing

Including this one, I wrote 15 posts this year, some lengthier than others. Less than usual. There's a bunch of drafts that I'm looking forward to finish!
Of this year's posts, most shared were an FAQ on accessibility and one on ableism in the Vercel community.

Most sceptical were a few posts I wrote about ‘AI’, where I said that opt-out is rude, ‘AI’ content isn't user centered and LLMs are not artificial, nor intelligent.

Cities

I stayed in Taipei, Kaohsiung, Düsseldorf, Porto (2x), Berlin, Zurich, Vienna, Paris, Brussels, London (3x), Bristol and Porto.

I wanted and was able to do a lot of this year's conference travel by trains, twice by night train. The latter aren't cheap if you want some comfort (I went for beds), but very pleasant and lower in emissions than flights would have been.

Saw hot air balloons in Bristol

Learnings

Some random things I learned this year, in no particular order.

• Social media doesn't need algorithms for that real community feel. I still like it on Mastodon and still mostly left Twitter and Bluesky. I still use Instagram (to follow artists) and LinkedIn (to follow a random mix of people that never came to Mastodon).
• A lot about electric cars (and probably still too little). Quite the rabbit hole, but I bought one, so that I can stop buying petrol. I didn't want to buy one without researching some ins and outs.
• In git: to fix commits further back than the very last one, by doing fixup commits and autosquashing them. I hope I won't forget.
• Lots of words in Mandarin (~1000). I had some formal courses, but midway this year I started Duolingo (add me!). It uses simplified Chinese characters (not traditional) and Taiwanese friends and family scold me for that. But honestly, the upsides outweigh the downsides for me.
• Fresh YouTube accounts (I set one up for work) recommend even more extreme-right content than my many-years-old one does. I wish I could turn recommendations off altogether.
• Conference speakers are actually just humans.
• Lots of things about government departments and how they work together and the meanings of very specific acronyms.

Wrapping up

Thanks for reading, hope there's useful recommendations in this post. If you're still reading let me end with my best wishes to you for the new year, see you in the next!

---

Originally posted as 2023 in review on Hidde's blog.

Reply via email