liz writes stuff down

Triggering videos, thoughtful content warnings, and responsible feature release policies

Content warning: police murder of black people

We need to talk about potentially triggering videos and social media.

Social media is nearly unavoidable. There's a lot of upsides to using it, such as keeping up with family and friends you can't see frequently and reaching out to your customer base in more personalized ways, but it's also evolving very, very fast. One day we're posting our latest relationship update; the next we're getting news as soon as it breaks. It empowers marginalized voices to tell their stories - stories that often go untold.

One second we were uploading photographs; the next gifs and videos - videos of our cats, then videos of police shooting black people. Maybe people are posting them to draw attention to issues the mainsteam media doesn't see fit to focus on. Maybe police shootings are being posted as videos because people don't believe black victims didn't pose a threat. I don't personally share these videos, so I can only guess at the motivations.

If we listen to black voices, we hear them pleading to keep videos depicting police shootings of minorities out of their view.

Black lives matter. Properly respecting black lives involves understanding that videos depicting a death of a human can be very triggering and respecting viewers by allowing them the chance to opt out of seeing them.

We need to use thoughtful content/trigger warnings.

Content warnings allow people to engage with content how and when they feel comfortable doing so. They are not censorship.

Placing content warnings for videos is a lot less straightforward than placing content warnings for written pieces without even photographs like this one. A written content warning before a video in a social media post is a good start. They work well for posts that link to articles with videos in them when those videos don't sneak into the previews social media like to embed.

The reader is able to see this tweet without having to see a potentially triggering graphic video.

We need tools that help us place content warnings specifically for video formats.

If someone comes across an article or social media post with a video directly in it, text-based content warnings aren't enough.

Preview frames might include a triggering image. We can replace the default frame selected from a video with one that contains only the text of relevant content warnings. We need tools that make this process easy to do. Preferably, social media would include these tools in their upload interfaces themselves. Their inclusion would provide not just ease of use but also a convenient reminder to use them.

Also, the video may start playing anyway - maybe it autoplayed, maybe the reader accidentally clicked on it. Tools to supply text-only frames containing the relevant content warnings for the first ten seconds of a video would give someone the opportunity to pause or scroll past it before triggering content is forced upon them. This would provide a buffer even when video autoplay is turned on.

We need to release new features responsibly.

When Facebook and Twitter released their video autoplay features, they enabled it by default. Their decisions forced users to unnecessarily engage with content they didn't desire to see.[1] We should not turn on new features like video autoplay by default.

Facebook does allow users to disable autoplay for videos, but that still doesn't make it okay to turn it on by default. Twitter allows you to turn off autoplay for some videos[2], but you're stuck with autoplay while you scroll through a Moment, regardless of your video autoplay settings. It is absolutely irrepsonsible of Twitter to force this feature on you in any situation.

Content warnings, tools, and responsible feature release policies will never be a complete solution, but maybe these tools and feature releases would allow for us to benefit from having triggering videos available without causing as much unnecessary harm.

[1] It's also a huge mobile data hog.
[2] This appears to now be in the "Data" section of settings on iOS, and I am told it is a similar process for Android.


Understanding GNU Screen’s captions

I love screen. I know all the cool kids are using tmux now, but screen keeps it simple and does everything I really need.

One of the things I (possibly mistakenly) want is lots of windows. The problem with having lots of windows is they quickly become hard to keep track of, especially since the default screen configuration doesn't have any guiding information quickly available to the user. Fortunately, you can fix this with a caption that appears at the bottom of your terminal.¹
screen caption
I do this in my ~/screenrc, which boils down to:

### pass commands to screen for describing windows
shelltitle '$ |sh'

### set caption
caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'

There's a lot going on here, and it took an unfortunately long time to work out...

shelltitle '$ |sh' is all about making it easy to know what's in each window, but it's only possible with this extra scripting in my ~/.bashrc:

# dynamic titles for screen
case $TERM in
  screen*) export PROMPT_COMMAND='echo -n -e "33k33\\"'

This passes the last command to screen to use within my caption to identify what's currently happening in each window. This is a lifesaver for someone who makes the questionable life decision of having at least eight windows open in every screen she launches.

That's the simple part; now, let's break down my complicated caption format. Captions aren't documented well. Lots of people post theirs, but usually without explanation - likely because it's a pain to describe. I started off by mashing up other people's captions, but that didn't get me very far. I completely redid mine last week, and I realized pretty quickly that I'd only make it perfect by understanding how to build it up part by part. Inspired by Jay Sitter's article on hardstatus strings, I present a breakdown of my caption:

