If you visit the rich parts of Paris, it’s a beautiful place. I fondly recall narrow cobble-stone streets, road-side cafés, funky french cars, homes, shops, and chapels each more ornate and gracefully detailed than the last.
Coming from a suburb designed by bean-counters and losers, I imagined that I’d be endlessly inspired by Paris, by New York, by wherever. But inevitably, the opulence, the architecture, the tradition, it all blends together.
I’m glad I travelled to all these places. Everyone should see more of everything.
That said, every journey inevitably leads me back to my ever-growing collection of charming, beautiful, and peculiar jpeg’s.
I started my personal inspiration library in 2010, saving cool images from the world wide web, and snapping photos from architecture and illustration books.
Like pruning a bonsai, sometimes I remove things that no longer resonate. What lives on are perennially interesting and memorable. The oldest branches evoke vibes and eras that I think are worth remembering and learning from.
I didn’t have a plan behind it, besides striving to express myself by combining and imitating the things I liked. I definitely didn’t think I’d be scrolling through these images a decade later.
At first I threw everything into a folder. Then I moved everything to LittleSnapper (now abandoned), then later onto the web with Are.na. Today, the collection lives in this Kinopio space.
I visit this space often. Sometimes to wander and wonder, other times to gather ideas for something new.
One of my original Kinopio references – nestled alongside drawings of nature with bright colors, and ’80s digital synthesizers with chunky buttons and sliders – is this gig poster:
You might be able to see the Connection
Maybe one day I’ll make something charming-enough, beautiful-enough, and peculiar-enough to be in someone else’s collection.
Bonus
I found this comic while going through some my old inspiration, it probably inspired the Kinopio logo.
You’ve probably heard, or lived, a story that goes like this…
I’m tired of technology. I’m leaving to do something real like sculpt clay, work wood, herd sheep, and grow vegetables.
But making software that runs fast, efficiently, and reliably is it’s own kind of craft, tangible in its own way. But, to do any kind of craft you have to understand the materials of your medium, how they bend, and how to work together.
Making an aircraft engine requires an understanding of the tolerances and capabilities of different metals, airflow and combustion. Not that I know anything about all that – our engine is made of state, localStorage, API, and websockets.
Porco Rosso
But First, the Two Kinopio Apps
kinopio-client is a Vue.js app that weighs 150 KB. When you go to https://kinopio.club, it’s downloaded and run in your browser. This is the only part of Kinopio you use if you don’t have an account.
kinopio-server is a Node.js app that runs on a server out in the world. If you’re signed in, it saves your data to a database so that you can share, collaborate, and access your spaces on other devices.
Speed first, perfect later. You shouldn’t need to wait for server requests to complete before editing your spaces. Because fast software is the best software.
Favor easy maintenance. To help you sleep at night choose open technologies that are widely supported and well documented.
Building a foundation for decades. This mindset encourages me to write small, simple code that is easy to re-read in the future. If I’m adding a third-party library to Kinopio, that’s now a commitment over years so I’m motivated to really know what I’m adding – and maybe write it myself instead if that’s the smaller and faster option.
The Four Elemental Web Technologies
State
State is your current space and user data, which informs the display of elements on the page. E.g. my user.name = 'Pirijan' and my user.color = 'cyan'. Kinopio uses Vue.js/Vuex to bind data to elements on the page. So when you change your user.color, everything that references that user’s color updates.
Data-binding makes apps feel alive and organic
State is not persistent though, unless it’s saved somewhere it’ll be lost the next time you refresh.
LocalStorage
LocalStorage is 2-5 MBs of key-value data that every website gets to save on your device. Unlike cookies, localStorage data can only be accessed by the URL that created it which means it’s secure and can’t be used for user tracking and other shady shit.
Here’s a secret, by stringifying JSON objects you can save any kind of data structure to it. LocalStorage is fragile though, you can accidentally wipe it out by clearing your browser cache.
API and Database
The Kinopio API is used to GET and POST(save) data to the database so that you can edit your spaces on other devices. Getting data from servers is much slower than getting data from your localStorage, because of the round-trip and because every request needs to be privacy authorized.
Kinopio API Docs are also public so that developers can make custom integrations and tools
Websockets
Websockets create that magical collaboration feeling by enabling a real-time stream of messages to be sent and received by a client, e.g. Pirijan moved cardId ABC123 to position {x: 100, y: 200}. These messages are relayed by the server to collaborators whose space state is updated. e.g. updating the position of the card.
Websocket connections must be actively kept alive with a ‘heartbeat’ exchange. If you go afk for a while, like to make a coffee or something, reconnecting to the stream takes a couple seconds.
When you load Kinopio for the first time, your state is created and saved to localStorage so it can be restored. When you update your state by editing cards or connections, localStorage is also updated. Once you sign up, updates also save to the API.
Once you start using Kinopio on other devices, the localStorage on your phone might be ahead of the one on your computer.
To be fast, Kinopio first restores state from possibly outdated localStorage. Once the latest server data is downloaded, the state is re-restored.
While the space is downloading from the server, edits you make are saved and then applied on top of the server copy.
Edits you make to your space while the server data is downloading are recorded and applied to it
Websockets only stream relayed updates to connected collaborators and spectators. You might be wondering, why don’t you just update the database with websockets instead of relatively slow API requests?
The problem with saving data with websockets is that they’re too fast. Authenticating that many messages per second and writing them to disk would be really inefficient. E.g. If you’re moving a card from position x: 20 to x: 420, Kinopio will use websockets to broadcast many updates during the move: moving card x to 21, moving card x to 24, moving card x to 28… potentially hundreds of messages. Or you could send a single API request after you’ve moved the card, PATCH card.x = 420.
Building fast, easy to maintain software that’ll hopefully last for decades means understanding and using the right technology for the right job. It’s its own kind of craft, in its own kind of way.
It sounds obvious that software isn’t like real world objects, it has no inherent gravity, softness, or squeeze-ability. But it does have its own kind of shape and weight.
That shape comes from helping you do what you can’t in the physical world. Great software responds with the enthusiasm of a puppy on a road trip, you build up a rapport with it, and it becomes an extension of your mind.
Software designed to replicate a physical experience will always suck because it replaces the tactility of the real-world with conceptual baggage that doesn’t fit the medium. Trying to be a whiteboard, for example, means putting a lot of fiddly questions in front of what you want to do:
Do you want to add a note or a comment? Is this text or a photo? What color should the note be? Do you want the font to look like handwriting? Should it be square or circle?
And … I’ve forgotten what I wanted to say. Clippy never left – he just got low.
Kinopio is software designed to be software. The entire interface revolves around creating and connecting small atomic units of knowledge that happen to be in the shape of cards.
Just like life, everything’s simpler when we’re not pretending to be something we’re not. Same goes for interfaces. In Kinopio, thoughts, feelings, ideas, or comments – everything is just a card. Click, type, and connect.
There are, of course, fancy options like card frames and checkboxes, but it’s all secondary to creating. Thinking tools have a timeless good feel when their primary interaction is creation.
Text as Text
My earliest mockups of creating cards imposed a lot of structure like status, custom fields and comments.
I built the first version with just a single textarea because it was the simple, iterative thing to do. But right away, it was obvious that a single field was calmer, inviting, and creatively expressive.
Turns out, you can do a lot with just a textarea. If you want to add a link, paste it in. If you want to comment, make a card and connect it. If you want a checkbox, prepend []:
Software is a conversation between you and a computer. Conversations are better when they’re chill.
A Short Update
It’s been a year or so since I started Kinopio. Encouragingly, I learned that I wasn’t that only one with fragile ideas to plant and grow, or thorny problems to think through.
But building a visual thinking tool for new ideas and hard problems still feels like an experiment. Can software created by one person succeed against corporations with hundreds of people and millions of dollars? Kinopio is an experiment in trust, transparency, and in people over institutions.
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.
Kinopio
