Category Archives: Uncategorized

Getting the digital autonomy we pay for

As an armchair educational technologist I’ve applauded the emerging notion that we should encourage students to build personal cyberinfrastructure, rooted in a domain of one’s own, that empowers them to live and work effectively. Doing so requires some expertise, but not necessarily this kind:

Authorship has blossomed since the dawn of social media; but even in its rise, authorship has been controlled by the platforms upon which we write. Digital pages are not neutral spaces. As I write this in Google Docs, I’m subject to the terms of service that invisibly manipulate the page; and I am also subject to the whims of the designers of the platform.

Owning our own homes in the digital requires an expertise that this writer does not have. I don’t own my own server, I haven’t learned to code, I haven’t designed my own interfaces, my own web site, nor even my own font. I must content myself to rent, to squat, or to ride the rails.

[Risk, Reward, and Digital Writing]

That’s Sean Michael Morris writing in the journal Hybrid Pedagogy. I agree with the premise that many are disempowered, but not with the conclusion that they’re stuck with that fate. Digital autonomy isn’t a nirvana only geeks can attain. We can all get there if we appreciate some basic principles and help create markets around them.

I’ve owned and operated servers. Nowadays I mostly avoid doing so. I host this blog on, and accept the limitations that entails, because it’s a reasonable tradeoff. Here, on this blog, at this point in my life, I don’t need to engage in the kinds of experimentation that I’ve done (and will do) elsewhere. I just need a place to publish. So I’ve outsourced that function to WordPress.

I haven’t, though, outsourced the function of writing to WordPress. I still write with the same text editor I’ve used for 25 years. When I finish writing this essay I’ll paste it into WordPress and hit the Publish button. This is not an ideal arrangement. I would rather connect my preferred writing tool more directly to WordPress (also to Twitter, Facebook, and other contexts). I’d rather that you could do the same with your preferred writing tool. And I’d like the creators of our writing tools, and of WordPress, to get paid for the work required to make those connections robust and seamless.

The web is made of software components that communicate by means of standard protocols. Some of those standards, like the ones your browser uses to fetch and display web pages, are baked into all the browsers and servers in a way that enables many different makes and models to work together reliably. Other standards, including those that would enable you to connect your favorite writing tool to your favorite publishing environments, are nonexistent or nascent. If you would like those standards to exist, flourish, and work reliably everywhere — and if you are willing to support the work required — then say so!

One of the Elm City project’s core principles is the notion that you ought to be able to publicize events using any calendar application (or service) that you prefer. In this case there is a mature Internet standard. But many vendors of calendar publishing systems don’t bother to implement it. When I ask why not they always say: “Customers aren’t asking for it.”

I don’t want most people to run servers, write code, or design interfaces. I just want people to understand what’s possible in a world of connected, standards-based software components, to recognize when those possibilities aren’t being realized, to expect and demand that they will be, and to pay something for that outcome. is a valuable service that I could be using for free. In fact I pay $13/year for domain mapping so I can refer to this blog as instead of That’s useful. It helps me consolidate my online presence within a domain of my own. But is that really critical? My wife blogs at Her homepage at links to the blog. Writing this post reminds me that I keep forgetting to create the alias Maybe I will, now that I’m thinking about it, but I’m not sure she’d notice a difference. People find Luann online in the spaces she chooses to inhabit and call her own.

I’d rather she had the option to spend $13/year for a robust connection between Word, which is her preferred writing tool, and WordPress. And then be able to transfer that connection to another writing tool and/or publishing platform if she wants to. Gaining this autonomy doesn’t require deep technical expertise. We just need to understand what’s possible, demand it, and be willing to pay (a little) for it.

We are the media

In an item posted last week, There was no pumpkin riot in Keene, I drew a distinction between two different events that became conflated in the national awareness. There was no rioting during the pumpkin festival at one end of Keene’s Main Street. And no pumpkins were smashed during the riots in the college neighborhood at the other end of the street. But as Reed Hedges noted in a comment on my blog:

The imagined scene of a quaint and boring pumpkin festival erupting in anarchy and violence for no reason was too amusing to resist viral spread across national and internet news.

In conversations about why the story went off the rails, I keep hearing the same refrain. It was “the media’s” fault. Yes, but that begs the question: Which media? Stories are no longer framed exclusively by newspapers, TV, radio, and their counterparts online. Using social media we all participate in that framing, for better and for worse. When we point the finger of blame at “the media” we must also point back at ourselves.

