Today, the book that started is one big step closer to reality.

My book about the 150 years of keyboards, from typewriters to the newest mechanical marvels, is now on Kickstarter.

I hope you will find it interesting and good enough to back — and/or tell others about it. Thank you!

On May 27, 2021, during an internal lightning talk session at Figma, I gave a remote “Ignite” 5-minute talk.

(This is a live recording; there was no video editing after the talk.)

I love Ignite talks and occassionally experiment with them, but this was the first one I’ve done remotely, and I’ve never spent so much time and effort putting together tech for it (mostly using OBS, which is an exciting experimental software used by streamers and remote presenters), and practicing.

In this post, I’ll be sharing a lot of details of how I did this. I don’t assume you will want to create another video like this (although why not?), but you might find bits and pieces of what I learned interesting.

This article has three sections:

1. The creative process and the setup
2. Specific tech questions
3. What I learned about controlling and scripting OBS (incl. all of my code)

Hope you enjoy!

1. The creative process and the setup

Why did I do this? It seemed like a weird gimmick and a fun challenge. Like with many of my weird creative projects, for most of the time I assumed that this will fail — after all, I haven’t heard of anyone doing something like this, and I had no idea if the tech was even available — but at least I will learn something.

Very quickly, I came up with basic questions:

• Can one do compositing in OBS? (can I overlap myself?)
• Can one feed the recording into itself as playback?
• How capable is OBS scripting? Can I do everything programmatically?
• Do I know how to make a consistently white background?
• Can I practice enough for this to feel good?
• Do I actually have something to say here?

I started answering the big ones first, and soon each one of them was replaced by a fractal of small ones. You’ll see most of them below.

The story

I knew I wanted to include Come into my world, Opportunities, and Tango. I quickly created a spreadsheet to try to map it out:

I originally planned to have five laps — one for each section — but this would leave less than a minute for each one. This felt tight time-wise, and also I didn’t know if I could make myself small enough using my camera/lens.

So, I ended with four laps, 70 seconds each, with a little room at the end to breathe. This coincidentally was exactly the structure of Come into my world, except that video’s laps were 61 seconds each.

I thought it’d be fun to mess in time in another way, by moving backwards — from 2002, to 1986, to 1980.

Quickly after establishing the early structure, I wrote down my script and started reading it out loud to gauge time needed:

As always with Ignite talks, I realized there is much less time than I expected: I had to drop more details about Minogue, there was a whole passage about rotoscoping her hair, and later on a reference to a Stanisław Lem short story about multiple Ijon Tichys.

In terms of a story, I struggled with ending, eventually arriving at a (cute?) hypothetical of describing something I was already doing… not sure if it ever quite landed.

I started practicing in front of camera as soon as I could, seeing how much time I need for certain things (e.g. putting the jacket on), and how do the gestures feel.

It was interesting to me how the structure pushed back on some of the ideas:

• I didn’t originally plan to fast forward, but that would make the first lap much too long. I hated this for the longest time, but now I think it works nicely.
• Originally, I wanted to put on the hat at the end at the exact moment I take it off originally — creating an impression this was the same hat — but the structure actually made it impossible without introducing a visible fifth lap!

Lastly, here are some of my ideas that didn’t happen:

• programmatically changing colours of the shirt or making me lighter with each loop
• cough at the same time (too hard to sync up)
• duck/throw something (dangerous)
• yawn (weird pause)
• subvert the glasses thing at the end by wearing weird glasses (didn’t fit with the story)
• instead of spelling F·O·U·R, do something more sophisticated (didn’t have a better idea)
• some more advanced choreo (ran out of time)
• turn on the light above me or pull up a banner or change the environment (ran out of time)

The setup

These are photos of the setup from both sides:

This is the diagram of the entire setup:

• Mac computer: This computer was grabbing the video from my camera, then in OBS the recording from that camera was fed back into OBS as video input after a 70s delay via a set of Lua scripts I wrote. The video camera source was always on top, so it required color key so that the white was “transparent” and the delayed videos in the background could be seen.

• Windows computer: The video output from the Mac computer was fed to a Windows computer’s OBS and composited with a pre-recorded 5-minute After Effects video that contained titles, “slides,” and all the music via another set of Lua scripts I wrote. The Mac computer output was always on top, and required a similar color key as above to allow the slides to be “behind me.” This computer also grabbed the sound from the mic, recorded everything, and sent things to Zoom.

• iPad: The iPad was responsible for showing the “timer” that alerted me to various events that were supposed to happen — it was like live quick time events. Most of the events were announced in real time, but for crucial things like moving to a new position (where I absolutely needed to do it at the right moment) there were counted down.

• There was also a fourth computer, but this was mostly used to connect to the Zoom independently, and just wait for my cue during the lightning talk session.

I’m surprised this actually worked

I almost quit many times:

• when the first attempts to script OBS resulted mostly in crashes, and when I realized how poorly documented everything is
• when I realized I would have to have two computers
• when my other Mac was too slow to handle OBS
• when the Windows computer that replaced it worked well for a while, and then stopped performing well

This was a project that reminded me of very early days of personal computers, where the technology was so young, the documentation so scarce, and the reliability so low, that you really needed to want it. I guess I really wanted this? But also, at some point, I wanted to keep going because I thought writing down

I learned a lot of little things from this: OBS scripting, Lua, After Effects, how to create a white background, how to make a blooper video (keep reading!), how to mount an iPad and use it as a helper, and even how to (very poorly) apply make-up.

The follow two sections have more details about the tech, all the way to source code:

2. Specific tech questions

How was the video looped?

In OBS, at least on a Mac, you can add the video of the current recording (if you figure out the filename) to the scene as a regular video. You can’t do it immediately, but since my loops were 70 seconds, that leaves more than enough time.

This is a snippet from a pretty creepy-looking early timing practice, with a lap length of 8 seconds (you will notice that it’s in reverse order, with the youngest me behind the older ones):

How did you make the slides/titles/etc.?

I used After Effects, and it was a pretty straightforward work.

I later used VLC to transcode the After Effects output to a .ts file that had a more manageable size. (ffmpeg also would’ve been great.)

How did you do the little rotoscoping bit?

There was a (short) video of the making of Come into my world from which I lifted the camera crane snippet, but I didn’t see any videos showing actual rotoscoping. So I used the After Effects function called Roto Brush, which was nice — and kind of magical — although really slow.

How did you know where to stand?

I put sticky notes on the floor and the table I used. Since the table wasn’t wide enough, I taped the sticky to a chopstick:

What kind of white screen did you have?

I don’t remember. I bought it a while back. It’s cloth.

I generally never quited figured out the best way to set this up. I put a random assortment of diffused lights in the back, and two diffused lights in front, but it never quite coalesced, and was painful to keep white — particularly at the edges and in the corners, where there was always some falloff (my space is very small).

I used a LUT to help with the background, and increased brightness/contrast as an OBS filter just enough. It was also important to switch my camera’s metering mode to “entire screen average.”

This is an example of me testing the light:

Why white screen and not green screen?

I think green screen is probably the way to go — see fringing in my video that I could never fully get rid of — but I already had a white background. I was also worried green screen would require even more lights. Something to try for next time!

How did you make the timer?

I mounted an iPad on a stand just below the camera, and wrote myself a little HTML/JavaScript app. It’s not very complicated.

You can see the timer here (click or press Enter to activate) or check out the source code.

Notes:

• most of the UI is at the top of the screen. It was originally centered vertically, but I noticed that this resulted in my eyes moving on the screen much more visibly
• there are special annotations when the music plays loudly. I actually didn’t hear any music as I was speaking, because I was worried it would create feedback or be recorded twice. So I needed a visual indication that music is playing so that I wouldn’t speak at that time.

If you are interested, here’s an entire talk with the timer overlaid so you could see what I saw. (This is a different take than above, because… why not.)

How did you mount the iPad below the camera?

I got this stand.

How did you mount the Windows computer close to the camera, so it could serve as a monitor?

I put it on my trashcan, and I put the trashcan on my piano seat. D’oh.

How much did you practice?

I recorded all of my practice videos, and so I know it was exactly 56 practice runs before the final one: ten reading the script, and 46 actually saying things from memory.

You can see here how it all changed over time:

What kind of mic did you use?

Since I was moving a lot, I thought the only reasonable way would be to use a lavalier mic. I also thought a cabled one would be better so I don’t rely on wireless. This is the one I used.

I think the lav in the videos introduces a bit too much noise and also it’s coming in a bit hot. Something to improve for the next time!

How to connect the lav mic to a Windows laptop?

I bought a little cheap device that connected via USB and exposed a mic input.

How did you prepare for failure?

This was incredibly complex system with a lot of moving parts I didn’t fully understand or control. So I did a lot of work to prepare myself for contingencies:

• a few days before, I made a “release candidate” video recording to have in the backpocket for the audience
• in the next few days, I kept replacing that video as I kept improving
• I had a pretty extensive checklist for the day off (this is only about 25% of it) and also a last-minute checklist on the wall:

• for the Mac, the checklist started from actually rebooting (sometimes connecting HDMI would make it go into an endless loop)
• I made both OBS have a deterministic start state (by default, OBS starts the way you left it last)
• on my Mac, I had this wallpaper set up just in case OBS decided to randomly crash in the middle (which it did once in a while):

What kind of camera did you use and how did you connect it?

I have a Sony Alpha a7R III. I used a 20mm (relatively wide angle) prime lens.

I had the ISO and focus set to manual. Also, I had the metering mode switched to “entire screen average”— that helped a lot.

I used a mini-HDMI/HDMI cable and connected it via Cam Link 4K to my Mac. That exposed it as a virtual camera that I could just use in Zoom (but not, for some reason, FaceTime). This is normally how I dial into work meetings.

Lastly, I used a fake battery connected to the mains.

How did you maximize room?

I don’t have a huge apartment, so I tried a few tricks:

• wide angle lens
• tilted the camera a bit up
• I didn’t know how to raise the camera so I didn’t cover so much of the screen… so instead I moved the recording down by 100 pixels. (Just needed to be careful not to move my hand up too much so they’d appear clipped.)

How did you pipe the video from Mac into the Windows computer?

I changed my MacBook’s resolution to 1920×1080 (non retina). I made OBS go full screen, I disabled True Tone and Night Shift, and I used (another, borrowed) Cam Link 4K with an HDMI cable.

(My friend recommended a cheaper capture device, but I never got it to work reliably in 1080p, only in 720p.)

Why did you use a Windows computer as a second computer?

I had a second MacBook, and an older Surface Book (first generation). I originally used the former, but it couldn’t handle even the compositing required, let alone also outputting to Zoom.

What I learned was that OBS on Mac for some reason isn’t hardware accelerated, but it is on Windows. So I dusted off the Surface Book, changed my code a bit, and run it there.

It handled everything swimmingly! Well…

