Over the last couple months, it’s been super encouraging to hear from teachers, programmers, designers, and students about how they use Kinopio to map out and make sense of their ideas, feelings, and plans.
Probably a cat
Right now I’m working on features to make it easier to share and collaborate with other people on those spaces. But I’m taking a little break to answer some questions that really deserve public answers.
How Will Kinopio Make Money?
My plan is to eventually require people to pay $4/month to create more than 100 or so cards. I want the pricing to feel simple, straightforward, and obvious.
What About User Data and Privacy?
I haven’t written a legalese privacy policy yet. But either way, here’s the common sense human version.
Kinopio won’t show you ads of any kind.
No cookies are used for anything. LocalStorage is used to save your info. Unlike cookies, other websites cannot access localStorage.
To share spaces and collaborate, your user data and spaces will be hosted on AWS (via Heroku). Besides this necessity, your data will not be shared with any third party.
The only analytics I use are from Netlify. Which does not allow me to uniquely identify anyone.
Children, and anyone else, will always be able to use Kinopio anonymously and collaborate with others on public spaces.
You can permanently remove all of your data anytime.
What Happens to My Data if Kinopio Dies?
We don’t live in a deterministic world. I could do everything right and still run out of money without being able to turn Kinopio into a healthy, sustainable business. If that happens, you won’t lose any data and Kinopio will still be usable.
Kinopio consists of two codebases, the client app that runs when you hit kinopio.club and the server app which will enable sharing and collaboration. The client app is like a cockroach, it’s tiny, free to host, and doesn’t depend on a connection to the server app. So if I can’t afford to run the kinopio server anymore, I can just switch it off and you can continue to use Kinopio as you do now – with all your data intact.
Besides all that, there’s already a bunch of ways to export your data. Either as entire spaces, or just the specific cards you care about.
It’s been ~3 months since I quit Glitch. From outside the city, amidst community gardens, fireflies, and lazing cats, I want to tell you what I’ve been working on.
Get the chaotic messy thoughts and ideas out of your head
Show you how they’re connected
Help you figure out what they mean, and how to start working on them
Instead of neatly structured forms and lists like a traditional planning tool, Kinopio works like your brain does. The best way to explain that is with a little tour of kinopio.club:
Tap anywhere to make a new card. Put an idea, thought, or feeling in it. It doesn’t need to make sense right now. Make some more, wherever you want. Drag cards to move them with a jolly wiggle.
Get your feelings out
By now some of these ideas might be connected – so let’s connect them by dragging from one card connector to another.
Connect your thoughts
Connections can also be tapped on to edit their color and type, among other things.
Edit connections
You’ve got the gist!
I made Kinopio for people who have ideas, feelings, or thoughts they’re struggling to express, organize, and understand. I used it to plan out this blog post [screenshot].
It also works great on phones and tablets.
Coming soon, I’ll be adding collaboration features that’ll let you whiteboard with a team, and better connect what you’re doing to why you’re doing it.
Here’s one more thing. You can use your art skills to manipulate multiple cards at once. Paint over them, and a menu of multi-card options will appear. You can also drag multiple cards around together too.
DanielX and I originally pitched Glitch in 2015 after a CreekWeek aimed at figuring out what FogCreek should make after Fogbugz, Trello, and Stack Overflow.
The original prototype was based on a client-only text editor that stored and published project files on Github Pages. DanielX developed it to build client apps which acted as small iframes that communicated with each other over postMessage to make a larger app, kinda hypercard-y. You can still try it out at http://strd6.github.io/editor/
Our pitch presentation and mockups sold the company on how the editor could be expanded into a professional tool for collaborative “web development without the trash parts”.
^ original design concept, looking p gross
Before we started building for real reals, Joel and MHP had us walk write up a list of Product Principles that would help define what we thought Glitch should be and what it shouldn’t. Basically:
We're in Beta until we are
- The easiest, fastest way to go from code to URL
- Enjoyable to use
- A Fluid Shared experience
- Aggressively Lazy (does less to mean more)
- Safe and Reliable
It might be hard to imagine now, but it was a very controversial project. Internally, a couple people thought it would flop because
It was too simple for ‘real’ devs, and too advanced for ‘regular’ people
They saw the UI of Glitch as just window dressing, that behind the pretty face we weren’t doing anything noteworthy and that it was “trivially copyable”
What’s the core value prop? Couldn’t I just use my more powerful local text-editor and deploy my apps myself?
I still sometimes refer back to Joel's response on that long email thread (expand to read)
Every time you make something a little bit easier to do, the number of people who do it explodes.
The way to make things easier to do is to make them simpler, with fewer options.
We've seen this with the evolution from Content Management Systems to blogging to Facebook and Twitter where you "blog" one sentence at a time to Tumblr and Pinterest where you "blog" by clicking one button. Each evolution resulted in 10x audiences for a much, much simpler feature. 2000 people used Vignette, 10,000,000 people used Blogger and 1,000,000,000 people use Facebook.
We also saw this the evolution from Windows/Mac desktop metaphors to iPhone. There appeared to be a great loss of functionality in the jump from Desktop to iPhones, (you can only show one thing on the screen at once, and you lost the ability to control your own files), but the usage exploded because it was so much easier for normal people. And eventually, developers figured out how to give you the features you really need in a simpler interface.
Make things 10% easier and you make the number of people who can do them double. Do that a few times and you can build a mass audience.
We've done this for "blogging" and self-expression, we've done this for computers in general, what's left?
As it turns out, we happen to work in a domain full of nerdy people who friggin' LOVE TO MAKE THINGS COMPLICATED. Maybe we're nerds so we don't notice.
And in that domain, the domain of programming, things are getting much much worse, not easier.
Example: From RCS - cvs - svn - Hg - git, every version control system added a new twist that made it harder to understand than the previous generation. Developers love to add features (like the git index) that give you more flexibility in theory but make everything harder to understand.
When faced with any technical tradeoff, developers' only design skill is to add a command line switch.
So now everybody in the world has to learn BOTH ferkakta ways of doing something which should have just been a simple one step process.
Everything I've looked at in the domain of programming has gotten stupidly more complicated every year when it should be getting simpler, because there doesn't appear to be a single programmer who doesn't love to make command line switches and complicated options. FFS, have you seen C++ lately? I couldn't understand it all in 1996, and I have a huge brain. Now I could not imagine anyone who is smart enough to understand the language and all its features well enough to use it without accidentally causing a nuclear war.
There was only one incident in the history of programming where a programming environment was built that stripped away unnecessary options WITHOUT removing any of the basic expressive flexibility of programming, and that was the original Visual Basic 1.0.
(Maybe Java 1.0, but that didn't last long).
The point about VB 1.0 is that you could build any Windows application. You weren't limited to stupid or ugly Windows applications. You could build REAL Windows applications, and you could do it with, say, three lines of BASIC code instead of 47 lines of C code.
And the REAL PROGRAMMERS (TM) laughed because it was BASIC and therefore "beneath their dignity" but at its peak Visual Basic was 2/3rds of all compilers sold. (people used to buy compilers) and 90% of the people who had occasion to program computers said that they would be willing to use BASIC.
Where does [Glitch] come in? There are, it turns out, a lot of stupid crufty complications in programming today that are unnecessary and obsolete, and if you get rid of all those complications and options you can make a much, much simpler programming environment WITHOUT removing any flexibility in what you can create.
For example, git is WAY too powerful. Probably 75% of developers are working alone and all they need is a way to go back when they make mistakes. This feature can be provided COMPLETELY AUTOMATICALLY with no user interface. So 75% of developers just need time machine for their code and they're happier than they would be with git.
If you give people the ability to work on the same code with a friend at another computer, Google Docs style, where you can both edit any document, you cover 10% more of the developers.
If you give them a simple way to make very basic feature branches, well now you're up to 95% of all developers needs being met with a user interface that is MILLIONS of times easier to use than git.
Most developers don't need make files or ant or build tools. They just want everything built always. If they have written tests, they want all tests to run all the time. So why even give them a button to run tests? Run everything always and don't deploy until all tests pass. When all tests pass, deploy automatically. That's all. Now all I have to know as a programmer is that if my tests pass, the code is on the server.
So this is the idea of [Glitch]. Get rid of all the nonsense around programming which doesn't matter. Focus first on the 90% of people who would be programming if it wasn't so unnecessarily tedious. Hide all that baloney about branches and deployments and editors and how you get your code to a URL and hide every detail about hosting except where you hook up your amazon/paypal/appleID to pay for it.
This is NOT squarespace. Squarespace is a GUI website builder. GUI tools always limit what you can do, because they don't map perfectly to HTML and CSS. They're clunky and never really win in the marketplace. We're giving you a real programming language (JavaScript, HTML, CSS) and we'll let you turn on things like node and angular. Our goal is not to reinvent programming languages because a lot of people have tried that and it doesn't always go so well. Our goal is just to eliminate the yak-shaving nonsense it takes to get code you just wrote to run.
How do we make money? Just like github. It's free for open source, paid for closed source.
For the first couple of years, Github and Atlassian ignore it, because it's too simple. It's like a toy joke and they don't even understand what it is.
On year three, they start to think "hm we need a [Glitch] competitor", so they start to design GitHub Jira Lite which is awful and nobody uses.
On year five, they realize that they have been completely outflanked. Yes, the y-combinator kids doing startups and the Tesla engineers writing code for self-driving cars are still using PROFESSIONAL tools. But everybody else is using [Glitch] because it's just really simple.
Joel
The Editor
After that, the grind gets mad blurry. Every week I gave demos to the company, and every week they crashed almost immediately.
The visual design of Glitch evolved piece by piece over time, as we sorted out our principles, we also sorted out our influences and what we were trying to say aesthetically. As I added new interface elements, I’d tweak or rewrite the older parts to fit. It was a lot of trial and error, and tweaking, and feeling.
Some Experiments and Snapshots,
Back then the files were seperated by back/front-end based on some folder name logic. The idea was that the editor mirrored the traditional seperation of concerns between back-end and front-end devs. Instead of just all files, it’d present things in the context of who it mattered to or what headspace you were in.
The original ‘About’ pop-over
An idea I for improving the socialness of the editor, when a new user joins a project a random greeting will appear next to them for a few seconds. The user can also customize their greeting if they want.
The original ‘new-project’ pop-over. We kept it simple because we didn’t want people going off in to a rabbit hole to research what framework or starting point was best.
Eventually, the editor evolved into the friendly, approachable version of Glitch that most people know.
Community
Once it started to actually work, we started getting a couple cool apps built internally and by others. To show them off I built the first version of the community site, a simple static site which you can still access at https://original-community-site.glitch.me
Later, I added curated categories to the second version , and the design slowly started to evolve
The third version I built is still the core of the current design. It added data models, user pages and other dynamic stuff. This was also the first time I worked with an outside illustrator on something, and it turned out rad.
It included the copy I’m most proud of writing
Meeting Anil
In the early days, FogCreek didn’t have a CEO. Instead it had a council of elders (really) who kept trying to ‘manage’ our small team of 2-3. It came off more like meddling by people who felt we needed ‘adult’ supervision so we mostly ignored them, checked-in-with Joel occasionally, and kept doing our own thing.
A year before he started, Anil popped by the office to see Glitch firsthand. I had no idea that he was planning to be CEO, but I was hyped to discuss it as a fan of his series on The Web We Lost. Here are my notes from that meeting. I’m still trash at stuff like messaging so hearing his thoughts on how he’d present it to the world was real inspiring. (At the time, it was assumed we’d eventually do the whole big TechCrunch conference presentation like Trello did).
That might also have been where I settled on using the word ‘Remix’ instead of more technical alternatives.
After Anil joined we went from HyperDev → Gomix → Glitch (the name we’d originally wanted). And from hummingbird to fish. With the launch of Glitch, we also put the community first – both technically, glitch.com now loaded the community site instead of the editor, and culturally as an internal priority with it’s own team.
Other Stuff
The original /about page. we explained things more dork-ily back then
The original illustration kit I drew for marketing
There’s way more things I could talk about but this is already crazy long.
All the drawings in this post were drawn this year by cool people using a tool I made. That’s a really awesome Feeling.
Speaking of Frog Feels, it’s in a really good place. Some real masterpieces were made. And in a small, gentle way a new community was created on the internet.
I start most of the weekly emails with a heartfelt personal newsletter of sorts,
# Frog Feels Issue #69
Hey Frog Friends,
We missed 25 and 50, but I feel like I should write something special for our first 69.
It was weird at first, but now this is just something we do every week. I think we fit together really well.
Also, I started a comedy podcast with my good good friend Michelle! I went from knowing nothing about audio and cringing at the sound of my own voice, to learning a lot about MIDI controllers, how DAWs work (❤️ Ableton), and audio producing. The responses I’ve gotten from people IRL have been dope, my voice is alright after all.
In other news, I made a couple other not-so-successful code projects this year too. The premise of Goodgoods.biz was supposed to be that I’d draw and animate something for each episode. But I got bored of doing it, and apparently css animating too many things destroys your cpu, good for warming up your room though.
From it’s ashes I wrote pirijan.com, and it’s collaborative drawing background, which people seemed to like. I’m drawn to mysterious interfaces that intrigue and surprise, so this was a chance to do me.
I also spent 2 weeks in France 🇫🇷. I hadn’t been there since I was 8 and I had a real good time re-exploring it. If I paid more attention in my high school french class I would’ve liked it even more. Unsurprisingly, the city was beautiful, I’ve got a lot of images that’ll stay with me.
This year of Glitch was a real rollercoaster. It’s good to see that it’s really picking up, people also seem to appreciate the work I’ve put into it’s interface and style, and I’m pretty confident about it’s future success. But also it’s getting more stressful, less fun to work on as the need for features pile up on both the editor and community site applications – which I design and write most of the code for. It’s crunch time, always be crunching.
The best part of the year was the two weeks I spent in San Diego and LA. California made a real impression on me to the extent that I almost moved there. LA is where all my favorite things are now, the best planetarium, the hollywood hills, venice beach, palm trees, chill vibez.
The only thing that stopped me this time was my work VISA, but I’m sure it’s a hurdle I can get around soon. Also I like driving, but there’s a chance I might regret saying that.
Kinopio
I still sometimes refer back to Joel's response on that long email thread (expand to read)
![[screenshot]](/images/2019/screenshot-blog-planning-kinopio.png){kind=link}