### set caption
caption always '%{= kw}[ %{y}%H%{-} ][ %= %-Lw%{+b M}%n%f* %t%{-}%+LW %= ][ %{r}%l%{-} ][ %{c}%c%{-} ]'
%{= kw} clear all text attributes and set to text color to white and background to black
[ plain text to mark sections
%{y} set text color to yellow
%H hostname of the system
%{-} go back to previous text settings (text color to white)
][ plain text to mark sections
%= with the later %= in the caption, pad this section on the left so that the caption spans the entire line
%-Lw list windows before current window, the optional 'L' indicates that these windows show their flags
%{+b M} the current window section starts, make text bold, set text color to magenta
%n current window number
%f flags of the current window
* plain text I use to mark the current window
%t current window title
%{-} go back to previous text settings (text color to white, normal weight)
%+LW list windows after current window, the optional 'L' indicates that these windows show their flags
%= with the earlier %= in the caption, pad this section on the left so that the caption spans the entire line
][ plain text to mark sections
%{r} set text color to red
%l current load of the system
%{-} go back to previous text settings (text color to white)
][ plain text to mark sections
%{c} set text color to cyan
%c 24-hour clock
%{-} go back to previous text settings (text color to white)
] plain text to mark sections

Hopefully this explanation inspires you to customize your screen caption to your heart's content!

Oh, by the way, my dotfiles are now available on GitHub.

¹You could also fix this with a hardstatus. I don't like this solution as much because hardstatus is for status messages from screen, e.g. to alert you about activity, while caption is more thematically in line with giving the details of the windows within the screen.


“First” thoughts on git

I suppose it's more than a slight bit incorrect to state that these are my first thoughts on git; I've certainly already been exposed to git in a variety of ways. I'd always been told that my love of graph theory would convert me over to this different type of version control.

I more or less decided to look into git on a set of whims, yet I was really persuaded to go to the "dark side" because I was strongly encouraged (read: required) to understand the back-end model instead of just memorize a handful of commands (like with SVN). I'd attempt to do the merits of the consequences of git's back-end model justice, but instead, I'll point you to a far more experienced git user's blog post.

My first steps to really learning git was to look at a handful of resources:

After an hour or so of reading, my friend Evan and I talked through a bunch of the basic commands briefly and some of the more interesting commands in greater depth. I took notes on easel paper for the basic commands, and we worked through diagrams for cherry-pick, merge, and rebase:

Notes and diagrams from our conversations on git commands

I got fairly excited when I guessed that rebase essentially applies a series of cherry-pick calls to a branch.

I decided to use my first git repository for a documentation project I'm working on for MIT's academic computing environment, which is publicly available on github. That repository hasn't seen as much activity as I'd like yet, but I have also been using git much more frequently for my academic projects.

I really like the control that my understanding of the back-end model provides, and that control in and of itself is a sufficient reason to consider switching to git. I'll also argue that learning the back-end model is a fun enough exercise to want to switch.


gitionary: the graphical game of git guessing

I apparently have a knack for coming up with nerdy party games. Three Fridays ago, my 6.033 TA encouraged us to practice creating diagrams for our design project proposals by trying to identify UNIX commands or filesystem structures from our partner's drawings. He claims that this "6.033 pictionary" was a result of strong nudging of the course's writing staff. Given that I had been encouraged by some of my friends to learn git earlier that day, naturally, I merged the two ideas and decided that gitionary needed to be created. I told Nelson, who is quite fluent in the ways of git, and he generated the game cards so we could actually play with the idea.

The original premise was simple: draw the appropriate directed acyclic graph corresponding to git commands so that your friends could guess it. However, many people who would likely end up playing the game did not yet know git, myself included, so we thought it would be good to allow drawing non-DAGs, too.

Nelson generated a set of gitionary cards, and we test ran the game with a rotating "artist" and the rest of the room guessing. I can't post pictures and comments about all twenty-six commands drawn that night, so I'll just show you a few (semi-arbitrarily selected) highlights. Many of the most successful were not drawn as directed acyclic graphs, such as git-revert:

git-revert, wdaher, 15 seconds

git-stash turned out to be difficult when initially drawn in a way that reflected what the command did, and more surprisingly still took about half a minute after the lower left-hand corner of the sheet was sketched:

git-stash, jesstess, 68 seconds

A somewhat hilarious failure mode of gitionary is that objects which would ordinarily be drawn as a combination of circles and lines inadvertently look like DAGs. This was a problem Jeff had while he was drawing a magnifying glass to represent git-show:

git-show, jbarnold, 34 seconds

You are welcome to examine the full set of drawings from the first run of gitionary. I definitely encourage you to get a group of your favorite nerdy friends together to play the game, and maybe, you will do more than one of the plumbing commands.

Now that I've created a party game about gitionary, I think I should probably go spend some time learning git. Word on the street is that I'll think the back-end model is "cute."