We’re becoming more aware of how and why to be critical consumers of online information. The corollary is not yet widely acknowledged. Because we collectively shape the stories that inform public awareness, we must also learn to be careful producers of online information.

In the aftermath of that chaotic night in Keene, an acquaintance (and prominent local citizen) mentioned in a Facebook post that two people had died. His source? He’d heard it from someone who had in turn heard it on a police scanner. In fact nobody died. I don’t think that careless report amplified the collective misconception, but it easily could have. Our online utterances are news sources. When we like, retweet, and tag those utterances, we shape the flow of news. This is a new kind of power. We’ve got to use it responsibly, and hold ourselves accountable when we don’t.

Let’s talk

Ray Ozzie, in conversation with Ina Fried and Walt Mossberg last week, reflected on his decades-long effort to enlist computers in support of collaborative work. Ina asked whether the tools he’s built — Notes, Groove, now Talko — have been ahead of the curve. Ray’s response:

With Notes it was an uphill battle, and then once it took off, it took off. We built a very substantial business around that, which is what gave me confidence there’s a macro-economic basis for computer-supported collaborative work. If you solve collaboration problems, there’s money to be made.

With Groove that wasn’t the case. It was a niche audience. But Groove is where I got excited about voice. It was used primarily by non-governmental organizations — in Sri Lanka after the tsunami, after Katrina, in many situations where people from different organizations needed to get together very dynamically to get something done. People used the text and file-sharing features in Groove, but they also used the push-to-talk button much more than we expected. Because when you want to convey emotion and urgency, there’s nothing better than your voice.

It’s ironic that Talko’s effort to re-establish voice as a primary mode of communication is ahead of the curve. Somehow we’ve come to accept that talking to one another isn’t a primary function of the devices we call phones, but that typing on them with our thumbs is.

With Talko, you speak in a shared space that’s represented as an audio timeline. Conversations can be asynchronous (like email) or synchronous (like chat), and the transition between those modes is seamless. When I bought my first iPhone in order to try Talko — it’s iOS-only for now — I contacted Matt Pope, Talko’s co-founder, to let him know I was available for Talko-style conversation. Over a period of days we chatted asynchronously, creating an audio timeline made from his voice messages and mine. In that mode Talko is a kind of visual voicemail: a randomly-accessible record of voice messages sent and received.

At one point I happened to be reviewing that conversation when Matt came online, noticed I was active in the conversation, and switched into synchronous mode by saying “Cool! Serendipitous synch!” Just like that we were in a live conversation. But not an ephemeral live conversation. We were still adding to the audio timeline, still building a persistent and shareable construct.

I’d been revisiting my conversation with Matt because, in a parallel Talko conversation with Steve Gillmor, he and I wondered how to exchange Talko sessions. Matt used our live conversation to explain how, and inserted an iPhone screenshot into the stream to illustrate. (Mea culpa. It would have been obvious to me if I’d been a more experienced iPhone user.)

When I hung up with Matt I captured the link for our conversation, which was now a record of a back-and-forth voice messages over several days, plus a live conversation, plus a screenshot injected into the conversation. And I added that link into the parallel conversation I’d been having, on and off for a few days, with Steve.

Talko’s business model is business. In that realm, voicemail is a last resort. And nobody loves a conference call that has to be scheduled in advance, that includes only invited attendees, that leaves no record for attendees (or others recruited later) to review and extend. Email is the universal solvent but it’s bandwidth-challenged with respect to both speed and emotional richness. Voice is a radically underutilized medium for communicating within and across organizations. It’s not a panacea, of course. On a plane, or in a meeting, you often need to communicate silently. But a smarter approach to voice communication will, I’m certain, solve vexing communication problems for business.

And not only for business. My most pressing collaboration challenge right now is helping my sister coordinate care for our elderly mother. My sister lives in New Jersey, I’m in California, mom’s in Pennsylvania. We are in ongoing conversations with mom, with each other, with staff at the facility where mom lives, with her friends there, with an agency that provides supplemental care, and from time to time with the hospital. Communication among all of us is a fragmented mess of emails, text messages, voicemails, pictures of handwritten notes, and of course phone calls. It’s really one ongoing conversation that would ideally leverage voice as much as possible, while enhancing voice with text, images, persistence, tagging, and sharing. I wish I could use Talko to manage that conversation. The iOS-only constraint prevents that for now; I hope it lifts soon.

There was no pumpkin riot in Keene

