My 17-month side-hustle journey from code-dummy to building a product

David Hawkins
Jul 15 · 17 min read

Building a plugin for Adobe After Effects was never something I seriously considered. My yardstick was Andrew Kramer’s amazing Element plugin, which is wildly complex and (as far as I know) has a team of people far smarter than me working on it.

But as I tinkered myself towards the edge of the coding cliff, I learned that this was really just an outlier in a sea of relatively simple but useful third-party apps.

On what must have been a slow day, I finally took action and looked into Adobe development some more. What I found was reassuring for code-dummies like myself.

After a lot of starting and stopping, I’ve now built something with walls of scary symbols that, until recently, broke me out in cold sweats. It was hard, I learned a lot, and I certainly had a boat-load of fails.

But, I found it immensely rewarding. Looking back, I’ve learned that it’s also not something you need a four year CS degree for — although having a head start on the fundamentals will help.

What I do have though, is patience. If you do too, read on.

This article is about my 17-month side hustle journey to a product that I now believe is reasonably well-rounded and useful to anyone building a brand online through video, for themselves or as a service to others.

The case study ahead will hopefully offer practical insights to designers but more specifically to those who want to take their Adobe apps to the next level for themselves or others.


Semantics

I’ve learned that programs like Element are categorized as plugins. They are low-level applications with a GUI (graphical user interface), written in C or C++ or other intimidating geekery.

However, most third-party add-ons that involve code are not actually plugins. They are scripts, expressions and — as is the focus of this article — HTML extensions.

Before HTML extensions, the only other game in town, besides plugins, was scripts written in Adobe’s ExtendScript (which we’ll get into later). JSX scripts are very popular. Some of my favorites are Ouroboros, Comp Setter and Motion.

They are often built to save time on tasks that could otherwise be done manually, in more steps.

  • Ouroboros allows you to quickly style and animate paths.
  • CompSetter allows you to quickly make project-wide changes to a bunch of comps, whether that’s resolution, length, etc.
  • Motion is the Swiss Army knife of shortcuts, allowing you to create interesting animations at the click of a button, as well as change the interpolation of keyframes and the placement of your anchor point.

Where they fall short, however, is in the design department.

Without HTML and CSS, the aesthetics remain homogenous to that of the dark-themed/basic-buttoned After Effects universe. Not necessarily a bad thing, of course, but it leaves designers pining for more.

ExtendScript is also an older version of JavaScript, so modern code may not produce the results you expect. Adobe itself now views ExtendScript as legacy language.

For AE 2019, Adobe announced a new JavaScript expression engine to replace the legacy engine based on ExtendScript. Several of the expressions in my extension, Dokyu, had to be yoinked out and updated to modern syntax to avoid flagging errors in the new engine.

Speaking of expressions, this is technically another form of scripting. At their essence, expressions can only be applied to one layer at a time and are written manually, pasted in, or applied through a script.


What Are Extensions?

Before we continue, you might be interested to demo the extension.

Extensions in Adobe apps are dockable panels, much like you would dock a JSX script written with a native GUI.

However, rather than being exclusively written in ExtendScript, with the functional and aesthetic limitations that presents, extensions are run through Google’s CEP engine; a stack of technologies that produce a working panel in one of the supported Adobe apps.


CEP Engine (the Stack)

In 2013, the first version of Adobe CC was released. With it came HTML support. (Technically, Adobe Flash extensions were supported before HTML but at this point, that’s a little redundant.)

This HTML support was introduced due to a new form of third-party app framework: the CEP engine.

Think of it as a web app or website inside your Adobe app. CEP stands for Common Extensibility Platform. It’s a collection of web technologies integrated to extend the usefulness of Adobe’s suite of products.

Apple would be nothing without the App Store, so you might consider this a niche version of that idea. Developers around the world are free to extend Adobe’s suite of software, improving the platforms for both designers and Adobe.


CEF — Chromium Embedded Framework

Think the Google Chrome browser in your Adobe app. It supports most of the features you see in the browser. Things like audio, video, drag-and-drop, web storage, and API frameworks.

Below is a comprehensive list, although it’s worth checking the latest CEP versions for new functionalities, as new versions are published each year. (For this reason, Chrome updates may not come to Adobe apps as frequently as through the browser only. CEP versions are updated only once a year.)

For peace of mind, Adobe says in the documentation that:

“The CEP HTML engine does not restrict using any extension JavaScript libraries. As long as a library can be used in CEF Client or Chrome browser, it should be usable in CEP HTML Engine.”


HTML, CSS & JavaScript

This Chromium framework runs with familiar web technologies: HTML markup, CSS & JavaScript. It bodes very well for the future as you not only have Adobe following through with their newer native extensions (more on that later), but the underlying framework is as modern and dynamic as you can get.

