Project Remix: What? Why? How?

It’s been a bit over 3 months since I started working on Mix.byCollab, my stab at building a real-time collaborative video editor.

I am working on this by myself and have nobody to report to or to hold me accountable. And Tax Day just surprised me with the realization that my runway might not last me as long as I thought it would… which is a bummer. I guess that’s my accountability.

So, to not lose motivation and to stay on track, I thought I might as well be transparent and blog about my progress on a regular basis (maybe a weekly blog post, but don’t quote me on it).

What?

Ever since working on ZDO, I have been wanting to create an HTML based online editor for videos that let people upload their shots and stitch them together a la iMovie, Final Cut, and Adobe Premiere. But, I never started on it, because from a UX perspective, I was taking an already complicated experience of a native app and making it shittier by pushing it online.

But then, I started working for Google Docs. And, two realities of the new web dawned upon me:

1. A highly complex application such as a word editor or spreadsheet can be fully written in client-side javascript, and perform at an acceptable level within your browser window; and
   
2. Even though Google’s suite of apps wasn’t providing the sleek (debatable) native experience of Microsoft Office, it was miles ahead of it in terms of usability and functionality. All because of its one killer feature: Real-time Collaboration.
   

If I can get the application to be as collaborative as Google Docs, then it would be worth any degradation in UX performance. And, with the advances being made in WebGL, Socket IO, Web Workers, and FFMPEG.js, it might as well be an app that runs inside the browser. You must have seen the screenshot from my previous posts about what it will look like. If not here it is again:

And yes, that’s the browser experience that I’m shooting for. And if HTML & Javascript aren’t up to par to handle videos, then I could still build a collaborative editor that runs across all the native platforms, but I’m taking a web first approach.

Why?

1. I strongly believe that creativity gets better through collaboration, and the current set of available tools don’t enable frictionless collaboration. (I’m well aware of the irony intrinsic to me working solo on this project.)
   
2. I am passionate about filmmaking and storytelling, and not bought into the hype surrounding #blockchain yet :/ Definitely not bitcoin, which is literally fool’s gold.
3. I wasn’t happy about the work I did at Google. Don’t get me wrong! I love the company, and think it’s a great place to work. But, I felt unhappy with the scope of my work, and that feeling Steve Jobs talked about in his Stanford commencement speech kept creeping up on me.

The reason I want to create a collaborative video editor is simple: There’s increasing demand for video content on the web. And, to keep up with the demand, media sites and software companies are focused on speeding up the video creation process by sacrificing on quality and putting out junk content. There are companies like Wibbitz out there that are focusing on using machine learning to automate the creation of more junk videos.

I think there is a better way to keep up with the demand, and still maintain the quality of content being put online. I want to focus on enabling teams to streamline their workflow and unleash their creativity through collaboration. I want there to be more videos like this, and less like its subject matter :)

How?

Two words: “Operational Transforms”

Actually, it’s a lot more than that, but’s that’s the basic tech behind making the project state sync in real time. That’s how Google Docs syncs documents across user sessions. That’s how Dropbox Paper syncs its paper docs . And pretty soon, how Eclipse Che editors will sync their source code.

Words beyond “Operational Transforms” which I will get into detail in future posts:

• React Components for UI.
• Canvas + WebGL for rendering preview.
• Ffmpeg.js for exporting.
• Web Workers + Socket IO for communication.
• gRPC + Spring Boot for sync backend.
• Spring Boot + MySQL for backend services.
• Dockers + Kubernetes for deployment (potentially on GCP or AWS).
• Google Cloud Store or S3 for asset storage requirements, which is currently satisfied by my dev Macbook’s local filesystem.

What’s the status?

I spent a lot time initially to get the OT syncing right, and have a working gRPC service for syncing operations on the shared document between clients, which, as an engineer looking at it from an architecture perspective, is where the meat of the project is.

I’m currently working on building the editor front-end which, as far as the rest of the world is concerned from a value perspective, is where the meat of the project is.

And, it currently looks like this :/ #DontJudgeABookByItsCover #DontJudgeAProjectByItsLooks

In my next couple of posts I’ll dive into the details of how OT syncing works, the overall client-server sync architecture, as well as how I’m architecting the front-end using React components. And hopefully, the status screenshot will evolve with each post.