Last year I set out to rekindle my reading habit. That went well. This year’s reading has been enjoyable, but I’m not cozy with the ratio of non-fiction to fiction I’ve read this year…non-fiction (especially of the computing persuasion) far out balances the fiction I’ve read. I think this is mostly because I’ve been mired amidst a fiction book that I’ve found to be a slog…but enjoyable, too. I’d have abandoned it and moved on, elsewise. Onward!
Spring is quickly making way to summer here in Maine. The school year is fully geared up to end at any moment, and summer adventures are aching to start.
We don’t have anything huge planned this year — but we have more than we’ve had on deck for the past 5 years or so. I’m honestly a little anxious.
In an attempt to be more social, and not fake social-ness by occasionally posting these missives here, this weekend I was slated to attend an in-person game jam. Fate conspired against me, though, in the guise of an ill kid, and I was unable to attend. I was hoping to cobble together a game of some sort to help me think through what a simple game engine might be like implemented in apl, or another array language.
Here is a fun article on early computer art from Amy Goodchild.
Like so many other folks of late, my family has been deep into Zelda — but not the new Tears of the Kingdom game. We haven’t cracked that one, yet! We’ve been enjoying Links Awakening and Breath of the Wild.
…I joked about the Zelda games and pastoral art in another post a while back, I think, but can’t stop thinking about it in earnest now, especially Breath of the Wild, which literally features a flavor of pastoral art in cut scenes, all while relishing in an in-game art style that inches oh so close to romantic landscapes. Lots of juicy visuals to love.
Something left out of the original draft of this post:
I’ve started a fork of ngn-apl! My plan is to leave the core functionality in place, but to layer on some accessibility and mobile-friendly improvements to the web interface.
First afternoon at the beach this year!
A bit of this and that, some kind of mishmosh.
Over the last few weeks I’ve been reading a lot about array programming systems like J, K, Q, APL, and BQN. I’ve been intending to add a page to the wiki about them, but haven’t gotten to that yet. Consider this a little promise that I’ll do that sometime soon. I’m interested in array programming less because I think it’s particularly useful for me (it’s not) and more because I am captivated by the poetics it invites.
If I had a personal theory of programming (I don’t) it would be something like
programming is writing poetry that acts on input and data to cause a known effect.
Array programming systems invite a different sort of metre and verse to that poetry. They force ya towards something like haiku whereas most other languages want you to stick to a yawn inducing iambic pentameter.
Beyond that reading, I re-watched the original Star Wars movies — IV, V, VI — this past week with my older kid. Their reaction to them was skepticism, and being convinced that the Ewoks ate the dead Imperials after the Battle of Endor…which could be true?
A blog post I wrote a few months back at work got published. It is my attempt at sneaking in some thoughts on permacomputing into a more “normal” setting. The timing of the post was oddly synchronous with a few things, one of which is my thinking a lot more about permacomputing:
A lot of the dialogue around permacomputing that I’ve seen seems intertwined with a certain aesthetic sensibility that is entangled with the demo scene and retro computing communities. While I think both these spaces are kinda rad, I think they’re specifically prone to a certain flavor of navel gazing…a flavor focused on specific tech stacks, and tooling, and apparent minimalism. It’s a flavor that leaves a gap in the conversation around what I’d call the “why” of permacomputing.
Most of the conversations I see are hyper focused on the “how” and “what” of permacomputing. “How” and “what” cover the skeleton, “we use X system running on Y reclaimed hardware.” The discussions that gesture at “why” that I see tend to be like “because it’s the more harmonious way to do computation given that we’re living amidst climate collapse.” And, while that is a great reason for choosing lower impact tools, I think the community generally misses what I see as the most important bit of permacomputing:
Let permacomputing be an invitation to question why and how much computation ought to be involved with a thing, and, if that computation is being used to increase or decrease the anomie between folks…and with what impact to the world?
My take on permacomputing is that it’s a way of approaching computation that’s further distanced from the goals of capitalism. It is an effort to re-imagine our tech landscape, and in so doing enchant it with values that support, for lack of a better word, “balance.”
Some things of note, links mostly:
First and foremost, I found a suitable pinboard replacement in link hut! Shout outs to my buddy Bruno for the tip.
Here’s a bookmarklet I wrote to make it a bit more ergonomic for how I like to roll,
javascript:(function () {
const tags = prompt('A space separated list of tags.');
window.location="https://ln.ht/_/add?url="+encodeURIComponent(document.location)+"&title="+encodeURIComponent(document.title)+"¬es="+(window.getSelection().toString())+"&tags="+(tags)
})();
That will snag any selected text and pop it into the bookmark’s description after it prompts you to enter some tags.
Next, a confession: those who know me know that I’m cynical about all tech. So, it should come as no surprise that I’m deeply cynical about the current bloom of AI, a la ChatGPT.
…well, curiosity got the best of me and I tried ChatGPT out.
And, honestly, I’m still pretty cynical about the whole vibe — I started to write some discombobulated thoughts about all that on my wiki but haven’t gotten anywhere with that line of thought yet — BUT, the thing I have found ChatGPT incredible for is that it has totally replaced my least favorite weekly chore! Menu planning.
I loathe menu planning. It is weirdly stressful and we have a handful of interconnected constraints on our menus and it was exhausting for me for some reason. I always dreaded menu planning. Well, ChatGPT has solved menu planning for me, and I guess that is cool?
I said unto it: “please suggest 4 week’s worth of dinners for a gluten free, vegetarian family of 4 including recipes and shopping lists.”
…and it worked.
Insane with power, I submitted the same request with some minor tweaks 6 more times. I used the responses to build an archive of recipes paired with shopping lists. I’ve added a few items, and I’ve made myself a little tool to randomize a menu and shopping list.
Now ya’ll know my shame.
My birthday happened this month, for it I got 2 lovely gifts:
- Sandra fulfilled my birthday wish by making me a bespoke emoji of the 😬 face backing into a bush
- a whole pile of video games
Among the games are two standouts:
Eastward is specifically amazing because it hits every button right for me — I’m a sucker for the type of story telling it engages, as well as for Vermeer-level pixel-art. The graphical story telling, and world building are all kinds of good.
Speaking of pixel-art, I continue to work on a little Game Boy game. To empower my doodling around with that while on work meetings I pulled together a little pixel-art editor.
Spring has been teasing us here in Maine. Hints of its arrival abound, yet it remains sloppy and gray outside…sock weather purists.
I’ve been experimenting. I’ve been concocting a recipe for vegan kugel, and rediscovering little features and edges of my website I’d forgotten I baked in. Like chocolate chips hidden in an oatmeal raisin cookie.
One chip most recently re-discovered: support for per-page custom styles?! All I gotta do is include an optional bit of meta data, bespoke-css, that points to a style sheet. I may play with this feature more. I do love myself some css. I can tell exactly when in my life I added this feature because these days I’d never call such a thing “bespoke-css” — it would get a much more boring, terse label, like “css” or “styles.”
The kids have been home on school break this week. We’ve been having a lot of fun reading The Wind in the Willows aloud, and playing a bit of No Man’s Sky on creative mode. You wouldn’t think it, but each carry a really similar vibe. Cosmic-pastoral-localism?
In the last week notes I made mention of potty training; at first that was harrowing and seemed like it would never happen. Then, all at once, it did!
I continue to expand the newly formed wiki. My plan isn’t to catalogue everything and anything — outboard brain style — but to really only document stuff I find useful and that I want to keep track of for myself…that maybe will be useful for other folks, too? The acme page is probably most inline with what I’m going for.
For good times, check out ratfactor’s rad presentation on forth!
I’ve also been playing with babashka, reading it’s excellent companion book, babooka. Babashka is a wicked fast way to use clojure when you’d normally reach for bash.
In accessibility and the product person I said
we need to make accessibility a core part of our processes
Here, I want to talk about that in more detail. I want to briefly explore what making accessibility a part of core processes looks like, and how that is different from centering accessibility as a priority.
RICE is a scoring model many organizations use to prioritize what to focus on. If you aren’t familiar with it, RICE is an acronym that stands for reach, impact, confidence, and effort. The idea is that you assign a point value to each facet, and use the sum of those points to help determine priority between a few competing ideas.
If accessibility isn’t part of your core processes and baked into the culture of your work it will show up as one of many competing ideas all placed against each other in the RICE model. When pitted against other ideas, and when using tools like RICE, accessibility, and equity concerns writ-large, are gonna loose. They’ll be considered, discussed, added to the backlog, but, almost never prioritized. They won’t be prioritized because, across the software development landscape, accessibility isn’t a profit center, it is a cost driver.
But this is a solvable problem.
Stop using RICE and tools like it that don’t include accessibility and equity as facets of their model.
Add it if it isn’t there.
By adding them as a facet, RICE+Equity, you make accessibility a key part of all your decisions. You can still put the accessibility projects up against other ideas, but no matter what, by baking accessibility (and equity, generally) into the frameworks used to determine priority we can begin to ensure accessibility is a core consideration helping to guide all product decisions, and not left as a project on the backlog.
I recently re-read Peter Naur’s “Programming as theory building”. Afterwards I set out to write my own text editor. The paper posits that it’s really hard, if not impossible, to fully communicate about a program and sort of gestures at the futility of documentation…what spun around inside my head as I read was that our primary programming medium — text files — is silly. Like, some folks would totally 100% scoff at my writing forth but, at the end of the day, forth and javascript both produce executable text files despite being lightyears apart. What if a text editor let us have something more than just text files as artifact?
So, like many before me, I started to write my own text editor. And it sucked. What I made sucked, and the process itself sucked…or, at least, it didn’t lead to anything particularly different from the vast array of existing text editors. I wanted to be able to support a different paradigm of writing code, I didn’t wanna just produce vim with worse ergonomics. I didn’t make much progress, even leveraging web technologies that gave me a lot “for free,” because before I could begin to reinvent any particular wheel I had to crawl out of the primordial ooze…
Then I realized I didn’t actually want to implement my own text editor! I’m not a fanatic about what editor I use; I’m pretty evenly split between sublime text, emacs, text edit, vim, acme, and mg. I bounce between them depending on what I’m doing, and for how long I’ll be doing it. What I wanted was to be able to support a slightly different mental model of what a “file” is using any existing editor!
That was an easier technical nut to crack. It took about 2 hours after the kids went to bed with a little bit of help from the inimitable llimllib on mastodon…and all I did was write a shell script!?
So, my personal solution to the cutting edge of programming being just text files is to add even more text files!…at the end of the day, they’re a really really hard thing to leave behind, especially if you’d like to preserve compatibility with any existing programming system.
I wrote a shell script called Moon Maker. Moon maker, or mm, lets you attach orbiting moon files to central planet files. A planet file is the one you really actually care about — its probably a file in a project. A project can have any number of planet files, and a planet file can have any number of moons in orbit of it. Moons are files that orbit a planet, they’re places to take notes, a scratch space, somewhere to try things out, or add layers of information about the planet. A moon file can have any file extension, and references the planet by it’s name. Moon files live in a directory of their own, .moons, and each can be referenced by a unique id, or, collectively by the name of the planet they orbit.
Moon Maker
⋆｡°✩ ☾
mm is a small program that lets you add orbiting moons to existing planets.
A planet file is the one you care about -- probably a file in an actual project.
Moon files orbit planets, they are disposable scratch spaces connected to planets.
usage: ./mm
-i(nit)....initialize a directory to store moon files
-o(pen)....open a planet file and all of its moon files
-l(ist)....list all moons for a given planet file
-a(dd).....create a new moon file for a given planet file
-d(elete)..remove a moon file by its id
-c(lear)...remove all moon files for a given planet file
-u(pdate)..rename a planet file and all of its moon files
The idea is you use mm sort of like you’d use git — you initialize it at the project level, and then add moons to planets as needed within the context of a project.
By default, moons open in your EDITOR of choice, but I’m thinking of adding support for editor overrides so you can easily open planets in one tool, and moons in another.
I don’t honestly expect many or any folks to use this thing, but I’m excited too. It matches my mental model, and, my process: usually, when I’m working on a project, I end up creating a bunch of temporary or scratch files to document little corners of something, and experiment. This enables that in a consistent way across my projects while maintaining compatibility with all of my existing tools. If this works out, and doesn’t have any toothy gotchyas I’d like to support adding moons, satellites maybe, to specific lines, or regions of a planet file, too. My first attempt at this thing was more elaborate — rather than bash and saving to the file system, I tried to do something with sqlite, and having a database backing each file of a project.
The idea was to support using any convergence of row and column number of a text file as an id, and then generate a connected moon from that. This was a cool idea, but so fragile as to be untenable. Plaintext doesn’t offer a great way to reference specific points in a file if that file is changing.
This post is a slightly modified version of a talk I presented to the product practice at my work. It presents a few ways that product designers and managers can help to move accessibility forward. It is a little bit different than what I normally share, here, but, I thought it may be interesting to some folks.
I’m not gonna make a case for why accessibility is important; my hope is that we’re pretty well aligned around why.
Today I’m going to focus on what product folks can do to push accessibility forward.
The tl;dr of it is that we need to make accessibility a core part of our processes:
- We need to add it to our acceptance criteria and definitions of done if it isn’t there already.
- We need to have a plan for how to improve our products’ accessibility and know that compliance isn’t the goal, but the minimum. It is the floor. There is always room for growth.
- And, as we achieve accessibility, we can celebrate those successes. Sharing how we’ve done it, and why.
Many product folks have shared this meme. It is beloved in the community because it offers a concise vision of product, and tugs at some nostalgic heartstrings while doing so.
I also think that this meme offers a vainglorious view of product.
How annoying would an awesome burial form be? Or a tax form? These shouldn’t be noticed. No one should remember these forms for good or ill because these services are doing their jobs if they work and are totally frictionless.
Most of the products we work on are infrastructure that folks are obligated to interact with.
A real life example of a frustrated experience that we can see today is Namely’s PTO request form. That form takes a sighted person who can use a mouse a few seconds to complete. I urge you to try and complete that form using either a screen reader or only a keyboard. No mouse.
It is a gnarly-cumbersome experience because one of the form fields isn’t directly reachable from the keyboard.
When products aren’t accessible folks don’t have a clear way forward. So, how can we avoid confused, and frustrated Mario here?
The PTO request form on Namely isn’t empowering rad shit, as the meme says, it is frustrating and makes what ought to be a simple task a difficult one.
It makes what should be an unmemorable obligation an annoying experience.
But how do we avoid this? How can product folks help to prevent this situation?
Accessibility is often seen as a concern for UX and engineering — today I’d like to say that product folks are also key to creating accessible stuff.
My suggestion is to stop thinking about inclusion and start thinking in terms of exclusion.
By identifying points of exclusion, those moments where folks are either wholly forced out of your product, or, more likely, have to come up with homegrown workarounds to complete some task, we can start to take actionable steps towards more inclusive products!
Sometimes you may have to make the hard choice of who’s in and who’s out; I think this is the type of choice that product should make, not growth, not sales, not engineering or design. Product should make this call because product often has the longest memory — product folks can back the choice up with data and continually work towards products with fewer points of exclusion.
If someone has to be excluded at least have data about who, and immediately work on a plan for how to bring them in.
Thinking in terms of inclusion tends to lean aspirational, while by framing things in terms of those points of exclusion we can more easily come up with actionable steps to help create more inclusive products.
Again, how though? How can we identify points of exclusion…especially when we’re talking about something that hasn’t been built yet?
We start by examining the assumptions we’ve made and making sure that they are informed by research, and also informing new research.
- Are our assumptions excluding anyone?
- Are there folks who are having to work around any assumptions we’ve made?
The popularization of hashtags on twitter is an example of this, or a child climbing a counter to reach a cabinet in a kitchen.
- Twitter’s initial assumptions didn’t include groups wanting to use it as a tool for organizing, but folks worked around this hole by developing the hashtag. Twitter reacted to this, and baked support for hashtags into the platform.
- If a kid has to climb a counter to reach a cabinet, they’ve been excluded from that space, perhaps for a reason though?
What assumptions informed these choices?
Of course, the best way to interrogate your assumptions is to include disabled folks in the discussion. Folks excluded from your product and the system that produces it — that isn’t always in our power and is a bit out of bounds for this presentation, but, include and prioritize these voices whenever possible.
Next we make sure we have metrics about accessibility.
This, in my experience is the trickiest of my suggestions. A lot of things look and smell like metrics about accessibility, but end up being metrics about delivery.
To help ensure that our metrics are actually about accessibility, which is less an end-state and more a practice, or way of working, I’d suggest that we start by having metrics that focus on our teams’ processes and tracking how we approach accessibility in our day-to-day work.
Rather than track that we delivered some number of accessible components, I suggest that we track that our team has a plan for improving accessibility — like a tiny maturity model — so we can track this improvement in our processes.
For example, a metric tracking the number of components you shipped to production that include accessibility guidance.
Last but not least, don’t hold a meeting where you don’t mention accessibility, and, maybe most importantly, celebrate as you continually achieve accessibility beyond compliance.
We hear a lot about gaps in accessibility, and rarely about victories.
Because of this I think there’s an idea that accessibility is all about compliance and gloom; whereas we have an opportunity to make it about playgrounds and connection and innovation. It can be the next chapter in how we do this thing we do.
That is probably my most important point:
- Celebrate as you achieve accessibility to help show that it is doable.
Just like when “mobile-first” was the catchy rallying cry, we can celebrate and spread “accessible-first” methodologies and help to popularize it as a core principle for any new projects.
Accessibility isn’t the sole responsibility of specialists, it is a facet of the work everyone does.
Achieving accessibility beyond compliance isn’t possible through technical means alone; it also involves a certain amount of cultural change. I think cultural change is a responsibility that a product practice carries.
When folks started to embrace mobile, some businesses did quick fixes to update existing solutions so that they’d work on smaller devices. This is akin to accessibility remediation work.
Other businesses adopted mobile-first design methodologies, making mobile a key principle from which they worked. This is like doing accessibility beyond compliance.
An accessible-first approach, an approach that goes beyond compliance, invites the creation of more adaptable systems that are ready for situations we haven’t imagined yet.
With mobile, folks who had an adaptive, mobile-first methodology were able to take the introduction of tablets in stride, while those folks who’d been focused on only supporting the known form-factors had to do more work to keep up.
Product folks have an opportunity to bring “accessible-first” thinking to their work, and help cultivate a culture that strives for accessibility beyond compliance, and in so doing, ensure that we are all better prepared for anything that might come along.
A huge thanks to Josh and DK for sharing feedback with me while I came up with this presentation.
Some questions to consider:
- What are ways to interrogate your and your team’s assumptions?
- Are there tools that can help with this?
- What are some possible metrics that can be used to gauge the health of your team’s accessibility practice?
- How can you make those metrics meaningful for stakeholders?
- What are ways you and your team can celebrate your successes that can help set you up for more success?
- A higher-level kinda question: what is the role of a product person in helping to define a team’s culture?
I’m feeling pretty chuffed! Last week I wrote about my intention to make this website more accessible. My motivations were many-fold, but, primarily, mostly shame. I’ve worked as an accessibility specialist in the past, and now spend a bunch of my days at work looking for ways to make public infrastructure online more accessible. It seemed fitting to at least make sure the little bit I contribute to the web here is also accessible.
I thought it was going to be more of a project than it ended up being. Oatmeal is passing with mostly flying colors according to a couple different browsers’ in-built accessibility auditing tools, VoiceOver, axe, WAVE and IBM’s accessibility scanner.
I focused on improving a few key areas:
- color contrast
- markup structure
- navigation
To achieve better color contrast ratios I know I could have employed math, but, instead, I didn’t do anything scientific — I used trial and error to land at a slightly updated color scheme. Along the same lines I also increased the default text-size and made sure that link text was visually unique along an axis other than only color. Underlines, baby!
The markup was the issue that had me thinking I was gonna have to do a soup to nuts rewrite. I ended up finding a handful of big wins, though, so was able to make a lot of progress pretty quickly. The biggest win was tearing out a lot of indieweb-specific markup. I think it isn’t that hCard’s and what not aren’t accessible, they just lead to a really “chatty” page if poorly structured, and mine were poorly structured.
The markup updates flowed into improving the navigation. I’ve always leaned heavily on this being a blog, with everything structured around a gigantic chronological list of posts. That’s boring, though, and not all that conducive to actually finding stuff that isn’t chronologically recent.
The site’s navigation still lives mostly in the footer. Now there’s a skip link to get there more easily (try it! Use the tab key to trigger the skip link). I’ve also added a handful of new pages that invite folks in through some different entries — doors and windows and whatnot.
With these changes made, I’m feeling better about the state of this thing. There is 100% certainly more that can be improved, though, so, I’m gonna consider this the start of an ongoing project.
The worst kind of blogging is blogging about blogging, so, I’ll keep this blogging about blogging short!
I’ve made some minor updates to the design of the website that have improved it’s usability a wee bit, and are a step in the right direction toward upping my accessibility game. The major remaining accessibility issues are around color contrast and some structural stuff.
I’ve started to introduce an updated color pallet to resolve the contrast issues. The structural stuff is going to be a wee bit harder to address, but I’ve started to make inroads there, too, mostly by removing a lot of indieweb specific microformat markup. The entire site should be more or less totally navigable by keyboard now.
I’ve also added a page to help situate folks and invite ya in to different ways of finding stuff here.
“I am Batman.”
It got a wee bit cold here in Maine this weekend. It was thankfully uneventful for us. We hung around inside and watched it get real cold outside. Our home faired pretty well, too. Honestly pleasantly surprised about that!
We picked this weekend to go all in on potty training — pantsless days, treats, rousing bouts of encouragement sung, and a lot of spot cleaning. Fueled by hubris, I thought we had this potty training thing down pat. In reality, it was that our first go round with it was supremely uneventful. We will perceiver.
I’ve been thinking many thoughts about how to fix this website. While I love its design and general vibe, I know it’s not all that accessible, and has some usability issues (so many tags!?). I don’t have a real idea what to do, yet, but maybe take this as warning? Changes are afoot…albeit a pair of slow, uncertain feet. Things I hope to figure out include
- an equally quirky, but significantly more accessible design
- a better way of revisiting past posts
- and if I even wanna stick with this blog-ish format, or if I wanna move to something more like a wiki, or something altogether weirder!?
I recently asked a question on fedi:
Once upon a time I was an art history person. I thought for a long while I was gonna be a professor of it or something adjacent to it.
There’s a certain sort of art history writing that spends a lot of time establishing an ontology around what’s beautiful, and what moves make something beautiful.
These days, a lot of the nonfiction I read is about programming or computer science. It’s not unusual for a programming book to talk about beauty in code, or data, but the “rules” for what makes something beautiful seem a lot more ephemeral, but usually related to “elegance.”
For the code inclined among ye, when do you see code as beautiful? Do you?
This had a number of really interesting responses that I’ve been noodling on. If I was so bold as to condense them down, I’d say a connecting line between all the responses is “utility.” In hindsight this makes total and complete sense — code ought to work. When I asked the question, though, I was in a really aesthetic frame of mind, so, was sorta surprised with how focused folks were on the code actually functioning over some aesthetic quality of the rendering of the code itself.
…but this may also be sign that my code is mostly garbage?
In my mind, regardless of what or how it works, C is less “beautiful” than a lisp. There is an aesthetic to lisps that I find beautiful.
One respondent said,
I find code beautiful when it has an internal grain, a style of its own, whatever that style may be.
That struck me. I’ve read about the idea of code having “grain” before, and find that an interesting way to describe the tactile nature of programming systems when compared to one another…C to lisp, forth to pascal.
Since the new year I’ve finished a few books. I’m trying to read more fiction than nonfiction this year. I re-read The Hobbit with the family, and an unremarkable, but enjoyable book, the second in a series, Eyes of the Void, by Adrian Tchaikovsky. I liked the first in the series better than this second one, but it was fun, and I’ll most likely end up reading the third installment soon enough.
715 Creeks by Cristin Milioti is a song that has been in heavy rotation while I work lately. It is a cover from Bon Iver’s 22, A Million.
“I’m on a boat.”
Snorlax leaning into the whole vibe of her namesake.