Recently, in a store in Santa Rosa, my wife Luann was waiting behind another customer whose surname, the clerk was thrilled to learn, is Parrish. “That’s the name of the guy in Jumanji,” the clerk said. “I’ve seen that movie fifty times!”

“I’m from Keene, New Hampshire,” Luann said, “the town where that movie was filmed.”

It was a big deal when Robin Williams came to town. You can still see the sign for Parrish Shoes painted on a brick wall downtown. Recently it became the local Robin Williams memorial:

Then the penny dropped. The customer turned to Luann and said: “Keene? Really? Isn’t that where the pumpkin riot happened?”

The Pumpkin Festival began in 1991. In 2005 I made a short documentary film about the event.

It’s a montage of marching bands, face painting, music, kettle corn, folk dancing, juggling, and of course endless ranks of jack-o-lanterns by day and especially by night. We weren’t around this year to see it, but our friends in Keene assure us that if we had been, we’d have seen a Pumpkin Festival just like the one I filmed in 2005. The 2014 Pumpkin Festival was the same family event it’s always been. Many attendees had no idea that, at the other end of Main Street, in the neighborhood around Keene State College, the now-infamous riot was in progress.

No pumpkins were harmed in the riot. Bottles, cans, and rocks were thrown, a car was flipped, fires were set, but — strange as it sounds — none of these activities intersected with the normal course of the festival. Two very different and quite unrelated events occurred in the same town on the same day.

The riot had precursors. Things had been getting out of control in the college’s neighborhood for the past few years. College and town officials were expecting trouble again, and thought they were prepared to contain it. But things got so crazy this year that SWAT teams from around the state were called in to help.

In the aftermath there was an important discussion of white privilege, and of the double standard applied to media coverage of the Keene riot versus the Ferguson protests. Here’s The Daily Kos:

Black folks who are protesting with righteous rage and anger in response to the killing of Michael Brown in Ferguson have been called “thugs”, “animals”, and cited by the Right-wing media as examples of the “bad culture” and “cultural pathologies” supposedly common to the African-American community.

Privileged white college students who riot at a pumpkin festival are “spirited partiers”, “unruly”, or “rowdy”.

Unfortunately the title of that article, White Privilege and the ‘Pumpkin Fest’ Riot of 2014, helped perpetuate the false notion that the Pumpkin Festival turned into a riot. When I mentioned that to a friend he said: “Of course, the media always get things wrong.”

It would be easy to blame the media. In fact, the misconception about what happened in Keene is a collective error. On Twitter, for example, #pumpkinfest became the hashtag that gathered riot-related messages, photos, and videos, and that focused the comparison to Ferguson. Who made that choice? Not the media. Not anyone in particular. It was the network’s choice. And the network got it wrong. Our friends in Keene saw it happening and tried to flood the social media with messages and photos documenting a 2014 Pumpkin Festival that was as happy and peaceful as every other Pumpkin Festival. But once the world had decided there’d been a pumpkin riot it was impossible to reverse that decision.

Is Keene’s signature event now ruined? We’ll see. I don’t think anybody yet knows whether it will continue. Meanwhile it’s worth reflecting on how conventional and social media converged on the same error. There’s nothing magical about the network. It’s just us, and sometimes we get things wrong.

How recently has the website been updated?

Today’s hangout with Gardner Campbell and Howard Rheingold, part of the Connected Courses project, dovetailed nicely with a post I’ve been meaning to write. Our discussion topic was web literacy. One of the literacies that Howard has been promoting is critical consumption of information or, as he more effectively says, “crap detection.” His mini-course on the subject links to a page entitled The CRAP Test which offers this checklist:

    * Currency -

          o How recent is the information?

          o How recently has the website been updated?

          o Is it current enough for your topic?

    * Reliability -

          o What kind of information is included in the resource?

          o Is content of the resource primarily opinion?  Is is balanced?

          o Does the creator provide references or sources for data or quotations?

    * Authority -

          o Who is the creator or author?

          o What are the credentials?

          o Who is the published or sponsor?

          o Are they reputable?

          o What is the publisher’s interest (if any) in this information?

          o Are there advertisements on the website?

    * Purpose/Point of View -

          o Is this fact or opinion?

          o Is it biased?

          o Is the creator/author trying to sell you something?


The first criterion, Currency, seems more straightforward than the others. But it isn’t. Web servers often don’t know when the pages they serve were created or last edited. The pages themselves may carry that information, but not in any standard way that search engines can reliably use.

In an earlier web era there was a strong correspondence between files on your computer and pages served up on the web. In some cases that remains true. My home page, for example, is just a hand-edited HTML file. When you fetch the page into your browser, the server transmits the following information in HTTP headers that you don’t see:

HTTP/1.1 200 OK
Date: Thu, 23 Oct 2014 20:54:46 GMT
Server: Apache
Last-Modified: Wed, 06 Aug 2014 19:28:27 GMT

That page was served today but last edited on August 6th.

Nowadays, though, for many good reasons, most pages aren’t hand-edited HTML. Most are served up by systems that assemble pages dynamically from many parts. Such systems may or may not transmit a Last-Modified header. If they do they usually report when the page was assembled, which is about the same time you read it.

Search engines can, of course, know when new pages appear on the web. And there are ways to tap into that knowledge. But such methods are arcane and unreliable. We take it for granted that we can list files in folders on our computers by date. Reviewing web search results doesn’t work that way, so it’s arduous to apply the first criterion of C.R.A.P. detection. If you’re lucky the URL will encode a publication date, as is often true for blogs. In such cases you can gauge freshness without loading the page. Otherwise you’ll need to click the link and look around for cues. Some web publishing systems report when items were published and/or edited, many don’t.

Social media tend to mask this problem because they encourage us to operate in what Mike Caulfield calls StreamMode:

StreamMode is the approach to organizing your thoughts as a history, integrated primarily as a sequence of events. You know that you are in StreamMode if you never return to edit the things you are posting on the web.

He contrasts StreamMode with StateMode:

In StateMode we want a body of work at any given moment to be seen as an integrated whole, the best pass at our current thinking. It’s not a journal trail of how we got here, it’s a description of where we are now.

The ultimate expression of StateMode is the wiki.

But not only the wiki. Any website whose organizing principle is not reverse chronology is operating in StateMode. If you’re publishing that kind of site, how can you make its currency easier to evaluate? If you can choose your publishing system, prefer one that can form URLs with publication dates and embed last-edited timestamps in pages.

In theory, our publishing tools could capture timestamps for the creation and modification of pages. Our web servers could encode those timestamps in HTTP headers and/or in generated pages, using a standard format. Search engines could use those timestamps to reliably sort results. And we could all much more easily evaluate the currency of those results.

In practice that’s not going to happen anytime soon. Makers of publishing tools, servers, and search engines would have to agree on a standard approach and form a critical mass in support of it. Don’t hold your breath waiting.

Can we do better? We spoke today about the web’s openness to user innovation and cited the emergence of Twitter hashtags as an example. Hashtags weren’t baked into Twitter. Chris Messina proposed using them as a way to form ad-hoc groups, drawing (I think) on earlier experience with Internet Relay Chat. Now the scope of hashtags extends far beyond Twitter. The tag for Connected Courses, #ccourses, finds essays, images, and videos from all around the web. Nine keystrokes join you to a group exploration of a set of ideas. Eleven more, #2014-10-23, could locate you on that exploration’s timeline. Would it be worth the effort? Perhaps not. But if we really wanted the result, we could achieve it.

GitHub Pages For The Rest Of Us

In A web of agreements and disagreements I documented one aspect of a recent wiki migration: conversion of MediaWiki’s markup lingo, wikitext, to Github’s lingo, Github Flavored Markdown. Here I’ll describe the GitHub hosting arrangement we ended up with.

There were two ways to do it. We could use GitHub’s built-in per-repository wiki, powered by an engine called Gollum. Or we could use GitHub Pages, a general-purpose web publishing system that powers (most famously) the website for the Ruby language. The engine behind GitHub Pages, Jekyll, is also often used for blogs. If you scan the list of Jekyll sites you’ll see that a great many are software developers’ personal blogs. That’s no accident. They are the folks who most appreciate the benefits of GitHub Pages, which include:

Simple markup. You write Markdown, Jekyll converts it to HTML. Nothing prevents you from mixing in HTML, or using HTML exclusively, but the simplicity of Markdown — more accurately, GitHub Flavored Markdown — is a big draw.

No database. For simple websites and blogs, a so-called dynamic system, backed by a database, can be overkill. You have to install and maintain the database which then regulates all access to your files. Why not just create and edit plain old files, either in a simple lingo like Markdown or in full-blown HTML, then squirt them through an engine that HTMLizes the Markdown (if necessary) and flows them through a site template? People call sites made this way static sites, which I think is a bit of a misnomer. It’s a mouthful but I prefer to call them dynamically generated and statically served. I’ve built a lot of web publishing systems over the years and they all work this way. If what you’re publishing is data that naturally resides in a database then of course you’ll need to feed the site from the database. But if what you’re publishing is stuff that you write, and that most naturally lives in the filesystem, why bother?

