On the eve of it’s 5th anniversary, I’ve decided to make the code for the kinopio-client app public. That means you can run Kinopio on your own computer, make changes, and share improvements.

kinopio-client on github

kinopio-client is the app that’s downloaded and run in your browser when you go to https://kinopio.club. It can save data locally, and to the kinopio-server.

Because the app weighs only ~220kb, in an alternate dimension where we didn’t have the Internet but had html, I’d ship kinopio to you on a single floppy disk. It wouldn’t even need to be high-density.

To be honest, opening up 5 years of private code does feel a bit intimate, like inviting someone over. I’ve cleaned the dishes and swept up, but … don’t look in that closest.

That said, compared to other commercial codebases, you might find it refreshingly straightforward. It’s just a node.js app and here’s the entire install process:

git clone https://github.com/pketh/kinopio-client.git
cd kinopio-client
npm install
npm install -g @vue/cli
npm install -g hostile
hostile set localhost kinopio.local

Then create an .env.local file containing VITE_PROD_SERVER=true.

And to run it:

npm run serve
https://kinopio.local:8080

Why Make Commercial app code public?

I’ve long been thinking about how to share the amount of work that goes into Kinopio. The more you know how something is made, the more you appreciate it – even more so when it’s a quality product built to last a lifetime.

But at the same time, making software isn’t like carving fountain pens or acoustic guitars. As much as I would like to sometimes, I don’t toil in meditative isolation until I’m ready to deliver the perfect timeless objet d’art.

By contrast, delivering software is more like delivering a gooey crying baby. It’s alive. Squirming, growing, and changing because the technologies it relies on do too. Physical materials rarely change, but web browsers, operating systems, and servers sure do.

The big benefit of public code for me is that it’s another way to share the work that goes into Kinopio. One more piece of the puzzle, in between diagnosing bug reports, discussing feature requests, and sharing updates on social media.

Some kind souls might contribute changes. But because Kinopio is such a complex interface-based app, I have no idea yet how often that’ll happen.

Risks?

Sharing the code for paid software carries some potential risks worth considering,

1. A counterfeiter could theoretically use the code to make a clone product. Commercial derivatives are prohibited by the license, but even if they ignore that, the forger would still have to reverse engineer their own kinopio-server. It’d be way easier to use an off-the-shelf infinite canvas library or tldraw instead.

2. Code contributions are appreciated, but having too many PRs to review can be very stressful. On paper, Kinopio is a one person operation, but I’m not really alone because I’ve got a community of users I trust that moderate discussions and answer questions when I’m not able to. As always, I’ll be relying on their help and generosity.

What Happens Next?

If you are interested in contributing, please by sure to read the contributor docs first. And just like in the discord and forums, there’s only one rule:

We’re all friends here, so let’s be cool, constructive, and always treat each other with respect.

Compared to a library or CLI tool, where new features and more options don’t really complicate basic usage, what the ‘correct’ thing to do for a GUI application is far fuzzier and subjective.

I’m looking forward to seeing what kind of activity takes place in the repo. Will I spend more time reviewing and less time coding? Maybe I’ll stream some live coding sessions?

With loving scrutiny,

– Pirijan, Kinopio Creator

Comments…

The latest release of Kinopio lets you work offline while in a subway, plane, or uncharted rainforest. When you come back online, your changes will be synced back up. And because the app no longer needs to wait for a network before loading, it starts up almost instantly.

Full offline support was the byproduct of building for speed and immediacy. From a multi-storage loading process, to a queue system to save grouped changes, and a UI status system to inform and reassure users – many separate systems come together to enable an experience that responds fast and works everywhere.

If you're curious, the overall architecture of Kinopio is described in How Kinopio is Made

Multi-Storage Loading for Speed and Truth

While running Kinopio, if you peek inside the Storage tab in your web inspector, you’ll see that each of your spaces is locally cached under a space-ID key with a stringified JSON value containing cards and other attributes that gets updated as you work.

This local-first approach is what enables new users to immediately start using the app without an account – because the best way to learn how to use Kinopio is by using Kinopio.

The kinopio-server enables editing your spaces on other devices, sharing public spaces, and real-time collaboration. In scenarios like these, the remote data on the server acts as the source of truth. But reading/writing remote data from servers is much slower than cached local data.

When loading a space, we can use both local and remote data together to get the best of both worlds, local speed and remote truth. The process goes something like this:

A helpful side-effect of this loading system is that when you’re offline, you’ll still be able to open your cached local spaces.

Grouped Updates Through an Operations Queue

In most apps there’s a 1:1 relationship between user actions and server routes. In a social media app when I write something and hit the Post button, my post is then saved to a server so that others can read it.

But in the case of Kinopio, items like cards and boxes which need to show updates in real-time as you interact with them, this means a new update on each keystroke when you type in them, and on each rendering frame while being dragged. But of course you can also paint-select multiple cards and move them around together, so potentially that’s >100s of updates a second.

