Sean Riley, one of the creators of Computerphile, a web series about Computer Science from the University of Nottingham, tried to create an episode for his series using just free software. See how he faired below:
Inspired by an interview he conducted with Matt Lee, Technical Lead at Creative Commons, Riley embarked on the adventure of trying to processing Matt’s video using exclusively tools available on a Linux computer and only using programs and apps available under a free license. He managed to more or less complete the task, but he felt compelled to record another video describing how he felt about the whole process.
The video is not a tutorial, but more like a low-key rant. While clearly a very polite person, Riley’s frustration is palpable throughout and it may be a tough watching for some developers. But then again it is an invaluable peek into what is wrong with the current state of free and open video-editing software. What is probably even more interesting is that not all problems can be solved with coding.
Linux is Still Hard
There are many points that developers who have ever conducted a user-oriented surveys in the past will have heard before. For one there is the issue of the installation and configuration of Linux itself. Hardly the app developers’ fault, agreed, but in a world where 99,99999% of computers targeted at end-users come with some sort of proprietary operating system pre-installed (and, hence, users hardly ever have to install an operating system at all), this is a hurdle that has to be taken into account before your video-editing app is even run.
A possible solution to the above would be to develop a solid multimedia-oriented (live or otherwise) distribution. Instead of installing the operating system AND the apps, from the users point of view, you only have to install one thing. As for “solid”, I mean if it is possible to design a general purpose distro “that just works” (identifying hardware, facilitating installation of third party software, and so on), it should be possible to create a similar distro for a subset of applications for a specific purpose, such as video and audio editing.
It is true that there are quite a few distros that try to do this out there, but (a) they are usually unipersonal projects, and when the maintainer gets tired of the project, it gets abandoned; and (b) they do not collaborate directly with the creators of the apps they are installing. This leads to old or poorly configured software that is adequate for the creator of the distro himself, but does not perform well for other users.
Then there are the problems with the editing apps themselves. In Riley’s experiment, Cinelerra proved too difficult to understand (as did Blender) and too quirky and finicky. Many others crashed or froze when asked to execute certain actions. Most did not implement the features that would allow to complete the task in satisfactory way, or did so in a non-intuitive way. For the record, Riley found Kdenlive to be the most useful and usable program, but even that had many problems.
On the whole, we can divide the problems Riley describes into two broad categories: (1) those related to apps themselves; and (2) those related to his own expectations. Believe it or not, there is a lot a development teams can do to solve both kinds of issues. First, of course, teams can do what already is their main task, i.e., adding in new functionalities, especially if requested by users; and bug squashing. Having said that, too often, you see developers treating user requests and bug reports with a non-productive amount of hubris.
Take a look, for example, at what happens when the much requested feature comes up at Q & A session with GIMP developers (minute 7). This feature, by the way, is one the developers are still refusing to implement:
BIIIIG mistake. Notice how the audience turns aggressive when they are told that they are wrong to want CMYK support.
Yes, I get it: you cannot have a device that can only output RGB colours really and truly reproduce CMYK. But arguing the issue is pointless: there are programs out there that simulate CMYK, because, you know, that’s what computers do: simulate things. Those applications thanks to their apparently magical simulation skills, have become prevalent in the industry and as long as GIMP does not offer the feature, it will never have a significant user-base and will be considered by professionals as a toy.
You argue with your professional users at your own risk, especially if users have alternatives they can point to that prove you wrong.
And then there’s the matter of improving the software using user feedback. A fact of life is that submitting bug reports is a bore, so it is important to make it dirt easy, preferably automatic, taking a page out of, for example, the Firefox manual.
Once received, the team must hone their PR skills and have developers respond to the content of the report only, never the tone. Too often, when users finally resort to reporting a bug, they are beyond frustration and can be brusque in their messages. The bug has gotten in the way of their work. Reporting bugs is a time-consuming hassle, so the user must be really ticked off to bother. It is unwise to flip somebody off just because their exasperation bleeds through. Plus it is worth remembering users cool off and, by focusing exclusively on the content, and being reasonable, you are more likely to gain an ally and a faithful user that, in the future, may serve as an evangelist, collaborator (maybe in the form of a beta-tester), or even a donor to your project. There is nothing to gain in pissing a user off with a snide comment on how they don’t sign your paychecks.
If the requested feature does happen to already be implemented or the error occurred due to the user doing something wrong, say like missing a step in the installation of software the app depends on, then you may have a problem with the usability of your project. The feature the user wants may not be clearly labelled in the menus, or the documentation of the app may be lacking. All these are problems that must be solved by the development team. Blaming the user will not help… ever. Document well and extensively, ditch your assumptions about what you think the user should know, and be willing to update your documentation often. This is usability 101.
Which brings me to Riley’s final gripe: Creators of Free Software video processing and editing have to take extra steps to make their tools known and knowable to the users, including flattening the learning curve as much as possible. You want users to change over to your software, right? The marketplace is dominated by a few well-known applications and users willing to migrate to yours do not only have to learn how to use this new free app, but unlearn the old one. Years of muscle memory-associated keyboard shortcuts (such as the Ctrl+D shortcut Riley mentions in the video) that don’t translate to their free counterparts are going to make the free software apps seem clunky and counterintuitive.
There is no shame in copying over menu structures and shortcuts from industry heavy-weights. Even though a developer may think s/he knows how to do things better, the “best” in usability-land equates to no more than “make users feel less frustrated“. Familiarity, i.e, being able to access the same features through the same menus and keystrokes as to what users have become accustomed to in the proprietary counterparts is a key element of usability.
If you still want to keep your original setup because you are convinced it is better, create an optional “theme” that, when activated, emulates your competitor’s look and feel. Call it “XYZ Compatibility Mode” and include it somewhere really obvious within the menus, under File for example.
That’s how Microsoft wrestled the wordprocessing market away from WordPerfect and it is the only way it will work for free software too.
Cover photo by mconnors for morguefile.com.