Most software is annoying to use. Opening a news article to read 500 words should be instant but takes entire seconds. Try to make a quick update to a Google Doc and you’re waiting even longer before you can type. Hopefully you don’t have to use Jira or Photoshop.
I thought computers were supposed to be nicer than they were in the 90s.
Grizzled vets say that the good times make us weak. That because we have powerful hardware, modern software is built on top of a bewildering goop of high-level languages, frameworks, and dependencies on dependencies that make even simple things sluggish.
It’s a compelling argument. As craftspeople, we just need to not be lazy, get our shit together, and then we can make nice things.
ヽ(´□｀。)ﾉ
But I think self-flagellation is missing the forest for the trees.
As an industry, we’ve moved from putting engineering innovation and efficiency first, towards prioritizing usability and market-fit. I’m not mad at that. Computers exist to help humans do new things, they should be bicycles for the mind and all that good stuff. But there’s nothing stopping software from being useful and elegantly made.
I mean, except for the way most software companies are organized.
Most company structures are based on the Roman empire military. CEO Caesar says he wants something, and the lieutenant managers below him on the org chart break it down into smaller tasks for the soldiers to accomplish.
On a development team, programmers are the soldiers of these shitty new armies. They open their Jira issues and add whatever feature it says to add, or fix what it says to fix. If I can save time by adding another dependency, or skip a meeting by implementing a mockup exactly as designed, why should I care?
Some people care. Those people suffer:
I now spend 1/4 of my work week fighting dependency hell (after just about each addition of a new package by any other developer on the project), another 1/4 figuring out how the “latest and greatest” tool of the week is best used to do something that would normally take me 5 minutes to do custom (god forbid, not the C-word!), and the remaining half is spent maybe doing actual work. So incredibly frustrating that I’ve just about had it.
I’ve grown to loathe and hate that which I used to adore. (Source)
Building software is nothing like organizing armies in 100 BC. In 2020, we can communicate instantly, victory is ambiguous, and there’s less murder. But most importantly, we’re not conquesting, we’re creating.
Creation moves differently
To illustrate this, let’s talk about Super Mario 64, the landmark 1996 game that used an unusual new technology: 3D graphics. You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes.
Building like this is never a straight line. Ideas and code get left on the cutting room floor because part of innovation is questioning whether what you made should exist. The process is cyclical and iterative, looking something like:
Good software comes from a vision, combined with conversations not commandments. In a craft-focused environment, care for efficiency, simplicity, and details really do matter. I didn’t leave my last job just because I wanted to make something new. I left because I wanted to make it in a way I could be proud of.
So here’s what’s up, I’m working on my own right now, in a race between my diminishing savings and my typing fingers. But I’m not stressing too much. I’ve got a lot of work to do, but people seem to like what I’m making. Maybe one day though, it won’t just be me. When that happens I’d love to build a small company/collective/thing that’s the best place for creators to work.
Special thanks to Michelle and Hao for helping edit this.
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.
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}