If I was sending server requests for each update, even regular use would bang against the rate limit that exists to prevent the server from crashing.

Instead, all updates flow through centralized update methods which update: the local cache, app state, real-time broadcast stream, undo/redo history, and adds the update to the API operations queue so that multiple updates can be grouped together and sent to the server in a single request.

Especially worth noting is that operations currently in the queue are saved in localStorage, so if they fail the queue can be resumed later when connectivity improves.

Bringing It All Together with a UI Status System

Once you have systems that are local-first and resilient to connectivity issues, the actual loading the app offline part almost writes itself.

For offline loading, the vita-PWA build plugin generates a PWA manifest and service worker that instructs the browser to cache the app and its asset files locally. And when new releases are shipped, the browser updates its cache to the new version.

The last thing needed is to do is inform the user that Kinopio works offline and reassure them that their changes will be sync-ed up once they’re back online.

While offline, it might surprise users to learn that certain features aren’t available offline because they depend on the server, like global search. Those features display a little clickable offline info badge. Other features are more obviously not usable offline, like social or discovery feeds, which can just be hidden.

Essentially, I went through every dialog and button and decided whether I could either make it work offline, show an offline badge, or whether to hide it entirely.

Offline Is the New Luxury?

While using Kinopio offline to test features and write this post, I realized that working this way is a really nice way to concentrate even on my desktop computer.

I’ve never heard a productivity influencer say “hey just go offline sometimes”, but the offline web is here, it’s speedy, it’s the original focus mode.

Comments…

My earliest blog was pretty emo – totally what you’d expect from a teen of the 2000s. But what made it fun for me was the comments. New internet friends from around the world would comment on my posts and I’d comment on theirs. Before we knew it, we were a little community.

But for all the good times, comments come with the responsibility of guarding against spam and toxicity. In other words, it’s a job. But building our own communities is a job worth having in a world that’s noisier and spammier than ever.

On one side of the web, we have social media sites with engagement (i.e. outrage) driven feeds that keep us coming back. On the other, smaller sites and apps that are oases of calm in the storm – but which rarely give us a reason to return.

The good news is that it’s a lot easier to make an oasis engaging than it is to chill out at a nightmare mall. So maybe we can have it all?

How to Build a Comments System

Whoa wait, this might not be something you want to build yourself. I originally thought it’d take 2 days, but it took 2 weeks. Not just because I’m bad at estimates, but because my view of commenting was way too simple.

There was a time when this is how all early comment systems worked during those short-lived early days of trust and harmony on the web. But these days we need to also consider spam and toxicity.

Designing secure systems is easy. But designing slightly less secure systems that people actually want to use is way harder because you’ll have to choose the right tradeoffs for your specific goals.

As for my goals:

• Easy to use: as close to a classic commenting flow as possible; no sign up required
• Robust and timeless: This blog predates and will probably outlive most companies and their current authentication systems, so there is no “sign in with Google/Facebook/Github/X”
• A reason to come back: commenters can opt-in subscribe to email notifications of future comments on that post
• Reward trustworthy commenters: repeat commenters and those with kinopio accounts will get little badges
• Enjoyable details: commenter info (name, website, etc.) is saved so you don’t have to retype it next time. In-progress comments are backed-up as you type so if your browser crashes you won’t lose any work.
• Spam resistant: first time comments need to be approved, and all new comments are reviewed. More details on how moderation works below.

So here’s what the commenting system looks like now,

⏰ And lastly, every 2 hours the server checks to see if there are any new comments. If so, an email is sent to the subscribed commenters on that post.

If you’re looking for an easy alternative, I hear commento is pretty good. The reason I didn’t use it is because its sign in model didn’t fit with my goals. But also because it’s been years since I’ve been able to code just for fun – so I guess this was like a holiday gift to myself.

I hope this inspires you to add comments to your own blog. I had to leave out a lot of details to keep this readable so if you have any questions… leave a comment! ＿φ( °-°)/

Comments…

A couple days ago I was emailed by Pema about her thesis paper,

I’m studying the impact of digital productivity tools on the user psyche, the concept of digital gardens, and technology designed for reflection. Naturally, a lot of Fog Creek Software’s work came up and I’ve been following your work on Kinopio! I’m fascinated by its evolution and would love if you could answer questions on your philosophy on task management, digital productivity tools, and your intentions with Kinopio!

I thought you might be curious about some of these questions too, so here goes:

Question 1

Why did you make Kinopio, a tool not to manage/optimize tasks, but one for brainstorming and reflection? What were the intended outcomes for users when using a tool that “works the way your mind works”?

The idea originally came from my use of design tools like Sketch. When making mockups for work, I noticed that I was using the text tool to figure out the why and the how behind what I was doing. Unlike writing in a linear document, it felt really creatively free-ing and I wanted to bring a better version of that experience to everyone else.