How did you make Windows computer perform better?

After many days of working well, for some reason at some point the OBS on Windows started behaving poorly — skipping frames, choppy mouse cursor, that kind of stuff.

Nothing seemingly changed in the setup, and internet research proved inconclusive. I was despairing enough to consider buying a newer Windows laptop just for this… until I realized that just reducing the screen resolution to something much smaller (1920×1080, non retina) made it behave okay again.

The Windows computer used the virtual camera for Zoom, and recorded to file, and they were both using 1920×1080 regardless of the screen resolution. And I only looked at the screen as a monitor a few times during the presentation (the timer was the main source of info), so the actual resolution didn’t matter.

How did you share the video to Zoom?

Normally, Zoom combines two separate video sources:

• your webcam (prioritizes framerate over quality)
• your screen share (prioritizes quality over framerate, although there is an option to make it more closer to the webcam if you’re sharing video). Also, no pixels are cropped

If you are sharing with OBS, you can combine your screen and your webcam and potentially many other sources into one frame before Zoom even gets to it. And you can also send it back to Zoom in two different ways:

• as a webcam (making OBS create a fake webcam in your system that basically has your OBS screen)
• as a “projector” or just screen sharing an OBS window

It’s the former that I chose for this project, as I cared more about framerate than quality.

How did you share the audio to Zoom?

Unfortunately, the virtual camera doesn’t have the audio component.

I had to install a piece of software called Voice Meeter, which allowed me to redirect my microphone input from the USB dongle to a virtual output called B1. And this virtual output was also set as the output in Windows, ensuring the music from the pre-recorded slides was also mixed in.

(You might wonder why I didn’t just allow the microphone to be output to speakers in OBS. However, that also made the microphone be recorded twice in the recording, with a small delay, creating an awkward echo.)

Here are my settings:

Please note that the computer itself was muted, so I didn’t hear anything as I was talking.

How did you solve the issue of Voice Meeter audio getting garbled?

Voice Meeter’s audio engine sometimes makes the audio garbled and robotic (choppy). This seems to just happen once in a while.

You can fix this by choosing A1 menu and resetting the audio engine there.

To know whether my audio was garbled or not, I temporarily unmuted my computer, enabled A1 output in the first column (HARDWARE INPUT 1), and then plugging headphones to avoid feedback. If I could hear my microphone in my ear correctly, it means it worked. If not, I reset the audio engine as many times as it was necessary.

How did you solve the sync issue between video and audio?

Since I was recording the video on one computer, and audio on the other, there was a delay betwen video and audio as recorded and as sent to Zoom.

I actually didn’t solve it for Zoom — I didn’t get to it, thinking it won’t be very noticeable, since it was Zoom and I wasn’t that big on the screen.

For the recording, I adjusted the delay using ffmpeg:

ffmpeg -ss 00:00:28.00 -i input.mkv -itsoffset 0.3 -ss 00:00:28.00 -i input.mkv -map 0:v -map 1:a -c copy -t 05:00:00 output.mkv

How did you make Zoom go 1080p?

I don’t think I did. Don’t ask me more Zoom questions; I really hate Zoom.

How did you make sure the three devices started at the same time?

I connected a regular Logitech presentation remote to the Mac computer. In OBS on that computer, I assigned the script to the right arrow key.

Then, my Lua script would ping my server upon receiving that event, telling it to switch its time stamp to the current date.

The Windows computer and the iPad with the timer were both asking the server every 500ms for the saved timestamp. If they noticed the timestamp being newer than the last one, they started their own parts.

This wasn’t very precise, of course, but it was precise enough for me.

(Also, this was an external server, which was a bad idea — it would’ve been better for it to be internal, but then again I needed internet to give that talk, so…)

(Also, I used regular GET/PUT, rather than something smarter like websockets. Seems to have worked well.)

What font is that?

Bild Compressed from David Jonathan Ross.

How did you stop your cat from interfering with your practice or messing up your sound by meowing?

Trick question. You can’t control cats.

3. What I learned about controlling and scripting OBS

I found OBS to be pretty poorly documented – there is a bit of documentation, but few solid examples… and there is a community of people who share scripts, but the coverage seems low.

I put up my source in GitHub here (with some comments):

• OBS Lua script for the first computer (Mac)
• OBS Lua script for the second computer (Windows)
• Timer app (iPad)

And below I’ll tell you every tricky part about OBS that I learned in the process.

Note: All of the below require this line, which seems to be a standard way to shorten obslua in all the scripts I’ve seen online:

local obs = obslua

Why OBS and not Streamlabs OBS?

I couldn’t get the virtual camera to work on my Mac with Streamlabs OBS, but could in OBS. (Eventually, I ended up not needing it, but was already used to OBS by then.)

How to log to OBS’s console (called Script Log)?

I found this somewhere:

local function log(name, msg)
  if msg ~= nil then
    msg = " > " .. tostring(msg)
  else
    msg = ""
  end

obs.script_log(obs.LOG_DEBUG, name .. msg)
end

How to effectively iterate in OBS?

OBS crashed a lot, particularly if I wanted to run the same script again. It’s possible that I was doing something wrong — perhaps not releasing the resources properly, etc.

But it’s also a bit clunky to reload the scripts since there is no keyboard shortcut, and the button is in a window rather than exposed.

So I learned that the best way to iterate is to quit OBS and quickly open it again. Qutting even as the file was being recorded seemed to have finished the recording properly, and restarting the app forced my script to reload, too.

One challenge was that OBS remembers its state (all the scenes and items) between openings — so I had to make OBS forget the latest changes and always wake up in a predefined state:

How to start OBS in a certain state (Mac)?

When I was happy with my OBS settings, I duplicated the entire directory ~/Library/Application Support/obs-studio and renamed the result obs-studio-kylie

I wrote this shell script:

rm -rf ~/Library/Application\ Support/obs-studio

cp -R ~/Library/Application\ Support/obs-studio-kylie 
  ~/Library/Application\ Support/obs-studio

open /Applications/OBS.app

I named the file startObs.sh.command — the last addition allowed me to drag it into the dock.

Lastly, in the Terminal app, I went to Preferences, and then Shell, and set When the shell exists: to Close if the shell exited cleanly. This made sure that my script didn’t leave behind a terminal window. (Which would be visible to the audience if OBS crashed.)

How to start OBS in a certain state (Windows)?

I created a .bat file. Instead of replacing the whole setup, it only deletes all the scenes, and replaces with the new one. I probably would’ve deleted the entire directory instead, like above, for simplicity:

del /q c:\users\mwich\AppData\Roaming\obs-studio\basic\scenes\*.*

copy c:\users\mwich\desktop\kylie\bat\z.json 
  c:\users\mwich\AppData\Roaming\obs-studio\basic\scenes

cd "C:\Program Files\obs-studio\bin\64bit"
obs64.exe

How to make OBS go full screen?

I wanted a pure 1920×1080 output from OBS so I could redirect it to the Windows computer.

Normally, one would use a virtual camera or a recording, but this needed to go live over HDMI. I think long time ago I’ve used something called a projector, but:

• the last time I used them, they still had bits and pieces of UI
• I only had one display, and I felt this would’ve made things complicated
• I remembered it taking extra CPU
• I actually, believe it or not, couldn’t find it in the UI

The solution I found was basically configuring OBS to remove all the UI:

• I toggled all of these options off, and used Lock UI so that they wouldn’t reset
• In the Edit menu (why there???), I opened Preview Scaling, and changed it to be 1:1 (otherwise even in fullscreen, there was a bit of a bezel)
• I made OBS go fullscreen via Mac’s regular “green button”

How to move an item in the scene?

This is how to move it down by 100px:

local item = obs.obs_scene_add(current_source, camera)
local pos = obs.vec2()
pos.x = 0
pos.y = 100
obs.obs_sceneitem_set_pos(item, pos)

How to resize an item?

I ended up not needing that, since all of my items were matching the 1920×1080 resolution of the whole scene, but just in case:

local item = obs.obs_scene_add(current_source, camera)
local scale = obs.vec2()
scale.x = 0.9375
scale.y = 0.9375
obs.obs_sceneitem_set_scale(item, scale)

How to move an item in the z-index?

local item = obs.obs_scene_add(current_source, camera)
obs.obs_sceneitem_set_order(item, obs.OBS_ORDER_MOVE_BOTTOM)

How to remove all items in a scene?

local sceneitems = obs.obs_scene_enum_items(current_source)

for i, sceneitem in ipairs(sceneitems) do
  local sourceSrc = obs.obs_sceneitem_get_source(sceneitem)
  local type = obs.obs_source_get_id(sourceSrc)
  local settings = obs.obs_source_get_settings(sourceSrc)
  obs.obs_sceneitem_remove(sceneitem)
end

How to prevent a red border from appearing around things?

Newly-created items are selected and therefore have a red border around them. This doesn’t matter for a virtual camera (used by Zoom) or for recording, but it matters when you capture the Zoom UI to another computer as per above.

I could not find a way to deselect items programmatically in OBS, but locking them does the tricky:

local color_item = obs.obs_scene_add(current_source, color_source)
obs.obs_sceneitem_set_locked(color_item, true)

How to set up a color key filter programmatically?

local recording_filter_settings = obs.obs_data_create()

obs.obs_data_set_int(recording_filter_settings, "key_color", 0xffffffff)
obs.obs_data_set_string(recording_filter_settings, "key_color_type", "custom")
obs.obs_data_set_int(recording_filter_settings, "similarity", 57)
obs.obs_data_set_int(recording_filter_settings, "smoothness", 94)

local recording_filter = obs.obs_source_create_private("color_key_filter", "Recording Filter", recording_filter_settings)

obs.obs_source_filter_add(camera, recording_filter)
obs.obs_data_release(recording_filter_settings)
obs.obs_source_release(recording_filter)

How to fade out?

First, create a completely white scene:

fadeout_scene = obs.obs_scene_create('Fadeout')
local new_something = obs.obs_scene_get_source(fadeout_scene)
local new_source = obs.obs_scene_from_source(new_something)

local color_settings = obs.obs_data_create()

obs.obs_data_set_int(color_settings, "width", 1920)
obs.obs_data_set_int(color_settings, "height", 1080)
obs.obs_data_set_int(color_settings, "color", 0xffffffff) -- White
local color_source = obs.obs_source_create("color_source", 
  "Color", color_settings, nil)
local color_item = obs.obs_scene_add(new_source, color_source)
obs.obs_sceneitem_set_locked(color_item, true)
obs.obs_data_release(color_settings)

Then, set a fadeout timer:

obs.timer_add(start_fadeout, (5 * 60 + 25) * 1000) -- 5m25s

And then, transition:

function start_fadeout()
  obs.timer_remove(start_fadeout)

local new_something = obs.obs_scene_get_source(fadeout_scene)