Version control. A GitHub Pages site is just a branch in a GitHub repository associated with some special conventions. And a GitHub repository offers many powerful affordances, including an exquisitely capable system for logging, tracking, and visualizing the edits to a set of documents made by one or more people.

Collaborative editing. When more then one person edits a site, each can make a copy of the site’s pages, edit independently of others, and then ask the site’s owner to merge in the changes.

Issue tracking. Both authors and readers of the site can use GitHub to request changes and work collaboratively to resolve those requests.

You don’t have to be a programmer to appreciate these benefits. But GitHub is a programmer-friendly place. And its tools and processes are famously complex, even for programmers. If you use the tools anyway on a daily basis, GitHub Pages will feel natural. Otherwise you’ll need a brain transplant.

Which is a shame, really. All sorts of people would want to take advantage of the benefits of GitHub Pages. If it were packaged very differently, and presented as GitHub Pages For The Rest of Us, they might be able able to. The collaborative creation and management of sets of documents is a general problem that’s still poorly solved for the vast majority of information workers. Mechanisms for collaborative editing, version control, and issue tracking often don’t exist. When they do they’re typically add-on features that every content management system implements in its own way. GitHub inverts that model. Collaborative editing, version control, and issue tracking are standard capabilities that provide a foundation on which many different workflows can be built. Programmers shouldn’t be the only ones able to exploit that synergy.

In this case, though, the authors of the wiki I was migrating are programmers. We use GitHub, and we know how to take advantage of the benefits of GitHub Pages. But there was still a problem. You don’t make a wiki with GitHub Pages, you make a conventional website. And while you can use GitHub Flavored Markdown to make it, the drill involves cloning your repository to a local working directory, then installing Jekyll and using it to compile your Markdown files into their HTML counterparts which you preview and finally push to the upstream repo. It’s a programmer’s workflow. We know the drill. But just because we can work that way doesn’t mean we should. Spontaneity is one of wiki’s great strengths. See something you want to change? Just click to make the page editable and do it. The activation threshold is as low as it can possibly be, and that’s crucial for maintaining documentation. Every extra step in the process is friction that impedes the flow of edits.

So we went with the built-in-wiki. It’s easy to get started, you just click the Wiki link in the sidebar of your GitHub repository and start writing. You can even choose your markup syntax from a list that includes MediaWiki and Markdown. As we went along, though, we felt increasingly constrained by the fixed layout of the built-in wiki. Wide elements like tables and preformatted blocks of text got uncomfortably squeezed. You can create a custom sidebar but that doesn’t replace the default sidebar which lists pages alphabetically in a way that felt intrusive. And we found ourselves using Markdown in strange ways to compensate for the inability to style the wiki.

If only you could use GitHub Pages in a more interactive way, without having to install Jekyll and then compile and push every little change. Well, it turns out that you can. Sort of.

I haven’t actually run Jekyll locally so I may be mistaken, but here’s how it looks to me. Jekyll compiles your site to a local directory which becomes the cache from which it serves up the results of its Markdown-to-HTML conversion. When you push your changes to GitHub, though, the process repeats. GitHub notices when you update the repo and runs Jekyll for you in the cloud. It compiles your Markdown to a cache that it creates and uses on your behalf.

If that’s how it works, shouldn’t you be able to edit your Markdown files directly in the repository, using GitHub’s normal interface for editing and proofing? And wouldn’t that be pretty close to the experience of editing a GitHub wiki?

Yes and yes, with some caveats. Creating new pages isn’t as convenient as in the wiki. You can’t just type in [see here](New Page) and then click the rendered link to conjure that new page into existence. Jekyll requires more ceremony. You have to manually create (not, evidently, “New”) in your repo. And then you have to edit and add something like this at the top:

title: New Page
layout: default

Since conjuring new pages by name is arguably the essence of a wiki, this clearly isn’t one. But you can create a page interactively using GitHub’s normal interface. Once that’s done, you can edit and preview “New” using GitHub’s normal interface. To me the process feels more like using the built-in wiki than compiling locally with Jekyll. And it opens the door to the custom CSS and layouts that the built-in wiki precludes.

