To be completely candid, this is the story of the last month of EmberGrep. It's been a hard journey for me, and I've grown through the process. This is just some of my feelings and lessons that I've learned.
The Finish Line is in Site
With six days until release, I had completed most of the needed work for the first EmberGrep course. I had built the entire course, subscription, and lesson ecosystem needed to back it up. I had even deployed a free lesson to the public to test the ecosystem and various UX elements. 12 of the 13 lesson videos were recorded, edited, and uploaded to Vimeo. The last video was scripted, and had been recorded once already.
All that remained was the lesson notes to add to the videos.
Turning Away for a Noble Cause
For the Thursday before the course's launch date, I had invited the EmberGrep mailing list to a soft launch of the EmberGrep site. All that was needed was for users to be able to signup for the newsletter (since the homepage changed from the old basic landing page), view the free lesson, view the upcoming courses, and create an account for the site. I also needed to make sure that people weren't able to peek in on unreleased content or purchase courses until launch. This was completed more than a week before the soft launch, yet, I didn't deploy the site until 11PM that Thursday night.
So what happened?
When checking my beta site for the last few tweeks in styling, I found a bug. It wasn't in any of the areas that needed to deploy that day. In fact, when talking to one of my beta testers they didn't even encounter the issue since it took a bit to recreate.
The bug occurred when on a lesson page, the user watched the entire video, moved to the next lesson, watched that video, and then when moving to a third lesson in a single binge session, the video player wouldn't load. This was easily rectified with a browser refresh. It was an issue that could have waited until the ecosystem was actually being used. Instead, I took more than eight hours researching the HTML5 video spec, testing and failing to use other video player javascript libraries (BTW Sublime Video is awesome!), and all over scratching my head. Once I figured out the heart of the problem (you can't change sources on a multi-source HTML5 video element dynamically), there was a pretty straightforward solution (remove the video element completely and rerender the replacement without dynamic data bindings).
The issue was that I let a bug that didn't matter pull me away from the REAL goal. I needed to launch the login system, not solve an arbitrary issue that effected less than 10% of the beta testers, had a simple workaround, and wasn't even available to the production site until almost a week later. It was a noble cause to fix the feature, but I sacrificed customer expectations and more importantly (in this case) my concentration and time before launch. For me, it was the cycle of death from there.
QA - Creating a Launch Day Product
At work, I am a research developer working on iterative projects that move toward MVP. In non-buzz-word speak, I get to screw up: and I get to do it ALOT. It's part of building an evolving product.
Video is VERY different. No one will think twice (hell they probably won't notice), if you update the assets or server logic on a web app. On a video series, mistakes are costly. Not only does it mean going back to editing (finding missing screencap can be really annoying), but it also means informing your customer base.
If a customer has a broken feature, they might report it or just come back later to see if it's fixed. If a customer has a broken video, the cost of them watching it again is HUGE (not to mention resources to stream or download the file again). Even worse, if the training video is wrong, the customer might not notice. They could be missing vital information, or be lost thinking that magic just happened. This weighed heavily on me as it came down to the wire and time for me to go through the final QA stage.
It's All Broken
Working on the course, I was using my time creating lesson notes as my second to last line of QA. It went pretty well on the first lesson. I watched the video and wrote up an original blog style set of lesson notes to complement the video. I went into git and grabbed the file diffs and put together the links that I mention in the video and I was wrapped, checked, and edited in about two hours.
Then, the hammer dropped.
I got halfway through creating notes for the second video and just had to walk away (in reality, I went to sleep but… figuratively speaking). I was second guessing everything:
- "Man that text is small since I recorded at 1080P"
- "I stayed away from pops and background noise, but the VO volume is REALLY low"
- "Those hard cuts are distracting"
- "It sounds like I never breathe"
- "Pasting all the code was a stupid idea"
- "Typing all the code was a stupid idea"
- "Why did I make that edit?"
It kept compounding. I would find a way around some things, like changing some of the cuts, throwing a compressor on the audio (for which I of course had to find my iLok, install ProTools, and then go about ACTUALLY processing the audio). But, I had a terrible taste in my mouth and after four days staring at the screen and honestly thinking that things weren't being improved that much: I postponed the course on the day of release.
Almost Enough is Inadequate
Probably the biggest issue that I've been facing over the last month is that the resources were good enough for most standards. A small tweak here, an audio bump there, and just copying my script and calling it notes and I could have gotten by. For me that's a huge issue to overcome. Telling the difference between my standards and where the production value was became blurred.
For instance, I knew that I had created hard fast cuts and the videos needed more time to breathe and let the viewer see the code for longer. This would mean going back and rediting almost every audio and video cut in every lesson. In some instances, it would mean punching in new VO to slow down my pacing. It's a big task. It's made worse when it's late at night and I am quite honestly getting lazy and the standards start to drop. Then there's the voice that tells you that rerecording would be faster than going back to each individual cut and edit.
I was at a point where I didn't want to touch the product. The mix of knowing it needed to be better fought against the part of me that said "let that be good enough". And, I really want this course to not just be good, but, honestly: I want it to be the best resource for learning Ember!
What's This All Mean for the Course?
Ok, so I know that you've been waiting for this. You want a new release date. I'm not able to say at this point.
While I'm keeping my scripts (including the edits I made during recording the first way through), I am rerecording and editing the course from the ground up. This allows me to solve some of the bigger production issues such as font size, resolution, background noise, and overall pacing and presentation.
This post is also to say that… Today I just finished reworking on the first lesson. That's not to say that I've been working on the first lesson for a month: quite the opposite actually, which is why I wrote this post.
It's hard to tell a pattern from one lesson (although I do have the time it took to create the first iteration). However, I'm seeing that recording takes about an hour (20-40 mins prep and 20-30 mins of actual screen time), and then editing takes me about 30-40 mins (which is about half of the last iteration since I'm allowing more air time). The notes are still the big question. The first notes took me about two hours to write, edit, and grab the right links and files.
That's probably a bit high for most lessons since the first lesson had it's growing pains. It also had more links to track down (plus I was still building some of the ecosystem around styling the notes as I wrote them).
I'm continuing to work on the course this weekend and in my spare time so it is back on track. It's just not quite at a point where I can definitively say how long that track is.
Thank you for your support and understanding,
Ryan
For the comments, I'd love to know if you also have a problem with delivering a product that is just below your standards? Or, does is it hard for you to work on something that is close to being done?