Jamis Buck recently posted about his giving a Rails demo/talk to a
Java group. He mentioned (among other things):
There were a few technical things I would do differently next time:
1) Don't try to be clever and type out method comments in the screen
capture videos. It might be nice for later, when you distribute
the video, but during the presentation it just makes it lag.
2) Keep the action in the videos as close to the top of the screen
as possible, so that people sitting WAY in the back can see it
better.
I've been mailing software movies at my current job as means of
documenting how to install and configure assorted software. I'm
interested in what ways others have found to ensure good results.
I found that manually typing things while recoding is slow and error
prone, so I've taken to having vi open, from which I can cut and paste
text. (But if I'm not careful the app-switching is blatant and ugly).
On the other hand, one's sense of time while recording something
familiar may not be the best gauge for what speed a viewer might
prefer. So the typing part can help certain info sink in.
Does anyone have, or know of, a collection of handy tips and tricks
for such endeavors? (I should probably go see what Jon Udell has on
his site ...)
There's a Wiki page that seems like it might have been created for
recording such things, but it is empty (and possibly poorly-named)
If the entire setup can be done using a shell script, it probably
wouldn't take much to run that script through another script to add
appropriate delays - to make it "appear" as if it's being typed.
Just a thought.
···
On Sat, 19 Feb 2005 05:18:13 +0900, James G. Britt <ruby.talk.list@gmail.com> wrote:
Jamis Buck recently posted about his giving a Rails demo/talk to a
Java group. He mentioned (among other things):
> There were a few technical things I would do differently next time:
>
> 1) Don't try to be clever and type out method comments in the screen
> capture videos. It might be nice for later, when you distribute
> the video, but during the presentation it just makes it lag.
>
> 2) Keep the action in the videos as close to the top of the screen
> as possible, so that people sitting WAY in the back can see it
> better.
I've been mailing software movies at my current job as means of
documenting how to install and configure assorted software. I'm
interested in what ways others have found to ensure good results.
I found that manually typing things while recoding is slow and error
prone, so I've taken to having vi open, from which I can cut and paste
text. (But if I'm not careful the app-switching is blatant and ugly).
On the other hand, one's sense of time while recording something
familiar may not be the best gauge for what speed a viewer might
prefer. So the typing part can help certain info sink in.
Does anyone have, or know of, a collection of handy tips and tricks
for such endeavors? (I should probably go see what Jon Udell has on
his site ...)
There's a Wiki page that seems like it might have been created for
recording such things, but it is empty (and possibly poorly-named)
Haven't done any videos myself but would like to mention script and
scriptreplay. These two utils come with the bsdutils package on my
Debian box.
script records a console session with optional timeing data.
scriptreplay plays back the session
Not sure how the timeing data is used but it doesn't look too hard
to alter for your purposes.
Just a heads up.
Cheers,
Emiel
···
* James G. Britt (ruby.talk.list@gmail.com) wrote:
Jamis Buck recently posted about his giving a Rails demo/talk to a
Java group. He mentioned (among other things):
> There were a few technical things I would do differently next time:
>
> 1) Don't try to be clever and type out method comments in the screen
> capture videos. It might be nice for later, when you distribute
> the video, but during the presentation it just makes it lag.
>
> 2) Keep the action in the videos as close to the top of the screen
> as possible, so that people sitting WAY in the back can see it
> better.
I've been mailing software movies at my current job as means of
documenting how to install and configure assorted software. I'm
interested in what ways others have found to ensure good results.
What software is good on Linux for authoring demo movies? I used to use Camtasia on Windows and have been missing it on Linux
Cheers,
Tim
Bill Guindon wrote:
···
On Sat, 19 Feb 2005 05:18:13 +0900, James G. Britt > <ruby.talk.list@gmail.com> wrote:
Jamis Buck recently posted about his giving a Rails demo/talk to a
Java group. He mentioned (among other things):
There were a few technical things I would do differently next time:
1) Don't try to be clever and type out method comments in the screen
capture videos. It might be nice for later, when you distribute
the video, but during the presentation it just makes it lag.
2) Keep the action in the videos as close to the top of the screen
as possible, so that people sitting WAY in the back can see it
better.
I've been mailing software movies at my current job as means of
documenting how to install and configure assorted software. I'm
interested in what ways others have found to ensure good results.
I found that manually typing things while recoding is slow and error
prone, so I've taken to having vi open, from which I can cut and paste
text. (But if I'm not careful the app-switching is blatant and ugly).
On the other hand, one's sense of time while recording something
familiar may not be the best gauge for what speed a viewer might
prefer. So the typing part can help certain info sink in.
Does anyone have, or know of, a collection of handy tips and tricks
for such endeavors? (I should probably go see what Jon Udell has on
his site ...)
There's a Wiki page that seems like it might have been created for
recording such things, but it is empty (and possibly poorly-named)
If the entire setup can be done using a shell script, it probably
wouldn't take much to run that script through another script to add
appropriate delays - to make it "appear" as if it's being typed.
A very good thought. Even without adding any typing delays (though
that's a nice touch), a good general approach might be to script as
much as possible, then record your script in action.
Much less chance of finger farts that way.
James
···
On Sat, 19 Feb 2005 05:28:06 +0900, Bill Guindon <agorilla@gmail.com> wrote:
...
If the entire setup can be done using a shell script, it probably
wouldn't take much to run that script through another script to add
appropriate delays - to make it "appear" as if it's being typed.
What software is good on Linux for authoring demo movies? I used to use Camtasia on Windows and have been missing it on Linux
xvidcap/gvidcap is *very* good. I used it for my Wee tutorial videos. I used 3 frames/second with mpeg1 compression, as mpeg4 turned out to be too slow.
Yes, fine, but why a *shell* scripts, for Heaven's sake? We do know some
language named ruby, don't we?
I think the best way of doing it would be writing directly to the
pseudoterminal device used by the editor. Than you have a programmable
control of what you are doing, without having to do anything manually.
What it doesn't solve is the interaction with gui. But that's neither a
problem, as there are a hatful window managers with some kind of
scripting or "remote control" support (ie., you write simple action
names [possibly with parameters] to a named pipe or socket, and the wm
executes those). Maybe there are some which are macroable as well, that
is, you do some interaction with the wm and it records your actions to a
script with which you can replay what you've been doing.
Csaba
···
On 2005-02-18, James G. Britt <ruby.talk.list@gmail.com> wrote:
On Sat, 19 Feb 2005 05:28:06 +0900, Bill Guindon <agorilla@gmail.com> wrote:
...
If the entire setup can be done using a shell script, it probably
wouldn't take much to run that script through another script to add
appropriate delays - to make it "appear" as if it's being typed.
Just a thought.
A very good thought. Even without adding any typing delays (though
that's a nice touch), a good general approach might be to script as
much as possible, then record your script in action.