#7: Shift + Shift

This is a newsletter for Shift happens, an upcoming book about keyboards.

This happened about two years ago. It was close to the end of a workday. I was a little stressed out, more than a little tired, a coworker was standing next to me asking for a certain file, and so I went to my computer’s terminal, keyed in three simple characters: c:\…

…and then I froze.

c:\ is a perfectly fine incantation for when you want to find a file, and you intend to start at the very top. It will work on every PC ever made. Other computers have equivalent sequences that achieve the same purpose; on a Mac, for example, you would type in cd ~instead. The thing is, I was using a Mac that day. What was even more interesting: I’ve been using Macs — exclusively — for the past twelve years.

Somewhere in the depths of my muscle memory, c:\ was still there from my long-gone PC days, dormant for over a decade, apparently just waiting to be awakened under certain conditions — such as being tired, stressed out, and absent-minded.

That seemed like the most incredible discovery (what else is hiding in there?) and some time later, in the course of researching the book, I ventured out to learn much more about muscle memory.

Lesson one: don’t call it that. The proper term is “motor memory.” Second discovery? Motor memory is completely independent from our main, declarative memory. Did you ever experience someone asking you about a keyboard shortcut, and realize you had to watch your fingers perform it in order to answer the question? Turns out, it’s just how we’re built.

But then, motor memory is also still memory. Which means it has that one counterintuitive property that we take for granted: you can’t actually forget anything. Sure, memories get reshaped, bundled with other memories, moved behind certain triggers — but they never truly disappear. It’s the same with motor memory. There were studies of people sitting down to a keyboard after twenty-five years — and picking up typing with very little trouble. Put two of these together and you will arrive at the same astonishing realization I once had: at some point in your life you might forget who you are, but you will still know how to type.

I am writing this on a machine called Z88. It’s a British portable computer, made in the eponymous year, lent to me by my friend Scott in one of my favourite unexpected moments: he simply brought it to a random lunch and showed it to me without fanfare — and then, to top it all off, let me have it for a while.

Z88 is a gorgeous computer. Just like Canon Cat, released around the same time, its purpose is to allow you to write and do little else. But its demeanour couldn’t be any different. It’s a light, dark, flat slate, hinting at a faraway future filled with iPads. More than half of its face is occupied by a keyboard, and the rest by a small monochromatic screen. Z88 is elegant, and possibly the most beautiful machine of its kind: gentler than the reliable American journalistic workhorse TRS-80 Model 100, simpler than the messy AlphaSmart, and with much more integrity all around than the modern hipster annoyance that is the FreeWrite.

It also has one of my favourite keyboard shortcuts ever. There is no on/off switch, or a dedicated key to turn it on. To get the machine running, you press the left Shift and the right Shift together.

It’s a shortcut that’s easy to remember. It’s pleasant to press, as Shifts are among the biggest keys on most keyboards. But it’s also really clever. It breathes a new life to the first key ever added to a keyboard in its history, and criminally underused afterwards. And it immediately sets the tone: this machine might look simple, but it’s not simplistic — it’s a thoughtful tool that will reward mastery. Those two Shifts pressed together are just as good a prelude to using the Z88, as Slide To Unlock would be to the iPhone twenty years later.

When one day I took the Z88 to a café, it immediately became a conversation starter. Just like other thoughtful British computers — ZX81, ZX Spectrum, and Sinclair QL — you could put the 39-year-old Z88 on your desk today and it wouldn’t look terribly out of place. And just like all those computers, Z88 was designed by Rick Dickinson.

I mentioned Rick in the first issue of this newsletter. I talked how much the interview with him meant to me (it wasn’t the last time I would). One of my first “real” interviews for the book, it ended up being great fun, gave me a lot of material for the ZX Spectrum chapter, and assured me I’m not a complete disaster when interviewing. But it also did something else. It renewed my faith in storytelling about design. That way Rick enthralled me by telling me how he cared about the design of his products? That way was possibly mine to have, too.

