There are many screencasting applications out there at the moment.
gtkRecordMyDesktop, Istanbul (and for the hard core!) xVidCap. The trouble is, they were created WAY before screencasting became so popular, and so try to meet the demands of an audience which has changed dramatically.
They built on old principles which simply don’t apply anymore, and discontent with the options I saw, I decided to design (and hopefully make) my own.
I started with the main window from which you start the recording. I looked at the existing Linux screencasting tools and others (such as the excellent Screenflick for Mac OSx) and noticed a HUGE difference. Looking at Screenkey, the user is only presented with very few options to begin with, so they can just get started, whereas with the Linux ones, the user is drowned with options and configuration – all they want to do is get started!
I started to mockup my own main window (you can see the process below). The first iteration had less options than the Linux ones, however I still felt as if it was too difficult for the user to just START! Then came the idea which my design is now based on.
I decided that the initial recording of my screencasts should not be encoded into OGV, MP4 etc. Computers have so much storage today, that I decided it is better to forget quality etc. in the beginning, and let the user deal with it later. this was one of my biggest problems with the Linux ones. If you set the quality too low etc. you would have to record to whole screencast again – not acceptable in my mind.
So the options I included on my main window were the video and audio sources (optional) and I also did a third iteration where a screenkey-like option is offered to the user.
After this window, an application indicator (or status icon for our GNOME friends!) will appear in the panel, and start counting down from five. A translucent black window will also appear at the sametime, counting down from 5 at the same time. This allows the user to prepare for the screencast, but also having the indicator appear and countdown with the black window, shows that they are connected, with no need to explicitly tell the user through some documentation. While recording, everything is as normal, with the indicator acting as the means to pause and finally finish recording. The mockups of the indicator and the black window are shown below.
Once the user elects to finish the recording, a small window popups, telling them that the recording has finished, and asking them what they want to do. They can either edit the screencast with Kazam (the name of our application) or with any other video editing application (such as PITIVI). Another option is to save the video file in its current uncompressed form. This is if they want to edit it later, or if for some reason their video editor is not in the list. The purpose of this window is to smoothly link the recording of the screencast with the editing and final output.
However I realise that for many screencasts, a powerful video editing software package such as PITIVI can be a bit overkill and not suitable to quickly get a screencast out onto the web. Therefore I have included BASIC editing capabilities in Kazam, but with the clear guideline of not trying to replace applications such as PITIVI. A mockup can be seen below, where the user can now adjust the quality of the video and audio, and even crop the video in an easy-to-use separate dialogue. The final use of this editing part of Kazam, is to quickly export to a number of sources. These include (but are not limited to) YouTube, Vimeo, VideoBin, to file etc.
Just to let you guys know, this will not take place of my work on Wasiliana, just something I was working on when I was getting to grips with Genie. Hopefully one day I shall make such an application…
Links
http://and471.deviantart.com/gallery/#Kazam – deviantArt Gallery with all mockups