There are, alas, still more caveats. You can’t always believe the preview. Some things that look right in preview are wrong in the final rendering. And that final rendering isn’t immediate. Changes take more or less time to show up, depending (I suppose) on how busy GitHub’s cloud-based Jekyll service happens to be. So this is far from a perfect solution. If you only need something a bit more robust than your repository’s file, then the built-in wiki is fine. If you’re creating a major site like then you’ll want to install and run Jekyll locally. Between those extremes, though, there’s a middle ground. You can use GitHub Pages in a cloud-based way that delivers a wiki-like editing experience with the ability to use custom CSS and layouts,

I don’t think this particular patch of middle ground will appeal widely. Maybe a hypothetical GitHub Pages For The Rest Of Us will. Or maybe Ward Cunningham’s Smallest Federated Wiki (see also will. In any case, the ideas and methods that enable software developers to work together online are ones that everyone will want to learn and apply. The more paths to understanding and mastery, the better.

Voyage of the Captain Kirk Floating Arms Keyboard Chair

When we moved last month we let go of a great many things in order to compress our household and Luann’s studio into a set of ABF U-Pack containers. At one point we planned to shed all our (mostly second-hand) furniture, figuring it’d be cheaper to replace than to ship cross-country. But since Luann had acquired all that furniture, it was much harder for her to let go of it than me. So to put a bit more of my own skin into the game I sacrificed my beloved Captain Kirk chair with Floating Arms keyboard.

The idea was to preserve the essential one-of-a-kind keyboard and replace the commodity chair. Which was foolish, Bodybilt chair’s don’t come cheap. But I was in the grip of an obsession to lighten our load, and there was no time left to sell it, so off to the curb it went. My friend John Washer and I immortalized the moment.

Then, happily, fate intervened. First another friend, George Ponzini, sensibly picked up the chair and took it home. Then we decided to use our reserve fourth U-Pack container to bring a sofa, some living room chairs, and other stuff we thought we’d leave behind. Now there was room for the Captain Kirk chair to come along on our voyage. George kindly brought it back, I packed it, and off to California we went.

Weeks later we unpacked our household containers in our rented home in Santa Rosa. When I set the chair down in my office, the hydraulic lifter broke. Not a disaster, I could live with it at the lowest setting until I could replace the lifter. But then, as we emptied box after box, I began to worry. The Floating Arms keyboard wasn’t showing up. Disaster!

Then, finally, it turned up. Joy!

But when I tried to reattach it to the chair, two crucial parts — the rods that connect the arms of the chair to the custom keyboard — were inexplicably missing. Disaster!

Eventually it dawned on me. This wasn’t the Floating Arms keyboard I’d been using for the past 15 years. It was the original prototype that I’d reviewed for BYTE, and that Workplace Designs had replaced with the production model. I’d had a backup Floating Arms keyboard all this time, forgotten in a box up in the attic. So now I could recreate my setup. I just needed to replace the connector rods and the hydraulic lifter. Joy! Maybe! If those parts were still available!

I called The Human Solution and spoke to the very friendly and helpful Jonan Gardner. He took down the serial number on the chair, asked for photos of the broken hydraulic lifter and the arms into which the missing connector rods needed to fit, and promised to get back to me.

The next day the missing Floating Arms keyboard turned up in the bottom of a bag of shoes. More joy! I hooked it up to my broken-but-still-functional chair and got to work. The first order of business was to contact Jonah and let him know I didn’t need those connector rods, they were attached to the missing-but-now-found keyboard. “You’re lucky,” he said. “We couldn’t have replaced those. But the lifter is still available for your chair, and you can order it.” So I did.

The lifter arrived today. It wasn’t immediately obvious how to extract the old one in order to replace it. There were no fasteners. Do you just need to pound on it with a sledgehammer? I wrote to Jonah and he responded with this video and these instructions:

Someone will need to use a 3-4 pound, short handle, steel-head sledge hammer. Timidity will not get the old cylinder out so do not be afraid to HIT the mechanism. After 20 some-odd years, they are going to have to HIT the mechanism.

That’s just what I needed to know. And he wasn’t kidding about the weight of the hammer. I didn’t have a sledgehammer handy, and a regular hammer didn’t work, so I improvised:

And that did the trick. I HIT the cylinder a bunch of times, it popped out, I popped the new one in, and I’m back in business.

Thank you, Workplace Designs, for inventing the best ergonomic keyboard ever. Thank you, Jonah, for helping me bring it back to life. Thank you, World Wide Web, for enabling Bodybilt to share a video show exactly how hard to HIT when replacing a hydraulic lifter. And thank you, Captain Kirk Floating Arms Keyboard Chair, for being with me all these years. I’m sorry I threatened to abandon you. It’ll never happen again.