But I’m not writing this to reminisce about the interview again, or focus on portable typewriters, or talk about the fascinating and — to America — exotic years of British computing. I’m writing this because Rick Dickinson died a few weeks ago, on April 24, after a failed battle with cancer.

I wasn’t ready for this aspect of writing the book. At all. I used to say it’s nice to be a historian of computers, since you can walk among the people who invented them. But I forgot that only works up until a point. The daughter of Dr. İhsan Sıtkı Yener, the inventor of Turkish keyboard I wrote about in 2015, contacted me and promised to put in touch with her father — but I procrastinated and was devastated to hear of his death a year later. After I did some serious digging, I found the (awesome) name of the project manager behind the infamous PCjr keyboard — Ralph Crawford Byxbee Jr. — and got excited about the prospects of talking to him, just in time to find his obituary from a prior month. Later on, I found out why Regis Magyar, an IBM keyboard designer I really wanted to talk to and tried to contact a few times, never responded to my letters.

And then, I learned of Rick’s death through an offhand, semi-related tweet.

I’d like to think Rick liked our interview, too. I was nervous and technical issues abounded — at one point my MacBook went haywire and started playing back the beginning of our conversation to both of us. But at the end of our chat, Rick said “We’ll talk again,” and I was genuinely excited to do so. I imagined I’d send him the finished book and say “hey, I have a whole chapter about your machine, and I feel I made a pretty great case for why it was actually a really well-designed one.” And then, one year, I’ll happen to be in the U.K., and perhaps we’d meet in person, now both civilians.

(Rick’s “we’ll talk again” sounds so much more different today, when I realize that he already knew his cancer was back then.)

I don’t know if I was the last person that interviewed Rick, but I think I will be the last one to publish the interview. It’s a strange responsibility. I’ll pour over video and audio from our chat once again, to make sure I capture as much of that conversation, as much of what Rick tried to express, as much as who he was, as possible.

But I couldn’t wait until whenever in 2019 to tell you about him. I am sending this off newsletter cycle, the moment I figured out what to say. I struggled for a few weeks — how do you talk about a death of someone close to you in this unusual and abstract way? — until I grabbed the Z88, and turned it on by pressing both Shifts at the same time without even thinking about it.

Throughout his life, Rick designed keyboards that taught millions of people in the U.K. (and poorer countries like Poland) how to use computers. Most people don’t know that it was him; like with good design, most will not even realize it was anyone at all. I’ll be happy if my book makes the connection more obvious, in a chapter that talks as much about Rick’s keyboards, as it does about the beauty of design that appears pedestrian, and the importance of careful design that feels like it never even happened.

Rick will live on in the memories of people who knew him, who worked with him, who were lucky to get a bit of his time that one morning in early 2017, despite his advancing illness. But when you design a few great keyboards, something else happens, too.

In a strange way, Rick will also get to live on in the memories of all the hands that learned programming on the ZX81, hands that played games on the Spectrum, and hands that wrote office memos on the QL. And in the hands that typed on the black rectangle of Z88, hands that unbeknownst to their owners will forever wait for the right circumstances to once more, instantly, automatically, touch both Shifts to turn it on — something they learned in the fading years of the 1980s, and something they will never forget.

Marcin

This was newsletter №7 for Shift happens, an upcoming book about keyboards.

I recently spent some time with a startup called Kite to work on the typography of their tools. Among their group of smart utilities helping programmers code, the centerpiece is a native/web app named Kite Copilot that sits by your editor to lend a helping hand. It looks like this:

One early afternoon, a programmer using Copilot wrote to us suggesting adding a second, dark colour theme: a way to convince the app to use light text on a darker background. It made sense. The dark theme is something preferred by many programmers — indeed, a default in many modern editors like Atom or Visual Studio Code. Right next to an editor with a dark theme, Copilot can feel like it dressed up for a wrong kind of party:

I started wondering if it was possible to add a dark theme that very afternoon, promising myself that I would move on to other things the next day rain or shine, whether I finish or not.

This is a story of how a few new-ish CSS options came together like a bunch of superheroes in a summer blockbuster movie, and allowed for this project to indeed take up one afternoon, and not much more.