local transitions = obs.obs_frontend_get_transitions()
  local fade = find_source_by_name_in_list(transitions, "Fade")

obs.obs_frontend_set_current_transition(fade)

obs.obs_transition_start(fade, obs.OBS_TRANSITION_MODE_AUTO, 
    2000, new_something)
end

How to only fire a timer once?

You initialize a timer this way:

obs.timer_add(something, 2000)

This will call a something function every 2 seconds. To do it only once, do this:

function something() {
  obs.timer_remove(something)

...
}

Yeah, I know, it’s weird.

How to add CamLink capture programmatically? (Mac)

local camera_settings = obs.obs_data_create()

obs.obs_data_set_string(camera_settings, "device", "0x1100000fd90066") -- Cam Link 

obs.obs_data_set_string(camera_settings, "preset", "AVCaptureSessionPresetHigh") -- This means 1920x1080

local camera = obs.obs_source_create("av_capture_input", "Camera video", camera_settings, nil)
local item = obs.obs_scene_add(current_source, camera)
obs.obs_data_release(camera_settings)

How to add CamLink capture programmatically? (Windows)

Very similar, but some parameters are named differently :

local camera_settings = obs.obs_data_create()

obs.obs_data_set_string(camera_settings, "video_device_id", "Cam Link 4K:\\\\?\\usb#22vid_0fd9&pid_0066&mi_00#227&71832f1&0&0000#22{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\global")

local camera = obs.obs_source_create("dshow_input", "Camera video", camera_settings, nil)
local item = obs.obs_scene_add(current_source, camera)
obs.obs_data_release(camera_settings)

How to get the necessary CamLink id? (Mac)

After opening System Information and going to Camera, the Unique ID is listed here. Then, you can plug it here:

obs.obs_data_set_string(camera_settings, "device", "0x12000000fd90066")

Note that the first digits of the id will change if you connect it to a different USB port… so don’t do it.

How to get the necessary CamLink id? (Windows)

If you go to Device Manager, then Cameras, then Details, and then just sort of click around, you will find all the necessary part to construct the id:

Here’s an example:

obs.obs_data_set_string(camera_settings, "video_device_id", "Cam Link 4K:\\\\?\\usb#22vid_0fd9&pid_0066&mi_00#227&71832f1&0&0000#22{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\global")

How to know the various names of settings for various items you can put in the scene?

This seems (or is) poorly documented. The best luck I’ve had was looking at the source code.

For example, wanting to know how to programmatically create a color key filter, I looked at settings here in GitHub to know the right string ids, and then looked further down in the file to see whether they’re numbers, strings, bools, etc.

To find the filter id I needed, I searched for .id and found it here.

This led me to knowing that I need to do this, in this example:

local recording_filter_settings = obs.obs_data_create()

obs.obs_data_set_int(recording_filter_settings, "key_color", 0xffffffff)
obs.obs_data_set_string(recording_filter_settings, "key_color_type", "custom")
obs.obs_data_set_int(recording_filter_settings, "similarity", 57)
obs.obs_data_set_int(recording_filter_settings, "smoothness", 94)

local recording_filter = obs.obs_source_create_private("color_key_filter", "Recording Filter", recording_filter_settings)

obs.obs_source_filter_add(camera, recording_filter)
obs.obs_data_release(recording_filter_settings)
obs.obs_source_release(recording_filter)

(Random note: it seems that color_key_filter has a v2 version! Either this is new, or I didn’t notice it before.)

How to figure out what are the right setting values if those are not obvious?

What I found useful is creating the right item by hand, and then writing a script to inspect and output the setting:

local sceneitems = obs.obs_scene_enum_items(current_source)
for i, sceneitem in ipairs(sceneitems) do
  local sourceSrc = obs.obs_sceneitem_get_source(sceneitem)
  local type = obs.obs_source_get_id(sourceSrc)
  local settings = obs.obs_source_get_settings(sourceSrc)

log('local_file', obs.obs_data_get_string(settings, "local_file"))
  log('looping', obs.obs_data_get_bool(settings, "looping"))
end

That was useful, for example, to know the expected values of these two settings, for example:

obs.obs_data_set_string(camera_settings, "device", "0x1100000fd90066")
obs.obs_data_set_string(camera_settings, "preset", "AVCaptureSessionPresetHigh")

How to start and stop recording?

Easy:

obs.obs_frontend_recording_start()

and:

obs.obs_frontend_recording_stop()

How to start a virtual camera? (Windows)

Contrary to the above, this is not available directly. But I found somewhere a pretty weird recipe that goes back to C.

Somewhere at the top, you have do this. This, I believe, creates a link to C and writes some code in C that’s necessary to supplement Lua:

local ffi = require 'ffi'
local obsffi
if ffi.os == "OSX" then
  obsffi = ffi.load("obs.0.dylib")
else
  obsffi = ffi.load("obs")
end

ffi.cdef[[
typedef struct obs_hotkey obs_hotkey_t;
typedef size_t obs_hotkey_id;

const char *obs_hotkey_get_name(const obs_hotkey_t *key);

typedef bool (*obs_hotkey_enum_func)(void *data, obs_hotkey_id id, obs_hotkey_t *key);
void obs_enum_hotkeys(obs_hotkey_enum_func func, void *data);
]]

Then, this function does the rest:

function start_virtual_cam()
  local target = 'OBSBasic.StartVirtualCam'
  local htk_id

  function callback_htk(data, id, key)
    local name = obsffi.obs_hotkey_get_name(key)

    if ffi.string(name) == target then
      htk_id = tonumber(id)
      return false
    else
      return true
    end
  end

  local cb = ffi.cast("obs_hotkey_enum_func", callback_htk)
  obsffi.obs_enum_hotkeys(cb, data)

  if htk_id then
    obs.obs_hotkey_trigger_routed_callback(htk_id, false)
    obs.obs_hotkey_trigger_routed_callback(htk_id, true)
    obs.obs_hotkey_trigger_routed_callback(htk_id, false)
  end

end

The code seems to indicate it’s cross-platform, but I only tested this on Windows.

How to check whether a file exists?

function file_exists(name)
  local f = io.open(name, "r")

  if f ~= nil then
    io.close(f)
    return true
  end

  return false
end

How to read from a local file?

local handle = io.open("c:\\Users\\xxx\\Desktop\\yyy.txt", "r")
local result = handle:read("*a")
handle:close()

Note I only tested this on Windows.

How to access a certain URL (Mac)?

local url = "https://aaa.bbb/ccc"
local status = os.execute("curl --connect-timeout 1 --max-time 1 '" .. url .. "'  2>&1 &" )

Please note that I just needed to ping a URL, without worrying about status.

How to access a certain URL without blocking the UI (Mac)?

In OBS, executing commands blocks the main thread, which is really not great. However, accessing a local file doesn’t (or if it does, it’s imperceptible). Therefore, I just ran a local Node script that connected to the server and updated a local file… and then had OBS check the local file instead.

How to mute a video source?

Add a gain filter with a lot of negative gain. (Maybe even more than -30dB?)

local recording_filter_settings = obs.obs_data_create()
obs.obs_data_set_double(recording_filter_settings, "db", -30.0)
local recording_filter =
  obs.obs_source_create_private("gain_filter", "Mute",
  recording_filter_settings)
obs.obs_source_filter_add(recording, recording_filter)
obs.obs_data_release(recording_filter_settings)
obs.obs_source_release(recording_filter)

What’s audio output and monitoring and how does it work?

I don’t know if I fully understand this, but here’s what I think:

• By default, all the audio input sources in OBS are in Monitor Off mode, which means they get sent to streaming if you enable streaming (I didn’t use that functionality), and recorded properly. However, they are not actually output through the speakers (“monitored”) since you might not want to e.g. hear yourself again.
• You can switch any audio mode to Monitor And Output, which means they will both get recorded and output to speakers.
• You can switch any audio mode to Monitor Only (Mute Output), which means you can only hear it, but it doesn’t get streamed/recorded.
• You can also just disable any audio input, although I am not sure how.

(If you are the person who arranged the options this way and labeled them, I have some harsh words for you. This is really confusing for something that could be three simple checkboxes.)

Some of the controls are available in the main window, next to meters, and the rest is in the Edit menu (for some reason) when you choose Advanced Audio Properties. Here’s a picture of both:

How do you set it programmatically?

First, you register a handler that tells you when any of those sources get activated or deactivated:

function script_load(settings)
  local sh = obs.obs_get_signal_handler()
  obs.signal_handler_connect(sh, "source_activate", source_activated)
  obs.signal_handler_connect(sh, "source_deactivate", source_deactivated)
end

Then, redirect both of these handlers to one function:

function source_activated(cd)
  set_monitoring(cd, true)
end

function source_deactivated(cd)
  set_monitoring(cd, false)
end

And then, in that function, turn the monitoring options:

function set_monitoring(cd, enable)
  local source = obs.calldata_source(cd, "source")

  if source ~= nil then
    local source_id = obs.obs_source_get_unversioned_id(source)

    if (source_id == 'ffmpeg_source') then

      if enable then

        obs.obs_source_set_monitoring_type(source, 2) 
        -- OBS_MONITORING_TYPE_MONITOR_AND_OUTPUT

      else

         obs.obs_source_set_monitoring_type(source, 0) 
         -- OBS_MONITORING_TYPE_NONE

      end

    end

    if (source_id == 'scene') then
      obs.obs_source_set_monitoring_type(source, 0) 
      -- OBS_MONITORING_TYPE_NONE
    end

    if (source_id == 'wasapi_input_capture') then
      obs.obs_source_set_monitoring_type(source, 0) 
      -- OBS_MONITORING_TYPE_NONE
    end

  end
end

I found the source ids the same way as I described above. ffmpeg_source was the After Effects video playing, scene was the entire scene, and wasapi_input_capture and wasapi_output_capture was input/output from the little USB device. (This is on Windows.)

How to change the volume or set the audio source to be active or not?

I never got this to work. Fortunately, it wasn’t necessary. But in theory, it’s this:

obs.obs_source_set_volume(source, 0)
obs.obs_source_set_audio_active(source, false)

What is the difference between “scene” and “source” in OBS?

I seriously never got it. Sometimes I think the names are reversed, or don’t match the UI names. I basically button-mashed my code into working.

This works, for example, but I have no idea why, the names of the functions don’t seem to match the output, and at some point I just gave up understanding. Please let me know what I’m missing.

new_scene = obs.obs_scene_create('NAME')
new_something = obs.obs_scene_get_source(new_scene)
new_source = obs.obs_scene_from_source(new_something)

What’s the importance of “local” in front of a variable?

Honestly, no idea. I assume it’s related to scope, but it didn’t seem to matter in my case a lot.

Thank you so much to Lauren Budorick for being patient, and testing the setup with me on multiple occasions. Additional thanks to Basia Wichary and Matt Braithwaite.

The rectangle behind you, a series of articles about interactive presentations.

By Marcin Wichary (@mwichary)

The making of Four Laps was originally published in The rectangle behind you on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Ignite talk that changed room colours

This is a five-minute Ignite talk I gave at ORD Camp 2019:

I got excited about the idea of using the room’s ambient lights after seeing a demo of the light setup and console in the conference room at Google in 2018, and witnessing that room change colours:

I thought it’d be fun to use that capability, so I reached out to the event technician, Nicholas Carroll, to ask him if we could collaborate on a talk.

Eventually I came up with a script talking about ambient colours in technology. But since Nick was in a different city, I had to create two artifacts:

• a spreadsheet that showed the cues and general ideas

• a reference video, with Hue lights roughly showing what I was after

Nick helped me with fine-tuning a lot of this and adapting it for the room, whose lightning capabilities were much more sophisticated. He added some light animations, and note how in the talk I’m lit differently to be always visible… with one slide being a crucial exception.

(Note: We couldn’t make the room completely black, because emergency exit signs had to remain illuminated. Steve Jobs movie, anyone?)

To synchronize my slide deck and his script, we went an old-fashioned route. I just had a quick countdown timer at the beginning, so Nick knew to start his programmed routine at the right moment.

That’s it! If it helps, the snippet of code I used to control my hue lights was this:

function changeLight(lightNo, lightData) {
  let oReq = new XMLHttpRequest()

  oReq.open(
    "PUT",
    `http://192.168.7.238/api/ACVASCN7N-muRklx8jmHwfa5NP7QSf3xTAMSrzKG/lights/${lightNo + 1}/state`

  )

  let data = {
    on: true,
    bri: Math.round(lightData.bri * 254),
    hue: Math.round(lightData.hue * 1.0 / 360 * 65535),
    sat: Math.round(lightData.sat * 254),
    transitiontime: 10, /* x100ms */
  }
  oReq.send(JSON.stringify(data))
}

Thank you so much, Nick!

The rectangle behind you, a series of articles about interactive presentations.

By Marcin Wichary (@mwichary)

The rectangle behind you: The Ignite talk that changed room colours was originally published in The rectangle behind you on Medium, where people are continuing the conversation by highlighting and responding to this story.

I wonder sometimes what would be the oldest extant word based on technology no longer in use. Taping an interview? Dialing someone?

I received many more answers than I expected, although it soon became obvious how my rules were impossible to follow, even by me: What exactly is technology, and which technology ever truly goes away?

Scrolling (who remembers scrolls?) feels different than fonts (used more than ever, in a digital form directly evolved from a physical predecessor), and somewhere in between these would be a tablet — a new tech inspired by old one, although without a direct connection.

But despite (or maybe because) the fuzzy rules, it was fun to comb through the answers, and ponder how often technology hides in everyday language long past its own limelight. So, let’s check out some examples.

Note: The following will be very English-centric.

We dial a number — or dial someone — even though dials disappeared from phones decades ago. And we hang up even though there’s rarely a handset that actually needs to be hung up.

Both radio and TV stations still ask us to tune in, even though tuners don’t really exist in television any more (and in the radio, tuning is much more automatic, using buttons and programs rather than… another dial.)

(Side note: to tune in, someone needs to broadcast, which originally meant scattering seeds in a broad field, by hand. And even if you don’t broadcast, you can still telegraph your intentions… without the actual telegraph.)

The user interface component where you choose one of a few options is called radio buttons, based on old radio buttons you’d toggle to… tune in to different frequency bands.

(To add to an already massive confusion, the user interface component on a Mac that actually looks like old radio buttons is called “tabs.”)

People still talk about rolling down a window in a car, even though they don’t roll a circular handle — it’s the motor that does it today. (And you can still ask to crank up the volume, too.)

We still talk about rewinding video, long after we stopped using magnetic tape that needed to be wound and rewound. And yes, we also tape things (meaning: record them), and some of us get good enough to start filming things, often on a digital camera that never touched film. When you tape or when you film, you amass footage — although no longer measured in actual feet of film or tape length.

(Taping should not be confused with wiretapping, which used to mean a tap on an actual wire, and now largely outgrew it.)

In some places, a finished artwork is still called camera-ready, from the days it needed to be photographed in order to be reproduced. And the camera itself? The word means “room,” from when camera obscuras were room-sized. To think if earliest giant computers arrived first, they could be called cameras today… (And speaking of which, an interesting inversion: computer used to mean a person doing computing, before it became a term for a machine — a distinction once awkwardly preserved in two spellings: computer and computor.)

In a visual world, play button triangle refers to moving tape from one reel to another — more of those abstract symbols are documented here — and don’t even get me started on the save icon!

Many of today’s terms come from the nautical world. Taken aback used to mean a wind suddenly reversing, and your sailing ship going backwards. Bitter end refers to the bitts, where the end of a rope was attached (also see: at the end of one’s rope). Pooped? Originally: swamped by a following wave. And, on a good day you might have find yourself on an even keel, as your boat once was.

Some of these terms might still be in use, although here’s the kicker. As someone reported:

I’ve worked for 13 years in the modern maritime industry, and I can confidently assert (because I’ve asked them) that none of the modern maritime workers I’ve worked with even know that these terms came originally from their own field.

One of the most interesting examples is an album. A photo album was — still sometimes is — a physical item, but so was a music album once: early records were packaged with many records in one big book, each song occupying a whole side of a record. The word that meant a physical item evolved to mean more of a concept…

…but maybe not really! The word album itself comes with a Latin noun meaning “blank tablet.” And, today, there are once more multi-record vinyl albums, so maybe — excuse the pun — all of these things are just revolutions.

(A meta inversion: in a conversation a few people referred to older shellac records as vinyl records, and I called an old phonograph a gramophone. Of course, shellacking might be a good candidate, since shellac is no more in common use.)

Some people say catching you on the flip side originated from two sides of the record: you’d see someone later, after the record finished its current side and had to be switched to another.

And, one of my favorites: a record label — once a physical attribute of a physical artifact, now a faraway business concept.

(And, in the world of sounds, the common example might be the record needle scratch, even recently turned into a meme.)

Knots as a measure of speed comes from sailors using a knotted rope to determine a speed of ship. (Knots exist today, of course, but maybe aren’t used for that specific purpose.)

Horses do little that’s measured by horsepower (although that unit is slowly disappearing, too), and candela as a unit refers to the candle — candles still exist, of course, but we usually measure light output of more advanced technologies. Likewise, you can still be in the limelight without any actual limelight.

Burning the midnight oil comes from working late by a lamp literally burning oil. And gaslighting is particularly interesting — referring to vintage and forgotten technology, too, although abstractly so, the word itself based on a 1938 play called Gas Light.

(Speaking of horses, dashboard used to mean something very different: a barrier of wood or leather fixed to the front of a carriage to protect the driver from mud or debris “dashed up” by the horses’ hooves. And typewriter carriage harkened back to the horse carriage, although it was outlived by it — except in the extant technical term carriage return, or CR.)

Refrigerators are no longer iceboxes (even though some people still call them that). Ringing up a sale used to mean a cash register actually ringing. Even your Apple Watch still strikes twelve.

We still talk about CC, coming from pen and typewriter carbon copies — either many pages interspersed with carbon paper, or later special paper with carbon backing that would duplicate itself during typing.

Typing itself is related to type (metal letters) through typewriting — we no longer often call onscreen letters “type,” although we still talk about typography.

And, on the modern keyboards, we still see Shift that does no physical shifting, and Backspace that does quite a bit more than just going back one space. They date back to the 1880s, but changed in 1980s as computers took over typewriters.

Slide decks or slideshows in your PowerPoint or Keynote consist of slides, originally physical objects which the projector (or magic lantern before it) used to slide into place in front of the source of light. (Yes, sometimes limelight.)

The world of typesetting is filled with probably as many historic terms as the nautical world, but the one that achieved widespread attention is uppercase to mean big letters, and lowercase for small letters — coming from two physical cases, one above the other, holding the type used for printing.

Then there is the story of stereotype and cliché, twin technologies whose names were adopted and evolved to mean something very similar.

And we scroll around on our computers, even though we barely remember an ancient technology of scrolls. (Funnily enough, in 1970s computing a word “roll” battled for dominance, too, meaning scrolling, and referring to pretty much the same item.)

There are tablets that harken back to very different tablets — and even without one, you can still talk about a blank slate or wiping the slate clean.

Today’s branding comes from a branding iron used to brand cattle and claim it as belonging to you, and ear-marking is of similar nature.

Some terms are even more niche and specific, but nonetheless interesting. Priming the pump is an economic term meaning seed money or bootstrapping, coming from pouring liquid into a pump to expel the air and make it work, in the late 1800s. And, bootstrapping itself has vintage connotations.

People in the U.K. talk about it being cold enough to freeze the balls off a brass monkey; the origins of that phrase are only partly technological, but wholly fascinating.

Cinderblocks no longer contain cinder. A cornerstone no longer refers to the the first stone set in a masonry foundation, guiding the orientation and placement of the whole building.

Teamsters originally drove teams of horses, now they’re driving trucks. Freelancers are people for hire, but no longer required to carry a lance. Original saboteurs wore noisy sabots and were generally noisy, interrupting work with constant labour disputes.

A computer directory harks back to a physical book. (Unless your computer calls it a folder, but those can still be found in an office supply store.) Similarly, people pencil you in — pencils still exist, although the term refers to a physical agenda that sees less and less use. Some people pen a novel, but on their keyboards. Or do bookkeeping without books designed to hold your finances. Or, still refer to their list of contacts as a rolodex.

And one of those things really goes back in time: Pen as a writing instrument dates from the proto-Indo-European word for “feather,” although though quill pens became obsolete two centuries ago. A clay pot (ostracon) shards were used to vote on banishment from ancient Athens, which morphed into ostracizing. Divan comes from a Sumatran word for “clay tablet” + “house.” (“I guess that’s like if we had an iPad chair and 4000 years later people were still calling it a padchair but the meaning of pad was completely obscured.”)

And even the very letter A: it original shape from 4 millennia ago was derived from an ox, early technology of castrated male cattle used for plowing, pulling carts, or threshing grain (and possibly also influenced threshold?).

And there are cases where we don’t have to go far at all. The very original question started from a recent word podcasting, peculiar in a few ways: the rare word here related to a commercial product, a product that feels ancient even though it is still being sold, and a device that has never been actually very good at podcasting to begin with.

But then again, what do you expect when you intersect a messy world of languages with the messy world of technology?

Thank you to everyone who participated in the original thread, and Helen Rosner for instigating it with her tweet.

Stories of San Francisco’s ghost stations

New York has abandoned subway stations in all sorts of configurations: never opened, opened and then closed, half-closed, incomplete — some with ghost platforms, others with doors floating in the air, not to mention a closed station that looks better than many opened ones. Chicago has politics, shutdown blocks-long superstations, carcasses of some stations used to build others, and even eleven former ghost stations: opened, closed, and then reopened again. Ah, even L.A. has a secret subway from before it sold its soul to automobiles.

And then there’s San Francisco, with only a few mildly interesting abandoned transit spaces: a tunnel in Fort Mason, Bayshore roundhouse, former (possible) transit stops on the Bay Bridge. Counting proper ghost stations gets you to… one. Well, maybe two, if you bend the rules a bit.

But they’re still our two ghost stations, so let’s spend some time learning their history and looking at some wonderful photos (some never before seen online). If you’re like me, you might be surprised to find out how much both stations have in common, and what tumultuous journeys got them to where they were.

Part I. Eureka (Valley) Station, 1918–1972

At the turn of last century, we treated Twin Peaks, one of the city’s most famous hills, as a billboard. In 1901, someone adorned it with an ad for Cook’s Water (not a proto LaCroix, as I assumed, but rather a popular resort)…

…and by 1913, with two separate big-lettered ads:

Luckily, the tradition didn’t continue for much longer — from now on, only the things on the ground and below it would multiply.

Both of the photos above point to the end of Market Street, already the city’s biggest and most important street, although much abbreviated from present day’s perspective.

Today, you can get into a car at the bottom of Market Street by the Ferry Building, and witness its five personalities without ever changing a lane: first a straight line cutting through downtown like a solidus, then a winding road that sheds most of transportation and hugs the bottom of Twin Peaks, followed by its renamed continuation — Portola Drive — sneaking by San Francisco’s most famous canyon right before the city’s highest natural point, to then morph into to a Boulevard, and eventually become an Interstate claiming to be “the world’s most beautiful,” leading all the way to San Jose.

But in 1913, Market Street just… ended. You could turn left into Castro Street and visit a brand-new Castro Theater (not the one you’re thinking of! and not as impressive!), or choose to turn right into 17th Street towards the largely uninhabited western parts of the city. Alternatively, you could stay at the intersection and visit the well-known pharmacy… or even move into the new, shining, white four-story apartment building that sprang up next to it in the recent few years.

But the last one would’ve been a bad idea. For the first steps to extend Market Street and turn it into a 60-mile ribbon would start within a year — and its first casualty would be that very building.

The plan was far more ambitious, however, than just making Market Street longer. It was to make Market Street longer twice — split it into a more impressive thoroughfare for cars, but also allow the trams already traversing the diagonal street to simply keep on going, through a streetcar tunnel that would become the world’s longest and take them all the way to the other side of Twin Peaks, considerably shortening the downtown commute of people living there.

The following maps show Market Street before the extension, the Twin Peaks Tunnel during construction, and the eventual outcome with both the tunnel and Market Street continuing southwestward: overlapping for a few blocks, then going their separate ways.

Construction on the tunnel started at the end of 1914…

…with the extension of Market Street hugging both sides of its entrance (called the East Portal), and a bunch of buildings sacrificed to create room for both:

The project was ambitious in another way. It recognized, even in the early 1910s, that the future of the already-congested Market Street was public transit running below it.

And so, at the entrance to the new Twin Peaks tunnel, the tracks dipped down sharply so they could get underground really quickly — and, in the future, the rest of Market Street would join them there.

The tunnel, called by then-mayor Rolph “the last tunnel which reveals to the eyes of the people of the East the Golden Shores of the Pacific,” opened in 1918, frequented by streetcar lines with letters — K, L, M — recognizable to any rider today.

There were two small boarding platforms just before the entrance to the East Portal but, of course, with the entire Market Street streetcar traffic soon moving underground, the stop would disappear and was meant as temporary.

Instead, not far from the entrance inside the subway, a proper station was built. Named after both the valley and the nearby street, it was called either Eureka Valley Station, or Eureka Station. (We could never truly decide.)

Streetcars entered the station via the tunnel. For pedestrians, there were four small kiosks located by the sides of Market Street, still in the process of being extended, with the tunnel running directly underneath. In the photo below, the four brand-new kiosks are clearly visible — as is a guy hanging his laundry:

The kiosks were tiny, although elegant, each one hiding stairs leading to platforms below:

In this photo from July 1919 — the kiosks and the tunnel already open — it becomes obvious how little-developed that part of the city still was (and also the apparent popularity of hanging out white laundry):

In later photos, we can watch the process of paving first the cross streets…

…and, by 1920, the extension of Market Street itself:

The diagram below shows how the kiosks connected to the subway platforms:

But the plan was even more ambitious. It wasn’t just extending Market Street for cars and public transit. It wasn’t just anticipating Market Street streetcars going underground. It was also planning for another tunnel — Sunset Tunnel, which meant to start at the same place, and Eureka Station to become a crucial connector that would send you off to your journey west, or your journey north.

Then, as you probably anticipate, life did what life does to best laid plans.

But we should finally take a look at the station itself.

We know it was simple, spartan even — so rudimentary that few bothered to take the time to describe or photograph it. A few photos of its construction remain, with the East Portal visible in the background:

There is also a short surviving video, showing the project’s officials – among them the legendary civil engineer Michael O’Shaughnessy who started this whole project:

After tons of searching, I eventually found a rare Eureka Station photo in normal use, showing a simple construction with brightly lit platforms. This could almost be a tiny subway station in London or uptown Manhattan, if not for a K streetcar promising Ocean To Phelan, its single light shining into a camera and giving us a pretty flare.

San Francisco waited to put Market Street streetcars underground for so long that streetcars themselves became obsolete. What was eventually moved underground — in mid-1970s, six solid decades after Twin Peaks Tunnel — were more advanced light railway vehicles, kind of an SUV version of a streetcar.

In the meantime, Castro Theater №2 appeared in its current location, the classic Bank of America building moved in at the corner, boxy cars and streetcars of the beginning of the century evolved into more modern equivalents, and the volume of traffic increased:

And, we invented colour photography:

Sunset Tunnel was built, too, but its entrance portal ended up located much farther to the north, shattering the Eureka Station’s dream to become a transit hub.

As the 1970s approached, the station and the tunnel faced another challenge: how to stay in operation as the East Portal was being replaced by a wholly underground connection to the newly-built Market Street subway. What transpired was the most fascinating ballet of construction work and track realignments with a singular purpose: to allow Market Street surface streetcars to continue into the old tunnel, and everyday commute to stay uninterrupted.

It started with the excavation of the area around the East Portal. In both photos below you can see the streetcars and their passengers continuing on their merry way as if nothing was happening when, in fact, literal tons of things were:

Then, temporary side tunnels were built, connecting the surface of Market Street with the underground. (Compare the two photos below.)

The rather unnerving temporary configuration of a streetcar running above an open trench earned itself a hilarious nickname “Collingwood Elevated,” a rare elevated transit line in the history of San Francisco (Collingwood is a name of a nearby street):

Eventually, the main Market Street streetcar tracks were connected to the side tunnels more directly. (Look carefully at the first photo below, and you will also see the now-gone twin-decked Central Freeway crossing Market Street):

Things went on like this for a few years, with streetcars entering the Twin Peaks tunnel from the sides, cars driving from the old Market Street straight into its extension, and the work on Market Street subway proceeding out of sight.

Finally, in 1980, the seventy-year old dream came to be. The first car — a light rail vehicle — drove all the way underground from the top of Market Street to the very end of the Twin Peaks Tunnel.

But neither that car, nor any car after, would ever stop at Eureka Station.

In the end, for all its once grand ambitions, Eureka Station was an old, tiny box with twin platforms and little else. Upgrading it to new light rail standards (which meant, at the very least, raising all the platforms) and making it more accessible would be harder and more expensive than starting from scratch. And starting from scratch had another benefit: we could do it in a more convenient place.

After thinking about it, it turned out that the simple boarding platform just by the East Portal, always meant to be temporary, was actually in a better location for many people. And so a completely new station, called Castro, was built on that very spot.

Castro Station was bigger, equipped with a mezzanine level taking care of ticketing, and more modern styling including chrome pillars, sans serif fonts, and better lights. Instead of kinked stairs inside small kiosks, it gave people elevators and escalators.

Eureka Station, now obsolete, was put out of circulation in that way that’s only possible in controlled environments: The kiosk entrances were boarded up, and streetcars started skipping it as if it was never there.

The station name survives today, although perhaps only in the minds of people working in public transit or admiring it from afar: the 1970s side entrances to the tunnel were named Eureka Portals and for a while at least have seen occasional use during special transit events.

The story of Eureka Station seems filled with ignominy. The Sunset Tunnel disappointment, the decades of waiting to have a chance to shine as a connector between the Market Street tunnel and the Twin Peaks one, and then the closure that felt like a complete surprise — as late as 1969, Herb Caen wrote about “the newly refurbished station” and the new “rainbow-hued pillars.”

The station was abandoned in 1972, even before the Collingwood Elevated. In the years after, it gained a bit of a notoriety as people started venturing down there to take drugs, party, cover the walls in graffiti.

Seeing that, the transit authority decided to double down, adding more security around the Eureka Portal entrances, and — in 1980 — destroying the four graffitied aboveground kiosks that once saw Market Street becoming what it is today.

Other ghost stations sometimes live on to get second lives: as transit museums, movie shooting locations, repurposed spaces.

Eureka Valley ended up serving a role in the end, although not a particularly exciting one: it became an entrance to the tunnel for people working in it — and as emergency exits for everybody, just in case.

Today, the whole area feels like a time machine in a shuffle mode. Market Street continues through the intersection as if it’s always done so, even though this is far from its first configuration.

The two Eureka Portals look as if they were the original streetcar entrances, now abandoned with abandon — but they’re barely half the tunnel’s age.

The Castro Station, a many-million investment, is in the exact place of the original surface stop that was meant to be there for but a few years… and itself feels old, in that weird way brutalist creations can often appear more out of time than buildings from a hundred years ago.

The two Eureka Station kiosks became two barely visible metal grates in the sidewalk. (The other pair was removed, as it ended up right above the new tracks.)

But you can still see Eureka Station — the oldest in the subway and the only one given up on — if you board a K or L or M train in Castro heading westward toward Forest Hill. Its platforms will be removed, it will whiz by quickly, and people around you won’t even notice. But it will be there.

And sometimes, when I do that, I imagine that station watching you wistfully — like it does in a photo I found in the Public Library, and which appears online for the first time:

Part II. 19th Street Dolores Park stop, 1917–1981+

By a peculiar combination of topography, San Francisco is virtually shut in on all four sides, with the exception of a narrow pass down the Mission Valley around the base of the San Bruno Range. But the possession of perhaps the finest harbor in the world is more than compensation, and the City should consider itself fortunate in not having more impassable barriers.

These were the words of Bion J. Arnold, a renowned transit specialist, who — after successes advising New York railroads and subways — was hired by the city of San Francisco to help devise a public transit strategy.

Within the city limits numerous ridges and hills interpose obstacles which not only render transportation expensive, but which inevitably result in the comparative isolation of various districts (…) whose interests have become so diverse (although, in reality, identical) as to constitute an almost insuperable barrier to wholesome municipal progress.

At that time in particular — the year 1913 — one area in dire need of public transit was “heavily-settled Noe Valley district, now requiring additional service perhaps more than any other district in the city.”

The remedy for this is quick and convenient intercommunication…

The plan for the new J streetcar line connecting Noe Valley to downtown couldn’t have been more simple. Start on Market Street, go almost all the way to its end, and then take one solitary turn to continue straight down the tree-lined Church Street — a gorgeous street passing by a beautiful sloped expanse of grass known as Mission Dolores Park, or Dolores Park (today), or Mission Park (once):

There was just one problem.

…which can hardly be achieved until these barriers are removed by means of tunnels through the intervening hills.

Church Street was steep as hell.

It was a weird time for public transit. Cable cars could traverse hills, but they were already obsolete: cramped, slow, dangerous, expensive. Buses that conquer those hills today with relative ease were not quite ready yet. And streetcars, the preferred mode of public transportation, came with heavy bodies and slippery wheels that couldn’t handle the 14.4% climb of the Church Street block that gave Dolores Park such beautiful views — let alone the 19.3% ascent two blocks later, followed by an immediate roller-coaster-like drop.

And so, Bion J. Arnold went full Robert Moses. He proposed cutting a trench inside a park to create a new street, then continue that street through a bunch of existing buildings, and then — when the going got really rough — put that street inside a popular solution du jour: a tunnel.

But the Board of Supervisors was not impressed. This felt like an expensive, drastic incision, with half of its immense cost swallowed by land acquisition from property owners. The Twin Peaks and Sunset tunnels, cutting through some of San Francisco’s biggest hills, seemed unavoidable. This one felt like overkill.

The city solicited other ideas, and a dozen ideas came. One suggested building a viaduct connecting nearby streets. Another one cutting off the top of the hill — somehow — to reduce the incline. Someone came up with an awkward cable assist proposal, or a battery of few small bridges. All of these solutions were eventually discarded, but they all needed to be looked at, and that took a long time: out of all the planned new lines, J was the only one that failed to be ready in time for the Panama–Pacific International Exposition of 1915. The press reported with exasperation that “another scheme for disputed railway bobs up to cause still further delay.” The official, usually dispassionate reports mentioned “considerable useless and costly conflict.”

The eventual solution to the J problem was surprising and ingenious. It was revisiting Arnold’s original idea, but multiplying it by a simple realization: a streetcar can still be a streetcar even without a street.

A narrower cut through Dolores Park for two streetcar tracks alone — no pedestrians, no cars — would be cheaper and wouldn’t compromise the park nearly as much. And for the next two blocks, having its own tracks meant the streetcar could snake through the buildings in a more complex way that would allow to smooth the grade, reduce the need for too much of eminent domain, and avoid the expensive tunnel. One solitary turn was now what seemed like a dozen, but the wavy route would not be any less safe given a streetcar is glued to the tracks and doesn’t share them with anyone else — and the whole project would be much cheaper.

After years of frustrations, everything worked out beautifully.

The map on the left shows four blocks where the route otherwise shooting straight down Church Street moves inland: the two blocks between 18th and 20th Street through the edge of Mission Park in its own cut, and the next two blocks with the streetcar snaking through people’s backyards.

(You can also see the beginning of Twin Peaks tunnel and the Eureka Station in the upper left corner, and the Sunset Tunnel — then called Duboce Tunnel — some blocks above it.)

The work to lay tracks started in 1916:

The two construction snapshots below give a hint how beautiful the ride would eventually be. They also show a small footbridge that replaced the street running through the park.

And below that bridge, a few platforms and staircases were added to create a picturesque stop, right next to where 19th Street met Church.

At the opening, on August 11, 1917, three years later than anticipated — please insert your favourite joke about J line never being on time — mayor Rolph boasted about the new streetcar going through “the new Mission, the most prosperous section of San Francisco.” (He also mentioned the Twin Peaks tunnel less than a year away from completion.)

He then jumped into a J streetcar to take it for its first spin. Among the route, the 19th Street Dolores Park Stop was the perfect place for thousands of people to come and check out the inauguration — with the only exception apparently being a guy walking away unimpressed.

(It turns out, there’s always a guy.)

But disinterest seemed rare. Finally, a brutally hilly area was conveniently connected to downtown. Many years later, in 1981, a reader of San Francisco Examiner/Chronicle reminisced the first actual ride:

I lived in a flat at the corner of 30th and Church Street, and I sat in the window with my infant son on my lap — he is now sixty-four years old — and waited for the approach of the first J-car. Eventually it came, crowded with City Hall Executives, a small band, and Mayor Jimmie Rolph at the controls.

If it was a nice stop during its opening, unique and old-fashioned, the 19th Street stop only grew more beautiful as the trees made themselves welcome around it.

Here are some early photos from the bottom of the hill, with the footbridge visible in the distance:

19th Street stop might have been as simple as Eureka, but it was infinitely more attractive — and if today we can find barely two photos of the underground station, many photographers tried to capture this one’s interplay of metal, stone, nature, and buildings in the distance:

A few photos captured kids playing around and even “nipping the fender,” as the daring/dangerous practice of hitching a ride on the back of the streetcar was once known.

“A streetcar track runs along one side of the park, under a bridge, giving the park the feel of a quaint model-train layout,” mentioned one article, and many photographers found that hard to disagree with — particularly as the park was often desolate, far away from the extreme popularity it sees in present days:

The 19th Street Dolores Park Stop was so beautiful it even made it onto the cover of a brochure in 1976, with two PCC streetcars portrayed almost as if enjoying a secret rendez-vous:

But just like Eureka Station’s new coat of paint was the beginning of the end, so this photo was the last moment of glory for the 19th Street Dolores Park stop.

As far as I can tell, the stop was removed from service in 1981 under circumstances mirroring Eureka — the J, late as usual, was the last letter line to finally upgrade to light rail vehicles. But the exact reasons are unclear to me. Perhaps it was trying to make the line faster by removing stops (after all, the J line has two nearby stops in the corners of the park). Perhaps to avoid maintenance costs of an underused stop. Perhaps the platforms were too short or otherwise inadequate for the new service.

Either way, some time in the 1980s, the scenic “backyard streetcar” — now a backyard light rail vehicle — started going from 18th Street straight to the Golden Fire Hydrant. The 19th Street Dolores Park stop was no more.

But there was one more reason that likely contributed to the closure — and it’s the same reason few people mourned Eureka Station in 1972. It was safety.

Yes, both stations saw their fair share of transit accidents.

In the 1930s, at Eureka Station, an K streetcar crashed into the L streetcar in front of it because of what seems like an unbelievable reason: the driver of the L started backing up to retrieve a 50¢ coin lost by a passenger.

In 1996, a towed streetcar detached atop Dolores Park and ran away downhill, crashing into parked cars. Just a few months later, a J light rail vehicle jumped the tracks, immediately causing millions of dollars in damage.

But transit accidents happen all over the city. What joined both stations was concerns about personal safety.

Remember that brightly lit photo of Eureka Station with a lone streetcar above? The blurry doors betray that it was an unusually long exposure. In reality, the station was dim, and the dogleg staircases created perfect spots for thieves to hide — or even throw people down the stairs. “It was a haven for muggers and rapists, a place as dangerous as any in the city,” mentioned a 1980 article, quoting one of the people living nearby as saying “It was worth your life to go in there alone.”

19th Street Dolores Park stop also felt unsafe — its sunken location and stair access made it in many ways similar to a small underground station. In one particularly tragic event in 1961, a 27-year-old teacher, William Hall, was assaulted by three teenagers who beat him into semi-unconsciousness and left on the track in the way of an incoming streetcar. The streetcar failed to stop in time, and Hall died before he could be removed from under the vehicle. (The assailants, motivated by homophobia, were eventually found guilty and convicted of first-degree murder.)

And while Eureka Station could be thoroughly removed from public presence, the aboveground 19th Street Dolores Park stop still exists. Even just a year ago, the San Francisco Chronicle reported that “numerous residents” called the bridge “a magnet for criminal activity and homeless encampments.” Here and there, suggestions arise to remove the bridge and the disused stop altogether.

I took to aerial photos to look at the J line as it was then, and as it is today. Compared to the former terminus of Market Street, here it seemed not much has changed, and how! In a beautiful bit of historical symmetry, even the two light rail vehicles in the 2018 photos appeared in the exact same spots as their predecessors in 1938 — by the entrance and the exit of the four blocks where the streetcar said good-bye to the street — as if passing a baton through eight decades.

But I had another option that Eureka Station didn’t give me — I could go and see the 19th Street stop myself.

I did it just a few days ago. Like any lazy person, I started from the top of the hill, on 22nd Street, peeking into all the secret streetcar spaces I wasn’t allowed to see, admiring nary a straight line in sight:

I saw a great visual confirmation of how important it was to flatten the streetcar route, rather than sending it straight up the hill:

Two blocks down, I entered Dolores Park, beautiful even on a gloomy winter day, the view making it immediately obvious why people fell in love with it then, and still enjoyed it today. Indeed, even the boxy modern light railway vehicles still felt a bit like model trains.

But the abandoned 19th Street stop itself, the very place that once saw thousands cheering the mayor behind the (figurative) wheel, wasn’t particularly picturesque or welcoming.

Instead, it was rather honest in showing me some of what I understand are Dolores Park’s — and maybe even the city’s — biggest problems.

I didn’t plan to stay very long either way. There was one more stop for me, right where we started: a house on 17th Street, somewhere in between the ghosts of Eureka Station and the Dolores Park stop. Remember the four-story residential building from the beginning of this story, sacrificed to the extension of Market Street even before it turned ten? I learned later that it wasn’t demolished, but moved, a century ago — and I simply wanted to see how it was doing, perhaps starting an altogether new adventure.

But I couldn’t help myself. I turned around for the last time, and tried to imagine the 19th Dolores Park Stop’s in its idealized best moment of existence, one summer day long ago, shrubbery covering its arch, a gorgeous PCC streetcar climbing the magnificent hill that once confounded so many.

I’m glad I did this all in this order. That I spent time in libraries and online figuring out as much as I could about Eureka Station and 19th Street Dolores Park stop, before visiting them properly for the first time.

It’s possible — of course — to check out a ghost station, an abandoned building, a half-realized urban plan, and enjoy them without much introduction. Decay can be attractive. Nostalgia, even for times you haven’t yourself witnessed, potent. There is certain universal awe in how infrastructure gets a free pass: its end of life doesn’t automatically mean death.

But those two ghost stations were no longer just the above. I saw them as stories of how San Francisco felt exactly a hundred years ago, of city planners trying to wrangle the city’s complex topography, of grandiose plans gone awry and adjusted, and adjusted, and adjusted again. The fact that both stations were simple and unglamorous made this all feel even more special. It was so easy to ride past them and never even notice. But I knew now they existed, I knew where to look for them, and I knew a way to see them as neither “they don’t make them like they used to,” nor “a place as dangerous as any in the city,” but both — and so much more — at the same time.

And now, I hope, you do too.

If you liked this, I also wrote about The Phelan Building, Muni Kirkland bus yard, Paramount Theatre in Oakland, The Embarcadero Center, The Old Mint, The High Line, bridges in Chicago and New York, The Golden Gate Bridge, and a road trip following Robert Moses’s footsteps.

More info on Eureka Station: SF Chronicle, Curbed, SFMTA, SFMTA, OutsideLands, OutsideLands, YouTube/SFMTA, YouTube/KRON.

Main sources of research: San Francisco History Center in person (photos, books, ephemera), Eric Fischer’s archive online, SF Chronicle/Examiner archive online (SFPL library card needed), David Rumsey Historical Map collection online, Open SF History online, SFMTA Photo Archive online, Prelinger Library in person, Mr. Therkelson’s collection in person.

Massive thank you to Eric Fischer for reviewing this article, and forwarding multiple sources. Thank you to Devin Smith, Matt Braithwaite, and Western Neighborhoods Project (who forwarded me a photo that started this entire project). Additional appreciation to Peter Ehrlich, Christopher Cirrincione, and SFMTA Photo Archive for allowing me to use their photos.

Follow along and up

I crave follow-ups. When I was little, I loved opening the encyclopedia to learn more about something I just heard — particularly when it felt the volumes were roughly as big as I was. Later on, I cherished coming back from the movie just to read Roger Ebert’s review, or ⌘+clicking every link in the young Wikipedia.

Today, I still like looking up a newly-discovered word in a dictionary, an obscure product on Internet Archive, or a historical event on Google. In the middle of a conversation, you might find me scribbling something down to look up myself — or to send you later. When I worked on Medium underlines, part of my excitement of it was just working on better linking.

And I’ve always dreamed of creating a “link” that would work when I delivered talks.

Yes, as an audience member, you can easily write down something I’m saying to look it up later. But the act of jotting might be distracting and — more importantly — the best links to find are not always the first results Google spits out.

But I, the speaker, know all the links! If I do my job right and prepare for the talk, I am aware of exactly the obscure pages and documents you should check out if you want to dig deeper… and yet, there is no obvious way for me to give them to you.

The idea

My idea was to create a small talk companion: a web app you could open on any device you have, at any moment during the talk. During my talk, the app would slowly reveal new topics I brought up, and allow you to say “I’m interested in this! I would love to know even more” by simply tapping on a topic — in effect bookmarking it for the very near future.

The only remaining thing would be to provide your email address. And then, some time after the talk ended, you would get a perfectly curated follow-up email with more high-quality links about the things you expressed interest in — and only them.

Preparations

I built and tested a rudimentary version of this idea recently for my Beyond Tellerrand talk about fun and keyboards.

I started by looking at my slides and grouping them into topics. I ended up with 20 of them: the evolution of typewriters, ATASCII movies, overtyping, semigraphics, and so on. Here are the first five, matched with the slides:

I then created a little follow-up block of text for each section. Each topic contained anything from one to five links: sometimes they would point to obvious things like Wikipedia, sometimes to rare Internet Archive books, sometimes to Medium posts I made just for this occasion. Either way, each one would be the best possible companion to a given topic, for example:

How do mechanical typewriters work?

A nice Olivetti manual explaining different parts of a typewriter: http://machinesoflovinggrace.com/manuals/OlivettiLettera22Manual.pdf

For comparison, here’s a much older one: https://archive.org/details/TheBookOfTheNewCentury

A fantastic book about the insides of a typewriter: https://archive.org/details/MechanicalDevicesOfTheTypewriter

Then I added a way for my slide deck to communicate its progress with a custom simple Node server (I hosted it on DreamHost, although I bet there are many other options).

Before my talk, on every seat, we put out URLs and QR codes for the second component: the companion app. Before or during (or even after) the talk, anyone in the audience could open the app to “follow along.”

The app would talk to the server as well (via Websockets), and receive any new topics I just revealed. It would also allow people to tap on the topics they were interested in, and save that information back so that eventually a proper email could be sent.

The design goal was for the companion app to provide a distraction-free experience (after all, fiddling with the UI as I was speaking would go against the whole idea). That meant two things: UI simplicity, and high robustness.

In the visible UI department, the app needed just one tap on a topic to express interest. You could also enter your email address at any point, before, during, or after the talk. Everything you did was saved automatically and silently… and that was it.

Once I started talking about a new topic, it would appear at the top, like in a chat. This made saying “I want to know more about what he’s talking about right now” — likely the most common use case — to be always in a consistent place under your finger. And, if the new topic arrived as you were looking at the page, it would slide in and animate slowly, making it harder to tap on something wrong by accident.

A lot more stuff happened behind the scenes. I was worried about wi-fi failing, and I anticipated people jumping in and out as the talk went along. And so, saving was silent and automatic… but if the connection was spotty, you’d get an error message warning you — and you didn’t have to do anything, as the app would continue trying to reconnect in the background (with exponential backoff). A bunch of code was also dedicated to saving the data in local storage so that reloading the page would never lose any data.

At any given moment you could also input your email… and the app would warn you if you started selecting topics without providing the email address.

You can play with the simulation of the companion. It is not synced to the server in any way. Rather, it pretend the talk starts 5 seconds after you load the page, and each topic takes 4 seconds.

And, here is an example of the email you’d have gotten if you selected all the topics.

The outcome

Did it all work? I think so.

About 100 people (out of the ~450 in the audience) provided their email address, and eventually got a follow-up email. (This was an MVP, so I sent the emails myself one by one, after writing the script that helped me put them together them).

I didn’t track the open rate on the emails, and didn’t embellish the URLs so that I could see how many of them were eventually opened. Those would be improvements for a future edition — although, to be honest, I hate the interim URLs in newsletters as they obfuscate the destination.

The most the experiment failed so far was in the UI department: I made saving too smooth and people were confused whether their choices were actually being sent to the server. (One way to solve it would be either to provide an explicit Saving/Saved UI, or arrange the UI to look more like a form with an explicit Submit button.)

I plan to continue working on this and report back. If you’ve done or will do something similar, please let me know. I won’t mind sharing my code, either, if you’re interested.

(I have previously worked on a different type of a talk companion — one that would allow you to see the slides in real time and save or tweet them. This feels better, rewarding longer-term interest over short-term reactions.)

And either way, once you have a talk companion built, you can also allow the audience to send you something… but that’s a whole different story.

This was part of The rectangle behind you, a series of articles about interactive presentations.

By Marcin Wichary (@mwichary)

Choose your own (secret) adventure

As a grandson of someone who worked on the railways I might be predisposed to extreme punctuality, but as a speaker it’d my job to be timely either way. Going over your time limit in a talk is unprofessional and disrespectful towards the organizers and — more importantly — the audience.

Practice makes better. However, recently, for my Beyond Tellerrand talk about creative uses of keyboards, that would not be enough. I wanted to try out a brand-new experimental exercise with audience participation… but I had no idea how long it was going to take. It was not something I had experience with, or something I could easily test beforehand.

What’s even worse, the exercise was highly dependent on good wi-fi and my code being bug-free, and those two are always in question. It was possible that I would skip the entire interactive portion altogether… but then I had to do something else during the suddenly empty time.

This situation was too complex for the simple “I’m running out of time” mode I tried out earlier, which allowed to quietly skip or show certain slides. I decided to design my talk as a “choose your own adventure” scenario — a bunch of possible pathways, from which I would choose just one… and the audience would never know others were even an option.

There were a bunch of pathways, ranging from “the audience part went so well we’re going to do it again” to “the audience part fails miserably and we jump into a special-made section that talks about failures” to “I already know it’s not going to work, so I will just never attempt this.” Here’s the entire chart, with black squares denoting decision points:

How was I supposed to choose my pathway as I was speaking? I went for the same cheap UI I’ve already tried before: the keyboard attached to the presenter’s laptop.

At the boundaries of each section, I blocked the arrow keys from being able to navigate forwards or backwards, so that jumping to each section was always a deliberate decision. And then I gave each section a secret keyboard shortcut — Shift+Ctrl+1, Shift+Ctrl+2, and so on — wrote myself a cheat sheet, and taped it onto my computer.

This worked well, and — if you watch the video — you will notice that there’s never any hint of me choosing a section, or quickly advancing through slides in a way that’s never too pleasant for the audience.

Alas, of all the scenarios I planned, I had to execute the “I already know it’s not going to work, so I will just never attempt this.” The interactive portion had a bug I only learned of minutes before the talk… so I could not fix it in time.

But the strategy proved itself: The only person knowing anything failed was me.

This was part of The rectangle behind you, a series of articles about interactive presentations.

By Marcin Wichary (@mwichary)

Today we introduced a new way to master keyboard shortcuts: a redesigned panel that shows up at the bottom of your Figma screen. It will respond to your behavior by highlighting patterns in your keyboard use and help you discover new key combinations in a fun way. We’ve taken our inspiration from computing pioneer Douglas Engelbart, and wanted to briefly share how his work shaped our approach. (Read to the end for the deep dive into our new keyboard panel.)

One Monday afternoon fifty years ago, on a stage by San Francisco’s Civic Center, computer pioneer Douglas Engelbart gave a demonstration that forever altered the course of computing.

At the time, computers were known to serve corporate and government needs: calculations, simulations, payroll. But Engelbart focused on something different: computers that were personal and could help with daily tasks. Collaborating with a few team members thirty miles away, he showed the audience how to write documents together, add graphics to make them better, create links between them and chat while doing it.

The session received a standing ovation and helped inspire other tech industry leaders. Some of the most significant strides in people-oriented computing that came afterward — like Apple’s first Macintosh — can be traced directly back to this demo.

But for me, just as important as the events shown on Engelbart’s screen was what was happening with his hands. On a custom-made tray, a traditional QWERTY keyboard was surrounded by two never-before-seen accessories: on the right, a thick box named a “mouse,” and on the left, an unusual one-handed device called a “keyset.”

The mouse initially stole all the glory, as it felt simple and friendly. But the keyset — a cross between a keyboard and a piano — was just as fascinating. With the mouse, Engelbart could point to things; with the keyset, he could describe what to do with them. At one point, he started aiming at a word with the mouse and then — still on the way there — used his other hand to quietly key in two letters: DW (“delete word”). The word disappeared.

