localfirst.fm

A podcast about local-first software development

Listen

Conference

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

The guest of this episode is Pirijan Ketheswaran, the creator of the Kinopio, a playful, canvas-based tool for thought. He is also the co-creator of the online IDE Glitch. This conversation will go trough his journey as a creative including his time at Fog Creek and later building Kinopio as a solo developer.


Mentioned in podcast


Links:

Thank you to Expo and CrabNebula for supporting the podcast.

Transcript

Intro
00:00I think another way to frame that is with the idea of resiliency.
00:03When Kinopio first launched, it was like front page of
00:06Hacker News for a little while.
00:07A hundred thousand people visited it like pretty fast, but because the server didn't
00:11even know about them, cause they were mostly checking it out in their browser.
00:15Like nothing went wrong.
00:16I barely noticed, because I didn't have to worry about like, Hey,
00:19now there's 100, 000 accounts.
00:21And now my database is like inflated or, now my server's on fire.
00:25Welcome to the Local-First FM podcast.
00:28I'm your host, Johan Schickling, and I'm a web developer, a startup founder, and
00:32love the craft of software engineering.
00:34For the past few years, I've been on a journey to build a modern, high quality
00:38music app using web technologies.
00:40And in doing so, I've been falling down the rabbit hole of Local-First software.
00:44This podcast is your invitation to join me on that journey.
00:48In this episode, I'm speaking to Pirijan Ketheswaran, the creator of Kinopio, a
00:52playful canvas-based tool for thought.
00:55He's also the co creator of the online IDE Glitch.
00:58In this conversation, we talk about his journey as a creative, including
01:03his time at Fog Creek and later building Kinopio as a solo developer.
01:07Before getting started, also a big thank you to Expo and Crab
01:11Nebula for supporting this podcast.
01:13And now my interview with Pirijan.
01:17Hey Pirijan, nice to meet you.
01:19Thank you so much for coming on the show.
01:20How are you doing?
01:21Hey, thanks for having me.
01:22I'm doing quite well.
01:24So for those of us who don't know you, could you give a quick background?
01:29Sure.
01:29Yeah.
01:29So my name's Pirijan.
01:31Uh, I'm the creator and mostly sole developer and designer of Kinopio.
01:37club, uh, a mind mapping and creative thinking tool.
01:40Uh, but before that I worked at Fog Creek, um, and.
01:44Uh, specifically, uh, at a time where the Trello office was there
01:48and Stack Overflow had just spun out.
01:50And I eventually went on to co create Glitch.
01:53com, the, uh, web editing development environment.
Fog Creek / Glitch
01:59That sounds fascinating.
02:00So, Maybe some of us have heard of Trello and Stack Overflow, or
02:05certainly have heard of those, but maybe not quite about Fog Creek.
02:09So I think that's quite a long journey, but could you give a bit more
02:12background on Fog Creek and the really monumental projects that came out of it?
02:18Yeah, so Fog Creek, as I understand it, was founded by Joel Sposky and
02:23Michael Pryor, way back when, a long time ago, in New York City.
02:26Their premise was, let's make the best place for programmers to work, which was
02:29a wild and crazy concept at the time.
02:32And from there, um, Fog Creek kind of acted as an incubator.
02:36So they developed Stack Overflow and they, let's see, I'm trying to remember
02:41the timeline here, but, um, eventually Stack Overflow got really big and they
02:45moved to a slightly different building in the New York financial district.
02:49And Trello grew the same way and for a long time shared the office with Fog
02:54Creek and Fog Creek would develop its own bug tracker which kind of they used
02:58to fund the development of new projects and the third project that was being
03:03developed after Trello was Glitch.
03:05So how did you find your way to Fog Creek and what led you to work on Glitch?
03:11Oh, wow.
03:11Okay.
03:12So it actually kind of came from a couple of jobs I've been working at previously.
03:16So I went to school actually for biology and urban planning.
03:19And while as an urban planner, I kind of got into a love for map making
03:25and visualizations and illustration.
03:27And that kind of led me to a job in tech where I started as an
03:30illustrator, then became a designer and then became a developer.
03:34To build things that I designed, it's kind of a trial by fire.
03:37But in all those jobs, the other thing that was new to me was using a bug tracker
03:41and a lot of the companies that I worked for, uh, used Fog Bugs, the Fog Creek
03:46bug tracker, and it wasn't the greatest product and it kind of inspired me.
03:51To like want to make a better version, like as a designer first, I kind of
03:55came up with concepts and new ideas.
03:58Like how could Fog Bugs work if it was designed around more of a human workflow
04:02as opposed to more of a managerial one.
04:04And so I put a lot of those mock ups up on Dribbble when Dribbble was a thing.
04:08And the leadership from Fog Creek saw it, uh, flew me over to New York and
04:11asked me if I wanted to work there and eventually that's what I did.
04:15That sounds amazing.
04:16So yeah, tell me a bit more about like how Glitch then came
04:19to be and how it took shape.
04:21And I think you also shared some of the design principles that you arrived at
04:26for, for Glitch on a great blog post that we'll also link in the show notes.
04:31So I'm curious to learn more about that.
04:33Sure.
04:33Yeah.
04:34So, so at the time they had Trello and Stack Overflow, and
04:38both were really big successes.
04:40Now Trello was still independent, so it wasn't bought by Atlassian
04:44at the time and was also on its way to be a really big success.
04:47And the company leadership wanted to figure out what
04:50they were going to do next.
04:51What would be their third big thing?
04:53So what they did was they held what they called a Creek Week, which was a couple
04:57of people who were interested, could independently arrange teams and come up
05:01with like ideas of what we should work on.
05:03And there were some pretty good ideas.
05:05But the one that eventually went out was the one by me and
05:08Daniel X that became Glitch.
05:10It was a web development interface where you didn't have to download
05:14an ID or set up a server.
05:16Or, you know, figure out how Git works or anything like that.
05:19You just start typing and you have a real Node.
05:21js app at your fingertips immediately.
05:24And so, yeah, like over time, we sort of, every week we build it a little
05:29bit more and demo it to leadership and every week it would crash.
05:33And then one day they were just like, Hey, what if we added.
05:36real time collaboration to this and so that's what we did and that's what it
05:40has and you know like it started as like this project where we were working really
05:45closely with Joel and then eventually the rest of the company as the team
05:50opened up and yeah it eventually grew to subsume so unfortunately, um, Fog Creek
05:56is like pretty much dead as a company.
05:58Glitch, it kind of got renamed to Glitch and then Glitch was bought.
06:03Well, as they say, all good things come to an end, but it's,
06:07it's been a phenomenal product.
06:09And I think it had just such a distinct vibe and visual aesthetic and feel
06:14to it, particularly at a time when I remember like a lot of products just
06:19kind of felt the same, like spoke the same, imitated the same design language.
06:24And Glitch really like, not just the name stood out, but the visuals, like
06:28the feel of it, all of it stood out.
06:30So I'm curious, like, what was the inspiration for that and
06:33what was the goal for that?
06:34Yeah.
06:34Glitch was actually a really interesting project.
06:36I mean, I guess in a lot of ways it was a dream project because you get to make
06:40a product from the beginning, kind of help define the team and you're doing
06:45so like without having to worry about money, which is like pretty amazing.
06:48The big bet on Glitch was that.
06:50There's a middle market of developers.
06:52So everybody knows there's the pro developer who's like, I am on Vim all day.
06:56I can SSH into whatever, and I'm super great.
06:58And then there's the beginner side, which is like, Hey, I'm learning MIT scratch.
07:02I'm, I'm doing like, like tutorials on how to make like, you know, like
07:08a really simple to do list, but then we thought there's this big kind of
07:11in the middle of these two developer markets where people want to code with
07:17real code, not like, you know, building blocks and abstractions, but they also
07:21kind of are kind of turned off by a lot of the configuration like they could
07:25do it, but it's kind of like a pain.
07:28And if they want to make, like, a small project or try stuff
07:30out, it's kind of beneath them.
07:31And so that was our bet.
07:32And so, like, we thought, okay, this is going to be like a different.
07:35market of developers, they're going to have a different vibe, let's say.
07:38So we tried to get away from the, every developer tool has to look like serious
07:43fortune 500 enterprise grade, you know, software and more like, Hey, what's
07:47something, what's the, like a beautiful thing you would actually want to use?
07:49And we kind of took inspiration from vintage computers.
07:53Uh, you know, there's a lot of Macintosh, classic Macintosh inspiration in there,
07:56but we also took inspiration from, I took inspiration from a little bit of like
08:00pop fashion and also just like, yeah, burgeoning trends in, in, uh, programming.
08:06That were just happening by people kind of outside of like the then
08:10classic definition of a programmer.
08:13Yeah, I mean, I, I think you, you greatly succeeded at the very least of like just
08:17setting Glitch apart in terms of the, the feel and, and, and using it was so cool.
08:23I remember like I, I used it for a few years.
08:25Few smaller apps.
08:26And I think we also looked at it back then at Prisma actually for, for using
08:30it for, for example, apps, but while like, I think you'd try to really make it
08:34very easily accessible for beginners and sort of that mid segment of the market.
08:39I'm sure there were many, many interesting challenges to actually
08:43make the product work under the hood.
08:45Are there any sort of anecdotes that still come to mind when
08:48you think back of that time?
08:50Yeah, this might be a problem that doesn't exist anymore, but I think
08:52it's kind of an interesting one to, to think about even in today's context.
08:56So, you know, nowadays we have really great browser data
08:59binding frameworks like Vue.
09:01js and, and React.
09:02But back then those projects were either didn't exist or were very much in their
09:06infancy and definitely not production grade, even in the relatively small
09:10production grade of Glitch at the time.
09:13So Daniel X, the other co creator.
09:15Of, uh, of glitch, he had his own pet framework called
09:18Jade and it had data binding.
09:20It kind of did what we wanted to do.
09:22And also obviously we had support by the person who created like Jade is like
09:26a HTML transpiler, which is renamed to Pug, but there was another technology.
09:30It was like Jade lit or something Jade related added data binding functionality
09:35and like a like component state to Jade.
09:38And so we use that.
09:40And it worked really great, but obviously it came with the problems, um, same
09:44with, we also use CoffeeScript by the way, but it also all that our tech
09:47stack kind of came into, had issues.
09:50When new people joined, there was a lot to figure out, a lot of new, crazy wild code.
09:55But yeah, it was like a, it was like a really interesting place
09:58because we had to build the framework and the tool, not just the tool.
10:01And I think we made some good choices and we made some bad choices in that front.
10:05But actually like Daniel X is still out there creating Civet, which is kind
10:09of like a successor to CoffeeScript.
10:11Uh, he wouldn't let the dream die, which I think is really cool.
10:14And yeah, I think, um, just being really early on a technology.
10:19I mean, the web's not really like new or anything and it wasn't new at the time,
10:23but this idea of web sites as web apps, single page apps, that was all kind of
10:27like, burgeoning technology at the time.
10:29One of the reasons why Glitch was so kind of appreciated when it launched, one
10:33was like, you know, the visual design, which is kind of a little bit of love
10:35hate it, but very memorable, but also like everything reacted very immediately.
10:40You know, you could rename something in one panel and see it change
10:42in another panel, which at the time was like pretty magical.
10:46It's the magic of data binding.
10:47I thought of it as like a totally new tool for a designer.
10:50Yeah, that certainly rings true of like those sort of new superpowers that you
10:55slowly but surely like convince yourself that's possible in the web, but then
10:59also trying to actually make that work.
11:01Particularly so early in the web, that's kind of going in hard mode.
11:05That seems to be a bit of a recurring theme across different
11:08episodes that we've done so far.
11:11So I think by now we've like elevated a little bit to a new plateau of new
11:17challenges, and now we're trying to figure out like the next generation of problems
11:22where we get new APIs, but there's also new challenges and new unsolved problems.
11:27So I I'm, but I'm excited about it.
11:29There's lots of.
11:30Good stuff to, to dig into.
11:32So after Fog Creek and working on Glitch, you've been moving on at some point.
11:38And I'm curious what were like the questions that were top of mind for you?
Kinopio
11:45Yeah.
11:46So I kind of took some time off after working Glitch, either to figure out what
11:50I wanted to make next or what I wanted, like what I wanted to do essentially.
11:54Like a lot of us after Glitch were a little burned out on coding and design.
11:57So.
11:58One of the things I kept coming back to was bug tracking.
12:01So, like, that was how I got my job at Fog Creek.
12:04But also, like, something I feel like still wasn't solved.
12:07And actually, to be honest, I feel like it kind of isn't either.
12:10But I have strong opinions on bug tracking, actually.
12:12But anyways, what I started doing was building or designing
12:16a different take on bug tracking.
12:18And it was okay for a time.
12:20Like it was kind of making forward progress, but when I showed it to
12:23people, even just regular people, like, and, or developers, neither
12:27groups were very impressed like they're like, Oh, it's like maybe 1.
12:302 X better or maybe 2 X better at most, but it's not 10 X better.
12:35It's not something that would cause me to like change my habits or,
12:38you know, adopt a different tool.
12:40But it also, it doesn't seem like building a bug tracker is taking advantage of, of
12:45what you kind of uniquely do, which is, you know, Design plus development to make
12:49something kind of a little more unique.
12:51And so, you know, I thought about that feedback for a little while and yeah,
12:55it kind of hit me like a Eureka moment.
12:57All this time I'd been designing things.
12:59I'd been using sketch, which is, you know, like Mac OS Sigma,
13:02and I'd be using the text tool.
13:03So like I'd have my mock up and then with the text tool, I'd write like, here's
13:07why I did this thing, or here's what's missing, or here's what I need to do
13:10using the freeform text tool to just click anywhere on the canvas and type things.
13:13And I thought, this is like a really great.
13:17way to like organize my thoughts and figure out what I'm doing next.
13:21And fundamentally the issue with bug tracking isn't tracking bugs.
13:24It's communicating between people about what we need to do.
13:27And I thought, what if this was the answer?
13:30Like, what if the ability to write anything anywhere and connect
13:33information to anything anywhere.
13:35And the idea of not having a structure up front was the product.
13:39Like, what if I could bring this superpower to like, People who didn't
13:42have design software didn't want to bother to her have to learn how to use it.
13:47And also design software is not made for this sort of task.
13:49It doesn't use structured data for any of this stuff.
13:52So that's kind of where the original idea for glitch kind
13:54of came from this idea of just.
13:56Clicking anywhere and typing a node and, you know, free form manipulation
14:01of that, which was a bit more of a novel concept than it is these days,
14:04but basically from that, I kind of started and ended up with a mock up
14:08like a design that five years later still seems like it was pretty accurate.
14:12Like I ended up just building and building from that and also being kind of moved
14:16in new directions by people's feedback.
14:18And yeah, the, the thing that exists now is actually eerily similar
14:22to the thing that was kind of envisioned five, five years ago,
14:26which means it was pretty good idea.
14:28So the, the project that you're describing is Kinopio, right?
14:32Yes.
14:32So that seems to have originated from still that urge to figure out
14:38a better way to build a bug tracker, but I think has evolved since then
14:42in terms of its vision and goals.
14:45So how would you frame today what the goals and vision for Kinopio is?
14:50Yeah, that's interesting.
14:51I think the goals for Kinopio is to kind of enable people to think through problems
14:56by themselves or collaboratively without needing to kind of define a structure
15:00up front, but also being able to, like add a structure as needed as they go.
15:04And so people can use it for retrospectives for, for meeting notes
15:09or personal notes, research notes, but also for like, like traditional
15:13mind mapping and excels at, um, but I've also seen people use it for
15:16mood boards and personal websites.
15:18It's kind of like a, yeah, it's a, it's a canvas, but it's a very like
15:22expressive one, but also one that kind of has like productivity roots.
15:26Yeah, so I definitely encourage every listener afterwards to go check
15:31out the show notes and open some of those beautiful Kinopio boards.
15:35They really feel like nothing you've ever seen on the web.
15:39They feel like very tactile and playful, et cetera.
15:43So, uh, it just seems very fun.
15:46So I'm curious, what are some of the design principles that you had in mind
5 principles of Kinopio
15:53Um, so I guess I had five main principles, so I can, I can talk about them.
16:00First to embrace smallness.
16:02To build for fidgetability, to embrace plain text, to have a simple
16:06interface for mobile and desktop, and the fifth is to refine by pruning.
16:10But I think overall, at a high, high level, I kind of wanted to recreate the
16:14feel of interacting tangibly with paper.
16:18And not necessarily do that by imitating paper, so a lot of apps fall into the the
16:22trap of like, hey, we want to like make something that feels like a scrapbook.
16:26So let's have like frayed edges around everything and like a papery
16:30texture and make little like, like pen noises when you type and stuff.
16:34And actually, I think what makes tangible or like physical interfaces,
16:38for lack of a better word, feel good is the immediate feel of that
16:42reaction and the quickness of it.
16:43And I try to carry that forward in Kinopio.
16:45So you'll notice like you just hover over a card and it kind of sticks
16:48to your mouth just a little bit to give you like a like a feeling of
16:52you're just kind of moving your hand and fidgeting over a piece of paper.
16:56When you go to add information, you're not presented with like, hey, do
17:00you want to like add a sticky note?
17:02Or do you want to add like a video clip or an image?
17:05Like you don't have to make a choice.
17:06You just kind of click to add the card and then you can type whatever you want.
17:11And if you want to add an image, you can add an image to that card either
17:14by dragging an image or just by pasting in any web URL, uh, same for websites.
17:20Yeah, it's a sort of like idea of like, we have text fields, we have regex, with
17:25the combination of those two things, we know whether something inside that field
17:30is like a link or a file or an image.
17:35We can do the right thing.
17:36We don't have to, like, have a toolbar on the side of the screen where people have
17:39to, like, before they add any information, decide what kind of information is it?
17:43I just want to get rid of all that barriers and just have things as
17:48immediate and fast and fluid as possible.
17:50And I think in that way, you recreate the feeling of working
17:53with like a physical tool.
17:54I love that.
17:55You draw such a stark contrast compared to so many other web tools that you're
18:00used to, where I think most tools feel much more like material UI, et cetera,
18:06like very forum oriented, like very, like all the inputs feel very similar.
18:12And I think the software that you've built with Kinopio feel very tactile
18:17and very tangible and very playful.
18:20So I'm curious which sort of patterns you figured out there that you would also
18:24encourage other builders to embrace more where you'd say like, Oh, we're kind of
18:29over complicating much of our software.
18:31We could just let the user go with their intuition and let's just make that work.
18:35So are there any patterns that you figured out that you thought
18:38like, okay, they might be hard to implement, but they're really worth it.
18:42Curious to hear more on that.
18:44Yeah, I think the reason a lot of our tools are the way they are, they
18:47reflect kind of the way the teams that build those tools are organized.
18:51So you have your engineering team and you have your design team.
18:54And they both don't fully understand what's possible, because maybe
18:58they're not speaking to each other as well as they should be.
19:00But because of that disconnect, the design team might not understand that,
19:04you know, like anything can be, Intuitive essentially like you can figure out if
19:08something is some kind of data model, you know, just based on what it is And they
19:13may just be told here's like the database model at best and be like we need to fit
19:18things into this essentially Excel chart make make an interface for this and you
19:22end up with a lot more steps than you you may not necessarily have and conversely
19:26developers Might see an interface, propose to them and not really push back
19:31or not want to not necessarily want to rock the boat too much by explaining,
19:35Hey, maybe we don't need this step.
19:37It kind of requires the programmer to also kind of take on a little
19:41bit of characteristics of a designer, like by looking for, Hey,
19:45where are the points of friction?
19:46Can they be reduced maybe in ways that people don't anticipate?
19:50I guess nowadays, like the hot thing is AI and maybe there are like legitimately
19:54useful points in an interface where AI could, could make a difference that people
20:00don't recognize, because again, what one group knows and what another group knows
20:04may not necessarily be the whole picture.
20:06So you mentioned text, drag eggs, images, et cetera.
20:10Are there any particular implementation patterns that you feel
20:14like, okay, this is like a trick.
20:15I'm going to use this across different projects in the future, no matter what.
20:19Oh, yeah, I think this is becoming more and more normalized, but I think the
20:22big thing that I still see on a day to day basis that a lot of apps get wrong
20:27is this idea of like, I'm submitting some information in a field, whatever
20:30form that field may take, and I've got to wait for the server to like get that
20:35information and come back to me saying, hey, it's a 200 before the interface
20:39will let me go on to the next step.
20:41And like 99.
20:4299 percent of the time, that's going to be a 200.
20:45So I think The interface can just assume it's good, it's a
20:48200, and just assume success is what I like to call that pattern.
20:52Uh, if you assume success, then the user puts an input in and
20:55immediately is able to keep working on whatever else they want.
20:58If they do multiple things at once, those atomic inputs just happen and are
21:02assumed to be successful unless they fail, which is, you know, unlikely.
21:06But, It lets you create like, you know, really fast, really responsive
Implementation of Kinopio
21:12So I think another term that's commonly used to describe this
21:16pattern is optimistic updates, which I think if you want to take it some
21:20steps further, this is where that.
21:22And certainly points you in the direction of Local-First.
21:25So based on our prior conversations, it sounded like you did not build
21:30out Kinopio from the start with like Local-First as sort of like the technical
21:35goal post in mind, but you've rather worked on it over time and ended up in a
21:41direction that has many similarities with Local-First, such as that the app works
21:46offline, it is collaborative, et cetera.
21:49So I'm curious to hear more about.
21:51The similarities that you see with Local-First and also learn
21:54more about the tech architecture.
21:56Yeah, I guess another way that I'd put it is like, I only learned about Local-First
22:00after I'd built a Local-First app.
22:01So I didn't know that there was this community of people like
22:04really pushing for, for that particular style of building.
22:07But for me, it was kind of a more natural or organic path.
22:10So, yeah.
22:11Kinopio is the web client but it's also the server.
22:14The server is a source of truth for data, especially when you collaborate
22:17or if you switch devices, you need that information accessible anywhere.
22:21But I didn't start with a server, I started with just the
22:23client and I, I released pretty early to get people's feedback.
22:26So, I basically, taking a pattern from what we did with Glitch, I save
22:31information, your local state essentially, to local storage in the browser.
22:35So I stringify a JSON object and throw it in there and deserialize
22:41it as needed to read from it.
22:42Which sounds onerous, but it's actually really fast, and I still
22:45haven't had a reason to replace it.
22:47But anyways, like, By having that as sort of like the fundamental source
22:51of information initially, especially, it's let me, um, do a couple things
22:55that apps don't do is one, it helps with those optimistic updates.
23:00It lets me load information faster.
23:02So if you refresh Knopio, you don't have to reload your space or board information.
23:07It's already there.
23:08And then it kind of gets updated when the source of truth arrives.
23:12If there's any discrepancies, the other thing it lets me do, uh,
23:15which I think is even more unique.
23:17is you can use Kinopio without having to sign up.
23:19So you go there and the first thing you see is this like sample
23:23space, which is kind of shows you how to use it, but that's a real
23:26space, that's real information.
23:27You can click it, you can edit it, you can create new spaces and that stuff
23:30will be saved if you choose to sign up.
23:33But it's the complete app.
23:34There's no, nothing in front of you, which I think is pretty cool.
23:37Yeah.
23:37I love that pattern.
23:38I would love to see that pretty much in all software, but I think it's really
23:43like a symptom of that most apps are just like, so server heavy and account heavy
23:49that you basically On a technological level, like you can't even have an easy
23:55way to make the software work without a user account with all of that baggage.
24:00But if you build software more in a Local-First oriented way, then the
24:05software should work no matter what.
24:08And that makes it trivial to have a fully working version of the app running
24:13locally right in your browser, you can seed it with like some demo data and
24:17then optionally upgraded into a server account, et cetera, for collaboration.
24:24But I think this is what this new generation of Local-First inspired
24:28apps all have in common with the thinking of something like.TLDraw,
24:32which is a, is a great canvas-based diagramming tool, which you can
24:36also use right away in your browser.
24:40And it's also has local persistence.
24:42It has collaboration.
24:44So I think this is switching this around for making software useful out
24:49of the box without you having to sign up and like pick another password.
24:54I think there's such a obvious thing in hindsight that just makes
24:58it also much more likely to fall in love with, with some software.
25:02I think for for new companies especially or new new startups, it's such a big
25:07advantage if you haven't started that way and you started with the root
25:10assumption that your app needs accounts to function, it's really hard to go
25:14back on that, like, it's basically impossible, but if you've started building
25:19Local-First, this gives you a feature that that larger giants just can't match.
25:24A common pattern that I've seen is like that you basically give away
25:29like free anonymous accounts that you can claim later, but then you
25:33really need to subsidize that and it's not something you can just do for
25:37free, but if you build Uh, software Local-First, then there is no thing you
25:43need to subsidize since the software just like runs in someone's browser.
25:47You don't need to pay anything for that.
25:49So I think, like you say, that gives new startups huge advantage and I hopefully
25:54becomes table stakes for new products.
25:57I think another way to frame that.
25:58is with the idea of resiliency.
26:01So, you know, when Kinopio kind of first launched, it was like front page
26:04of Hacker News for a little while.
26:06And you know, a hundred thousand people visited it like pretty fast, but because
26:10the server didn't even know about them, cause you know, they were mostly making,
26:13like checking it out in their browser.
26:14And some of them would upgrade, but are to like sign up for an account.
26:17But a lot of them would just, you know, kick the tires and maybe come back later.
26:20Like nothing went wrong.
26:22Like nothing mattered.
26:22I barely noticed, because Yeah, I didn't have to worry about like,
26:26Hey, now there's 100, 000 accounts.
26:27And now my database is like inflated or, you know, now my server's on fire.
26:32Yeah, and I think this is, you're, you're touching at a point here that
26:36I'm super bullish about Local-First software is like, you're, you seem to
26:40be working on Kinopio just by yourself.
26:43And you've been working on this for, for quite a while.
26:45And you probably reached by now, like more and more users without
26:50you as a necessity, having to raise VC money and scale a team, etc.
26:55So given that you can put your focus.
26:59On like making the product better and not having to babysit a Kubernetes
27:03cluster to handle the load.
27:04I think that's another benefit of this architecture.
27:07Not having to, to learn what Kubernetes is also sounds like a big benefit.
27:11It's uh, it seems like a lot.
27:13I'm on like the broke boy.
27:15Heroku plan, and it's still fine.
27:17That's amazing.
27:18So you've shared a little bit of like how the technical architecture works in terms
27:23of local state management and how you're persisting data and reading data from and
27:28to local storage, but you can also share Kinopio boards between users and even
27:34collaborate on them, probably real time.
27:37So curious to hear more how that is working, how you've implemented that and
27:41which sort of challenges you've run into.
27:43Sure, yeah, to enable that stuff is, is precisely why I did end up adding
27:48a server early on in Kinopio's life.
27:50So the way it works is it's pretty conventional.
27:52Um, all the things that change your local, your local storage
27:56state also shoot up an update.
27:58To the server.
27:59Um, so there's a source of truth database for all that stuff.
28:02And, you know, all that's connected to your own user account.
28:05So when you sign on on another device, like your phone, you have the same
28:08information in terms of the real time collaboration stuff, I'm essentially
28:13sending a small version of those transformations over a web socket to the
28:16server, which sees who are the clients connected to this particular space of
28:20the time beams, those updates to them.
28:23And those people have their own local storage or local state.
28:27And local storage updated at the same time.
28:29So it's actually, I'm using like the same, like atomic update system, but I'm
28:33using it in three very different contexts, local storage over API requests where
28:38things are authenticated and through WebSockets where they're very fast.
28:42And the things that you're sending over the WebSockets, is this
28:45the entire board state that you send over or is updates events?
28:49Can you describe a bit more how that works?
28:52Purely updates.
28:53So when you load up, like somebody invites you to a space, so you click the
28:57invite link, Kinopio, the web client, will open, see, hey, you're trying to
29:00load up this particular URL with an ID that doesn't, that isn't already
29:04existing in your own local storage.
29:06So I'm going to ask the server, hey, pull this down for me.
29:09And so that'll all come in one big, you know, space, blob or clump of, of JSON.
29:15And as you make updates, iterative updates while you collaborate, like
29:19move a card around, type in some text, those will all just be like
Building Canvas-Based Tools
29:26Got it.
29:27So given that Kinopio is not just like a more traditional web app where you have
29:33tons of forms and like pages and routes, et cetera, but it's a spatial canvas.
29:39This seems to be a more common way now, how software is laid out.
29:44I've never built a canvas-based app myself, but I'm very interested
29:48in learning more about it.
29:49So I'm curious whether you can share some of your learnings.
29:53about building a canvas-based tool?
29:56Fundamentally, there are two main different approaches
29:59when you build a canvas.
30:00So the first approach is you can build it sort of like a website where
30:05each card is a dom node and you know, absolutely positioned and you just
30:09kind of move it around with transforms.
30:11Um, the upside of that is it's really fast and you know, like it'll work everywhere.
30:15The downside is there's a lot of like interactions you do on a canvas, like
30:20pinch zooming and things like that.
30:22are not really handled well by all browsers out of the gate, especially
30:27iOS Safari and, and Android Chrome, for that matter, does a really
30:30poor job in some of these things.
30:32So for example, like I have a UI on my, on my page and I, but I also have my canvas.
30:37If I pinch zoom the phone, I'm zooming in the whole thing, including the UI, which
30:41makes the buttons look wild and crazy.
30:43And I don't want to do that.
30:44I can also like add like special touch handlers to only zoom in that part of
30:49the canvas, but it's really hard to do it in a way Where it doesn't just crash
30:53the browser because the transformed texture of the page gets gets too big.
30:57So a Kinopio document can be like tens of thousands of pixels wide or deep, right?
31:01So it's really hard to design around that.
31:03The second approach, which is by far the more popular approach, is to recreate
31:08the whole canvas in the HTML canvas element or some some similar type of
31:14rendering that you control and you have really fine grained thing over.
31:18And so the upside of that is you have full control over pinching and zooming.
31:22You can tell things to, to leave space.
31:25The viewport like intersection observer equivalent, um, is a lot more reliable.
31:31So browsers don't always report their positions, especially on mobile,
31:34accurately to web apps, as I've found.
31:37And so, being able to control every part of the rendering
31:40process means you control it.
31:42You can make things appear precisely how you want to.
31:46The downside is you have to, you lose all the things you get for free on the web.
31:50You lose accessibility, you lose speed.
31:53You lose like, you know, like special touch handling and other things like that.
31:56And you have to build it in yourself, or more likely you don't really.
32:00And you kind of have a canvas that works great on like desktop
32:03computers, but not so much elsewhere.
32:05And so because of that, Kinopio uses the first approach, which is fast, but.
32:10It requires a lot of work to not be janky and I, I do my best, I'll say that much.
32:15Any particular patterns that you figured out for that first
32:19approach that you laid out?
32:20Yeah, so there's a thing that I do called counterscaling.
32:24So essentially when you pinch the screen on mobile, the whole page
32:28will zoom up, including the UI.
32:30But what I do with the UI is I tell it to scale itself down.
32:34So if let's say you pinched in and the page is now 2x, I tell the UI.
32:38Hey, it looks like the page is 2x.
32:40Maybe zoom yourself down, scale yourself down to 0.
32:425x.
32:43And so it kind of like net makes the UI look the correct size.
32:47So I'm basically like making the UI smaller so that it appears regular
32:51size while you're doing this.
32:52What I found though is that browsers, mobile browsers don't send
32:56resized data and pinch zoom data as quickly as you interact with it.
32:59A lot of events happen in the browser that just aren't reported.
33:02To the browser, because they don't want to like, you know, blow
33:05up the JavaScript or whatever.
33:06There's like little tricks that you do to kind of work around that.
33:09So like, I will fade in the UI during like touch events so that you don't
33:13see things like jitter around as they're, they're struggling to resize.
33:17So yeah, I've learned a lot about how mobile browsers operate
33:20differently than desktop ones.
33:21And, uh, it's, it's a lot.
33:23Would you still choose approach number one, as opposed to
33:27the canvas-based approach?
33:28I think I would, because I've tried like.
33:30a couple times to, to redo Kanopio with different approaches.
33:34The other big downside of the canvas-based approach is it
33:37also makes iteration way harder.
33:40Like adding new features when you have to also render them or like, you know, like,
33:44like at a lower level and figure out how to just work around that sort of stuff.
33:48And you don't have like, you know, the normal flex box type
33:52positioning flow and things like that.
33:53It's a, it's a lot more tricky.
33:55And so I think it's kind of like I've chosen the net best
33:58approach, at least for Kinopio.
34:00And the one that I've kind of embraced because one of the other advantages
34:03of doing a full canvas rendering is you can scroll in 360 degrees.
34:08And with Kinopio, you can only scroll down and to the right as much as you want.
34:11But because of that constraint, You always know where the
34:14beginning of the document is.
34:16It's always in the top left for the most part, as opposed to other canvas
34:20tools where it can be like in the center of the page, which might not
34:23be visible depending on the size of your device and you've got to kind of
34:26scroll around to figure things out.
34:28That's super cool.
34:29In regards to the real time collaboration, so you can share boards with other people
34:35and like work on them at the same time.
34:37Are you going even further to have like a sense of presence across collaborators?
34:42You can do see other people's cursors or how did you think about
34:46designing those interactions?
34:47So, Kinopio has this kind of unique feature called Paint Select or Magic
34:51Paint and basically it lets you select multiple cards to do bulk actions, like
34:55move them all together, but it lets you paint over them to select them.
34:59So instead of drawing a box, you can kind of like make more kind of unique
35:04selections by painting over and it was kind of also a way to like bridge this
35:07gap between the right side of your brain and the left side of your brain.
35:11And so the paint stroke kind of disappears as you're paint selecting, there's like
35:14a exponential decay function there.
35:17And so I also I show those same paint strokes for other people looking at
35:21your space or interacting with it.
35:23So as you're moving around, you see their paint strokes kind of moving
35:26around and fading in the background.
35:28You also see their user icons kind of floating around.
35:30So it kind of creates more than just like the cursor plus user icon.
35:34It kind of creates more of like a feeling of like, Oh, like these people are
35:38like, or someone's really interacting with the space or maybe somebody is
35:40just noodling around in the space.
35:41I can just see their paint strokes and they're trying to spell out words or
35:44draw things before the paint fades away.
35:47That is super cool.
35:48Yeah.
35:48This is, I think goes back to the design principles that did you laid out initially
35:53and how you're not directly imitating paper, but you figure out like what is
35:58the best mechanism here for, for this medium and the goals you're going for.
36:02So going back to the canvas, I recently read that I think Obsidian has launched
36:08an initiative called JSON Canvas.
36:11Um, if I remember correctly, and I think there, do you have some plans
36:15to, to also like integrate with that?
36:18Funny you should mention, I literally, um, just yesterday launched, uh, Kinopio
36:22support for full import and export, uh, you know, um, exporting with that, with
36:27that file format, the canvas file format.
36:30So they launched it yesterday.
36:31I really quickly added it yesterday.
36:33So can you share a little bit more about why that would be useful for, for people?
36:37Sure.
36:38Yeah.
36:38So for the longest time there hasn't been like a great interop document format.
36:43So of course, each different app has its own JSON representation of nodes
36:48or cards and edges or connection lines.
36:51But they're not, they're all app specific.
36:53So, you know, it's kind of tough if you're trying to, you know,
36:55Migrate from one tool or another or test out one tool or another.
36:59And so the closest equivalent we had before, just for a little bit of
37:01historical context was OPML, which is also like kind of a, an off requested feature,
37:06an OPML was kind of made for outliners.
37:09So like collapsible nested tree and you know, structures I can indent now dent.
37:14The problem with OPML is it doesn't handle what happens if you have multiple trees
37:19that aren't connected to each other, or you have multiple trees that might
37:22have child node that they both share.
37:24You know, like you can, you can create structures that are way
37:26more complex than OPML can capture.
37:29And so I just couldn't figure out how to do it with OPML.
37:32So I followed the spec for a while and, and when Capano and Obsidian launched
37:36it, I, I was already kind of in a rework of the importing and exporting system.
37:41So it's a very simple spec.
37:42It doesn't cover every feature that either app has, I'm sure.
37:46But the advantage of that is it's also very easy to implement.
37:48So, you know, it's different.
37:49Transforming from one JSON object to another, essentially.
37:53Got it.
37:53And I suppose that while the spec is like very open ended in some
37:58way, maybe that converges to, towards some more details over time.
38:03And the idea would be that I can bring some data from one tool,
38:07for example, Obsidian into Kinopio or the other way around or future
38:12tools that might, might exist.
38:14Yeah.
38:15It's, but there are wrinkles because.
38:17Of how different these tools are, or at least how different
38:19Kinopio is from all of them.
38:21So there are assumptions and I've, I've left like feedback about these
38:24things in, in GitHub issues for the spec, but there are like assumptions
38:28that they make like, um, the node has to define like how wide it is
38:32explicitly, or what type of node is it?
38:35Is it a file node?
38:36Is there a, you know, like a website node or whatever.
38:39So problems with both of these is that like the width, Of one app's node for the
38:45same amount of text might be different for another app because they're all rendering
38:49it differently in Kinopio's case.
38:51There's also this.
38:52It's also mobile compatible.
38:53So there's a bit extra of padding and sizing for touch friendliness.
38:57So those numbers don't really translate.
39:00And so it's kind of weird that they're required in the spec
39:02as opposed to being optional.
39:03Second issue was the node type.
39:05So I can mention a long time ago.
39:07Or earlier in this chat, you know, a lot of apps make you choose, like, Hey,
39:10are you going to insert a web page?
39:11Are you going to sort of whatever?
39:12On Kinopio, they're all the same type.
39:14They're all just, there's only one type of card, a text card, and whatever
39:17type of content you put in that, whether it's a link or a website or
39:20whatever, is what that card transforms into using the power of regexes.
39:24And so that part of the whole spec is basically, like, not
39:28necessarily relevant to Kinopio.
39:30Didn't really connect because It's making the assumption
39:33that that isn't really shared.
39:34So in some ways I think it's too specific in some ways it's, and I'm sure
39:38a lot and a lot of people's complaint is that it's not specific enough.
39:42So it's weird because like it's really hard to make a
39:45spec for wildly different apps.
39:47But I think currently I'm actually pretty happy with the spec because it
39:50captures like the most important part, which is the representation of cards
39:55and nodes in a way that doesn't require them to have this strict tree structure.
40:00Yeah.
40:00That makes a lot of sense.
40:01And yeah, I mean, the devil's always in the detail and you built Kinopio really
40:06to enable the sort of interactions and details that you uniquely thought about.
40:11And you might not have that entropy available in Obsidian and vice versa.
40:17And then it's also, how do you preserve that intent and
40:20that information across apps?
40:22That's, that's a very tricky problem, but I, I applaud the initiative to take
40:27some first steps there to at least bring some data across one app to another.
40:32So that sort of cross app collaboration, I think that is certainly a goal that I'm
40:37rooting for, but that we still have like many chapters still ahead of us there.
40:42So the way I've built Kenopio, it's super impressive, both in terms of like how
40:48the product feels and works and looks, but also like, given that you've been
40:54on this journey for, for such a long time, uh, by, by yourself, I'm curious
40:59which corners you might've already cut along the way that you regret looking
41:04back where you wish you would have like spent up front or vice versa where you
41:10thought something might be a problem and it never actually became a problem.
41:13Oh, wow.
41:14Yeah.
41:14There's, there's definitely a lot of those.
41:16So like, there's like a lot of code kind of like with the syncing engine, uh, and
41:21the way I merge, um, different changes to make smaller change sets that get
41:25sent to the server, but I feel like.
41:27are a little hard to work around now in just in terms of like just how gross
41:32that code is or how like abstractive and I wish I did a better job writing
41:36it like it's not it's not something that's painted me into too harsh a
41:39corner it's just something I'm like oh I'm scared to touch this part of
41:42the app but one day I'll just you know buckle down and and really get to it.
41:47So I actually think the app is in a pretty good place just because um I
41:52guess the other thing is like I prefer to like write code that's like, not
41:57necessarily for me to understand now, but for me to understand in like two
42:00months or three months or five years from now, where I forget what the S variable
42:05or the A variable is referring to.
42:07So I, I, I was like kind of influenced by, by some short time, like,
42:13Coding for Apple platforms where they're very verbose with variables.
42:16I kind of took some of that Coco convention into my own
42:20kind of code writing style.
42:22Yeah, I think that's very wise.
42:23Uh, I've made the same observation about myself since in reality, even
42:28if you just work by yourself, you still collaborate with yourself.
42:32Over time more instances of you over time the future you, the past you.
42:34who do not the same context right in your brain
42:42So just like leaving notes for yourself of like, why did you do a certain
42:48thing has, I, I've had to learn that lesson painfully and I'm treating my
42:53future self better or I'm trying to, so, uh, it looks like you've learned
42:59quite a couple of similar lessons, but
43:01Yeah, I think we all kind of learn that, but we all have to, like, burn ourselves
43:04a little bit before we truly learn it.
43:06Because it's not, like, an intuitive thing to know.
43:09And it is, like, in an industry that's always trying to, like, move fast and
43:12ship fast and whatever, it's a little, it's mildly antithetical to that.
43:16But it is one of those things where, take a little extra time to write
The Journey as a solo-developer
43:23So you've been on this journey by yourself now for quite a while after
43:27being in a more conventional team context at Fog Creek working on Glitch.
43:33I'm curious whether you can reflect a little bit on that
43:35journey now working on Kinopio.
43:37What are the good things?
43:38What are the challenging things?
43:40What are the things you wish you would have known before
43:42embarking on this journey?
43:44Yeah, there's definitely pros and cons to, to working by yourself
43:47or for yourself versus in a team.
43:49The obvious things are like, yo, camaraderie when you're having a bad
43:51day, you know,, you're in it with other people and, and, you know,
43:55like the pain can be absorbed by many people kind of thing or the struggle.
43:59But actually in reality, like, I don't, I kind of work alone, but I
44:02also kind of don't in the sense of like, there are other creators building
44:05great projects out there like MM doc.
44:07page or TL draw, et cetera.
44:09Uh, and so it's kind of like, Even though some of them are sort of competitors in
44:13the way, but sort of not like Muse as well, because we're all kind of on that
44:16same hill, we're all kind of struggling and we're all kind of in a similar place.
44:20It kind of acts as like a de facto team, even though you're not necessarily
44:23like in contact with them every day.
44:25Uh, they're also the companies that I've contracted for, like
44:27Futureland, which is also kind of like a early stage startupy company.
44:31I can see that they have similar challenges that I have in terms of, you
44:35know, getting the word out and stuff like that, or just refining the product.
44:38And so.
44:38In that sense, it's like, I think, I think you mitigate like a lot of
44:42the sort of downsides of, of not being in a, in a large organization.
44:46But I also kind of like, like in addition to sometimes working as a
44:50contractor, I also employ contractors or I'm starting to, and so I've
44:54gotten some really great database performance optimizations, um, from a
44:58friend named Lucas who I met in Bali.
45:00Yeah.
45:01These are things like, Oh, I like wrote the indexes wrong and I didn't know how
45:04to check them or like, Hey, I could.
45:06Make merge these database calls into one simpler one to make like
45:10really dramatic beat improvements.
45:12And so, like, it is great, you know, finally having just a
45:16little bit of the resources to be able to do that sort of thing.
45:19And I kind of want to continue to new more and down the path until
45:22it sort of stops making sense.
45:24Yeah, like, it's kind of one of those things where you see, I feel
45:27like I've learned what works and what doesn't from my time working
45:30at other people's companies.
45:31And I'm kind of, you know, Testing all those hypotheses now, uh, as I build
45:36Knopio and, and, you know, ideally sharing in my blog and on Twitter and
45:40whatnot, how that's working out and what I was wrong about or right about.
45:43Yeah.
45:44Thank you so much for taking the effort of, of sharing your, your
45:47learnings and experiences there.
45:50Highly recommend for, for every listener to check out your blog that
45:54has its own very unique style, in the same way as Kinopio has its own
45:58style, your blog has like a very organic style, which I really like.
46:02It's very inviting to, to read about your, your different blog posts, et cetera.
46:06I guess, speaking of organic and that blog, like one of the funny things about
46:10it is it's actually like extremely organic in the sense of like, I designed the first
46:14version of that blog in 2014 or before that on a trip to when I was interviewing
46:19at Flickr, newly bought by Yahoo in San Francisco, back when they used to
46:24fly you out for tech job interviews.
46:26And so I'd, I'd built lots of like blogs in the past, like personal
46:30blogs, but I kind of wanted like something new back in the day.
46:32That was a de regard thing to like start a blog and then get
46:36bored of it and start a new one.
46:37And so this is the one that stuck, but essentially like, Over the years, I've
46:41been like slowly tweaking design and slowly adding features like blog post
46:46tags and actually a couple months ago.
46:48I just added commenting and before that, like a little bit
46:50of newsletter functionality.
46:52So it is very much like this thing.
46:54That's kind of collected pieces of it.
46:56As it's rolled down a hill.
46:57Yeah.
46:58I think there's also this term of digital gardening, which I am also very drawn to.
47:04I have not evolved yet myself to, to reach that level of like organic feel.
47:10I think my blog right now is like much more neutral and traditional.
47:14So.
47:15You've mentioned initially that you didn't always happen to be an
47:20engineer and a designer, but you found your way towards design and
47:24engineering by actually starting out studying biology and urban planning.
47:29So, I'm curious to learn more about that journey and that transition
47:33and which sort of maybe unique perspectives this has given you.
Applying Biology & Urban Planning principles to Software Engineering
47:37Yeah, I went to school for biology and then I did my grad studies in
47:39urban planning, basically because I like SimCity and initially because
47:42for biology, because I didn't have anything else to do in university.
47:45Uh, but from there, like from, especially from the urban planning side, I'd
47:48always been doing, like, using Adobe Illustrator for like illustrations and
47:52stuff just for friends and for fun.
47:54But in grad school, I also had to do like mapping and more formal presentations.
47:58And one of the things I sort of realized in that environment was like,
48:01we'd have to present this like huge paper and we'd have these like little
48:05dioramas to go with it with like, you know, figures and maps and stuff.
48:08And all the people grading it didn't read the papers because
48:11they were boring as fuck.
48:12They're just like policy and stuff.
48:14But they would be like, wow, this is so cool.
48:17Wow.
48:18the use of fonts and whatever and great colors and stuff and so yeah it kind of
48:22like taught me that like oh okay like even like the most like unapproachable or high
48:27minded academia types they're all kind of drawn to like what's beautiful or what's
48:31shiny we're all just animals at the end of the day so It kind of made me, like,
48:36leave the urban planning world and go more into, like, the illustration world.
48:39And that's where I kind of got my first job in tech as a staff illustrator for
48:43a company that did, like, banner ads.
48:44Definitely the dregs back in the day.
48:47Um, but from there I did design work for them, like app design
48:50work, and then from there got pushed into doing more development
48:53to build things that I designed.
48:55Uh, it was a real kind of trial by fire situation.
48:58Um, But that's how, that's how this kind of thing started.
49:02It all started with illustration, then design, then building
49:04the things that I designed.
49:06Are there some learnings that you take away from biology or urban
49:10planning that you now apply to designing or to software engineering?
49:14I guess kind of at a high level way, like biology and urban planning are both sort
49:18of the The study of systems, like the systems in your body, or the systems of
49:23how traffic flows on the street, or how, you know, like cities develop, um, from
49:29like medieval towns into regimented grid, like, uh, structures and and streets.
49:34And so I guess, um.
49:36One example is like when you see like how people organize themselves and
49:40their teams or how they, you know, like identify their projects, there
49:43are kind of a lot of similarities.
49:45It's almost like a pale imitation of biology and city planning
49:49or in terms of the complexity.
49:51But so I'm really inspired by, like, the biological process mitosis for one,
49:56where an individual cell gets really big over time and at a certain point,
50:00moving information from the edge of the cell to the middle, like the nucleus,
50:05where all the processing is done.
50:07Um, the high level thinking is done gets it takes too long.
50:11And so what a cell does is instead of, like, adding scaffolding or trying
50:15to, you know like make that, that cell more complex than it should be.
50:20It just splits itself into two pieces, obtaining like the core parts from
50:25both so that each little, little new piece can be much more efficient.
50:28And I think, you know, that's something that like, that we do when we try and
50:32like cut down scope, break a big problem into small problems, or just, you know,
50:37break a big document into little ones.
50:39And that's also why I like, That's also kind of the heart of the thinking
50:43of cards as an atomic unit of thought with a character limit, kind of
50:48like a tweet level character limit.
50:49It's because it, that constraint does force you to think
50:53more, I guess you could say.
50:55Yeah, this is fascinating.
50:56I think there's so many, Ideals in software engineering that I'm drawn
51:01to such as like composability and like principle of like locality and now that
51:08you say it, uh, those are like nature got that figured out like long time
51:12ago where like all of our organs and like on a much smaller scale, this all
51:17composes and there's things emerging, us emerging, civilizations emerging.
51:23So yeah, I think there's the great Case study to study nature and be
51:29inspired for building better products.
51:31Yeah, absolutely.
51:32It's one of those things where you see it and then you can't unsee it.
How to become a better designer?
51:35Yeah.
51:35Thank you so much for, for sharing that perspective.
51:38So you're not just a great engineer, but also a great designer that shows in like
51:43all the products that you're building.
51:45And I think that sort of intersection of being an engineer and a designer,
51:50I think that's a, Rare trade that I feel myself very drawn to.
51:54And I want to learn more about that.
51:56Are there any sort of hints or words of advice that you would
52:01give people how they can, as an engineer, become a better designer?
52:05Yeah, that's a great question.
52:07I think a lot of the, the applications we have now, like one example, uh, that we
52:11talked about with, you know, you submit a form and then you've got to wait For the
52:14form response to come back from the server before the app lets you do other things.
52:19And a lot of that is caused by a disassociation or a separation between
52:23what a designer thinks is possible.
52:25And when an engineer is like, like their level of interest in the design.
52:29And so I think if to answer the question of like a programmer wanting to do
52:33more design, I think a trap people fall into is like, there's two traps.
52:38One is, Hey, I need to figure out how to make things look better.
52:41Pretty before I start and like, you know, how do they like what is attractive?
52:44What is aesthetic?
52:45So thinking of design as as like, you know the lipstick on a pig it's
52:49definitely a trap I feel people fall into but I think the other side to it
52:53is like not understanding that design is kind of like Being a chameleon
52:57for whatever you're designing for.
52:58So let's say you're designing an app for nurses to do some sort of nursing task.
53:04The designer's role in that case isn't necessarily to be like, Hey,
53:07how do I make this button look great?
53:09But to be like, what does the nurse need?
53:11Like, when do they need it?
53:12How do they need it?
53:13And that's things that an engineer should also know.
53:16And In situations like that, where both, both sides of the product building
53:21experience, whether that's your own head, both sides of your own head, or a separate
53:25engineer and developer, they both kind of come into it with the idea of like,
53:28hey, what's the best thing for a nurse?
53:30Uh, when do they need it?
53:31What do they need?
53:32Like, that's how really great design happens.
53:35And yeah, an engineer also has this advantage of knowing,
53:39having access to like, technical information that a designer doesn't.
53:42So one example in Kinopio is, you know, as we mentioned, like, you can just
53:46click to type a card, and you can type freeform text, and that'll be a text
53:50card, or you can drag an image in, or paste in an image URL from wherever,
53:54and that'll also become a thing.
53:57That's because, as the engineer side of my brain knows, hey, we can just
54:01use regex and determine what is what.
54:05There may be new opportunities for that with AI, but the
54:08fundamental idea of, like, just.
54:10Like, knowing that you know something that someone else doesn't know.
54:13It's like, like, like thinking past what you can see and kind of knowing the full
54:18possibilities of what you can do is kind of the most important part of design.
54:22Yeah, that, that's great advice.
54:24Uh, I think about like most things that you use to build stuff with as
54:29materials that's in the real world, but also digital materials, whether that's
54:34code or whether that's other things.
54:37And so I think it's actually more folks should try to assume a bit of
54:42like different disciplines as well.
54:44Like look at the same material from different angles, from the engineering
54:48angle, but also from the design angle.
54:50I think this is where you can build much better products.
54:53And also quoting a previous episode we've done with Rasmus
54:57Andersson, who's referenced this concept of mechanical empathy.
55:01This is very much from like a engineering perspective.
55:04What does the material allow me to do?
55:07What does like the, the hardware this is running on allow me to do?
55:11Or what does the web ecosystem allow me to do?
55:15Do I use the DOM?
55:16Do I use the canvas?
55:17And, uh, those materials that I have available.
55:20What does that allow me to, to build the best product?
55:23So thank you so much for, for sharing all of this with us.
55:26Is there anything that you want to tell the audience or share with the audience?
55:31I guess if I want to share one thing, it's something we've already mentioned.
55:34Um, my blog, which I have been writing on and off for, I guess, since 2014.
55:39Don't read the old articles.
55:40They suck, but the new ones are pretty good.
55:43They're, I kind of try and write about.
55:45technical or design topics in a way that's more approachable to
55:48even non technically minded people.
55:51They give like, you know, a lot of high level overviews of how Canopia was made,
55:54how Glitch is designed, things like that.
Outro
56:00Perfect.
56:01I definitely recommend that.
56:02I've enjoyed the few blog posts I've read quite a lot.
56:06So yeah.
56:08Thank you so much for coming on the podcast and sharing all of your wisdom.
56:12Thank you.
56:13Thanks so much for having me.
56:14Thank you for listening to the localfirst.fm podcast.
56:17If you've enjoyed this episode and haven't done so already, please subscribe and
56:21leave a review wherever you're listening.
56:23Please also tell your friends about it.
56:24If you think they could be interested in local-first, if you have feedback,
56:28questions or ideas for the podcast, please get in touch via hello at
56:32localfirst.fm or use the feedback form on our website, special thanks to Expo and
56:38Crab Nebula for supporting this podcast.