CSS variables

I knew immediately that this project could not happen without CSS variables, and I was excited to try them for the first time in native CSS (I’ve only known them before courtesy of LESS). I started by turning all the existing hardcoded colors into variables, and then reducing the number of variables to the absolute minimum. It looked something like this:

Before

.main {
  background-color: #eef4f7;
  color: #0a244d;
}
.docs {
  color: #0c2959;
}

After

html {
  --background: #eef4f7;
  --text-color-normal: #0a244d;
}

.main {
  background: var(--background);
  color: var(--text-color-normal);
}
.docs {
  color: var(--text-color-normal);
}

I didn’t, however, wait to systematize everything in the light theme, and only then come up with a nightly alternative. As a matter of fact, I did the exact opposite. I created the simplest scaffolding of the second theme… and immediately enabled it. The reason for this was simple: this approach made it easier to see which colours among the dozens of CSS files (most I have never traversed before) I missed and didn’t turn into variables yet. Anything that was off was easy to spot in the increasingly darker and darker universe:

I also cleaned up a few other adjacent areas. I removed any opacity that was paired with colours, and baked the lightness into the colours themselves. I removed any alpha values (rgba), too. That made it easier for me to trust them again, since some of the half-transparent colours could become backgrounds atop other elements with other background colours, and it was impossible to predict their interaction.

Before

.home {
  color: #0a244d;
}
.home__version {
  opacity: 0.7;
} 

After

html {
  --text-color-normal: #0a244d;
  --text-color-light: #8cabd9;
}
.home {
  color: var(--text-color);
}
.home__version {
  color: var(--text-color-light);
}

The only opacity I kept was for disabled UI elements — its presence was well-defined, and made things simpler.

Lastly, I also created a variable for shadows used on popovers, as I needed the shadows to be more prominent in the dark theme.

Expressing colours

Then, I took variables one tiny step further. I didn’t want to assume that the colours would always come from the Design world and the job of Engineering would only be to plug them in. There was a practical reason, too: playing with colours live by editing the file seemed like the best way to optimize the palette.

And so, in order to make everyone’s life easier (starting with my own), I moved to describing all the colours as HSL:

Before

html {
  --text-color-normal: #0a244d;
  --text-color-light: #8cabd9;
}

After

html[data-theme='dark'] {
  --text-color-normal: hsl(210, 10%, 62%);
  --text-color-light: hsl(210, 15%, 35%);
  --text-color-richer: hsl(210, 50%, 72%);
  --text-color-highlight: hsl(25, 70%, 45%);
}

I find HSL the most satisfying way to navigate the world of colours, the three components having clearer responsibilities than the opaque and arbitrary dials of RGB (where brightness is a complicated formula rather than just a number, and saturation is buried very deeply).

But there was another benefit: I could add secondary variables for main hues of the colour theme.

html[data-theme='dark'] {
  --hue: 210; /* Blue */
  --accent-hue: 25; /* Orange */

  --text-color-normal: hsl(var(--hue), 10%, 62%);
  --text-color-highlight: hsl(var(--accent-hue), 70%, 45%);
}