It’s also universally adopted, unlike Flash which was produced by Adobe but is no longer in development. (And is now rejected by default in most modern browsers.) It’s a reasonably safe bet.

HTML builds the core framework of the app, CSS styles it to your liking with some basic animations if needed, and JavaScript provides the brains to the outfit.


Node.js

More exciting still, Node.js is also supported. (Node is actually powered by the same engine as CEP panels.)

You might think of Node.js as jQuery, but rather than being client-side, it caters to the server-side.

A rich ecosystem of pre-made software means that many features within your app may have solutions already. Check out the pre-installed npm package manager to see what’s available.

One example with Dokyu was to use ADM-ZIP, a popular ZIP compression library. It enabled users to download file[s] from the Dokyu server to a server-specified directory on the user’s machine, and automatically unzip it so the app would automatically find what had just been downloaded.

Having said all that, I ended up with a simpler solution for the final version of Dokyu.

Another example I experimented with was building the extension into a full-stack application. That is, an app that delivers services through a Node.js back end server launching silently alongside the panel the user can see (the front-end HTML, CSS & JS).

Information on the server doesn’t have to be shared with the user. This makes it ideal for sensitive information or delivering files. It’s also a good practice for services that will need to scale with use.

Finally, I spent far too much time experimenting with the Amazon Polly API (text-to-speech) which would have automated VOs. Polly offers access to the technology that powers Alexa.

It was up and running easily enough but I realized quickly that it wasn’t adequate, so I re-branded it as a proxy VO for timing animations and offering samples to human VO artists.

Then I decided I would wait until a better service came around and I could test demand more quickly. (Google’s WaveNet looks interesting, but it is not available nor cost-effective at this point.)

The Adobe team have written a neat tutorial here if that’s something you think your app would benefit from.


ExtendScript

Finally, we have ExtendScript; also known as JSX or syntactically called EcmaScript 3.

This is an older version of JavaScript (syntactically known as EcmaScript 5) which has been adapted to offer functionality in the Adobe apps which wasn’t available in the version of JavaScript at the time. One feature of ExtendScript is the file system, for example.

It’s used for any script that transforms a user action in the extension into a programmatic action within the Adobe app. For instance, moving the anchor point, creating a text layer, assigning effects, etc.

However, for communication between the extension and Adobe app to take place, there needs to be a bridge to translate between the two languages.

JS can communicate with JSX using JSX-compatible code, which can then return a value. Conversely, JSX can listen for JS events and trigger callbacks.

As an example, you can use csInterface.js which is required in extensions. This is effectively an API that Adobe created for extension/app communication.

The call CSInterface.evalScript() can be used in your panel’s JS to speak with the JSX/Adobe app. But it is an additional step to take and can tax your short term memory when there are a lot of calls from panel to interface with the Adobe app.

On the plus side, as you’ll recall with the new JS expression engine, there’s good reason to imagine Adobe transitioning over to JS for scripting, as well as expressions, very soon, which would simplify development massively.

If you want to go deeper into this topic I encourage Davide Barranca’s training. (No affiliation, just recommending a good product when training on the topic is scarce outside of forum posts. The training is for Photoshop but much of the information applies to any Adobe app that allows CEP panels.)


HTML Panel Without ExtendScript

Although most HTML panels interface with the Adobe app, nothing says you can’t have a preview-only panel. This way, the website analogy would be even clearer.

In practice, the user could access information from within the Adobe app that has some utility. An impractical example might be a weather app. More useful might be a team chat app.

In the team chat example, a siloed extension could plug into your server or an API and offer even more advanced features without ever having to touch a line of ExtendScript.


HTML Panel Examples

As is perhaps expected, Adobe themselves have been designing newer panels in the HTML format.

On launching your app, there’s a good chance you’ll see a welcome screen that looks distinctly different from the conventional user interface of a panel. This includes image and video elements which are very easy to produce if you are familiar with HTML markup, CSS and perhaps a little JavaScript.

If your app includes a ‘libraries’ panel, you’ll notice it looks a little fresher compared to other native Adobe panels.

Looking forward, it’s not too bold to expect much of the Adobe suite to transition wholly over to CEP, as this will open up the opportunity to use their apps in the cloud. Just as Google Earth is now accessible in the browser without downloading an installer.

While doubtlessly a technical feat with volumes of legacy code needing to be re-written, if Adobe wants to keep its edge over new entrants like Canva and Animoto, they don’t really have a choice.


Dokyu — Brainstorming

January 30, 2018 — February 28, 2018

Brainstorming for Dokyu began in earnest on January 30th, 2018. This is when my written notes started in Apple Notes and Trello and it’s also the date I received Barranca’s HTML Panels course.

No more playtime, then.

In Apple Notes, there were some disparate thoughts. I posed one question that resonates with me now: “Could I become the Frame.io of animation?”