The more I learned about the field, the more I understood why writing this way felt so right. We’re spatial creatures, with brains designed to associate feelings and thoughts with places and landmarks.

It’s a little depressing that these days we mainly use computers to consume fast and react fast. Task management turns us into more productive human machines. Rather conveniently for managers, human machines have higher predictability and lower inherent value – they’re easy to automate, replace, and erase.

Productivity is important, but it’s just one piece of a bigger world. The history of computing, from WordStar, to KidPix, to HyperCard, to HTML, is the history of creative software designed primarily to help us understand and express ourselves.

Question 2

I see that Kinopio has 5 design principles, unique from the mainstream software landscape. Why this philosophy in general?

The principles behind Kinopio are a reaction to seeing the results of the opposite ideology in previous workplaces. It wasn’t explicitly stated, but if I had to describe the average software company’s lived philosophy, it would look something like:

1. Go big, or go home
2. Low-friction above all else
3. Design for the lowest common denominator
4. Many teams, in many silos
5. No time for refinement, this will be someone else's problem

This philosophy is ironclad but never explicitly declared, because it’s never questioned. Most leaders just assume that’s just how things are, or need to be.

When you’re on the inside, each of these on it’s own sounds reasonable. But taken too far, without nuance, and without an understanding of why, eventually leads products to enshittification.

Question 3

The ‘clean’, minimal experience is a design principle in UI UX today… You reject this in Kinopio. How does this affect the user? Are there other UI UX principles of design you do not subscribe to?

Our inspiration shapes what we build. If all you see is clean minimal product design, then you’ll inevitably make the same. I think that’s why art schools teach art history in year 1, because knowing the varied history and styles of your medium – software included – really helps expand your perspective of what’s possible, interesting, and cool.

Minimalism as an art-style is a pretty tight leash. But if you think of ‘less’ as merely one of many possible techniques used to not overwhelm or confuse users, then you’re in the right place to ask yourself questions like Why is this confusing? From there, maybe you can use other techniques like contextual relevance, or a more intuitive layout, to make important options less confusing, instead of hiding them.

I like to think of Kinopio as a professional tool, like a keyboard synthesizer, or a race car. If you were going 200mph would you rather find your controls inside a clean/minimal/aesthetic menu, or just hit some upfront buttons and dials?

Question 4

Your third principle emphasizes the power of plain text for the user. What are your thoughts on empowering users through Kinopio? What is Kinopio’s relationship to its user?

There’s billions of people on earth, and provided you don’t owe your investors millions of dollars, the software we make doesn’t have to cater to the lowest-common-denominator. For both users and designers, products that are made for a specific group of passionate people can feel like a glass of ice water in a desert. This requires me to be deeply connected to the community in order to understand their needs – and for them to understand mine as well.

To use another physical example, Leica cameras cost way more than their competition and don’t take better photos. But Leica is able to thrive by building cameras with a more opinionated manual-focus-only shooting experience because there are enough photography enthusiasts out there who appreciate the result of those opinions.

Question 5

Can you describe any unexpected outcomes or challenges that arose from developing Kinopio? Were there any unanticipated user behaviors or outcomes?

To be honest, I didn’t expect it to be this hard. To make the business sustainable there’s many new skills like marketing, and being on camera, that I have to get a lot better at.

But having to wear so many hats, you also start to notice patterns. Like the deep anxiety that comes before trying something new, then being okay with sucking at it, and then maybe one day being pretty good at it.

Question 6

How did you measure the success or effectiveness of Kinopio?

📈 The quantitative measures I use are basic things like unique page views, and the revenue numbers reported to me by Stripe. The subjective bits are things like how many people are editing public spaces Live right now, adding their spaces to Explore, or hanging out in the Discord.

Question 7

Have you found any patterns or insights regarding user behavior and psychology through the data collected by your tool? How do you use this information to continuously improve the user experience and provide more effective features?

I don’t perform any analysis of user data so everything I know about users I get anecdotally, and through the feedback I get from sharing works-in-progress. But because I’m building Kinopio as much for myself to use as for others, I’ve got no shortage of features to build, and ideas on how to refine the user experience.

Question 8

Did you encounter any ethical dilemmas during the development process? How did you approach and address those dilemmas while still meeting the intended goals of the tool?

The only thing I can think of is related to funding. It’s something I’ve been approached by investors about in the past, and while I’m grateful to anyone who sees potential in Kinopio, this also led me to come up with the term Organic Software to describe why I’m wary about the long-term ramifications of taking traditional VC.

Question 9

How do you envision the tool evolving to better support users in their personal and professional growth?

Like any kind of growth, it’s a slow, continual process. I have some big feature ideas, and a lot of little quality-of-life improvements. I also have ideas on how to make the community feel like even more of a community. And I also know I need to try new things to get the word out to more people about Kinopio.

It’s all a journey I guess~

Comments…