Remember Bigcanvas? The infinite online canvas that anyone can draw on, which I launched in 2013? I didn’t do anything with it since, but the idea has always been at the back of my mind, biding its time. The most fun games for me are always those which give you creative freedom (RollerCoaster Tycoon, Minecraft, Kerbal Space Program, SimCity) so even though Bigcanvas is not strictly a game, this is something I would love to work on. Recently, I bought the domain bigcanvas.io and started working on a second version.
The original implementation gathered a fair amount of interest briefly, then faded back into obscurity. It may also have fallen victim to a server reboot, as I was just running it in a
screen session. I revived it for the occasion; have a look here! (It’s again running in a
screen session, so don’t expect longevity.)
Three things conspired to make me pick Bigcanvas up again. The first was that idea at the back of my mind, that this could really be something. I had many ideas how it could be improved and made more engaging. I’d even worked out several possible monetization strategies, which could get me some passive income without hurting the core idea of a free, infinite, somewhat anarchistic creative space.
The second factor was that I will sooner or later be leaving my day job, either because I’ll move to another country again, or because I just want a change. I still want to be an independent developer, or entrepreneur if you will, so it would be good to get some practice and make all the mistakes while I still have a financial safety net.
The third factor was a book I read recently, The Lean Startup by Eric Ries. It’s not rocket science, so let me summarize it. As a startup, you’re operating in extreme uncertainty: you have no idea whether your idea will work. So the first thing you should do is not to create a perfect product, only to find that nobody wants it; rather, your first mission is to learn what it actually is that people want. You do this by building a minimum viable prototype to validate your core assumptions. From then on, you continue to run rigorous scientific experiments to validate any hypothesis you might have about how to improve.
If this reminds you of agile software development, it totally is, but extended to the world beyond software. Also, I feel that most agile methodologies are targeted at business-to-business (figuring out what your client wants); the process for figuring out what consumers want is different (more based on metrics, less on just asking them directly).
Anyway, I was itching to try this method in practice, and Bigcanvas seemed like a perfect case study. I have many ideas in my head that might work, that might come together into a final product, but they’ll just be unvalidated assumptions until I try. The first Bigcanvas version had already validated that, given an online canvas, people will actually draw cool things on it. That seems promising.
It also gave me some interesting insights that I would never have had otherwise, such as that community moderation works: yes, people would draw penises, but other people would often find creative ways to turn them into a cactus, a dog or a flower. If I’d given them an eraser, they’d have been even more effective. Without this insight, I might have spent days up front to come up with some kind of flagging and moderation system. It might still be needed in the end, but now I know it’s not that urgent.
One of my other findings was that drawing with a mouse is pretty hard; this app would be better suited to a touch screen. So I decided to make it into an Android app. The threshold to adoption is a bit higher than for the web; on the other hand, it’s far easier for me to set up in-app payments.
There are also many other changes under the hood; this is a complete rewrite. It seemed worth doing this now, because it’s setting me up to be more flexible and adaptable in the future. I’ll write more about the technology in a later post, but for now, here are the key points:
Tiles are PNG files, instead of custom vector-based strokes. This means I can implement fancier features on the client without the server having to know how to apply them; the client just sends updated tile images.
The server uses Redis instead of flat files. The file-based storage turned out to be too slow to be practical; even with the current relatively small data set, it takes tens of seconds for the server to load everything into memory. Redis should also scale better to multiple servers, if it should ever come to that.
The wire protocol is the newly released gRPC. This makes it flexible and extensible, while still remaining binary, lean and fast.
The Lean Startup method forces you to make your assumptions explicit, and to test them explicitly with well-designed experiments. With the upcoming Bigcanvas mobile app, I intend to test the following:
When discovering a free, no-signup, shared canvas app, some people will install it.
Technically, the cheapest way to test this would be to fake some screenshots, and submit an app to the Play Store that just shows those but does nothing else. But I might get banned from the Play Store if I tried. So let’s at least live up to the promise.
People will subsequently use the app, at least once, to draw something interesting.
For this, I will need some analytics. I’ll generate a random identifier for each install, and see how many seconds each user actually spends drawing (and moving around, and idling).
Seems modest? Sure. But if even these don’t hold, will need to make some serious changes to the core ideas. Fail fast, learn fast, adjust fast.
There’s too much in my head to cram into a single blog post. I’ll be writing separate posts about the following, in no particular order:
Note how 80% of that is about business, and only 20% about software development! Maybe I’ll be growing pointy hair soon…