In Trello, I asked the question: “Include Adobe Stock/alternative?” as Adobe Stock was the immediate media solution that came to mind. Although, as Adobe Stock is a paid service, I stopped considering it as an option before even finding out whether it was possible.

I listed a link to a page on Adobe, About Creative Cloud Libraries. Presumably, I was researching how Adobe was using the cloud in their extensions, but I can’t remember now.

I also captured the following screenshot which was one source of inspiration for the UI of Dokyu’s ‘preview-top, text-bottom’ card format:

A point I’d like to make here is that I really wasn’t certain which direction this would go. I was almost indiscriminately collecting possible ideas from a 20,000-foot view.

Business models, design, functionality, marketing, and other things I’d come across before that which I thought might be useful.

Just collecting a ton of stuff without putting pressure on myself, so I could get to the easy and more structured work of editing it and letting ideas circulate in the back of my mind. (I also go on walks daily which is really helpful for seeing problems and solutions from different angles.)

Throughout February, I researched current entrants to get an idea of demand, consumer expectations, and possible pricing models. Here’s one example:

“GoAnimate is a cloud-based animated video creation platform. With GoAnimate you can create animated videos for your business using thousands of props, assets, and characters, representing hundreds of industries. Create professional videos with simple drag-and-drop tools for a low monthly cost. Start a 14-day free trial.” — GoAnimate

And I considered whether I would require users to sign-in via the panel before accessing the goodies. This is an approach the Getty Images extension takes. (See image gallery for concept art, below.)

I’ll stop there for the sake of time, but feel free to contact me for more ideas and I’ll be happy to help you out if you’re feeling a little directionless or overwhelmed.

One more thing I’ll say about brainstorming is regarding the course I purchased. It wasn’t cheap, although not unfairly priced for the content; 28 working HTML demos and video training. Particularly when there’s no comparable alternative.

One of the most valuable aspects of Barranca’s course was the 28 HTML panels that you could install and play with. This gave me an insight into what you might want to do with a panel in Adobe apps, and more importantly, what was possible.

I had assumed that the extensions were limited to shortening the routes to doing a certain task in After Effects; centering your anchor point is a classic example in After Effects.

The working demos were unobfuscated, meaning I could deep-dive into how to go from a basic “Hello World” panel to styling it with basic CSS, and to essential workflow tips like managing the pains of cache while developing.

A personal tip from me. (There may be superior approaches to caching but this saved me a lot of time.) Viewing the latest versions of your extension inside Adobe apps can be particularly challenging.

I tried deleting several cache folders, which didn’t help. Adding — disable-application-cache to the manifest.xml file also did not work for me. The best approach I found was renaming the com.###.panel folder by adding a number where I’ve placed the hashes. Then ensure you update the manifest.xml to reflect the changes.

Make sure debug mode is also enabled. (The default writes com.adobe.CSXS.9 PlayerDebugMode 1 in the terminal. ‘9’ corresponds to the CEP version. ‘0’ at the end disables debug mode.) This forces the Adobe app to load your extension as new.

After learning the basics, more advanced demo extensions that plug into APIs on the back end, like a weather app, were less daunting and really opened up the exciting possibilities for what I could create.

Brainstorming is a super interesting topic but too long for this article to do it justice. What I will say is that to hone in on my app concept, I looked at what was possible, courtesy of the 28 HTML panel examples that came with the training. As well as where I had some experience: creating templates.

I asked myself: “How can I create something that differentiates me but also wows people’s socks off?” I learned that having a ‘website’ in AE opened a lot of doors but looking pretty is nothing if it’s not useful once the novelty has worn off.

I knew I could create templates; I’ve been doing that for several years.

The problem is that the competition is hot, piracy is rampant, and templates alone don’t really reconcile the inconvenience of having to manually install something and dedicate limited screen real-estate to.

Which feature/benefit could I leverage that is enabled through HTML panels — a skillset I hoped would give me an advantage over the competition and protect my work — while complimenting the various features of the product into a coherent package?

The idea of providing access to stock media alongside templates, many designed around stock media, came at the start of brainstorming. It was with Adobe Stock, as I mentioned earlier. But I didn’t want to promote that as an additional cost after users purchased Dokyu.

While taking the course, I installed and studied the free Flickr app in the training to understand the coding behind it. This introduced me to the idea of an API for images while retaining complete control over the appearance of your extension.

I then wondered whether Pixabay, a popular free stock image website that I’ve used many times, would have an API for their community.

Fortunately, they did. I contacted the website to let them know what my plans were, and with their approval, got to work.

Early inspiration from Adobe, Barranca’s training and seeing what HTML panel extensions were already out there.

