I have been setting up a new computer (yay!) which means installing a bunch of software (boo!). It’s actually been a while, at least in software years, since I did this, so I’m enjoying some pleasant surprises (like Homebrew, and having no reason to need MySQL yet) along with the unpleasant bumps along the way.
I’ve also been chatting with several new and prospective Dexy users, and trying to get a feel for what issues people encounter when they try to install and run Dexy and start working through the tutorials. It’s great when I can provide just a few small tips to help people get started, but of course I have no idea how many other people run into those small little roadblocks and decide “oh, I don’t have time to troubleshoot this now, I’ll come back to this later” or even “that error looks scary, I’m never running this program again”. I do use feedback to refine tutorials and improve error messages, but I know I’m not seeing all the potential problems.
On the other side of this, I had an incredibly frustrating Sunday with a not-quite-polished web application, and a particularly frustrating afternoon today trying to figure out how to set up my EC2 environment for command line use. In both cases I really wanted to provide constructive feedback on my experiences so the app and documentation (respectively) could be improved, but by the time I had solved the issues in question I realized that (a) I really didn’t want to spend any more time on them and (b) I probably couldn’t remember and reconstruct all the issues I ran into, so it wouldn’t have been a terribly useful exercise for me to provide feedback, without a lot of work (GOTO a).
However, out of frustration came an idea. While last week I was toying with the idea of suggesting that prospective Dexy users arrange a time and Skype me when they are first attempting to use Dexy so I can provide real-time assistance, now I have refined this to the following idea which I am going to put into practice:
Whenever you are about to install or upgrade software, use new or recently upgraded software, or try to do something unfamiliar, or just any time your spidey senses are tingling, start a screen recorder. Preferably one that catches sound and, ideally, webcam video. Use the audio to explain what you are doing as you do it. When you are finished, if all has gone well, then you can just delete the recording. If all has not gone well, then you can watch the recording, note down the times at which important things happen, and email the developers with your documented tale of woe.
Will this be practical? I have no idea. Will this backfire with users not bothering to do as much troubleshooting as they otherwise might? Not sure about that either.
I know that I, as a developer, want to know about people having bad experiences with my software. Many of these experiences will have nothing to do with my software, but I still want to know about them.
I know that I, as a user, want to be able to express my frustration when things go wrong to the creators of software. I want to do this in a constructive way, but part of me also wants to convey the very real cost that poor design or poor documentation imposes. I also want to be able to easily illustrate ways in which software could be made more beneficial, and to be able to provide accurate and useful feedback when I encounter an issue.
So, I personally will be doing this screen recording experiment. And, if you are a Dexy user or are about to try Dexy, I encourage you to do it too. There’s no need to send me links to videos where everything went well (unless you’ve done something very cool with Dexy and want to tell me about it – then please do!) but I encourage you to send me links to videos that illustrate a problem or roadblock. Or, if you have suggestions for improving the tutorials or other documentation. Preferably with an explanatory email telling me what you were attempting to do (if it’s not clear from the voiceover), and I’d really appreciate timestamps where important things happen. I can’t promise to watch everything, but I will do what I can. And, please use this as a supplement to rather than replacement for the usual information you submit with a support request.
I have started a list of screen recording software with an emphasis on free, multi-platform software. Please feel free to make additional suggestions in the comments. I suggest people do a trial run to ensure that the software doesn’t place an undue load on your machine, and that your console screen is actually readable (a text-based, searchable console transcript is probably a good idea anyway – easy if you’re using GNU screen). A console transcript is also an option if you don’t want to record a video, and you can delete any sensitive content this way too.
If you upload your screencast to a hosted service, take note of their Ts and Cs in relation to the ownership of your upload. Take care that your screencasts don’t include any sensitive information like passwords or API keys, or any dodgy browser history that you don’t want the world to see. I certainly won’t rebroadcast anybody’s screencast without their explicit consent, or mention anybody by name [assuming recordings are in good faith, that is], but I will take note of the OS and software you are using in order to better tailor training materials, and I may discuss these in an anonymized way like “I notice a number of people who submitted screencasts to me weren’t using GNU Screen, let me tell you what a great utility this is.” If that bothers you, then, well, probably best not to send me anything since it will be hard for me to unsee. If you are happy for me to publish your screencast on the Dexy blog or elsewhere, then let me know and this will make things quicker for me in the event that I want to share some examples in future. If you give me suggestions for documentation improvements, I will assume that you want me to go ahead and make use of these.