I wanted to make it easy for the person coming after me to understand the relationships between colours. Even without the hue variables, HSL would make it easier; all the colours starting with hsl(210 would be immediately recognizable as a family. But making 210 another tightened the screws a little bit. It was my way of saying “feel free to experiment with colours, but the act of adding another hue should be an intentional one.”

Plus, changing the hue value was another way to test the integrity of the theme. Any colour not changing would mean a colour accidentally left behind:

I considered going even further, expressing some colours as variations on others. But that felt like overkill here. The slightly inelegant way CSS expresses variables, combined with the need for calc() would make this CSS much less readable.

And so, this is what I ended up with:

html[data-theme='dark'] {
  --hue: 210; /* Blue */
  --accent-hue: 25; /* Orange */

  --text-color-normal: hsl(var(--hue), 10%, 62%);
  --text-color-light: hsl(var(--hue), 15%, 35%);
  --text-color-richer: hsl(var(--hue), 50%, 72%);
  --text-color-highlight: hsl(var(--accent-hue), 70%, 45%);

  --link-color: hsl(var(--hue), 90%, 70%);
  --accent-color: hsl(var(--accent-hue), 100%, 70%);
  --error-color: rgb(240, 50, 50);

  --button-background: hsl(var(--hue), 63%, 43%);
  --button-text-color: black;

  --background: hsl(var(--hue), 20%, 12%);
}

Switching between themes

The theme was applied to a data attribute on top of <html>. A class would be okay, too, but in my head classes feel like checkboxes, whereas data attributes act more like radio buttons. It felt like a moot distinction at this very point — we only had two themes — but I wanted to think a bit ahead.

Definition in CSS

html {
  --hue: 210; /* Blue */
  --text-color-normal: hsl(var(--hue), 77%, 17%);
  ...
}

html[data-theme='dark'] {
  --text-color-normal: hsl(var(--hue), 10%, 62%);
  ...
}

Invocation in JavaScript

document.documentElement.setAttribute('data-theme', 'dark')
document.documentElement.setAttribute('data-theme', 'light')

(Note that the default theme was expressed without any qualifiers. This ensured that if something went wrong and the data attribute disappeared, things would still remain readable.)

This was perfectly functional, but switching the theme back and forth felt abrupt. This was effectively a light switch, but there was a reason I installed fade-in and fade-out light switches in all the rooms I spend significant amount of time in. And so, I installed one in Copilot’s CSS, too:

html.color-theme-in-transition,
html.color-theme-in-transition *,
html.color-theme-in-transition *:before,
html.color-theme-in-transition *:after {
  transition: all 750ms !important;
  transition-delay: 0 !important;
}

This class, color-theme-in-transition, effectively tells the browser “for literally any style that changes from now on, make it a transition.”

Applied all the time, and every incidental hover color change or transition would become a slo-mo nightmare, belonging more in a Zack Snyder movie than in a productivity tool for programmers. But if we were to add this class tactically a moment before changing the theme, and remove as soon as the transition was over, it would give us in a beautiful crossfade:

document.documentElement.classList.add('color-theme-in-transition')
document.documentElement.setAttribute('data-theme', theme)
window.setTimeout(function() {
  document.documentElement.classList.remove('color-theme-in-transition')
}, 1000)

This was possibly my favourite bit of the project, seeing different departments of CSS working together as a team. The change to the attribute made the new set of variables take over the old ones, automatically. After that, all of the new colours inside those variables would then slot themselves in all the places where they were used… but not before another department of CSS would hold them gently in place, stretching what would otherwise be a blink of an eye into a better part of second. Just one new class and one attribute change, and the complex machinery of CSS would come to life in one magically coördinated moment.

CSS often feels clunky and awkward. I can’t say I’m a fan of the way you express variables in it — it looks weird and I keep putting the double dashes in the exact wrong place. But when CSS goes, it goes. And in that very moment, it was fun to watch it go.

(Caveat: this worked really well in Firefox, but Chrome sometimes still struggled, transitioning some parts too late or not at all.)

Theming vector icons

The colour variables took great care of text. But then the dreaded moment came when it came to taking care of the visual elements. A bunch of iconography in Kite’s Copilot existed as vector SVGs as backgrounds:

.sidebar__icon__settings {
  width: 2rem;
  height: 2rem;
  background-image: url(./icon-settings.svg);
}

As far as I know, you can only colorize SVGs with CSS in some circumstances — when you embed them inline, or when you use them as images. But you couldn’t do it in this scenario. And without it, icons in the dark theme would look bad if not downright disappear:

Fortunately, there was another way than creating two versions of all the SVG files. I could use a mask instead of a background:

mask-image: url(./icon-refresh-white.svg);
mask-repeat: no-repeat;
mask-position: center;
background: blue;

What the above bit means is “turn the entire thing blue, but then cut away everything that’s not covered by the shape of the SVG.” If the SVG has a transparent background, it works beautifully. And in that case, it did:

And, to make the transition even easier, the syntax for mask and background is basically interchangeable — with things like background-repeat, background-position, and background-size having perfect doppelgängers on the mask side.

Before

background-size: contain;
background-repeat: no-repeat;
background-position: center;
background-size: 1rem;
background-image: url(./icon-back.svg);

After

mask-size: contain;
mask-repeat: no-repeat;
mask-position: center;
mask-size: 1rem;
mask-image: url(./icon-back.svg);
background-color: var(--link-color);

There are caveats, of course. You can only use a single colour this way. Plus masks, while supported relatively well, still require to be prefixed for webkit.

Most importantly, applying a mask prevents you from doing anything else in the same element: any border, any outline, any text becomes masked away too. In a few instances I had to creatively demote the icon to a :before or :after pseudo-element, which fortunately can be masked independently of the main one.

Without this method, the project would probably stop in its tracks. The thing is I feared it was about to anyway, since there was one type of visuals standing in my way.

Theming images

Kite also has regular bitmapped images interspersed through some of the developer documentation. They looked something like this:

Seeing a big rectangle of white scroll into view wasn’t just aesthetically displeasing. I imagined that while for some people a dark theme is just a visual choice, some — even many — might enable it to take a better care of their eyes. I didn’t want the theme to go 95% there, but then behave like an annoying moviegoer pulling out their smartphone on maximum brightness, and texting in the middle of the aforementioned Zack Snyder movie.

Fortunately, modern CSS saved me from redoing all the images by hand, or writing a script to process and re-save them. I could use a CSS filter to easily invert every image:

html[data-theme='dark'] img {
  filter: invert(100%);
}

The image didn’t look quite right, though, with completely different colours. But I remembered a trick I picked up in Photoshop years ago: Invert the image image and then rotate its hue halfway through, and the image will look much more natural. It doesn’t work so well for photos, but for any charts and diagrams it is basically flawless. Luckily, those were the kind of photos you’d encounter in Kite app.

And, luckily once again, there was also a CSS filter that allowed me to do the exact same thing automatically:

html[data-theme='dark'] img {
  filter: invert(100%) hue-rotate(180deg);
}

And then, I could go even further! Another once-photoshoppian thing is now available in CSS; using a blending mode I could make the visuals feel even more at home — by making its darkest pixels effectively become transparent:

html[data-theme='dark'] img {
  filter: invert(100%) hue-rotate(180deg);
  mix-blend-mode: screen;
}

I could even bring back the blending mode to the original theme, and make that one better as well (multiply is the opposite of screen, so it’d work as well for outputting on light background). Once again, the addition of a dark theme ricocheted into improving the original one, too.

img {
  mix-blend-mode: multiply;
}

html[data-theme='dark'] img {
  filter: invert(100%) hue-rotate(180deg);
  mix-blend-mode: screen;
}

And that was it. Those few lines of CSS made the project complete. (Depending on your needs, you could consider simply reducing the brightness or contrast rather than inverting — both also available via CSS filters.)

Theming the scrollbar

Well, almost complete. If images and icons kept their bright liveries and had to darkened, we faced the opposite issue with Mac’s autohiding scrollbar — it was black (and basically invisible) even in the dark mode.

I first started by experimenting with the vintage Webkit scrollbar CSS values and got somewhere half-decent, but we soon learned it came with a terrible price: any change to those made the scrollbars visible all the time, even if your Mac option was set to have them hidden until you scroll.

I went back to the drawing board. It turned out I didn’t need to worry about styling the scrollbar, but convincing the scrollbar to style itself. Mac’s scrollbar can actually turn light when needed. Except we weren’t scrolling the whole page, just a smaller element inside it, and for some reason that confused the scrollbar’s inner chameleon. Applying the background again directly to that scrollable element, even though redundant, made the scrollbar understand that it should become lighter:

.docs-page__content {
  background: var(--background);
  overflow-y: auto;
}

I also made sure that the scrollbar was glued to the edge. It’s annoying when the autohiding scrollbar sits in the middle and overlaps the content, and even more so in the dark theme. (And it makes it harder to grab if it’s by the edge of the screen!)

The solution was as simple as taking the padding from the parent element that wrapping the scrolling content, and moving it inside the scrolling element instead:

A high contrast theme

I also wanted to extend this project in another direction. I added one more theme — a high contrast one:

I will be the first to admit that this is not the best high contrast theme. Not only that: I am not even entirely sure what a good high contrast theme means. But I feel that it was important to at least start, to send the message that colours are not only about aesthetics, fashion, or comfort — to people with visual impairments, they might be the difference between being able to use the app or not.

The variables for the high contrast theme are beautiful in their simplicity…

html[data-theme='high-contrast'] {
  --text-color-normal: white;
  --text-color-light: white;
  --text-color-richer: white;
  --text-color-highlight: white;

  --link-color: white;
  --bright-color: white;
  --error-color: white;

  --button-background: white;
  --button-text-color: black;

  --background: black;
  --popup-background: black;
}

…and the new theme also became another unexpected test for the integrity of my set of variables and how I applied them. If a high contrast theme ended up putting white text on white background — or black on black — it meant something went profoundly wrong in my thinking, and that the contrast on any of the other two themes was probably in trouble, too.

In this way, I once more experienced that tried-and-true effect: accessibility gives universally. Trying to increase accessibility doesn’t just benefit a certain group of people; it benefits everybody.

(I do believe that a proper high contrast theme needs to have more borders and other elements for the eye to hang onto. Please let me know if you know. The one thing I changed was the shadow becoming more of a border, as demonstrated below.)

html {
  --popup-shadow: 0 5px 16px rgba(0, 0, 0, .25);
}
html[data-theme='dark'] {
  --popup-shadow: 0 5px 32px black;
}
html[data-theme='high-contrast'] {
  --popup-shadow: 0 0 5px white, 0 0 5px white;
}

That was it. I was done with the dark theme late afternoon, and I spent a few more hours over the next few days adding a couple of finishing touches and bug fixes.

I was kind of amazed that all of this could happen via CSS and CSS alone: the colours, the transitions, the vectors, and even the images:

I’m curious if you have any other tricks to share? Any other new CSS properties that could come in handy? Or a different understanding of dark themes? Please respond to this post or let me know via Twitter.

Thank you to Dane Bratz at Kite for overseeing the implementation, and to Kathy Ahn for being my writing buddy for this article.

BTW Kite is hiring! I had a great time there. If you’re a designer excited about engineering — or an engineer with strong interest in design, reach out to them.

#6: A love letter to the in-betweeners

This is a newsletter for Shift happens, an upcoming book about keyboards.

What am I typing this issue on?

Here’s one thing that’s been bringing me a surprising amount of joy when writing the book. No, it wasn’t figuring out final answers to puzzling questions (there really aren’t many), or finding Some Thing’s definitive first appearance (history, it turns out, generally dislikes the word “first” as much as it does “best”). It was encountering all the seemingly confused concepts, machines that didn’t quite belong, ideas before or after their time. The in-betweeners.

For a hot 19th-century second, the first popular typewriter looked like a sewing machine, complete with a foot pedal for “return.” Early 1960s computer keyboards had an extra component inside to… hit the case and make typewriter-like noise when typing. Along the same lines, there was an early computer with typewriter knobs. And a joystick to be mounted on top of arrow keys. And a typewriter with AM radio built in:

And many forgotten pocket keyboards:

Both the Canon Cat and the Ryan Seacrest case we talked about before are good examples, too. So are iPhones with built-in keyboards, early screen-less teleprompters, a Polish computer that repurposed a toy piano case, many amazing watch keyboards, or this monstrosity. Even your very keyboard has a few in-betweeners: Print Screen, Insert, Pause, Num Lock, and Scroll Lock all once helped bridge a gap between two eras, only to be half-reinvented or simply… abandoned.

All these examples often seem funny today, each one a horseless carriage of its time. But each one has something to say if you care to listen: it might be a story of comfort and familiarity, of a once-needed connective tissue, of the negotiations with — or simply the fear of — that steamroller that is The Future.

I am typing this on Olivetti Praxis 48. This 1964 office machine is an in-betweener in more ways than one. It’s an electric typewriter, from that now-forgotten era of electrically assisted keyboards that came after typewriters and before computers. It’s also an office machine that does something few other office machines dare to do: it looks absolutely gorgeous. You can fall in love with its compact size, its cantilevered keyboard, its ultra-symmetric buttons, its floating keys dipped in green. Once you get closer, it becomes a catalogue of deliberate details: you can press any key to turn it on, ridges on the side make it slender, green accents reappear in different places.

There are many beautiful keyboards — I keep a running tally of them in a Twitter thread — but the 48 goes one better. It tries to bring its playfulness and thoughtfulness into an environment that usually cares little about all of these things. There was no 47, and there would be no 49. In a worse world, the 48 wouldn’t exist and no one would miss it. In this one, we’re lucky that it did.

(Adam Richardson recently wrote an ode to this machine, filled with amazing photos. It’s worth checking out.)

Here’s a confession. I often feel like an in-betweener myself: an engineer turned designer, a European still getting used to America, someone that took a break from his professional career to write a random book. I am still figuring out how to navigate those largely unlabeled areas, and how to be less and less afraid of uncertainty. Your words of support help. Knowing kind people in similar situations does as well. But, in a strange way, so do the in-between machines. In all of them, I find comfort; in those that succeed — like the 48 did — I find validation.

What’s going on with the book?

I finished reading the first draft. It was an unusual experience. It felt so familiar, and yet I learned new things — even new words — from my own writing. It was peculiar, being able to read a book and rewrite it on the spot if needed. There were (few) moments I stopped in frustration; other times I ended up thoroughly elated.

I was prepared to hate it all. I didn’t. The beginning needs to be rewritten, and there are many rough edges. But the book didn’t feel boring, or long, or confused. It came together as a whole. I felt proud of it.

But whether this is good or bad, I have no idea.

Here’s a confession. I’m not actually writing it on the 48. I can’t. I broke it while attempting to fix it. Turns out, trying to glue together a broken-in-transit spacebar is harder than it seems. Turns out, using toothpaste to make metal more shiny makes that toothpaste go inside the mechanism and clog the entire thing. Turns out, electric typewriters are much more complicated and deserve much more respect than I gave them.

This is my first book. It’s hard for me to know how much to trust my own feelings, and how much to allow more experienced people to tell me what to do. I will continue trying to figure it out. I know I will bring my 48 to a mechanic and they’ll fix it. With the book, it’s more complicated; the more I look at it, the more it itself feels like an in-betweener. Despite trying, I honestly cannot point to another book quite like it.

Right now, I’m halfway through rewriting big parts of the book to arrive at the second manuscript. Then, it’ll be time to show a whole of it — or individual chapters — to other people. I hope you’ll be one of them.

A mini milestone

From the first day, I wanted to celebrate all the milestones, no matter how small — to reduce the pressure on the actual book having to live up to unreasonable expectations, and to help carry me through the arduous process. The most recent one? Someone just called me “author of Shift Happens,” and… seeing it phrased this way, for the first time, felt wonderful.

“I forgot what it’s called, but it’s this special typo machine.”

I found the videos of kids reacting to typewriters and an Apple II a hilarious and refreshing way to cut through all the nostalgia — plus, I actually learned some things from these!

A keyboard mystery

Can you figure out why does this keyboard look unusual? (And if so, can you tell me how you arrived at the answer? I’m genuinely curious.)

A secret document I’m sharing with you

Here’s the bibliography for my book, including links to things you can read online for free!

Come hang out with me

If you’re in Berlin in November, come see my talk at a conference called Beyond Tellerrand! It’s titled “An abridged history of having fun with the keyboard,” and it will be recorded. Can’t wait for you to see it.

Marcin

This was newsletter №6 for Shift happens, an upcoming book about keyboards. Read previous issues or subscribe: