#8 – Pirijan Ketheswaran: Kinopio, Canvas-based tools, being a solo developer

I think another way to frame that is with the idea of resiliency. When Kinopio first launched, it was like front page of Hacker News for a little while. A hundred thousand people visited it like pretty fast, but because the server didn't even know about them, cause they were mostly checking it out in their browser. Like nothing went wrong. I barely noticed, because I didn't have to worry about like, Hey, now there's 100, 000 accounts.

And now my database is like inflated or, now my server's on fire. Welcome to the Local-First FM podcast. I'm your host, Johan Schickling, and I'm a web developer, a startup founder, and love the craft of software engineering. For the past few years, I've been on a journey to build a modern, high quality music app using web technologies. And in doing so, I've been falling down the rabbit hole of Local-First software. This podcast is your invitation to join me on that journey.

In this episode, I'm speaking to Pirijan Ketheswaran, the creator of Kinopio, a playful canvas-based tool for thought. He's also the co creator of the online IDE Glitch. In this conversation, we talk about his journey as a creative, including his time at Fog Creek and later building Kinopio as a solo developer. Before getting started, also a big thank you to Expo and Crab Nebula for supporting this podcast. And now my interview with Pirijan. Hey Pirijan, nice to meet you.

Thank you so much for coming on the show. How are you doing? Hey, thanks for having me. I'm doing quite well. So for those of us who don't know you, could you give a quick background? Sure. Yeah. So my name's Pirijan. Uh, I'm the creator and mostly sole developer and designer of Kinopio. club, uh, a mind mapping and creative thinking tool. Uh, but before that I worked at Fog Creek, um, and. Uh, specifically, uh, at a time where the Trello office was there and Stack Overflow had just spun out.

And I eventually went on to co create Glitch. com, the, uh, web editing development environment. Uh, that's just a cool community of building apps.

That sounds fascinating. So, Maybe some of us have heard of Trello and Stack Overflow, or certainly have heard of those, but maybe not quite about Fog Creek. So I think that's quite a long journey, but could you give a bit more background on Fog Creek and the really monumental projects that came out of it? Yeah, so Fog Creek, as I understand it, was founded by Joel Sposky and Michael Pryor, way back when, a long time ago, in New York City.

Their premise was, let's make the best place for programmers to work, which was a wild and crazy concept at the time. And from there, um, Fog Creek kind of acted as an incubator. So they developed Stack Overflow and they, let's see, I'm trying to remember the timeline here, but, um, eventually Stack Overflow got really big and they moved to a slightly different building in the New York financial district.

And Trello grew the same way and for a long time shared the office with Fog Creek and Fog Creek would develop its own bug tracker which kind of they used to fund the development of new projects and the third project that was being developed after Trello was Glitch. So how did you find your way to Fog Creek and what led you to work on Glitch? Oh, wow. Okay. So it actually kind of came from a couple of jobs I've been working at previously.

So I went to school actually for biology and urban planning. And while as an urban planner, I kind of got into a love for map making and visualizations and illustration. And that kind of led me to a job in tech where I started as an illustrator, then became a designer and then became a developer. To build things that I designed, it's kind of a trial by fire.

But in all those jobs, the other thing that was new to me was using a bug tracker and a lot of the companies that I worked for, uh, used Fog Bugs, the Fog Creek bug tracker, and it wasn't the greatest product and it kind of inspired me. To like want to make a better version, like as a designer first, I kind of came up with concepts and new ideas. Like how could Fog Bugs work if it was designed around more of a human workflow as opposed to more of a managerial one.

And so I put a lot of those mock ups up on Dribbble when Dribbble was a thing. And the leadership from Fog Creek saw it, uh, flew me over to New York and asked me if I wanted to work there and eventually that's what I did. That sounds amazing. So yeah, tell me a bit more about like how Glitch then came to be and how it took shape. And I think you also shared some of the design principles that you arrived at for, for Glitch on a great blog post that we'll also link in the show notes.

So I'm curious to learn more about that. Sure. Yeah. So, so at the time they had Trello and Stack Overflow, and both were really big successes. Now Trello was still independent, so it wasn't bought by Atlassian at the time and was also on its way to be a really big success. And the company leadership wanted to figure out what they were going to do next. What would be their third big thing?

So what they did was they held what they called a Creek Week, which was a couple of people who were interested, could independently arrange teams and come up with like ideas of what we should work on. And there were some pretty good ideas. But the one that eventually went out was the one by me and Daniel X that became Glitch. It was a web development interface where you didn't have to download an ID or set up a server. Or, you know, figure out how Git works or anything like that.

You just start typing and you have a real Node. js app at your fingertips immediately. And so, yeah, like over time, we sort of, every week we build it a little bit more and demo it to leadership and every week it would crash. And then one day they were just like, Hey, what if we added.

real time collaboration to this and so that's what we did and that's what it has and you know like it started as like this project where we were working really closely with Joel and then eventually the rest of the company as the team opened up and yeah it eventually grew to subsume so unfortunately, um, Fog Creek is like pretty much dead as a company. Glitch, it kind of got renamed to Glitch and then Glitch was bought.

Well, as they say, all good things come to an end, but it's, it's been a phenomenal product. And I think it had just such a distinct vibe and visual aesthetic and feel to it, particularly at a time when I remember like a lot of products just kind of felt the same, like spoke the same, imitated the same design language. And Glitch really like, not just the name stood out, but the visuals, like the feel of it, all of it stood out.

So I'm curious, like, what was the inspiration for that and what was the goal for that? Yeah. Glitch was actually a really interesting project. I mean, I guess in a lot of ways it was a dream project because you get to make a product from the beginning, kind of help define the team and you're doing so like without having to worry about money, which is like pretty amazing. The big bet on Glitch was that. There's a middle market of developers.

So everybody knows there's the pro developer who's like, I am on Vim all day. I can SSH into whatever, and I'm super great. And then there's the beginner side, which is like, Hey, I'm learning MIT scratch.

I'm, I'm doing like, like tutorials on how to make like, you know, like a really simple to do list, but then we thought there's this big kind of in the middle of these two developer markets where people want to code with real code, not like, you know, building blocks and abstractions, but they also kind of are kind of turned off by a lot of the configuration like they could do it, but it's kind of like a pain.

And if they want to make, like, a small project or try stuff out, it's kind of beneath them. And so that was our bet. And so, like, we thought, okay, this is going to be like a different. market of developers, they're going to have a different vibe, let's say. So we tried to get away from the, every developer tool has to look like serious fortune 500 enterprise grade, you know, software and more like, Hey, what's something, what's the, like a beautiful thing you would actually want to use?

And we kind of took inspiration from vintage computers. Uh, you know, there's a lot of Macintosh, classic Macintosh inspiration in there, but we also took inspiration from, I took inspiration from a little bit of like pop fashion and also just like, yeah, burgeoning trends in, in, uh, programming. That were just happening by people kind of outside of like the then classic definition of a programmer.

Yeah, I mean, I, I think you, you greatly succeeded at the very least of like just setting Glitch apart in terms of the, the feel and, and, and using it was so cool. I remember like I, I used it for a few years. Few smaller apps. And I think we also looked at it back then at Prisma actually for, for using it for, for example, apps, but while like, I think you'd try to really make it very easily accessible for beginners and sort of that mid segment of the market.

I'm sure there were many, many interesting challenges to actually make the product work under the hood. Are there any sort of anecdotes that still come to mind when you think back of that time? Yeah, this might be a problem that doesn't exist anymore, but I think it's kind of an interesting one to, to think about even in today's context. So, you know, nowadays we have really great browser data binding frameworks like Vue. js and, and React.

But back then those projects were either didn't exist or were very much in their infancy and definitely not production grade, even in the relatively small production grade of Glitch at the time. So Daniel X, the other co creator. Of, uh, of glitch, he had his own pet framework called Jade and it had data binding. It kind of did what we wanted to do.

And also obviously we had support by the person who created like Jade is like a HTML transpiler, which is renamed to Pug, but there was another technology. It was like Jade lit or something Jade related added data binding functionality and like a like component state to Jade. And so we use that. And it worked really great, but obviously it came with the problems, um, same with, we also use CoffeeScript by the way, but it also all that our tech stack kind of came into, had issues.

When new people joined, there was a lot to figure out, a lot of new, crazy wild code. But yeah, it was like a, it was like a really interesting place because we had to build the framework and the tool, not just the tool. And I think we made some good choices and we made some bad choices in that front. But actually like Daniel X is still out there creating Civet, which is kind of like a successor to CoffeeScript. Uh, he wouldn't let the dream die, which I think is really cool.

And yeah, I think, um, just being really early on a technology. I mean, the web's not really like new or anything and it wasn't new at the time, but this idea of web sites as web apps, single page apps, that was all kind of like, burgeoning technology at the time. One of the reasons why Glitch was so kind of appreciated when it launched, one was like, you know, the visual design, which is kind of a little bit of love hate it, but very memorable, but also like everything reacted very immediately.

You know, you could rename something in one panel and see it change in another panel, which at the time was like pretty magical. It's the magic of data binding. I thought of it as like a totally new tool for a designer. Yeah, that certainly rings true of like those sort of new superpowers that you slowly but surely like convince yourself that's possible in the web, but then also trying to actually make that work. Particularly so early in the web, that's kind of going in hard mode.

That seems to be a bit of a recurring theme across different episodes that we've done so far. So I think by now we've like elevated a little bit to a new plateau of new challenges, and now we're trying to figure out like the next generation of problems where we get new APIs, but there's also new challenges and new unsolved problems. So I I'm, but I'm excited about it. There's lots of. Good stuff to, to dig into. So after Fog Creek and working on Glitch, you've been moving on at some point.

And I'm curious what were like the questions that were top of mind for you? Were there any things that you wanted to explore in particular?

Yeah. So I kind of took some time off after working Glitch, either to figure out what I wanted to make next or what I wanted, like what I wanted to do essentially. Like a lot of us after Glitch were a little burned out on coding and design. So. One of the things I kept coming back to was bug tracking. So, like, that was how I got my job at Fog Creek. But also, like, something I feel like still wasn't solved. And actually, to be honest, I feel like it kind of isn't either.

But I have strong opinions on bug tracking, actually. But anyways, what I started doing was building or designing a different take on bug tracking. And it was okay for a time. Like it was kind of making forward progress, but when I showed it to people, even just regular people, like, and, or developers, neither groups were very impressed like they're like, Oh, it's like maybe 1. 2 X better or maybe 2 X better at most, but it's not 10 X better.

It's not something that would cause me to like change my habits or, you know, adopt a different tool. But it also, it doesn't seem like building a bug tracker is taking advantage of, of what you kind of uniquely do, which is, you know, Design plus development to make something kind of a little more unique. And so, you know, I thought about that feedback for a little while and yeah, it kind of hit me like a Eureka moment. All this time I'd been designing things.

I'd been using sketch, which is, you know, like Mac OS Sigma, and I'd be using the text tool. So like I'd have my mock up and then with the text tool, I'd write like, here's why I did this thing, or here's what's missing, or here's what I need to do using the freeform text tool to just click anywhere on the canvas and type things. And I thought, this is like a really great. way to like organize my thoughts and figure out what I'm doing next.

And fundamentally the issue with bug tracking isn't tracking bugs. It's communicating between people about what we need to do. And I thought, what if this was the answer? Like, what if the ability to write anything anywhere and connect information to anything anywhere. And the idea of not having a structure up front was the product. Like, what if I could bring this superpower to like, People who didn't have design software didn't want to bother to her have to learn how to use it.

And also design software is not made for this sort of task. It doesn't use structured data for any of this stuff. So that's kind of where the original idea for glitch kind of came from this idea of just. Clicking anywhere and typing a node and, you know, free form manipulation of that, which was a bit more of a novel concept than it is these days, but basically from that, I kind of started and ended up with a mock up like a design that five years later still seems like it was pretty accurate.

Like I ended up just building and building from that and also being kind of moved in new directions by people's feedback. And yeah, the, the thing that exists now is actually eerily similar to the thing that was kind of envisioned five, five years ago, which means it was pretty good idea. So the, the project that you're describing is Kinopio, right?

Yes. So that seems to have originated from still that urge to figure out a better way to build a bug tracker, but I think has evolved since then in terms of its vision and goals. So how would you frame today what the goals and vision for Kinopio is? Yeah, that's interesting.

I think the goals for Kinopio is to kind of enable people to think through problems by themselves or collaboratively without needing to kind of define a structure up front, but also being able to, like add a structure as needed as they go. And so people can use it for retrospectives for, for meeting notes or personal notes, research notes, but also for like, like traditional mind mapping and excels at, um, but I've also seen people use it for mood boards and personal websites.

It's kind of like a, yeah, it's a, it's a canvas, but it's a very like expressive one, but also one that kind of has like productivity roots. Yeah, so I definitely encourage every listener afterwards to go check out the show notes and open some of those beautiful Kinopio boards. They really feel like nothing you've ever seen on the web. They feel like very tactile and playful, et cetera. So, uh, it just seems very fun.

So I'm curious, what are some of the design principles that you had in mind when you designed and built this product?

Um, so I guess I had five main principles, so I can, I can talk about them. First to embrace smallness. To build for fidgetability, to embrace plain text, to have a simple interface for mobile and desktop, and the fifth is to refine by pruning. But I think overall, at a high, high level, I kind of wanted to recreate the feel of interacting tangibly with paper.

And not necessarily do that by imitating paper, so a lot of apps fall into the the trap of like, hey, we want to like make something that feels like a scrapbook. So let's have like frayed edges around everything and like a papery texture and make little like, like pen noises when you type and stuff. And actually, I think what makes tangible or like physical interfaces, for lack of a better word, feel good is the immediate feel of that reaction and the quickness of it.

And I try to carry that forward in Kinopio. So you'll notice like you just hover over a card and it kind of sticks to your mouth just a little bit to give you like a like a feeling of you're just kind of moving your hand and fidgeting over a piece of paper. When you go to add information, you're not presented with like, hey, do you want to like add a sticky note? Or do you want to add like a video clip or an image? Like you don't have to make a choice.

You just kind of click to add the card and then you can type whatever you want. And if you want to add an image, you can add an image to that card either by dragging an image or just by pasting in any web URL, uh, same for websites. Yeah, it's a sort of like idea of like, we have text fields, we have regex, with the combination of those two things, we know whether something inside that field is like a link or a file or an image. We can do the right thing.

We don't have to, like, have a toolbar on the side of the screen where people have to, like, before they add any information, decide what kind of information is it? I just want to get rid of all that barriers and just have things as immediate and fast and fluid as possible. And I think in that way, you recreate the feeling of working with like a physical tool. I love that.

You draw such a stark contrast compared to so many other web tools that you're used to, where I think most tools feel much more like material UI, et cetera, like very forum oriented, like very, like all the inputs feel very similar. And I think the software that you've built with Kinopio feel very tactile and very tangible and very playful.

So I'm curious which sort of patterns you figured out there that you would also encourage other builders to embrace more where you'd say like, Oh, we're kind of over complicating much of our software. We could just let the user go with their intuition and let's just make that work. So are there any patterns that you figured out that you thought like, okay, they might be hard to implement, but they're really worth it. Curious to hear more on that.

Yeah, I think the reason a lot of our tools are the way they are, they reflect kind of the way the teams that build those tools are organized. So you have your engineering team and you have your design team. And they both don't fully understand what's possible, because maybe they're not speaking to each other as well as they should be.

But because of that disconnect, the design team might not understand that, you know, like anything can be, Intuitive essentially like you can figure out if something is some kind of data model, you know, just based on what it is And they may just be told here's like the database model at best and be like we need to fit things into this essentially Excel chart make make an interface for this and you end up with a lot more steps than you you may not necessarily have and conversely

developers Might see an interface, propose to them and not really push back or not want to not necessarily want to rock the boat too much by explaining, Hey, maybe we don't need this step. It kind of requires the programmer to also kind of take on a little bit of characteristics of a designer, like by looking for, Hey, where are the points of friction? Can they be reduced maybe in ways that people don't anticipate?

I guess nowadays, like the hot thing is AI and maybe there are like legitimately useful points in an interface where AI could, could make a difference that people don't recognize, because again, what one group knows and what another group knows may not necessarily be the whole picture. So you mentioned text, drag eggs, images, et cetera. Are there any particular implementation patterns that you feel like, okay, this is like a trick.

I'm going to use this across different projects in the future, no matter what. Oh, yeah, I think this is becoming more and more normalized, but I think the big thing that I still see on a day to day basis that a lot of apps get wrong is this idea of like, I'm submitting some information in a field, whatever form that field may take, and I've got to wait for the server to like get that information and come back to me saying, hey, it's a 200 before the interface will let me go on to the next step.

And like 99. 99 percent of the time, that's going to be a 200. So I think The interface can just assume it's good, it's a 200, and just assume success is what I like to call that pattern. Uh, if you assume success, then the user puts an input in and immediately is able to keep working on whatever else they want. If they do multiple things at once, those atomic inputs just happen and are assumed to be successful unless they fail, which is, you know, unlikely.

But, It lets you create like, you know, really fast, really responsive to inputs web applications.

So I think another term that's commonly used to describe this pattern is optimistic updates, which I think if you want to take it some steps further, this is where that. And certainly points you in the direction of Local-First.

So based on our prior conversations, it sounded like you did not build out Kinopio from the start with like Local-First as sort of like the technical goal post in mind, but you've rather worked on it over time and ended up in a direction that has many similarities with Local-First, such as that the app works offline, it is collaborative, et cetera. So I'm curious to hear more about. The similarities that you see with Local-First and also learn more about the tech architecture.

Yeah, I guess another way that I'd put it is like, I only learned about Local-First after I'd built a Local-First app. So I didn't know that there was this community of people like really pushing for, for that particular style of building. But for me, it was kind of a more natural or organic path. So, yeah. Kinopio is the web client but it's also the server.

The server is a source of truth for data, especially when you collaborate or if you switch devices, you need that information accessible anywhere. But I didn't start with a server, I started with just the client and I, I released pretty early to get people's feedback. So, I basically, taking a pattern from what we did with Glitch, I save information, your local state essentially, to local storage in the browser.

So I stringify a JSON object and throw it in there and deserialize it as needed to read from it. Which sounds onerous, but it's actually really fast, and I still haven't had a reason to replace it. But anyways, like, By having that as sort of like the fundamental source of information initially, especially, it's let me, um, do a couple things that apps don't do is one, it helps with those optimistic updates. It lets me load information faster.

So if you refresh Knopio, you don't have to reload your space or board information. It's already there. And then it kind of gets updated when the source of truth arrives. If there's any discrepancies, the other thing it lets me do, uh, which I think is even more unique. is you can use Kinopio without having to sign up. So you go there and the first thing you see is this like sample space, which is kind of shows you how to use it, but that's a real space, that's real information.

You can click it, you can edit it, you can create new spaces and that stuff will be saved if you choose to sign up. But it's the complete app. There's no, nothing in front of you, which I think is pretty cool. Yeah. I love that pattern.

I would love to see that pretty much in all software, but I think it's really like a symptom of that most apps are just like, so server heavy and account heavy that you basically On a technological level, like you can't even have an easy way to make the software work without a user account with all of that baggage. But if you build software more in a Local-First oriented way, then the software should work no matter what.

And that makes it trivial to have a fully working version of the app running locally right in your browser, you can seed it with like some demo data and then optionally upgraded into a server account, et cetera, for collaboration. But I think this is what this new generation of Local-First inspired apps all have in common with the thinking of something like.TLDraw, which is a, is a great canvas-based diagramming tool, which you can also use right away in your browser.

And it's also has local persistence. It has collaboration. So I think this is switching this around for making software useful out of the box without you having to sign up and like pick another password. I think there's such a obvious thing in hindsight that just makes it also much more likely to fall in love with, with some software.

I think for for new companies especially or new new startups, it's such a big advantage if you haven't started that way and you started with the root assumption that your app needs accounts to function, it's really hard to go back on that, like, it's basically impossible, but if you've started building Local-First, this gives you a feature that that larger giants just can't match.

A common pattern that I've seen is like that you basically give away like free anonymous accounts that you can claim later, but then you really need to subsidize that and it's not something you can just do for free, but if you build Uh, software Local-First, then there is no thing you need to subsidize since the software just like runs in someone's browser. You don't need to pay anything for that.

So I think, like you say, that gives new startups huge advantage and I hopefully becomes table stakes for new products. I think another way to frame that. is with the idea of resiliency. So, you know, when Kinopio kind of first launched, it was like front page of Hacker News for a little while. And you know, a hundred thousand people visited it like pretty fast, but because the server didn't even know about them, cause you know, they were mostly making, like checking it out in their browser.

And some of them would upgrade, but are to like sign up for an account. But a lot of them would just, you know, kick the tires and maybe come back later. Like nothing went wrong. Like nothing mattered. I barely noticed, because Yeah, I didn't have to worry about like, Hey, now there's 100, 000 accounts. And now my database is like inflated or, you know, now my server's on fire.

Yeah, and I think this is, you're, you're touching at a point here that I'm super bullish about Local-First software is like, you're, you seem to be working on Kinopio just by yourself. And you've been working on this for, for quite a while. And you probably reached by now, like more and more users without you as a necessity, having to raise VC money and scale a team, etc. So given that you can put your focus.

On like making the product better and not having to babysit a Kubernetes cluster to handle the load. I think that's another benefit of this architecture. Not having to, to learn what Kubernetes is also sounds like a big benefit. It's uh, it seems like a lot. I'm on like the broke boy. Heroku plan, and it's still fine. That's amazing.

So you've shared a little bit of like how the technical architecture works in terms of local state management and how you're persisting data and reading data from and to local storage, but you can also share Kinopio boards between users and even collaborate on them, probably real time. So curious to hear more how that is working, how you've implemented that and which sort of challenges you've run into.

Sure, yeah, to enable that stuff is, is precisely why I did end up adding a server early on in Kinopio's life. So the way it works is it's pretty conventional. Um, all the things that change your local, your local storage state also shoot up an update. To the server. Um, so there's a source of truth database for all that stuff. And, you know, all that's connected to your own user account.

So when you sign on on another device, like your phone, you have the same information in terms of the real time collaboration stuff, I'm essentially sending a small version of those transformations over a web socket to the server, which sees who are the clients connected to this particular space of the time beams, those updates to them. And those people have their own local storage or local state. And local storage updated at the same time.

So it's actually, I'm using like the same, like atomic update system, but I'm using it in three very different contexts, local storage over API requests where things are authenticated and through WebSockets where they're very fast. And the things that you're sending over the WebSockets, is this the entire board state that you send over or is updates events? Can you describe a bit more how that works? Purely updates.

So when you load up, like somebody invites you to a space, so you click the invite link, Kinopio, the web client, will open, see, hey, you're trying to load up this particular URL with an ID that doesn't, that isn't already existing in your own local storage. So I'm going to ask the server, hey, pull this down for me. And so that'll all come in one big, you know, space, blob or clump of, of JSON.

And as you make updates, iterative updates while you collaborate, like move a card around, type in some text, those will all just be like little update card operations that are sent to all the clients in the API.

Got it. So given that Kinopio is not just like a more traditional web app where you have tons of forms and like pages and routes, et cetera, but it's a spatial canvas. This seems to be a more common way now, how software is laid out. I've never built a canvas-based app myself, but I'm very interested in learning more about it. So I'm curious whether you can share some of your learnings. about building a canvas-based tool?

Fundamentally, there are two main different approaches when you build a canvas. So the first approach is you can build it sort of like a website where each card is a dom node and you know, absolutely positioned and you just kind of move it around with transforms. Um, the upside of that is it's really fast and you know, like it'll work everywhere. The downside is there's a lot of like interactions you do on a canvas, like pinch zooming and things like that.

are not really handled well by all browsers out of the gate, especially iOS Safari and, and Android Chrome, for that matter, does a really poor job in some of these things. So for example, like I have a UI on my, on my page and I, but I also have my canvas. If I pinch zoom the phone, I'm zooming in the whole thing, including the UI, which makes the buttons look wild and crazy. And I don't want to do that.

I can also like add like special touch handlers to only zoom in that part of the canvas, but it's really hard to do it in a way Where it doesn't just crash the browser because the transformed texture of the page gets gets too big. So a Kinopio document can be like tens of thousands of pixels wide or deep, right? So it's really hard to design around that.

The second approach, which is by far the more popular approach, is to recreate the whole canvas in the HTML canvas element or some some similar type of rendering that you control and you have really fine grained thing over. And so the upside of that is you have full control over pinching and zooming. You can tell things to, to leave space. The viewport like intersection observer equivalent, um, is a lot more reliable.

So browsers don't always report their positions, especially on mobile, accurately to web apps, as I've found. And so, being able to control every part of the rendering process means you control it. You can make things appear precisely how you want to. The downside is you have to, you lose all the things you get for free on the web. You lose accessibility, you lose speed. You lose like, you know, like special touch handling and other things like that.

And you have to build it in yourself, or more likely you don't really. And you kind of have a canvas that works great on like desktop computers, but not so much elsewhere. And so because of that, Kinopio uses the first approach, which is fast, but. It requires a lot of work to not be janky and I, I do my best, I'll say that much. Any particular patterns that you figured out for that first approach that you laid out? Yeah, so there's a thing that I do called counterscaling.

So essentially when you pinch the screen on mobile, the whole page will zoom up, including the UI. But what I do with the UI is I tell it to scale itself down. So if let's say you pinched in and the page is now 2x, I tell the UI. Hey, it looks like the page is 2x. Maybe zoom yourself down, scale yourself down to 0. 5x. And so it kind of like net makes the UI look the correct size. So I'm basically like making the UI smaller so that it appears regular size while you're doing this.

What I found though is that browsers, mobile browsers don't send resized data and pinch zoom data as quickly as you interact with it. A lot of events happen in the browser that just aren't reported. To the browser, because they don't want to like, you know, blow up the JavaScript or whatever. There's like little tricks that you do to kind of work around that.

So like, I will fade in the UI during like touch events so that you don't see things like jitter around as they're, they're struggling to resize. So yeah, I've learned a lot about how mobile browsers operate differently than desktop ones. And, uh, it's, it's a lot. Would you still choose approach number one, as opposed to the canvas-based approach? I think I would, because I've tried like. a couple times to, to redo Kanopio with different approaches.

The other big downside of the canvas-based approach is it also makes iteration way harder. Like adding new features when you have to also render them or like, you know, like, like at a lower level and figure out how to just work around that sort of stuff. And you don't have like, you know, the normal flex box type positioning flow and things like that. It's a, it's a lot more tricky. And so I think it's kind of like I've chosen the net best approach, at least for Kinopio.

And the one that I've kind of embraced because one of the other advantages of doing a full canvas rendering is you can scroll in 360 degrees. And with Kinopio, you can only scroll down and to the right as much as you want. But because of that constraint, You always know where the beginning of the document is.

It's always in the top left for the most part, as opposed to other canvas tools where it can be like in the center of the page, which might not be visible depending on the size of your device and you've got to kind of scroll around to figure things out. That's super cool. In regards to the real time collaboration, so you can share boards with other people and like work on them at the same time. Are you going even further to have like a sense of presence across collaborators?

You can do see other people's cursors or how did you think about designing those interactions? So, Kinopio has this kind of unique feature called Paint Select or Magic Paint and basically it lets you select multiple cards to do bulk actions, like move them all together, but it lets you paint over them to select them.

So instead of drawing a box, you can kind of like make more kind of unique selections by painting over and it was kind of also a way to like bridge this gap between the right side of your brain and the left side of your brain. And so the paint stroke kind of disappears as you're paint selecting, there's like a exponential decay function there. And so I also I show those same paint strokes for other people looking at your space or interacting with it.

So as you're moving around, you see their paint strokes kind of moving around and fading in the background. You also see their user icons kind of floating around. So it kind of creates more than just like the cursor plus user icon. It kind of creates more of like a feeling of like, Oh, like these people are like, or someone's really interacting with the space or maybe somebody is just noodling around in the space.

I can just see their paint strokes and they're trying to spell out words or draw things before the paint fades away. That is super cool. Yeah. This is, I think goes back to the design principles that did you laid out initially and how you're not directly imitating paper, but you figure out like what is the best mechanism here for, for this medium and the goals you're going for. So going back to the canvas, I recently read that I think Obsidian has launched an initiative called JSON Canvas.

Um, if I remember correctly, and I think there, do you have some plans to, to also like integrate with that? Funny you should mention, I literally, um, just yesterday launched, uh, Kinopio support for full import and export, uh, you know, um, exporting with that, with that file format, the canvas file format. So they launched it yesterday. I really quickly added it yesterday. So can you share a little bit more about why that would be useful for, for people?

Sure. Yeah. So for the longest time there hasn't been like a great interop document format. So of course, each different app has its own JSON representation of nodes or cards and edges or connection lines. But they're not, they're all app specific. So, you know, it's kind of tough if you're trying to, you know, Migrate from one tool or another or test out one tool or another.

And so the closest equivalent we had before, just for a little bit of historical context was OPML, which is also like kind of a, an off requested feature, an OPML was kind of made for outliners. So like collapsible nested tree and you know, structures I can indent now dent. The problem with OPML is it doesn't handle what happens if you have multiple trees that aren't connected to each other, or you have multiple trees that might have child node that they both share.

You know, like you can, you can create structures that are way more complex than OPML can capture. And so I just couldn't figure out how to do it with OPML. So I followed the spec for a while and, and when Capano and Obsidian launched it, I, I was already kind of in a rework of the importing and exporting system. So it's a very simple spec. It doesn't cover every feature that either app has, I'm sure. But the advantage of that is it's also very easy to implement. So, you know, it's different.

Transforming from one JSON object to another, essentially. Got it. And I suppose that while the spec is like very open ended in some way, maybe that converges to, towards some more details over time. And the idea would be that I can bring some data from one tool, for example, Obsidian into Kinopio or the other way around or future tools that might, might exist. Yeah. It's, but there are wrinkles because. Of how different these tools are, or at least how different Kinopio is from all of them.

So there are assumptions and I've, I've left like feedback about these things in, in GitHub issues for the spec, but there are like assumptions that they make like, um, the node has to define like how wide it is explicitly, or what type of node is it? Is it a file node? Is there a, you know, like a website node or whatever.

So problems with both of these is that like the width, Of one app's node for the same amount of text might be different for another app because they're all rendering it differently in Kinopio's case. There's also this. It's also mobile compatible. So there's a bit extra of padding and sizing for touch friendliness. So those numbers don't really translate. And so it's kind of weird that they're required in the spec as opposed to being optional. Second issue was the node type.

So I can mention a long time ago. Or earlier in this chat, you know, a lot of apps make you choose, like, Hey, are you going to insert a web page? Are you going to sort of whatever? On Kinopio, they're all the same type. They're all just, there's only one type of card, a text card, and whatever type of content you put in that, whether it's a link or a website or whatever, is what that card transforms into using the power of regexes.

And so that part of the whole spec is basically, like, not necessarily relevant to Kinopio. Didn't really connect because It's making the assumption that that isn't really shared. So in some ways I think it's too specific in some ways it's, and I'm sure a lot and a lot of people's complaint is that it's not specific enough. So it's weird because like it's really hard to make a spec for wildly different apps.

But I think currently I'm actually pretty happy with the spec because it captures like the most important part, which is the representation of cards and nodes in a way that doesn't require them to have this strict tree structure. Yeah. That makes a lot of sense. And yeah, I mean, the devil's always in the detail and you built Kinopio really to enable the sort of interactions and details that you uniquely thought about. And you might not have that entropy available in Obsidian and vice versa.

And then it's also, how do you preserve that intent and that information across apps? That's, that's a very tricky problem, but I, I applaud the initiative to take some first steps there to at least bring some data across one app to another. So that sort of cross app collaboration, I think that is certainly a goal that I'm rooting for, but that we still have like many chapters still ahead of us there.

So the way I've built Kenopio, it's super impressive, both in terms of like how the product feels and works and looks, but also like, given that you've been on this journey for, for such a long time, uh, by, by yourself, I'm curious which corners you might've already cut along the way that you regret looking back where you wish you would have like spent up front or vice versa where you thought something might be a problem and it never actually became a problem. Oh, wow.

Yeah. There's, there's definitely a lot of those. So like, there's like a lot of code kind of like with the syncing engine, uh, and the way I merge, um, different changes to make smaller change sets that get sent to the server, but I feel like.

are a little hard to work around now in just in terms of like just how gross that code is or how like abstractive and I wish I did a better job writing it like it's not it's not something that's painted me into too harsh a corner it's just something I'm like oh I'm scared to touch this part of the app but one day I'll just you know buckle down and and really get to it.

So I actually think the app is in a pretty good place just because um I guess the other thing is like I prefer to like write code that's like, not necessarily for me to understand now, but for me to understand in like two months or three months or five years from now, where I forget what the S variable or the A variable is referring to. So I, I, I was like kind of influenced by, by some short time, like, Coding for Apple platforms where they're very verbose with variables.

I kind of took some of that Coco convention into my own kind of code writing style. Yeah, I think that's very wise. Uh, I've made the same observation about myself since in reality, even if you just work by yourself, you still collaborate with yourself. Over time more instances of you over time the future you, the past you.

who do not the same context right in your brain So just like leaving notes for yourself of like, why did you do a certain thing has, I, I've had to learn that lesson painfully and I'm treating my future self better or I'm trying to, so, uh, it looks like you've learned quite a couple of similar lessons, but Yeah, I think we all kind of learn that, but we all have to, like, burn ourselves a little bit before we truly learn it. Because it's not, like, an intuitive thing to know.

And it is, like, in an industry that's always trying to, like, move fast and ship fast and whatever, it's a little, it's mildly antithetical to that. But it is one of those things where, take a little extra time to write that good comment, it'll save you so much more time down the road.

So you've been on this journey by yourself now for quite a while after being in a more conventional team context at Fog Creek working on Glitch. I'm curious whether you can reflect a little bit on that journey now working on Kinopio. What are the good things? What are the challenging things? What are the things you wish you would have known before embarking on this journey? Yeah, there's definitely pros and cons to, to working by yourself or for yourself versus in a team.

The obvious things are like, yo, camaraderie when you're having a bad day, you know,, you're in it with other people and, and, you know, like the pain can be absorbed by many people kind of thing or the struggle. But actually in reality, like, I don't, I kind of work alone, but I also kind of don't in the sense of like, there are other creators building great projects out there like MM doc. page or TL draw, et cetera.

Uh, and so it's kind of like, Even though some of them are sort of competitors in the way, but sort of not like Muse as well, because we're all kind of on that same hill, we're all kind of struggling and we're all kind of in a similar place. It kind of acts as like a de facto team, even though you're not necessarily like in contact with them every day. Uh, they're also the companies that I've contracted for, like Futureland, which is also kind of like a early stage startupy company.

I can see that they have similar challenges that I have in terms of, you know, getting the word out and stuff like that, or just refining the product. And so. In that sense, it's like, I think, I think you mitigate like a lot of the sort of downsides of, of not being in a, in a large organization.

But I also kind of like, like in addition to sometimes working as a contractor, I also employ contractors or I'm starting to, and so I've gotten some really great database performance optimizations, um, from a friend named Lucas who I met in Bali. Yeah. These are things like, Oh, I like wrote the indexes wrong and I didn't know how to check them or like, Hey, I could. Make merge these database calls into one simpler one to make like really dramatic beat improvements.

And so, like, it is great, you know, finally having just a little bit of the resources to be able to do that sort of thing. And I kind of want to continue to new more and down the path until it sort of stops making sense. Yeah, like, it's kind of one of those things where you see, I feel like I've learned what works and what doesn't from my time working at other people's companies.

And I'm kind of, you know, Testing all those hypotheses now, uh, as I build Knopio and, and, you know, ideally sharing in my blog and on Twitter and whatnot, how that's working out and what I was wrong about or right about. Yeah. Thank you so much for taking the effort of, of sharing your, your learnings and experiences there.

Highly recommend for, for every listener to check out your blog that has its own very unique style, in the same way as Kinopio has its own style, your blog has like a very organic style, which I really like. It's very inviting to, to read about your, your different blog posts, et cetera.

I guess, speaking of organic and that blog, like one of the funny things about it is it's actually like extremely organic in the sense of like, I designed the first version of that blog in 2014 or before that on a trip to when I was interviewing at Flickr, newly bought by Yahoo in San Francisco, back when they used to fly you out for tech job interviews. And so I'd, I'd built lots of like blogs in the past, like personal blogs, but I kind of wanted like something new back in the day.

That was a de regard thing to like start a blog and then get bored of it and start a new one. And so this is the one that stuck, but essentially like, Over the years, I've been like slowly tweaking design and slowly adding features like blog post tags and actually a couple months ago. I just added commenting and before that, like a little bit of newsletter functionality. So it is very much like this thing. That's kind of collected pieces of it. As it's rolled down a hill.

Yeah. I think there's also this term of digital gardening, which I am also very drawn to. I have not evolved yet myself to, to reach that level of like organic feel. I think my blog right now is like much more neutral and traditional. So. You've mentioned initially that you didn't always happen to be an engineer and a designer, but you found your way towards design and engineering by actually starting out studying biology and urban planning.

So, I'm curious to learn more about that journey and that transition and which sort of maybe unique perspectives this has given you.

Yeah, I went to school for biology and then I did my grad studies in urban planning, basically because I like SimCity and initially because for biology, because I didn't have anything else to do in university. Uh, but from there, like from, especially from the urban planning side, I'd always been doing, like, using Adobe Illustrator for like illustrations and stuff just for friends and for fun. But in grad school, I also had to do like mapping and more formal presentations.

And one of the things I sort of realized in that environment was like, we'd have to present this like huge paper and we'd have these like little dioramas to go with it with like, you know, figures and maps and stuff. And all the people grading it didn't read the papers because they were boring as fuck. They're just like policy and stuff. But they would be like, wow, this is so cool.

Wow. the use of fonts and whatever and great colors and stuff and so yeah it kind of like taught me that like oh okay like even like the most like unapproachable or high minded academia types they're all kind of drawn to like what's beautiful or what's shiny we're all just animals at the end of the day so It kind of made me, like, leave the urban planning world and go more into, like, the illustration world.

And that's where I kind of got my first job in tech as a staff illustrator for a company that did, like, banner ads. Definitely the dregs back in the day. Um, but from there I did design work for them, like app design work, and then from there got pushed into doing more development to build things that I designed. Uh, it was a real kind of trial by fire situation. Um, But that's how, that's how this kind of thing started.

It all started with illustration, then design, then building the things that I designed. Are there some learnings that you take away from biology or urban planning that you now apply to designing or to software engineering?

I guess kind of at a high level way, like biology and urban planning are both sort of the The study of systems, like the systems in your body, or the systems of how traffic flows on the street, or how, you know, like cities develop, um, from like medieval towns into regimented grid, like, uh, structures and and streets. And so I guess, um.

One example is like when you see like how people organize themselves and their teams or how they, you know, like identify their projects, there are kind of a lot of similarities. It's almost like a pale imitation of biology and city planning or in terms of the complexity.

But so I'm really inspired by, like, the biological process mitosis for one, where an individual cell gets really big over time and at a certain point, moving information from the edge of the cell to the middle, like the nucleus, where all the processing is done. Um, the high level thinking is done gets it takes too long. And so what a cell does is instead of, like, adding scaffolding or trying to, you know like make that, that cell more complex than it should be.

It just splits itself into two pieces, obtaining like the core parts from both so that each little, little new piece can be much more efficient. And I think, you know, that's something that like, that we do when we try and like cut down scope, break a big problem into small problems, or just, you know, break a big document into little ones.

And that's also why I like, That's also kind of the heart of the thinking of cards as an atomic unit of thought with a character limit, kind of like a tweet level character limit. It's because it, that constraint does force you to think more, I guess you could say. Yeah, this is fascinating.

I think there's so many, Ideals in software engineering that I'm drawn to such as like composability and like principle of like locality and now that you say it, uh, those are like nature got that figured out like long time ago where like all of our organs and like on a much smaller scale, this all composes and there's things emerging, us emerging, civilizations emerging. So yeah, I think there's the great Case study to study nature and be inspired for building better products. Yeah, absolutely.

It's one of those things where you see it and then you can't unsee it.

Yeah. Thank you so much for, for sharing that perspective. So you're not just a great engineer, but also a great designer that shows in like all the products that you're building. And I think that sort of intersection of being an engineer and a designer, I think that's a, Rare trade that I feel myself very drawn to. And I want to learn more about that. Are there any sort of hints or words of advice that you would give people how they can, as an engineer, become a better designer?

Yeah, that's a great question. I think a lot of the, the applications we have now, like one example, uh, that we talked about with, you know, you submit a form and then you've got to wait For the form response to come back from the server before the app lets you do other things. And a lot of that is caused by a disassociation or a separation between what a designer thinks is possible. And when an engineer is like, like their level of interest in the design.

And so I think if to answer the question of like a programmer wanting to do more design, I think a trap people fall into is like, there's two traps. One is, Hey, I need to figure out how to make things look better. Pretty before I start and like, you know, how do they like what is attractive? What is aesthetic?

So thinking of design as as like, you know the lipstick on a pig it's definitely a trap I feel people fall into but I think the other side to it is like not understanding that design is kind of like Being a chameleon for whatever you're designing for. So let's say you're designing an app for nurses to do some sort of nursing task. The designer's role in that case isn't necessarily to be like, Hey, how do I make this button look great? But to be like, what does the nurse need?

Like, when do they need it? How do they need it? And that's things that an engineer should also know. And In situations like that, where both, both sides of the product building experience, whether that's your own head, both sides of your own head, or a separate engineer and developer, they both kind of come into it with the idea of like, hey, what's the best thing for a nurse? Uh, when do they need it? What do they need? Like, that's how really great design happens.

And yeah, an engineer also has this advantage of knowing, having access to like, technical information that a designer doesn't. So one example in Kinopio is, you know, as we mentioned, like, you can just click to type a card, and you can type freeform text, and that'll be a text card, or you can drag an image in, or paste in an image URL from wherever, and that'll also become a thing. That's because, as the engineer side of my brain knows, hey, we can just use regex and determine what is what.

There may be new opportunities for that with AI, but the fundamental idea of, like, just. Like, knowing that you know something that someone else doesn't know. It's like, like, like thinking past what you can see and kind of knowing the full possibilities of what you can do is kind of the most important part of design. Yeah, that, that's great advice.

Uh, I think about like most things that you use to build stuff with as materials that's in the real world, but also digital materials, whether that's code or whether that's other things. And so I think it's actually more folks should try to assume a bit of like different disciplines as well. Like look at the same material from different angles, from the engineering angle, but also from the design angle. I think this is where you can build much better products.

And also quoting a previous episode we've done with Rasmus Andersson, who's referenced this concept of mechanical empathy. This is very much from like a engineering perspective. What does the material allow me to do? What does like the, the hardware this is running on allow me to do? Or what does the web ecosystem allow me to do? Do I use the DOM? Do I use the canvas? And, uh, those materials that I have available. What does that allow me to, to build the best product?

So thank you so much for, for sharing all of this with us. Is there anything that you want to tell the audience or share with the audience? I guess if I want to share one thing, it's something we've already mentioned. Um, my blog, which I have been writing on and off for, I guess, since 2014. Don't read the old articles. They suck, but the new ones are pretty good. They're, I kind of try and write about.

technical or design topics in a way that's more approachable to even non technically minded people. They give like, you know, a lot of high level overviews of how Canopia was made, how Glitch is designed, things like that. And yeah, check it out if you feel like reading some good blog posts, I think.

Perfect. I definitely recommend that. I've enjoyed the few blog posts I've read quite a lot. So yeah. Thank you so much for coming on the podcast and sharing all of your wisdom. Thank you. Thanks so much for having me. Thank you for listening to the localfirst.fm podcast. If you've enjoyed this episode and haven't done so already, please subscribe and leave a review wherever you're listening. Please also tell your friends about it.

If you think they could be interested in local-first, if you have feedback, questions or ideas for the podcast, please get in touch via hello at localfirst.fm or use the feedback form on our website, special thanks to Expo and Crab Nebula for supporting this podcast. See you next time.