The alliance between two hands and two devices made Engelbart’s presentation feel like nothing less than magic, the closest to a mind-meld with a machine we’d ever witnessed — or, in words of one of the attendees, like Engelbart was “dealing lightning with both hands.”

Part of the wonder could be traced to the properties of our motor memory, which allow us to master physical actions to the point they become instinctive and subconscious. If you know a pianist or a dancer, ask them to describe their performance. They will struggle; they internalized their movements so much that they no longer even register as actions. The motor memory allows them to simply play or dance.

Engelbart applied those same properties of motor memory to computer tasks. By mastering the mouse and the chords on his keyset, he was able to operate the computer with astonishing fluidity — and his prowess with both devices was a significant part of the demo’s impact.

What Engelbart’s demo has to do with Figma

I can’t count how many times I’ve watched the Engelbart demo in awe. As a designer, I’ve long been fascinated by the universe of input devices — enough that I’ve decided to write a book about the history of keyboards. So when I joined forces with Figma to help with a few projects, I started thinking about not just the screen, but also the hands underneath it.

Much like Engelbart’s demo, witnessing someone really good at using Figma will feel like a miracle. They’ll traverse the canvas, restyle objects, and create new designs at a miraculous pace, without ever glancing down at their hands. Just like watching an experienced pianist or dancer, it will almost feel like a performance.

And all this happens using a setup similar to Engelbart’s: one hand on the mouse, another on the keyboard. It’s still the best combination to free your mind to engage in the state of flow. Let your hands do their job, and instead of thinking of the tool you’re using, think about the problems you want to solve.

But just as in 1968, one of those devices is much harder to master than the other. The mouse and its successors are easy to grab and use, even by a beginner. However, the long-gone keyset or modern keyboard shortcuts are a different story. They require practice and dedication to first explore and then commit into motor memory.

So today, we’re adding a small improvement to Figma that might help: a better keyboard shortcut panel. Before now, that part of Figma hadn’t received much love. It was hard to scan and would take over the entire screen — making it hard to learn by actually trying.

The new keyboard panel will appear underneath your canvas instead. You can summon it the same way — by clicking the question mark in the bottom right hand corner of your screen and then choosing Keyboard Shortcuts (or pressing Ctrl+Shift+?).

When you open the new panel, you can click through categories to learn new shortcuts specific to the type of work you’re doing. If you’re dealing with vectors, go straight to the shape tab to see a few power shortcuts like bending. If you — like me — usually work with fonts, head to the type section instead.

We also added a tab for some of the most rewarding combinations — those, just like the famous Engelbart demo, that come from a two-handed effort. For example, did you know holding Alt while moving the mouse around allows you to measure objects in Figma with ease?

And if you feel overwhelmed by all this, there’s one simple tab on the left hand side. It will introduce you to starter key combinations you will never want to live without, like how ⌘+\ takes away all of the “chrome” so you can focus on your work.

Our hope is that this new setup will make it easier to learn shortcuts and help you discover related shortcuts you never knew existed. By working on this project, I personally discovered and learned how useful Shift+2 in the Zoom panel can be — it always does just the right thing to make the selection visible.

We also added one more thing: the panel will actually listen to your fingers, highlight the shortcuts you just pressed, and remember them for the future. We hope this detail will make it easier and more fun to reflect on your use of keyboard with Figma, and notice the shortcuts you never had a chance to try.

And yes, I know it feels a little silly contrasting a small improvement like this with a seminal moment in computing history known as “The Mother Of All Demos.” But even small steps are worth celebrating, particularly if they can give your motor memory a chance to shine. :·)

P.S. On a related note — I’ll be co-hosting an Engelbart-themed bash at Figma on December 9th, to celebrate the 50th anniversary of his famous presentation! RSVP here.

Thank you to Ryan Kaplan and Peter Herbert Barnaba for their help on this project.

Figma’s new finger tips was originally published in Figma Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

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(https://medium.com/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(https://medium.com/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(https://medium.com/icon-back.svg);

After

mask-size: contain;
mask-repeat: no-repeat;
mask-position: center;
mask-size: 1rem;
mask-image: url(https://medium.com/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.

I recently wrote a 427-tweet thread that a great many people contributed to, with many wonderful replies:

Marcin Wichary on Twitter

Things that surprised/amazed me about Japan, an ongoing thread. (More likely UI than food, but you know this already.) It's my first time here. Please comment away and/or point out my cultural insensitivities!

It was a great deal of fun for me, and I am not sure this could’ve happened anywhere else but on Twitter. However, creating and maintaining the thread was painful, and — much more than ever before — reading and participating in it seemed also to be painful to others.

This is a list of my observations and suggestions on how to make it better. I don’t know how common this use case is, and how exactly it relates to other Twitter/threading use cases; I wanted to share this in case there’s something useful in here.

I bolded my suggestions so it’s easier to scan this quickly.

Setup: I used my iPhone 6S to take photos, and posted most of the tweets using the official Twitter iOS app on the same phone.

1. Threads are slow to load

In the iOS app, opening any tweet in a thread shows it immediately, but the context of the thread (surrounding tweets) and the UI to append to the thread are slower and slower to load the longer the thread gets.

This feels like an unintentional punishment for creating longer threads. It’s there for me as a writer, and — more importantly — it’s also there for readers. Currently, looking at the later tweets in the thread (example link to one) on good wi-fi takes over 90 seconds to load the surrounding context and UI. (And looking at it on cellular made me worried about data charges, as it seems consistently slow and therefore probably not cached?)

It seems like this could be optimized to load in constant time (perhaps show the first few items in the thread and then a Load more item, in between, similarly to what’s done in notifications?). Or cached once loaded. It’d also be good — and it feels like good practice — to see the related UI (Add another Tweet button) appear immediately without having to wait for the content. Lastly, some sort of a loading indicator would be nice to add, although perhaps only if the thread is expected to be long.

(The desktop web experience doesn’t seem to have that problem.)

2. There is a nasty scroll up bug

In the iOS app, if you open any tweet further down the thread and scroll up or down even just a bit before the context/UI finish loading (or even attempt to scroll)… the moment they do, you get moved up all the way to the top of the thread, losing whatever orientation you had.

It’s really confusing at worst, and infuriating at best, when you understand what’s going on but — after having waited 90 seconds and accidentally touched the screen and scrolled it— are still powerless to stop it.

Please fix this bug. It’s been there for so long.

3a. It seems easy to lose track of the thread

As you read, the thread gets truncated at some point, with responses to the “selected” tweet (the tweet with big letters) taking over. There is a call to action to keep reading the thread, but it’s tiny and that makes it easy to miss it — and that assumes you know to look for it.

The call to action also says X more replies, not using the word “thread,” even though the UI to enter the thread calls it that (Show this thread).

Even when you find that call to action in the middle of scrolling and tap on it, you’ll have to fish for it next time, too, as the responses to the original tweet keep hanging in there at the bottom of the chute.

(There is also a bug you could see above, where for some reason the number never goes above 171? That might add to the confusion — you tap it once, scroll down, and the number remains the same.)

3b. The conversation UI seems confusing, in general

The above three problems — slowness, scrolling bugs, extending UI — contribute to the confusion, but I think even without them it’d still be hard to participate in a conversation where people respond to various tweets in the thread. Here’s a sample of the problem:

I don’t think people intended to respond with the same answer despite others having done so before them. I believe they responded because they never saw the other answers.

This was the first time I actually wrote a little explainer…

Marcin Wichary on Twitter

Pro tip if you're following this thread: tap or click on tweets that interest you; many have feedback and thoughts from awesome people who understand things better than I do. (Also, thanks for following this thread!)

…and I had so many questions — on Twitter or otherwise — about how to read the replies to a tweet in the thread. It’s confusing (here are some comments), even if it’s explained to you: the replies to the “selected/current” tweet appear nowhere close to the tweet but far below, separated by 30 subsequent tweets in the thread.

I have a few tactical suggestions:

• Make the “tap here to extend the thread” UI more visible, and tie its label more to the notion of a thread (right now it reads as replies from others).
• If you tap on the action to extend the thread, consider making the initially “selected” tweet not selected any more — or at least remove the replies to it from the bottom. This way, reaching the end of the visible part of the thread will also mean reaching the bottom of the scrollable chute, Fitts’s Law and all that.
• When you start navigating within the thread (e.g. tapping on various tweets to make them “selected”), maybe reduce the distance between the currently “selected” tweet and the tweets replying to it from 30 to much lower? Since the intent of the reader is then to engage with the replies first, and the thread later.

I do have a sense that a more profound redesign of this entire UI would be in order, however, to better accommodate threads with replies to them.

4. It’s hard to stay on top of notifications

The very moment your tweet/thread become nanoviral, your notifications get shot. It feels like the service punishing you for doing a good job. Two things in particular are frustrating:

• You can very quickly run out of notifications buffer — you scroll back and at some point the notifications just stop without any warning. If you don’t want to miss out on a reply to you, this forces you to be on top of your notifications, and that’s stressful. I talked about it a bit more before. One idea would to be to extend the notifications buffer. The other, to perhaps allow you to paginate notifications, or allow to choose a specific date and be more intentional about reading notifications than just the rudimentary (and getting slower and slower) infinite scroll.
• Notifications pane has two modes: All and Mentions. I expect the second tab to also include quote tweets, but they’re not there. That forces me to use All not to miss anything — and wade through tons of likes and retweets that are not pertinent. Suggestion: Please add quote tweets to the Mentions view.

5. It’s easy to make a mistake and mess up the thread

If you mess up and continue the thread not from its last tweet, the whole thing breaks — you can follow up to the beginning from a misplaced tweet, but you will no longer be able to read the entire thread when you start from the beginning.

This makes sense, but it feels too easy to arrive at this state. It happened to me twice in the above thread alone, where I later had to delete some tweets and republish them in the correct order. (Leftover proof where someone else helped me figure it out.)

I think a feature to reconnect/reshuffle tweets in a thread would be an overkill. Making the UI appear faster (as per above) would help. Perhaps there’s a chance to introduce some sort of a thread end mark, maybe even visible just to the author? It could be a typographical glyph, or it could be just a change in the UI. Right now in my own stream the last tweet in a thread has the same text as any tweet before: Show this thread. Maybe there’s an opportunity to make the last one special?

6. It’s hard to keep track of which photos were already included

Managing photos is a small private hell: choosing photos to be portrayed, remembering to filter them, remembering which ones were already used. This is mostly on iOS, not on Twitter. As a matter of fact, Twitter has a pretty good photo selection UI.

However, one feature request that would make this so much easier: when I’m selecting photos to be attached to a tweet, please indicate (gray out?) photos I already attached to (other) tweets before.

That’s it! My DMs are open if anything here needs clarification. Screenshot frames thanks to mockuphone.com.