asciinema screencasts

[ThomasWaldmann]

we have new asciinema screencasts in #2835, but I am not totally happy with them.

there is just too much whooshing, blinking and attribute usage going on.
stuff comes onto screen at very different paces. a bit slow (typed live), then whoosh a lot of fast input (not typed live, but just recalled).
this is something that will affect / irritate quite some viewers of these.

also, due to the same root causes, there is lots of stuff in the json that makes it hard to edit (e.g. to fix small typos or other minor stuff), like ansi colour/attribute sequences, temporary stuff (that was neither typed nor output by borg), ...

so I propose these rules for the next iteration of asciinema screencasts:

• in general:

  • no fancy shell tricks
  • no fancy shell styling
  • no shell extensions (or powerful shells that have lots of stuff built-in)
  • just plain sh / bash

• no stuff pre-entered in the shell history that just gets recalled by some key combination

• everything except trivial and short shell completion (e.g. of a path) must be typed "live", char by char

• no or only minimal colour / attribute usage in output, acceptable would be:

  • one full-line color for comment lines
  • a coloured prompt for input lines or one full-line colour for input
  • one full-line colour for all output
  • all colours must have good contrast to background (e.g. no dark grey on black)
  • no intra-line syntax highlighting

• no underlined stuff (e.g. no automatically underlined directory names)

• no cursor up to recall anything except the last 1 or 2 commands

• no edits of recalled stuff except very few characters

• no typing in of something and then erasing all of it again with backspace

• nothing showing up temporarily below the line where input happens while input happens (e.g. no shell input completion offering some options)

• enter your sudo password before you start the recording, so it won't ask while recording

[enkore]

FTR I'd prefer long texts popping up at once / quickly over typing them in, because I read way faster than anyone could type so I'm naturally annoyed by having to wait. Skipping in these demos isn't really ergonomic, either.

Of course for a good video the pacing still needs to be right, you can't flood the entire screen with text and expect folks to read it in a second.

I also really like the minimal prompt (just $, no user/hostname/workdir); uses less columns as well. This should definitely be kept in the future.

Simple coloring is imho ok. Having comments in bold gray or whatever distinguishes them nicely from commands or borg output.

[ThomasWaldmann]

@enkore there's a speed param on asciinema for that. Having the text kind of fast-typed makes sure there is enough total time to read that AND also the program output. Looks also more natural.

[rugk]

FTR I'd prefer long texts popping up at once / quickly over typing them in, because I read way faster than anyone could type so I'm naturally annoyed by having to wait.

Indeed that's why I choose to do it in this way.
But the speed parameter is indeed a better way…

Having comments in bold gray or whatever distinguishes them nicely from commands or borg output.

Are you kidding? I specially removed that because you asked to do so. And it literally was bold grey!

no cursor up to recall anything except the last 1 or 2 commands

When you only change the name of the backup, I would find it cumbersome to see the whole command line to be typed again in manually. As a viewer, I then would try to look whether there are differences to the previous one and be kinda disappointing when there are not.
So this just makes clear: I am running the same command again. (just with 1 change)
Thus, I think this should be allowed.

no typing in of something and then erasing all of it again with backspace

That does not happen in the screencasts. It only erases parts of the command (borg export key). The reason is to show some options, and I like it in that way.
Of course, it makes no sense to remove the whole command without executing it.

---

Generally, what is needed is just some autotype program for linux. Where you can enter your text and it then types it automatically. Possibly leaving pauses for things, you want to type in manually.
Okay, possibly a custom version could be made with a shell or Python script…

[enkore]

Are you kidding?

I wouldn't swear it, but it seems more likely to me that Thomas argued against this, not me.

But the speed parameter is indeed a better way…

Is it? Unless I overlooked something it's not easily changed by the viewer. For longer texts it still seems superior to me to just paste it in and pause for a moment.

Thus, I think this should be allowed.

+1 (but pacing / context)

[rugk]

I wouldn't swear it, but it seems more likely to me that Thomas argued against this, not me.

Okay, it does not matter. Just saying… The (correct) argument was grey is not really readable on a black background. So if you do this next time, use a light gray or a different asciinema theme…

Is it? Unless I overlooked something it's not easily changed by the viewer.

You can pass it in the URL as you do with the pre-1.1 screencasts.

[ThomasWaldmann]

Dark grey on black was bad, too little contrast.
A lighter grey on black (bold or not) has better contrast and is thus fine.
There are a lot of shades of grey. :P

[rugk]

A lighter grey on black (bold or not) has better contrast and is thus fine.

The issue is, when you then change the theme on asciinema (as it is possible) using a white background, you cannot read it either.

[enkore]

Well I mean, when you change the terminal colours many apps become unusable. Not really surprising that the same issue applies to aciinema ;)

[rugk]

I mean that: https://asciinema.org/a/aQGBdQzxpD4LiFNOITfleCqIv