(Very) rough drawn concept in notebook
The beautiful Frame.io UI which gave me an idea of just how customizable extensions were
An early version of Dokyu that included a text-to-speech facility from Amazon’s Polly API. It was eventually dropped as the quality wasn’t quite there.
An early timeline concept bodged together in Photoshop
The beautiful Fontself Maker for Illustrator
Researching Muserk for Premiere Pro. (Web apps work the same across all CEP paneled Adobe apps by just editing the manifest.xml file within the CSXS folder. You can choose which Adobe apps and versions to allow your app to be opened in.

Dokyu — Development

February 28, 2018 — July 14th, 2019

I had paid for and started the training. And now I had copious amounts of notes with a little triaging for the core functionality. Something I could start to work with, anyway.

The future of the extension was still up in the air at this point. I wasn’t even sure whether I’d be able to work it out. It was a lot of information to take in and I was most certainly out of my comfort zone.

Doubts crept in more times than I’d like to admit, but you know what? This was a side-hustle, a fun little experiment. And the only person to judge at this point was me.

In case you find yourself dealing with imposter syndrome, or just doubt your ability to code, I recommend the book Outliers by Malcolm Gladwell. It transformed my fixed mindset into a growth mindset and I’m very grateful for having read it.

I can still be self-critical at times. TLDR: it’s less about ‘fixed’ genes and more about just putting the hours in.

The image gallery below will perhaps do a better job at conveying the progress during development than anything I can write here. I’ve also included a list of resources that I used throughout development at the bottom of this article.

The key momentum points for me were:

  1. Paying for tuition at a price point that was high enough for me to question whether I was committed enough to stay the term. I won’t state the cost here lest Barranca changes his pricing, but it was three figures which is an amount I rarely spend on tuition online.
  2. Starting to write those first notes as quickly as possible and without too much judgment on my ability to do anything with that information. Just get an idea of what people might be prepared to pay for with what interests you from a development standpoint and what is realistically possible in line with what’s already available. (Although, if you have specialist knowledge to justify reinventing the wheel, your situation might be different.)
  3. From there on, it just kind of evolved slowly but surely, step-by-step, revisiting the brainstorming process as I encountered obstacles or new information.
A more chiseled concept of the idea

Dokyu is alive! Sort of. Very rough experimentation when I believed Dokyu would need file system access.

Dokyu contains two apps in one; Motion and Media. The first two images are early implementations of that.
Dokyu contains two apps in one; Motion and Media. The first two images are early implementations of that.
An early build of Dokyu Motion, with the awesome Tippy tooltips!

An early working version of Dokyu Media, alongside a quick inline checkout through Gumroad. This wasn’t the best format from a UX standpoint (too small) and it would have been weird for most people as I haven’t seen payments inside AE done before. So users are now directed to their default browser for payment.


Closing Words

If you have any questions, feel free to reach out. If you are curious to see the published version of Dokyu, there’s a web demo at my homepage: https://3dmybusiness.com/

In closing, I’ll reiterate the importance of passing on personal judgment during the first few weeks and months. That’s just something that helped me.

The point is, it’s so easy to feel overwhelmed early on. If you struggle with self-criticism, try to relegate the activity to just a fun little project that may well never see the light of day. That’s fine.

Curate inspirational content, think about problems and solution you believe others would pay for. As a designer, the curating habit will no doubt come in useful for other projects if you don’t do that already.

Use Google extensively to see what others are saying about a solution you have in mind. Allude to it in social media posts without distorting the results by stating you want to make money with it. (“Does anyone know how I can do xyz in After Effects/Photoshop/Illustrator?”)

Invest in yourself so you might one day have enough time and resources in life to start giving back. I can’t think of a better way to spend your working life.


Resources

Remember that ExtendScript is now a legacy language so update to a modern cross-compatible syntax where you can.

I will add to this list if I remember any more resources and I welcome suggestions.

Paid resources

Although Photoshop is the focus of this training, much of the content applies to all Adobe apps that accept CEP panels. As Barranca says himself:

“HTML Panels are implemented in a variety of Adobe Creative Cloud applications; the course is based on Adobe Photoshop, yet Panels’ architecture is shared among them all.”

Important: I used this training to produce a fallback .exe when I was having problems with a Windows ZXP installer.

ZXPs are basically installers for Adobe programs but still not without a fair share of bugs. Frankly, ZXP typically works fine as long as your app is under 500mb.

I had no issues with Dokyu when it was under this size. Although, I only ever had issues with ZXP.

Even if you want an exe fallback for your app, Barranca’s original CEP training (above) does include exe creation but without the advanced automation which simplifies exe creation with a programmatic approach.

Free resources

Better Programming

Advice for programmers.

David Hawkins

Written by

Animator and developer. Founder of 3DMyBusiness.com. Creator of Dokyu for Adobe After Effects. Publisher of Better Programming.

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade