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