Kingsley, our biggest proponent of dog food
For the last couple of months, Scripted’s engineering team has been managing the content creation process for our engineering blog with our own platform. Everyone on the team (well almost everyone, ahem Ryan) has signed up for a writer account, passed the English Proficiency Test, and started accepting and writing blog posts.
The process has allowed us to dogfood both the writer and business sides of our platform, with the aim of finding UX issues and better understanding our users. There have been learnings from both sides, though I’ve only participated on the writer side of things, so I’ll discuss my findings there.
To start, we brainstormed topic ideas and divvied them up, and then our fearless leader, Jake, used the platform to assign work to all the engineers. I was first up, with what was supposed to be a clickbait post about why we’re sticking with Angular 1.x.
The day before it was due, I began the blog post and had my first taste of our document editor as a writer. I had mixed reviews. Undo/redo was working well, but I noticed for the first time that the font felt a little small. Also, every time I moved a piece of text using copy/paste, extra line breaks disappeared. As the engineer, I knew a regex was removing them as part of an extensive defense against Microsoft Word HTML paste. As a writer, it was annoying.
First, I considered fiddling with how many line breaks are removed after paste actions. This option was complicated. I know the code is there for a reason: It corrects an obnoxious interaction between HTML5 content-editable and Word where extra breaks periodically appear with repeated copy/pastes. Then I realized I could use CSS to space out blocks of text, which is what I really wanted.
After finishing a solid chunk of rough draft, I headed home happy to have found two easy UX wins. That night I saw the editor was open, so I made an edit. A big red modal popped open, warning me that the document was not saving correctly. I reloaded and was redirected away from the document.
I broadcast my frustration to slack the next morning, and Sarah informed me I’d flaked. I’d missed the deadline assigned to me and lost the job.
Our writers do not usually miss deadlines because, shockingly, they’re more professional at writing things than I am. On the rare occasion when they do, the job is taken away from the original writer and offered up to our most efficient freelancers, who’ve earned the “Superhero” badge. Because I’d flaked, Jake couldn’t reassign the job to me using the platform. Day 1, and we’d already found ourselves in a situation that the system couldn’t handle. It’s a tribute to our writers that we’d never before had a business and writer who wanted to work together but couldn’t because of our flake rules.
Fortunately, we are engineering, so “we” can use the command line to reassign “ourselves” to jobs. I considered if warning emails about a pending flake would be a good feature request based on this experience, but most of our writers visit their dashboard more than once a day and would simply be annoyed by the extra email.
After getting my job back, I quickly wrapped up my first post, pressed the finish button to send it off to Scripted’s editor layer, then set about making the easy UX changes I’d discovered. Tasty dog food!
p.s. I flaked twice more while writing this post (sorry, Sarah). Clearly, I’m not cut out to be a Scripted writer.