Flipgif: draw and share your 10 second creation!
Here’s the idea: Drawing scribbles and doodles is always fun. But when you finish your doodle, you *only* get to see the final static image.
Why not record the user’s mouse movements/doodling, and then rather than giving back a static image of the final composition, give back a .gif or a .webm?
Some twists
Now, to add an extra bit of creative tension, there will be a limit to how long the user can draw for: I’m thinking 10, or possibly even 20 seconds. This will serve two purposes:
- Encourage the user to “get on with it” - nobody likes to sit around for ages watching a
.gif's punchline come to fruition. - Place a hard upper limit to the backend storage requirements
Flipgif’s user-facing offering
The user-facing “Flipgif” interface will be a very simple web page with a canvas element as the central focus.
-
When the user starts drawing, a 10 second timer will start. When the user draws on the canvas, the timer counts down.
-
To end the doodle, either keep doodling until the timer reaches 0, or click an optional “End doodle” button.
-
This will then send the user’s motions as a JSON blob to a backend renderer, which will compose the result into a .gif, or .webm, and any kind of resolution/format.
-
The user is returned a link to the animation, which they can share with their friends however they like, via Discord, Steam, or any chat messenger.
Below is an illustration of what the full application pipeline look like:
Risks
A major obstacle to any kind of drawing, is the physical interface. The mouse is a very poor input device, and touchpads are even worse.
Mobile devices are a natural fit for any kind of drawing input, but they will require additional work to the website in order to fit the canvas to the user’s full screen size, as opposed to the PC display where the canvas will take up only a small element of the screen.
Summary
By recording the creation of the doodle, aswell as the end product, it hopefully adds an extra dimension of user value that could be exploited for fun/comedic effect.
The time limit forces the user to avoid dragging on, and get to the punchline as soon as possible.
Finally, the technical decision to send the user’s drawing motions, instead of the final composed .gif (which I think would be possible to do entirely on the client-side) serves two purposes:
- Prevent the backend from being (ab)used for image hosting purposes
- Gives freedom in creating a large number of formats after the user has already made the drawing. e.g. lazy on-demand format conversion at a later date, changing resolution of the composed canvas without loss of fidelity, etc.
