Metamuse

By Adam Wiggins, Mark McGranaghanTechnology

Metamuse episodes

January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Which by the way, something that’s a little bit
unique to digital systems versus classic analog systems, you know, if
your wrench is rusty or doesn’t work as well, but it still basically
works as a wrench, whereas if you have one bit off in your software,
just crashes, you know, you’re out of luck.
00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for
thought on iPad and Mac. But this podcast isn’t about me as the
product, it’s about me as the company and the small team behind it.
I’m Adam Wiggins here with my colleague Mark McGrenigan. Hey, Adam,
Mark, you were giving us a very interesting little workshop at a team
summit recently about the use of iPads in aviation.
00:00:44 - Speaker 1: Yeah, so aviation is one of the most interesting
and powerful use cases I’ve come across for iPads in the wild.
It’s so powerful and important that folks are willing to spend $100
200 dollars, $300 a year for high-end aviation-related iPad software.
So there’s something right going on there, no pun intended.
And as I’ve been exploring that world, there’s a very interesting
contrast and sort of technology share between these super shiny iPads
and this new software that’s being updated constantly, and the very old
general aviation aircraft you tend to see out there.
This is the Cessna from the 60s, which by the way, is basically exactly
the same as it was 60 or 70 years ago.
And then they’re being flown with these iPads from 1 to 2 years ago,
and it’s very interesting to compare and contrast those worlds, and it
led into this topic today actually because we were noticing that
longevity of the aircraft versus the almost ephemerality of the iPads
and the software and how much churn there seems to be in that world.
So we want to dig into it on the show.
00:01:51 - Speaker 2: So Cessna, which is kind of a small private plane,
is an extremely complex piece of technology and also one that is used in
very high stakes situation, i.e. if it fails, you fall out of the sky
and die, and it has very complex controls as well, but those are all I
guess analog is the right name, but, you know, again, they look the same
as they did in the 60s, even new ones built today, and the ones built in
the 60s, they continue to, essentially, you need to maintain them, you
need to replace parts and upgrade them to comply with newer aviation
regulations, but Again, they haven’t changed much in that underlying
technology and that’s so wildly different from the world of not just
iPad, but software and internet in general where change is at an
incredible pace and in fact that’s probably desirable in this what’s
the piece of software that’s kind of the commonly used pilot software.
00:02:44 - Speaker 1: For flight is the most common one.
00:02:46 - Speaker 2: So that’s got maps, it’s got weather, it’s got
flight routes, it’s got locations of other planes, all of the stuff is
being presumably downloaded or even streamed in through APIs. It’s all
very real timey and current information, and you want that, in addition
to just keeping up with all the new capabilities of the iPad. So you get
maybe that separation is nice, you get the benefit of the really fast
moving software and internet world that’s on this device that’s
strapped to the pilot’s knee, but it’s completely decoupled from the
safety reliability oriented core instruments that are built into the
plane.
00:03:24 - Speaker 1: Yeah, researching this reminded me a lot of
navigation in cars. So my experience has always been if you buy or if
you see a car that has like built in navigation, it’s always gonna be
bad because it was designed 2 to 4 years ago and it wasn’t designed by
a software company, but everyone just wants to use their iPhone, right,
to navigate and they want to be able to plug it in and have it just
their iPhone apps be displayed in the car. That’s a good way of
embracing the reality that there is some shear between those two layers
in terms of how fast the technology tends to evolve.
00:03:54 - Speaker 2: So then our topic today is software longevity, and
I think you can slice this two ways. One is the software itself and how
long that lasts or how durable that is, and then you can also cut it the
other way, which is, yeah, software is eating the world or is invading
everything from, you know, toasters to cars, and how does software’s
dynamism impact the longevity of everything else as it creeps its way
into the rest of our world. But as always, I like to start at the very
beginning. So I guess first I have to ask what it means to you to talk
about something being long-lived or having longevity, whether it’s
software or a plane or something else.
00:04:35 - Speaker 1: Yeah, I think it’s the software being able to
serve its stated purpose, which sounds very straightforward but has
several important constituent parts. First of all, you actually need the
software, you know, sometimes we just lose it. It needs to run, it needs
to run correctly and needs to have access to the relevant data, needs to
have access to the relevant pieces of the outside world in terms of
APIs, and it needs the appropriate substrate to run on and interact
with, and that’s probably other pieces that we could come up with. But
there’s a lot of moving pieces that go into the software actually
serving its original end goal.
00:05:07 - Speaker 2: For me thinking about that word longevity. I tend
to think about what is long, I guess, what is a span of time that counts
as long and of course it depends a lot on. What you’re talking about.
So if you’re talking about all of society, culture, humanity, then
perhaps you’re talking in the thousands of years, hundreds or thousands
of years. So for example, the long now is a phrase that we used in the
local first paper, we tend to use it internally on our team to refer to
longer term thinking.
This comes from the Long Now Foundation and the Long Now clock project,
which is sort of this idea to build a clock that can keep time for, I
think it’s 10,000 years. And it’s basically an art project, but it’s
designed to inspire us to think longer term, and that can obviously
connect to things about climate change or human culture, and since
humans are naturally inclined to think probably pretty short term,
actually really short term, we think about the day that’s ahead or the
week that’s ahead of us, maybe at most, the year that’s ahead of us,
we don’t tend to think in 10s or hundreds or thousands of years.
So it’s maybe a society level thing. I think for individuals and
thinking about, you know, softwares that impacts our lives as
individuals, I think there a human lifespan actually is a pretty good
chunk of time to compare something to.
One interesting subreddit that I stumbled across years ago and still
subscribe to is called Buy it for Life, and it’s essentially people
just posting. Photos or anecdotes of products they purchased, they’re
often something like a cast iron pan handed down by their grandfather or
a pair of work gloves they bought 30 years ago that are still working
just as well as the day they were purchased, and I think implicit in
that is that there’s some kind of inherent beauty or virtue in
something that does have this long lasting value versus something
that’s more flash in the pan.
And it’s interesting for me to try to tease apart the pragmatic aspect
versus the, yeah, that inherent beauty. Which again, it feels to me like
a virtue, but I’m trying to like dig a layer deeper and see if there’s
something practical that drives that. Maybe it isn’t, maybe it just
comes from a place that it seems right to me that something like
products you purchase, that their lifespan of the product could be
measured in something that is a portion of a human’s life that’s not
thrown away in a month or a year even.
00:07:32 - Speaker 1: Yeah, and I think we can come up with a few good
reasons why longevity is valuable.
The zero reason would just be economic, depending on how long lived a
product is, it has different economics.
On the one extreme you have consumables like toothpaste, you know, you
use your toothpaste, it’s gone forever. On the other extreme, you might
have. Extremely durable things like stone tablets and mason
reconstruction that could last hundreds of years. And in the middle you
have the classic capital goods, durable goods, things like really nice
hand tools or really well maintained car that you expect to last at
least several decades, potentially longer, like you were saying a
lifetime or more, and the economics of those things are all very
different. This goes a little bit back to the pricing podcast that we
had a while ago. Another thing is I think just continuity, like, for
example, if you run a business on a piece of software or you run your
own creative process on a piece of software, there’s real costs to
churn in that. And another thing would just be preserving history, you
know, having access to the past. I think this is especially important
with software because it’s very easy to lose that both in the sense of
the software itself and the data that it was manipulating.
00:08:36 - Speaker 2: And that side of it makes me think of some of
these submergent field of sort of digital preservation, archive.org is
probably the one of the biggest players they’re doing incredible work
to save copies of websites, but also product manuals and old video
games, and indeed other kinds of software. And maybe that brings us to,
when you do leave the world of durable goods, it brings us to the world
of information and information longevity.
00:09:02 - Speaker 1: Yeah, and one other point I want to add relates
information is, I think there’s a dimension of longevity, which is, and
I’m gonna make up a word here, roll over ability, you know, the ability
to buy a new or get a new version of something that rolls over your
previous state. So for example, like maybe you rebind a book or
something in that way roll over the pages, or you can put a new engine
and transmission in a truck and you roll over the truck frame. But some
stuff can’t be rolled over. Classically the black box data, just some
opaque binary format now you basically like once that software is gone.
So I think that ability to roll over is an important dimension, even if
it’s separate from a single instance having long longevity. Hm.
00:09:42 - Speaker 2: Yeah, well, information has this particular
property that exists on a substrate or a medium of something physical
atoms, but in the end, the information is not the physical thing.
So, the book rebinding example, you can either rebind the same book or
in some cases just transcribe it completely and as long as it’s a
correct and accurate copy.
Older books are an incredible artifact, maybe they have margin notes,
something about how the pages were made or whatever does carry some
history.
There were the artifacts and objects of their own right, but ultimately
the contents, the words on the page are probably what we care about. And
so on one hand, information technology has actually been getting worse
in the sense of the durability of the underlying thing, right? stone
tablets were very durable, papyrus and later paper were less so, then we
go into the digital world and it’s actually vastly less so, you know,
everything from CDR. to cloud storage, the failure rate is pretty high,
but because it is so easy, cheap to copy those bits from one place to
another, to replicate it, you potentially have the ability to roll it
forward as far as it’s worth your while to do so.
Right. Then if we sort of come to software as a special class of
information, and it is information, but it’s highly dynamic, and I
think that points to some of the particular challenges with it in, I
guess that would be sort of the first category that I mentioned there at
the beginning, which is the software itself and its ability to be long
lived.
And I think some of this is cultural, you know, the tech industry is
dynamic, it thrives on change, that’s sort of the nature of it and many
things that are good about software and the internet and the tech world
come from that willingness to embrace the new and almost an endless
seeking of novelty.
But the downside is, yeah, you get something that is not just an upgrade
treadmill, but it just seems like it can be very much the case that the
lifetime of a product or of data or any particular piece of software can
be measured in Again, years and only a small number of years, which is
comparatively just a very, very short time span. But I guess one
question is, why is that? Why should software sort of default beyond
just sort of tech? Maybe that’s what it is, but I, I feel there’s more
to it than just culturally, the tech world doesn’t do the buy it for
life, built to last thing. I feel like there’s something inherent to
the dynamic information nature of software that makes it hard for it to
be long-lived.
00:12:11 - Speaker 1: Yes, I think that’s true.
There is a lot of things that need to go right for software to work, and
you can see it in fact as something that’s strictly harder than
preserving simple textual information for the following reason.
You have at least that problem to start because you have the source
code, then you need to preserve information about the dependencies, you
potentially have the compiled source. And then you have the whole run
time around it very broadly defined, you know, the computer, the APIs,
maybe even the data, and it’s just a very broad multi-dimensional, and
in many cases ill specified. State space that if you don’t get your
thing exactly right in that state space, it doesn’t work at all, which
by the way, something that’s a little bit unique to digital systems
versus classic analog systems, you know, if your wrench is rusty, you
know, it doesn’t work as well, but it still basically works as a
wrench, whereas if you have one bit off in your software just crashes,
you know, you’re out of luck. It’s very high dimensional and it’s
very sensitive to errors in preserving the environment.
00:13:15 - Speaker 2: I think it’s one wants to even think of a binary
artifact.
So here you’ve got a compiled executable, you can download it, you
don’t need the dependencies, you don’t need the compiler chain, and I
think there’s the feeling that shouldn’t that just kind of work
forever, but of course it’s as you said, it sits within this context of
the system.
If it’s accessing files on your file system, it’s calling out to APIs
on the network, it’s accessing APIs in the operating system, even
something like it just makes assumptions about what kind of hardware
exists on the keyboard and mouse as being standard input devices that
exist, and then you go onto a touch device and those aren’t there. And
so over time those fundamental assumptions and APIs and the system
changes around it. And I think that’s gotten dramatically more so with
the internet, where you might call out even something as simple as a
static website that has a Google Maps embed. Well, now, a big portion of
that website, this big pain is depending on this exact integration to
the service, and that that service is still online. And so I think that
the one-off binary build shouldn’t have worked forever, does make some
sense, for example, games, which kind of don’t have as many hooks, so
let’s say just like a single player game, not some Complicated
cooperative thing, but it tends to have very simple inputs and outputs.
Displays things on the screen, maybe it needs to save a high score file
to the disk as opposed to productivity software where all those little
integration points you drag and drop and how do you open a thing in the
browser and what all the different APIs that use to be a good citizen on
the system, and those change all the time. They should with an operating
system that’s growing and improving and evolving, but then that means
the apps have to keep up with that, and if they don’t, they fall out of
date and eventually either become Somewhat irrelevant or more commonly
just stop working.
00:15:05 - Speaker 1: Yeah, I think this idea of the complexity of the
surface area and the APIs is very important.
You mentioned games. I think we actually had it much easier back in the
good old days of games where he’s had keyboard input, mouse input, you
draw to a pixel buffer, and that’s it.
The issue with games now in addition to stuff around networking and
multiplayer is the graphics pipeline is incredibly complex. And unless
you end up emulating earlier versions of graphics pipelines, I think
there’s little chance that this stuff rolls forward, whereas you could
plausibly roll forward writing into a pixel buffer, you can kind of go
the other way. You can emulate a pixel buffer with our advanced graphics
APIs today, but you have no chance of going the other direction. And I
think this generalizes to API complexity broadly, and it’s one of the
reasons why it’s gotten so hard for software to persist.
00:15:54 - Speaker 2: Games also make me think of the, we’re speaking
briefly about the Internet archive and yeah, you mentioned emulators,
and it turns out that games seem to be both something that people do
want to preserve as a cultural history, but in a way, the best way to do
that is not try to get the original hardware, but in fact, just to have
these emulators like Maine, for example. And it’s really impressive,
yeah, you can play almost every arcade cabinet video game from the 80s,
just in your browser with these kind of JavaScript emulators that would
load up the ROMs, which are basically the way they distributed binaries
in those days, and play them, not quite as they were intended, because
again, the hardware is different. Certainly the displays are different,
but certainly we do preserve some of that legacy. Now another one from
Games that maybe is your roll forward idea. I really like what ID
software does, which is they take their classics, Doom and Quake, and so
on, and after, I don’t know, they’re 2030 years old, something like
that, they open source them. And that creates this interesting effect
where maybe it’s less that people are playing the original, although
I’m sure that happens. But then it becomes fun to just port it to weird
places, right? Like you’ve seen quake that’s been ported to like be
100% Asky. I think I saw a Twitter thread recently where someone managed
to, they broke open one of these digital pregnancy tests, realized that
it had a reasonably good processor and display in it and decided to like
get Doom running on it. Oh yeah.
00:17:24 - Speaker 1: Yeah, it’s a whole culture, you know, people
running on the refrigerators and exactly, yeah, so in a way, it has
turned this over to remix culture and the internet.
00:17:28 - Speaker 2: And so it gets rolled forward and becomes
something that maybe people will experience none of this original form
necessarily, but becomes woven into the cultural tapestry, let’s say
through these fun little projects.
00:17:46 - Speaker 1: I think this also speaks to the importance of that
API environment that we’re talking about either being specked or at
least specable for the software to be rolled forward or actively
preserved, either one.
Like we’re saying, old timey games, that’s a pretty specable
environment like you need to build a compile C and relatively
straightforward input and output. System and even if the games weren’t
designed specifically with a really clean interface there, you could
basically back it out after the fact and then do the porting.
Books and paintings, by the way, are examples of analog things that are
very specable. They map down to text streams and bit maps respectively.
But some stuff like our modern software is much more difficulty being
specked, and so it becomes harder to do that sort of rolling forward or
active preservation.
00:18:34 - Speaker 2: Now, some have argued that perhaps part of the
challenge here is the rapid pace of change of that underlying system of
those APIs.
I think it’s interesting here to contrast the Apple versus Microsoft
approach. So I think that, you know, Microsoft with DOS and later
Windows really focused on backwards compatibility, quite an impressive
level.
I’m not exactly sure when the cutoffs are, but I think you could run
DOS stuff natively on Windows till well into the Windows lineage, and
then Much later versions of Windows could run much earlier versions, but
that’s part of, I think what also created the relative instability and
unreliability of that line of operating systems, such as when you need
to support every conceivable thing that’s ever existed in the past and
put it all together in the same box, things get messy pretty fast, and
Apple, at least with the iOS world has gone very much the other route.
Which is they basically are releasing new stuff, a new OS update once a
year, and if app developers don’t keep up to date, you pretty quickly
just fall out of the App Store.
So, I experienced that with, I wrote a little puzzle game for the iPhone
10 or 12 years ago, I think it was on like iOS 3.
And yeah, my collaborator did some work to try to rebuild it with the
new stuff and keep it in the app store, but I think by OS 5 or 6 it just
fallen out.
And it’s a shame there’s basically no way to play this game that was,
you know, fun side project and we spent some good effort on it’s just
sort of lost to history because you have this very kind of demanding
operating system that requires developers to be doing active maintenance
or else it tends to go away.
00:20:16 - Speaker 1: Yeah, and while I don’t doubt that there was some
contribution in the Windows situation to instability from needing to
support all versions forever.
I think what really gets you is when you need to do that and things that
are really end user facing like visual in particular, because the
strategies that you typically use for providing stability are not viable
in that world. So if you look at things like Unix style server operating
systems, many programming languages, these are things that can have
backwards compatibility for a long time, certainly decades. But the way
they do that is they just never ever ever ever break any APIs and if you
want to do something new, either A too bad or B, call it thing 2 and
just keep thing one around forever.
00:21:00 - Speaker 2: Python 2 versus Python 3 comes to mind.
00:21:03 - Speaker 1: Oh yeah, well that one, that’s a whole thing.
There’s an element of that of not wanting to break Python too, but even
just individual methods, you know, when we write our own programs, we
think of, oh, we need to change the method, just like edit the source
code.
Well, not so much if you have the entire universe relying on thing one,
you just gotta keep thing one around forever and write a new thing too
that people can call into. Anyways, you can’t really do that with like
a windowing system, for example, or a user interface paradigm or how
things look on the screen, right? You just gotta pick something and do
it, and the old thing needs to go, and so I think it does become very
hard to have that culture of very long lived durability that you see in
some of these more systemsy programs.
00:21:43 - Speaker 2: Yeah, maybe that points to the fundamental
trade-off there, which is durability in many cases means stability,
which means less change.
But change is how we get things that are new and better in the world of
technology and computers and the internet is so at the very beginning.
There’s so much unexplored space, and it would be a shame if we just
said, OK, well, we’ve been working on making these computers here for a
few decades now. Yeah, pretty much how they are is probably it, it’s
probably good for the next several 100 years. Let’s just hold it there.
That’s not what we want to do. Uh, we want to keep changing and
improving. So, yeah, there just is a trade-off between those two.
00:22:18 - Speaker 1: Yeah, I think there’s a very real tension, and I
agree we want to keep exploring. I do think that in adopting this
attitude of exploring and taking risks, we are going to find some things
that in retrospect were not good choices.
The intuition here is, I think we’re projecting these very dynamic
system benefits over lives that we have historically associated with
durable goods, you know, so we get the shiny new computer enabled
software enabled thing. And it works great the first year, and we think
things like this, before we had computers, they worked for 20 or 30
years, therefore this thing is gonna work for 20 or 30 years, and it’s
gonna be awesome.
And we’ve kind of projected that all forward, and I think in many cases
that’s not gonna be true, and so we’re going to have to confront the
downside of that trade-off.
00:23:04 - Speaker 2: And do you think the downside there is mainly
economic? You buy the smart refrigerator seems great for the first year,
some cloud service goes offline, suddenly your refrigerator doesn’t
work anymore and you got to throw it out and get a new one, or do you
think there’s something beyond the economic side?
00:23:18 - Speaker 1: Unfortunately, I think there are several potential
very serious downsides.
And just to give you a couple, one that we’re already seeing is this
issue of repairability or even modifiability. Again, if you look at
these durable goods categories like tractors is a very prominent example
right now.
Traditionally people could service and maintain and change and modify
and improve their own tractors, but as tractors increasingly become like
iPhones, you know, these black box computers in many ways are highly
computerized hardware, potentially you can’t service them yourself, you
can’t repair them yourself, you can’t modify them yourself, and that
has all kinds of second order effects. There’s also this whole thing
about like surveillance basically, that I think we’re sleeping on a
little bit, but we don’t need to go down that whole road today.
00:24:08 - Speaker 2: On the economic side, I think there’s also the
incentive, which is basically Apple and other phone manufacturers have
done very, very well by always creating that shiny new.
The thing that comes out every year or two and you think I want to
upgrade, it’s even often built into cell phone contracts and things
like that, that people want to get a new phone very frequently, and I
think that’s paired with sometimes the operating system upgrades or
maybe the visual refreshes.
It’s almost more like fashion, right? The fashion industry found this
very clever way.
To get around the fact that their IP isn’t really protectable, which is
they just make new fashion trends that totally change for a couple of
years. So then you like need to go out and get a new wardrobe. It’s not
that the clothes wore out necessarily. It’s that you want to be up to
date and you look behind the times when you’re strolling around in your
bell bottoms and those have been out of fashion for 3 years or whatever
it is.
Yeah. And so I think there’s an element of this kind of a fashion
desire to get the new thing. That has driven a lot of revenue for, for
these companies.
I don’t mean to imply that that’s some kind of a cackling in the back
layer, they’re using this opportunity to prove and genuinely make their
products better, you know, each version of the iPhone has a better
camera, that better battery life, the bigger, brighter screen, it is
genuinely better, but it’s also the companies are very incentivized for
a high pace of change that has you buying new products all the time as
opposed to something longer term.
All right, so let’s say for the sake of argument that we’ve decided
that longevity in our technology products is desirable, whether we
because we think it’s about preserving history or because we think
there’s inherent beauty and timelessness, or we think there’s a good
economic argument. What can we do as engineers and designers and product
managers to make our software stand the test of time?
00:25:55 - Speaker 1: Yeah, I do have some techniques there. I do have
to preface it by saying that I think there’s a large element of just
draw the owl here. I don’t know if you’ve seen this meme before. But
you got to sit down every week for 30 years and make sure the software
doesn’t break. And that’s sort of a necessary but not sufficient
condition, I think.
00:26:13 - Speaker 2: And the implication there is also just
maintenance, right? And that maybe ties into some of our discussions
about sort of software supported by subscriptions versus one-off
payments, which is it really is an ongoing effort, an important ongoing
maintenance effort rather than a one and done.
00:26:32 - Speaker 1: Now that said, I think there are things you can do
to make this maintenance effort much more feasible.
One thing we’ve alluded to is this idea of narrow defined APIs, your
software has to run in something, and the broader, the more complex, the
more ill specified that environment is, the harder it’s going to be to
do this job of keeping the software running.
And this would include things like taking on few dependencies.
Minimizing weird binary compendencies that are hard to compile, limiting
the APIs that you access, things like that.
Another thing that I’m very big on is really focusing on data.
Often, especially in this world of rolling forward over multiple
generations, what you really want to keep is the data. This is more true
probably for like productivity type stuff than games, for example, but
data is very important and if you want to roll forward data, you either
need to adopt an existing open data format, existing data format, or you
need to do your own, which can be done, but it’s a lot of work.
I think that programs or program lineages, if you call it that, embrace
this idea of really focusing on the data so that that can always be
ejected and rolled forward into the next generation of software.
00:27:47 - Speaker 2: And one good example of that from my personal life
is I’ve had the same calendar in some ship of thesis since, I think I
started using a product called 30 Boxes, I don’t know, 15 or 20 years
ago was my first kind of like digital online calendar, and then have
migrated from one to the next as new stuff comes along. And hopefully
there are some standard formats here, I think it’s Calav or something
like that. There are also, I think these companies are often
incentivized to make importers where you can kind of slurp down from the
other company’s API or whatever your existing calendar, but it would
just make it much harder to move forward.
I probably could, but it’s just I do put things on my calendar that are
either annual recurring things like, you know, pay the taxes, but also
things that I really wanna make sure I remember that are pretty far out,
and I like having that history in the past. I like to know when a
particular thing happens, so I can look it up occasionally.
So having that my calendar is something that for me feels distinct from
the particular calendar software I happen to be using at the moment.
00:28:51 - Speaker 1: Yeah. I also think there’s a social slash
community element here, where if the thing that you’re building is used
and demanded by a lot of people, there are a lot of forces that are
going to be pulling in your direction for that thing to be preserved.
It’s kind of like this data quality issue that I think we’ve talked
about before in the podcast where the quality of data tends to be
determined by how often and carefully it’s read, not how often and
carefully it’s written, and I think similarly with software, if you
have many people constantly trying to run the program in different
environments that will encourage it to become persistent.
And that by the way, goes down recursively to your dependency. So one of
my favorite examples is Site. If you use SQLite to write even your semi
custom data format, if you write it into SQL database, you’re
absolutely going to be able to read that in 30 years, even if you do
nothing yourself. Whereas if you roll your own format on disk, there’s
a very good chance that it will at some point become totally lost.
00:29:49 - Speaker 2: Yeah, SQLite I think is a favorite example for us
in many cases of sort of well made simple software that does one thing
and does it well. They have a great page though about their long term
support. I’ll link that in the show notes, where they list off some
techniques like testing and making their database files cross platform
and disaster planning and not embracing hot new technologies with too
much gut.
But actually, I think one of the things that points to that to me feels
like maybe the most fundamental is to just think about longevity in the
first place and just care about it in the first place.
Part of the reason I thought this topic would be an interesting one.
I think again, tech industry skews young. I, I think also had the same.
What is it like gap in my thinking as a younger person, which was I just
didn’t have the longer experience to be able to see what it is like for
a software that I’ve created that’s in production for 3 years, 5
years, 10 years and longer, and what happens over time.
So part of what I like with the SQL Light long-term support page is they
basically lead with a statement of our goal is to support this until the
year 2050. And so, will they achieve that? Hard to know, but just by
like making that statement, calling it out as a value for themselves,
and thinking about it actively, maybe this comes back to the long now
clock idea, which is, they may or may not succeed, but certainly one
good way to not succeed is to not think about it in the first place. And
so this makes it a first class concern.
00:31:20 - Speaker 1: Yeah, I think that’s a good point. You gotta
think about longevity for sure and for me that circles back to this idea
of data. I see people typically design and implement programs again
thinking, for example, productivity type software. We tend to focus on
the interface and the behavior because that’s what users are demanding,
that’s what the short term success of our business depends on.
But the reality is that interface, including its implementation, is
going to almost certainly fully churn, at least once, potentially
several times over the course of software, but what’s not going away is
data.
And so one thing that I think is helpful for longevity of software is
really focusing.
On the underlying data model, not only in the sense of how it’s stored,
which is mostly what we’ve been talking about in the podcast so far in
terms of text files or SQL light, but also what is the data model
itself, like if you were to draw out the SQL tables or equivalent, what
are the boxes and what are the labels on them, it sounds really basic,
but it’s a step that I feel like people often skip over and then it
leads to all kinds of longevity headaches down the road.
00:32:21 - Speaker 2: Futureproofing, I think is a word we sometimes use
in general for talking about helping things be longer lived, but
certainly I think that’s most notable in the data model, precisely for
the reason you said, it’s just much less changeable and harder to
change, and heavier weight to change.
00:32:37 - Speaker 1: Folks, you want a practical tip? Here it is. Put a
ID on everything, put a version on everything, and only write new data,
don’t plete all data.
00:32:45 - Speaker 2: Yeah. That is a deceptively simple list, but I
think it probably reflects some pretty deep, I’m guessing painful
experiences in your career. Got any war stories for us?
00:32:58 - Speaker 1: Well, the version one, I remember well, cause
you’re the one who taught me.
We were working on the Hiroku runtime, where the runtime builds
applications into binaries and they are deployed and run.
And I was working on, what the time was the unlabeled version one of the
system. And you point out, Mark, I’m sure at some point we’re going to
have a different version of how we package up these files. So I’m going
to give you a tip, which is that you should write version 1 next to all
of these, and then when we go to do version 2, it’ll be a lot easier.
And sure enough, that made a huge difference, and we did eventually get
to version 2 and then 3456, I think after that.
00:33:37 - Speaker 2: And that was something at that point, you know,
you were earlier in your career and I had had a few of those bumps and
difficult data migrations and had realized that this one simple trick
can save you some headaches.
Now, of course, the future proofing should be balanced against what’s
usually called, you’re not going to need it, which is over, I guess,
engineering for something that an unknown future.
So you’re not trying to create a system that has totally flexible
properties and tries to take into account every feature you might ever
want to possibly add, I think that tends to create abstractions that
just get in your way. It’s more of these small, simple tricks that
don’t get in the way, but create opportunities to more easily make
changes that you can’t guess right now in the future.
00:34:23 - Speaker 1: Right. On the data modeling side, the advice that
I always give is, you’re just trying to accurately model the world as
it really is, cause the world as it really is, isn’t going to change.
It might expand as you add more features, right? But if you have
incorrectly portrayed the world in your data model, and then you also go
to model more of it, you know, now you have 2 problems plus there are
section 3 problems, whereas if you had correctly modeled the part of the
world that you were working with, it becomes relatively straightforward
to extend the model to the new features.
00:34:53 - Speaker 2: And to go just a little bit technical for a
minute, the version thing is also making me think of, I think it’s the
image file format, maybe TIFF is the one I’m thinking of, but this
approach, I think, has been used in a lot of different places, and I
feel like you’re doing a version of this in the local first sync
infrastructure we’re working on right now, which is to have chunks that
have kind of a type in front of them. And so you can add new chunks to a
stream of data or to a file that older versions of the software can
load, recognize, they don’t know this chunk, and they can kind of skip
past it and just try to interpret the rest of it the best that they can,
you know, maybe this is something that web browsers do pretty well,
which is you load a new. Page in an older web browser, if there’s some
unsupported features, it doesn’t completely break. It just does its
best to render it.
Of course, the older the browser is and the more new features you’re
using, the more and more sort of ugly and unusable the page is going to
become, but it makes its best effort. It’s not that it just gives up
the moment it sees something it doesn’t understand.
00:35:54 - Speaker 1: Yeah, and this gets into the peculiar challenges
of longevity with distributed system software. We’ve been talking about
longevity in terms of supporting the past with distributed systems. You
gotta support the future because the future arrives unevenly. So that’s
the sort of challenge you deal with when you’re working on distributed
systems like the data synchronization layer from use.
00:36:14 - Speaker 2: Yeah. As usual, Link and Switch has some good
research on the subject with the data lenses in the Cambria project, and
one of the things there is about sort of data migrations, but it’s
assuming you need to translate both ways.
You need to translate, I guess you say back in time to older versions
and forward in time to newer versions, but in fact it’s actually more
complex than that because there may be just a branching tree of systems
that all understand the data in slightly different ways.
And the other small thing, it’s sort of obvious in some ways, but I
think it’s kind of a Lindy effect of file formats. So Liny effect here,
of course, being sort of the idea that something that’s been around a
long time probably will be around a long time. So I’m always a big fan
of those flat file formats, PNG, JPEG, PDF, plain text, because they’ve
proven themselves to be durable over the long term. And they don’t
always do everything you need, but where you can, it’s really nice to
just kind of go down to that simple common format that’s understood by
many applications, both now and in the past, and potentially will be in
the future. Bringing all these ideas together in a very practical and
relevant area for us. How do we think about this for Muse, the products,
the data aspect that you mentioned, but also the team and the company?
00:37:37 - Speaker 1: Well, I think there are layers. I think the first
layer in the sense of what’s likely to be longest lived is from
basically day one we’ve supported flat file export. So you can export
your board to a PDF or your images to a PNG. You can export your whole
corpus to a zip of a bunch of flat files of these types, and that way
you know you’ll always at least have your data in this format that
everyone knows how to store essentially forever. And yes, it’s lower
fidelity. Obviously you can’t easily edit it, like you can’t amuse,
but that’s sort of the tradeoff you make there is you have access to
this very durable format for all that data.
00:38:17 - Speaker 2: And I often find for archival purposes, I have put
a lot of effort in the past to preserving things I’ve created, whether
it’s an essay or back when I used to make music, trying to preserve all
those kind of source files, video, similar thing, and usually I find the
kind of flattened artifacts read only. is really kind of what I want in
the long term because I do go back to reference those things or look at
them for inspiration or just for take a walk down memory lane, but I
very rarely want to edit, even if I could. And so in that sense, just
it’s actually superior to flatten out to an image or a video or
something.
00:38:55 - Speaker 1: Yeah, it’s a good point. In many ways, it’s a
benefit, not a downside. I think especially when you have this habit of
building up an archive that’s all in these handful of formats,
everything is basically Texts, PNG, PDF, maybe video or MP3, you can
browse it all together and you can do it very quickly, basically ininder
or the equivalent, whereas you can imagine, if for every picture you
wanted to check out, you had to open up Adobe Photoshop or whatever, you
had to wait 2 minutes. So it’s nice just to have that very lightweight
archival copy.
00:39:25 - Speaker 2: Now for the app’s kind of data itself, and we did
toy early in the company with having it be part of our product to try to
make that be something that’s more like the native format that Muse is
saving to is like a Dropbox folder, for example, and it just turns out
that we couldn’t achieve this.
Things we wanted to either being on iPad or things we want to do around
sync, just wasn’t compatible with that sadly. Right.
But what we do try to do is really make the format that the app stores
its data and on your device, on iPad or now on the Mac, a format that is
something we will support over the long term and obviously we’ve only
been at this for 2.5 years, 3 years if you count the research time. But
already we’ve had people who have been around from, you know, the early
days of the beta and we’ve had to, including our own personal corpuss,
you know, I’ve got 20 some odd gigs of stuff and use from my now years
of doing all my thinking and strategizing in it.
And the engineering team spends a lot of effort on carrying forward as
we build major new things, whether it’s something like the flexible
canvas, or whether it’s something like, yeah, we at one point converted
the ink from raster to vector, we have another huge sort of data
migration here with the introduction of sync that the team’s working on
right now. It’s a high stakes, but really important operation to bring
that across.
So ideally, you could have been, and in fact, many people have been
using these that whole time, and you can go back and access your very
earliest boards and everything is pretty much just as you left it, you
can still edit it. It’s all still right there.
00:40:56 - Speaker 1: Yeah. Now that data layer and rolling forward
versions does become much trickier in a world where you have multiple
writers and especially if those writers are potentially not programs
under our control.
Certainly right now with Muse in the near future, the deal is gonna be,
you have Muse, the app, writing your data, like a traditional cloud app
would.
But you can also imagine a world where, and we have in fact imagined a
world where we have things like bots and end user scripting, and
plug-ins and extensions.
And that while everyone’s participating in a data model, so the stakes
becomes much higher and you can’t just roll forward the world when you
deploy a new version.
So that’s why as we are working on sync right now with an eye towards
this world of scripting and extensions and so forth, we’re thinking
very carefully about the data model because you basically need to
support that forever or go through a very troublesome migration process.
So we’re trying to lay that foundation now even though it’ll be some
time before all those end results come to fruition.
00:42:02 - Speaker 2: Now that’s the data, so how about the software,
the app you download or the product more broadly over time? Is it
important for that to be long-lived and how do we think about
accomplishing that?
00:42:14 - Speaker 1: Well, I think it’s harder for that to be as long
lived as the data because that’s less in our control, you know, you’re
participating in the Apple ecosystem, as we talked about this ecosystem
has certain characteristics that lend itself to being medium term life
in practice, you know, apps or individual builds of apps don’t last a
decade, even if the app itself does.
So we do, we can there, we have minimal external code dependencies, and
we have no critical dependencies on third party network services except
the ones that Apple requires for any app to be able to, you know, be
downloaded and paid for and so forth. But we are participating in that
model if you got to keep the app sort of up to date on that time scale
of quarters or years as the underlying runtime environment on iOS and
Mac changes.
00:43:01 - Speaker 2: Yeah, exactly. I would think of the software as in
any particular build as being something that at least I hope would
continue, you know, in some future where I don’t know, someone’s
running this in an emulator, for example, as long as the operating
system, APIs are kind of what’s expected, and again, we don’t tend to
use heavy amounts of those, we tend to keep it pretty light, but
assuming, you know, we can read pencil data, for example, on the API
that’s expected. That should still work.
And a big part of that is the network side. So many apps on your phone,
on your tablet, and increasingly on the computer, they expect some kind
of service to be online and I tend to discover that because I really
like working in offline environments. I like taking a long train ride or
working on a plane, or just going to one of our team summits in some
weird rural location with weak internet and actually that’s good.
To be more kind of focused on what’s in the moment, but then you really
quickly get exposed to these weird timeouts and network errors and
can’t contact or whatever and I’m thinking, why is this software even
contacting the network? Those hooks are just so pervasive now, we hardly
think about it, but we’re working for use to make it be very much the
network is optional.
You get some nice benefits, but you don’t need it once you’re logged
in.
And then I would probably say, you know, that’s any individual build of
the software, but I would say on the product side it comes down to more
of a team and viable economic model and things that we’ve talked about
extensively on the podcast here, but if we have a product vision we
think is good, that the members of the team are invested in that long
term and We’ve got a sustainable way to sort of fund it or work on that
over the long term, and it even ties in with something like just running
the team at a sustainable pace, right? Avoiding this drive to burn
bright but burn out quickly that maybe does tend to come in the kind of
hypergrowth world of startups. And instead be thinking a little bit more
about, yeah, we want to be doing for this for a while. We know great
products take a long time to build, and that’s not just like total
person hours to build, but in fact it’s wall clock time for people to
use in the real world and get back feedback and expand and improve upon
it. So running the team in such a way and having a vision that we think
that we’re all committed to in the longer term, again thinking in terms
of human life scale spans, not months or Just years, but maybe slightly
longer than that. I think that’s how we get a product, you can really
depend on the longer term.
00:45:31 - Speaker 1: Yeah, another way you could think about this is
lining up the reality of the software environment, what you’re
communicating to users with how the team and the company is run.
So it’s not even necessarily that you want all stuff to be exactly the
same forever. It’s more like you want these promises to line up. So for
example, as we’re developing new features, you’re really annealing
them in. You’re not saying as soon as you come up with an idea, oh
we’re going to support this forever. Initially you do a beta and you
say, we’re gonna support this for the beta, it’s gonna be there for a
few months and longer if it works well and not if it doesn’t. But then
when it kind of graduates to the next layer, it becomes something that
you support longer term you have corresponding infrastructure around
what the company to do.
00:46:12 - Speaker 2: And from the perspective of customers, maybe some
of that comes back to trusting the team and knowing the team, right?
That’s why I think it’s important to communicate our values, our
philosophies and our motivations through writing, through podcasting
where someone can Dip into that world a little bit, get to know us and
have some sense of what’s driving us and where we’re going and what we
value, and if you share some of those values and you see a similar
vision, then you can maybe trust that the software will change and
evolve over time, but it will change and evolve in directions that on
net will hopefully be Improvement for you, at least not a downside or a
disruption, whereas if, yeah, you listen to us talk for a few hours in
this podcast and you think, um, these folks are, you know, thinking
about things in a different way than I think about things, and then
maybe it’ll happen to be that the product does something useful for you
right in this moment, but maybe over the longer term, it won’t be
evolving in directions that are as useful to you. So that’s the reason
in my own life. I try to use software as much as I can from teams I
know, which it helps that, you know, I’m in the industry, I’m
reasonably well connected now thanks to Twitter and other sources. And
of course, it’s really fun to use your friend’s software, you know,
using The Arc browser or something like that, for example, or some of
the not boring apps from our friend Andy works as a couple of examples,
but I also like that because, yeah, it feels different when I know
who’s behind it and what they’re trying to achieve. It feels good both
to support their work, but also the sense that sort of, not quite like
we’re a team, but we’re working together to reach a similar future,
where they’re working hard to make this software that can serve my
purposes, and I’m, you know, giving them feedback and using the
software and paying for it, and that’s my contribution, and together,
hopefully, we work towards a better future. Well, let’s wrap it there.
Thanks everyone for listening. If you have feedback, write us on Twitter
at @museapphq. We’re on email, hello at museApp.com. And of course, we
definitely appreciate it if you leave a review on Apple Podcasts. And
Mark here is hoping that in addition to our business venture being
long-lived, that indeed this podcast will be long lived.
00:48:30 - Speaker 1: Right on, Adam.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: There’s been very little innovation and research
more generally into what is a good interface for inputting equations. So
I think most people are probably familiar with Microsoft Word or Excel
have these equation editors where you basically open this palette and
there is a preview and there is a button for every possible mathematical
symbol or operator you can imagine.
00:00:28 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad and Mac. This podcast isn’t about Muse the product,
it’s about Muse the company and the small team behind it. I’m Adam
Wiggins here today with my colleague Mark McGranaghan. Hey, Adam. And
joined by our guest Sarah Lim, who goes by Slim. Hello, hello, and Slim,
you’ve got various interesting affiliations including UC Berkeley,
Notion, Inc and Switch, but what I’m interested in right now is the
lessons you’ve learned from playing classic video games. Tell me about
that.
00:01:01 - Speaker 1: So this arose when I was deciding whether to get
the 14 inch or 16 inch M1 MacBook Pro and a critical question of our
age, let’s be
00:01:10 - Speaker 1: honest. Exactly, exactly. I couldn’t decide. I
posted a request for comments on Twitter, and then I had this
realization that when I was 6 years old playing Organ Trail 5, which is
a remake of Organ Trail 2, which is itself a remake of the original. I
was in the initial outfitting stage, and you have 3 choices for your
farm wagon. You can get the small farm wagon, the large farm wagon, and
the Conestoga wagon. I actually don’t know if I’m pronouncing that
correctly, but let’s assume I am. So I just naively chose the Conestoga
wagon because as a 6 year old, I figured that bigger must be better and
being able to store more supplies for your expedition would make it more
successful. I eventually learned that the fact that the wagon is much
larger and can store a lot more weight means that it’s a lot easier to
overload it. Among other things, this requires constantly abandoning
supplies to cut weight. It makes the roover forwarding minigame much
more perilous. It’s a lot harder to control the wagon. And yeah, I
never chose that wagon again on subsequent playthroughs, and I decided
to get the 14-inch laptop.
00:02:12 - Speaker 2: Makes perfect sense to me and and what a great
lesson for a six year old trade-offs, I feel like it’s one of the most
important kind of fundamental concepts to understand as a human in this
world, and I think many folks struggle with that well into adulthood. At
least I feel like I’ve often been in certainly business conversations
where trying to explain trade-offs is met with confusion.
00:02:35 - Speaker 1: They should just play Organ Trail.
00:02:37 - Speaker 2: Clearly that’s the solution. And tell us a little
bit about your background.
00:02:42 - Speaker 1: Yeah, so I’ve been interested in basically all
permutations really of user interfaces and programming languages for a
really long time, so this includes the very different programming
languages as user interfaces and programming languages for user
interfaces, and then, you know, the combination of the two. So right now
I’m doing a PhD in programming languages, interested in more of like
the theoretical perspective, but in the past, I’ve worked on I guess,
end user computing, which is really the broader vision of notion, I was
at Khan Academy for a while on the long term research team.
00:03:18 - Speaker 2: Yeah, and there I think you worked with Andy
Matuschek, who’s a good friend of ours and uh previous guest on the
podcast.
00:03:24 - Speaker 1: Yes, definitely. That was the first time I worked
with Andy in real depth, and I still really enjoy talking to him and
occasionally collaborating with him today.
So, I guess, prior to that, I was doing a lot of research at the
intersection of HCI or human computer interaction and programming tools,
programming systems, I guess. So, one of the big projects that I worked
on as an undergrad was focused on inspecting.
CSS on a webpage or more generally trying to understand what are the
properties of like the code that influence how the page looks or a
visual outcome of interest, and there I was really motivated by the fact
that you have these software tools have their own Mental model, I guess,
or just model of how code works and how different parts of the program
interact to produce some output and then you have the user who has often
this entirely different intuitive model of what matters, what’s
important.
So they don’t care if this line of code is or isn’t evaluated, they
care whether it actually has a visible effect on the output. So trying
to reconcile those two paradigms, I think is a recurring theme in a lot
of my work.
00:04:30 - Speaker 2: And I remember seeing a little demo maybe of some
of the, I don’t know if it was a prototype or a full open source tool,
but essentially a visualizer that helps you better understand which CSS
rules are being applied. Am I remembering that right?
00:04:43 - Speaker 1: Yeah, so that was both part of the prototype and
the eventual implementation in Firefox, but the idea there is The syntax
of CSS really elides the complexity, I think, because syntactically it
looks like you have all of these independent properties like color, red,
you know, font size, 16 pixels, and they seem to be all equally
important and at the same level of nesting, I guess, and what that
really hides is the fact that there are a lot of dependencies between
properties, so a certain property like Z index, you know, the perennial
favorite Z index 9999999. Doesn’t take effect unless the element has
like position relative, for example, and it’s not at all apparent if
you’re writing those two properties that there is a dependency between
them.
So I was working on visualizing kind of what those dependencies were.
This actually arose because I wrote to Burt, who is one of the
co-creators of CSS and was like, Hi, I’m interested in building a tool
that visualizes these dependencies. Where can I find the computer
readable list of all such dependencies? And he was like, oh, we don’t
have one, you know, we have this SVG that tries to map out the
dependencies between CSS 2.1 modules, and even there you can see all
these circular dependencies, but we don’t have anything like what
you’re looking for. That to me was totally bananas because it was the
basic blocker to most people being able to go from writing really
trivial CSS to more complicated layouts. So I was like, well, I guess
this thing doesn’t exist, so I’d better go invent it.
00:06:12 - Speaker 2: Perfect way to find good research problems. Now,
more recently, two projects I wanted to make sure we reference because
they connect to what we’ll talk about today, which is recently worked
on the equation editor at Ocean, and then you worked on a rich text CRDT
called Paratext at In and Switch. Uh, would love to hear a little bit
about those projects.
00:06:34 - Speaker 1: Yeah, definitely. So I guess the Paroex project,
which was the most recent one was collaboration with Jeffrey Litt,
Martin Klutman and Peter Van Harperberg, and that one was really
exciting because we were trying to build a CRDT that could handle rich
text formatting and traditionally, you have all of these CRDTs that are
designed for fairly bespoke applications. They’re things like a counter
data type or a set data type that has certain behavior when you combine
two sets, and we’re still at the stage of CRDT development where aside
from things like JSON CRDTs like automerge, we don’t really have a one
size fits all CRDT framework or solution. You still mostly have to hand
design and implement the CRDT for a given application.
And it turns out that in the case of something like rich text, it’s a
lot harder than just saying, oh, you know, we’ll store annotations in
an array and call it a day, because the semantics for how you want
different types of formatting to combine when people split and rejoin
sessions and things like that are all very complex and it turns out that
we have a lot of learned behaviors that arise, even from just like,
Design decisions in Microsoft Word, where you expect certain annotations
to be able to extend, certain annotations to not extend, things like
that. Capturing all of the nuance in that behavior turns out to be
really difficult and requires a lot of domain specific thinking.
But we think we have an approach that works and I would really encourage
everyone to read the essay that we published and try to poke holes in it
too. This was like the 5th version of the. algorithm, right? So like
months ago, we were like, all right, let’s start writing and then
Martin, who has just an incredible talent for these things is like, hey,
everyone, you know, I found some issues with the approach and, you know,
oh no, 00, and sort of we fix those, we’re like, all right, you know,
this one’s good and just repeat this like week after week. So I really
have to give him a ton of credit for both coming up with a lot of these
problems and also figuring out ways to work around it.
00:08:33 - Speaker 2: We talked with Peter a little bit recently, Peter
van Hardenberg, about the pencils down element of the lab, but also just
research generally, which is there’s always more to solve, you know,
it’s the classic XKCD, more research needed is always the end of every
paper ever written, which is indeed the pursuit of the unknown. That’s
part of what makes science and Seeking new knowledge, exciting and
interesting, but at some point you do have to say we have a new quantum
of knowledge and it’s worth publishing that. But then I think if it’s
just straight up wrong or you see major problems that you feel
embarrassed by, then if you want to invest more.
00:09:09 - Speaker 1: Right, exactly. I think in this case. There was a
distinction between, there’s always more we can tack on versus we
wanted to get it right, you know, and in particular, the history of both
operational transforms or OT and CRDT for rich text, just text in
general is such that it’s this minefield of I guess to use kind of a
gruesome visual metaphor, just dead bodies everywhere.
You’re like, oh, you know, such and such algorithm was published and
it’s such and such time and it was new hotness for a while and then we
realized, oh, it was actually wrong and this new paper came out which
proved like 4 of the algorithms were wrong and so on.
And so with correctness being such an important part of any algorithm,
of course, but also kind of this white whale in the rich text field, we
thought it was important to at least make a credible effort to having a
correct algorithm.
00:09:57 - Speaker 2: Yeah, makes sense. Yeah, I can highly recommend
the Paroex essay.
One of the things I found interesting about it, maybe just for anyone
who’s listening, whose head is spinning from all the specialized jargon
here, CRDTs are a data structure for doing collaborative software,
collaborative documents, and then, yeah, rich text, the Microsoft Word
is the canonical example there.
You can bold things, you can italic things, you can make things bigger
and smaller.
Well, part of what I enjoyed about this paper was actually that I felt,
even if you have no interest in CRDTs, it has these lovely
visualizations that show kind of the data representation of a sentence
like the quick brown fox, and then if you bold quick, and then later
someone else bolds fox, you know, how do those things merge together.
But even aside from the merging and the collaborative aspect, which
obviously is the research, the novel research here. I felt it gave me a
greater understanding of just how rich text editing works under the
hood, which I guess I had a vague idea of, but hadn’t thought about it
so deeply. So, highly recommend that paper. Just give them the figures,
even if you don’t want to read the thousands of words.
00:11:05 - Speaker 1: I’m glad you like the figures. They were a real
labor of sigma.
00:11:08 - Speaker 2: Perfect, yeah, so.
00:11:10 - Speaker 1: The one thing I would add is that CRDTs are a
technology for collaboration, but the way they differ from operational
transforms or OTs is that a CRDT is basically designed to operate in a
decentralized setting, so you don’t need a persistent network
connection to all the parts. you don’t need a centralized server. The
idea is you can fluidly recover from network partitions by merging all
of the data and operations that happened while you were offline, and
this turns out to be really important to our vision of how collaborative
editing should work because we think it’s really important for people
to be able to do things like not always be editing in the same document
at the same time as everyone. Maybe I want to take some space for myself
to write in private and then have my changes sync up with everyone else
thereafter. Maybe I’m, you know, self-conscious about other people
editing. are seeing my work in progress, but I think that it would be
interesting and helpful to look at what the main document looks like and
how that’s evolving while I’m working in private, and you can have
that kind of one way visibility with something like a CRDT versus with
something like Google Docs, where it’s just sort of always online or
always not editing in your own personal editor. Conversely, maybe I’m
OK with everyone else seeing the work that I’m doing in progress, but I
just find it really visually jarring to have all these cursors and
different colors jumping around and People inserting text, bumping my
paragraphs down the page. I’ve definitely been there. I’m not
particularly precious about people seeing my work in progress, but I
just cannot focus on writing when the page is just changing all around
me. So in that situation, maybe I would want to allow other people to
see my work in progress, so that we don’t duplicate effort or something
like that, but I just have like a focus mode where incoming changes
don’t disrupt my writing environment and these kinds of fork join one
way window. Microgit style branching paradigms are really only enabled
by a technology like CRDTs where you have the flexibility to separate
and then come back together.
00:13:12 - Speaker 2: And I’m incredibly excited by the design research
that needs to go into that.
Now at this point, I think we’re still on the technology level, you
know, one way to think of it is Google Docs came along, I don’t know,
15, it’s almost 20 years ago now, I can’t even remember, let’s say 15
years ago, and this novel idea that We could both have a shared document
or several people could have a shared document, all see the up to-date
version and type into it and get, you know, a reasonable response or
have that be coherent was an amazing breakthrough at the time and has
since been kind of widely copied notion, Figma, many others.
But now maybe we can go beyond that, much more granularity, like you
said, maybe borrowing from the developer version control workflows a
little bit in a lightweight way, giving a lot more control and
flexibility, and giving us a lot more choices about how we want to work
most effectively.
But before we can even get onto those design decisions and how do we
present all these different things to the user, what are the different
options? We need this like fundamental underlying merge technology,
hence the endless fascination that we have the lab and increasingly the
technology industry generally has with CRDTs because it has the
potential to enable all that.
00:14:23 - Speaker 1: Yeah, when we were working on the Paratax project,
Peter was pushing really hard for, don’t make this just a technology
project.
It’s a socio-technical endeavor and we need to invest a lot of time in
the design component, also just doing user interviews, identifying how
people interact with and.
How people collaborate in the status quo on text and Jeffrey and I
actually did do a bunch of user interviews with people from all kinds of
backgrounds. We’ve talked to people who write plays, people who produce
a dramatic podcast kind of in this style of Night Vale.
I love Night Vale. Yeah, people who are in the writer’s room kind of
working together with their collaborators on that, people who write
lessons, video lessons for educational platforms. And there was a ton of
really interesting Insights into user behavior around collaborative
text.
We ended up just torn because we had this 12 week project and we were
like, how should we best spend our time? Clearly, this is not just a
technical area and we need to invest a lot in getting the design right,
understanding what the design space even looks like since it hasn’t
really been explored.
I really want to avoid, and this is a recurring theme in my work, I
really want to avoid publishing or shipping something. And having it be
this like, very broad, very shallow exploration into all the things that
are possible. I think that this kind of work plays an important role,
and there are a lot of people who do this well, just fermenting the
space of possibilities and getting these ideas in a lot of people’s
heads, who can then go on and do really cool things with them.
My personal style, I never want to feel like something is half baked, I
guess, I would much rather ship this cohesive contribution like, here is
an algorithm for building rich text. We think that this is a technical
prerequisite to all of these interesting design choices, but the
alternative with a 12 week period, and in fact, you know, this, the
correctness and revision phase extended way over that. So thanks a lot
to Martin and Jeffrey for leading during that part.
But it’s just already so hard to get it correct that trying to tack on
a really substantive design exploration that does the area justice on
top of that, I was just really worried it would stretched too thin.
So absolutely lots of room for future work in this particular. project.
It’s very much a challenge in any area where you have simultaneously
this rich design space that’s just asking to be explored with tons of
prototypes and things like that, and then also to even realize the most
simple of those prototypes, you require fundamentally new technology.
00:16:53 - Speaker 2: Yeah, I’ve been down that same path on many
research projects as well, and often it’s that I’m excited for what
the technology will enable, but also that in many cases it’s a
combination, you know, some kind of peer to peer networking thing, but
with that will enable us to provide a certain benefit to the user and I
want to explore both of those things, but then that’s too much and then
the whole thing is half baked exactly as you said. I’ve never found a
perfect or even a good. Way to really manage that tradeoff. You just
kind of pick your battles and hope for the best. Yeah, definitely. Well,
I do want to hear about the equation editor project, but first I feel I
should introduce our topic here, which I think folks could probably have
gleaned is going to be rich text and rich text editing, and maybe we
could just step back a moment and define that a little bit.
I think we know that texts, you know, symbolic representation of
language is a pretty key thing, writing and the printing press and all
that sort of thing. We wrote about that a little bit in our text blocks
memo, which I’ll like in the show notes. But typically, I think
computers for a lot of their early time and even now with something like
computer code is typically plain text, that’s the dot TXT file is kind
of almost the native style of text that you have and then rich text
typically layers something on top of that. I don’t know, so maybe you
could better define rich text for us to have a more concrete discussion
about it.
00:18:21 - Speaker 1: Yeah, I think rich text for most people basically
evokes things like bold, italic, underline, the ability to augment plain
text with annotations that are useful in formatting, actually, I think.
Notepad to word pad is the archetypal jump in software, if you’re
thinking about it from the old Windows perspective.
In the past few years, I think we’ve started to see a real expansion of
what rich text can look like. So, of course, we started out with
something like Markdown, which is, of course, a plain text
representation. But it’s designed to be able to capture more nuance in
plain text and be rendered to something like HTML which very much
supports rich text.
So in Markdown, you have not only these kinds of inline formatting
elements like bold and italic and hyperlinks as well.
You also have support for images, which you could think of as more block
level rich text elements, I guess, and I don’t think there’s a real
clear consensus across editors on how block level rich text elements
should be displayed.
Of course, in between you have things like bulleted lists and those tend
to be handled in a fairly standard manner with nested lists and so on,
but it quickly becomes like a question of taste. Which kinds of
annotations you support.
So in editors like Coto or Notion, you have all these different block
types where the block is really the atom of collaboration and editing,
and then you can have things like, you know, file embeds or even
database views, things like that.
So I think we’re at a point now where both block-based editors, I’m
using block based editors in like the text or writing sense, not the
structured editors for programming sense, although I have other things
to say about that, but we’re at a point where you’re starting to see
these block-based editors appear and I think that there are a lot of
really interesting patterns that this permits that the paragraphs via
linear sequence of characters, including new lines and whitespace does
not permit, or at least doesn’t allow you to build as structured
tooling around.
00:20:30 - Speaker 2: I’m trying to think what is actually the core of
the difference between a block-based editor, that’s a notion, a RO uses
working on its own block text implementation and a flow of characters,
so that’s Microsoft Word, Google Docs, maybe even text editors. I guess
it’s sort of like paragraphs are separated by like these sort of
nested. Elements or have a parent to the document versus like two new
lines embedded in the stream of characters, but I don’t know, that
seems too unsophisticated, maybe have a better definition for us.
00:21:03 - Speaker 1: So, I actually think about this very similarly to
in the like programming languages and editor tools space.
There is a distinction between structured editors and regular plain text
editors for programs. The idea is that you might have a text-based
programming language and you can write that perfectly fine in any buffer
that allows you to put sequential characters, often AI is sufficient for
some languages, and then on the other hand, These programs might have a
lot of inherent structure. A simple example is with lisps which are
built out of these parenthesis S expressions, everything is, you know,
an S expression. You can think about like the structure of the tree
formed by, I guess a forest, formed by having like these S expressions
with subelements and stuff. that, and then you can do manipulations
directly on the structure in a way that allows you to always have a
syntactically correct program or at least a partial syntactically
correct program by doing things like I’m just going to take this
subtree, which is a sub-expression and move it somewhere else where
there’s room for another subexpression. So, I think of block-based
editors as capturing a very similar zeitgeist to structured editors for
code, because instead of just having this linear buffer of characters
that can have, you know, formatting or things like that, you can have
new lines, you actually have more of a forest structure where you have
lots of like individual blocks, and then you can have blocks that are
children of other blocks and so on, and that allows you to Do things
like move an entire subtree representing an outline to another position
in the document without selecting all of the characters, you know, cut
them and then paste them somewhere else. So things like reparenting
becomes a lot easier, things like setting the background of an entire
subtree becomes a lot easier. Just in general, you have more structure
and there’s more things you can do with that structure, I guess is how
I would phrase it. One of my favorite things that you can do with this
model in notion is you can change the type of a block very easily. So
let’s say I have a bullet list item, and then I hit enter and enter
these like subnote or something like that as children of the initial
bullet list item. I can turn the bullet list item into a page, and then
all of a sudden it’s just a subpage in the document, and the sub
bullets that were there before are just like top level bullets in that
page. And this is particularly important for my workflow because I care
a lot about starting out with something like really rough and sketchy
and then progressively improving it or moving up and down the ladder of
like fidelity into something more polished. So you might, for instance,
start off with just an outline list or even a one dimensional list of to
do blocks when you’re trying to do project planning or something. And
then later on, let’s say I want to put these into like a tasks database
with support for like a conbond view or something like that. I don’t
actually want to sit there and like recreate all of these tasks in Jira.
I’ve been there, you know, I’ve been the person making all the tasks
in Jira after the meeting and then assigning them to people. What the
workflow that I think notion is poised to enable and can certainly do a
better job in this regard, but already offers some benefits on is like,
can I just highlight all of these blocks because everything is a block,
move them into some existing database and have them match the schema.
That kind of like allowing people to do fast and loose prototyping with
very unstructured primitives and then promote them into something more
structured like in a relational database setting or similar, I think is
the sweet spot, structured editing provides the sweet spot between like
just completely unstructured text and these very high fidelity, high
effort interfaces that allows you to kind of move between them.
00:24:47 - Speaker 3: Yeah, I really like that direction and framing,
and if I can extend it a little bit, I think we can also look at a
continuum of richness in terms of the content itself.
So you have plain text, what you might classically call rich text with
links and bold and underlying. And then you maybe start to throw a few
images in, and then what if you can put it in videos and what if you
have a whole table, and that table is actually a database query, and you
can nest the figment document, and this way you can see that there’s
sort of continuum on the richness of the document. One reason I think
Notion has been so successful, they’ve been pushing along that
continuum while maintaining a sort of foundation of rich textness, which
is very familiar and the important basic use case for a lot of people.
A related idea is that I think we’re seeing a lot of the classic
document types converge. So if you look at a rich text like a Microsoft
Word and a PowerPoint and increasingly spreadsheets, those all used to
be 3 distinct Microsoft Office applications, and we’re seeing the value
of them being in or being the same document.
This is actually one of the motivating ideas behind Muse and a lot of the
research we’ve done in the lab, and the kind of something Slim was
saying, you want to take your idea continuously through different media
and different modalities and different degrees of fidelity, and you
don’t want to jump between different applications do that. You want to
be able to do it on the same canvas. That’s by the way, one of the
reasons I like Canvas. It’s not only because it’s a free multimedia
surface, but also it evokes this idea of like flexibility and
potentiality, and I think that’s one of the things that’s really
excited about these mixed media documents.
00:26:16 - Speaker 2: And I know if Jeffrey were here, he might jump in
and say that one downside to our current application silo world is that
the only way to have this deeply rich text where it’s images, video, a
table, a database query, something like that, is to have the Uber
application, to have the everything app, and certainly notion has
probably gotten pretty far on that, but others kind of in In some ways
are forced to do that, like we have to do some of that in Muse as well.
People come in and ask for all these different types here as well, and
there’s more of like an open doc inspired or Unix inspired future that
maybe Jeffrey and others, including me, would hope for, which would be
more that applications could be these individual data types and you
could put them all together through some kind of more operating system
connection.
But that is so completely reversed from kind of how all our computing
devices work today. It’s hard to see how we might get to that.
00:27:14 - Speaker 3: Yeah, I’m certainly sympathetic to that concern,
although I suspect the way out is through, and you get platforms from
working killer apps.
And so the way we got the whole unit ecosystem was they wanted to build
a computer for, you know, writing and running programs and then
eventually got all this generalized text processing stuff, but it’s not
like they started in like, oh, I’m gonna make a generalized text
processing machine.
I don’t think that was really the way that they approached it and
developed a success. So, I’m still hopeful we could do this, but I
think you got to extract it from something that’s already working as an
app, but it always helps to have an eye towards that, and I think we’ve
done some of that with Muse.
00:27:46 - Speaker 1: I was just going to say that it’s not me talking
about texts, unless I bring up my favorite piece of software of all
time, which is Pandok.
And I think that Pandok actually is very relevant to this discussion. So
for those who aren’t as familiar with it, Panok brands itself as this
Swiss Army knife for document formats, and it’s sort of headline
contribution is that it allows you to convert between all kinds of
documents.
For instance, I can take a Word document and convert it to a PDF Word
documents to something like, I don’t know, IPython notebook, Jupiter
notebook, back and forth across this incredible bipartite graph of
formats, but I think that the subtler contribution that Pandokc makes,
which is extremely significant, is that Pandok has this form of markdown
called Pandok markdown that essentially aligns and supersedes all of the
different fragments of markdown that we’ve seen before.
So the problem with markdown basically is that the original
specification is sort of ill-defined. There are several cases in which
the behavior is not super clear and then on top of that, it’s not very
expressive.
There aren’t very many constructs. So things like fenced code blocks,
which many people associate very closely with Markdown today, that was
only added by GitHubb flavored markdown, which is certainly widely used
among the programming community, but not everyone is on GitHub, of
course. And then you have things like table formatting or even like
strike through really strike Through wasn’t defined in the original
markdown specification either. And so you have markdown and then you
have like GitHub flavored markdown, common mark is sort of this unifying
effort remark down all these different is the markdown cinematic
universe. I tried to make a joke about this. I had this joke ready for
the markdown Cinematic universe when the last Marvel. Movie came out.
But then like, it didn’t get nearly the traction in my timeline as the
Dune did, perhaps understandably. So really, I’m just going to have to
wait till the next movie comes out. It’s a real, real tragedy. No, but
like, I guess you have this real pluralism of forms and it becomes very
difficult to use markdown truly as a portable format because the way it
renders in one editor or even parses can very much differ from editor to
editor. So, Pandoc provides this format that essentially serves as an IR
or intermediate representation between all these kinds of documents
using a markdown supersets that somehow magically encapsulates
everything.
00:30:18 - Speaker 2: And that includes not just markdown, but also like
PDFs or Microsoft Word, that seems.
00:30:24 - Speaker 1: Well, so the way it works is it’s this
compilation pipeline, I guess, that allows you to go from a markdown
document.
It compiles it to PDF using PDF Lawtech or something. It outputs
Lawtech, it outputs HTML various things, and you can think of it as
being this intermediate representation because you start with this like
Word document, you can turn that into markdown and you can go from that
markdown format into any of these output formats, which turns out to be
like really powerful because the main issue with these kinds of
conversions is that it’s often lossy, there are features that are
supported by Law tech, for instance, that aren’t supported by the web
natively, there are features that are part of like Word documents that
aren’t necessarily supported by HTML and so on and so forth.
So Pandok serves this role of like basically saying, OK, what is an
intermediate language that can encapsulate all the different
implementations of the same concept across different input and output
formats.
And what I think is so remarkable about it is that oftentimes when you
are using an AP. of software and you’re like, oh darn, you know, now I
need to support this other thing too. You quickly end up in a situation
where you have the snowball and things start to feel tacked on.
So you’re like, Oh man, it’s very clear that they just glommed on this
additional syntax for this feature. And with Pandok, everything feels
like very principled in its inclusion. And at the same time, whenever
I’m using Pandok and I’m like, darn, I really wish there was a
construct that I could use to express this. particular thing, I look up
in the documentation and it’s always supported. So, as one of my
favorite examples, one of the output formats that Handok supports is
various slideshow frameworks. So Beamer for people who use Lawtech and
Reveal JS for people who use HTML and CSS and these slideshow frameworks
basically allow you to replace something like PowerPoint, Keynote,
Google slides with essentially like a text-based format. I really like
doing slideshows in Pandock markdown. There are a few reasons for that.
The first reason is that it’s really useful to be able to reuse some of
the same content from like my blog post or essay even in the slideshow.
There are some really minor and almost petty, but really significant
reasons. Like, I like to have equations or code blocks with syntax
highlighting in my slideshows, and there’s not really a good solution
to putting like a syntax highlighted code block in Keynote right now.
00:32:39 - Speaker 2: Last I remembered, the gold standard at the Ruby
conferences I used to frequent was to take screenshot of Textmate and
paste that in.
00:32:47 - Speaker 1: Yeah, it’s awful. I don’t want to see your like
monochai editor with like the weird background that contrasts weirdly
with the slide background. I just, ah, and it doesn’t scale on a huge
conference display anyway, I digress, but The other reason why I really
like doing my slideshows in text is actually that there is often a
hierarchical structure to my presentations, right? I’ll have like these
main top level sections and then I’ll have subsections, and then I’ll
have like sub subsections and all of these manifest and slides. But in
the gooey thumbnail view of most of these existing Slideshow editors
like PowerPoint or Google slides, it reduces it all to like this linear
list. It’s like, here are all of your thumbnails in order. And it makes
it very hard, as soon as I have like an hour-long conference talk, how
do I like jump to this subsection that I know exists, aside from like
scrolling past like 117 thumbnails and trying to find the right one,
right? And moreover, let’s say I want to Reorder a certain part of the
talk because I think it better fits the narrative structure. Now I have
to like figure out which thumbnails I need to drag to which other place
or worse, go into the individual slide, select the text from that, move
that somewhere else, and it’s just way, way clunkier actually than
reordering some text in like a bullet list outline in my editor.
And then the other part is that I was talking about how Pandok has
really great support, expressive support for idioms of different
formats, and one thing you often have in slideshows is that I have some
element on the screen and then I press, you know, the next button again
and then another element will appear.
So in Pandoc you can denote this with just like an ellipsis basically so
like dot dot dot and then if I have a slide where I have a paragraph and
then the dot dot dot and then another paragraph, it will render with
just the first paragraph visible and then I press next and then like the
subsequent paragraph comes in.
And that’s like just a very lightweight way to handle these stepped.
Animations compared to going to the animation pane and then clicking the
element that I want to animate in and so on and so forth.
So it started off with me being like, I’ll just prototype in this
format, but then it ended up supporting columns, it supports all these
things that you actually want. And I was like, this is in many ways a
more ergonomic way to handle long technical slideshows. Anyway, I have
to chill for Pandok anytime I talk about rich text, I’m contractually
obligated to do so.
00:35:08 - Speaker 2: Yeah, it’s a great piece of software, use it here
and there. I think I was doing some Asky doc kind of manuals many years
ago and yeah, just in general, it’s also worth looking at the homepage
that you mentioned the plot they have where it shows all the different
formats that can convert between is quite fun. You click on that, you
can zoom in.
00:35:26 - Speaker 1: Yeah, I had this really elaborate plan when I
decided to go to Berkeley, that I was going to print out a door-sized
poster of like that graph that shows all the formats they convert
between and then show up at John McFarlane’s door and ask him to sign
it. But then the pandemic interfered with some of those plans.
Nonetheless, it remains on my list.
00:35:48 - Speaker 2: Good bucket list item, pretty unique one at that.
00:35:51 - Speaker 1: Also, I found my tweet, or I found the draft of my
tweet, which is about eternals, and I said, directed by Chloe Zhao, the
latest entry in the Markdown Cinematic Universe features an ensemble
cast of multi markdown, GitHubb flavored markdown, PHP Markdown Extra, R
Markdown, and Common Mark as they joined forces in battle against
mankind’s ancient enemy, Doc X. Nice.
00:36:12 - Speaker 2: Wow. You would have gotten the like from me.
00:36:16 - Speaker 1: Yeah, we’ll see if it ever sees the light of
Twitter.com.
00:36:20 - Speaker 2: You briefly mentioned there equations and La tech,
and maybe that’s a good chance to talk about the equation project you
did for notion. And part of what I thought was so interesting or what I
think in general is interesting about equations is that they are
obviously an extremely important symbolic format, but in many ways
extremely different from the pros we’ve been talking about.
So English or other languages, even languages that are right to left or
something like that, they all have the same kind of basic flow and the
way that we represent sound. So with these little squiggly symbols, even
though the symbols themselves and sounds vary and how we put them
together into words across languages, that’s a common thing. If you go
to the mathematical realm, you have symbolic representation, but
equations are the whole own beast, and I think one that has gotten a lot
less attention from kind of the software and editing world. So tell us
about that rabbit hole.
00:37:16 - Speaker 1: Yeah, so just as context for people, notion and
many other applications actually have long supported block equations, an
equation that basically takes up, you know, most of the page
horizontally.
What is much more uncommon in editors is support for inline equations
and so this can be something as simple as saying, You want to type let X
be a variable, and X should be formatted or stylized mathematically.
Being able to refer to elements of a block level equation in inline text
is a prerequisite for being able to do any kind of serious mathematical
writing, yet because this is kind of this niche area that has
historically been the purview of Overleaf and other law tech editors,
it’s really not implemented.
In most editors.
So I pushed really hard to add inline equations and inline math to
notion, because I was like, there’s a huge opportunity for people to
write scientific or mathematical documents that take advantage of all of
notion’s other features like being able to embed FIMA or embed
illustrations and things like that, right? So, it turns out that it’s
kind of difficult, exactly as you’re describing to do this equation
format.
There’s been very little innovation and research more generally into
what is like a good interface for inputting equations. So I think most
people Probably familiar with Microsoft Word or Excel have these
equation editors, or even like operating system level sometimes where
you basically like open this palette, and there is a preview and there
is a button for every possible mathematical symbol or operator you can
imagine. And then for composite symbols like the fraction bar or
integral or something like that, you find the button for that, you click
it, and then you click into like the little subboxes and then you find
whatever symbol you want and you put those there too. So it’s kind of a
structured editor, but like in an unimaginably cumbersome interface.
This is what I used to do my lab reports in high school, for example.
And then at the other end of the spectrum, you have things like law
tech. Law tech is basically how everyone in at least in computer science
and mathematics chooses to typeset their work, typesets complex
mathematics. One of the real selling points of law tech, I think is that
It turns out that operator spacing is really important, and there’s a
big difference between, say, a dash that’s used like a hyphen or a dash
character that’s used in text, and a hyphen or a dash character that’s
used as a minus sign in an equation, the spacing is subtly different.
And one of the big things that Lawtech does is it basically allows you
to declare certain operations in certain contexts as like a math
operator versus just a symbol versus just like a tagged group of
characters, and it correctly handles the spacing depending on what kinds
of characters are around the operator in question. And so Lawtech
basically produces really nice looking mathematics at the cost of this
markdown which looks like I kind of smashed my keyboard that only had
like 3 characters. It’s the exact opposite of the equation editors
instead of having a button for every imaginable character, you only have
3 buttons. The buttons are backslash, open curly brace, and closed curly
brace, and somehow like permuting those characters is supposed to get
you like any possible mathematical outfit. There’s just two ends of the
spectrum.
00:40:41 - Speaker 3: Yeah, I used to do my analysis homework in college
in law tech, and I remember when I first looked up how you would input
in law tech these formulas, like, that can’t be right. This is not the
best way in the world to do this. In fact, that’s it, that’s the one
and only way.
00:40:53 - Speaker 1: It really is, it’s terrifying. It’s the one and
only way and the wild part is there are people who are like super, super
good at law tech. They can like live tech their lecture notes. I was
never nearly like that fast, but some people can do it usually with
extensive use of macros, which macros are another selling point of law
tech as you can define these kind of custom shorthand for operators you
use a lot. But anyway, yeah, so you have a lot of tech sort of at the
other end of the spectrum, like really quite unreadable, oftentimes,
like, it’s like a right only format, many times.
00:41:23 - Speaker 2: And of a regular expressions come to mind on that
as well, yeah.
00:41:26 - Speaker 1: It’s exactly the same zeitgeist, I think. It
turns out that figuring out how to have like a combination, gooey, plain
text interface that allows you to be like in a rich text editor like
notion, then. into an inline equation field to have like an inline
symbol and then go back into the GUI editor was like just very
unexplored territory.
And it kind of makes sense that lots of people don’t prioritize this
because many people that notion rightfully had the question like, oh, is
this something we should be working on? But first of all, it turned out
that if you actually tallied up like our user requests, inline math was
like near the top.
Of editor feature based requests. And then more generally, it turns out
that because this is like a prerequisite for many researchers and for
students, you can get a lot of people on your platform who rely on it,
you know, as a student to take notes and something like that, because
there’s literally no alternative. And then they are able to stick
around and use the platform for all kinds of other things.
So this is just kind of a plug that more editors should implement this.
But Yeah, I thought that this project was really interesting because in
the interaction paradigm, you want to capture a lot of the things that
are very fluid about editing regular text. So for instance, we knew it
was important that you should be able to use the arrow keys to move left
and right, kind of straight through a token without editing it if you
wanted, or if you wanted to be able to go. Into a token and edit it
using the arrow keys, you shouldn’t have to like use the mouse to
click, although, of course, you should also be able to use the mouse to
click. And when you have this formatted equation, we made the decision
that the rendered equation would be represented as this atomic token. So
if you were highlighting text to copy and paste and move around, it
would be like highlighting a single character that would just be like
the whole equation. But of course, you could go in and edit the
equation. Any way you want it in kind of this pop up text editing
interface.
I think another thing that’s the subtle interface challenge here is
that like Mark was saying, there is often a Uh, disproportionately large
number of characters used to represent the equivalent of like one
character with a formatted output. And so that’s something you don’t
really take into account. The output is like X with a hat in San Sara
font, and then there’s like 25 characters of markup that goes into
that, and you just need to like scale the interface appropriately to
take that into account.
But I think that it’s really interesting because It shows the power of
combining different input and output formats in like the same atom,
right? So you have like a single line of text, and you want to have rich
text that’s formatted and stylized and so on, hyperlinks, and then also
equations or whatever inline rendered output of another input format
that you have. I think that that’s really where GUI editors and whizzy
wig editors can shine is being able to combine these like, Input formats
and output formats like in the same line in Chu, yeah, I guess you
can’t really do that at all with the terminal or something like that,
and I say this as someone who uses like CLIIM for everything.
00:44:34 - Speaker 3: This is bringing back so many memories. I wish I
had notion with equation support back when I was a math undergrad. It’s
so nice.
00:44:41 - Speaker 1: I’m like the notion math stand guardian, I don’t
know, something like that. And I’m always keeping track of like all the
cool things people are doing using equations and notion.
A lot of people are doing like math blogs in notion, which is really
awesome for me to see. Also, I just feel like they’re having tried lots
of other things. They’re just like really isn’t. A good alternative
short of like actually writing lots like for your blog, which no one
really likes. And yeah, I mean, certainly it’s the kind of thing that I
implemented originally, kind of, I was like, I’m gonna do this for
myself, and then realized that lots of people would be able to benefit
from it.
It’s been really cool to see a bit of reception it gets, like the
inline math tweets on the notion, uh Twitter account overwhelmingly get
the most engagement and interaction.
And initially, like the marketing team was shocked. They thought this
would be the super niche feature, but no, it turns out that people love
math and like, they may not be the most vocal proponents or they’re
used to no one caring about math type setting, things like that.
For a while, I think it was the case that when I did find an editor that
had support for equations of some kind, to me, it was overwhelmingly
obvious that the people who implemented it did not regularly use
equations for writing. I think you can often tell that with different
features. So I think that having that kind of Representation is not
quite the right word, but being able to see a feature that was designed
by someone who really cares about using it themselves is really cool for
people who are interested in typesetting, students, researchers, people
who are interested in typesetting more mathematical text.
00:46:11 - Speaker 3: Yeah, and I think it’s really important, like you
were saying that it’s mixed media because you’re combining the
equations, the inline equation and the block equation, by the way, in
the world class form, which is a lot tech based with a world class rich
text editor with text and images and stuff. It’s really nice. I do
think there’s still one frontier here, especially for math, which is
the fully gradual process from you’re taking handwritten notes and
you’re working out a problem and you’re drawing squiggly diagrams all
the way up through your finished homework. I remember when I was at math
undergrad. I would basically have to do the homework twice. You do it
once on paper. Nobody could read that, including myself, so that, you
know, do it in lot again. And I always wish there was a way to do it
incrementally. You sort of changed equation by equation and diagram by
diagram into the final product. And I know there has been some research
on uh turning equations into lot tech formulas with machine learning. I
don’t know if I can do handwriting, but perhaps someday we’ll get the
new support for equations and you can go all the way to the end.
00:47:02 - Speaker 1: Yeah, like you, I share exactly the same
frustration that you have to essentially do lots of things twice, and
the relative position of everything is ambiguous, and Lawtech is what
allows you to do things like have subscripts of subscripts, which would
be really inscrutable in most people’s handwriting, including my own,
and, you know, subscripts of subscripts along with super scripts and
things like that. There are just so many ambiguous details and it turns
out in my experience with like, anything that tries to automate the
transition is that I always end up Going through and like really
rewriting all of the details to be structured in a readable way.
You have this other problem which back in the days of like Wizzy Wig web
editors like Dreamweaver and Microsoft Front Page and things like that,
you would often end up with this problem where you try to do like any
edit in the Wizzy Wig side and then you look at the generated HTML and
it’s ridiculous. There’s just like 16 nested empty span tags, and no
one would ever be able to maintain that.
And my worry is basically that when you automatically create Markup for
something that has a very complex graphical representation, it’s really
like one way, you know, maybe it will help you produce a compiled
output, but it doesn’t actually help you go back in and like edit and
tweak the representation later or it’s just so inscrutable if you do
that it’s kind of also a reg x type situation.
I think we really need to get to some kind of like good intermediate
representation that allows you to flexibly go both ways.
And that goes back to something that I think Adam and I were chatting
about earlier, which is that a lot of people gripe and complain that
like law tech is the best we have and, you know, I’m one of them, but
It really is the case that, you know, lottech was just this like
monumental effort by really a few people and amount of effort that would
be like considered really impressive if I were to try to do the same
thing but better today and not a lot of people just have like spare time
to do this all in one text formatting, packaging, document
representation project, even though it would have huge impact on the way
people write and publish these kinds of documents. And so in many ways
we’re sort of just bottlenecked on the fact that It’s hard to do
incremental improvements to this particular area. We really depend on
these like software monoliths to keep us afloat.
00:49:19 - Speaker 2: I’m not nearly as mathy as either of you, but I
can’t help but make the comparison on these equation editing to what
you mentioned earlier with kind of structured editors and programming,
where whether there’s lightweight help from your text editor, things
like code folding, syntax highlighting and autocomplete, or full
structured editing, some of the visual programming stuff we talked about
with Maggie Appleton, like Scratch, for example, or these flow based
systems that are fully graph. and you sort of can’t have it in a bad
state. And I can’t help but to think there might be some direction like
that that is not necessarily the right only inscrutable tech, but is not
the Microsoft Word one button literally for every symbol you might ever
want.
It does seem like there might be some other path, and yeah, I agree
it’s a monumental effort, but I mean, mathematics is so important and
foundational and so much of human endeavor that certainly seems like one
worth investing in, although perhaps hard to reap a profit from, and
that makes it harder to put concentrated capital behind it.
00:50:20 - Speaker 1: Yeah, I think that there’s definitely very clear
demand for I think something exactly like what you’re describing, which
is somewhere in between the two extremes, and it is really relevant
because ACM, which is the Association for Computing Machinery, the
academic and professional body really for computer science, they are
currently undergoing this.
Fiasco, maybe, I probably shouldn’t go on the record as calling it a
fiasco.
The ACM is currently undergoing this initiative called TAPS, which is
the ACM Publishing System, where they are attempting to revise the
template by which all computer science research is published and
disseminated, and the idea behind this is that right now, computer
science research is published to these PDFs. Initially they were all two
column PDFs, now I think there’s some one column PDFs. They want to
output HTML as the archival format for various reasons, including that
it offers much better reading experience on different screen widths, so
like phones or tablets, which are increasingly how people are reading
papers, not just printed out. And they are much more accessible than
PDFs. PDFs are just like really quite inaccessible, especially to screen
readers and other assistive technologies that are trying to parse out
all the different math or whatever arbitrary formatting you’ve decided
to use. The upshot of this, I guess, is that there are currently a group
of very smart people who are trying to figure out how in the world
we’re going to get people to start writing all of their papers and
outputting them in a different format, in a world where everyone is
already used to preparing. Their publications and preprints in law tech.
And turns out that even if you solve the problem of like what the input
syntax should be, rendering math in the browser is like an extremely
unsolved problem.
00:52:05 - Speaker 3: Yeah, isn’t the state of the art that it like
generates PNG and sticks it in the web page?
00:52:09 - Speaker 1: Not exactly, but like almost. OK. So MathML, which
is like an XML dialect or like mathematical markup language, was this
effort to build.
HTML XML style syntax for typesetting mathematics.
Naturally, it is only implemented in Firefox, so that’s really
unfortunate. So in terms of the state of the art, there are basically
two libraries that you can use to typeset mathematics. There’s math
Jack and Caltech.
Mathjax supports basically all valid law tech, including, you know,
different. Environments and equations and things like that.
The problem is that Mathjacks is very slow. So if you ever go on math
overflow or another like related stock exchange and you see like all of
these answers with like weird gaps, and then as you watch before you,
the page starts to like load all of the rendered equations like bumping
everything down one level at a time. That’s math Jackson action.
And oftentimes it is doing what you’re describing where it is
outputting like an SBG or a PNG or something like that, and it’s just
like reflowing the page with every equation.
So then you have Caltech, which was a library developed at Konn Academy
where they realized that math Jack’s performance was basically just
like not satisfactory for their exercises and things like that. Sootte
supports a much more limited subset of all of Law tech syntax, but it
does it all using CSS basically, and it doesn’t reflow the page for
every equation. It’s basically instant surrender.
So tech is what we use at Notion, it’s also what’s used in like
Facebook Messenger, which supports equations if you ever tried that, and
many other websites, and basically it means that your options, if you
want to render math are only target Firefox. Use a limited subset of
math that’s supported by Kottech and Consign yourself to like extremely
slow, dozens of reflow, full expressive power rendering to inline
PNG’s.
And so that’s just not like a great situation to be in, and we haven’t
even gotten to the question of like how people write math. So I would
say that people underestimate like how open this problem spaces.
00:54:17 - Speaker 3: Yeah, man.
00:54:19 - Speaker 1: Just take a moment of silence to like recognize
the gravity of the situation.
00:54:23 - Speaker 3: This is an aside, I don’t know if you want to put
this in the episode, but now I’m curious. It sounds like both of those
are interpreted in the sense that the equations are rendered at load
time instead of being compiled down to some like HTML and CSS that you
can render without JavaScript. Like, basically, do you need JavaScript
to render these pages?
00:54:39 - Speaker 1: Yeah, basically, I should say you also need
JavaScript, unless you’re doing the pre-compied to MathML and then hope
that people are using Firefox.
00:54:47 - Speaker 3: Man, I feel like there’s no way that that stuff
loads in 10 years, but we’ll see.
00:54:52 - Speaker 1: I actually had this exact argument, again, I
don’t know if you want to put this in the episode.
I had this exact argument with Jonathan Aldrich, who’s on the taps
committee when we were talking about this, and I think the point was not
so much that you can guarantee that the artifact loads. Exactly the same
way in 10 years, but that the representation is rich enough that one
could feasibly build software that renders it the same way in 10 years.
So it’s more about the fidelity of the like underlying representation
where like a team of, I guess, digital, you know, archaeologists could
recover the work that we were doing and not so much like we trust in the
vendors to like keep everything stable, which is obviously never going
to happen. You know, the only reason like PDFs are stable is because how
many trillions of dollars of IP depend on being able to load the PDF the
same way as it was written, you know, 30 years ago.
00:55:45 - Speaker 3: Yeah, interesting.
00:55:46 - Speaker 1: Nice. Going back to this idea earlier that Mark
mentioned of the spectrum of like plain text, rich text, Wizzy wig
editors.
One recurring theme for me is thinking about decoupling this spectrum
into like what is the format and then what are like the editors and
tools that we can use to interact with this format, so they structured,
unstructured, etc.
I want to call outAR, which is a native application for Mac OS and iOS
that does a really great job with this, which is that Bear is basically
Something in between a whizzy wig and a plain text editor in that
you’re always editing markdown documents and indeed, when you have
something that’s bold, you can see the like asterisks around it that
delimits that character.
But all of these standard, you know, Control B, U, editor shortcuts work
as you would expect.
And more importantly, you can see like the formatting applied in real
time.
So That when you do star star, hello star star, he suddenly becomes bold
face in this gooey.
And so in many ways it combines like the fluidity and the real-time
preview of a rich text editor or previewer with the flexibility of like
ultimately just writing plain text characters. And I think this is like
really unexplored area.
I don’t just mean something like Open VS code or VIM and type
characters and then see like different formatting labels attached to the
results.
I mean like a native application that’s really designed like for end
use or end users, that doesn’t fully obscure the input syntax but does
real time rendering in place.
It’s not even like in monospace font, right? It makes it feel much more
like this is actually the output that you’re targeting. And not just
like an input step that needs to be pre-processed. I think that there is
a lot of room for applications that are kind of in between and in that
same spaces where it doesn’t entirely obscure what you are writing, but
it does give you a lot of the benefits of previewing things and having
like a GUI application outside of the terminal in terms of like
capturing the richness of the possible results.
00:57:52 - Speaker 3: Yeah, I like the bear approach a lot. Now, are
there particular domains or types of documents that you think would be
susceptible to this approach, or it just for rich tech specifically?
00:58:01 - Speaker 1: So I was making a list of like all of the
different traditionally graphical outputs that have corresponding plain
text representations and a lot of them I was thinking about, for
example, in engraving sheet music, right, traditionally you would use a
desktop program like Finae or Sibelius nowadays you have options like
new score and flat, which are more web-based editors, but you see the
staff and you click notes. In the staff like corresponding to where you
want the note, and you know you use the quarter note or the 8th note
cursor to pick the duration and so on.
And then at the other end of the spectrum you have Lily Pond, which is
kind of like law tech I guess for engraving sheet music where you type a
very like law tech-esque syntax and out comes, you know, beautifully
typeset sheet music. For me this is like a little bit too. Gnu edgy,
just because when I think of like composing music, I’m very much
thinking about like what the staff looks like, just to be able to
visualize chords and counterpoints and things like that.
But I think the upshot is that like you could very easily have something
in between where you have like a text-based or non-binary representation
of like a piece of music or a composition, and then you can edit it
either using like the text editor or using the structured editor of an
existing Wizzy wigUY like composition software or notation software
rather, and edit the same representation both ways. And then likewise,
you have for diagram generation. This is an area that’s been A real
pain point for me historically because you can basically do something
like really low fidelity, like sketching on paper, but then if you
don’t want to like take a picture and upload it to whatever document,
right? All of the options are like very high fidelity, like there’s
omnigraphle and whimsical and Sigma, which is even more involved where
you get all of these nice things like lots of styles and force directed
layout and so on and so forth, but it’s like quite cumbersome to input
a diagram that you sketched in all of 30 seconds into omnigraphle in its
full glory. And then you have like on the plain text end of the
spectrum. The software like graph is Tie for Law tech things I really
like are Mermaid, which is a markdown type syntax for quickly generating
diagrams. There’s SVG Bob, which is incredible. It basically lets you
turn Asy art into formatted SVG though, as a brief aside, I don’t
actually know what problem this is solving. Aside from being incredibly
cool, because at least for me, I consider myself someone who’s like
fairly artistic, and it takes at least as much effort to figure out how
to make a really nice Asky art like thought bubble as it does to figure
out how to actually like do the SVG. I’ve always really wanted
something that basically allows you to edit it either as text, which
allows you to prototype really quickly, make a fast flow chart or
something like that, and something. I’ve always really wanted an
intermediate representation for diagrams where you can edit it either on
the text end using something like mermaid to do really fast prototyping
for a flow chart or something like that. And then if I wanted to have
more precision and control, I could also pull it into software like
omnigraphle or Figma and make fine grain tweaks, um, get like my nice
force directed layout or control where individual nodes were if I find a
grain control over positioning, things like that. I guess I think there
are lots of different areas outside of just traditional documents that
are ripe for an editor or a representation that learns some things from
the plain text approach and some things from the whizzy wig approach. I
think that we are, yeah, we’re getting close to being able to explore
those, but I would love to see more work in this area.
01:01:40 - Speaker 3: Yeah, this is very interesting. One challenge here
I think is with plain text and rich text, the structure of the text and
structure of the final output are going to be pretty close.
And so that makes it most feasible to have the thing where you’re
seeing both the worlds superimposed with the double asterisks on both
sides and the bold text, for example, with something like a diagram, if
you were to represent a diagram in just like Like not like input, it
would be a complete mess. It basically no resemblance to the final
output, just be like a string of really opaque characters, and then it
would compile out to a nice graph, but it’s kind of hard to go back and
forth because of that.
One way to combine these two worlds would be to invoke the command
palette metaphor that we see emerging so often, as you can imagine, OK,
you’re editing a score or you’re editing a graph. And instead Having
1000 buttons around the edge of your screen like you do with these
typical applications, the only interfaces you can click on stuff and
then you can type stuff in the command poet. So you click up where you
want to add a note and you say like B, you know, BQ, and it puts in the
Bcor node and so on. And similarly with graphs, you could click on a
node and you could invoke little commands with your text editor or
perhaps edit the little node locally represented as a little text box.
That’s kind of a way to bridge this issue of a pure tax representation
would have no obvious correspondence to a 2D or a 3D image, but if you
have some way to get more local nodes, it could work well.
01:03:00 - Speaker 1: Yeah, definitely.
01:03:01 - Speaker 2: And the thing that brings to mind for me is our
oft-cited favorite tool for thought, which is the spreadsheet where you
do have this, it’s a very, very simple version of that, this 2D layout,
but in fact you do click on cells and type in symbolic there, so you are
mixing a visual spatial layout, a very lightweight one with some
symbolic representation.
01:03:23 - Speaker 3: Spreadsheet remains undefeated.
01:03:25 - Speaker 1: One thing that I find really interesting about
spreadsheets, that’s I think often very unexplored is that many
applications like Air Table notion is also very much guilty of this.
You can capture like the power of the spreadsheet as like a relational
database or we like what happens if we impose better structure onto the
different columns and things like that, but there’s like a separate
totally untapped. Under explored area of spreadsheets, which is that
it’s basically this canvas, right? Spreadsheets capture everything that
people liked about table-based layouts in HTML with none of the stigma
associated with it. And so you can create these like really complex
interfaces that basically just do data. and things like that and put
things, be like, OK, I’m going to like copy this data and bring it over
closer to where I’m working now so I can reference it more easily.
It’s basically just this grid, right? And that’s totally unstructured.
It doesn’t correspond to any kind of relational format, but it’s also
a really powerful computation paradigm.
01:04:20 - Speaker 3: Yeah, totally. I think people really love to be
able to click somewhere and put stuff there. And a lot of spreadsheet
use is just that. They just want to click there and put text or put a
color, and there’s no formulas at all. And by the way, this goes back
to our idea of convergence of the Office document types. I see people
using Figma for this a lot, like they’re not designers, they’re not
designing interface. They want to click and put pictures on a 2D canvas,
and they want to click and put text there and you could see a sort of
continuation of this world where these things continue to merge as the
software gets more sophisticated.
01:04:49 - Speaker 1: Yeah, and then on the subject of diagrams real
quickly, I remember that I want to mention sketch and sketch, which is
this project by Brian Hempel, Justin Lubin, Robbie Shug at University of
Chicago from a couple of years ago, and the idea there is you have
direct manipulation programming for SBG.
So in the same you have this editor and then on the left side, you might
see the code that outputs a certain SPG on the right side you see the
SP. itself, and you should be able to do things like directly go in with
the mouse, click an anchor point and drag it somewhere or do other kinds
of transformations that people are used to when SVG editing, and it
should obviously be reflected in the output, but also change the code
that goes into it, and then you can make changes to the code and it will
modify the output.
I think this is one of the most successful examples. I’ve seen of an
editor that actually manages to keep this bidirectional linkage working
and when you make manual edits with the direct manipulation edits with
the cursor, it doesn’t totally botch your code and when you make
changes with the code, it doesn’t lose all of your edits with the
visual side. I think it would be great to see like more things like this
for more structured areas like diagramming or things like that.
01:05:59 - Speaker 3: So many research projects to do.
01:06:02 - Speaker 1: Yes, lots to do.
01:06:04 - Speaker 2: So slum, I see a recurring theme in how you think
about all of this, whether it’s equations, prose, rich texts, musical
score, or diagrams, is this intermediate format concept, and maybe like
a straw man or an outside view might come at this thinking, well, being
able to see something like a markdown is sort of exposing plumbing that
nerdy programmer types might like, but The reason we invented what you
see is what you get word processors, whatever, 40 years ago or whatever
it was, was to potentially liberate us from that.
But I see that you see the future is not one where those go away.
We want to expose that. There’s some value to that separately from a
fully visual 100% mapping the rendered output and the way you edit it
looking precisely.
The same, so I think that eliminates somewhat what I would imagine how
you would answer the question I was going to ask you about the future,
but with that in mind, I’ll basically say, yeah, if you look forward,
say 5 or 10 years to what advances either have happened or that you hope
to see happen in terms of how rich text works on our computing devices,
what does that look like?
01:07:16 - Speaker 1: Yeah, I think it’s exactly like you were
describing, we originally had this idea that you would be able to get a
Wizzy Wig editor or something like Microsoft Word and totally decouple
yourself from this underlying representation. I think that works up
until the point where you have lots of different Output formats or
different ways of viewing the document that people would like to use.
And as soon as you are in a world where even something like, let’s say
I want to have two different views in a GUI application, all of a sudden
it becomes much more beneficial to have some kind of intermediate format
so that you don’t have to do like N times different renderers and
parsers and compilation pipelines for all of these internal things.
01:08:01 - Speaker 2: So there’s a simple example of that earlier you
mentioned the reading academic papers on different size screens, you
know, a phone versus a desktop versus a printout, that even just the
basic reflow of the text, simple as that seems to a narrower or wider
screen actually is pretty complicated and There was an approach of
designing for several different screen sizes, but now we know that
that’s not very futureproof and doesn’t the way we want. And so as
soon as you have anything that’s even slightly dynamic, even something
as simple as text free flowing, that’s the place where you think in an
immediate format is necessary.
01:08:36 - Speaker 1: Yeah, exactly, like it’s not tractable to design
like a phone version of the website for every possible phone and then
like a tablet version for all the tablets and then a desktop version.
And but also like a projector version, things like that.
So the layout and the appearance is driven by the content itself. And I
think that there’s an idea of that for outputting a paper.
If you’re thinking about outputting another artifact like a diagram or
something, I think there are situations where it’s really useful to be
able to do standard direct manipulation diagram editing and then also
situations where it’s really useful to be able To like select all of
the text that corresponds to a certain subgraph and just like move it
somewhere else and allowing people the flexibility of choosing between
those different edit options, depending on what task they’re trying to
perform, what problem they’re trying to solve is like a really big area
of opportunity.
So I think like, we’re still at a stage where with all of these
different new editors like Coda or Notion or even bare craft. Editors
are still like very much borrowing from each other a lot and
periodically striking out in the direction of like, here’s a new kind
of block or a new kind of like cell or type of text that you can have,
and I think that while we’re still in the stage of like churning
feature churn around, what are the editing primitives that people care
about, what things go in a document, it’s going to be hard to develop
any kind of like unifying framework or IR for these documents to work
together.
I’m hopeful that once we reach a scenario where there’s a little more
stasis and maybe more overlap in the capabilities and interests of
different editors, you could have like this intermediate platform that
extends from things like Rome to notion or notion to air Table or
something like that for the components that make sense to go into those
other platforms, and then you can actually really flexibly move your
data around between these areas and likewise, within applications, maybe
you want to be able to start off with something really low fidelity and
gradually get something higher fidelity, like it would be really nice to
have a slider almost. That allows you to move up and down the ladder of
abstraction, but failing that, like an intermediate tool that you can
plug in and be like, OK, I want to take this like bullet list of to do
items and upgrade it into a database for like things or something like
that. Something that’s more plug and play that also handles structured
data in the same way we have a tool like Handdoc for text. That’s what
I’m really excited to see because I really think of rich text as slowly
expanding to include all the things you might want to have in a
document, which might include Embedded views of other databases or
things like that. So just having a more expansive interpretation of rich
text that is less constraining with respect to the kinds of artifacts
that you can produce, allows you to combine more things together, has
like a notion of structure that enables these kinds of really Powerful
edits like re-parenting an entire subtree, while also allowing you to do
things like select a linear region of text and copy it somewhere else. I
think that’s kind of the direction we’re moving in, where we combine a
lot of flexibility of plain text editors that we’ve seen to date with
some of the power of having more structure.
01:11:51 - Speaker 3: It’s a pretty exciting future.
01:11:53 - Speaker 1: Yeah, let’s hope we get there.
01:11:54 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at @museapphq. You can
reach us on email, hello at museapp.com. You can also leave us a review
on Apple Podcasts. And slim, your drive and passion for all things text
and in fact expanding my mind has been expanded on what even we would
think of text as being and what these intermediate formats can do for us
in the future. So I’m really excited that you’re on the forefront of
this and pushing forward our tools.
01:12:29 - Speaker 1: Yeah, thanks so much for having me. This was great
to talk about.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: I think complexity gets a bad rap because I think
a lot of times people think complexity is the opposite of simple and
everyone loves simple because simple is elegant. How do you have your
creator tools give people the knowledge of how to be able to address
such complexity?
00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad and Mac, but this podcast isn’t about Muse the product.
It’s about Muse the company and the small team behind it. I’m here
with Mark McGranaghan. Hey, Adam, and our guest today, David Hong of
Webflow.
00:00:38 - Speaker 1: Hey, thanks so much for having me.
00:00:41 - Speaker 2: Now something that we talk about quite a bit in
the Muse world, maybe we take inspiration from physical workspaces,
physical studios, but I understand you are creating your own physical
studio screen free these days.
00:00:54 - Speaker 1: Yeah, it’s one of the pandemic projects, if you
will.
We’ve been working in our garage and trying to create a more creative
space that just really fosters movement and I think the inspiration just
came from Back pain, you know, and just sitting in front of your desk
all the time and just being on Zoom, which is a lot of my day these
days. And I was watching Brett Victor seeing faces again and just really
got a lot of inspiration of like How do you leverage like physical
spaces to create stuff? So my girlfriend’s an interior designer and I
used to do a lot of art. I went to school for art, which ties a lot into
a lot of the work I’m interested in these days and really just wanted
to create a space for us to be like, let’s just work all analog and
really Just to feel something, right? Just create something really
physical, just to really deviate away from what feels like a 100%
digital world right now.
00:01:57 - Speaker 2: Yeah, doing things with your hands, the texture of
paper or certainly craft materials. I like to go to just art stores,
craft stores, and yeah, I like highlighters and I like chunky markers
and I like butcher paper, and I like all that sort of thing, and I have
less as the digital tools get better and better and in fact. Superior,
particularly in their shareability, which is really important on your
kind of distributed teams, those things become more of a curiosity maybe
or something I keep around, but every once in a while I get them out for
a similar reason to that. But yeah, maybe that means I should really
just take up like wood block carving or something like that.
00:02:34 - Speaker 1: Yeah. The thing that’s interesting about that too
is I think in many ways, our tools are processing way faster than we can
think about our ideas.
And the thing I love about working on paper and those chunky markers
like you said, is it gives you time to really kind of flush through the
idea and work on it because the problem today is not the level of
computation you have access to, maybe 10 or 20 years ago.
It’s like you can process and build anything, but it’s just like how
do you Hash out the ideas and I’ve really kind of found this return to
working on paper recently and that’s whether it’s drawing up a user
flow or creating low fidelity wireframes. It’s been really helpful to
work in that material that almost intentionally slows down and gives you
time to think a little bit deeper.
00:03:24 - Speaker 2: And I’d love to hear a bit about your backstory,
days before web flow, and then what you’ve been doing now that you’re
there.
00:03:30 - Speaker 1: Yeah, so, right before I joined Webflow, I was the
head of product design at a health tech startup called One Medical and
was there for about 4 years. I led design and research there.
00:03:41 - Speaker 2: Quick personal note, I was a customer there while
I lived in San Francisco. This was kind of A doctor’s office, but
reimagined a bit in terms of being more user experience centric. Is that
a right way to describe it?
00:03:54 - Speaker 1: Yeah, that’s accurate. I hope you had a good
experience with it too.
00:03:57 - Speaker 2: I did. I’m missing that there is no such thing in
Berlin as far as I know. User experience is not a key feature of doctors
I visited here, sad to say.
00:04:08 - Speaker 1: Healthcare experience is something where I think
we need more designers and more technology, like thinking about that end
user experience. Yeah.
So when I was at one medical, one of the first features I started
working on was our video visits platform. So it was being able to do a
one on one virtual call which You and your doctor, and I built that
prototype using Quartz composer and kind of started that from the
initial prototype of like how we could even wire the AV and really test
these cases. So a lot of what I’ve been interested in is design
prototyping in a lot of ways.
And prior to one medical, I was director of mobile design at a company
called Black Pixel that was really focused on Like iOS and Mac apps
doing our own products, but then also doing a lot of client services as
well. And what brought me to web flow was after I left one Medical, I
think. It’s really great when you leave a place that you feel like you
could be there for another 4 years, and that’s kind of how I felt at
one medical and was just looking for something a little bit different.
So I took a mini sabbatical, probably about 2 months off trying to
figure out what’s next.
And my original idea was considering to do a startup around like
prototyping on the iPad, because I think that was the year when Swift UI
came out and I thought to myself, it’d be really cool to Build tools
for people to build, and really build layout, and whether it was like a
full-on developer tool or prototyping tool. That’s what I was
exploring, but I think for me, I know how hard startups are and the life
expectancy of those. So, you know, it’s something that I was continuing
to explore lately, but then got connected with web flow. And for those
who don’t know, web flows a visual development platform and it’s
really focused on websites, blogs, and more dynamic web experiences. And
I think the thing that got me really interested in that is this bridge
between design and engineering. And it wasn’t just prototyping, but the
stuff you build goes straight into production right away.
So you can build your site, publish it, and you know, wire up a domain
and you’re done.
And I was just like, wow, you know, I think this is a really interesting
space to be able to take the things that I was really excited about,
which is like visual programming. And that is naturally just a part of
it too. And I was like, OK, this is a company I have to join. Like I
think at that time, they were growing and still growing, and I figured,
you know what, instead of doing my own thing, I’d love to join forces
with a company that’s already doing a good thing.
00:07:02 - Speaker 2: And thinking about the product positioning there.
Is the target user or I’m sure you have a lot of diversity of customers
now, but when you’re doing this design work, do you think of it as
someone who’s coming from maybe a simpler tool, I don’t know,
Squarespace comes to mind, and they want to upgrade and do something
that’s more powerful and gives them more control over the CSS more
capabilities, or is it actually the other way around, which is someone
who’s been hand coding their HTML and they go, you know, this is a
little bit tedious, and I’d like a visual tool that augments my ability
to do that.
00:07:35 - Speaker 1: Yeah, oh man, that’s such a good question, and I
think it’s something we’re talking about a lot.
And the thing that I know for sure is, you know, our end user and who
we’re targeting are designers, and not to get into this existential
crisis, but it’s like, what is a designer, right? There’s so many
different flavors of what a designer can do. I would say this predates
my time at web flow, but I would say like when the early product was
being developed. I think it was really focused on the web designer and
the web designer that really knew, really familiar with HTML and CSS,
you know, that material of code to create and build these sites, but I
think as Our customer base has grown, you are kind of seeing people who
maybe their mental models are more from the Squarespace or using a tool
like FigMA or Adobe XD to really understand design, so they’re kind of
bringing those mental models in. So I think the thing that I think about
a lot is What are the different types of personas of designers that
we’re looking to serve, and that could be many different levels, you
know, could be designers who know code really well or they want to use
no code tools so they don’t have to know code.
00:08:52 - Speaker 2: If I can make a comparison to Hiokku, this was a
similar, I think dilemma we had, you might say in our user base, and of
course a good product can be used by different types of people and it
works to try to understand the different segments you’re trying to
support.
Yeah, Hiroku both had developers who were people that maybe would have
struggled a bit to get like a production deployment of. on rails and a
SQL database and so on, and we made that much more possible for them to
do, but it also had the other way around, which was professional
developers that completely knew how to buy a server, install Linux on
it, put it in a co-location facility or set up a VPS or whatever, do all
that server and operation stuff.
They said, I don’t want to bother with that. I would rather outsource.
To you, it’s undifferentiated work. I just want to build my app, but we
have people that are sort of coming from two very different skill
directions that land on kind of needing the same solution, but as you
said, like their mental models of how everything works is going to be
wildly different in that, hence the huge design challenge to make a
single product that works for both of them.
00:09:57 - Speaker 1: Yeah, it’s such a tough challenge because what I
ask myself is, who do you serve in that instance? And for me, the answer
should be both approachable software for these sort of tools. is you
want to be able to abstract away the complexity, but you also want to be
able to pop the hood open, if you will, right? So if someone wants to
use code and make things more extensible, there’s a lot of challenges
if we cap that from people and they don’t have access to it and to what
you mentioned with Hiroku it’s like. Do people go with a different
solution, or do you find ways where it can be a little bit more flexible
for what people’s needs are? And I think that’s the sweet spot you
want to hit and it’s really hard to find, which kind of makes me really
excited about this space because it’s not only like a diverse persona,
but it’s also the different use cases and how people learn too. So
really trying to figure out how you find that place where it meets both
of those ends of the spectrum is really challenging.
00:10:57 - Speaker 2: Maybe that’s a good moment to introduce our topic
which is designing for creative tools. Now creative tools can include a
pretty big gamut from word processors and video editing.
Here we’re talking about maybe the fairly far end of the spectrum on
complexity, which is dynamic modeling tools, web design, development,
but if you think of that spectrum as being on one far end as the pure
consumer, very everyday apps, something like a kitchen timer.
Whether maybe things that are in the middle but still closer to that
consumer side might be social media, for example, not to say there
isn’t a ton of complexity in that, but compared to what you can do with
creative tools or what the user can do with creative tools, there’s the
variety of possible states essentially that a user can put their
document into with anything on this end of the spectrum is vastly
greater than some of those everyday apps.
And that creates some pretty big challenges, but also for the right kind
of person, and I would count, I think the three of us in that category,
those challenges can be very fun and interesting.
00:12:02 - Speaker 1: Yeah, it keeps you on your feet, for sure, and I
think the word I keep attributing to this is just dynamic, right? It’s
that it’s always changing, it’s always evolving.
And I think what’s most interesting for me in this space is you build a
set of capabilities for people and you see what they do with it, right?
And that’s different for what you alluded to is that, you know, a lot
of my background before was consumer apps or networks and e-commerce and
they’re more rigid in the user experience, so it’s more predictable
with what people will do.
Like, of course, there’s flows you want to Optimized for, but I think
there have been times where I imagine a lot of spaces of people working
in creator tools see this a lot, where end users just subvert and find
new ways to use your tool and you’re always so surprised by it and I
think Rather being worried about what happened to you, embrace that and
see where it goes, and I think that’s really interesting.
It’s just kind of like, uh, you know, this whole notion of like, I
think Microsoft uses the term citizen developer or you know, end users
creating stuff. Now it creates such a unknown journey map for a lot of
these users, which I think is personally really cool.
00:13:22 - Speaker 2: Yeah, that rigid design you mentioned in, for
example, e-commerce, that’s actually by design, you want a checkout
form, for example, the number of forks in that path should be pretty
minimal, right? The data is different, where I’m shipping to is
different, maybe there’s a few options in there, but you don’t want to
choose your own adventure on a checkout form and perhaps the work you
did in the medical space was similar that you want something pretty
structured, pretty rigid.
Everyone kind of does it more or less the same way with some essentially
minor variation is really the complete opposite of a great creative
tool.
I think almost by definition is one that your users will use it to make
things that you never expected. They like you said, that subversive
element.
00:14:08 - Speaker 1: Yeah, and I think that’s why at Webflow, we tend
to call things capabilities versus features, and we want to focus on
that lens where it’s like, what are we equipping end users being able
to do versus like, here’s this feature that will do X or do Y but it’s
more like, here’s this capability, here’s this offering. Let’s see
what you do with it.
00:14:32 - Speaker 2: I’d be curious to hear if there’s any cases
you’ve seen so far of web flows, users and customers doing something
interesting, unexpected, even even subversive.
00:14:43 - Speaker 1: Oh man.
00:14:43 - Speaker 3: Have you had any bitcoin miners like we did on
Hookku?
00:14:46 - Speaker 1: Not yet, not yet. We’ll see, there’s still time
for that.
I’d love to hear the Hiroka use case. There’s two that come to mind
for me, and one is a weblow community member created, I think it’s
called The Big Bed, and it’s a children’s story that he illustrated. I
can’t remember if it was directly about his daughter, but it was this
narrative that they created.
So he created an interactive site with web flow that had audio and just
this really great immersive experience.
And then there’s another use case where someone in the blood flow
community created a game that I used to love playing is he actually
recreated some of the intro and functionality of the game Civilization
in web flow, and I’m just like, oh my goodness, there’s so many
events, so many interactions built this, and you could tell like the
people who built this is just, it’s pure passion for learning and just
love of creating stuff and like.
When I saw those two things, especially, I’m just like, oh my goodness,
like this isn’t just for building like the websites built on Twitter
bootstrap where they all kind of look the same. It’s kind of returning
this sort of expressive form of the web, which got me really excited
because I think in my iOS days, I think at that time the web was
becoming a little bit stagnant and less expressive, but kind of seeing
these sort of tools come back for people to be expressive on the web, I
think it’s really awesome.
00:16:18 - Speaker 2: I think we talked with Wei Weixu a bit about kind
of personalization in our online spaces, and I think I expressed my love
of personal websites and the web and HTML remains and has only gotten
better with years, even if there’s fewer sort of GeoCity style places
for people that easily have their own spaces, what you can express
through a personal site is greater than ever before, but that’s
balanced out or maybe just drowned out would be the way to put it by.
Yeah, maybe social media profiles or even just sites that are designed
to be a profile for you, and it’s nice cause you upload a picture and
you type in a bio and you click on three things you like and it gives
you a nice looking page, but yeah, it lacks that personality, that
expressiveness, and certainly that handmade element, but that’s still
live on the web in terms of what you can do with HTML.
You have to get away a little bit from the template driven world of say
a Squarespace and a little bit closer to the metal if we want to call it
that, and I think you know hand coded HTML is a great way to go, but not
to drop in too many metause references here, but we also talked with
Maggie Appleton about visual programming, which I think David discussing
that episode is part of how you and I got talking and Talks about, well,
look, we don’t want to replace code, but maybe we want to layer new
kinds of visualization tools on top of it.
I think the web is really, really perfect potentially for that, and you
see a small version of that and say the developer tools, the Chrome
slash fire bug derived developer tools, but there’s so much more we
could do with that, I think.
00:17:53 - Speaker 1: Yeah, for me, the word I keep coming back to is
expression, right? And the expression of how you create, and I think.
I don’t like using like web 12 and 3 just because I think it’s just
like a continuous evolution, but for the sake, let’s say web 2’s a lot
of social media, a lot of feeds, and that’s where conversation
happened, right? And I think for me, I grew up in the earlier days of
the internet having a Geo City site using Dreamweaver to build my
personal websites.
I use this analogy of like visiting people’s homes and you would go to
people’s home pages to be able to see that expression and now things
are in social graphs, right? And there’s still a lot of where web 3
might move and I still think it’s.
Really early, but through all this, I think there’s a lot of this
interest to kind of bring personal expression back and bring back
personal websites, blogs.
RSS is a technology that I continue to use and love today, and I think
there’s like a resurgence to this because people want expression in the
content, you know, whether it’s personal expression or that of the
people they interact with.
00:19:02 - Speaker 3: Yeah, definitely hitting on some recurrent themes
from the podcast here, just kind of give another angle on it.
This idea of a personalized space is so important for professionals
because almost by definition, you’re spending all of your waking,
working time in it.
And if you have no agency over how it works and how it looks and how it
feels, that’s very demoralizing and discouraging. So for that reason
alone, it’s very important.
There’s other angle of like being able to do things that the creator of
the tool didn’t specifically envision. In some ways, that’s the very
definition of a creative professional, as someone who’s doing something
novel, who’s doing these.
Combinations because if there was no novelty for it, it’d be more like
turning a crank and why pay really high professional labor rates for
doing that, right? And so the tool has to facilitate it.
You have to make this leap of, we’re going to provide these primitives
and building blocks and people are going to reassemble them into games
or whatever, you know, civilization, who knows, right? You have to be
able to support that.
00:19:56 - Speaker 2: So going a layer deeper on what it means to design
creative tools and design for creators, including designers and
developers. One of the big topics in design is always mental models, and
I’d be really curious to hear about the mental models you’re using for
web flow, David, maybe Mark, you could talk to Muse a little bit or
maybe we have some other examples from our collective experience, but
maybe to start, Mark, could you define mental model just to make sure
we’re all on the same page?
00:20:26 - Speaker 3: Yeah, so a mental model is sort of the platonic
forms you’re dealing with in the domain. It’s the nouns and the verbs
and how they interact, you know, what is the way that you think about
the space? What are the primitives, how do you build on top of them? How
do you combine them? So, for example, with a desktop OS you have things
like files, folders, windows, things like that, mouse, and so forth.
00:20:51 - Speaker 2: One trick I’ve always liked for coming to grips
with the mental model of some system that I’m designing is to write a
glossary, essentially a list of all your vocabulary, and these are
things that you’re surfacing to your user.
So for example, I think I might have first tried this for the Hiroku
add-on system.
And in writing that glossary, I realized first of all we had way too
many things. There was like 20 different things in there we were
expecting people to keep track of, many of which were like kind of a
relatively new concepts and certainly pretty abstract ones. So we’re
looking for ways to kind of reduce those.
Second, I found that sometimes we would use two words to mean basically
the same thing, and that’s confusing. But then third, it kind of forces
me at least to ask, does each one of these serve a really good purpose?
Is a person going to have a clear understanding of what this item is?
They know this term refers to that, and they can either connect it to
something else they already knew before they started kind of using the
product or reading your documentation or whatever, or for the very few
you want to offer as new, is it worth your while to introduce this new
term, this new concept.
And of course one of the tricks, I think you Kind of illustrated pretty
well there, Mark, is to take physical world metaphors. So your desktop
is on your computer as a literal metaphor to your top of your desk.
Files and folders are also metaphors, although even there you see where
it’s an imperfect. fit.
My mom actually has commented on this a number of times, which is she’s
worked with paper files and folders for a long time and from her
perspective, a file folder is one kind of thing and it’s one of those
folding manila envelopes that you can put pieces of paper and documents
into. So she thinks that you should call files documents and you should
call folders files, and now of course, we’re set now, but it’s a good
example of where users have preexisting expectations, you’re trying to
borrow these metaphors, but they don’t necessarily map perfectly, but
you get some leverage there because you’re not asking someone to learn
a whole bunch of new words that don’t map to anything they know from
any other domain.
00:22:57 - Speaker 3: Yeah, and my experience has been that the product
architecture, which is the phrase we sometimes give to coming up with
and naming these mental models, is incredibly important. If you get this
even a little bit wrong, it’s gonna make everything much harder down
the road, and in particular for some people to be able to span the full
range of use cases from very simple to very complex, and to be able to
do unanticipated recombinations, they have to be really solid.
00:23:24 - Speaker 2: So what kind of mental models do you make use of
in web flow, David?
00:23:30 - Speaker 1: Yeah, I think a challenge in a lot of creator
tools is to decide how opinionated you should be. And what I mean by
that is when you become opinionated, there’s kind of a trade-off with
that, right? You can kind of really help guide people in how they build
certain concepts, or do you be more open ended and you give people the
flexibility to explore that. And I think the thing that’s tricky with
that is The question I ask myself is what mental models do people come
in with using web flow, so someone who is a front end developer, the way
they approach using web flow is going to be dramatically different than
someone who may use FIMA. And I think the thing that’s hard is In
design, there’s a lot of these things that are very similar, but not
necessarily identical, right? So, for example, in Xcode, the auto layout
engine is a lot different than auto layout in Figma, but yet, these are
things that people associate with how to approach using it.
So I think When we’re thinking about the mental models of web flow, I
think a lot of things that we’re asking ourselves is like, what do
people come in expecting, right? So, someone who’s coming in and using
layout may not think of things as divs, right? And also think about
things like nesting and parent-child relationships. They may be thinking
of it as an infinite canvas that they drag and move freeform. And unless
you kind of set position to absolute, there’s really no way of doing
that in a way that produces good code and That can be frustrating for
users if you’re coming in not knowing box model and some of these web
design practices. So I think a lot of things we’re thinking about like,
how do we become more opinionated in our own product without like
biasing them on what to build, right? So for example, a lot of this can
come from onboarding new users and teaching them like, hey, these are
the core aspects of web design that’s going to be really important for
you. To know, you already know this, great, you can skip it, right? But
if you don’t know, it’s going to be really helpful for people to
really understand those mental models, because I think for me, really
being true to the material and the material in this case being like HTML
and CSS I think. I personally wouldn’t want to abstract it so far away
where you’re creating some like proprietary markup or something, right?
You really want to make sure that you can get as close to the native
output as much as possible, but abstracting how people build with. That
I think is key.
00:26:08 - Speaker 2: It also occurs to me that some of the mental
models are things about what do my users come in expecting a front end
developer versus a designer, for example, but also, as you said, the
material, you just inherit a bunch of things that are just true whether
or not you want them to be, and certainly the web and HTML and CSS are
full of plenty of quirks and history and that sort of thing, and so
something about how the grid system works or something about how Flexbox
works or what have you, you’re just gonna inherit that. Some of that
may be good because there’s good mental models, some of it may be more
like baggage or gets in your way, and so presumably, maybe I’m
realizing now I’m just kind of resting what she said, but just for my
own understanding, you’re trying to figure out which things are
abstractions you really want to surface to your users because they’re
useful, they’re powerful, they’re compre. Sensible, they fit well with
the visual tool you’re creating and which are weird quirks of the web
that don’t really help you to know and I don’t need to know about, I
don’t know what JavaScript mification, it’s just we do that quietly
behind the scenes and kind of tuck it away and you don’t need to really
like have a concept for that in your mind to get value from the tool.
00:27:18 - Speaker 1: Yeah, and I think this is why I like the jobs to
be done framework where you’re kind of focusing on that outcome that a
customer wants, right? And I think for us, when we think about it.
There’s like multiple ways to build a layout, right? But if we’re kind
of looking at some of the best practices of like, here are the things
that people typically try to build and it solves like 80% of those use
cases, like how do we surface more of that because the likelihood of
what people want to build with that is higher, right? And there’s
always going to be this option B, C, D, and E that people can explore.
But when you give them A through E all at once. It’s this paradox of
choice, right? So if I drop a div and then you’re asking like, OK, you
can use display, flex box or grid, someone who doesn’t know what the
difference is three are, they probably just pick one, right? And then
really just trial by error with that.
But if we can be more opinionated about some of these things, I think it
helps reduce the cognitive load of decisions that people have to make.
So can we streamline people to what we think is the best decision while
giving them that option to subvert it or explore other paths to, as
opposed to give them all the divergent paths at once.
00:28:38 - Speaker 2: Now here we’ve spoken a little bit about sort of
things within the page ad, a flex box, and that sort of thing, but
actually the web has a huge number of abstractions or that mental model
glossary for the web would include pages, include URLs, would include
links. I think all of those are pretty well understood even by
non-creators, which is actually pretty great and so you can just rely on
using those things, I assume, even something like a website, what
actually is a website. Where are the edges of it that may or may not be
fully understood by the average person, they may not fully grasp when
they sort of leave Facebook and go to another site, but certainly I
think for your target audience, those things are probably really well
understood and you can totally lean on that, is that right to guess.
00:29:24 - Speaker 1: Yeah, absolutely. And I think that’s the beauty
of building for the web is there’s such a rich taxonomy and a lot of
like standards already set on that, that even if people aren’t familiar
with it, it’s not like they’re learning just web flows mental model,
right? They’re learning the mental models of like building a website
and links, buttons, and even in layout, you know, thinking about
sections and Some other elements that are offered to people. So I think
that’s the thing that’s been helpful for us is that it’s like, as
you’re learning web flow, you’re learning the web mental model as
well.
00:30:01 - Speaker 2: Can you give us an example of something, you know,
we’ve talked about this kind of visualization element, which in many
cases I think a visualization tool is something that doesn’t really add
a new mental model, it just helps you better, well, literally see what
it is that, yeah, understand, for example, margins and padding. It sort
of shows you how those layout. Is there some major new abstraction that
web flow gives you that’s sort of a new capability that’s added to
your user’s tool kit, but it is not something that comes from the web,
but is something you created as part of your universe of mental models.
00:30:36 - Speaker 1: Yeah, it’s not something we originally created,
but maybe I’ll throw this example out here because we just had our no
code conference. We announced a capability that we call logic.
And now when you have the UI side of things, and you have logic, and you
have data with our CMS offering, it’s essentially a 1 to 1 connection
to model view controller, right? And I think as we start exploring this
is like, The question I’m asking is, do we teach everyone the
fundamentals of model view controller and ask them to build it the exact
same way? Are there ways to leverage those ways of doing things in new
ways? And I think for us, there’s a lot to be able to explore there,
even with our CMS, right? It’s like we’re letting people buying data
to layout and building collections with them not necessarily knowing.
What a collection is and how you would build that in code, right? So I
think it’s not necessarily like inventing new definitions of things,
but maybe new ways of manipulating and using it. And I think for us now
that we have data, UI and logic, being able to manipulate, layout or
data based on events, there’s a lot for us to really explore on how end
users interact with that.
00:32:00 - Speaker 3: This brings us to another interesting aspect of
designing for creative tools, which is the social aspect.
So increasingly designing tools and then using the design tools takes
place across many people, and there’s interesting social dynamics
there.
So especially if you look at a domain like the web, which is very
multidimensional, like you can use absolute positioning or box model or
grid or whatever, you have to come to some common language and
understanding as a team, and sometimes you just gotta kind of pick one
or be on the same page or at least call things the same thing. So an
important job of design tools I think is helping teams reach that
agreement. I can give you two examples. One is Hiroku, where there’s
basically a lot of ways you can design and deploy an app, and Hirokoku
picked one, and there were good reasons why Hiokku picked that way, and
we said basically you should do this, like you should use Git and you
should not write to the local file system and so on and so forth, you
should use environment variables and Yes, those were good choices to
make in of themselves, but they also basically forced everyone onto the
same path, which was itself another example that’s maybe more analogous
to web flow is Ruby on Rails, where basically it need people to pick a
way to do NBC like, put this here, put this here, call this that, use
this convention for converting between lower case and uppercase, and
just do it, it’ll be fine. And there’s actually a huge service and
just picking these defaults and having these guard rails in place.
00:33:21 - Speaker 1: Yeah, it’s really interesting you bring that up,
Mark, because I think one of the things we’re really thinking about and
that’s really top of my mind is how does collaboration work in web
design and in a tool like web flow, and I can give some examples of that
is one, let’s say you have an end user creating their site, but perhaps
they find inspiration from our showcase and they pick a template to use,
right? But that template is built Flexbox only. And let’s say they use
CSS grid or something else for their site, they drop it in and just
boom, the whole layout just collapses, right? So I think for us, that’s
something to really think about.
It’s just like, again, just how do users understand like how the
material’s created, right? And I don’t know if it’s something where
we’re like, want everyone to use flash. Xbox only and get rid of the
other stuff because there’s implications with that.
But how do we kind of nullify and make sure that when people are using
other resources that people build, like in a community aspect, that
there’s clarity, there’s good documentation, and there’s some good
best practices around that.
And I think the other thing.
That you touched on, Mark, that I think is really interesting is, how do
you think about like design architecture as a team, right? And if you
have multiple designers working in web flow on a larger team, it’s
like, how do you make these agreements and how do you declare these
things that’s like, hey, as we’re working, this is our approach to
Naming our CSS architecture or this is kind of how we want to approach
building pages and having that.
I think a lot of that lives off platform right now today. Some of the
things that we’re thinking about is just like how do we enable teams to
work better in web flow, and I think we’re still doing a lot of
research on it and trying to figure out like what that best case is.
00:35:13 - Speaker 3: Yeah, it seems inevitable that all design tools
are going to become collaborative and social, at least have the
capability to do things as a group, and it’s interesting that we’re
sort of working our way up. So the first thing was like Google Docs,
which is text, and then you add the whole office suite, and now we’re
working on complex tools like Figma and web flow, and I think eventually
we’ll get to video that’s probably the hardest one to do
collaboratively because of bandwidth, but we’re gonna get there. It’ll
be interesting to see how that all plays out.
00:35:40 - Speaker 1: Yeah, I’m starting to see a lot of startups
working on collaborative video too, so I think definitely a really
gnarly problem, but I think it’s a sign, like you said, it’s
inevitable that everyone’s shifting to collaboration in as real time as
possible too.
00:35:55 - Speaker 2: A bit of a tangent, but it’s certainly a reminder
of something I feel like comes up on Twitter from time to time, which
is, it does seem odd that you basically have all of these startups that
are reimplementing collaboration, typically inspired by Google Docs or
some combination of Google Docs and GitHub. And in fact, given that we
want every single tool to be collaborative, couldn’t you imagine that
as an element of the operating system or the file system? And instead,
every single startup that does this has their own big engineering team
and like needs to build it all, but one can’t help but to envision that
future operating system where by default that is part of anything you
build.
00:36:36 - Speaker 1: I think about that a lot about annotations too.
Couldn’t annotations and commenting be more native across the operating
system based on the objects that you’re working with, but like you
said, a lot of these tools, it’s part of this walled garden, right? And
everyone’s building their own version of it and there’s got to be a
way where How do you take that a layer deeper, like either in the
operating system or being more open source about it, but it is
interesting, like everyone’s kind of building these same like set of
features, and I always think about annotations and commenting as ones
that I would love something like that on the OS level.
00:37:15 - Speaker 3: Yeah, I actually had the aspiration for such a
thing existing.
I think it could be an OS service or a web service sort of like S3, and
I repeatedly hear people ask for this, and I think there are two big
hurdles.
One is there’s an expertise hurdle, which I think is not obvious until
you try to do it, but it’s very, very hard to build such a system, and
I think it’s basically impossible to do without having a motivating
example product.
So I think it’s most likely this gets extracted out from either a
company or someone who has experience with the domain of trying to build
such a system.
And I think there’s an important path dependence thing where yes,
everyone wants the operating system to support this, but, you know,
it’d be very convenient if the operating system was the one that
already ran, you know, my program, right? I don’t want to have to
rewrite all my stuff or change my business or lose my business for such
an operating system. So there’s a first mover problem. So, basically,
I’m looking for the bookstore that wants to get into the business of
web services in this space, and I think they’re out there somewhere. If
you are, remember, we’re looking for such people, so contact us please.
00:38:16 - Speaker 2: David, what you mentioned earlier about the
dropping a Flexbox component into a grid layout also makes me think of
another thread here, which is the kind of componentization elements of
things.
Yeah, I think a product with a good mental model, a good set of
abstractions, the elements of it can be combined together in a lot of
different ways, again, ways the creator didn’t originally expect, but
you take that even a step further, which is not just that I, the person
using the tool within my document, can Do interesting and different
things, but then you can go from there to, as you said, the
collaboration, we’re on a team and we’re working together on something
like a website or a document, but then the furthest step is to go from
there to, you have these components that you can plug together where
maybe the I don’t even know the person that made this calendar widget
that I’m plugging in.
But I feel like this has been a dream for a long time, and maybe one
that there’s been many attempts, I think OpenDoc is kind of a famous
one there, maybe ActiveX kind of Microsoft had a couple of different
iterations of object embedding and yeah, I’m curious if you have a take
on that path of computing history attempts.
00:39:28 - Speaker 1: Yeah, I can speak about the promise of OpenDoc
cause candidly speaking, I never really had a chance to play around with
it and. Implemented, but I think this idea of component software that is
reusable and adds value for people immediately, I think it’s still a
lot of ways the dream, right? And when we think about community plug in
the ecosystems, it’s an aspiration I want to continue to pushing now,
there’s a lot of trade-offs in practice because I think for me. Someone
who used like cocoa pods a lot, right? There was something around like
how open are these plug-in ecosystems, and I think that’s a tough
tradeoff for any platform that’s being built, but I think for me with
OpenDoc, I kind of felt like web objects was a lot of this too, in this
world where you now have people who can build components. That serve
other people and really being able to open up like how work is done,
right, whether within your company or externally, but I think OpenDoc is
just one of those still kind of waiting for that promise to be fulfilled
and then I think that vision is so inspiring.
00:40:40 - Speaker 3: I think this is a super interesting frontier as
well, and I think it’s like understudied and under theorized. I think
people don’t appreciate how complex it is, especially when these
plug-ins are turned complete and they have access to compute and data,
you know, that is your compute and your data, they can do wild stuff and
there’s sort of a this problem in the engineering world of libraries.
And I think we’re still in the very early days of how we think about
libraries, which is basically we download a bunch of random code from
the internet and run at our computers and who knows, you know, a lot of
it’s probably like mining Bitcoin or, you know, stealing my keys.
It’s a complete mess. And I think it requires a very serious design and
engineering effort. As well as again this respect of the path dependence
problem where you need a way to bootstrap the ecosystem and to
incentivize the ecosystem. So I’m so optimistic. I just think it’s a
very hard problem.
00:41:27 - Speaker 1: Yeah, I think in a lot of ways, you’re right,
it’s still so early in the way that we’re doing it.
And I think one of the things, like let’s take no code, for example,
and use this open doc analogies. I’ve always described as no code being
like the 3D printer for building on the web. So what it does is really
creates repetition and reusability in a great way, right? Now, no code
tools, there’s always going to be this threshold where if you’re doing
something sophisticated, you might need to code it, right? So it’s
never this like one or the other, but I think it kind of evolves into
that and I see that with component software too, in the sense that it’s
like, I think about this all the time. If I’m building an app, I’m
like, why do I always have to build the same authentication flows,
right? Or kind of build these things that people predict. It’s a very
rigid solution intentionally, like, you know, e-commerce and check out
some of these things like why do these things have to be constantly
unique, right? There’s clear interactions of what people expect in
those. And how do you do those things at scale. So then the things that
need to be unique for your business or your product, you can really
focus on that. And I think that’s where, again, I think this whole
concept of like component software, I still very much believe in it.
It’s a very ambitious vision and I think in a lot of ways still pretty
early.
00:42:54 - Speaker 2: By the way, it probably is worth defining no code
briefly for the audience. Again, we suspect a lot of folks may have at a
minimum part of it, but given that you put on a conference with that
name, it seems like you might be an authority to speak to what you think
that word means, you know, what the category is, what the movement is,
etc.
00:43:10 - Speaker 1: Yeah, absolutely. With like what it’s not, right,
which is not the absence of code or any existence of that. And it’s
really more of like the primitive that you build with.
So instead of building, using code in a command line interface or a text
editor, it’s through like visual abstractions.
So there’s no code and low code.
But yeah, it is something funny where It’s not even in my opinion,
combating with code, right? It’s just kind of the existence of these
two approaches in a lot of ways. And I think the companies that are
going to excel at this is they’re probably going to use a combination
of both, right, depending on some of the different use cases, but yeah,
no code is kind of starting with not needing to learn how to code and
you’re kind of focused on like the visual abstractions of creating with
code.
00:44:05 - Speaker 2: My sense is that it’s often non-programmers doing
automation and particularly connecting services together, so I think of
the if this, then that and Zapier as being kind of a starting place,
very simple, just, I don’t know, we use a Zapier integration for
someone tweets about X, then put it in the Slack channel, for example,
or you get an email with a PDF, stick it in this Dropbox. Those kinds of
basic automations and that certainly I’m sure professional software
engineers sometimes use such service just because it’s easier, less
work to maintain or whatever than using their full on development stack,
but I think very often it’s a business person or a designer or some
other person that the writing a, I don’t know what a shell script to do
the same thing would probably be out of reach for them.
00:44:53 - Speaker 1: Yeah, it makes me think about and name any use
case, right, where before you’d have to like ask an engineer to run a
rake task to be able to get all these things done.
Now you’re empowering people, like you said, maybe they’re on the
business side of things or not on the engineering and product side to be
able to create their own automations in that way. And the question I
always ask myself is like, this is the stuff you want to democratize
even within your own company, right? It may not be the stuff like an
engineer even wants to work on. So it’s like, again, it’s not contrary
to how you do it, it’s just kind of really thinking about some of these
use cases. I don’t know, do you all remember Yahoo pipes? That was
another one that I think about with the automations too.
00:45:41 - Speaker 2: Yeah, I had to do some serious digging around in
the web archives to find a screenshot of that because I wanted to
reference it for the inco switch end user programming article that we
did.
But yeah, I think of that as one of the original put together flow-based
programming with, I guess the emerging idea of web services or the fact
that URL over here as a web report and another API over here is where I
can feed in my travel plans and maybe I can connect all those together
with well pipes. And maybe it was before its time, I’m not sure, but
the concept there was so simple and maybe coming back to our mental
models point, you know, you even look at a screenshot, you instantly
understand what this is doing and what it might be capable of.
Now another thing that I think about when thinking of a tool like what
you’re making with web flow, I think Kokku had some of this as well,
and I think any kind of creative tool always has this, you know, you
talk about your ideal is the low floor, high ceiling, that’s the idea,
it’s relatively easy to get started with, but you don’t get
constrained later on.
There’s also these powerful cases, but I do think there are cases where
you do want to say, OK, you’re asking for something that actually is
more kind of off the edge of what we actually want to offer with the
tool.
Certainly when we ran this Hiroku, someone would come in. I want to tune
all these kernel parameters, whatever, we’d say, well, look, this
actually isn’t the right platform for you because that level of control
and customization is exactly what we’re trying to save you from. We’ve
just made good choices there that will work pretty well for most people,
and you can just remove thinking about all that kind of stuff from your
head.
And an example, you know, that I like to cite a lot for end user
programming is Flash, which I think did a really great job of bringing
animators and maybe what we would now call motion designers into
something that was essentially kind of a programming environment, but
it’s been speculated on some of these uh flash dyed postmortems that
came along a couple of years ago that one of the Issues that it faced
was in those early days, it was so accessible to animators, then people
started making games, those games would get pretty complicated, they
would need all these things that just professional software engineers
need, want, expect in terms of data layer, caching. Complexity of the
language, all that kind of stuff, ability to add libraries and
dependencies, and eventually it became such a powerful programming tool
that it actually lost that ease and that accessibility. Essentially the
floor kind of crept up as they pushed up the ceiling. So I also think in
designing a particular tool, it’s very reasonable to decide our
spectrum of use. cases, you know, there’s some that’s going to be too
trivial or too, you know, we don’t want to make things so easy, you
know, we push you out to some more beginner tool, but there’s also a
ceiling somewhere where we say, look, you actually reached the limit of
what this tool is for. We’re not designing it for you. You should go
use this over here that’s more powerful but also has, you know, other
trade-offs.
00:48:38 - Speaker 3: Furthermore, I think there are different ways to
do this. So I think the ideal way, again, if you have the right mental
model and product architecture is to have basically a nested mental
model, a nested architecture where you can peel back layers and get at
the granular abstractions within.
There’s all kinds of examples on Hooku. I think we did do a pretty good
job with this. If you get push an app to compile and deploy it, it just
basically picks how I think it should compile based on what the app
looks like.
But if you want, you can swap in your own compilation step and say,
here’s the script that I want to compile this app, but critically, both
the Hiokku default and that. use the same interface. They’re totally
interchangeable.
It’s like basically peeling off that one layer and saying I want to
insert something different into this interface. It’s not saying, oh
well, you know, Her only deploys Ruby. I gotta go do my whole own thing
on AWS from scratch, right? You get to granually pick apart pieces and
there are all kinds of examples of that.
In contrast, sometimes I see these programming tools that are like code
generators where there’s a super complicated problem and you invoke the
code generator and it spits out 100 files. And as long as you don’t
need to do anything different, you’re fine, but as soon as you need to
do something different, you’re completely out of luck. It’s like
you’re often hand editing these 100 different files. So I think the
extent that you can create a system where you can peel back these
individual abstractions while still enjoying the stack overall, that’s
great.
00:49:54 - Speaker 1: Yeah, and it makes me think about, I’ll give a
small example.
So there’s this note taking tool I love called Obsidian, and the thing
I love about Obsidian is you use your local markdown files, right? So.
If Obsidian ever gets to a point where it’s not scaling for me, which I
think it serves my use case, well, you still kind of have the native
markdown files and you’re not kind of stuck in that application layer,
right? And I think great applications will figure out ways to be more of
a facilitator than controller on that, you know, and I think for some
like web flow, we think about, OK, we no longer are meeting the
threshold of what like a certain customer wants, they can still export
their code. But are there other things we can kind of build to make that
interoperability a little bit easier too. So I think that’s the trick
is like being in an application that can be great at facilitating some
of these things. So if such things do evolve too, that you’re not kind
of locked into that, but I think what you said, Mark is spot on.
00:50:57 - Speaker 2: Yes, I guess in the ideal world you design your
tools so that.
You start with a basic set of primitives, abstractions, mental model
glossary that hopefully someone can understand and do something useful
with when they need a little more power in some particular areas,
that’s where they, as you said, mark, peel it back or I think David you
put it as kind of popping the hood, and you can go down one layer at
least for that spot, but you’re not completely off in some new world,
you’re still within the kind of universe of abstractions that all fits
together.
And then there’s a final step, which might be what you referenced there
David, which is where you actually do get to the end of what the tool
can do for you, but hopefully now it’s not, now I’m really screwed and
I have to just kind of recreate everything from scratch in some new
environment, but rather you can, I think it’s React Native uses this
term. Eject, where you essentially can say I want to take my project out
of the React Native world to just make it a standard X code or Android
Studio project, and there’s no going back once you eject or no easy
going back, but that’s your out, right?
00:52:05 - Speaker 1: Interesting choice of words for React Native.
00:52:10 - Speaker 3: Yeah, that’s actually the kind of project that I
was thinking of in my previous example where if you have to eject in
that case, I think it’s pretty bad. I mean, you can still run.
Another example of ejection would actually be with deploying apps with
Hiokku. If you have a standard app, you can deploy to Hiroku, but you
can also take that standard, like Ruby on Rails app, for example, and
deploy it somewhere else, sort of an injection in a sense.
Hm. This is a very important concept, by the way. Another way I think
about this would be as an efficient frontier where the axes are
difficulty slash complexity and the other axis is power, and what you
want is you want a smooth trade off on those where you can always add a
little bit more complexity to get a little bit more power. If you need
it. And so if you need a little bit more power, you never have to
undergo a huge complexity jump, like migrating your app to a whole
different platform. For example, there’s little changes you can make
along the way. And furthermore, you want that frontier pushed out as far
as possible, so that the minimal amount of complexity is needed for the
given amount of power.
00:53:01 - Speaker 1: I think complexity gets a bad rap too, because I
think a lot of times people think complexity is the opposite of simple
and everyone loves simple because simple is elegant, so then complexity
becomes a sort of like villainous thing, right? And I think there are
times where we do need to embrace complexity, but how do you make it
approachable, right? And I think that is the thing to solve, right, is
to figure out like when there is a time where complexity is called for,
how do you have your creative tools give people the knowledge of how,
like again, to peel that layer back or pop the hood open to be able to
address such complexity as opposed to avoiding it entirely.
00:53:45 - Speaker 3: And again, I keep coming back to this idea of
mental models, often with complexity, you’re dealing with a fundamental
reality of the underlying world, and if you ignore it or try to cover it
up for long enough, you just make it worse, you have to address it. But
on the other hand, you don’t want to make that problem any worse than
it is by, for example, combining two problems and giving yourself three
problems.
00:54:06 - Speaker 2: I’m reminded of the Einstein quote, Everything
should be made as simple as possible but no simpler, which is, yeah, the
world is complex, it can be messy.
You’re creating a tool for someone to model something about the world
or create their own little mini made up world, and they are just going
to need to deal with that complexity.
In the web world, that’s something like all the different browsers and
all the different devices that someone might browse from and different
screen sizes and the difference between interaction on touch versus
mouse versus trackpad versus stylus.
Those things all exist and you need to deal with them when you’re
creating something and attempt to totally abstract all that away because
it sounds too complicated. It may impair the ability of the creator to
make something that’s really good.
00:54:52 - Speaker 1: Yeah, because abstractions still derived from the
original thing, right? And I love the idea of really focusing on where
you address complexity as opposed to neglecting it or putting it
everywhere, right? So when you have these complex things to solve,
what’s the optimal place to solve it?
00:55:10 - Speaker 2: Yeah, absolutely. Well, I do think we’re in kind
of a golden age or the beginning of a golden age for creative tools that
includes being more interesting, maybe place for designers to go work on
tools for thought and things like that, that the the stodgy old kind of
vanilla styles of the office suites of the past and so forth are giving
way to more stylish and interesting and opinionated tools for thought
and developer tools and designer tools. I’d be curious to hear from
both of you looking forward to kind of the future, you know, if we could
fast forward that trend 3 or 5 years, how does creative tools look
different in the near future?
00:55:50 - Speaker 1: I think you’re gonna see a lot more participation
in it, and it’s almost like.
The consumerization of creator tools, which I think is exciting.
And the reason I’m excited about it is I believe some of the people
with the best ideas and things that can be life changing and can really
change the world, probably don’t know how to code. They might not know
how to design. So being able to give a platform for people to explore
and express, kind of gives the continuation of such idea to manifest in
other ways. Now, it may not be that person who ends up creating it, but
maybe it sparks an idea somewhere else. So I’m always like a big fan of
participation in anything because I think for me, honestly, if it
wasn’t for visual programming tools like Hypercard and Quartz Composer,
I may not have gotten into an interest in Building software and if I
went the conventional route, I probably would have failed. So I think
for me, that’s what I’m excited about is that like, this whole notion
of like end user programming and it being more accessible, just for
people to play and explore is pretty exciting for me.
00:57:03 - Speaker 2: It’s funny, I’m obviously a huge proponent of
end user programming and more people learning how to grasp the power of
the dynamic medium that is computers, not just as users, but as creators
of software.
But when you use the word consumerization, Then that actually almost
gives me a little bit of an opposite reaction and intellectually, I
think I agree with you that more participation, more accessibility is
better, but I guess as a crafts person and I love my niche and sometimes
kind of complicated powerful tools, then what consumerization brings to
mind for me, I don’t know, Instagram stories, or for example, you’ve
seen this in some of Apple’s creator products like they have for audio
editing, you’ve got. Logic Audio, but then you’ve also got GarageBand,
which is installed in a reac. It’s pretty simple and easy to use, which
is nice, but then in some ways they brought some of that design
aesthetic to logic, maybe taken away some of the things that the
longtime pro users of that could be described as like a dumbing down. So
it’s interesting to reflect on that reaction of myself. I don’t think
that’s a good thing. I don’t think I’m proud of it, but I just had
that twinge when you said that word.
00:58:12 - Speaker 3: Oh Adam, I got a different phrase for you. What if
we called it end user creating as a sort of generalization of end user
programming, and this is a road we’re already part of the way down.
So it used to be that even end users couldn’t do something like word
processing that was kind of a professional activity you had a typist or
whatever. And we’ve since brought the Office suite to end users, and
now I think we’re in the process of doing that for richer media, so
audio, video, web pages.
Of course, those are things that are kind of on the cusp right now of
even a few years ago, it was quite hard for someone to casually do audio
editing or video editing, but now you go look on YouTube and there’s
these like super, super niche, random people doing super random stuff,
but the video quality is like insane because everyone can do video
editing now. And I think that kind of progress is going to continue.
00:58:56 - Speaker 1: Yeah, it’s interesting.
I think Adam, even when I said that word, I had a similar reaction too
and it just makes me wonder, like, has the term consumer transformed in
a way that, you know, needs to evolve a little bit, but I’ll give you
an example.
There’s an awesome. iOS app called Universe, which lets you build
websites like on your phone. And I think for that, that to me is like
the consumerization of a creator tool, right? You’re kind of taking the
mental models of what people are used to on their. Smartphone dragging
and dropping these swipe gestures, but instead of consuming content,
maybe it’s more the consumers are becoming creators, right? So it’s
kind of normalizing creators in that way and I think the universe is a
great example of that. But just wanted to say when I said that word too,
I had a certain mental model that came to mind and I think it’s, yeah,
kind of like, maybe it’s more turning consumers and the creators rather
with the mental models that they know.
00:59:56 - Speaker 2: Yeah, I love that, and certainly I have my own
career to thank for that in a way.
As a kid, I loved video games, I was a consumer of video games, and that
led me to think I want to be able to create these for myself, how can I
do that? Back in those days that was breaking out your basic prompt and
you know, doing some turtle graphics and that sort of thing.
Nowadays, we have quite different tools at our disposal, but having that
smooth on ramp and folks have talked about how we in some ways have lost
that as computing has gotten more sophisticated, it means, yeah, that
same eight year old with an iPad, they’re playing the games and
they’re thinking, how can I create these games and they kind of can’t
because, you know, basically the whole stack of software creation and
design.
Tools lives on a totally different platform and you know, requires
professional buy in and is incredibly complicated, but anything that
brings us back the other way and puts that creator power into the hands
of interested people who, you know, they may just dabble in it and
that’s fun and satisfying and they never go further and others may
actually find their spark there and their inspiration and they go from
there to something more sophisticated.
And both are great. Having that smooth ramp rather than gaps or a wall
or a gap, whatever metaphor you want to use on the other side are the
quote unquote serious professionals, and you have to do some kind of
ritual to prove your worth to be part of them, but in fact, that if you
have that spark, that bug to create and you pursue it, the opportunities
are in front of you to take it as far as you wish to take it.
01:01:35 - Speaker 1: It’s interesting you mention that, Adam, because
I think what it dawned on me is the same way I got into computers from
playing video games and understanding how sprites are created that kind
of sparked this curiosity for me to create.
I don’t know if that’s happened for mobile and tablets yet, right,
because even though the inspiration is on device to be able to create,
it’s off device and maybe this is where Xcode is going to bring a lot
more things to.
The iPad and be more mobile centric, but maybe perhaps that’s the
reason we’ve seen so much like hyper consumerism on these smartphones
is that the tools on device, we may not have had that evolution yet,
right, the same way as on my Apple II or name any old computer, it was
like on device and you’re creating on the same platform. I don’t know
if that’s really happened with mobile, a lot of that still kind of
locked in, so it’d be interesting to see how that evolves over the
years.
01:02:36 - Speaker 2: Yeah, I think the web has its own version of that.
I think in many ways the web is better in the sense that maybe it’s a
little more hidden in the menus now, but you can still view source on
any web page. You’ve got to have tools inspector and certainly anyone
that wants to grab a glitch account or a web flow account can start
making simple web apps without a huge amount of ceremony.
Nevertheless, there is still a bit of a gap you jump over and certainly
in compared to the original vision for the web, which was something much
more read-write, something much more where you kind of right click a
page and say edit, and it takes you in, or maybe something like Beaker
browser has an interesting vision there or essentially any web page
you’re on, you can click a fork button, you get a local copy and you
can start editing it.
I like to see things like that because I feel like it helps. Reverse or
provides a counterbalance to the tendency that as systems get more
complicated, of course they get less accessible, and the tools for
creation get further and further away from the regular tools for using.
So hopefully we can say web flow is part of that story as well. Well,
let’s wrap it there. Thanks everyone for listening. If you have
feedback, write us on Twitter at MuseAppHQ or via email, hello at
museApp.com. You can help us out by leaving a review on Apple Podcasts.
David, thanks so much for help making creation on the web, something
that’s more accessible.
01:03:59 - Speaker 1: Oh, it’s such a joy. I feel like it’s a life
purpose in many ways and yeah, thank you so much for having me on the
podcast.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: And I don’t hold this against Apple or anybody
else. There are billions of people on Earth who need great computers,
and most of them are not scientists or authors or policymakers, but we
believe that this has left a gap where there just simply isn’t a major
computing group that’s actually focused on how to use computers in this
intelligence amplifying way.
00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad and Mac. This podcast isn’t about Muse the product,
it’s about Muse the company and the small team behind it. I’m Adam
Wiggins here today with my colleague Mark McCrannigan. Hey, Adam, and my
frequent collaborator, Peter Van Hardenberg from I and Switch. Hi, it’s
good to be here. And Peter, one of the things that I find fascinating to
talk to you about is your varied hobbies outside of the world of
computing. What’s your latest interest?
00:00:56 - Speaker 1: Oh yeah, I mean, when I’m not, you know, brewing
beer or getting into some strange creative hobby of one form or another,
well, I guess I’m always picking up another one.
So lately I’ve been doing a lot of hydroponic gardening, and I’m not
growing anything of legal dubiousness, but with the pandemic, first I
was focused on trying to basically have some green space in my home,
because I was living in San Francisco and we didn’t have a yard.
And then more recently, I have moved back to my ancestral homeland of
Canada, and it gets real dark and cold here in the winter, and I wanted
to make sure I could secure a steady supply of Mexican ingredients,
particularly herbs and chili peppers and things that you just can’t
find. Sort of north of the wall in the offseason.
So that’s been a lot of fun.
I’ve been learning a ton about electrical conductivity and how to take
pH measurements and having a lot of fun with automating all the
components of this system over time. So these are going to be the most
expensive cherry tomatoes in the world by the time I’m done, but it’s
just a blast learning about all this stuff and, you know, what kind of
absorption wavelengths are better for different kinds of plants and so
on and so forth.
00:02:09 - Speaker 2: And correct me if I’m wrong, but I think the term
hydroponics typically refers to growing plants without soil or with
minimal soil. That’s right, I assume here you also have the artificial
light element as well with the northernly climate.
00:02:22 - Speaker 1: Yeah, and basically what I have is sort of, if you
imagine like a 2 m by 2 m bed or maybe a 1.5 garden bed, that’s sort of
cut into 3 pieces and then stacked into a bookshelf. And then nutrient
and oxygen-rich water circulates sort of around these U-shaped trays and
then cascades back down to a reservoir in the bottom, where it gets
pumped back up to the top in a loop. And so I routinely come in and I
have to top up the water, there’s a lot of water loss due to
transpiration, which is where basically the water goes out to the leaves
and then evaporates, and then you have to sort of monitor how much water
there is, but also regularly top up the nutrients to make sure that all
of the vital macro and micro nutrients that the plants need to live are
present in the solution. It’s a fun little chemistry project.
00:03:10 - Speaker 2: And I would be disappointed if there wasn’t, I
don’t know, a raspberry pie or something connected in this mix
somewhere.
00:03:17 - Speaker 1: Oh yeah, there are 2 computers now involved.
There’s one that doses out the nutrients using peristaltic pumps.
And there’s a separate one that came with the unit, which handles
notifying me when the water levels are too low, there’s a little
ultrasonic sensor that can tell when the reservoir tank gets low on
water, and also handles scheduling the lights off and on during the
day.
I’m still hopeful about automating the nutrient sensors, but it turns
out that monitoring pH over time is actually a surprisingly difficult
problem, and that a good hardware solution actually involves a fair
amount of like upkeep and maintenance and expense just in sensor probes
alone. So so far I haven’t quite taken the plunge there, but I think
it’s just a matter of time. We’ll get there, don’t worry. The end
state, of course, is to build a robot arm that will like use computer
vision to spot when a cherry tomato is ripe, and then pluck it for me
and place it on a conveyor belt. But uh, you know, I think we’re still
a few years out from that, both in terms of like technological
feasibility, but also just in terms of like, I got a lot of other
projects on the go these days.
00:04:23 - Speaker 2: And surely plucking the ripe literal fruits of
your labor is the funnest part of the whole thing, so save that for last
to automate.
00:04:33 - Speaker 1: Yeah, my kids really enjoy going into the garden.
They get the little step ladders out and climb up and peer into the
different tiers and pluck leaves to sample. Honestly, this thing is the
only way I’ve ever convinced them to eat green leaves, because they’ve
learned now that there’s lots of interesting green leaves they’re
allowed to eat in the garden. But if you put a salad on their plate,
they won’t eat it, but they’ll go and like forage some mint leaves or
basil or things like that. They’re into that.
00:04:57 - Speaker 2: And I mentioned we’re frequent collaborators, so
the three of us worked together all the way back in the Hiroki days.
Nowadays you are leading, administrating, directing the I and Switch
Research Lab, which was a position I had previously held before entering
the new spin out, which we can talk about the relationship there, but
I’m sure the audience would love to hear about your background. How did
you end up connected to this unusual band of misfits and unusual space
in computing?
00:05:26 - Speaker 1: I always tell people that I like to move like a
knight across the chessboard of the industry. I don’t like to go in a
straight line and I don’t like to follow an obvious path, so I move a
little bit to one side and a little bit across.
So before Ink and Switch, I had been working at Hiroku with the two of
you. But my background is super varied. I have been an Arctic
oceanographer and spent time collecting data at sea.
I’ve had waves roll over the side of a flat bottomed research vessel
and swamp my boots while I was working on the aft deck. I’ve worked in
game development and written physics engines for the Game Boy DS.
You know, it’s really hard to ride a physics engine using only integer
math. You really sort of take the ability to like divide numbers for
granted in day to day computing, and so that was a really cool
challenge.
Yeah, I’ve done computational Shakespeare, which was cool. There’s the
Internet Shakespeare editions are like a scholarly Shakespeare, so if
you want to be able to ask questions about, like, can we tell who
typeset this page of an original edition by analyzing their use of
combined letter ligatures. You know, because they think they can tell
different typesetters had different habits for where they would draw
type out of the frames. But all those kinds of questions about
provenance and genuineness of Shakespeare, we were building technology
to enable that kind of computationally. So, yeah, I’ve done a lot of
weird and wonderful things before I wound up at I and Switch, and if
I’m lucky, I hope to do many more in my career, so, so far so good.
00:06:57 - Speaker 2: And then another important piece here is, what
actually is Ik and Switch? What does it do?
00:07:01 - Speaker 1: Right, yeah, I and Switch is an independent
industrial research group.
We’ll break that down a little bit more, but basically, the way I
describe what we do to people who are sort of outside the field is that
we think that computers have much more potential to Make us smarter and
more capable than we’re really seeing happen with the kind of
technology platforms we have today, and we know that that’s true, but
we don’t really know how best to pursue it, and we sort of feel like a
lot of the fundamental requirements to be able to do that work aren’t
in place yet.
And so, I can switch research. It is about trying to light the way to
make possible these kinds of breakthroughs in the way people build
software and the kinds of software people can build by unblocking and
discovering paths forward for people.
00:07:57 - Speaker 2: And if one were to flip through the publications
on the I can switch website, I’ll link in the show notes, you’d
quickly get a feel for, I think a lot of research areas that are things
that Mark and I mention and with our guests here all the time on this
podcast. So end user programming, for example.
Yeah, what a coincidence, increasing the accessibility of programming,
obviously kind of tablet touch interfaces or next generation interfaces
generally.
Local first software is a huge one. We had Mark Klepman on just.
Recently to talk about that, and there’s many kind of sub branches of
that sort of you think of it as like oh what comes after the cloud or
how do we give data agency back to creative people.
So those topics, many, many of the things that we talk about here really
do come from or have their roots in the research there, and the research
is ongoing, so those ideas are continuing to be developed and pushed
forward by you and your team.
00:08:48 - Speaker 1: Yeah, there’s an endless amount of work to do,
and I think the hard part is really just sort of continuing to find the
efficient frontier, right, which is where are the most important
unanswered questions, who are the people that can do that work, and how
can we convince them to come and spend a bit of time with our ragtag
band of adventurers?
00:09:09 - Speaker 2: Could you give us an example of something you’ve
published recently on, just to give a taste for the kind of research
work that’s undergoing there?
00:09:18 - Speaker 1: I’ll give a little preview of two unreleased
papers that are coming up. Maybe that’ll be even more exciting for folk
if anyone out there follows us. We have two pieces that are currently in
editing and sort of preparation for publication.
One of them is called Inkbase and the other one is Paratext.
Now, Ibase was led by James Lindenbaum with Shimon Kliski, and it was an
exploration of how you could program ink. Now, One way of looking at
this is to say, well, what should the programming language for Ik be?
But in fact, we sort of deliberately cut that out of scope. What we
wanted to know was what would an ink programming environment feel like?
What would it be capable of? You know, how could you use it if you had
it, even though we didn’t have it, right? As a research project, what
we wanted to know was kind of like, well, what would happen if you did?
This was also in partnership with Josh Horowitz, who came to us from
Dynamic land on his way to grad school.
00:10:22 - Speaker 2: So we built an environment that allowed you to
program ink drawings to make them interactive, and ink here you mean the
digital ink, the same exact kind that is in use, except there you
scribble on your board or whatever, and that ink can be moved, it can be
deleted, it can respond to To your interactions and create interactions
of its own.
00:10:31 - Speaker 1: And so we saw really cool ideas explored there
like Shimon built a music sequencer that produced MIDI out of the system
and let him drive sound synthesis engines using drawn lines.
James demonstrated how to build like a fitness tracker, you know, sort
of like the Seinfeld streak that people often use. What if you could
make that a programmable thing or like a to do list? You know, like a
Zettel casting or a personal GTD kind of system, but one that you could
mold and actually make smarter over time by adding interactions as you
develop them the same way that sort of like an Excel spreadsheet grows
out of a simple table of numbers into some fully featured and powerful
computational environment.
We want to know what happens if a drawing evolves over time to become a
computational environment that responds to your needs. And your
discovered requirements. So that’s the ink-based paper. It was
presented at live very briefly this year, but in classic Ink & Switch
style, we have a massive paper going into all kinds of detail and with
links to some code coming soon.
And that kind of represents one angle of our work.
Another piece that we’ve been working on, we’ve talked about local
first, you mentioned earlier, we’ve been exploring something called
CRDTs, that’s a conflict-free replicated data types. A really
gratuitously confusing name for what is basically maybe more usefully to
think about like Git for data structures, mergeable data maybe mergeable
data, yeah, if you have like a JSON file in Git and then you check in
changes and then somebody else checks in changes and then you go to
merge and you just have like some kind of nightmare of text editing and
comma placement and figuring out what really happened. The idea behind
automerge is like, well, what if the data structures were smart enough
to synchronize themselves and what kind of new capabilities would you
get that? And that’s really been sort of foundational research that’s
enabled a lot of local first work over the last few years and we’re by
no means the only game in town, but one of the problems we keep running
into with that is we write a lot of these big essays and we want to have
local first tools for it. But today the kind of state of the art is
like, OK, well, you can do plain text editing. Or you’ve got nothing,
and our essays are these like complex multimedia documents with videos
and asides, and we won’t be able to make suggestions and comments all
throughout them as we edit. And so, what we needed was a rich text CRDT
and that is to say a CRDT that was aware of formatting and spans. And we
talked a lot in the Paraex paper, which is coming out soon, I hope, is
in concert with Jeffrey Litt, who led that project with Slim.
00:13:12 - Speaker 2: Notion, former guest of the podcast, in fact.
Yeah.
00:13:15 - Speaker 1: So we’re looking forward to publishing that
because it turns out to be a surprisingly subtle problem. If you’ve
ever dealt with non-hierarchical data, like extent data overlapping
extents, it just leads to a lot of like really interesting and subtle,
quite literal edge cases. So, we’re eager to present that to everybody
as soon as we stop finding bugs in the implementation. I think we’re
close, we’re close.
00:13:43 - Speaker 2: I think we said before we talked with Lis Lee in a
previous podcast about whether software is ever done and certainly
research is never done. You have to just kind of draw a line in the sand
somewhere and say we’ve advanced the state of the art enough that we
think others can build on this. Let’s publish.
00:13:59 - Speaker 1: Oh, I have a great Dune quote for this, it’s
right in the zeitgeist now.
I’ve been using this line for years, but the way I think about this is
in the words of Frank Herbert, Araki teaches the way of the knife, it is
finished because we stopped here. Yeah.
So by that, I mean, you know, you kind of go into a space and you work
for a while, and you can spend your whole career bashing away at one
problem, but one of the things I think we do really well and actually
that we’ve inherited from your time as lab director is like this
ruthless discipline about sort of pencils down on a given date and
moving on. If you don’t do that, it’s really easy to get caught up in
what you’re doing and to continue to pull that thread, you could be at
it for the rest of your career. And maybe that’s good, but by stepping
back and sort of re-evaluating, it forces you to kind of Both take the
time to publish, but also to sort of take the time to think about
what’s next and what’s really important now.
00:14:49 - Speaker 2: I think that maybe this is different for other
researchers or labs, but Frankenswitch, I think we want to take kind of
a breath first search of the adjacent possible for how we can improve
creative computing rather than sort of the depth first, follow one fork
in the trail and go as deep as we can.
00:15:07 - Speaker 1: Yeah, the way I talk about this is I often
describe us as a lighthouse, you know, we can’t necessarily walk the
path for everybody, but we can light the way and hopefully show people
how to get to where they need to be and show them opportunities that may
not have existed before.
And related to that, one of our core values is to produce actual
demonstrations of our ideas, right? Real tangible objects, computational
objects that a human can use.
You know, one is this just kind of comes from our background as like
hackers and entrepreneurs, you know, you have to go and build it, but it
also kind of comes from a DARPA sort of motto. DARPA, of course, is the
American Department of Defense Research Group. And they talk about how
you really have to show somebody a robot climbing a wall before they’ll
believe you. It’s one thing to say, oh yes, robots can climb walls now,
and to write papers showing sort of thrust vectors and forces and
friction and so on. But if you walk into a room and a robot climbs a
wall, then you believe. So we like to show people the robot climbing the
wall, that’s what we do. That’s a long way from having robots in every
home, but, you know, once you’ve seen it happen once, then you believe.
00:16:18 - Speaker 2: Well, I think we sort of naturally slid into the
topic here, which is independent research and actually you previously
described I can switch as being an independent industrial research lab,
so it seems like it’d be worth breaking those down a little bit. I
guess I’d like to start actually really fundamentally what is research
and how does it differ from other kinds of work you could do in the
computing field, and then what do those modifiers mean for you?
00:16:43 - Speaker 1: Yeah, so, OK, what is research? In the words of
Richard Hamming, who I think is quite an influential figure in this
space, his art of doing science and engineering, essay, lectures and
book. There’s a really great book from Richard Hamming, published by
Stripe Press. If you haven’t got a copy of that, you should definitely
pick it up if this stuff interests you.
But he said, if you know what you’re doing, and it’s science, you
should not be doing it. And if it’s engineering and you don’t know
what you’re doing, you should not be doing it. So science is oriented
fundamentally towards the unknown. That’s what research is. If you know
how to do it, you shouldn’t be doing it. You should be oriented towards
the unknown.
So, as a research group, we are oriented towards how to solve questions,
how to answer questions that nobody knows the answer to, or at least
that we don’t know the answer to and can’t find, you know.
There’s an old joke that 2 years in the lab could save you 2 hours in
the library.
So we do try and find prior art and do some survey of the space before
we do research, but, you know, sometimes you miss things and then you
find out when you go to publish that somebody else had already written
about that.
But that’s OK. We’re learning as much for ourselves as for anything
else.
So that’s research, but of course, research comes in a lot of flavors,
right? There’s sort of pure research, you know, if you think about the
National Science Foundation will fund you. To do things potentially if
you have the right connections and proposals that may not bear fruit or
may not have any direct industrial application ever, or certainly not
for hundreds of years.
And a great example of this would be prime number theory. Prime number
theory is at the very heart, the very heart of cryptography.
Now it is extremely important mathematical research.
But most of the core of that research happened like 100 years before
anybody found any use for it. So it’s undeniably good for society that
this research was done. I mean, depends how you feel about cryptography,
but let’s say that it’s good for society that this research was done,
but the people who actually did the research, they were dead for
centuries or decades at least before any real fruit of this sort of
transformational work was known. And that’s not to say that there
isn’t value in it, it’s just industrial research. What we’re trying
to do is be much closer to what’s happening in the world today, and to
sort of connect problems that we see in the real world of humans and
software authors and businesses back through this sort of lens of what
we care about to doing research. So we want to identify problems or we
don’t see solutions. And then we want to develop candidate solutions
that could be applied in at least the span of our lives or hopefully
over the next few years.
00:19:27 - Speaker 3: Yeah, and I think importantly, it’s a two-way
relationship with the industrial ecosystem. You’re solving problems
that have some potential industrial application, but you’re also
drawing from the experience of industry, you’re talking to the
customers, you’re understanding the current technology and what’s
possible, you’re aware of the trends and things that are happening and
it’s that sort of alchemy of not only solutions to problems, but
potential that you’re identifying from the industry.
00:19:51 - Speaker 1: That’s right. And so I think you often find
industrial research groups inside big companies like Microsoft Research
or Xerox PARC, or Bell Labs.
So there have been a number of these very impactful industrial research
groups in recent decades, but of course, all of those examples I just
listed. are anything but independent.
And this brings us to sort of what is perhaps most strange and most
unique about ink and Switch, which is that we are not part of an
academic body and we are not part of another corporation.
We are autocephalus, we are our own head, there’s nothing above us,
much like the strange Greek monasteries of the Orthodox church that date
back their independence thousands of years.
Well, OK, we don’t have thousands of years, but, you know, the
independence is a blessing, right? We’re not sort of tied to the
Quarterly returns cycle of some business, but it also creates all of
these kinds of pressure and constraints. We don’t have this like cozy
relationship with the money fountain that will keep trickling us budget
year to year. We have to kind of find ways to carve out our existence as
we go.
00:21:03 - Speaker 2: And if you’re interested in kind of all the ways
that research and labs work in the world, I point the audience to Ben
Reinhardt’s work. He’s got a pretty Extensive set of writings on this.
He writes quite a bit about DARPA, which you previously mentioned there,
Peter, just because they’re one of the more interesting long running
government sort of research funding institutions. And he speaks about
ink and which specifically as sort of inverting this normal relationship
between an innovation organization and it’s money machine, right, which
is that the corporate research labs, yeah, Bell Labs certainly is has
been a creator of so many incredible things from lasers to GPS. To the
transistor, for example, and Xerox PARC, of course, for its short run
was legendary. There’s many others like that, say the skunkworks, but
typically you have a corporate parent whose job is they’re an
industrial company, their job is to commercialize to sell things to make
money, and then the money they make from that, they want to put into
this research arm. But it does mean that always that that organization,
of course, is subservient to that.
So with it could switch the idea here a little bit is to kind of switch
that around a bit, or at a minimum, make it kind of standalone.
00:22:15 - Speaker 1: Right, and so for us, you know, there’s sort of
two puzzles, one which is, you know, how to get our work out there, how
to have an impact, because You know, as an industrial research group
doing work but not actually impacting the industry, you know, what was
the point, you know, you could have just stayed home and watched Netflix
all day, would have had the same end result. So it’s important to us to
actually sort of change how things happen, but we also need to find ways
to do that sustainably over time.
So we have a number of hypotheses, you know, as with all kinds of like,
long term projects, you tend to have long cycles before you see
results.
But we believe that there’ll be a combination of strategies that
ultimately make this thing self-sustaining, and one of those is to
commercialize our technology through producing spin-out companies and
then maintaining sort of a share in those companies.
And of course, the flagship example of this is Muse itself, right?
00:23:13 - Speaker 2: I mean, that’s kind of the videos.
00:23:14 - Speaker 1: Yeah, spoiler alert. Here’s the big reveal, you
know, Muse came out of work we were doing at I can Switch. And the
original version of Muse was a prototype built at the lab, and of
course, the 3 founding partners, 3 of the 4 founding partners, were
there 4 of you in the beginning?
00:23:32 - Speaker 2: We were 3 actually, so they were all 3 lab
participants.
00:23:35 - Speaker 1: Yeah, so, all 3 of the founding partners of Muse
were ink and Switch staff, and of course, that was the 2 of you, and
then Julia as well.
So the lab helped develop the concepts that led to Muse. It brought the
team together and it built the initial prototypes, and then as a spin
out from the lab, the lab retains some stake in the company.
So we’re not only delighted to see our ideas put into practice, we’re
incredibly excited to see the work that you’re doing and the testing of
our values in the world, but we’re also sort of directly incentivized
to see you succeed.
And so I really love this kind of like Symbiotic relationship where we
have both proof in the market of our ideas being feasible, but we also
have this incentive to follow closely and make sure that, you know,
we’re doing research that can help and that we’re communicating with
you and vice versa. So I think it’s a really great relationship and
I’m looking forward to many more of those as the years go on.
00:24:36 - Speaker 2: Yeah, I hope at least the flywheel that we’re
trying to go for here, but as you said, it’s a very long cycle to prove
that out is do research that is driven by real world problems. And of
course, basic science and just the pursuit of truth for its own sake is
absolutely incredibly valuable, the prime number theory you mentioned or
maybe Gregor Mendel sitting there breeding his pea plants just to learn
about how the world works or to learn about mathematics or computing’s
most basic principles is worthwhile, but in it which really goes after
things that are related to real world problems, all the ones that are
maybe too far out, for example. Startup or a commercial entity to
tackle.
00:25:16 - Speaker 1: What a great segue. Let’s talk about why Ink and
Switch exists a little more. What we’ve talked about is the notion of
like independent industrial research in the abstract. You could do this
kind of independent industrial research in any field, material science,
you could build spaceships if you had enough capital, which apparently
some people do, you know, you could study journalism, as long as you
have this sort of like connective loop.
But in the words of Thoreau, it’s not enough to be busy, so are the
ants. The question is, what are we busy about? And what we’re busy
about is sort of this despair that computers have increasingly become
mechanisms entirely for consumption, and that so many of the groups and
bodies that were building the bicycles for the mine that were pursuing
this sort of vision of computers as these intelligence amplifying
devices have kind of retreated from that vision towards a more Natural
consumer demand. And I don’t hold this against Apple or anybody else,
you know, there are billions of people on Earth who need great
computers, and most of them are not scientists or authors or
policymakers, and so it’s natural that they would sort of follow the
pull of their users and go to where the market is. But we believe that
this has left a gap where there just simply isn’t a major computing
group that’s actually focused on solving problems.
Around how to use computers in this sort of intelligence amplifying
way.
And specifically, the reason why a research group exists to solve this
problem is that people are, oh, well, startups are these great
innovators. That’s only true in a very narrow way.
All three of us on this call here have plenty of background in startups,
both working in them, and founding them, advising them, etc. And
startups can take certain kinds of risks, but they can’t take every
kind of risk, and it’s sort of like the old advice about only break one
law at a time, you know, it’s the same thing with startups, which is
you should only take one risk at a time, and generally for the startup,
there’s like a core hypothesis to the startup that they are trying to
test. It’s Some new kind of product or in some new kind of market.
And so the advice people give startups is, well, you should be
conservative in all your other choices because you’re already taking a
massive risk on this one axis. And so the way we see that play out is
lots of people are building startups that would be much more effective
from, we think a software and user perspective as local first software,
but they build them as cloud sass because that’s what the market
expects and that’s what’s easy, that’s what’s known how to do. It’s
also what venture capitalists expect.
Right, venture capitalism is, let’s be honest, mostly about pattern
matching and comparing with other past successes and trying to into it
based on this sort of both guiding and being guided by the structure of
what the market is doing right now. And that’s fine too. It’s just,
this doesn’t leave much space for the kinds of major transformative
direction. That a research group can pursue. We can think a decade out.
A startup can only think 2 or 3 years out at most. And so that means
that we have the opportunity to do work that simply isn’t possible in
the context of a startup. And in so doing, we can bring those time
horizons in closer and bring things into sort of striking range for a
startup, and then those startups can go and pursue these ideas. And in
fact, we’re seeing that all the time these days, not just with Muse,
but You know, we’re seeing lots of startups these days who reach out
and contact us and say, hey, thanks so much for your essays, they were
really inspiring, they’ve been really influential on how we’re
thinking about this, and we’re hearing from venture capitalists when
there are local first startups in some new domain, we’re seeing
tangible results of this work on the industry today.
00:29:10 - Speaker 2: Your point about markets and the fact that sort of
even startups or commercial ventures, I think just generally speaking,
need to follow market trends.
It would be dumb not to. In fact, that’s almost the definition of a
good opportunity is capitalizing on an immediate trend and In fact, what
we see that for example, ARPA slash DARPA, what they do is try to change
the whole industry. So one famous example of theirs is they decided in
the early 2000s, we think self-driving cars should be a thing, and they
put their money to work with prizes and other kinds of funding grants to
Get a bunch of both researchers but also companies and investors
interested in that, and they basically kicked off that whole revolution
that has yet to perhaps fully yield fruit, but at least you see they got
a bunch of people caring about it, they got a bunch of money into it,
they got a bunch of smart people who want to make that future come true.
00:30:05 - Speaker 1: Yeah, and DARPA refers to this as the
challenge-based model.
So they use this trick everywhere. DARPA doesn’t actually do any
research in-house. They are fundamentally a funding agency.
And so, with self-driving cars, they said, hey, we’re gonna give you
this challenge, which is you have to drive this car across the desert.
And the first year, I think none of the contestants made it to the
finish line at all, but each year it got closer and closer until they
were eventually, there were entrants that were able to traverse this
whole landscape and they won some prize money, but they talk about at
DARPA how The way they evaluate projects is that they want things that
are really ambitious in their outcome, but they also want things that
are tangible in their direction. And so they need to be both very hard,
they call it DARPA hard as sort of like a discriminator of ambition.
They don’t want something that’s just difficult, they want something
that’s really difficult, but they also want something that can be
articulated in like a real world results that can be measured or
evaluated.
00:31:06 - Speaker 2: Yeah, so obviously I can switch doesn’t have that
same structure. We do the research in-house. We don’t have government
money to spend, etc. but I think just broadly this idea of moving the
market rather than going with the trends that exist, we’re saying we
actually don’t like some of the trends where the massive
consumerization of computers, which has many nice benefits like most
people use the computers in their pockets as Messaging devices, right,
and stay in touch with friends and family. Great, that’s good, but then
who is working on the creative tools? Creative tools are just not sexy,
not interesting, not where it’s seen to be the place that smart people
or smart investors put their effort.
00:31:45 - Speaker 1: Well, the smart investors is, I think the secret
here. This is the core, right, which is that if you’re an investor, you
need a Big market and it turns out that a bunch of novelists and like
researchers, there aren’t a billion novelists and researchers to buy
your product and if there were, they probably don’t have the budget
themselves to go after it. So I think it’s perceived as a relatively
small market, though we think there’s a lot of opportunity there if you
build tools focused for them.
00:32:10 - Speaker 2: I don’t know, Microsoft Office did OK back in the
day. Adobe seems to be doing all right.
00:32:14 - Speaker 3: That’s true. Yeah, so here’s my variant on this.
I think there are actually 3 big markets that are already very well
funded and being effectively pursued.
One is what I would call consumer software, this is ad funded,
engagement based software, Facebook, and so forth.
There’s enterprise software, which is perhaps actually the most
profitable domain right now. This is now Microsoft. AWS stripe, things
like that.
A third one actually that we often don’t mention is like surveillance
and weapons related stuff, like kind of government stuff. That’s all
very well funded.
So this is an area with individuals that’s perceived to be less
economically lucrative. So the entirely predictable and predicted
outcome is that there’s just much less investment and therefore, much
less progress in it. And we’re trying to jumpstart that flywheel a
little bit and get some more progress in this area.
00:33:00 - Speaker 2: But I do think it’s not just on the investor
side, we talked to Jason Yuan about this, which is, for example, doing
design work for designers, do they want to go to work on the next Excel
or do they want to go to work on the next, I don’t know, Snapchat and.
At least in the recent past, I feel like these consumer facing companies
because they are so big because they have such big outsized brands, but
you’ve heard of them, but also they have so much money to put into it,
they can do a lot to build those brands and be perceived as a place that
the best talent comes to.
So I might think of one of the goals of use and I can switch and all the
other folks who are in our sphere of creative tools and tools for
thought and so forth is just making that a cool area that people are
drawn to work in.
00:33:47 - Speaker 1: Obviously you got to pay your rent and Nothing
says cool like 6000 word essays on esoteric technical subjects, and then
we all got our own definition of cool.
00:33:55 - Speaker 1: Oh yeah.
00:33:56 - Speaker 3: I think that’s true. I think that gets to this
idea of institutional alchemy, which is it’s not a matter of just going
to a space and working on it or even of just providing funding for it.
You gotta bring together all these different factors. There’s funding,
there’s vision, there’s people. There’s memes, you know, there’s
lines of research, you need it all to be there. Communities, yeah,
exactly. And one of the things I’m really proud of with ink and
Switches I think we’ve managed to do that somewhat for this space.
There’s this nexus, this scene that is formed around the work.
00:34:29 - Speaker 1: Yeah, I think that’s true. It’s very exciting to
see a growing space, and of course, we’re talking about Ink & Switch
and so I’m sort of focused on that, but I want to note that like we’re
by no means operating in a vacuum, and there are plenty of other people
like Gordon Brander out there who are writing about this, and there’s
lots of startups like Rome Research, who are out there building products
in addition to Muse, and I like to think that we are. Certainly a
significant player in that ecosystem, but I don’t mean to sort of imply
ownership over it or take credit for what is by every indication. A
rapidly growing and very dynamic space. I think that’s true.
One thing I would like to talk about is why this is important, and why
we’re doing this. Now, I think all of us, sort of longtime members of
the lab. Believe that the world is kind of in a rough spot right now,
like in a big picture sense, right, we have major climate change
problems ahead of us, we’ve got this sort of breakdown of the old
social order, which is largely driven by new dynamics and communication
tools through social media, without getting too much into that, there’s
these attentional economy problems, right? You know, you go to unlock
your phone and there’s 75 push notifications waiting for you from a
mixture of actually useful things and marketers that have somehow
managed to slide into your mentions. So you’ve got like all of these
kinds of, like, real major issues, and here we are monkeying around with
CRDTs and programmable ink. You know, I’ve had friends who are like, if
you think these problems that are facing the world are so important, why
are you playing with computers? Why aren’t you out there working on the
front lines of climate change? I think it’s a good critique and it’s a
fair question, but I think, specifically our work. And our motivation
behind our work is that we want to empower the people who have those
first order skills to be able to attack these problems. We want to
support physicists, we want to support journalists, we wanna support
writers and authors, and there’s this whole pipeline of knowledge.
Pipeline is Gordon Brander, if you’re listening. There’s a systems
theory explanation here. It’s not a pipeline, there’s lots of feedback
loops at every step along the way, but there’s this system of cultural
change that occurs where real knowledge about the universe produces
change in the way that we live. And at one end of the pipeline are
scientists and social theorists and other people, activists, and then,
you know, it goes through a long process that involves a lot of
different parties and systems like journalists and writers who bring
these ideas to the public and talk about them and communicate them and
eventually winding up with policymakers and entrepreneurs and government
officials who either change public policies, introduce new laws, or
start new businesses and pursue opportunities revealed by this. And so
all of that kind of structure. You know, we believe that there’s a lot
of unnecessary friction and loss of productivity caused by these bad
tools. Every time someone who could be working on climate change loses
their data because whatever, the computer reboots to run an update or,
you know, they have some great idea and they go to take a note, but they
get distracted before they take that note, because their phone is
telling them to play whatever Flappy Bird or something. Like anytime
those kinds of things happen. That is slowing down and taxing our
ability to respond to all of these problems. And so we as a group, the
people in the lab, don’t have physics degrees. We’re not social
theorists, but we hope that by working with journalists and talking to
them, and working with scientists and talking to them, and working with
writers and talking to them, that we can learn what the challenges these
people have are. And develop a set of values and theories and practices
that we can then build infrastructure around that will enable these
people to be more effective. But why that, right? The answer is just,
this is what we’re good at, this is what we know how to do, right?
We’re taking our skills, our unique advantage, and we’re trying to
apply them indirectly, perhaps, but sincerely and over a prolonged time
scale and intentionally towards enabling those kinds of changes.
00:38:58 - Speaker 2: 80,000 hours has a kind of whole set of essays and
theory about how to apply your career in the most effective way as
possible to do good in the world, and they reference exactly that point
you just mentioned, which is you have to find the overlap between a
meaningful problem in the world. What you specifically are great at,
drawn to or passionate about, or you have skills or knowledge or
experience that very few others have. And the third one actually is an
area that not a lot of people are working on. And so I think that’s
part of what drew us to this space for for and switch.
00:39:31 - Speaker 1: Not a lot of people were working on this when we
started here. Certainly there have been times when people have kind of
looked at me and been like, why aren’t you doing AI or ML or blockchain
or cloud software or like any of the things that anybody ever raises any
money to work on. It’s like, well, doing what everybody else does takes
you where everybody else is going. If you want to solve interesting
problems, you’ve got to work on things that other people aren’t
already doing. That’s part of it.
00:39:57 - Speaker 3: Yeah. Another angle on the why that I would give
in addition to this like kind of productivity and effectiveness
motivation is one of just aesthetics and beauty and sentiment.
I talk about how we are using these tools 468 hours a day, and it’s
incredible. demoralizing if they’re not beautiful, if they don’t feel
good.
And I think that is the state of a lot of our tools. And you would feel
terrible and in fact, refuse to go to work on a really creative project,
8 hours every day in like some terrible concrete block building, right?
It would be demoralizing.
That’s a situation that I feel like we are in with a lot of our tools.
And just making people feel better about what they’re working with well
I think also enable more good work.
00:40:37 - Speaker 1: Yes, we’re asking all of the artists and
scientists of the world to do their best work inside a Walmart full of
billboards, while the internet is screaming at them. Yeah. It’s not
ideal.
00:40:49 - Speaker 2: Yeah. Yeah, to sort of summarize what both of you
said or perhaps my take on it would be that computers and software and
the internet have become a really fundamental infrastructure in the
world. They’re like roads and bridges, they’re like our agricultural
systems and our economy, and those things need to work well and for us
to do anything else, solve any other worthwhile problems or do. Things
like make great art, create beauty in the world, and computers have gone
from being something that is maybe more of a toy or a novelty to being
something that is fundamental and everywhere. And so them supporting the
humanity’s best aims and noblest pursuits versus being swept up in that
Walmart of billboards demanding your attention is something we think
will produce returns for all of society.
00:41:41 - Speaker 1: Talking about all of society, I think one of the
really valid criticisms of both our work and a lot of the other work in
this space is that it is rooted in this kind of technocratic elitist
view that there are experts and brilliant people out there in the world,
and what we really need to do is enable them to do better work.
You know, I have young kids and I was at sort of some 3 year old’s
birthday party in a playground.
And I got to talking to a golf course equipment manager who lives here
in this town, super nice guy, sort of opened with, oh, I don’t know too
much about those computer things. But he’s interested in what we did,
so I was trying to sort of translate my work for him because, you know,
it’s nice to hear about what other people do and share what you do.
00:42:23 - Speaker 2: Just as a note, the cocktail party conversation,
which is exactly what I described this, trying to bridge, you know,
describe your nichey work to someone that’s completely outside the
field, was one of the biggest challenges for me working on Incode
switches very hard to summarize that. It’s gotten a little easier since
I’ve been onus cause I can just say, yeah, we’re making an iPad app.
00:42:43 - Speaker 1: Well, so, funny enough, this gentleman who claimed
not to know much about computers was actually more plugged into the
problems of our industry than anybody I know in Silicon Valley that you
just pick off the street. He starts telling me about how he doesn’t
trust the tractor companies. Because they’re taking all their data and
putting it in cloud services and it’s not necessarily to the benefit of
him or the equipment managers at the golf course, and how he’s been
building all his own software and FileMaker Pro to do all of this stuff
in-house, because he doesn’t like that all this data is going to
these.
Enterprises who are deciding what they pay and how much maintenance is
going to cost and all these things, and he’s trying to maintain his
independence and he doesn’t trust them not to change the data. I’m
like, oh man, you get this work better than almost anybody I talked to.
You understand the problems cause you’re out there on the edge. You’re
the guy who is suffering because of all these venture capital backed
startups and this big push to cloud sass, like, yeah, there’s a lot of
benefit, but there’s a lot of cost. And this guy sees it in a way that
most Silicon Valley software people don’t, because he’s feeling the
pain. And so one of the things that I think we need all to do as a group
is do a better job of like.
Realizing that climate change is not something for scientists to solve,
it’s too late for that, right? We need resilience at every level of our
communities. Everybody is going to be finding new ways to live and
working on new solutions to these problems, right? Social media driven
sort of like cultural collapse. It is not something that only media
theorists are going to solve. It’s all of us on our phones, on our
computers, in our lives are going to find new ways to communicate.
We’re going to need new tools to find that quiet space for ourselves,
whether you’re, you know, designing knitting patterns or whether
you’re Organizing neighborhood barbecues and potlucks, right? Like this
is not solely a problem that affects sort of elite thinkers in society,
and we should be building tools for everybody and thinking really about
deep resilience through all of society. And so I think that’s something
that I’ve been challenged on lately and I’ve been thinking a lot about
and so I want to encourage everybody listening to remember that like
this is an all of society problem and so we should be building all of
society responses.
00:44:57 - Speaker 2: Well, after that grand and sweeping discussion of
the big picture stuff, I’d actually be curious to just get a little
nuts and bolts. What does an Ink & Switch project look like? Mark and
I have talked before here about the Hollywood model a little bit, and
you talked in the very beginning about the pens down, the strict pens
down at the end of the project, but for example, two of these two
projects you mentioned earlier, what does it actually look like start to
finish?
00:45:22 - Speaker 1: So, we have a number of sort of active areas of
research, and there are other areas we need to expand into and haven’t,
but that’s a separate problem.
So, to do a project, the first step is to find a problem, and so we have
a process of sort of developing project briefs we call pre-infusion.
And so, you know, around the lab and in our community of past and future
collaborators are a lot of people who are sort of tracking these kinds
of interesting problems, but a good Ink & Switch problem is one that
we think is really important. That we don’t know how to solve and that
we don’t think somebody else will solve for us if we just wait a little
00:46:03 - Speaker 1: bit.
00:46:04 - Speaker 2: So maybe an example here might be the rich text
CRDT you mentioned earlier. We’ve done lots of projects with CRDTs
because that’s a great technology for collaboration and local first,
but then anytime we go to add text, you go, can we make this rich text?
Nope, because there’s no such thing as a rich text CRDT. OK, well, put
that in the future research bin somewhere.
00:46:26 - Speaker 1: Right, and I do want to point out that Kevin
Jan’s uh YJS project has a rich tech CRDT, but it had some properties
that we felt didn’t make it suitable for the particular task we had at
hand, and also, while he’s done a ton of great work there, There’s no
sort of documentation about how to do this that other people could pick
up and draw from because it’s, you know, an implementation he wrote to
solve his problems.
So we wanted to write something about this, both so that we could
implement it as well, but also so that other people could learn from
this and build on this work in a more sort of open way. So that’s a
great example of a problem.
So basically do some research upfront. We usually have one person doing
this sort of pre-infusion thing, they’ll look at the state of the art,
they’ll try and scope a problem, they’ll define what we need to do,
and they’ll kind of write up like a 1, maybe 2. Page description of
what’s the problem we’re trying to solve and how are we going to solve
it and who do we need on the team to be able to solve that.
And that’s important because as you’ve talked about the Hollywood
model before, but for folks who haven’t heard that episode, we sort of
treat each research project kind of like a film production. We put
together a team of experts or domain knowledge or generalists with the
right kind of philosophy, depending on the project. To execute on some
vision, and then when it’s over, we ship the paper and most people move
on and go on to whatever they’re doing next, just like you would if you
were building a film, rather than these sort of like permanent staff
researchers. So we do have a couple of folks like that around as well.
And so that’s kind of the pre-infusion.
00:47:57 - Speaker 2: One thing I’ll just note briefly on the staff
side is that being able to hire people kind of as short term for these
projects, which are usually a couple of months, means that you can get
the exact combination of skills that you need.
When we’ve done more kind of innovation oriented R&D within an existing
company that has a standing staff, you know, when it comes time to say,
well, we need to implement this back end system, what are we going to
use? Well, we use Erlang because we have an Erlang programmer on the
team rather than coming at it from what is actually the best technology
or the specific skills that we need and go.
Find those people.
I think one of the more dramatic examples to that for me, Peter, was
when you came into the lab and started advocating for CRDTs as a
solution to the kind of sinking problems we’ve been thinking about a
little bit, and then we decided to do a project around that, you know,
this was 2016 or something, because this was such an early time for
that.
There was probably only 10 or 12 people in the world who you could
consider experts or even reasonably knowledgeable about CRDTs.
We literally made a list, you made a spreadsheet and contacted every one
of them and saw who might like to work with us or who did we vibe with,
and that’s how we met Martin Kleppman.
00:49:08 - Speaker 1: Yeah, and we’ve been working with him ever since.
00:49:11 - Speaker 2: Yeah, it turned out to be a great collaboration,
but it’s a good example of where You don’t start from, you know, you
say, well, we’ve got some post graphs experts on the team, let’s do
post graphs. No, you start from what is actually needed if you look at
the whole world of skills and technology and design needs and what have
you, and then go find the specific person or people who have that exact
skill.
00:49:33 - Speaker 1: Yeah, and one of the other sort of killer
advantages of the lab is that there’s Code for America, and Code for
America is this great organization that basically gets engineers to
spend some time doing basically civic service, building software for
some kind of governmental body or agency and. You know, we could debate
sort of what percentage of that work ends up being sort of abandonwa or
how effective that is, but I think the model is great, which is it sort
of recognizes that in your career, you may have these gaps between
things, you’re finished one thing, you’re not quite ready to start
something new. And so Code for America, it’s sort of like an escape
hatch that people use when they’re tired of their job or just need a
break or want to do something different.
Similarly, because we run these sort of short term projects, We’ve had
this amazing ability to bring in incredibly talented people who will be
in eventually are snapped up by the top companies in our industry.
Moments later, but we get to work with them for a few months on some
really interesting project and not only do they influence our thinking,
but we influence their thinking, and so we’ve really been able to scale
our influence on the world. And to bring in a ton more insight and
knowledge and sort of inspiration by working short term with people than
we would have by working long term. And so I think that’s one of our
like secret weapons for sure at the lab.
So, once we scope a project and kind of say, OK, well, we want to do
this thing, we’re going to need these kinds of people, we go into
recruiting mode, as we said, and we bring in a team. And then at that
moment, our goal is like on kickoff day for a project, not always, but
this is sort of the archetype. We want to have like a really clear sense
of, you know, what’s the tech stack, what are we going to build, what
are some vague milestones along the way. At this point, we’ve done
prep, and you know, no plan survives contact with the enemy. Once the
project gets started, things tend to change, but we want to come in with
like a really clear direction and hit execution mode, and the team just
focuses, they go head down. And they just engineer the crap out of it
for like 2 or 3 months. We always pick sort of a fairly strict end date
at the start of the project. You know, the fear of like impending
deadlines helps everybody stay focused. And the other thing we do
throughout the project is we do sort of a show and tell every other week
where teams come and say like, hey, this is what we’ve been up to, you
know, share with the rest of the lab, get feedback, but that sort of
regular cadence of showing your work both helps people to stay focused
and on task, but it also gives you kind of like regular mile. Stone so
you don’t end up rabbit holing too bad. You know, it’s not like
there’s like a law, but you have to show up on this day and have
something new to demo. But if you’re going to turn up on Friday, on
Monday, you know, this week we’re going to be showing our work, so you
sort of make that extra little bit of effort to like make sure things
work a little better or to polish something up a little bit or just to
make sure you don’t break the build on Thursday kind of thing. So I
really like that cadence. And then at the end of that time, it’s sort
of like pencils down, project is done. And in the beginning, we really
just sort of like at the end of the project, someone on the project, the
project lead, would usually write a little internal Google doc talking
about what we did, and in the really early days, everybody at the lab
was on the same project, so everybody knew what the project did because
you did it together. But at the end of the project, these days we’re
spending more and more time writing, editing and publishing. And today
that process generally takes 2 months, 2 to 3 months of work, and it’s
certainly not full time work and often overlaps with pre-infusion for
the next project, but it’s very much this kind of like process of not
just publishing to share the knowledge with everybody else, but also
mining your memories of that experience for insight and figuring out
what happened. So that you can tell that story, and the process of
writing, I think, really turns the work into knowledge in a really
powerful way. And so as valuable as it is to publish this work to
everybody outside of the lab, I think it’s at least as valuable to
those of us inside the lab because it adds this extra level of rigor and
understanding that we all benefit from. And then at the end of the
publication, we put up these massive essays with lots of cool
interactive elements and links on the sides. And then you dust your
hands and take a quick breather and head back into pre-infusion and do
another.
00:54:01 - Speaker 2: I think the you can switch essay style is
something that developed over time. I think you wrote one of the first
pieces just kind of as a medium post, you said, hey, we should publish
about this work, and then we’ve gotten more comprehensive over time and
really putting a lot of effort, like you said, basically now, at least
in terms of wall clock time spending essentially as much time writing.
And distilling the results to understand what’s important, what are the
real findings, and then put it into this very nicely comprehensible
thing that others can read and learn from.
And certainly I’ve experienced that thing you talk about, which is
taking the time to do that.
I feel like I extract more insights from the project through the writing
process.
And then in terms of remembering it both in terms of institutional
memory, but also in terms of just as an individual, I remember the
things better or I can go reference my own work. It happens with some
frequency of muse where we say a design question comes up or a technical
question. I say, you know, actually we researched that exact thing at I
can switch, let me go pull up the reference and.
Sometimes we have some internal docs, but those tend to be pretty rough
and they haven’t been through the same clarifying process of writing
for an external audience. But when we’ve published about it publicly,
then it’s much easier to both find what you’re looking for, but then
also be able to draw from that and our team can use that to make
decisions about something we’re working on the product.
00:55:24 - Speaker 1: Oh, it’s great to hear that that stuff is
benefiting you and that you’re able to take advantage of that.
I mean, obviously you’re very close to the lab, but it’s nice to know
that our target audience is able to get that kind of yield.
I’m always asking how we can reinvent the lab, you know, I’ve just
talked about what the lab is, but I’m always thinking to myself about
what’s next. I’m always thinking about how can we change.
We’ve gotten much better at writing, we’ve developed this, we call it
the academic voice, it’s not academic, academia has too much jargon and
It has a really powerful culture around like these latexch publications.
We try to make our writing more accessible than academic papers
generally are in terms of tone and language, but we try to take a lot of
inspiration from academic writing in terms of maintaining a sedate tone,
avoiding superlatives, supporting any statements that we make.
We do actually publish a lot of our work in various academic venues
these days. But first and foremost, we published for the web and for
this sort of industry audience and for ourselves, and the academic
version sort of follows on from that.
00:56:31 - Speaker 2: Yeah, the academic format, you might think of as
being an illustration of how the lab sits on the innovation spectrum
between startups and classic academia, where, yeah, academia, you know,
you typically have, yeah, these PDFs, they’re published in particular
venues, you’ve got peer review, you’ve got a lot of conventions about
citations and things designed to enforce rigor. And then in the startup
world, people do publish, but it’s usually some engineer tried a
framework one time and they wrote a blog post about their insights on
that.
00:57:02 - Speaker 1: Right, or the point of it is like this marketing
exercise for a product.
00:57:05 - Speaker 2: Yeah, exactly, marketing for startups, yeah.
00:57:08 - Speaker 1: We try to be very sober in our presentation and to
be really explicit about trade-offs and shortcomings and open questions,
and I think that serves us well and it serves our readers well because
we try to make sure that we portray the work we do with the inspiration
and the context that we hope will make people excited about it. We also
try to be really transparent about what we have and haven’t done and
what remains to be done as well.
00:57:35 - Speaker 2: Well, as a place to end, you mentioned what’s
next for the lab or how might it expand or reinvent itself, what exactly
is on your mind there?
00:57:45 - Speaker 1: Well, to me, the biggest areas where we can
improve are both growing the scope of the kind of work that we do in
terms of both getting broader and deeper, I want to see us expand into
other adjacent areas, hardware, and I’d like to see us expanding into
ever more fields of research, but some of that comes down to just sort
of like funding bandwidth and people around.
But I’m also interested in Expanding the ways that we work and opening
up the lab to more people. We have this vision of a new kind of
computer, and you know, it’s that vision of a different kind of way of
using computing, not just programming, but computing that is more
empowering, that makes us better versions of ourselves, that lets us do
more things to do better work, to work better together, to think
deeper.
And I just think that our current working model is doing fine, but there
has to be so much more opportunity for us to take what we’re doing to a
wider audience and to get more people involved.
And I think some of that is writing more about the why behind the work,
but some of that is also finding new ways to get more people involved.
So, I’m always eager to experiment with new things, not just in terms
of doing the research, but also uh getting New kinds of projects started
and approved and so on, and yeah, we’re just gonna keep pushing the
envelope and keep doing the work out there. So, if you hear this and
you’re interested and you think that’s something I really want to do,
hey, send an email to me, hello at inkinswitch.com, and who knows, maybe
there’s an opportunity there.
00:59:26 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. You can write us on Twitter if you’ve got feedback at
@museapphq, and we’re on email as hello at museapp.com. We always
appreciate it if you leave a review on Apple Podcasts. And Peter, I’m
so glad that you’re continuing to push both the vision for better
computing and the vision for how we can do innovation in this
independent way and really looking forward to seeing what comes out of
ThinkSwitch next.
00:59:55 - Speaker 1: Well, thanks so much for having me on, and it’s
just a joy listening to the podcast and seeing Muses out there, building
great software and testing these ideas in the market that we’re working
on at the lab. So let’s keep that alchemy going.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: So I do think it’s a really tough sell for
classic native apps into the enterprise. Now there is another market
which you might call independent creative professionals, and these
buyers value different things and say what they want is powerful tools
that are shaped to their needs and workflow that they can deploy on
their platform of choice, and that give them a lot of abilities and that
are kind of unique to them as a creator.
00:00:26 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad and Mac, but this podcast isn’t about Muse the product,
it’s about Muse the company and the small team behind it. I’m here
today with my colleagues Mark McGranaghan. Hey Adam, and Leonard S
Saberski. Hello. And I don’t know if you fellows noticed, but we
changed the intro a little bit. I did. So this is a bit more
aspirational than actual, but exciting news, Muse 2 is coming early next
year, that will be in early 2022. I’ll link to our roadmap memo talking
about that, and one of the top features there is a MacA.
00:01:07 - Speaker 1: Very exciting, the pieces are coming together.
00:01:09 - Speaker 2: Yeah, and certainly this has been part of our
vision from the beginning, tying together all the devices where creative
people do work.
Clearly, the iPad, while we think it was sort of like an underserved
device and has a lot of potential for creative uses, particularly this
thinking work that Muse is all about, but having, I think, pretty well
explored that, we also need to fill in these other pieces of the
puzzle.
And so, desktop is obviously the next step there. And of course, one
answer on desktop is you make a web app, either something runs in a
browser or something that runs in a, what’s called an electron app,
which is basically just kind of a wrapper for a browser or a web
technology app.
But we’re opting to do something that is what I would call a native
app, and I thought that would be a great opportunity to explore the
topic of native apps generally and what those even are and and what they
mean for users of the software.
So maybe we can talk a bit about the technical side of that because it
is fundamentally a technical thing, but then the design user experience,
you know, what does it mean to design a native app and what’s the
benefit to users or how should things look or feel different for them.
And I’d also like to speak a little to the business side at the end
because we’ve seen a big growth in a lot of interesting productivity
tools, both kind of business team, enterprisey stuff, but also personal
tools and see how the native app question fits in there. So Mark,
you’re the most technical of this group, I think by a fair shot. So
maybe you could briefly define for us what is a native app or what’s
even the alternative to that and how do they differ.
00:02:48 - Speaker 1: Well, there are a lot of different axes here, but
let me give you the classic native app and then the contrast with say
the web app.
So classically, a native app is something that you download as a binary
artifact like a DMG versus a web app where you would go to a URL. It’s
implemented in the native language and stack of the platform. So for an
Apple products that would be Objective C or Swift. And it integrates
closely with the platform features and libraries for things like UI
systems access, input and output, and so forth.
Contrast with web, it’s going to be implemented in the language of the
web, you know, HTML and you might have more or less access to the
underlying platform features you might not be able to read it and write
the disk, for example. And then I think importantly, traditionally
native apps store things locally. On the local disk and web app store
things in the cloud.
Now, as we’re going to discuss, I’m sure you can mix and match
different axis here, but that’s the classic native app as I see it.
00:03:45 - Speaker 2: Right, so I think of the classic native
productivity tools would be something like the Microsoft Office Suite.
So if you were on a Windows computer in the 90s or early 2000s and you
would download or even install it from a CD probably, so you’ve got
the, as you said, the binary program, you copy that software onto your
computer, you run it there, and then when you want to save something, a
XLS. or a doc that goes onto your hard drive somewhere and you can
transmit that to someone else, you can email it, put it on a floppy disk
or a thumb drive, but everything is very on the local device and the
software is there and downloaded and runs right there on your computer.
And nowadays, both with things like Google Docs, actually, I think
Microsoft has even transitioned to cloud kind of web apps with their
stuff as well. That’s something where you’re really connecting to
someone else’s computer or cluster of computers, AKA the cloud through
your web browser and everything stored. Basically, most of the sort of
software itself is run on their computer and sort of the results just
transmitted to you and the data itself is also stored there.
00:04:52 - Speaker 1: Yeah, and just to give an example of mixing and
matching these different aspects, you have electron apps which are
distributed as binaries like DMGs on Mac, but under the hood they wrap
what is basically a web browser, so you have a web implementation and
then the resulting feel and storage characteristics is often in between
that of a native app and web app. It feels kind of webby, but also kind
of native, depends on the individual developer, but that’s an example
of how you can mix and match some of these axes.
00:05:22 - Speaker 2: Electron has become incredibly pervasive. Slack’s
desktop app is Electron, so it’s the Spotify app, so there’s the
Notion app, so there’s the FIMA app, so this sort of, yeah, wraps up,
would otherwise be a web app.
Another piece on the technical side, I think is it’s not just this kind
of web and cloud versus local program and local storage duality, but
it’s also how you implement that interface.
So there’s typically APIs that are customed to a platform, so Windows.
has a set of APIs, Mac has a set of APIs, iOS has a set of APIs,
there’s often widget toolkits that go with that, you know, on Linux,
you have something like GTK, often there are different widget toolkits,
and so the degree to which you use or don’t use those can make it feel
native. Now, Leonard, maybe you can give us the user experience or the
design side. What does native mean kind of within your discipline?
00:06:18 - Speaker 3: Yeah, I think there are a few different ways of
looking at it. So one is to just take the technical definition and look
at, OK, we have a native app. What does that mean for the design of the
interface? And we have a non-native app, what does that mean for the
design? And there are sort of implications on both sides that can make
the user experience better or worse. But what I actually find more
interesting is thinking about what makes an app feel native and look
native, even completely separate from the technical implementation of
it. So I think there are a lot of different factors to untangle that
just from the user experience, make an app feel native.
00:06:55 - Speaker 1: Yeah, and we can enumerate a few aspects of this.
So one that you’ve mentioned already is the look and feel based on the
UI toolkit and how the controls look.
Another, I think is how the app interacts with the underlying platform.
So for example, different platforms expect applications to write user
data in different locations on the disk, you know, like Unix has like
the slash user or whatever, and Mac has the till the application support
or whatever it is on Mac, right? And sometimes you get these apps that
are multi-platform, they start writing data in really random places and
it confuses you.
And maybe a third example, the most subtle would be the mental models
and metaphors that an application uses. So on Mac kind of uniquely
there’s this idea of app that’s separate from Windows, like physical
instantiations of the app, and so you can have an app open with no
Windows. Or you can have an app open with multiple windows, and that’s
quite different from how it works on Windows, where if you click the X,
like the application exits, because the window is the app and vice
versa.
00:07:50 - Speaker 2: Linux window managers typically work the same
ways, and also that you can run the program twice, right? So that was
something I has a Linux on the desktop user for many, many years, and I
actually really liked that if I ran my Text editor, for example, a
second time with my command pallet or from the command line or just by
clicking the icon, I would get a second window, a second instance of
that, and with Mac, when you click on it in the dock or you all tab to
it, it brings whatever was already there to the front. So basically
whether the program is running or not gives you different behavior when
you go to launch it.
00:08:24 - Speaker 1: And maybe one more thing we could throw in there
in terms of platform access is just the power of the features that you
have access to. So a lot of audio and video things, for example, are
hard to get at if you’re not a more native app on the iPad, for
example, you can only get 120 hertz if you can’t do that as a web app
and so forth.
00:08:40 - Speaker 3: And I think a lot of that is not just because you
don’t have technical access to those features, but even just because
these apps are designed for so many different platforms and so many
different devices that basically every feature that isn’t available on
all of these platforms just isn’t that important and isn’t that easy
to build.
00:09:00 - Speaker 1: Yes, and this brings us to what you might call the
implied aspects or dimensions of native versus non-native apps. So you
mentioned one which is if you’re building a non-native app, it’s often
because you’re building for multiple platforms and then you tend to get
this least common denominator effect where you only use the features
that are available on all platforms. Another one that we found is quite
important is performance, where sometimes but not always, if you
implement the app in a way that’s less native, you can suffer worse
performance or perhaps have a lower performance ceiling.
00:09:30 - Speaker 2: One thing we learned working with web technologies
and styluses was, for example, that the data you could get from the APIs
was just less.
Yes, you can get input, maybe you can even tell it’s a stylus, but you
couldn’t get, for example, the asimuth of the pencil.
And maybe that doesn’t matter for your particular application, but for
example, for Muse where we wanted to do weird stuff with you hold the
stylus in a different grip, and then you get a different tool, and we
thought this would be a cool and interesting and powerful way to take
advantage of that unique form factor, but it just wasn’t on the web at
the time. And I think the web tends to catch up eventually, but that
stuff always comes first to the native platform APIs.
00:10:08 - Speaker 1: Yeah, it’s a good point that there’s a time
dimension here where, as you said, often web or multi-platform umbrellas
will catch up over time, but you’re less able to change as the
underlying platform makes changes, you need to basically wait for the
change to propagate up through the various abstraction layers that
you’re using, whereas if you’re native, as soon as the underlying API
changes, you can adopt it.
00:10:32 - Speaker 2: Now another slice maybe of the kind of native
versus not, again on the technical side here is the web I think of as
being the sort of universal runtime that won the wars of the early
2000s, so for those graybeards like me who are around to experience
that.
Java and the JBM was a very big push in the industry to create this
concept of right once run anywhere, that you have different computing
platforms or different kinds of computers, different operating systems,
different manufacturers, but in a way they were kind of especially
pre-mobile, they were basically all pretty similar in terms of they have
screens and keyboards and some kind of pointing device and seems silly
that you have to rewrite your app to run it in.
Different places and the JVM had this concept that it could make this
universal run time, make it run anywhere and Flash had a version of that
as well, but they both were basically pretty terrible experiences for
anyone that ever remembered running Java Servlet applications or Flash
had its uses, but in the end also it felt like this this very confined
box that was just constrained.
From interacting with your computer in all these useful ways, and I
think the web eventually won that war where essentially everyone now has
a web runtime environment.
It’s called the browser. It’s become extremely powerful. It often can
tap a lot of the operating system APIs for hard audio and video access
and things like that. And of course we do love the web for a lot of
reasons and that has unlocked a lot of things, but in the end it is this
essentially kind of translation layer.
Another type of translation layer that isn’t requiring the user to
install a runtime, that is a browser or a JVM is something like React
Native, or something like Cordova. It’s the right ones run anywhere
concept, but rather than trying to give that sort of general bundle to
someone on Windows and someone on Mac downloads the same program, the
Java jar or the web HTML plus related assets bundle. Instead, you
actually compile it, trans. You might even say to each of these
platforms.
So React Native, for example, is a mobile application platform. You
write your app for a phone, but then it can compile to iOS and it can
compile to Android, and these are true native apps in the sense that
then you compile them and build them with the normal iOS and Android
tool chain, they become a binary artifact that is probably hard to tell
from casual inspection. That it wasn’t built kind of directly using
Xcode or the Android equivalent workspace.
And yet of course it has the downside that now as you said, lowest
common denominator there is this translation layer, but it just kind of
happens at a different time. It happens on sort of the developer’s
computer when they do the build and through this toolchain rather than
the end user’s computer. And so that probably gives you some
performance benefits, but there is this thing where you’re kind of
homogenizing between the platforms.
00:13:36 - Speaker 1: Yeah, and with React Native in particular, you
seem to get the now you have N +1 problems issue, which we have to some
extent with browsers, sort of famously web developers deal with browser
quirks and every browser is a little bit different, although that seems
to be less of an issue these days with auto updating browser. But with
React Native, it seems to be a huge deal. Probably because of the
surface area and complexity and dynamism of the underlying APIs, just
trying to write something that compiles reasonably and runs reasonably
on these two platforms which are very different and have very particular
APIs just has proven to be quite hard, but we can talk more about how
that’s played out.
00:14:07 - Speaker 2: But where I thought the technical side interleaves
pretty well with the designer user experience side is I feel like this.
I don’t know if it’s a siren song, or at least it is an appealing idea
to developers and to certainly to businesses that don’t want to have to
maintain code bases and multiple platforms that you write kind of one
single code base and then you can deliver it to different platforms
through some kind of minor effort, minor translation layer. And I feel
like it’s so compelling to the creators of the software, but then as a
user of the software, then there’s this thing where, yeah, it just
seems like it’s never as good. It’s gone through this translation
layer, it’s lowest common denominator, either it feels like the other
platform. So, one example there might be something like, I sometimes use
the Audacity audio editor, which I originally used on Linux back when I
was in that world, it’s built using the GTK toolkit, so it was native
to that environment. And they build what you would call native versions
for Windows and Mac, but it looks like Linux, because it uses the GTK
toolkit, it does not integrate at all well, and that matters a lot for
audio stuff, so it’s a good example there with Audacity, it’s hard to
switch between your audio sources, it basically gets really confused, it
just doesn’t use the Mac audio APIs very well, so it ends up feeling
very, very clunky and feeling like it’s been transplanted from this
other place, even though it’s been compiled in this way.
00:15:34 - Speaker 1: Yeah, and this is an engineering problem. You’re
not fated one way or another to have either a great uniform app or a
terrible app that looks bad on all the different platforms. Another
example would be Flutter. Flutter. Yeah, so they did the same thing.
It’s right once run anywhere for I think primarily targeting mobile
platforms, but they did the thing where they reimplemented all the iOS
controls, Pixel for Pixel, and it basically looks pretty good, even
though you’re not using the AS controls at all, so it can be done, just
big engineering problem.
00:16:01 - Speaker 2: So Leonard, what for you is some examples of great
native apps that showcase, it’s not necessarily about the technology,
but it’s about being designed specifically for a particular form
factor, or a particular platform.
00:16:14 - Speaker 3: Yeah, I think the most obvious example to look at
is just the Apple apps, you know, that’s the sort of gold standard, of
course, in terms of native apps that are adapted to each platform. There
has been, at least in recent times, like some exceptions to that, where
they are also trying to bring the iPhone or the iPad app to the Mac. And
that can result in something similar to just bringing a web app to the
Mac, where it’s not really optimized for the platform and it doesn’t
quite feel right. But yeah, there are some great examples and I think
especially for the pro apps, you know, Final Cut or something. This is a
very native app that feels great in its design exactly for the platform.
I think there are still a few third party apps that do a great job, like
Things app. Which is a task manager.
00:17:01 - Speaker 2: Things was gonna come to mind for me, yeah.
00:17:03 - Speaker 3: Yeah, and things are surprisingly, I don’t think
they actually use that many completely native UI elements like a lot of
the UI is sort of custom, but all of it feels very native and it is
still a native app and they just customize elements to sort of bring in
their own brand and do things a little bit differently to fit their
needs.
00:17:25 - Speaker 2: Yeah, for me, the feeling native thing is not
about using system controls. I think it’s good when kind of principle
at least surprise or you’re familiar with these controls, and so
therefore, you know, if your share sheet just uses that standard share
action icon and you tap on it and you get a pop up, whereas I think
it’s quite common. I know a couple of apps do this quite annoyingly
where you tap that share icon and you get something that is not the iOS
default share thing, maybe Twitter does that.
00:17:55 - Speaker 3: Yeah, I think YouTube does that and basically all
the Google apps, like they first show a share sheet that highlights all
the different Google ways to share and then like at the very bottom of
the very right corner, you have to scroll to there’s like a tiny more
button and then you get the actual share sheet.
00:18:09 - Speaker 2: Yeah, exactly, there’s some more thing and that
takes you to the system one.
For me, it’s not necessarily about using the system widgets everywhere,
it is about performance, it is about using the form factor to its best
extent, and I think things is an example I like because they have apps
for Mac, for iPad, for the phone, and they’re all very similar visually
and they have a lot of the same controls, but they use the different
screen size.
And they use the different options that are available in each place. So,
for example, they’ve got great keyboard shortcuts, which you can use on
the iPad and you can use on the Mac, they’re not relevant on the phone
for obvious reasons, and so, making use of what exists in each place,
even if it’s just different screen sizes and orientations, is part of
what it’s about, that it’s been thought about, how do we make this
work well on this. Device and I think that’s where often either the
translation layers or back to some of our very first episodes of the
podcast, Mark and I spoke quite a bit about what he usually calls the
transliteration of apps, rather you take a desktop app and you try to
bring it to the iPad, or you bring an iPhone app and you bring it to the
iPad, and either way, if you haven’t really thought about iPad’s
unique capabilities, unique form factor, it just feels like a port, like
a weird port. And sometimes I’ve even seen versions of these where
people take iPhone apps and make it available on iPad, but it doesn’t
even work in landscape mode. It’s got this weird letterboxing. I almost
think, why does this even exist? It is so out of place on this platform
that you might as well just not even have it.
00:19:50 - Speaker 3: Yeah, I think there’s another reason here why
many larger companies prefer a non-native design for the apps.
And I think often it basically comes down to their brand identity and
they don’t want to give up their brand for feeling native. So in the
end, it becomes a decision between being native to the system and native
to the brand that you’ve established and the sort of visual system
around that.
And so for example, apps like Spotify, they basically look the same on
every platform, on every device and they also behave and feel similar,
right? And I think for them, that’s a very conscious decision not only
because they don’t want to develop a native app for every single
platform, but also because their brand is so important to them.
And I think that’s especially true for industries like music streaming
or even like car sharing food ordering where it’s very commoditized and
you basically have to rely on your brand for people to use your service.
And so if they all switch to like a generally more bland, less branded
native experience where they can’t control every single aspect of the
app, I think that’s just not worth it to them.
00:20:59 - Speaker 2: I think you also see the war between the tech
giant empires play out there a little bit, right? Google wants to bring
their material design stuff. It’s actually an interesting thing
recently where maybe it’s the Google Maps team or one of the teams that
takes some of the Google products and brings them to iOS, and they
retired a bunch of their custom widgets, some really interesting Twitter
thread there. I’ll see if I can find and link it, but They do have a
kind of consistent, I mean, material design is great and it’s
consistent across these different platforms they’re on, it’s tied to
their brand, but there is also this element of Google and Apple are kind
of warring empires in a way, and you probably get a similar thing with
Microsoft as well.
And so it’s weird to say that you know Microsoft Office doesn’t feel
that native on Mac because they want to like. Use their unique brand
identity when Microsoft’s office is pretty bland and vanilla, but there
is this element of it’s their, they’re trying to bring some of their
empire into this other company’s empire, and so sometimes you see these
wars play out, maybe like the YouTube share sheet is an example of that.
What you’re seeing is not kind of user-centric design, what you’re
seeing is the warring tech giants trying to encroach on each other’s
territory.
00:22:12 - Speaker 3: Yeah, and I think if you take it to the extreme,
there can be cases where basically a third party creates a platform on
top of your system that’s just completely takes over the design. Like a
lot of people just spend a ton of time on Facebook and use Facebook apps
and Facebook services and everything that’s created there will just
look like Facebook and not support anything system related. And I think
there’s a similar thing in many countries where you know in China you
have WeChat and that is like the platform that everything runs on and it
doesn’t matter at all if it’s running on an iPhone or an Android. It
just becomes the system essentially.
00:22:47 - Speaker 2: Yeah, that’s a good example, and I’ll tell you
another good example, almost the most impressive one of all time, which
was in the 1990s, Microsoft had an absolute lock on the desktop
operating system.
To the point that they were, you know, being hauled in front of federal
courts for essentially having a monopoly, and the thing that eventually
broke that was not legal action, I don’t think, but was the web and the
appearance of the web browser was essentially this insertion of a whole
other platform, or other almost operating system. That you could run
inside this existing platform, and I think ultimately the web was what
broke the Microsoft monoculture and Microsoft computing monopoly a
little bit. And so rightly so, I think companies are afraid of that.
Apple probably works hard to defend against that, for example, not
allowing other browser engines on iOS or letting you do anything that
runs code or anything that looks vaguely platform like and for good or
for ill, but you can see why from a business perspective and defending
your empire perspective, that’s a wise decision.
So Leonard, you’ve been spending a lot of time on the design of Muse for
Mac recently, and without giving too much away there, I’d be curious to
know how you went into approaching that or if you have this idea in your
mind that it’s good to design something to feel native, it’s less
about the technology and more about how it feels and what the end user
experiences, what principles did you bring to bear, or how are you
approaching the design of use for Mac with that in mind?
00:24:23 - Speaker 3: Yeah, it’s interesting because Muse is basically
a native app both on the iPad and on the Mac, but it does still feel
like a bit of a foreign entity when you use it since we are not using
that many system components by default and we are doing things a lot
differently than many other iOS apps.
00:24:42 - Speaker 2: One of the things I found really interesting
reading some of your just internal memos as you were gearing up for this
project was pointing out that basically Muse for Mac will use a lot more
system widgets and a lot more common conventions around things like
menus and shortcuts and Right, click context menus and things, and
that’s basically because Mac is the world’s best, it’s just my
personal opinion, but I think a lot of people share it, it is the
world’s best platform for creativity and productivity. So on iPad, we
came into it saying we think this device has huge potential for creative
tools, but that potential is not being exercised, and that’s lack of
the right kind of software and it’s also lack of the right kind of
support from the operating system or the right kind of widgets or the
right kind of system APIs.
And so we kind of invented a lot of our own, and we started with a
literal blank canvas and brought in a lot of our own controls and
interactions and so on, taking advantage of a lot of the things that
make iOS very powerful, including the high performance and the
programming frameworks and so on, but really the system level widgets
were of less use to us.
But it seems like on Mac, that will be less the case because in fact
there is a multi-decade history. In fact, I would argue that Mac traces
its lineage back to Xerox PARC when Steve Jobs went in there and saw the
future of computers in the form of the Alto and brought that to Lisa and
then the original Macintosh. And so it’s steadily accumulating all our
best practices about how to be productive on computers in that time.
00:26:19 - Speaker 3: Yeah, I think iOS and iPads have something very
special and unique there where every app really feels like its own world
and it sort of lives on its own.
And I think as a result of that, we have seen many native IOS apps
looking very different from each other. And that’s not really as much
the case on the Mac.
Like the native apps on the Mac all look quite similar and feel quite
similar. Like there are some that, you know, maybe trying things
differently and either succeeding or failing, but in the end, like they
are all trying to follow the same visual language.
And that’s not really the case on iOS and I think that provides an
interesting opportunity at least for designers to try new things. And I
think you have to be a bit more careful with that on the Mac since yeah,
there’s such a long tradition on the Mac and be right next to all kinds
of other apps and people kind of have a different expectation of how an
app fits into the system. And so I think a general rule for us, even
though it doesn’t seem like it at first, is actually we deviate from
sort of the native default design for a future, then like that has to be
a very deliberate decision and like we have to have a reason for it. We
have to understand why the system component or the system design pattern
works differently and then we can sort of do our own thing with it. And
I think that’s even more true on the Mac and there will also be less
reasons basically to do our own thing.
00:27:41 - Speaker 2: Yeah, to name one example that comes to mind as a
pretty core design idea from Muse dating back to our research prototype
days is that you should never have to wait for anything, no controls, no
gestures, have some kind of built.
In delay.
So the standard drag and drop on iOS, and that includes iPad OS, is that
you hold your finger down for some period of time. It’s usually about
half a second and then the item kind of lifts up and then you can carry
it someplace else. And the problem with that is if you want to move a
bunch of items quickly while you’re constantly waiting. And we wanted
to make something where you could not only never have to wait, but in
fact, with the larger screen of the iPad, there’s this really neat
effect where you can start moving your hand in the direction of where
you want to move the card, bring the finger down and sort of catch it
just like it’s an index card sliding across your desk, move it to where
it’s gonna go and let go. So there’s no delay there, but that, you
know, is our own custom gesture system because that’s quite an unusual
way to do things as far as I know. I don’t know that I’ve seen any
other app on iOS do that, whereas on Mac, yeah, guess what, when you
click on an item and start dragging it, it goes right away. That’s,
that’s how it works. That’s how basically all programs work. And so,
great, so there we just do the standard thing that everyone else does.
00:29:03 - Speaker 3: Yeah, I think you can really achieve a lot if you
try to play to each system’s strength and not just, you know, try to
adapt one element and like make it work.
But really think about the different kinds of inputs and systems
surrounding your app.
Like at the very basic level on the iPad, of course, we have touch input
and, you know, that feels great. You have like a very direct way to
manipulate things, can your gestures and we use that a lot from use on
the iPad.
But then on the Mac, like if we just take all of that stuff and let you
do the same stuff with the mouse, yeah, theoretically that would work,
but it’s just not going to feel great.
And so instead, the mouse has its own benefits, right? Like it’s much
more precise. It can be used in tandem with the keyboard that’s also
always there. And so I think there will be a lot of opportunities like
that where if we really think about what the strength of each platform
is, then we can do something that web apps which have to serve the
lowest common denominator, can’t even do at all.
00:30:01 - Speaker 2: And I think it’s not just the capabilities of the
platform, but the use cases you are going to use them for and even how
you were sitting.
So Mark, I think this was part of your kind of original vision for the
multi-device use experience.
I’ll see if I can paraphrase here, which is, you know, when you’re at
the computer, you’re in this focus posture, you’re probably sitting
upright, you’ve got the bigger screen, you’ve got the keyboard and
mouse. You’re probably doing something like deep research on the web or
maybe production work, like writing a long paper or designing an
interface or something, whereas the tablet, maybe you’re sitting in a
reading chair, you’re at a cafe, maybe you’re outside somewhere.
You’re in this much more relaxed, or you have a lot more variety of
positions you can have flat on the desk, sitting in your lap, that sort
of thing. You might be holding it in different angles and you’re using
it more for this thinking, arranging, pondering, you’re scratching your
chin and sipping your coffee and maybe getting up and pacing around the
room. You know, that’s more of the setting that you’re in. And so, of
course, you have different capabilities on each device, but in many
cases you actually have different uses, and so we should be as much as
we can designing for those uses, I think, without also being too
restrictive about we obviously don’t want to stop you from doing any
one particular thing in any one particular environment, but knowing
roughly what sort of environment and what sort of use you’re having
seems like a thing to take into account with the design work.
00:31:24 - Speaker 1: Yeah, exactly, and then by the way, the phone is
going to be, you’re on the go, you have one hand and a few taps, and
that’s it to either save something or look something up quickly.
00:31:32 - Speaker 2: Yeah, a good example on the phone is I think it’s
considered best practice, and I think I probably agree with this to try
to make everything doable essentially with one finger, basically one
thumb, and also a thumb that you can reach, you know, maybe in the
bottom half of the screen.
So most of what you want to do when you’re hailing a ride. You’re
messaging with a friend, you’re quickly looking something up on the
map. You got to imagine that you’re juggling the phone in one hand,
maybe you got a coffee or a baby or a dog’s leash or a bag in the other
hand, it’s a noisy environment, maybe you’re outside.
And so what the design should prepare for is I’m at my office, it’s
quiet. I’m looking at a big screen, I’ve got my hands on a full-sized
keyboard, and I can take my time and I have much more precision, and I
want more control and power, but it’s also OK if the essentially things
are a lot fussier. There’s more on screen at the time, and if I click
on the wrong place, it’s OK, I’ll undo that sort of thing.
00:32:29 - Speaker 1: OK, so we’ve been talking a little bit abstractly
here about use cases and postures and number of hands available and so
forth. Leonard, to kind of bring it back to the concrete visuals, how do
you see that being different across these different platforms and native
versus non-native?
00:32:43 - Speaker 3: Yeah, I feel like there’s always a very
interesting conflict between native and non-native apps where native
apps always seem like sort of the dull ones and the ones that aren’t
going to be visually unique or interesting. Like we talked about this
earlier with the brand design and presumably if you do a native app, you
know, your brand is not really going to shine through. And so I think
the instinct is very often to just not follow the native design so that
you can sort of do something unique and do something interesting and
then your app will actually stand out from the crowd.
00:33:14 - Speaker 1: This is like moral hazard, visual designer
edition. It reminds me in the world of engineering where sometimes
companies make it a requirement to get promoted, they do something
complicated, and then so engineers introduce a whole bunch of
unnecessary complicated stuff into production because they want to get
promoted. As a similar vibe to me.
00:33:30 - Speaker 3: Yeah, I think there’s actually a management part
to that where as a designer, if you, if you strictly try to follow the
system components, like those are basically constraints, and if someone
tells you and says, you know, we want to do a specific thing this way,
then you might have to say that’s not compatible with the system way of
doing it and we can’t do that since we are following the system
guidelines.
And so it’s very appealing in that way to just do your own thing and
then you can always say, OK, yeah, let’s do what we want basically.
I do think we kind of have a bit of a lost art idea of being able to get
the most out of the native components and being able to bring your own
design language into them. Like if you look a few decades back to
something like Windows 95. Like there when you download like a media
player from the internet, you would actually have skins that you can
also download and then the app just looks completely different and
completely wacky and basically by now modern interface standards usable,
but it introduced a ton of personalization and sort of uniqueness to the
whole platform, right? And I think it’s somewhat making a comeback that
like some apps have options for themes or skins you can click through
and those can still be native apps and they just sort of transform how
things look a bit and introduce some personalization to it.
00:34:46 - Speaker 2: One interesting point there, I think we talked
about with Weiweiu in our episode about expressive tools is there’s the
designer or the company getting to express their unique brand, like you
mentioned Spotify, and then there’s the individual getting to customize
so that they can express their unique personality through their
computing environment.
So I think the Winna skins were great. Yeah, a lot of them were maybe
not super usable, but maybe for a media player, that’s pretty simple
anyways, it’s just like play pause, volume, jump track, you as a user
are choosing, I want this wacky, brightly colored one, because I like
what that expresses about myself and brings some customization to my
computing environment.
Which something about that feels more wholesome or maybe just comes back
to this user-centric thing again compared to my company has a
prerogative to use our brand styling system everywhere possible in order
to maximize shareholder value or a designer wants to get promoted
because they did something cool and unique that stood out to their team
or to their boss. I don’t want to be too negative on that. I think
there are a lot of good places for bringing unique style and character
to an application that reflects your team or your product, but I think
those are two really different categories.
00:36:05 - Speaker 3: Yeah, I guess what I would like to see more is
just people trying to merge the two and trying to use native components
and still infuse them with their own brand.
Like one great example of that is a Wikipedia reading app called V for
Wikipedia. And that basically uses like 90% system components, but if
you just look at it, like it still exudes sort of its own style just by
type of. colors, iconography, animations, good image views, and that
sort of requires, I think, a pretty high craftsmanship to be able to
really merge the two and you have to really know what each component is
doing and what you’re trying to do with it.
But yeah, I think if we could see more of that, that would elevate
native apps to a level where non-native apps don’t have as much as an
advantage at these foreign brands anymore.
00:36:56 - Speaker 2: Another example that comes to mind for me on that
when you’re talking about typography is Twitter. I think they do pretty
well with something that to me feels like a pretty fundamental app on
the iPhone, browsing social media sort of like, for better or for worse,
what our pocket communicators have largely become for.
They have a new typeface that I think they had custom designed, but for
the most part, they really give over the space to user content. You have
avatars, you have the handles, you have the tweet. And you have, you
know, an image or video, and you can scroll through that in a feed, and
it mostly feels pretty kind of integrated to the operating system, and I
think it works pretty well with the share actions and things like that,
although they may have their own share button problems. But in general,
it feels like there’s a Twitter brand, but it also doesn’t feel too
overbearing or feeling like they’re forcing it on you, or either that
that’s taking away from sort of the personal brands, you could say a
person communicates through their Twitter bio or whatever, or that it
feels out of place on the iPhone. I think it feels very good and natural
on the phone. Multimemedia kind of audio and video stuff.
There’s also another interesting one coming back to the WA thing, and
you also mentioned Final Cut, uh, program I use, which is maybe in
between those two is called Screen Flow, which is a really nice kind of
classic screen recording software for Mac and been using it for many
years, and it’s sort of not nearly as complex or sophisticated asinal
Cut. But it does allow you to do quite a lot that’s very specific to
screen recordings related to use and other software that I work with,
and it feels very native, it’s certainly fast, it uses system widgets
and that sort of thing, but it also does bring some of its own style to
how the timeline is shown, how you interact with, you kind of slice and
slice the video clips, and what happens, you know, they do a little icon
of a rabbit when you are doing a sped up clip and a little icon of a
turtle and it’s slowed down. So I think that’s kind of a nice example
from an indie shop.
00:38:57 - Speaker 3: Yeah, I think that’s a good way to do it in
general, to sort of infuse the uniqueness and branding into the
components that make your app special anyway, like yeah, for a video
editor, that’s like the timeline and specific settings for it, but then
try to use system components whenever you have more standard options.
00:39:15 - Speaker 2: So two interesting apps I’d love to reflect on
here are Sketch and Nova.
So both of them have essentially worked native in the concept of being a
native app into their marketing, which is unusual because I think
that’s typically seen as more of a technology term or a kind of an
insider jargon.
That sketch, for example, has this beautiful article titled Part of Your
World, Why We’re proud to have Built a truly native Mac app, and then
Nova right on their homepage, they talk about a native Mac code editor
and why that’s better, and basically all of their value proposition is
around why being native is a better experience for the end user. I think
your users of both of those pieces of software, Leonard, I’d be curious
your take on those specifically and sort of presenting it as a user
benefit in their marketing.
00:40:06 - Speaker 3: Yeah, I feel like for sketch, it’s certainly a
unique selling point, especially since they are an app for designers,
and I think a lot of designers still do care about that craftsmanship
that is in the native app and like prefer using native apps. And so I
feel like they specifically sort of have to lean on that.
But then on the other end you have FIMA, which is not native and it’s
still doing great, right? Like it’s a very fast app. The first time I
heard of it was because Sketch was actually really slow and like
crashing a lot with large files while on Figma, the same sort of
designed files were just completely smooth. So they still managed to, in
terms of performance be similar.
In terms of the design of the interface, they are very similar to
sketch, like you don’t have to adapt too much. And at least over the
last few years, it feels like Figma just has gotten a lot better than
Sketch at developing new features and basically making a better app
faster than Sketch can make an app that supports collaboration and the
web, basically.
00:41:08 - Speaker 2: Yeah, I think that brings us nicely into the
business side of this, which is kind of the last piece I wanted to talk
about which.
Maybe the sketch figma thing is something we’re seeing play out
throughout the industry, which is FIA can start with something that is
maybe worse in some perspectives because it’s not native, but they’re
able to reach a wider audience, they’re able to offer these sharing and
collaboration features that in turn, and those things are both valuable
enough, they can essentially earn more money or attract more investment
dollars. They can use that to hire an unbelievably good engineering team
that have done.
Just really remarkable things with using the web platform through web
assembly and other quite impressive tricks, and therefore more or less
keep up with and maybe even in some cases beat sketch on some elements
like performance, obviously things like integration the system APIs will
just never be possible.
But maybe those aren’t quite valuable enough to users, at least not in
comparison to being available on every platform by default and the kind
of sharing and collaboration features and so then that naturally creates
a flywheel where they can earn more, they can get more investment and
then they can make the product that much better.
So to me, it comes to a tough question for us, the software makers and
all software creators have to consider the same thing, which is we can
sit here and say we love the crafts personship and the design work and
the performance of native applications, but then if we look at the
industry, I wonder, is that kind of a bad bet? Are we sort of picking
the losing side?
00:42:38 - Speaker 1: OK, a few thoughts here. I do think that the
center of gravity of how software is implemented in terms of the
language, the platform, the deployment is going to be determined by the
economics and right now the best economics in the industry are an
enterprise software. There’s also a consumer software which we can talk
about, but let.
Focus on enterprise.
One of the things that enterprise buyers care about, it’s uniformity
and ease of distribution, control, security, ability to facilitate
collaboration, which is almost a definition of an enterprise, right? And
these are things that the web really excels at.
So to my mind, Sigma was better than Sketch for enterprises because the
things that enterprises value were just more aligned with how the web
works, you know, that Sketch might have had better native API
integration. It’s almost like not even wrong. It’s just not what the
enterprises, I think we’re looking at when they were looking to buy
software to support collaborative design, right? So I do think it’s a
really tough sell for classic native apps into the enterprise.
Now there is another market which you might call independent creative
professionals, and these buyers value different things. They don’t
necessarily care about uniformity of distribution and control by someone
else in anti-fe and say what they want is. Powerful tools that are
shaped to their needs and workflow that they can deploy on their
platform of choice, and that give them a lot of abilities and that are
kind of unique to them as a creator.
And so I do think you see these tools succeed with this platform choice
with things like sublime text or even something like Final Cut Pro. But
there’s this asterisk of success is different because the market is
much smaller.
That’s just the way the market is right now. The ability to price these
things is significantly lower than enterprise software, so that is what
it is. So I think it’s not so much that one is better than the other is
that they’re aligned with different markets and the markets are of
different size, and I mentioned consumer briefly. Now consumer, I would
actually say is better for natives, in particular, it’s better for iOS,
which is the main platform in terms of money. And their consumers
actually really value performance and integration with their phone with
things like contacts and so forth, and so there you do see native apps
winning.
One other thing that I’ll say here is I do think that sounds maybe a
little bit bleak for native apps. There is the consumer positive and of
course there’s this independent creative professional positive that
we’re targeting with Muse. I do think that there are a lot of
sensibilities from native apps that you can pull into apps that are
distributed over the web, because I mentioned that these axes are
somewhat independent. So one of my favorite examples and sorry notion,
I’m gonna pick on you again, we do it because we love you. Notion
search is really slow. You type a sync, which is something that we’re
working on now, and it takes like 5 seconds to show you a result. And
that’s not because of native versus web, like whether it’s written in
JavaScript or objective C. It’s slow because it’s going to a remote
server and like scanning notions entire database for stuff.
My sync, where if instead it worked like a local app where just loaded
all the data in memory and scanned everything I’ve ever written, they
could do that in 10 milliseconds, right? That’s an example where you
could have something distributed over the web with something like an
electron app, but they had more of this native slash local first
sensibility and gave you some of those benefits. So it’s not all bleak.
00:45:38 - Speaker 2: Yeah, well, as you said, that comes back to the
data question and so it’s less about, you could have a native app that
was mostly doing things through APIs to cloud backend, and yeah, every
time you need to do a quick search, it has to go, you know, round trip
to the cloud.
But you would also have a web technologies app that has much more local
stuff. I think it was something like Kevin Lynasiner is one good example
where he wrote the thing in Rust. He had the goal of 60 frames per
second. It’s a nice blog post about that, I’ll link, and it’s really
all about looking stuff up on your local system, and he used web
technologies because that’s what he’s good at using, and you can make
them fast if you want to, but it really is about the data locality more
than how the software is built, let’s say.
I think another important question on the business side is the platform
creator and what their incentives are.
So, we’ve definitely seen this and talked about it a little bit with
being a prosumer iPad app, means that you’ve got the App Store with the
heavy-handed review. And the pretty limited things that you can do
inside the application, and a lot of things you inherit from App Store
economics, which are really all about consumer, but makes it harder to
do a subscription prosumer piece of software, for example, and probably
Apple’s incentives are such that that’s not super likely to change
because the iPhone is their big product and the App Store is made to
serve that, basically. And then similarly, you might have something like
Google, which has platforms like Android or Chrome OS, but you know,
when you look at their business empire, those are not primarily
moneymakers for them, they’re primarily channels to get you into the
places they actually make money, which is, for example, having you do
searches and serving you ads.
And even Microsoft famously in many ways the most successful platform
maker of all time, as we talked about that 90s computing platform
Monopoly, they, as of a few years back, basically deemphasized Windows
that when Satya came on as CEO, basically said, look, Windows is
Microsoft’s past, it’s still a piece of our business, we need to
create it and make it good, but it’s not their big focus and it’s not
their big moneymaker.
So then the Individual platforms in terms of what they want to
incentivize with developers, in terms of how they, how you distribute
apps, how they allow or enable you to make money or not make money
through the apps.
Certainly things like app stores, what APIs are provided, all of that
plays into dynamics about what kind of software can get created, and it
really does feel to me like the web. Ends up being the best, not just
for enterprise for the reasons you said, Mark, but even this more
prosumer world of things, you know, I think we see this kind of tools
for thought, space, you know, that includes the notions and figmas of
the world, but also something like Rome or obsidian, for example. Yeah,
it’s just the web is I don’t know, superhuman or linear. These apps by
being on the web, they get maximum control, they get ease of
distribution, and they get to charge money without an intermediary, and
that’s just a very powerful thing for business.
00:48:46 - Speaker 1: Yeah, yet another important idea in this political
economy of software that we’ve been talking about a few times on this
podcast. I think that’s an important like.
00:48:55 - Speaker 3: And I think even if we assume naively that the
goal of every company is just to create the best app possible, even then
native apps become less and less a good choice, the more devices you
want to support.
And so as Mark said, enterprise companies just need to support many
devices.
And so if you try to do native apps for all of these, like that’s not
gonna be possible. You won’t be able to really create a good experience
across like 10 different platforms and device factors, right? And so I
think that’s why we often see native apps more with smaller companies
that may be focused on, yeah, either a single user environment where you
don’t need to support many different platforms and ideally even an
environment like Apple’s platforms where you have the Mac, the iPad,
and the iPhone, or even the Apple Watch, all kinds. sharing some APIs
and the code base and some design language so that a few people can
reasonably keep it all in the head and sort of design and build a good
product for all of these platforms, and that sort of approach doesn’t
really work anymore for larger enterprise companies where you need to
have apps on many different devices.
00:50:04 - Speaker 1: And now that we’re talking about this, I got
another riff, so we talked about how perhaps enterprises tend to choose
web because there’s all this collaboration amongst the members of the
enterprise, which in fact is almost the definition of an enterprise, but
increasingly you could say we’re all part of the enterprise of like the
software community, and this is a little bit of a joke, but here’s what
I mean.
It used to be that you would like go to the software store and you would
buy a box with Excel and you would install it and you would try to learn
it yourself, and that was kind of that.
But now we’re in a much more networked community.
So for example, If you are doing design, you might want access to a
plug-in that was authored by someone else on the internet and to be able
to install it.
Well, by the way, it’s a lot easier if you’re using FIMA, or it just
might be that you want to look at a YouTube tutorial of how to do
something.
I said several times in this podcast that YouTube is very important, and
if your product is available on essentially all devices, there’s more
likely to be good YouTube content, so there’s this big positive
externality that feeds back in.
So this is kind of me partially trying to understand why it is that what
Adam just said was true about the web also seems appealing for what
looked like in one sense to be individuals, but even there there’s an
element of community and participation.
00:51:10 - Speaker 2: One item might be remiss to leave out in the
business discussion was there was a bit of a kerfuffle, I might say in
the iOS slash Apple developer community when OnePassword, which is one
of the more successful password managers, announced that they were
switching from their native built password manager on the Mac to one
built on what’s basically web technologies, it’s like Rust and
Electron, I think.
00:51:34 - Speaker 1: I was going to give them as an example of a good
native app earlier.
00:51:37 - Speaker 2: Exactly, so the Twitter discussions that followed
were essentially, OK, you got this shining example of an indie software
company that has created a lovingly crafted and well designed native app
for many years, you know, there’s many password managers, but one
password is successful largely on the strength of the look and feel and
performance that feels very native and feels very integrated,
particularly with Apple stuff.
And then they essentially raised a big round of venture capital and
immediately thereafter switched their previously native app to these web
technologies and people felt betrayed, or that it was some kind of a
harbinger for the future of native apps generally and maybe Mac
specifically. And they ended up doing a follow-up blog post that I’ll
link in the show notes that was interesting about essentially the
engineering management and business decisions they made that led up to
that, and some of them are just some specific things related to exactly
where the platform APIs are in the moment.
But maybe it does come back to that question of when you’re trying to
serve the widest possible audience, and you’ve got an engineering team
and it’s just a good business decision, even when you’ve got a pretty
big engineering team, you think, can’t you afford folks to build native
apps on all these platforms and actually just makes more sense to have
this unified code base and less to support. So we’ve talked about the
technology side and the cost of building the apps, we’ve talked about
the design and user experience, we talked about the business. Are there
any other aspects of native versus non-native that are notable to touch
on here?
00:53:06 - Speaker 3: Yeah, I feel like one of overlooked aspect is
accessibility. That’s kind of a big victim of non-native apps where
accessibility really depends on system features, right? Like you wanna
be able to set in the system settings what you need and rely on these
features that providers like Apple built across the system and not, you
can’t fine tune these settings for every single app and you can’t.
Rely on every single developer building like a complete suite of
accessibility features. That’s just not going to happen. And so for
that system to work, you kind of need native apps that can support these
native APIs and build with accessibility in mind and non-native apps
just can’t really do that. And there isn’t usually time to build
custom implementations for non-native apps for accessibility.
00:53:55 - Speaker 1: That is an interesting one. I’ve been thinking
about this in the back of my mind because the type of non-native
technology that I’m most excited about is the setup where you have a
high performance language that you compile down to a very narrow
runtime, like the rust slashwam style, for example, where you write the
app in a high performance language, it compiles down to what is
basically like a web native binary, and then you can run that wherever
you want.
But there’s only a very thin API between what becomes the application
and the platform, in contrast to the usual thing where there’s like a
whole windowing system and tool kit and widgets and everything that the
platform provides. And yeah, in that world in particular, you implement
your very high performance text editor, but then what people can’t, you
know, highlight the text so they can’t have it spoken to them or
whatever. It’s tough.
One thing I wonder though is, can you separate a little bit the platform
hooks for accessibility from the implementation.
So to take the example of text size, one way to do that is there is a
platform standard text implementation, which I’m sure there is on Mac
and iOS, and if you use that, it automatically scales the text up and
down according to whatever. The user has set in the universal text size
settings, but it could also be that there’s a thing you can call which
is like get current text size, and then in your own implementation of
text you could scale the text accordingly and yes, it’s gonna be harder
and less likely people do it, but it’s still potentially possible,
especially if there are various other libraries and other library
options for UI widgeting. So yeah, it’s tough.
One other question I have is what do games do because games are
typically implemented in this way where you have basically the game
takes over the whole screen and does whatever it wants, including
different ways of rendering texts and so forth. So I kind of wonder what
they do. It’s probably a lot of just don’t support accessibility, but
maybe there’s a fire right there.
00:55:40 - Speaker 2: Yeah, I think it just ends up being a custom
implementation per game, so whether it’s color blind mode, or changing
the text size or different kind of input controls, there’s a good game
maker’s tool kit video, I’ll link to that.
But yeah, essentially it’s all up to the developer, which often means
that smaller indie games just can’t or don’t have the resources to
support that, but of course the AAA games have these massive budgets and
massive teams, is both possible and really in their business interests,
because once you’re going to a wide enough audience, then even a small
percentage of people that have a particular type of color blindness to
pick one example of an accessibility area, that actually represents a
pretty good number of customers for you.
Well, maybe as a closing point, we’ve talked all about the pros and
cons. I think it sounds like we come down personally pretty strongly in
favor of native, but we also see where business wise that might be a
more questionable thing as the world evolves. So I’d love to hear from
each of you and maybe I have my own answer. Why are we making news for
Mac and why not use for the web?
00:56:48 - Speaker 1: Yeah, well, I actually don’t have a very dogmatic
answer to that.
It’s that we had a few key desiderata for the Muse, let’s call it
desktop app, you know, the thing that you’re going to run on your Mac,
and the two main options for implementing that would be a maybe the
three options would be a classic native app, an electron app, and a web
app.
And there’s things like performance, but a huge thing for us was access
to the file system to be able to do a local first work, which basically
eliminates the web option, really you’re left with electron and classic
native and I do think the performance is quite a bit better for a
classic native, and also we have this potential to share a lot of code
between the iOS app and the desktop app, so there was a clear path to
implementing it. So that’s why I would have thought about it.
00:57:31 - Speaker 2: Yeah, for me, the answer is also all about
performance and that also connects to the local first or local data
storage. Again, you can do that with electronic web technologies, but I
feel like it’s more of a reach. The electron app that uses local
storage. It’s a translation layer, that’s kind of all there is to it,
and so trying to make the performance good and use local storage
effectively, not to mention integration with things like drag and drop,
which is really important for me is getting stuff in and out. It’s just
hard for me to picture providing a really great experience there.
00:58:02 - Speaker 1: I’m not an expert on it by any means, but my
sense is that local first data storage and the web in particular is
quite hostile. Like someday someone in Mountain View might have a bad
day and just kick you out of the Chrome cache because whatever you’re
using too much space and then you’re out of luck. I don’t know if
that’s exactly what happens, but my sense is that you cannot count on
the data in a stored in web browser.
00:58:19 - Speaker 2: Yeah, so for me it’s all about fast, and it’s
about local, and you get those things with native, so therefore,
probably make different arguments about the business case, but for what
we want to express in bringing news to the desktop, use for Mac is the
only thing that makes sense. And by the way, answering my own question
there, it’s not that we’re not making use for web. I feel very
strongly we should do that, and that’s for the sharing and
collaboration case because that is where the web excels, but sequencing
that later feels like the right decision to me.
00:58:51 - Speaker 3: Yeah, I feel like that’s the important thing
coming back to playing on the strength of each platform. And for the
Mac, that’s just the native app ecosystem and the connection we already
have with the iPad app. And we’ll be foolish not to use that strength
of the Mac, basically. And then in the future, if we want to build
something more web-oriented, then we’ll surely also play to the
strength of the web.
00:59:15 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at NewAppHQ or via
email, hello at museApp.com, and you can help us out by leaving a review
on Apple Podcasts. We still early with the muse for Mac beta, but I’m
really enjoying this question of how we bring what makes Muse special and
interesting and unique from this other platform onto the Mac, which is a
platform beloved by me and many other creative people, and watching your
work on that, Leonard, as well as our engineers working on what exactly
will be the same and what will be different has been really interesting.
So looking forward to continuing to watch that evolve.
00:59:57 - Speaker 3: Yeah, me too. I think it’s something we’ve been
kind of working towards for a long time, so it’s been sort of in the
back of our minds, so you might look on the Mac, but yeah, it’s an
entirely different beast to actually like get into the weeds and really
figure out the design details of the Mac app.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: We both really, really like writing and are good
at it, and care a lot about the written quality of the product, and we
both also have this product DNA where we’ve built software products
before, and we know how that works, and we’re trying to figure out if
you put those two things together, what can you make?
00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad. This podcast isn’t about Muse the product, it’s about
Muse the company and the small team behind it. I’m Adam Wiggins here
today with Mark McGranaghan. Hey, Adam. Joined by our guest, Dan Shipper
of every.
00:00:40 - Speaker 1: Thank you. Thanks for having me.
00:00:41 - Speaker 2: And Dan, I know you like me are quite a reader,
reading anything good these days?
00:00:47 - Speaker 1: I am. I’ve been actually reading a lot. I also
just have to say, like, the way that you do that intro, it feels so
calming. I feel like I’m in good hands. I wanna like slow down and just
bask in it a little bit.
Perfect. Yeah, but what am I reading? I just finished this book by John
Green, who I love called The Anthropocene Reviewed, and John Green, he
typically writes novels. I know him for his novels. He’s written a
couple books called like A Fault in Our Stars, another book called
Turtles All the Way Down, which have been really impactful for me, and
this is the first series of his essays that I’ve read.
It’s basically a collection of essays. And the conceit is that in the
Anthropocene, which is the era that we’re in right now, which is the
era in which humans are affecting the environment. One of the central
things that we do is we give reviews to everything. If you go on Google
Maps or Yelp or whatever, everything in our world has like a review that
boils everything down to between 1 and 5 stars.
00:01:43 - Speaker 2: Yeah, I always find it funny when you look up
something like, I don’t know, the Atlantic Ocean or like an abandoned
power plant or something like that, and there’ll be reviews in there,
which are often hilarious to read, but yeah.
00:01:57 - Speaker 1: Yeah, it’s really funny. He opens it up by saying
that he noticed that someone had given a park bench, like a 5 star
review, and it’s like, what is that? What is that about? Why do we do
that? And so the conceit of it is every essay in it is a review that
boils everything down to between 1 and 5 stars of lots of things like
sunsets or sycamore trees or bacteria or every single topic at the end
of it, he’s like, I give sunsets 5 stars, and then every time he does
it, it’s hilarious, but it says something I think really interesting
and I just tore through it in like 2 days. It was really good.
00:02:30 - Speaker 2: Yeah, for sure. I feel like he’s got quite a
personality as a podcaster. I think YouTube was even maybe where he got
started, kind of classic blogger, but yeah, great observations on the
world, but also, yeah, very poignant observations, but also just really
funny, really entertaining, and so that makes it, yeah, easy to read.
I am at the point in my life actually, where there are many great books
that have had a big impact on my life that are kind of a slog. But with
being a busy parent and business owner and whatever else, I really
appreciate something that’s just easy to read. It’s fun, it’s written
in a way that it just flows smoothly and you can both get those great
insights and widening of perspective, that is the reason why we consume
media, especially things like long form books, but in a way that maybe
it’s a little less costly in terms of your own personal activation
energy.
00:03:22 - Speaker 1: I totally, totally agree. Like, there’s all those
books where you’re like, I should really read this and I should really
like it, but I’m just feel like I’m kind of out of gas, like, I don’t
have the mental energy to do it, and then there are other books where
you just kind of tear through it.
I just went through this whole series of books. I basically went through
the ouvre of this guy Irv Yum, who’s like a psychiatrist, and he
writes, basically what I would term therapy fan fiction.
And it’s so good.
I read like 5 books in like 3 days and I just could not stop reading it,
and I just like finding those things sometimes as a refresher to all the
heavy stuff that we end up thinking about and reading day to day.
00:04:00 - Speaker 2: Absolutely. Well, tell me a little bit about your
background. You kind of come from maybe a more classic Silicon Valley
tech entrepreneur background, but then you had this journey of being
early as a kind of substack paid newsletter, and now you’ve got your
business every, which is very interesting, kind of modern internet media
business, writers collective has some elements of some of the small
giants, the business stuff we talk about here, but yeah, tell us the
journey that brought you here.
00:04:28 - Speaker 1: The journey that brought me here, so my background
basically started in software, really in technology and software. I
started programming when I was in middle school.
I read a Bill Gates biography and decided I wanted to start a Microsoft
competitor, so I learned Basic, and I was going to build a Microsoft
competitor called Megasoft, and Didn’t actually end up ever writing an
operating system, although I really wanted to, but just fell really in
love with that whole thing because I was super interested in business,
and the only way to really start a business when you’re in middle
school, is to be able to program cause that’s the only way that you can
start a business where the only cost is your time.
So, built a lot of apps, started with apps for BlackBerry in high
school.
And then the iPhone came out and I started building iPhone apps.
That’s kind of how I paid for gas and food in high school, and then in
college, finally met people that were also programmers and were also
into like starting companies and stuff like that, and started my first
company, it’s called Firefly.
And there was an enterprise software company we built co-browsing, which
is kind of like screen sharing, but all of that happens in a web
browser, and we applied it to customer service, so built that for
several years, primarily bootstrapped, so you’ll notice like a thread
in my life is kind of this whole bootstrapping type mentality, and then
sold it to Pega, which is this big public enterprise software company,
right as I was coming out of school, and that was really, really good
experience.
I learned a lot about building a business. I ran the firefly business
inside of Pega for a little while, and then I spent the next couple of
years just like trying to figure out what I wanted to do with my life.
00:06:06 - Speaker 2: And I think this may have been the point where we
met and I think what you described to me at the time and you had just
started the super organizers newsletter and you were starting to
interview people.
Correct me if I’m wrong on this, but what I remember is you’d reached
out to me and said, you know, hey, can we chat? I’m working on this
kind of interview newsletter and the way you described it was, well, you
didn’t exactly know what was next, but you figured talking to lots of
really Interesting, accomplished, productive people might lead you to
that somehow, and it really resonated with me because I was working on
ink and Switch at the time, which in some ways had a similar origin
after my sort of big career success in the form of Furoku and that
ending and me trying to figure out what was next.
Starting a research lab was a way. To kind of maximize my optionality,
stay in divergent mode, not pick a thing to work on, basically, and
eventually that did turn into something that was pretty focused around
some specific goals, but at least in the beginning, the point was to do
a thing that was incredibly exploratory and didn’t like tie me down to
one very specific path.
00:07:10 - Speaker 1: Yeah, totally. And I definitely did that and the
newsletter that I started Super Organizers was part of that.
I think like, I went through this phase where I was writing a novel,
which I wrote like 4 drafts of.
I did tons and tons of other like little software projects and worked
with a bunch of different people and had a bunch of different ideas that
I was excited about.
And eventually, I started this newsletter called Super organizers, cause
I realized that I was just super interested in productivity and note
taking.
I’d had a bunch of ideas.
In the, I would say like tools for thought space for a long time, kind
of stemming from my first company where I just felt like I was this
information processing machine, but my tools for processing information
were like not great, and I was really interested in building software to
like make that better.
So when we talked to you, I basically started super organizers and the
conceit for me, the reason for starting it was I wanted to build a
productivity software company.
But I didn’t exactly know 100% what I wanted to build, so I decided,
hey, I’ll start a newsletter. I’ll interview like really smart,
interesting people about how they think about their own productivity
systems, and I’ll use that to inform the product I make.
I’ll write the interviews up and get an audience, but like the real
idea is it’s a way for me to do customer interviews with smart people.
And so talk to you, published a bunch of interviews with a bunch of
really, really smart people, and along the way, I just actually decided
or found that people loved the newsletter, and loved the writing, and I
could build a business with it, and that was very exciting to me and not
something that I’d really considered before. So it kind of put me on
this path of like, how would I do this as a business instead of like
actually just going and building software cause I love writing, I love
business, and this is a way to put them together.
00:08:56 - Speaker 2: Another interesting thing here, I feel like is the
timing that sort of email newsletters were on the rise, maybe as kind of
a replacement for blogs, RSS. I’m not sure exactly. Substacks obviously
a big part of the story. You were early there and sort of the concept of
paying a subscription for an email newsletter was something that I feel
like kind of came out of nowhere, but then suddenly was getting a lot of
traction and you were, I felt like very much in the right place at the
right time to take advantage of that.
00:09:26 - Speaker 1: Yeah, it was a really, really interesting time. It
was that wave about a year and a half ago where this started to really
pick up that I was running super organizers and starting to think about
this as like a business, and at the time I didn’t really understand
that it was becoming this like trend, and it was kind of at that time
that I started talking to my co-founder Nathan Behez.
We’ve been friends for a long time, and we just both, at the time he
was the first employee at Substack, so he was really feeling it and
like, had been on this train for a long time and kind of knew that this
was coming, I think in a lot of ways, and we started talking together at
the time he was no longer at Substack.
And we started talking about what could we build together, what we do
together, and what that turned into is us kind of thinking about what
would it look like to build a media company in this kind of environment
where solo paid newsletters are becoming a thing, lots of writers are
leaving their publications to do it on their own, and there’s a lot of
benefits to that, but there’s also a lot of drawbacks, both for writers
and for readers, that I think People maybe aren’t as sensitive to right
now, but will become more and more important over time.
And so we started thinking about how do we build a publication or a
media company under this kind of environment, and we knew we wanted to
build something that had a group of writers that was covering topics
that we’re most interested in, which is basically topics in tech,
topics that are about business, but that, you know, when you read them,
you’re both entertained and you kind of feel like you’re getting
something out of it. I would put this podcast in that kind of category
too, where you feel like you’re getting something that is going to help
you think better, make better decisions, be better at your job in some
way. So we’re kind of like toying around with what is that kind of a
media company look like? How do you build that? and how do you build the
supply of writers and create incentives for them to all be in one place
when there’s so much incentives to be on your own, especially if
you’re someone that can write well enough to do that. And so, that’s
where we started to come up with this idea for a writer collective,
which I can explain, and start on this journey of like taking all these
individual writers who could really write on their own in this
environment and figure out how do we actually write together because in
a lot of ways that’s better.
00:11:34 - Speaker 2: Well, that brings us really nicely to our topic
today, which is, let’s say, building a media empire in the internet
age, or just simply creating a media brand, an internet era media
brand.
And I think one of the things that was maybe eye-opening for me,
watching your journey on this was thinking about what I would call
classic media brands, I guess that’s the way to put it. Something like
magazines and newspapers like The Economist is one that comes to mind,
or The New York Times, maybe if you go more to entertainment, you have
something like Disney, there’s one that I’ve read quite a bit about
just because, yeah, Walt Disney is a really interesting entrepreneur and
everything that’s been created there and how that company has evolved
over time, is also really interesting.
But I remember you telling me a bit about some of these what I would now
call I guess like internet native media brands, and that’s something
like Vox, for example, or Vice. So both of these to me are very
evocative of like I know instantly what their voice is and what their
kind of view on the world is, but they’re not one single media, right?
Like you know, the Economist is a magazine. And so it’s writing, and
that’s pretty much it. And then they have, I don’t know, data
visualizations and things, but Vox, well, they have articles on their
website, but they also have a bunch of podcasts, and then they have some
YouTube videos, but they also have like a Netflix series and there’s
definitely something that unites all of them, but at the same time they
feel different to me in some ways from these more classic brands.
And then you’re on this journey of bringing your perspective as a
software entrepreneur, I don’t know, maybe it’s a software is eating
the world kind of thing to, OK, how does the internet change media and
especially if you’re doing it more at this indie level and yeah, as you
said, like, how writers and publications and stuff even gets distributed
to people, all of that is changing, which maybe creates confusion. It’s
hurting some of these existing classic publications, and people have
talked about the death of journalism and that sort of thing, but that it
also creates new opportunities.
00:13:35 - Speaker 1: Yeah, totally. There’s a lot in there, there’s a
lot to unpack.
I think on the kind of like traditional media side, the way it has
worked for a long time is, yeah, you have an editor at the top that is
kind of assigning stories, is responsible for the voice and the vision
of the publication, and writers kind of like slot into that more or
less, and the publication is.
Well, for, they pay you a salary, they give you an editor, they give you
kind of like support, you kind of know what to expect. And a lot of
cases, they don’t even give you a salary now because it’s too
expensive, but like they give you some money and the publication’s job
is to go figure out how to get distribution.
Sometimes it’s like magazine stands. Now it’s on the internet.
And if they get more distribution and then can sell a lot of ads or can
sell more subscriptions, the writer doesn’t get paid more necessarily.
And so they kind of like make the difference there.
And I think for a lot of those non-internet native publications, it’s
been a difficult transition to the internet because the style of writing
is not really native to what gets shared on the internet, like a
headline. In The Economist is usually not something that people are
gonna want to like click on on Twitter, but it makes a lot of sense in
the context of the Economist, where you’ve already bought this thing
and you’re kind of like going through the full piece of content and you
kind of like reserve time versus like, you’re just seeing something in
the stream of information and you kind of like click it, cause it feels
really worth your time like right now, it gives you that little dopamine
hit.
00:14:58 - Speaker 2: And I think the bad version of that or the
immediate interpretation of this is not a good thing. We might have
talked about this a little bit with Tobias back in our social media
episode, but sort of in some ways the clickbait headlines of the
internet era are all throwback to kind of yellow journalism where
because every newspaper was sold on the street corner and there’s just
some kids saying.
Extra, extra, read about, you know, war declared and blah blah blah, and
they’re just very incentivized to have these flashy headlines that
would often just be completely false. And the subscription model where
you essentially buy a year’s worth of whatever newspaper it is that’s
delivered to your door, they’ve already got your money, they’ve
already got your attention. So now it’s more about this long term value
building trust and giving you really good and useful information, they
don’t need to catch your attention with flashy headlines.
00:15:48 - Speaker 1: Right, totally. I think your history there is
really good, and I think that’s what the internet native brands that we
know have figured out how to do is they have writers and editors that
have grown up with the internet and know what is going to catch
people’s eye. And so the way that they have built their brands is to
try To amass large audiences, usually by getting them from existing big
social platforms like Facebook or Twitter, and then still advertising
against those audiences and they’re trying to get as big and serve as
many people as possible, and it has worked, it hasn’t worked like as
well as I think a lot of investors hoped when they first invested in
them in like 2012 or 2013 or 2010 because These brands are still really
subject to platforms, and when Facebook changes its algorithm, a lot of
them have had a lot of trouble, and they’re still around, like Fox and
BuzzFeed and all those companies are still around, and I think they’re
probably going public soon, but it’s been a really tough road,
basically.
And I think that you’re right, people are feeling like a lot of those
brands ended up. Doing things that are more clickbait, and so you end up
losing trust in them and you don’t feel like maybe they’re doing as
high quality stuff as you want, and I think that has been one of the
reasons why we transitioned to subscription media is people feel like
they’re developing a relationship with a specific writer that they
like, that is not feeding them just kind of garbage that they have to
write in order to get them to pay attention and get the algorithms to
put it in front of them. And I think that’s a really interesting move.
I don’t think it at all solves the problem. I think you can still be
kind of outrageous and not fact-based as a subscription writer, but it
solves some of the problem for sure. If we write something
controversial, it definitely still gets views and we can convert those
views into subscribers. You still have to think about top of funnel if
you’re a subscription writer, you do.
00:17:39 - Speaker 2: How do you find this as a business owner where you
know you need to sort of justify your existence and make sure you can
keep the lights on and everything like that? Do you find yourself
compelled towards kind of the controversy, clickbait titles just a
little bit? I mean, I don’t think you’re very much in that vein, but
do you find yourself with the mental debate of we could title this this
way, and I think that would get a bunch of like outrage posts, and I
know that that’s worth $10 to me because I know how that converts,
right?
00:18:09 - Speaker 1: Sometimes, I think for us, I’m pretty probably
afraid of controversy.
I don’t really like outrage, so I’m not tempted to. I think some other
people that I work with are a little bit less afraid of that and are a
little bit more tempted to do it, but I think that there are definitely
incentives around what kinds of topics we cover, what we think people
will pay for, and those are not necessarily the same as what we think we
should cover in every single case, and like a really, really easy
example is We know if we cover crypto, people are gonna read it and
probably buy it. It’s the most interesting thing that is happening
right now to most people, and it’s just hard to find writers, and I
think we have them, which is really great, but it is actually kind of
hard to find writers that cover crypto in a way that feels actually
balanced and responsible.
And if we just found someone who was more of like a crypto, just a pro
crypto, like all the way person, like really, really breathless, I think
we would get a lot of readers and subscribers. We just would. It would
sacrifice our brand and it wouldn’t be the thing that we want or care
about, but it would work pretty well.
And so I think that the trap that it’s easy to get sucked into is
thinking about what is everybody else covering that’s in the ecosystem
at our level of the value chain, what is everyone else covering. And why
aren’t we doing more of what’s working for other people? And that’s a
really quick way to just kind of court disaster, because you can never
do anything actually interesting or that actually moves the conversation
to a new place, if you’re just trying to figure out what everyone else
at your level of the information value chain is. Chasing trends. So we
try not to get sucked into that, but business incentives wise, it can
feel like the local incentives are to do more of that. Hm.
00:19:56 - Speaker 2: And maybe we can talk about the writers collective
part of things. You entered that a little earlier, so we talked about
the sort of the sub stack thing, the paid newsletters. Something I like
a lot about this overlaps really well with what we’re doing with the
muse business, which is this kind of indie thing, which is if there’s a
smaller team, especially.
One person, obviously it’s one writer, but even if it’s just a few,
where you feel a very kind of personal relationship to them, you know,
their personality and style, and it feels like a much more human
transaction somehow you want to support this one person or a small set
of people than sort of the big faceless corporate monolith.
And so that’s part of what SubStack potentially offers when you see
some of these writers go off and go indie. I know I like this one
writer. I like their take on the world, and I want to support them, and
therefore it sort of has a farmer’s market vibe a little bit there, but
obviously there’s many downsides to kind of being independent like
that. How do you see the writers collective as fitting into that
equation?
00:21:00 - Speaker 1: So what a writer collective is, or the way that we
defined it is we’re trying to be for writers somewhere between having
your own sub stack and working at a big media company.
So on the big media company side of things, what we try to provide for
writers are things like distribution to an audience, so you’re not just
fending for yourself, trying to get views on Twitter, you have an
organization that’s going to put your stuff out to readers and find
readers for you.
We give you an editor, so you’re not just kind of alone trying to turn
out as much content as you possibly can. There’s someone there who can
help you think about the sentences and the ideas. You have a group of
other writers, so it’s not all on your shoulders, you know, Ben
Thompson writes 4 days a week and it’s all him, it’s not all you in
this model.
00:21:41 - Speaker 2: Yeah, interesting there, Ben Thompson, I think is
also sort of a prototype or an archetype in this. He writes tracheri. I
know I’ve linked to their articles a number of times in our show notes.
He’s been doing this quite a while, but yeah, kind of independent
business, charges money directly through his own website, and yeah,
apparently it’s just able. To continue producing really good content
essentially every day and has done so for I don’t know what, better
part of a decade or something like that. That’s obviously a pretty
remarkable case, but it has shown, I think he served as a role model for
a lot of the modern email or kind of independent writer, independent
subscription paid writers.
00:22:18 - Speaker 1: Right, totally. And so what we want to do is give
people those benefits that Ben Thompson doesn’t really have access to,
and give them a lot of the benefits that they get if they write their
own substacks.
So we want to give them more of an ability to write stuff that is their
own voice and vision, not something that they have to conform.
Like if you write for the economist, you have to write in the economist
style. We want to be less like that.
There’s obviously always a spectrum, but we want to be more allowing
people to do the thing that’s most interesting to them in their own
voice, cause that’s what we think the best writing is.
And then we want to share upside, so we want to measure who is
subscribing to the collective for a particular writer and pay that
writer, we pay writers 50% of the profit from each reader that is
subscribed for them. So writers don’t have to ask for a raise.
If they’re writing good stuff that’s attracting readers or obtaining
readers, they get paid more. And then we also want to give writers the
list of emails.
What we believe is because we’re in this world where readers primarily
subscribe to publication for the voices of the people that they most
like, that when a writer develops a relationship with a reader, they
should be able to contact that reader, even if they leave, and we’re
not interested in retaining writers by holding their audience hostage.
And we think this kind of a deal where writers get upside and maintain
access to their readers is more reflective of the reality of who is
driving value for publications in the internet age, and is the kind of
deal that we think more publications will do or have to do over time.
So that’s the basics of a writer collective and I think it comes back
to this thing that you mentioned earlier, which is this realization that
we had that most people 50 years ago were thinking about reading The
Economist.
But today they’re more thinking, I really like Matt Levine, or I really
like Ben Thompson.
So if you want to create a publication where you have multiple writers
together, which is what we want to do because we actually do think that
that’s better for a lot of reasons, which I can explain, you have to
both market it to readers as being voice first. It’s like, here are the
voices that you’re going to get when you subscribe and you’re gonna
like those people, but you also have to compensate the writers as if
they’re the ones driving the value, which they are. And so that means
sharing upside and sharing emails.
00:24:26 - Speaker 3: Yeah, it’s really cool to see that you’re
actively exploring different approaches here.
We’ve had this incredibly important change with communication and media
that’s ultimately gonna have massive impacts in terms of how we
organize ourselves as wild as it seems, we’re still in the very early
stages of that.
But anyways, when that first hit, of course, the first thing that we
tried to do was transliterate the old world onto the digital world.
So we took a magazine and Put like www in front of it and said, oh,
we’re an online magazine now, right? And you know, that’s a very
common pattern, but now we’re in the more interesting phase of
exploring what you can do with the new affordances that you have with
digital mediums.
And so things like direct subscriber relationships and smaller writer
collectives and different platforms that support those in different ways
with substack and Ghost and whatever, and uh just a very interesting
time.
00:25:11 - Speaker 1: Yeah, I feel really lucky to be a part of it.
It’s something that I kind of stumbled into, but it’s such an
interesting amalgamation of my own interests and such an interesting
time in history to be figuring it out. And obviously we don’t have all
the answers, but it’s really fun to get to think about.
00:25:29 - Speaker 3: And I think it’s interesting to think about what
are some of the underlying reasons why we’re getting pulled towards
these other solutions that are not called the online magazine
transliteration, and we’ve talked about some of them here, like one is
You can have a much broader variety of voices just because you’re in
these long tails and you don’t need to funnel everything through one of
a small number of oligopoly media publications, right? But also you can
have that long tail effect also applies to like the subject area and
even the balance of the opinion, you know, whether that’s political
opinion or whatever.
Another thing I think that’s happening and that we’re starting to see
with this little bit of tension call up between the legacy platforms and
The newer smaller outlets and even individuals is there’s a little bit
of kind of escape and routing around institutional dysfunctions in the
larger legacy publications. And I don’t have a fully developed theory
of what’s happening here, but I think it’s something like these older
public like take like the New York Times or The Washington Post,
they’ve built up an incredible amount of capital through tens or
hundreds of years of in many cases, quite good journalistic work. And
now I think there’s a constant temptation if you’re an individual at
one of those firm.
Terms to basically draw down the capital for your own benefit or for the
benefit of whatever your pet cause might be, that might be you basically
take advantage of the masthead to like write some wild opinion piece
that doesn’t make any sense, you know, for example. And it feels like
it’s become so compelling to do that and people have developed
basically better strategies for doing that, that I think basically
we’re seeing that happening and indeed, if you look at the Just
broad-based opinion polling in the US, these legacy media publications
will be at almost the very bottom, right? I think that reflects this
capital getting drawn down.
And meanwhile, the individuals, the entrepreneurial publishers, these
individuals, they see that they could potentially build. For themselves
and write for themselves either as a single individual or as part of a
small collective, and you get more of this builder’s mentality of like,
you’re basically accruing capital, and you’re getting 50% of the
dividends that get paid out because of more readers. And I think that’s
just a powerful dynamic that’s happening right now.
00:27:38 - Speaker 1: Yeah, I haven’t really worked in one of these big
publications before, so it’s a little hard for me to like, comment on
the internal dynamics of why people do the things that they do or how
they maybe kind of draw down the institutional capital or whatever.
It is true that if you’re working at one of these large companies,
it’s easier to hide, right? Like you can write an article that’s like,
OK, and it doesn’t matter as much cause it’s got the New York Times
masthead behind it, whereas if you’re on Substack, if you don’t write
something awesome.
Until you are Ben Thompson, Ben Thompson gonna write lots of bad stuff
and it doesn’t matter, but until you are Ben Thompson, you have to
write good stuff, right? So I think that’s one interesting thing, and
then I think the other part of that is that there are a lot of people
who can hide at those big publications, and then there’s a lot of
people at those big publications that are the ones that are carrying it
today, that are increasing the capital, right? And sometimes they feel
underpaid or undercompensated.
00:28:29 - Speaker 3: Right, and that’s a big piece of this tension
that I was alluding to, right, where basically people are looking, these
individuals are looking at both sides of the fence and saying, hey, wait
a minute, I’m building up all this capital here. I’m not getting paid
and it also seems like it’s getting drawn down by others for nefarious
purposes.
What if I just, you know went over here and, you know, paid myself a
$250 million a year with really nice news on there, right? That’s the
sort of dynamic.
And then The tension is that that reveals a sort of fundamental problem
or issue with the larger firms, organizations, so they’re basically
scrambling to either fix that or address that somehow in their approach.
00:29:00 - Speaker 1: Yeah, totally. I think that. 5 years ago it was
not seen by people as a legitimate thing to like go and start your own
newsletter like that just seemed crazy. And it’s something that writers
over time are learning is something that you can do if you are a certain
kind of writer, and I really underscore if you are a certain kind of
writer, it’s not for every writer, and if the only option was to start
substacks, the world would be like way worse off because the kinds of
writing that you can do on substacks successfully are very specific, and
the kinds of people who can do sub sub stacks are very specific.
But I think the trade-off for those people that do leave is they’re a
losing security, which is really important for a lot of people. Oh yeah,
if you’re a writer and you haven’t really been making a lot of money
in your career and you have a family, like the security of working at a
big company is really important to you. But you’re also really losing
the respect and credibility that comes from being able to say I write
for the New York Times, I write for The New Yorker, and I think a lot of
people in those communities really deeply value that. It’s not
something that they want to just throw away.
When you grow up dreaming of writing for The New Yorker, like, and you
get to do it, it’s like a big deal, and it’s a big deal for more than
just the money.
It’s very similar to growing up wanting to be a movie star, and then
being like, well, I could start a YouTube channel.
I think for a long time, starting a YouTube channel was not acceptable
to people that grew up wanting to be movie stars. I think kids today,
it’s different. I think most kids today are interested in being
internet famous, or interested in being TikTok stars, and being a
Hollywood star is just, it feels old. or just like less like the thing
they want. And I think the same is true of writers. And it’s probably
just taking a little bit longer because like just happened and
YouTube’s been around for a longer period of time. But I think previous
generations of writers wanted to write for big publications. They wanted
to have their books published by large publishers, and that’s a huge
thing in their psyche. And that’s why you get into writing is not for
the money. It’s for this kind of thing. It’s for having a chance to be
in a bookstore and win the Pulitzer Prize or whatever. I think now we
are starting to see generation people where that stuff is a little bit
less valuable to them. They’re more interested in internet native types
of respect, credibility and success. So those institutions are a little
bit less valuable to those people, and that creates an opportunity for
players like us that we feel like we’ve also grown up on the internet
and we can give them something that they want, but also give them kind
of the experience of being part of a collective, which is something that
I think a lot of people value.
00:31:22 - Speaker 3: Yeah, for sure. By the way, this reminds me of one
of my pet peeves, which is you’ve probably seen this like meme or
statistic that in the US, the number one job aspiration for young people
is to be like a YouTube star.
And in China, it’s like to be an astronaut or something. And people
often say that in a way that’s like derogatory to the US or as if it
reflects badly on the US.
But the way I always saw that is people in the US. to run their own
small businesses and control their own destiny and make their own way in
the world. And it’s obviously lots of good things about aspiring to be
an astronaut, right? But it does have this element of like, you got to
be one of the three people that the government picks every decade,
versus having a shot to make it on your own. Right. So, to kind of
reflect your point, I think there’s a lot to be said about having the
desire and the initiative to strike out on your own, whether that’s to
run a traditional small business or the sort of emerging class of small
businesses with online media.
00:32:12 - Speaker 1: Yeah, it’s so easy to just be the kids these days
meme, like kids are so shallow and whatever, and I would rather just be
actually interested in what does that mean to people to be YouTube stars
and how is that actually probably similar to other things that have
happened in the past and what are the good things and the bad things
about it and not just like, oh, yeah, everyone’s just terrible and
shallow and. Losing so much to China because they want to be astronauts.
It doesn’t mean anything to me.
00:32:35 - Speaker 3: We could probably do a whole episode about this,
but there’s this fascinating, it’s actually a big and serious business
to be a major YouTube personalities. People like they have multi-channel
media empires, they have staffs with organizational hierarchies. They
have like these huge discords. They have all kinds of payments going in
and out. It’s no joke of a business. I think people sometimes forget
that.
00:32:54 - Speaker 1: Totally. I mean, It’s really hard when, and this
is one of the big things that we try to address for writers is, if your
business is about you, then every single moment that you’re not making
content is a moment you’re missing out on money, and it’s really easy
to burn out that way because you have to be on 24/7.
If you’re a YouTube star, you haven’t got to produce a video a week at
least. A lot of them produce more than that.
Casey Neistat, a vlogger, famously vlogged every single day for like 2
years, 7 days a week, while having kids. Like that is crazy.
And these vlogs are like edited. They’re not just like 10 minutes of
staring in front of a camera, it’s like highly edited 10 minutes of his
day told in the story format.
It’s crazy, but the same thing is true of writers, like, the fact that
Ben Thompson every single day, 4 days a week for years, has to have an
opinion. That’s hard. It’s really, really, really hard.
And I think that there’s a generation of people who are starting to do
that. And in 2 years, a lot of them will be like, fuck, I want to do
this once a week, not 4 times a week. How can I do that?
00:33:59 - Speaker 3: Yeah, totally, which brings us right back to the
importance of experimenting with these new platform technologies,
whether that’s, you know, collectives, I think is going to be an
important one. Also different recommendation algorithms can kind of
address this by basically helping out people who make good content, but
like take a month off, the algorithm can bring you right back and not
kill your business. So yeah, much more to explore in this space.
00:34:21 - Speaker 1: Yeah, I think the weird thing is that the
algorithms right now are not built that way for creators. They’re not
built with creators like mental health in mind. They actually just
penalize you if you go away for a while so that you don’t go away. And
a lot of creators just end up feeling terrible. And I hope that that is
fixed over time. It is within the power of these platforms to do it.
It’s not clear yet that they really care.
00:34:43 - Speaker 3: Yeah, or, you know, be the change you want to see
in the world and start your own media company where you have different
incentives.
00:34:48 - Speaker 1: I mean, that’s what we’re trying. That’s what
we’re trying. We’ll let you know how it goes in a couple of years,
you’ll have to have us back.
00:34:53 - Speaker 2: And the algorithmic recommendations, and I think
that touches also on something you spoke about earlier, Dan, with the
audience ownership, the email basically that your writers get the email
list, and I think Substack also and maybe newsletters in general, I
think part of why they emerged in that moment in time was a sort of Push
back to these platforms and their algorithms that decide what you see
and people realize that, OK, someone following me on Facebook, following
me on Twitter, subscribing to me on YouTube.
I think YouTubers in particular, there was a lot of outcry and concern
over algorithmic changes where someone can subscribe to your channel,
but they still actually don’t even know that you put out. a new video,
because the algorithm doesn’t decide to recommend it.
And they have this bell where you can get notified. And in any case, I
saw a lot of YouTubers basically decide, OK, we can’t have our fate be
decided totally by this platform.
I need to collect my own email list so that I can let people know when I
have a new video, so people that really want to follow me and I can
build my own audience and own that separately from this larger
organization, this larger company that decides where to take a platform
may decide in the future, and I think that’s a lot of where the
substack thing came from. OK, here’s still a platform that can help you
with, you know, the software and the distribution and the monetization,
but in the end, if you’ve got an email address for every person in your
audience, that’s extremely portable and you’re trying to do that with
as well.
00:36:22 - Speaker 1: Right, totally, and I think that one part of the
problem is, even if you are a YouTuber that can ask for emails, your
conversion rate from a video to an email is like pretty low.
It’s a pretty leaky funnel.
You have to go type in something into the URL bar and like put an email
and that’s not great.
And 2, I think that platforms that are already established and have
huge, huge distribution like YouTube, just like. have very little
incentive to add the ability to go off platform right now, but I think
that younger platforms that understand this dynamic better, so subst is
one, I think we are kind of like in between a platform and a publisher
in a lot of ways, but we are another where we’re thinking about this
from the beginning, are going to be a lot more friendly about that and
give creators that option, and I think that these kinds of platforms
will end up being dominant over time.
We’ll see, but I think it’s the kind of deal that incentivizes
creators to use you in a way that they might not use a legacy platform
for fear of not really having any ability to access their audience aside
from what you allow them to.
00:37:31 - Speaker 2: The positive side of the algorithms for a person
who’s consuming media, whether it’s video, writing something else,
finding new stuff that you wouldn’t have come across before.
This is the classic long tail article, I think from the early 2000s
where they talked about, OK, the internet is going to allow us because
we don’t have this limited number of channels or this limited number of
places to discover content.
And therefore, what’s on your television channels when you don’t have
that many of them, it has to appeal to a very wide audience. There’s
just no space for niche stuff.
Maybe cable helped out a little bit, but with the internet, yeah, you
can have infinitely long tail and furthermore, you could find it through
algorithmic recommendations through a Spotify recommendation or an
Amazon product recommendation.
Or whatever, you start with something pretty mainstream and then based
on those likes, you can in pretty small number of hops get something
much more niche and in theory, that’s really good for small creators.
00:38:27 - Speaker 1: Totally, I think part of the problem for small
creators right now is that if you monetize with ads and you’re writing
niche stuff, you don’t make a lot of money, and so a lot of creators
are starting to use subscriptions, and that’s kind of what we overall
want to be able to do is You have a bunch of creators who are writing on
little niche topics that are all bundled together under one subscription
price, so those creators can basically make a subscription, be part of a
larger collective, and we can be in the middle kind of directing traffic
from readers to the writers that they should be reading.
But within a sort of walled garden where not everyone can write on here,
it’s like there’s a certain bar for quality and a certain tone that we
want to meet, and then within that we are kind of making connections
between writers and readers and distributing the subscription to the
writer that is driving most of the reader attention.
00:39:17 - Speaker 2: So you’ve curated the writers, the topics, there
is a kind of, if not a unifying brand voice, then at least maybe a
general vibe that cuts across it, unlike a YouTube or a Facebook or a
Twitter, that’s just wild west, anyone can post anything. But at the
same time, you could potentially. This is where your background as a
software entrepreneur and just the affordance of the new tools, unlike
those traditional media, you know, the newspaper that’s delivered to
your front door, you can send someone an email that is, here’s things
that you will like based on your past interests the same way that
Spotify does.
00:39:54 - Speaker 1: Exactly, and this is something that my co-founder
Nathan, who first employed Substack, he basically built our entire CMS
almost by himself.
We also have a couple developers who are really talented, but it’s
really a lot of him, and I think this is one of the things that he is
most excited about and pushes deeply is that we have this like, I think
one of the things that we have that I will say is rare, which you tell
me if it’s rare, is we both really, really like writing and are good at
it, and care a lot about the written quality of the product in a way
that I think is similar to a lot of the like. I don’t think we’re as
good as the New Yorker or Harvard Business Review, but it’s similar to
the attitudes that a lot of those people have, the reference that they
have for writing, and we both also, and Nathan really primarily leads
the way here, but we both also have this like product DNA where we’ve
built software products before, and we know how that works, and we’re
trying to figure out if you put those two things together, what can you
make? And we have a bunch of ideas for what can come out of that, but we
think that that’s somewhat unique in the kind of media landscape.
Usually you’re one or the other. You’re either like a product person
that is like trying to build some sort of aggregator or platform and you
don’t really have too many opinions about the writing, or you’re a
writing person and you’re just kind of like, I use a WordPress, you
know, and if you can be kind of in the middle and have both, like what
can you do? And that’s the animating force behind every.
00:41:15 - Speaker 2: Yeah, that’s really interesting and I agree that
that is part of what makes your team unique. And I do wonder how you
balance those, which is, I think curating great writers, providing those
editorial services, really caring about the content. is one whole huge
job, and then there’s what I would call the software business side of
it, a lot of which is just, yeah, you built your own CMS so that means,
you know, you got to spend time on, does it work in this browser.
What about this responsive design thing, oh this person’s having
trouble logging in because of this, that and the other thing, the
payments. You know, all that stuff.
So do you find that you’re sort of pulled in two directions, or do you
have a good way that you even think about how to allocate like your own
time, but also your team time? Do you think, OK, we got to put 70% into
the writing and the curation of the great content because that’s what
it’s about 30% of the software, or how do you find the balance there?
00:42:11 - Speaker 1: Yeah, it can be hard, and I would say most of the
burden is on my co-founder Nathan, but I think first of all, at the
heart, we know that the business survives or dies based on the writing.
It’s not based on the technology. The technology is going to help the
writing reach the right audience and it will be a multiplier on the
quality of the writing, but like if the writing is a zero, the
technology can’t do anything to fix that. So, the heart of it has to be
the writing, we have to get that working and get people excited about
the things that we’re writing and then on top of that, the technology
is the thing that can help us, you know, if we want to, for example,
have a bunch of overlapping niche audiences that we’re serving. It can
help us figure out, OK, who should see which article. It can help us
figure out, OK, who should get paid based on this reader’s behavior or
the survey that this reader filled out, like, there’s all these
mechanics of the business that the technology can help make smooth and
work better and especially scale better as we get bigger, but the heart
of it still has to be that really high quality writing.
And I think it gets back to this thing that you mentioned earlier, which
is that we’re not totally bootstrapped. We’ve raised some money, but
we haven’t raised so much money that we can just like hire a gigantic
engineering team and like not have to worry about it. Like, we are
constantly thinking about, we have a small team. We have technology to
build and writing to produce, and we’re constantly thinking about what
should we do and where should we focus our resources, and that can seem
painful, but I think it’s more like the kind of pain that you get
working out at the gym versus like the kind of pain that’s gonna like
really end up holding you back, because When I think of venture money,
especially for business like ours, like a media business, it’s a little
bit like an anti-gravity machine, and if you’re in the anti-gravity
machine for too long, your bones get weak, and it’s much better for us
right now while we’re still kind of figuring out the model to have some
gravity. We don’t want full gravity, we’re not at like 1G, we’re at
like, you know, 0.8gs or whatever, because we have money in the bank and
we can run experiments and all that kind of stuff we don’t have to be
profitable every single month. But we have enough drag or enough gravity
to deal with that we can’t be stupid for too long, and that is, I
think, really, really important. So we’re kind of constantly figuring
out what’s the balance between these two parts of the business, and we
know what the focus is, and we just got to make sure that we’re
balancing things correctly.
00:44:28 - Speaker 2: That’s really well said, Mark and I in many
episodes and many different forums have talked about venture money and
yeah, the Silicon Valley Standard Model and some of our pushback to
that, which is why we’re doing something a little different with Muse,
but also part of the reason it’s a reference point is that it is this
incredible thing to get a bunch of money to work on an interesting
problem space, especially in an emerging domain where there’s so many
unknowns, you just don’t even know what the opportunity is because all
the variables are in play. And so if you’re totally focused on survival
and earning money from customers so that you can keep your lights on
from day one, that can hold you back from being experimental, seeing all
the opportunities, trying weird stuff, but the other extreme which is
having so much money that you don’t really Feel the, it’s called the
discipline of the market, the real world, kind of like peering over your
shoulder and sweating a little bit.
When you see the bank account balance ticking down, then I think you
lose touch and become free floating, ivory tower, as you said, you’re
more likely to do things that are unwise.
So I think there’s a middle ground there. I’m very much in favor of
businesses taking investment. But I also am really in favor of not
taking too much investment, even though that seems like a good thing. So
I actually find myself in when I’m just like having kind of, let’s
call them advisory calls with people, people that come from a really
strong bootstrapping mindset of like, I’ll never take investment. I end
up trying to convince. them know, you should take a little money, but
then people who come from more of a Silicon Valley, or they just see,
oh, great, I can raise 10 million bucks for basically me and my two
friends and our idea, and I go, wait a minute, I think you’re setting
yourself up for failure by doing that, you should take less or try to be
more close to the middle, you might say.
00:46:16 - Speaker 1: Totally, yeah. I mean, it’s been a journey for
me.
My previous company was bootstrapped and I was never like outright
against taking money, but I felt like I wanted to prove a lot before
that seemed like a good idea.
My default is for any business, like don’t take money, basically. My
co-founder Nathan is the opposite. He took money for his last business
and I think his default is to take money for various reasons.
One is just like money and people help you kind of figure out your
business, and then another reason is Being able to participate in the
venture funded entrepreneur community is like a real benefit as much as
bootstrapping is an identity, being a venture backed founder is an
identity, and it’s a little scary to like take yourself out of that if
you’re in it.
I was a little bit more bootstrapper identity, and he was a little bit
more venture funded identity, so we had to kind of like figure out how
do we merge these two things, because there are real things that
bootstrappers feel that are worth taking into account when you’re
thinking about how to build a business and they’re a real thing that
venture funded entrepreneurs think about, and they’re real trade-offs
to each.
And so how do you figure out the middle ground or figure out, not even a
middle ground, but like a smart way to address each of the concerns and
each of the benefits of both paths. And so where we came to was, let’s
raise some money. We’re going to raise some money from A venture fund
and some smart angels who we think are going to be able to help us. So
we raised about 600, 700K led by Bedrock, who’s the main investor in
the athletic, which is a big consumer subscription media company that is
very similar to the kind of business we want to build, so we have and we
raised pretty much of.
So we have smart people on board, we have some money where we can
experiment, but when we raised it, we said very clearly to everyone,
like, this might be the last money that we raise, and we’ll raise it in
a way that if we don’t raise more, it’ll convert into equity. So, you
know, you’ll have a chunk of the business and all that kind of stuff.
So it’ll give us time to figure out what kind of business this is. And
if it is a venture right business, and we do overall believe that this
is going to be a big business, and that’s what we want to achieve, it
just may take longer than the venture timeline allows for. And if it
does end up becoming a venture backed business, we will raise more
money. And if it doesn’t, and we find that it’s not exactly that shape
of business, we still want to have people on board and want to have the
optionality to take that route without it kind of being taken off the
table too early.
And I feel really good about it. Like, I feel really good about having
taken money.
Had never raised money before, so going through a fundraising process
was kind of fun. I’ve been an investor, so I’ve seen it from the other
side. It was very interesting to get to do that and actually kind of
fun, even though it was stressful. And I don’t think it has materially
changed how we think about the business. It has just allowed us to do
more, a little bit more quickly and not have to worry as much. And
we’re still in some gravity. So we’re still finding a shape of the
business that can survive without having to pump more money in every 18
months. And I don’t know what the future holds, but I feel pretty good
about this kind of path for us.
00:49:05 - Speaker 2: Well, before we go, Dan, one thing I’d love to
get your take on is how the changing media landscape here, for me,
there’s these very deep questions about who we trust to help us
interpret and understand the world.
For example, when there’s something in the technology world, there’s
technology news, some big company goes public and I think I want to
understand what this means exactly and who do I go to. Do I go read
Divination, which is Nathan’s newsletter? Do I go read Ben Thompson and
Strachery? Do I go read The Generalist, for example, and this is also
true for political events and every other part of understanding the
world around us and how it’s unfolding.
And you’ve talked about the history, we’ve talked a lot about the
history of these big institutions, the New York Times and whatever, and
where all this kind of trust or what Mark calls capital that accrued to
these long term brands and institutions, the writers then were kind of
cogs in the machine for maybe now we have this more transition to yeah,
individual YouTube personalities, individual writers on substack, people
where I follow this one person and I trust them and their voice.
How’s that gonna evolve, do you think in the coming decade, let’s say?
00:50:17 - Speaker 1: I think that there’s obviously there’s a lot of
issues of trust at the heart of our society.
I don’t know that I have like a answer for like how we begin to trust,
cause it’s not just journalists, as politicians too, it’s like our
socio-political establishment more, that feels like definitely outside
of my pay grade, but I do know that when it comes to business topics,
people feel like They’re less likely to trust Business Week or like
Bloomberg or Entrepreneur magazine to like really tell them what’s
going on, and they’re more likely to trust certain individual voices
that have experience and credibility on a particular topic to help them
understand the world.
And you’re seeing that kind of play out as you mentioned with like
voices like Ben Thompson or Nathan writing divinations where people go
to him because they know his background and experience is relevant to
the topic that they want covered.
And I think the problem with that is being someone like Nathan or being
someone like Ben Thompson, where you’re one individual voice, and you
are the publication in its entirety, is it’s really fucking hard to do
that for years on end. You have to be Willing to grind it out for day
after day after day and constantly be putting yourself out there in a
way that most people are not prepared for, and in a way that like a lot
of topics are not well suited to.
If you’re going to be a person like that, you have to have a specific
beat, there has to be news a lot that you can comment on really quickly.
It’s not particularly good for someone who’s doing a lot of like long
detailed reporting or in-depth thinking about a particular topic. You
basically do all the thinking and put out a couple of those big Essays
like aggregation theory, and then you just continually refer to them
every single time a news event comes out. And so what I think we’ll
we’ll see over time is writers and readers beginning to realize that
there’s a lot of benefits to being attracted to a specific voice, but
there’s also a lot of drawbacks to like, subscribing to like one man or
woman publications.
And what we’ll find is, I think more collectives people emerge where
writers are navigating the trade-offs of being part of a group and also
trying to retain a lot of the things that they got used to or would have
come to expect from writing on the internet, which is like upside and
money and all that kind of stuff, and we’ll we’ll see groups emerge
that are voice focused, so when you subscribe to the publication,
you’re doing it because it has a writer or two that you really, really
like and trust. And the writers are compensated in a way that reflects
that reality. I think you’ll see that in writing, you’ll see that in
other types of content creation like video and audio and all that kind
of stuff is, it is generally better if you can do it to be together
rather than alone. It’s better to share the load. And people are going
to try to find new models for being together that are more reflective of
the new reality of what it means to create stuff on the internet, and
that’s what we’re trying to do. We have one way of thinking about it,
but there’s going to be lots of other people that are going to try to
do it, and I think one will emerge as kind of a new standard over the
next 5 to 10 years.
00:53:24 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at MuseAppHQ or on
email, hello at museapp.com. Really helps us out if you leave a review
on Apple Podcasts. Dan, thanks so much for letting me follow along with
the every journey so far. It’s made me, I think, much more aware or
just interested in what’s happening in the media landscape, which I
think is not only intellectually interesting, but probably important for
our society. So looking forward to seeing the next steps in that story.
00:53:57 - Speaker 1: Thank you, thanks for having me.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: One of the characters is a poet that evokes much
emotion with his work, and one of his fans asks, how do you do it? How
do you come up with these words that are so moving? And he says, well,
the key is the poet has to speak the words that are already in the
person’s heart.
Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This
podcast isn’t about Muse the product, it’s about Muse the company and
the small team behind it.
I’m Adam Wiggins here today with my colleague, Leonard Sursky. Hi. And
Leonard, it’s one of my favorite times of year now that I live in a
place with seasons. When the leaves turn orange and red and fall off the
trees, kind of have that smell of the, I guess it’s the decaying leaves
in the air, little bit of a chill, but it’s not too cold yet, Halloween
and pumpkin carving. How are you enjoying your fall so far?
00:00:55 - Speaker 2: Yeah, I love it. It’s my favorite season, I
think, especially since we both live in a city in Berlin which has a lot
of parks and a lot of forest area. It’s just really great to be able to
go into a forest and enjoy a long walk in that atmosphere.
00:01:09 - Speaker 1: My dog loves it as well. Basically, the leaves on
the ground all over the place, I think, give like plenty of stuff to
kind of sniff through, so it makes dog walks more interesting as well.
00:01:19 - Speaker 2: Even for humans, I feel like the smells in the
autumn are more exciting than in the summer.
00:01:24 - Speaker 1: Absolutely, yeah. Well, I’ve got exciting news.
The Muse team is growing.
I’ll link to our jobs page here. We actually have two positions now.
Longtime listeners of the podcast might remember we talked about our
partnership model all the way back in episode 4.
That’s when we were hiring the 5th member of our team who ended up
being Adam Wulf. That was a good year and a half ago, I think. And it’s
certainly nice, the stability, I think, team dynamic compared to the
kind of fast hiring growth startup environment that I was previously
used to where you just always have new people coming in, you’re
constantly on boarding, group dynamics are constantly changing. We’ve
had this really stable group for a while, which is nice in a lot of
ways, but also it’s really exciting to think of new perspectives and
just fresh faces coming in to to join us. And I guess growing from 5 to
6 or 5 to 7 isn’t such a huge jump, but also it’s a pretty big change
for us, I think.
00:02:17 - Speaker 2: Yeah, it’s a really exciting moment for the
company. So we’re hiring for two positions. One is a local first
engineer and one is actually a design slash storytelling position, and
that’s what we want to talk about today.
00:02:30 - Speaker 1: Yeah, that’s right. It felt like something really
worth digging in on that we landed in this kind of maybe slightly
unusual job description.
Well, I suppose local first engineer is also unique in its own right,
but The designer and storyteller versus other ways we could have titled
this role led me to really reflect on like what is storytelling and why
do we want to call it this for a marketing role or just a designer or
brand designer or something like that, and how does Muse tell its story
today? And what do we think of the unique qualities of a person like
this that could join our team and That’s kind of the whole deal with
this podcast, right, as we take a relatively straightforward thing like
a job listing and then go very philosophical. So, maybe we start there.
Our topic is storytelling, so, Leonard, for you, what does that word
mean?
00:03:19 - Speaker 2: Yeah, I think it’s been an interesting process to
figure that out internally for us as well. You and I have been kind of
filling that role as the storyteller from MS and doing all the marketing
and the design on the marketing side for that. And on one hand, we have
had really great success. I think with telling our story, I think
that’s kind of what we have to do for Muse, since we are a small
company and we don’t have that much budget basically to spend on
advertising and stuff like that. So we kind of have to tell our story
and share our ideas.
And the good thing is for us, for us, we have a lot to say.
We have built the product based on research that you’ve done at I can
Switch for many years. And so there’s actually a story to tell here and
we just need to be able to really tell that story well.
00:04:04 - Speaker 1: Yeah, I think there’s a couple of different
layers of it telling our story as a team, telling the story of the
product, telling the story of how people think and how technology has
helped or hindered that over time. There’s many different dimensions
here, but I think it’s pretty important, the software by itself without
the explanatory elements would be at a minimum hard to understand and
possibly worse, just easy to dismiss if you don’t have that kind of
backstory in context.
And so I found myself just kind of researching this fundamental
question, what actually is storytelling and of course, I think we all
sort of know that stories are fundamental to how humans understand the
world.
That’s how we, for example, share culture or instill moral lessons, how
we bond with each other, entertain, obviously, and everything from
religious and mythological texts, the Bible or fast forward to Something
like modern day superhero movies, those are sort of our modern myths and
those stories are ways that we not just are entertained, but yeah, we
kind of understand the world and what we as society value or don’t
value.
You can even look at something a little less that’s sort of like a
fictional story and something more directly explanatory.
I think like TED Talks, for example, you can make fun of the format and
people do, and maybe they’re sort of annoying sometimes, but in a way,
I think they have been so successful and so far reaching because
they’ve found. a format that on one hand is addressing big meaty
questions about how we improve the world, but they also have kind of a
gather around the campfire vibe. Let me tell you a story that will
enlighten and entertain, but also instill a lesson or at least some
enlightenment. So I think once you start thinking about this, you sort
of see it everywhere.
00:05:50 - Speaker 2: Yeah, I think TED Talks are a great example of a
format that’s made for storytelling or like built around storytelling.
Yeah, I think the most popular TED Talks are all just really, really
great stories and it becomes less about the point that’s being made or
that’s something you could also get elsewhere and less time if you want
to, basically.
But the reason they’re also so popular is because the story is so well
told. And that to me points to the interesting thing about storytelling,
which is that it’s really independent of the specific medium that
we’re talking about. And I think that’s why it’s so difficult or so
unusual to have an actual storytelling job, because most people see
themselves more as craftspeople for one specific medium, right? Like
maybe a, like a video person or you have a writer, or you have someone
that makes music that is a great public speaker. But all of these sort
of have the underlying element of storytelling and you kind of need to
be great at at storytelling in order to be a great artist in your
specific medium.
00:06:49 - Speaker 1: Or in some cases it may even just be a CEO or a
leader or an entrepreneur or product person. So Steve Jobs comes to mind
as probably one of the greatest storytellers, certainly in the tech
industry, but also of our age. Now, folks like to point to that original
introduction of the iPhone video, but also many others of his, even here
now, more than a decade after his death, we’re still sharing. Videos
and other clips that show him, in some cases really specific anecdotes,
but in other cases, he’s introducing a product, he’s framing how to
see the world, and how this product fits into that, and how it serves
user needs. That is storytelling.
00:07:28 - Speaker 2: And I think that’s an often underrated aspect of
that sort of role where we say usually, OK, Apple, you know, they have
great designs, Steve shops had a great sense of taste.
But yeah, I think a lot of it really comes down to storytelling where,
OK, the iPhone can be really nicely crafted and it can be a great
product, but the thing that will make it feel right and will make it
feel like something that people want is actually the story that’s told
around it and the story that the product tells. And I think that’s
something that A lot of people don’t like consciously consider and
often I think it’s sort of naturally like a story builds around it
without the people making it really considering what that is, but I
think it’s really valuable if you do actually sit down and figure out
what kind of story you want to tell.
00:08:13 - Speaker 1: So then if we bring it to the realm of, yeah,
business and yeah, especially tech products, you know, clearly Steve
Jobs or anyone else getting up on stage to announce a product that is
conventionally you would call that marketing, right? You’re marketing
your product. And I think it’s interesting here to kind of compare a
little bit how we see. I think actually originally we had had sort of
two job descriptions here for this role and you’d call it a marketing
designer and I think I’d called it a marketer and storyteller and so
notably there we both were using this term marketing to capture part of
what the role would do and I kind of think that marketing has a bad name
or It’s sort of disrespected, I think compared to all the other
disciplines that go into building a company. Certain product
development, because people think of annoying or bad marketing, you
know, invasive paid media advertisements getting in your way, whatever,
shoving information in your face that you don’t want or demanding you
to do something.
But I do think marketing is a really important function. You can build a
great product, but if no one knows that it exists, or how it fits in
their lives or whether it’s for them. Then it kind of doesn’t matter,
right? People need to be able to find out about it. And I also think
marketing as a discipline has a lot of great tools, which includes, for
example, this concept of the marketing funnel, which we do rely on.
Especially in the early days, we looked at stuff like how many people
convert from essentially downloading and logging into the app for the
first time to kind of making it far enough that maybe they’ve sort of
like figured out what the app is for and call that the onboarding stage.
And we use that to figure out that our onboarding, we tried a bunch of
different things, and basically it wasn’t working. So many people just
didn’t even make it through it because they just couldn’t figure out
what this weird app was about. It’s kind of how we landed on the
onboarding, the you design that we have now that Still plenty of people
get confused and don’t know what the hell this weird app is, but enough
of them make it through to make it work.
So those concepts like the marketing funnel, I think, are really
valuable, and we do use those, and I do think that there’s a
misunderstanding of what marketing really is, in the sense of a
conversation with the market, understanding the market, figuring out how
to explain the product to the right people, all that kind of thing. But
at the same time, it does come with a lot of baggage that maybe it’s
better to kind of leave off and certainly it implies a pretty
transactional or you’d say pragmatic, but sometimes almost crassly
pragmatic, just like try to get people in your funnel and get them all
the way through. With whatever annoying tricks and dark patterns you can
versus the longer term investment and we’re telling a story about the
product, about us, about you and about the world and over time, if you
like that story, you know, maybe that also means the products fit for
you. How do you see marketing that terminology, does it have the same
kind of negative implication for you, or how do you see that connecting
to what we do at Muse with selling our product?
00:11:09 - Speaker 2: Yeah, I feel like we both had a similar
realization during this process of writing the job description that we
were sort of at opposite ends of the spectrum where I was thinking more
from a marketing perspective and you were thinking more from a
storytelling perspective.
And as you said, I think like the realization is that These both kind of
need to come together since they both touch so many different things and
it would be wrong to just think of marketing as, OK, we are doing paid
advertising, we’re doing a website and we’re doing like a few little
banners of local design. And it will also be wrong to just think of
storytelling as this purely artistic activity. Instead, we kind of need
to bring them both together and really think about how we can use
storytelling in our marketing and how we can sell our product in a way
that also tells our story.
00:11:57 - Speaker 1: And maybe this question of selling, which is
almost is more clarifying than talking about marketing, which is a
pretty broad, maybe term or discipline, maybe that helps clarify, which
is there’s the very artistic side, which I’d put this podcast in that
category, you know, we’re basically here to explore philosophical
topics that are of interest to us and our guests. Basically, Mark and I
started it essentially for fun and then things got out of hand.
Whereas maybe something like the memos we write where we describe the
philosophies behind a particular product feature, maybe that’s in the
middle, like, you know, we want to explore why and how we made this
thing, but in the end, it’s partially to to that, hey, this feature
might be useful if you’re a person that needs whatever it offers, and
so in a way that’s sort of selling the product a little bit.
Then you take something like our website or the app store listing page,
and that is very explicitly when someone comes to your website, or at
least when I go to a website for a product. Tell me, right? Tell me
what’s good about your product. Tell me quickly, like, pitch me,
impress me, help me figure out right away, is this for me, is this not
for me? Do I want it? Can I afford it? Does it fit into my life? Does it
solve the problem I have? Does the vibe of the product and the team
like, fit with me well, and I want that, that’s appropriate for that
setting.
So yeah, there needs to be, or at least for us, what works is this
balance between, we do have a product to sell, we have a business to
run, and we need to be pragmatic about that, but at the same time,
we’re all here because we want to express something artistic, we want
to, as Mark would say, make a statement and, you know, our goal is to
have an impact on the industry and how people see creative computing,
and also we need to be viable as a business.
Now, on the product side, how do you think storytelling does or doesn’t
fit in there?
00:13:39 - Speaker 2: So we have already talked about all the different
mediums that storytelling is really useful for. And I feel like Adam,
you’ve been doing most of the exploration for us there and trying
different mediums to tell our story and what’s been your experience so
far.
00:13:53 - Speaker 1: Yeah, for sure. I think medium is incredibly
important. The medium is the message, I think they sometimes say, but by
here, by medium, you know, we talked about the TED Talk is one kind of
format or like conference talks or lecture maybe is the medium there,
but a different medium would be, for example, long form writing. So this
is something I’ve done a ton of in my career, including at Hiroku and
these long kind of academic essays that I can switch. And that’s
actually quite different from the much shorter, punchier kind of
copywriting you do for a website, for example, or an app store listing
page, like here’s some bullet points of features, but also a huge one
on the internet these days is video. Now that everyone’s got fast
enough computers and connections and things and we have everything from
YouTube to videos on Twitter to TikTok. Videos are really, really
important format, certainly one we’ve used a bit for these like short
product demo videos we do on Twitter, but also we embed them in our
website. The moment there’s a big hero video on the front page of our
website, and so on, and that was something you really couldn’t do on
computers generally, but even on the internet up until relatively
recently. But in working on this job description, I found myself really
reflecting on the web as a medium, and I’ve been working in web for a
long time, working with web technologies for a long time, and I feel
like a lot of the discussion about technologies there and how the web is
advanced is typically about web apps, the notions and Google Docs and so
on in the world, but I feel like what gets less, I don’t know, airtime,
let’s say, is the web as more of a content medium, and you’re a
storytelling medium, so. That certainly includes something like, you’ve
got a personal blog, and what do those pages look like, what’s the
reading experience like on that, but that also includes something like a
marketing website that is more of an exploring, you know, you tend to
skim it, you maybe don’t read all the copy carefully, there’s a lot of
embedded images, there may be a little animations with CSS transitions.
And one of the things that we kind of built into this job description is
we really want someone who uses the web as one of their primary mediums
for telling stories. That doesn’t mean they’re necessarily the
world’s greatest web designer, it means that they’re taking advantage
of this new and frankly pretty unique medium to tell their stories, even
if they’re, say, primarily a long form writer, that how you make that
article page for your personal site. What the reading experience is like
there, that that’s something you put a lot of craft and thought and
design work into. And it occurred to me kind of again in thinking about
this and thinking about our own needs and what you and I have done on
the website as well as what I’ve done on my personal site for my
articles and things like that, that the web is really a pretty
unprecedented medium because it combines many together. Obviously
there’s texts and typesetting is quite sophisticated, and you also have
images, but now you have videos which are very easy to embed whether
Using a hosting service or just kind of hosting your own HTML 5 video
playback stuff, but then you bring in the dynamic medium element of it,
and that is quite the next level, right? So you could say to begin with,
it might be something like, OK, you know, a PDF and the web can both
have pretty sophisticated rendering, but the web can be totally
responsive or you resize the window or you’re on different sized
devices and everything reflows. But then you can go a step further from
that, right? You get into the CSS transitions, you get into something
like changing behavior when you’re scrolling, and, yeah, sometimes
scroll hijacking is sort of annoying, but you’ve also seen sites do
some pretty interesting and sophisticated things with using your scroll
as a way to kind of progress you through this understanding of a product
or whatever it is they’re offering. And then, of course, that can
ultimately go to totally interactive things you can click on and
explorable explanations and things like that. And I feel like it’s
really only in the last few years, let’s say the last 5 years, the web
has really come in doing its own on that, that all this stuff is very
universally supported on every browser, that you can view it on your
phone, almost just as well as you can on a desktop device. That it’s
fast, that you have these amazing transitions and animations, that you
can do video and audio, and almost everything that you could possibly
think of can all be put together and integrated and controlled in a way
that’s potentially very sleek and very powerful, and there’s really
been nothing like that to date. And what I’m most excited about for
this position and just also broadly, is telling stories through the web,
really taking advantage of All that’s come together with that in the
last 5 or 10 years.
00:18:24 - Speaker 2: Yeah, totally. I feel like there’s a ton of
untapped potential in the web for telling stories in new ways.
And some of that kind of happens on like personal websites. So there’s
still like some spark of the experimental web as it was like a few
decades ago.
But most of that has been sort of restrained into a Very small corner of
the internet.
And if you look at most companies or products or websites, like they are
very much the same and don’t really try to tell any kind of special
story or tell a story in a different way than the competition,
basically.
And I think that is a unique opportunity for companies like us and that
our size to kind of have an outsized impact with this sort of goal in
the company to, yeah, do something that basically other companies can’t
do.
00:19:09 - Speaker 1: Yeah, part of that might actually be the reason
you see more interesting experimental use of the medium on people’s
personal sites with smaller teams is I think it does require a kind of
person that puts together a lot of skills into one.
I know one mind and so the same person that designs the site can also be
implementing the HTML and the CSS.
They’re maybe not a front end developer, I mean, you do this,
certainly, I do a bit of this as well, they’re not necessarily an
expert at that, but they know enough to really use the medium to its
fullest.
I think that’s pretty important and I think not to beat up on content
management systems, the WordPresses and Squarespaces of the world, but I
think they do tend to naturally take you into templates and sort of
pretty restrictive, just sort of doing what’s been done. Before, which
again is totally fine and appropriate for many people’s websites,
that’s fine.
But the interesting stuff tends to be when you have someone who can put
all that together into one mind or one set of skills, and you don’t
tend to have that, I think in bigger companies.
You do have that with an individual’s personal site and with a small
team site, and certainly that’s what we are striving for to some degree
with our website and hope to really expand on this, especially if we get
the right kind of person on the team here.
00:20:28 - Speaker 2: And as you said, the big factor here is that the
web really works as a medium that a lot of other mediums can kind of
build on top of. And so if you have a basic understanding of how the web
works and are interested in getting into that, then you can combine that
with another skill you have, whether it’s music or video production or
just drawing or writing. And on top of that, you can kind of build a
really unique experience on the web that you wouldn’t be able to do
with just a single skill.
00:20:57 - Speaker 1: Yeah, well, that’s one of the things that’s
great about the web is a multimedia medium is you can basically bring
most other types of storytelling mediums into it.
So, for example, photography is a really great format for storytelling.
But you can use that potentially together with the web, taking the right
photo that tells a story that then gets embedded in a website, whether
it’s part of a post, or whether it’s something more of like a hero
shot or background image or something like that, as just one really
simple example.
Now, I also think another medium worth talking about here is social
media. I don’t know if it’s quite right to call that a medium, but at
the same time I think it is.
And one of the things that’s always struck me, obviously Twitter is our
kind of main social media outlet for various reasons, but whenever I go
to try to use some other social media platform, and I think, OK, well,
maybe people would like to see new stuff on Instagram, or apparently
notion blew up on TikTok for a while there. And the idea of a short
video that shows productivity software, well, you know, guess what,
that’s a lot of what we do on Twitter, right? We record these short
demos that show a particular feature or a little vignette of how you use
this product in the real world and show the hands and the stylus in
action. It’s not just a screen recording. So clearly that works, but
times when I have gone to look at these other social media platforms and
think how we might fit in there, and I realized as soon as I’m there
that there’s a whole universe of What format is it? What’s the aspect
ratio, how long are these videos, you know, what goes in the text, you
know, how’s that superimposed, and then on top of that, of course,
it’s just the culture and the conventions that come with the platform
and people have been using them a long time. So I think that being
proficient in a particular social medium platform is sort of a medium in
and of itself, and like the web, can incorporate other mediums, which is
images and video and text and short form, long form, etc. but each one
is almost its own language to speak. You have to be fluent in it to get
good use out of it.
00:23:02 - Speaker 2: And social media seems interesting because there
are so many different communities within that. Like it’s not a single
thing that you post to and then it’s on social media, like you always
post to a specific group of people. And ideally it’s full of people
that are already telling a similar story and are really familiar already
with the context that you’re sort of setting.
00:23:24 - Speaker 1: Yeah, that’s a great point.
The stories resonate with our own experience or they match to something
that we understand or believe to be true about the world. And actually
there’s a quote in a fantasy book, it’s probably Guy Gabriel OK, I
have to look that up after the show, but essentially it’s a medieval
fantasy, I think set in China or something like that, and there’s one
of the characters is a poet. And like a famous poet that evokes much
emotion with his work, and one of his fans basically asks, how do you do
it? How do you come up with these words that are so moving? And he says,
well, the key is the poet has to speak the words that are already in the
person’s heart. The key is you’re putting words on something you
already feel implicitly or believe to be true, or have an underlying
sense that is the case, but finally someone has put these really
poignant words on it, or somehow described in a way, and you say, yes,
that right there.
00:24:22 - Speaker 2: Yeah, I feel like there are a lot of lessons like
this and really the classic storytelling, you know, that hasn’t been
invented in the last few years basically, there’s so many great
storytellers that we can learn from and so many classic lessons about
storytelling.
00:24:36 - Speaker 1: All right, so my next question then is how does
design fit in with storytelling or how can one tell stories through
design?
00:24:46 - Speaker 2: Yeah, I think the important thing to remember is
that it doesn’t have to be a visual story that you are telling, but a
lot of it is really stuff like world building, setting the context for
something, and sort of conjuring up mental images in the user’s head.
So one example I like is when you look at the original iPhone and look
at the first apps that Apple built for the iPhone, they all were kind of
built, I think, to tell a very specific story both about the iPhone and
then also about sort of the features it has, right? So for example, you
had the note sap which was very obscure morphic and was sort of built to
look like an actual notepad, right? Like you had this leather bound top
and the page looked like a natural page with lights on it and it was
yellow and the font was some sort of handwritten scribbly thing.
00:25:33 - Speaker 1: Yeah, and you wanted to touch it. I feel like
that’s morphic and the leather. And even that makes me think of
something like this slide to unlock, which we sort of take for granted
now, or, you know, has actually has gone to the dustbin of history a
bit, but it had this kind of shimmering effect, and there was a lot of
effort put into the physics when you pull it across or whatever. It’s
easy to forget this, but at the time, a screen that you touched was just
not a very common thing, and so inviting you to want to touch it, seems
like it was part of how you conveyed what was special about this
product.
00:26:08 - Speaker 2: Right. And since it was a very new product, like
if you just look at it from like a key tech perspective, it doesn’t
look like a product that is necessarily interesting to basically the
whole world. Like if you just compare the spec sheet, it’s basically
still something like a BlackBerry that has all the basic functions of
the phones of that time. And so what you really need is to sort of build
up a story around it that connects it with something that people are
already familiar with and that helps those people kind of understand how
the product fits into that.
00:26:43 - Speaker 1: This also reminds me of an ad for the first
iPhone, and while we’ve may beat up on paid ads, paid marketing a
little bit, you know, part of what Apple is great at is ads, these
little vignettes that tell a short story that show more than tell what
this product is and how it fits into your life.
So in this ad, which I’ll see if I can find a link to it on YouTube or
something, they have the person watching Pirates of the Caribbean, which
at the time was a popular movie. They see like a sea monster with these
tentacles, and they kind of go, hm, calamari, and they hit the home
screen, they pop up in the maps app, they type in a search for seafood
in San Francisco, they find a place and then they tap on it to like call
and make a dinner reservation.
And obviously they’re showing a lot of different things in this, I
don’t know what it is, 20 seconds that you can watch a movie, that you
can search on the map, that you can do things very spontaneously, that
you can do things very fluidly, these different apps coexist side by
side, that you do this all on this screen with no buttons, essentially
other than the home button, and it’s just a fun and cute little story
as well, little vignette. So yeah, the product tells a great story, the
apps tell a story, and the marketing that goes with it also tell a
story, and all those things fit together very holistically.
00:27:59 - Speaker 2: Right, and I think each of those kind of
multiplies the effect of the story, right? Like if it’s just the
marketing that tells the story and then the product is kind of really
bland and doesn’t implement the story at all, then that story is not as
effective, right? And I think you can also go the other way and look at,
OK, we have a great story that the marketing is telling and the product
is also telling it. And the whole company is living it like maybe even
the support team is trying to incorporate that story into their work,
but then you can also go down a few levels deeper and look at, OK, what
is actually a specific feature of this product doing as part of that
story. And that will kind of help explain not just the product itself
and the role the product has in the user’s life. But it will actually
make the product much easier to use if you can actually tell a story for
every single feature and ideally even for every single UI element and
you kind of know its place and know where it comes from.
00:28:54 - Speaker 1: Yeah, so this sort of progression or hierarchy
from the company or the team story, and then the product has a story and
then each feature within that product has a story and then maybe that
even goes down as detailed to each UI element, button, whatever that’s
on the screen, or non-UI such as our chromeless UI that’s really
interesting. One that comes to mind for me right away with that is the
pencil toolkit. Which is, you know, essentially it’s this little thing
you swipe in from the edge of the screen with your stylus, and we did
the very custom and pretty unique thing there as opposed to using the
standard Apple pencil toolkit, for example. And at first glance, and
sometimes people do have this question, why did you make this weird
custom thing rather than using kind of the operating system default? And
of course you could argue that there’s sort of our company and team in
general and certainly the product has a bit of a do it our own way, you
know, follow our own path, story, or maybe more of a theme throughout.
But it was actually the very first episode of this podcast where we
talked about tool switching, and at the time it was still just an idea.
Mark had this technical pen store idea of you go through and they have
1000 different pens, but you pick out the 10 you want and you put those
in your kit for what you need for a particular purpose, so that you’re
not overwhelmed with choice each time. And that was kind of, we told
that story or discussed that philosophy through this podcast, and later
on, we went to build it and you designed it, we incorporated some of
those ideas, as well as many other ideas, and came up with something
that eventually we did a memo about talking about whiteboards and the
choice of pens there, as well as the pen store and just looking at a lot
of inspiration from These various kind of real world drawing settings
and ultimately described why we built this feature the way that we did,
and then that in turn boils down to this very specific detail of why
does the tool switches show up the way that it does, why is the choice
of pen thickness or color, why do I need to go to the settings menu for
that, you know, it’s. Taps to get there as opposed to something that’s
sort of right there always present in UI, which is what a lot of drawing
apps do, but that connects to this philosophy and this concept and story
we have about trying to bring some of these elements that we think are
good for creating a flow state from the analog world into a digital
tool.
00:31:16 - Speaker 2: Yeah, the pencil token is a great example because
as you said, it really incorporates a lot of these ideas that I think at
the very core of news and what we want news to be.
And so it’s not just about like a single element, right? Like it’s not
just about the pencil case that you have on your desk and like that’s
the story of everything that’s related to pencil music. It kind of
draws from all kinds of ideas that matter to us and in turn that sort of
creates a really unique angle that wouldn’t be the same if even any of
those ideas is taking away.
And so then the product design challenge, I think, is you have this long
list of things you wanna incorporate and these values you have, the
ideas you have, but it’s not a simple, concise story or a simple
concise design yet, right? So that’s sort of the challenge to really
figure out the essence of these ideas and turn that interaction that
incorporates all of these different ideas.
00:32:16 - Speaker 1: It’s often the case that it does emerge
organically from following a hunch. For example, in the pencil tool kit,
we did have the sort of pen store idea from the start, but many, many
details of how the actual implementation ended.
I think with you following your hunches and instincts as a designer, it
was Julia following her hunches and instincts as an interface engineer
to eventually land on this thing that felt good, that looked good, that
seemed to be a reflection of our values and pragmatic. just serve the
purpose that it needed to serve, and all those things come together, and
then maybe it’s sort of post hoc, you end up with a story where you
look at the finished thing that you iterated towards and followed
hunches and followed instinct, and you look at this and you say, you
know what this reminds me of is, you know, a set of whiteboard markers
and why that kind of setup is good for a freeform thinking environment
where you’re not going to get hung up on the exact thickness of your
pen. And maybe, you know, we had some of that upfront, maybe that was
part of our inspiration, but sometimes you sort of look back and realize
why you ended up where you did, or I don’t know, do you agree with
that? There’s some elements of that?
00:33:24 - Speaker 2: Yeah, I think certainly at the start, that’s
often the case. You know, if you compare to writing, you have this fear
of starting with a blank page. And so you aren’t going to just start by
writing down the whole story, but you’ll need to start somewhere and
then you kind of go through this long editing process and at the end of
it, you’ll know what the story is, basically. And I think we are a bit
further along now where we already have a lot of the pages filled out
and it becomes a lot easier to add new sections to the story basically
and new subplots to it.
00:33:54 - Speaker 1: So that’s sort of the role that maybe product
design has to play in storytelling or the use of storytelling and
product design. What about brand design or visual design? How does that
fit this picture?
00:34:06 - Speaker 2: Yeah, I think for us, our experience has been that
marketing design works best and there’s some underlying truth to it,
which in our case is the product. So since we already have a really
compelling product, I think a lot of what we do is transform that into
different marketing channels and talk about the very same story there.
So one example there would be this podcast we are on, which is also a
channel for us to talk about the ideas we develop with use the product.
00:34:33 - Speaker 1: Yeah, for me, one example of where brand design or
visual design can be very helpful in telling your story is, obviously,
the podcast is super important for us telling our story of the team and
the product and that sort of thing.
But for some time we first made the podcast, which as I’ve mentioned
before, was just a weird thing that Mark and I were doing for fun on the
side, and at some point we realized it was something really worth
investing in, but we had basically were just redirecting to the overcast
public pages because they were, I don’t know, better than nothing.
We needed like some home on the web, they kind of give you a default
one, but it really didn’t convey that we cared much about the podcast.
And so you designed the page for us, which was both the MUA.com/podcast
page, which included figuring out what is the podcast actually about.
We’ve been recording it for a while and we needed that like top
headline, and that required me to sit down or we sat down together, but
mostly it was on me. What is this podcast actually about if we boil it
down to 3 ideas or 3 areas, 3 themes, what are they? And we ended up on
tools for thought, product design, and how to have good ideas. There’s
lots of other stuff in there about like independent software development
or we talk various things about company building and team building, but
you know, we felt like those were the three really top level things. And
related to that also is self-hosting the pages, and we have the embedded
media there, and you did this little illustration for kind of a riff on
our app icon, brainy guy, just sort of wearing headphones, and that
conveys something sort of calm and serene and fitting in with our brand
vibes. And that in turn, in a way, having this home on the web and
having had to figure out this headline and what the three themes are
that actually clarified my thinking about what this podcast is for or
what kind of things we should talk about and what kind of guests we
should have. So there’s a nice feedback loop between the, it’s called
the product in this case, which is the podcast and the brand design or
marketing design or visual design that goes with its home on the web.
00:36:42 - Speaker 2: Yeah, and those projects are kind of always the
most interesting to me where one part of it is, of course, like the
visual side and like the purely design side, but then the other part is,
OK, we actually still haven’t completely figured out the story or the
message yet, and we kind of need to develop both in parallel, because
then one can inform the other basically. We can do a bit of work on the
design side and then see if that is sort of the vibe you have in mind
for the message you want to get out there. And then once you develop
that, that will also inform the visuals.
I think we’ve been doing fairly well on that. Like we have a few
projects like this that I think tell a story both through the messaging
and the design side.
But yeah, I do also feel like there’s still a lot we kind of wanna do
and either I don’t have the skills to do it or we don’t have the time
to do it. And so that’s the reason we are hiring and looking for a
person to fill in those gaps and really help us out, both with
storytelling and brand design, visual design.
00:37:45 - Speaker 1: Yeah, for sure. We have a lot to say at this point
and more than we have the sort of bandwidth to get out of the world,
whether it’s through our website or other means. So I think that’s
part of what they would do is just this potential person to join the
team would be to just help us say more, right? Our website is pretty
minimalist at the moment and as we expand the product offering and in
general, expand our story, I think we would like to add a lot more
content there, but it’s just hard to do with the size of the team we
have.
That’s one is just kind of more.
And then the other dimension is the one you mentioned, which was
skill-wise, you know, someone could come onto the team. I think you’re
underselling yourself a little bit there, you managed to do both
incredible web design and product design, and you’ve argued before that
there’s a lot to be said for having one person that does both, so that
you have an integrated look and feel between them, but then at some
point that’s just too much, right? It’s too much for one person to
carry on going. And that, of course, is always the tension with the
smaller teams.
It’s great to be able to, everyone’s kind of jack of all trades, and
you span a lot of different realms, which means also the whole thing can
feel a lot more holistic because it’s not split up among so many
different craftspeople, but then, you know, you’re just both limited in
time and just where you can invest in your skills. So, I’m hoping that
a great designer and storyteller could come in here and help us both
with uh doing more about telling our story and all the unique and
interesting things about our company and our amazing users and
customers, and the reason to have thinking tools, you know, reason to
have our computers help us with thinking, as well as many, many more
details within all those realms, that we can do more of that, but also
do it better.
00:39:26 - Speaker 2: Yeah, I’m really excited for that.
00:39:29 - Speaker 1: Let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at MuseAppHQ or
we’re on email below at museapp.com and you can help us out by leaving
a review on Apple Podcasts. Leonard, I don’t know about you, but I’m
really looking forward to meeting all the folks who might find it worth
their time to apply for this and eventually to add our 6th member to our
tiny little band here.
00:39:56 - Speaker 2: Yeah, I’m especially excited since I’ve been the
only designer on the team so far, so, you know, I get to socialize with
designers again. That’s something to look forward to.
00:40:05 - Speaker 1: It’s well and good to have colleagues that have
complementary skill sets, but there’s a whole lot to be said for
someone you can really talk shop with very directly about your area of
craft. I look forward to that too.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Building my own tools, when I type a character in
or hit save, I know exactly where the bits are going, and I think that
changes the relationship that you have with your software. There’s kind
of a power dynamic where if you don’t know what the company that’s
providing you some software products is doing with your data, they have
the power, whereas if you build your own thing, you understand exactly
what’s going on, you’re in control.
00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad. This podcast isn’t about Muse product, it’s about
Muse the company, the small team behind it. My name is Adam Wiggins.
I’m here with Mark McGranaghan. Hey, Adam, joined today by Linus Lee.
Hello, hello. And Linus, before the call you were showing me on video
chat here, you have a fun new gadget in the audience would like to hear
about that one.
00:00:50 - Speaker 1: Yeah, this is always good audio podcast materials
when you have to show something off visually, but I semi recently got
this thing called the Surface Duo, which is an Android phone from
Microsoft, but the Android part’s not super interesting. What’s
interesting is it folds out like a book. It’s about the size of a
passport, and if you imagine. Passport, but it folds out and there’s
screens on both sides of the book, and there’s like a stylus you can
use on it and it’s meant to be sort of like a multitasking,
multi-screen, note taking on the go productivity kind of phone, and the
screen there is continuous, it’s using the folding screen technology is
there a scene there.
00:01:24 - Speaker 1: There’s a solid theme there, it’s two separate
screens, but it’s like if you imagine like a Nintendo DS from way back
when, tilted on side.
00:01:33 - Speaker 2: Or yeah, maybe a shrunk down multi-monitor set up.
00:01:36 - Speaker 1: Yeah, exactly, and it’s great for reading, great
for like general kind of content consumption, taking notes, things like
that, not so. For like watching videos or like Instagram’s really
struggles to fit on that screen because it’s basically square. But
yeah, I’ve been enjoying using actually, one of the perks of living in
New York, where I live is that all the tech stores are just lined up
right down 5th Avenue so I can go visit them when I go running.
Microsoft came up with a new one, I think just last week or something
like that, and I went down yesterday to visit it and they didn’t quite
have it on the shelf yet, but maybe soon, maybe I’ll upgrade.
00:02:08 - Speaker 2: Microsoft’s Surface line has continued to impress
me. We did a quite a bit of prototyping on one of the Surface tablets
from a few years back, and just in general, what they’ve done there,
kind of going into hardware and doing such a good job at it, is really
quite impressive for, especially such an established, you know, company
which are not known for that kind of innovation or moving into brand new
markets and doing a good job.
00:02:32 - Speaker 1: Yeah, definitely, it seems like they sort of see
their responsibilities of doing things that are weird. They’re very
reluctantly did like a classic laptop form factor. So yeah, I like it.
00:02:42 - Speaker 2: And could you tell the audience a little bit about
your background and interests?
00:02:47 - Speaker 1: Yes, so my name is Linus. I say I grew up in
Indiana, which is where I spent most of my childhood, before that, I
spent the first half of my childhood in Korea, just where my family is
from, but I grew up in Indiana, like normal kind of public high school
towards the end of that high school experience, I kind of self taught
myself how to code JavaScript backbone, react kind of stuff.
And then got a little job over the summer at a software startup in the
area called Spencer. We did agriculture, precision agricultural
software, so basically using some hardware in the field.
Indiana is a farming state, so hardware in the field plus some weather
data and satellite imagery and other things like that to try to Improve
efficiency and ease of producing food for humans or for cattle and and
so forth.
And so I was there for about that summer and then ended up taking a year
off after high school to work there, learning Django and JavaScript and
all that good stuff, and that was my first kind of real programming
gig.
I learned a lot there for about 2 years and then after that, the company
itself ended up getting bought, then I had a few extra months to travel
and things like that, and then went to UC Berkeley, where I studied
computer science for a few years just in California, so went to Silicon
Valley, did some other startup stuff, was briefly part of things like
relate, which is online IDE. Oh yeah, they’re doing some pretty cool
stuff, and a couple other projects, and then recently I moved to New
York, just where I am now working at uh another software startup doing
sort of tools for thought space things called idea flow, and then all
through that time sort of off on the side I’ve also been doing random
other. Experiments, building my own various side projects and writing a
little bit and things like that, which I’m sure we’ll get more into.
00:04:32 - Speaker 2: Yeah, well, I would think looking over your
homepage and your Twitter account and your blog posts that these what
you call side projects appear to me like they could easily be a
full-time worth of output. So doing that on the side from your regular
work as opposed to, I don’t know, a retired gentleman who can spend his
full day building interesting tools that certainly speaks impressively
to your output or maybe passion for building these tools.
00:04:59 - Speaker 1: Yeah, that’s a misconception that I’ve gotten a
couple other times. I think it’s actually interesting to think about,
like, having to work a normal job, like not being completely free on
your own to follow all your whimsical ideas and having a bit of
constraint on not only your time but also like having to use normal note
taking tools and having to like use notion and talk to people and slack
and things like that I think is a good kind of way to ground yourself.
00:05:25 - Speaker 2: Yeah, we actually see this dichotomy in the we
call it the research world, or even in like a classic software company
that has maybe like an R&D arm with sort of mad scientists thinking big
ivory tower thoughts versus the more kind of production like please our
customers, keep our systems running thing and you typically have If
you’re too much in the research, free floating, just have big ideas,
you’re not constrained by the realities of the market, or customers or
anything else, you’re just out of touch, and it’s hard to like, make
things that are meaningful.
But of course, on the other side of the equation, if you’re really deep
in the trenches of doing an atlas holding up the world kind of thing
with production systems, and you’re thinking about tomorrow and next
week, and you just can’t have big open, out of the box thoughts or,
like you said, explore weird whims or unusual directions. So it’s a
difficult dichotomy, seems like you’re walking that line though.
Yes, yes, definitely. So our topic today is self-made tools, and of
course, Linus, your work is a stellar example that I’ll link to some
posts here, maybe Moocle is an interesting one here. You have a post
explaining your motivation for that, and there’s a few other posts we
can reference here, or other folks I know who are really prolific
self-made tool makers. But yeah, what does that mean for you? What are
self-made tools? Why do you do it? And is it something you recommend
others explore, or is it only for a certain kind of person, maybe?
00:06:51 - Speaker 1: Yeah, so the way that I look at my tools is a lot
of the software that I rely on to function as a working human day to day
are things that I built myself to varying degrees.
I have notes apps that I built that I used to keep sort of my personal
information in, in general, a little bit. I have obviously things like
my website and other kinds of public presence things, but also like a
contacts app, CRM.
Your typical productivity suite kind of stuff, and then because these
are just sort of like things that I imagine and then I go build,
there’s also things that sort of don’t exist as general purpose things
in the market that I’ve built out, like a personal search engine, which
is the monocle that you referenced earlier, where I have all my data
sort of shoveled into a search index and then I can search for anything
across any of my sort of bank of data from people that I’ve met to
conversations that I’ve had to websites that I’ve bookmarked and
things like that.
So some of them are sort of what you would normally imagine as side
projects, so like off the shelf libraries and frameworks and things
combined into things that I put on the cloud, and other ones are more
involved.
Monacle, I think is a good example where the search index that I use for
that is one that I built myself. It was originally a project to learn
how kind of full text search worked and then that is then written in a
programming language that I wrote called Inc and this that kind of goes
very deep into that.
Yeah, things that I built myself to fix my own problems or solve my own
solutions, or solve my own problems, I guess, and really for myself
only, nobody else, I mean I guess if you wanted to, you could go to get
up and clone those down and deploy yourself, but a vanishingly small
number of people do that and so it’s mostly just for me to use.
00:08:29 - Speaker 2: As you sit there and describe, writing your own
full text search engine, writing your own programming language, sort of
not just the end application, but really going down the stack.
I’m reminded of this, it’s basically a meme now, but I think it’s
like an excerpt from a movie where there’s a guy that wants to change a
light bulb, so then he goes to get the light bulb out of the cabinet,
but then it turns out that the cabinet’s got a Loose things that he’s
going to get the screwdriver, but then the screwdriver turns out that
it’s in the squeaky drawer. And at the end, I think like his wife comes
home, what are you doing? He’s like, I’m changing the light bulb,
obviously.
So it feels like with technology and software systems today, I mean, the
stack goes very, very deep. How do you decide when to like stop diving
down. I guess another way to put it was, how much is the decision to
say, for example, write your own full text search is that a pragmatic
decision versus following your curiosity. You want to learn how this
works.
00:09:21 - Speaker 1: Yeah, I mean, to the question of when do I stop,
it’s really when my curiosity stops being strong enough to get me
through learning whatever I have to learn.
Back months and months ago when I was more naive, I mean this is all
endless yak shaving, right? Like I needed note taking app and then I
realized I need a front end library and then I realized I need a
language.
And there was a point in time when I was sort of made to myself the
argument that ultimately this is sort of a more productive way to work
because in the end, the little time that I take to build my own tools is
gonna kind of come back because it’s sort of so fit to the way that I
think and things like that. And I think to some degree that’s still
true in that.
When I’m really in the flow, I’m more productive with the tools that I
built, but I think really the argument that building your own kind of
software ecosystem is more productive may be a little flawed, but I
think the change of mindset that I’ve had is, I mean, I still do it and
so there still has to be a good reason that I do it, and I think for me
that reason is that it just changes the relationship that I have to the
software that I use.
And that if it’s my own tools that I built on top of my own stack,
running on it runs on the cloud, I use digital lotion, so I don’t want
to control everything, but to a large extent running on sort of things
that I understand, I can trust it more. It feels more personal. I mean,
I made it sort of handmade it obviously and so.
I think it changes the relationship that I have with the software that I
use, and the data that I get to keep on it and trust it a little more
and makes it feel more little more personal and durable.
And so I think that’s the benefit and along the side, I get to kind of
learn a lot, right? A lot of my side projects are motivated by just
encountering some new piece of technology that I don’t understand, and
then I use. Building a kind of prototype clone of whatever I’m trying
to learn how something works. I use that as the excuse to build another
tool like the search engine or I have like a toy assembler that I made
which I don’t need to assemble X86 code very often, so I don’t use
that as much, but it was a cool learning project.
00:11:20 - Speaker 2: Yeah, I really like the personalization angle. I
think there’s also this element of agency or self-actualization or
something like that, that fits into the same theme.
You know, we had Wei Wei Xu on the podcast, for example, we talked about
the fact that you have this homogenizing effect of now that most
technology is made by these absolutely massive companies that are
practically nation states, and of course, they’re appealing to the
widest possible audience, and that fits into the kind of software.
Yeah, basically, the wider an audience you can reach with your software,
you know, the more you can become one of these huge empires, but then
very much lost in that is not just sort of niche software, but also just
things that are weird, different, appealing to a smaller audience, and
in a way, the personalization side is, you know, when you’re making
something just for yourself or just for yourself in a small group,
that’s about as personal as it gets. It’s a nice antithesis or palate
cleanser or something from Let’s say the mass produced software that
honestly is what rules our lives now.
00:12:23 - Speaker 1: Right, definitely the phenomenon of like every
fast website looking like Stripe, but a little bit worse.
We were talking about something related right before the show about how
there’s sort of two bifurcating kind of classes of software, the one
that you just referenced the kind of big company one. is things that are
meant to be sort of lines of business, things that companies sell to
other companies or other people, and they sort of have a tendency to
grow indefinitely, like you build a prototype, you start selling it,
people need more things and so kind of grows unboundedly both in terms
of like feature setting complexity. Technical debt, but also in terms of
just codeba complexity.
It’s just easier to add things when you need the product to do newer
things and more things, whereas the idea of situated software where you
have a very finite group of people you’re building for and a very
finite use case you’re building for, which is frequently what I think
my tools are, I just needed to do these three things. Take my notes,
save them, I want to be able to read them, I want to be able to send it
to these places or receive some notes from these places. And I know
exactly what I want, maybe I’ll want to add one or two things there,
but it’s definitely not going to grow unboundedly. It’s definitely
meant for only me or only the small group of people, and I don’t really
care if that many people use it. It’s sort of an underrated group of
software, but I think there’s places where it’s the right thing.
00:13:41 - Speaker 3: Yeah, and just to riff on this piece a little bit,
so I agree with all of the sort of first order reasons we gave around,
it can be more fun, you get to learn, you have the potential for it to
be more fit for purpose for you personally, but there’s also
interesting second order effects with this focusing.
So you talked about how the general purpose tools they have all these.
Layers that are built up over time, because they need to serve a lot of
use cases, right? And with all those layers, even if you have a very
focused use case for the software, you’re kind of stuck with those
because the layers, they end up coupled with each other and you have all
these weird linkages, so you can’t just boot out some piece of it.
So for example, if you want to make a very basic static site, well, OK,
now you need the static site generator, and now you need a library
system, you need a package manager, you need a way to install the
package manager. Need a way to check for security vulnerabilities and
all the packages, need a web server, you need a place to run the app,
it’s the whole thing, right? And even if you have a very basic site,
you’re kind of stuck with all that. And so what I like about these very
simple projects is you have a possibility to do what I call stack
fusion, based on the similar idea from algorithms of stream fusion,
which is kind of looking at the whole thing and what you’re actually
trying to do and like compacting it down to the minimal possible stack.
The example that I like to give is these web pages I’ve done. Where my
stock is like, I open up index. HTML type, type, type, save, that’s the
website, and that’s a very basic and almost contrived example, right?
But it just shows how much stuff you could potentially get rid of if you
are able to do this sort of stack fusion.
00:15:11 - Speaker 1: Yeah, I like that a lot.
I think one of the questions that I get about, I guess at this point, my
personal infrastructure is what you call it, is, for example,
authentication, you’ll ask how I do authentication because there’s no
kind of authentication related code in any of the open source code that
I’ve released.
And the reason is because at the app level I don’t do any
authentication because all my stuff lives on a single Linux server and I
just have one giant authentication layer at the top, um, at the kind of
reverse proxy layer and then once any request goes through that layer
for anything that needs to be authenticated, I can assume that it’s me
and then I have all the permissions that I want and I like the idea of
what you call fusion of just if you know. A lot about the environment
that you’re deploying on who’s going to be using it and things like
that. You can make a lot of assumptions that let you not need a bunch of
those abstractions instead of when you kind of collect samples when you
need to deploy a search engine, you don’t have to start with I’m going
to start up a web crawler, I’m going to start up a database. I
statically regenerate my search index every once in a while. It goes
into a file, the file is loaded to the browser and then the browser does
a search. I don’t need any kind of sophisticated database or ingestion
algorithm or anything like that.
00:16:19 - Speaker 3: And this leads to further 3 order benefits because
if you successfully do this stack fusion, you have much more ability to
understand all the pieces work and you potentially have more durability,
because a lot of the complexity is often to support like dynamism and
change, which is a direct liability in terms of erosion of the stack.
But if you have files on a Linux server, there’s fewer ways that can go
wrong then a whole dynamic database is doing authentication and so on.
Adam, you might be able to speak to this because I know this was a
motivation for you with Broku.
00:16:50 - Speaker 2: Yeah, for sure, and the bit rot or software
erosion, the idea that a piece of software that worked at one time
doesn’t work anymore even though nothing changed with it, which always
seems weird because a software is digital, why should it not work the
same every time? And the answer is that the world changes around it.
Sometimes in small ways, you have an operating system upgrade, some
things were changed and I don’t know how paths are parsed or something
like that, but often in big ways, for me, one of the biggest disruptions
in my personal tooling was I used to write a lot of things with little
Ruby scripts that ran at the command line, that worked great when the
only kind of computer I used was what we call a desktop class computer.
Once the phone became a huge part of my computing life, now that
doesn’t fit in, or the world has changed in a way that those pieces of
software don’t fit into it as well as they once did.
But one of my motivations at Hiroku, yeah, for sure was I felt like
hobby projects and interesting side projects, and even at a company,
what you might call, yeah, we should talk more about the situated
software label, but you often have this case where I did this at
companies I worked for companies I consulted for, and you also see it
often as spreadsheets or filemerro things, or whatever, but sometimes
also web apps, would be something where one person would build a custom
tool for just that team, whether it’s 5 people or 10 people or 20
people, and they would set it up and it would be running over time. As a
web app, so often it would stop working database goes down, server needs
a reboot, the file system is full, because the log rotation thing
wasn’t set properly. And so one of the things we strive for with Roy
was to make these more explicit contracts with the underlying system, so
that you could more easily upgrade things and have the platform do a lot
more of that maintenance kind of automatically, and then hopefully the
app could keep running over the long term. I think there’s no perfect
way to ever do that. I think we did make some good strides there in
terms of reducing the likelihood of that software erosion. I’ll link
out to the article we did about that.
00:18:51 - Speaker 1: Yeah, I want to also dig a little more into the
kind of dynamism, ease of making changes thing because I think there’s
actually two ways to look at the ease of making changes when you solve a
problem with software. One way is to make the software sufficiently
sophisticated, so that you can swap any arbitrary part out and you can
keep making changes. The other is to make the software so simple that
it’s easy to rewrite, and you can just rewrite it when the constraints
change.
Yeah. And the way you do that is you make your data layer more portable,
use a lot of my data is stored in.
New line to JSON, just lines of JSON packed into a single file or text
files are marked on files or something like that where like basically
any tool that I pull in is going to be able to talk to it or if I really
need to structure something like SQL, you know, you can plug that into
basically any language and it makes things like backup really easy
because you just copy the file.
And things like flat dependency trees. So if you don’t depend on a lot
of things, it’s easy to rebuild things and you make sure that the earth
doesn’t shift under you quite as much.
If you write relatively small things that do one or two jobs only, then
if the constraints change a little bit, maybe you can just modify the
software a little bit, but if the world changes a lot, it’s not the end
of the world and you can scrap it and rewrite it or something like
that.
I try not to rewrite things too much. I try to make most of my things
last a while, but I’ve rewritten some of the older pieces of the things
I’ve been using the note tap and things like that, which I wrote at
this 0.56 years ago. I’ve rewritten those a couple times just because
the world changed and some of the packages that I used to use aged out
and so it didn’t take too long.
00:20:26 - Speaker 2: Yeah, some other stuff on the durability that I
think we talked about a bit before. I know, Mark, you were maybe one of
the ones who opened my eyes to the value of the go and static linking,
so the sort of dynamically linked libraries, whether it’s DLLs on
Windows or the dotSO files on Linux. You think of it as being sort of a
necessity for modern software, but go just as screw all that, it’s too
complicated, it’s likely to break, now you’re like tying things
together, let’s just package it all together and, you know, computers
are fast and we have storage, so it’s fine.
00:20:57 - Speaker 3: Yeah, exactly, I like that aesthetic.
00:21:00 - Speaker 1: Yeah, I like go and some kind of philosophies and
the tools that I used for the same reason where it’s as someone who
maintains a few dozen different things that are sort of concurrently
running online, it’s very difficult to think about doing that while
running on an ecosystem like node. I love node, JavaScript fee, it’s
great, but one of the faults it has is like every project has a million
dependencies and by the time you’re done with the next project, the old
projects so about a date.
And so it’s difficult to think about operating in the style of like
many, many different small projects with an ecosystem like that, whereas
with Go or, you know, one of the benefits of writing your own language
is that the language only makes breaking changes when you decide to make
breaking changes on your own terms and so using languages that
prioritize long term durability of software I think helps a lot and
things like static thinking, I think is a reflection of that value.
00:21:49 - Speaker 3: Yeah. And by the way, this Go discussion reminds
me of a generalization of the personally built software question, which
is, if you are a company or organization, should you use something off
the shelf or should you build it yourself? I don’t think we want to go
into that whole discussion, but I’ll just know that there are a lot of
echoes in that analysis and that calculus between an individual and
Corporate. And I was thinking about with Go because in the same way that
people will often tell you, you should always just use a library off the
shelf. I’m sure at one point everyone said, why would you ever write a
programming language? Well, it turns out it was the correct thing to do.
It does important things that no language had correctly brought
altogether. And so I think there’s a similar dynamic playing out with
personal software and with corporate choice to use libraries versus
build.
00:22:34 - Speaker 1: Definitely one thing that you touched on there is
the idea of like leverage and building your own tools, the various
levels in the stack where at some level of like operational scale or
software development scale, if in your own programming language makes
sense because it gives a greater leverage over the things that make your
shop easy or hard, yeah, and I think.
That doesn’t just apply at the programming language level, it also
applies to your life at the tool level. So, let’s say like a lot of
your work is about remembering people and keeping relationships with
people, maybe designing your own CRM or context app gives you that extra
leverage, or maybe if your job is about taking a lot of notes and
learning a lot, building notes app for yourself actually does give you
that leverage and so.
There’s a whole thing with not a hair syndrome which we don’t have to
get into, but I think that’s one way to think about it is in the long
term will it pay off for me to have this sort of deep understanding and
control over what I use and depend on, yeah.
00:23:23 - Speaker 3: I do also think there’s another side to this,
which is our now of the calculus has been very focused on the I, you
know, the durability, the flexibility, the understandability, and
that’s all important that goes into the calculus.
But I also think there’s an artistic element of sometimes to make a
statement about how you think the world should work, the only way to do
it is you just Do it all yourself top to bottom.
And I do think that comes through sometimes with these personal software
projects and even some of these libraries and other software endeavors
that initially seemed like a weird thing to try to go out and do. But
ultimately, you see that not only are they providing ilities, but they
end up making a statement about the world, which I think is cool. And I
think people underestimate how important that is.
00:24:02 - Speaker 1: Yes, definitely, that reminds me of one of my
favorite others sort of self-made software people is this couple of
people called 100 Rabbits. I don’t know if you’ve come across them,
but, oh yeah, yeah, they have a little boat, I think called the Pino,
and they sail down from Vancouver down to Australia up to Japan, and
they’re just open source hackers. On a boat and they also have their
own sort of homebrew software stack basically from the like language
virtual machine up for various things, a lot of C99 old school software
things, things that don’t break things that don’t consume a lot of
energy, certainly no electron apps. I think actually they’ve publicly
said that running instances of Chrome is untenable for them because they
only have a limited amount of energy from those solar powered things on
their bone and they have to be really efficient with it. But I think
that’s a great example of building your own tools or building your own
software stack, not purely for the utility that it provides in your
life, but as a demonstration of this is possible, or these are the
values that I believe in, which I think is, as you said, also important.
00:25:04 - Speaker 2: Uh, the one that comes to mind for me on that, and
these are publicly available, but a fellow named Jordan Singer has
little apps. It’s just a calculator, a draw tool, browser, and these
are all things that come by default on modern smartphones or whatever,
but he has a particular aesthetic and a particular just kind of
minimalist. Just does the littlest thing possible, hence little, and
yeah, it just has a particular style to express. It’s not that those
tools provide utility you can’t get elsewhere, it’s more like they
express something about how their creator sees the world.
00:25:37 - Speaker 1: Speaking of little, one of the nice things about
building your own thing is computers are very fast these days.
I don’t think most people realize how fast computers are these days,
and the reason that software is slow is because it turns out we write a
lot of code and we make computers execute a lot of code.
A modern desktop computer can run 2 to 4 billion instructions per second
on a single core, and if you’re slack or if you’re whatever app takes
up a second to start up, what is it doing with all those billing
instructions? Like you just have to show a rectangle on the screen.
It’s wild. And fortunately if you write your own thing, there’s only
so many lines of code that I can pack into my little project as a single
person hacking on it over a weekend, and so. By virtue of that and very
little else, all my things are really fast, like my notes have loads
faster than it takes for notion to start showing its spinner to load the
rest of the page, and those things about building little things are also
nice things like performance and sort of consistent design aesthetics
and things like that you get for free.
00:26:39 - Speaker 2: Now, we’ve talked about these are sort of
personal tools, personalization, you’re building for yourself, sort of
your target audience of one, and that person is the same person making
it.
And that also makes me think of a fellow I’ve worked with closely named
Simon Kalinsky, who does a lot of personal tracking tools and things
like that. He’s also a musician, and he makes a lot of music tools.
I’ll link out to his portfolio, so he’s maybe in the same category as
you in terms of making for himself, and that’s it.
Most of the time. But then you have something like, in a lot of my
experiences with this more like situated software is often creating for
a small group. It’s either a group of friends, or family, can also be
obviously very much in the corporate, call it enterprise environments,
you know, just a small team that has a need, and I’m thinking there of
Robin Sloan’s concept of home cooked. An app can be like a home cooked
meal. He’s got a little kind of messaging app for his family that he
wrote about, I’ll like that in the show notes as well. So how often do
you find either of you are writing when you’re doing this sort of work?
Are you writing for just yourself versus a very small group?
00:27:45 - Speaker 1: Yeah, that’s an interesting question. I think in
my experience, most of the things that I end up building are for just
myself. Almost all my work is online just because, you know, there’s no
reason to keep it to myself if other people want to look at it, yeah,
and you can look at it and I like writing a little. and things like
that.
00:28:02 - Speaker 2: Well, out of curiosity, what happens in that case
when someone submits a bug report, a pull request, a feature request,
you say, no, you got the wrong idea. This is for me, not you.
00:28:12 - Speaker 1: Or yeah, I mean, sometimes it depends.
A good example is my programming language. A lot of the reasons that I
have it is, well, it’s not at all because I have this grand vision of
like, I think this is how programming should work and these are the
features that it shouldn’t it’s just, I did a university project once
where I built like a Lip interpreter, which I think is like a common
college project and I was like, oh this is cool. Maybe I should be able
to build a whole language like this, and I can decide what all The
keywords are, and that will be the thing or instead of saying function,
because I like to keep it short. And so it’s a reflection of just my
tastes for those things, if other people want to come in and kind of
speak their opinions, I say things for your opinions, but this is my
language you can fork it and I’ll help you fork and understand the code
base, but for my thing, I want to keep it to my tastes and it’s totally
fine. But for some other things, for example, I have a little Twitter
client that I use, like a Twitter reader that just talks to the Twitter
API but gives me my own kind of chronological timeline and a few other
kind of search niceties and for things like that, other people have come
along and they’ve contributed things like a Docker file for people to
more easily clone it and use it on their own setting and things like
that.
And sometimes, actually the. Twitter thing is really interesting because
it’s designed to be sort of in one very specific way and user
customizable, which is that you can add these tabs that correspond to
searches instead of just having your own timeline, your home timeline is
just one of the many tweet deck style, one of the many tabs that you can
have open and you can have another tab that’s like people talking about
tools for thought or you can have another tab that’s like Taylor Swift
content or whatever because I’m a big fan. And maybe that means that
other people don’t have to contribute patches or get put in pull
requests because it’s like end user programmable, throwing a buzzword
there, but it’s end user programmable and so in that way maybe people
don’t have to modify the software itself for the thing to suit their
needs. But yeah, pull requests come in if it doesn’t really change the
way that I use it, I’m open to it a lot of times because it is an
improvement, but if it impacts the way that I use it, then, you know.
Yeah, I built it for myself, and so you can fork it, fork it, yeah.
00:30:20 - Speaker 1: Build your own version that matches your own
taste, yeah, definitely, and I’m actually a huge fan of that. You can
fork it and the winner will get the masses kind of approach to open
source.
00:30:28 - Speaker 3: And I think by the way, that aligns well with
having artistic goals because in that world, the actual code repository
is not so much the output as the instigation that you’ve admitted into
the world. This I think was a success of go by example, where I don’t
think anyone has used the actual code base, but people have used the X
by example idea and layout a lot and that’s propagated, which is great.
00:30:52 - Speaker 1: Certainly, I think this is true of Monaco as well
the search engine thing where just building that, I think it’s one of
those ideas where you tweet it out and then the thread is a bunch of
people who are like I’ve been thinking about building a personal
searching for and for the last 5 years and why haven’t you done it?
It’s because there isn’t that instigator. To say this is doable and
these are the ways that you could do it.
And one of the pure joy moments of building my own tools and then
putting it out in the world like this is seeing other people take those
ideas and either take the codebase or just take the idea and go and
build their own tools because it’s really lovely to see against the
kind of tsunami of these like corporate mass market tools, these little
small islands of personal tools that are reflections of the maker’s
values and tastes kind of come into play.
00:31:38 - Speaker 3: Yeah, I think as an empirical observation,
there’s a very big step function and like difficulty and effort when
you go from one person to end users, especially in our classic SAS model
of client server where the server is multi-tenanted. There’s all kinds
of complications. You have two code base, you have multi-tenancy, you
have security, you have upgrades, you have different versions across the
client, the server. It’s a whole idea.
So I think in practice that stops a lot of people and and equals one,
they say, you know, just basically go fork it and do whatever you want.
I do think there’s a world where this step function is decreased a lot,
and this goes back to our discussion of local first software. If you can
have something more like spreadsheets where you can just send someone
one file, and that’s basically all they need to be able to participate
in this home cooked meal, I think it could be much more successful.
In fact, we see this with spreadsheets often there’s groups of friends
or groups of colleagues at a company where they’re sort of sending
around or linking around or forking a spreadsheet and it sort of spreads
as a meme within a company. I could see the same thing with local for
software if you didn’t need a server and if all the data was either
stored directly on the clients or you could bring your own server and so
the originator of the software didn’t need to worry about multi-tenant
hosting your data.
00:32:49 - Speaker 2: Yeah, the authentication, the identity generally,
of course, is just kind of this huge unsolved problem. Throw in the
multi-tenancy, you throw in the Partitioning by users, even if you leave
out the security thing, assume that all your users are, yeah, friends or
family members are in the same company or something like that. It just
quickly gets very, very complicated compared to the, maybe the world of
software that I sort of grew up in, which is something where when you
write a program, maybe it saves data persists data to disk by writing a
file, which is incredibly simple, as you said earlier, there, like, you
can copy it, you can delete it, you have a lot of agency over it without
needing to build that into the tool, the app.
And yeah, the concept of user just doesn’t really exist or it’s
implicit in, for example, your local Unix user or something like that.
The permissions are all handled by the operating system, the location
and the file system is handled by the operating system. You just write
the program, and all the rest can go around it.
That’s kind of not where we’re at.
In a way, modern operating systems, whether they be on the desktop or
mobile, do way, way more, or even the web has way more APIs, way more
capabilities, accessing hardware, all these different things you can do,
but in a way, some of these simpler things like Just knowing who the
user is, you could do that in a Unix program. There’s a who am I, you
know, function, and you can kind of inherit that from the operating
system or file permissions you can inherit from the operating system.
Basically, every app is reimplementing all of that from scratch in the
modern world.
00:34:21 - Speaker 3: Now that we’re talking about it, I have another
example.
So longtime listeners of the podcast will know that there’s often two
examples we drawn. One is spreadsheets and one is games as areas that
have in many ways at the frontier of computing.
So now I’m thinking about sort of situated or home cooked software in a
context of games. And there I do think you see it with the like
scripting and modeling community. So you have these games where there’s
an existing infrastructure for players and accounts and identities and
server hosting and everything, and People can contribute their own
programs in the form of different skins or different map scripts. And
that is very successful. So again, you just need to basically put your
code, if you will, out there. People can share it around and copy it
around and link it around, and that’s all you need. You don’t need to
run your own map hosting server or whatever. That’s been very
successful. It makes me think even more that if you could have a similar
substrate in the world of personal knowledge management or more
traditional SAS apps, you could see the same success.
00:35:17 - Speaker 1: Yeah, definitely, I think, Mark, what you’ve been
talking about sort of made me go on a train of thought about software
packaging, because a lot of this is about how do you take something that
works on my computer and make it so that other people can just take it
and run it and it works the same on their computer and In a similar way
to what we’re kind of talking about, I think the advent of GitHub as
the de facto way that people share code, I think is kind of one of those
step function changes right about, yeah, instead of sending me a zip
archive or sending me patches, you can just send me a link and then I
can download it and include and oftentimes there’s instructions in the
repo of how to run it and presumably there’s more that we can go. Down
that road about instead of having to copy a whole bunch of files down
and then set all these things up and things like deploy AWBS with all
the scripts and stuff, maybe you can just give me a file and I can run
it and it’ll just work.
And I think that, yeah, there’s a lot that we can still improve on on
the packaging side, I think, for just being able to share sort of single
user single instance piece of software.
00:36:11 - Speaker 2: Yeah. In a way I’m nostalgic for the Windows era
of download an EXC. And run it, and I know why in the world of malware
and so on, that maybe doesn’t work anymore, but there was something
quite simple and elegant about it, and because Microsoft did work so
hard at kind of keeping backwards compatibility in the operating system,
you typically knew that, yeah, someone wrote compiled an EXC 10 years
ago, and you could still run it on a Windows computer today.
And the closest thing we have to that now, or the best thing I would
say, is the web, where typing a URL into your URL bar is essentially
downloading and running a program on the fly in a safe sandbox, which is
frankly, a miracle when I start to think about how that works, but it
has these limitations of things you can’t do, it’s not personal.
If you want to do anything with, you know, it’s gonna have some kind of
persistence that really needs to have a back end, and now you’re into
this whole crazy world of different tools, and you need to know 5
different programming languages, just to make the most basic thing, you
know, shared to do list or something work, and yeah, a world of local
first apps or something where you could download a piece of software,
expect to run, have it be in a security sandbox so it’s safe, but not
necessarily to go through some kind of Gatekeeping review system, and
then be able to do persistence and other things that you would do in the
local environment, or even add in some of the collaboration side of
things.
I would be very disappointed if we don’t end up in a world there
sometime in the coming years, but I also don’t know the path that gets
us from there because the companies with the most resources and software
engineers to throw at the problem, are pretty motivated to keep their
walled gardens and keep you logging into their system and keep you on
their servers rather than empower local, more powerful local apps.
00:38:04 - Speaker 1: Speaking of being able to download an EXC and run
it through, I think there is momentum in that direction.
I think one example that has been quite a big source of inspiration as I
work on my own program language kind of tooling and ecosystem is Dano.
Do you know? There’s no JS and then Dano is sort of the typescript run
time, I think is the way they talk about it, but it’s all of the same
underlying technology as node, but it runs.
Sort of TypeScript natively has built in Tyscript compiler and some
other nice things in the language and that’s all fine, but the really
interesting thing is Dano inherits kind of big focus on developer
experience and toling quality from other languages like go and rust and
so I think in the kind of intervening 15 years, they’ve learned a lot
about how to distribute andacket software, like, a lot of the big focus
of Noja was just like, let’s get a synchronous eventsa. Yeah, it’s
really good. Like they got that, but everything else is kind of a mess.
And then you know, I think a lot of the right choices have been made for
kind of software your ability.
So you can do things like deno compile, which gets you an executable
binary, so you can write things with typescript and build it with Deno
and package it up so that I can give you an EXE and you can run it on
any Linux thing, right? And I think things like that sort of being built
into the language tool chain are pushing us. I think in the right
direction.
The other thing that Dano does that’s really interesting is instead of
having a package registry, the packages that you can import are just
kind of URLs and so you say import X from this URL string and it’ll
download and cache that thing at that URL, but then there’s no
intermediator that has to be up all the time or that has to be correct
all the time, you’re just downloading things from the web, which I
think is about as futureproof as you could get.
00:39:39 - Speaker 2: Yeah, another interesting thing about Teno, and
that’s a smaller point, but I think it’s an important one, which is
this sandboxing thing is so important for making it possible to, I can
give my friend a piece of software that I’ve written, and they can just
run it, and we don’t need to go through some onerous review process,
but we obviously also need to protect from the now huge world of
malware, and so sandboxing, and good sandboxing is a potential technical
solution to at least some elements of that.
And the browser obviously does an incredible job at that, but if you
want to run a command line program, no, the demo actually does a lot of
that, where by default, any demo program you run at the command line has
no permissions essentially to the core operating system, but you can
pass.
It switches to say, I wanted to be able to, for example, make an
outbound HTTP request to this host, or I want to give it full network
access or something like that.
So you have a lot of that kind of control that I associate with, for
example, cueSOS. So that sandboxing gives you a lot of control over the
individual programs, how they’re accessing the network or the file
system, that sort of thing, while at the same time just giving you the
incredible simplicity, which I still love that you had from Ruby and
Python, and of course, Go and Rust nowadays, and leading back to the C
days, which is, you just have the file and you type, run this file at
the command line or you double click it, or whatever it is. The thing
just runs, and you compare that to, you know, what it takes to sort of
run a web app, particularly a database back web app, that’s just
incredible simplicity that I think can do the job in a lot of cases,
especially for these kind of self-made or situated apps.
00:41:15 - Speaker 1: Yeah, actually, one thing that people say around
software packaging is that the modern analog of the EXC is like the
Docker container, and I think sort of aspirationally that’s in the
right direction where instead of having a single battery that you can
run a Docker is sort of the representation of a thing that you can put
in a machine and it’ll run and if you need an entire system set up then
you can have. Whatever confirmation YAL or whatever, you can just throw
it to a cloud provider and it’ll spin up the whole thing. And I think
that’s aspirational in the right direction, like that’s where we want
to get to and I think if the dreams are fulfilled, that’s that’s a
really interesting world where you can, you know, give your friend a
confirmation YAL and they’ll just spin up their own little thing. But
in practice, just quality of experience wise, it’s much easier to
execute an EC than to throw it up on a web service. Maybe there’s a gap
that we can fill there. But yeah, it’s interesting to think about sort
of in this world of having a backend service and databases and then
users and things like that in a web app, what that equivalent to
executing the binary experience looks like.
00:42:16 - Speaker 2: I think in my ideal world you would somehow put
together, I guess the client side version of the Docker cubeSOS
virtualization sandbox thing would be, imagine a launch an application
launch screen that’s like the iPad home screen.
Basically, I could drop a Docker file essentially on there and become an
app icon, and when I tap the app icon, it fetches whatever it needs to
fetch to run it, spins up a virtual machine and runs it, and gives it to
the computer full screen until I exit.
Something like that that just makes it very, very easy, in fact,
standard, totally standardized to just spin it a virtual machine and run
it. And maybe there’s a server side. version of that as well and
certainly some I think platform services have attempted this, certainly
some we have services have stats at this, something where you really do
just have maybe Hiokku, the Hioku button was the equivalent of that drop
a little link onto your GitHub read me and you click this button and it
kind of spins you up a virtual instance of whatever this application is.
So we’ve had some good stabs at it to try to at least package up the
complexity, if not remove it or simplify it. We haven’t quite maybe got
that perfect. There’s still no .exe equivalent basically. Yeah.
00:43:27 - Speaker 3: Yeah, and I think there’s a couple of things
missing here. I think on the one hand, there’s additional platform
primitives that are needed for things like identity and data if you’re
really gonna do this without having your whole full blown client server
thing, which is necessarily a lot of hassle.
But also these things like Docker and virtualization and so forth, they
are sort of the opposite of Stack fusion. It’s like we’re gonna run
any stack you want, you know, any language, you know, 10,000 files in
your node modules or whatever, you know, go for it. And that’s awesome
because it gives you a way to better manage all its existing complexity
that’s out in the world.
A lot people needn’t want that, but it might be that if You want a
really nice double click experience that you need to do a bunch of stack
fusion and say, OK, these are the APIs. They’re much, much narrower
than all our stuff.
Maybe it’s only one programming language. Maybe you don’t have your
full suite of wild just calls or whatever. Maybe you can’t contact any
address in the network, you know, you figure out what’s a very narrow
interface, but by accepting that narrowness, accepting that fusion, you
can give a much more powerful experience to the Home Cook app developer.
00:44:26 - Speaker 1: Yeah, one thing that’s come to mind is we have
this conversation is the metaphor of the app as a thing that you can
hold and move around as opposed to a thing that you install on a
system.
I used to be a Windows user and then these days I kind of use Mac and
Linux and one of the really interesting things with the Macs, like, not
the underlying software model of applications installed the system, but
just the end user model of how the Mac works with applications is that
there’s like a dot app file.
And there’s like the safari. app and that’s the safari app and if you
want to get rid of it, you just take that file and you move it to the
trash. And if you want to open it, you just open it, you can move it to
a different part of the folder or something like that, compared to in
Windows, for example, where you have an installer.
00:45:09 - Speaker 1: I mean you can have an EXC too, but and it’s just
spraying files everywhere like messes with the registry and like put
some weird stuff in weird places that can do a bunch of stuff to your
computer and yeah, I’m just realizing how clean and that’s just so
much more and user friendly the Mac model is of here’s a thing you can
click on it to run it and it’ll do the thing that you expect and if you
don’t like it, you can get rid of it as opposed to like, it’s now
fused with the operating system, you can never remove it completely.
00:45:32 - Speaker 2: And I do think that, you know, mobile operating
systems do that even better, and they even package the data with it, so
it sort of all goes together. When I delete it, it’s deleted, that’s
it, it’s gone.
Now, of course, mobile restricts you and limits you in so many other
ways.
That basic idea of, first of all, the user’s mental model, I think of,
OK, an application, I’ve installed it, or I have it now, and it’s a
tile on my home screen until I decide I don’t want it anymore, and then
I press it and tap delete and the tile goes away, and there’s this 1 to
1 association between the icon that lives in a particular place in this
mildly spatial interface.
The application code and data, and then I can basically manipulate it as
one unit. And that’s where I certainly feel like there’s a very big
lost opportunity for end user programming system customizability,
whatever, particularly on the iPad, where I guess you can make shortcuts
and stuff like that, but again, because of the review process, because
of the heavyweight tooling doesn’t even run on that same platform. The
idea of, yeah, you know, I’d love everyone to do a little apps style
thing on their iPad, you know, they’re making it themselves in place,
and they type up their little program and they turn it into a tile
that’s on their home screen, and data gets stored there, and if they
wanna send it to someone else, they can, if they wanna move it to
another device, they can, if they want to delete it, they can. I think
there’s something very powerful about the simplicity of that model, but
then we haven’t quite connected that together with the more
programmability side of the equation.
00:47:03 - Speaker 1: Right? I mean, it goes back to what Mark was
saying about to have that quality of experience of stack fusion, you
need some constraints, and I guess I’s platform is providing some of
those constraints so that you can have that simplicity, just better API
contracts for the era.
Another example more on the website that comes to mind is Relate. Which
I’m a little biased because I worked there for a little bit, but one of
the things that you can do with a rep, a repel is a running environment,
right? It’s like code plus an execution environment, and you can click
a button and the software and it’s not perfect. There’s some bit rod
for like old things won’t run because like some MPM package has gone
out of date or something, but by and large, the promise of it is a repel
is like that, that packaged up thing. With all the configuration,
there’s a little database that you can talk to inside of Apple and
things like that, and you hit run, and if you see someone else that has
the thing that you want to run, you can fork it, put it into your own
account, and then you can hit run and now you have your own running
instance. And maybe the right solution kind of looks like that where you
just abstract the whole thing, even at a higher level than like a docker
container or a Docker file and you just say, here’s an environment plus
some code, and you can look inside if you want, but really it’s just a
click run and it runs kind of experience.
00:48:15 - Speaker 2: Yeah, definitely put Repole in the same continuum
of, I don’t know if they think of themselves as a kind of platform of
service or serverless kind of environment, but I think it is in the same
continuum with Roku, for example, and the idea of, yeah, wrapping it all
up and then putting it on the web, which there’s pros and cons to
essentially running it on someone else’s computer, but certainly for
the use case of learning and getting started, I think that’s sort of a
no-brainer, and of course over time that is becoming more and more.
Powerful. Yeah, that also makes me think of Code pen, which obviously is
a much simpler use case because it’s just some CSS and JavaScript,
it’s all client side, etc. but it has a lot of that vibe and it creates
a lot of that sharing dynamic, which is you search on there for, you
know, find me a pen for, I don’t know, doing parallax scrolling with a
whatever, whatever, you find a couple of good examples, you find the one
you want, you fork it, you make some changes. Maybe that has a little
bit of some of the same vibe of the skinning modding gaming community
you talked about earlier there, Mark.
00:49:13 - Speaker 1: Yeah, exactly. And then once you have something
like replic containers or environments that you can spin up and sort of
give to people, then it’s really interesting to think about, well, what
does an app store that’s built on that model look like, where instead
of downloading things to your machine and running it there, you have
sort of web software. Where there’s like a ret store or whatever and
instead of downloading a to do app you hit run and it clones that thing
to your account and then it spins up a little bit of backing code and a
little bit of client code and you have your own web app but it’s
running just with your account and just with your data and you can look
at your data and you own all of that.
Stuff until you have the cloud provider, but that I think is also really
interesting to think about where you have sort of single user web apps
and a way to distribute them, and then you can get people to have their
little cloud environment with their little web apps, instead of having
your own computer, you just have your own little cloud garden of things.
That sounds amazing.
The last interesting thing that I wanted to touch on was the idea of
transparency in the transparency down the stack and down your tool. One
thing that I found that’s really kind of gratifying is my own tools,
especially not just at the top but down to the language layer, is just
being able to understand what’s happening.
I think if you use a tool like notion, which I think is great, but it’s
very opaque. I type something in and it shows up on screen and I load
that same page up on a different computer and it shows up on screen, but
I have no idea how they’re saving it, how they’re transforming it,
where it’s going, who owns it, whether it’s in another continent, and
that’s nice in one way that it’s packaged and kind of hidden away, but
building my own tools, I think an interesting benefit has been when I
type a character in or hit save, I know exactly where the bits are
going. I know almost down to the CPU instruction, what’s happening with
that data. And I think that going back to the first thing that I
mentioned, it changes the relationship that you have with your software
where it’s there’s kind of a power dynamic where if you don’t know
what the company that’s providing you some software products is doing
with your data, or what’s happening behind the scenes, they kind of
have the power and you’re paying them so they let you use the thing,
whereas if you build your own thing, you understand exactly what’s
going on that you’re in control and you can understand. Even just the
concept of like, the things that you use to run your day to day life,
you have the power to understand fully, I think is kind of a radical
idea.
00:51:29 - Speaker 2: It comes back to this agency and this sense of,
yeah, as we live in a world where there’s more and more complexity to
the technology and it becomes indistinguishable from magic, and that’s
good in the sense that magic is great and powers more and more things in
our lives, but then it’s bad in the sense that we lose that
understanding of it that actually is important in the long run.
I feel there may have been a, it’s a Star Trek The Next Generation
episode where they encounter, and if there were some humans or an alien
race, I can’t remember where, kind of they had forgotten how to service
the technology or how it worked, you know, in generations past, because
it works so well and it’s kind of self-maintaining and that sort of
thing, but then the whole civilization was in a state of Not decay, but
let’s call it stasis or mild decay as a result of this, I kind of
explored philosophically that concept which that shows was very good at
doing.
00:52:25 - Speaker 1: Yeah, maybe maybe we’re not so far away from that
kind of thing where there’s another exec CD of like, you know, all of
modern software depends on this one little piece that’s maintained by
some lonesome developer in the middle of nowhere Arkansas or something.
Yeah, these things are hugely complex and there’s a lot of parts that
are sort of under service.
My favorite variation of that joke is in the tools without space. One of
the table stakes thing that you have to build when you build like a note
taking or knowledge management app is you need a good rich text editing
experience to be able to do things like bullet lists and things like
that and basically.
Everybody that I know uses this library called Prosemir, which is
amazing and excellent and really well designed, and also quite complex
just conceptually, and it’s just this one dude, Maran working on the
library, and he’s like holding up an entire kind of burgeoning venture
backed industry, which is sort of frightening and interesting to think
about.
00:53:18 - Speaker 2: was a place to end. I thought it’d be interesting
to talk about software as kind of an ever evolving thing versus
something that you finish.
We talked about this in the filmmaking podcast with Max Bacht where he
basically said films, you finish it, it’s printed, that’s it, it’s
done. You don’t get. iterate on it, any feedback you get and you think,
oh man, I should have done that differently. Too bad, you know, if it’s
a TV series, you could incorporated the next season or whatever.
And I’ve also tweeted about kind of this is part of why the
subscription model actually does make sense for software is that it’s
sort of never done. The tweet that I quoted there was the curl
maintainer speaking a little bit about the 23 years he spent working on
that piece of software, and it’s still very active, new features, bug
fixes for what’s basically a very simple tool. So, how do you see that,
especially in the context of self-made tools where you can’t maintain
them full time, particularly if you have a whole suite of them, how much
can you build them as something that’s finished versus now you’ve
created for yourself a huge open-ended maintenance job?
00:54:22 - Speaker 1: Right, right, I think this goes back to what I
spoke on earlier around if you have a software product that is in the
line of business for some company or that a lot of people depend on like
Curl is a great example where it does nominally does one thing, which is
talk to some server on the web, but it’s used like virtually every
piece of electronics out there, but like, I’m sure my car, I don’t
have a car, but if I had a car, my car would use it in my fridge
probably uses it or something like that.
And in those things where these things sort of grow in an unbounded way
just because of user needs changing and the world changing.
I think it’s difficult to be done with software and I’m sure most my
side projects if I really think about it, if you know something about
Linux changed or something about the HTP protocol changed or something
like that, I have to rebuild it occasionally and fix some bugs, but by
and large I think the benefit of having a single user and a very
constrained well defined use case is that you can kind of be done with
software, like at least a single piece of software.
Like my notes app, it does a very constrained set of things. I can write
some text in it in a markdown format. I can save it. I can load it up
and look at another device, and maybe there’s some things that I want
to add to it and occasionally I can go back and add to it, but when I
initially came up with that, I had a set of things that I wanted to do
with it, and it does those things and I’ve mostly been fine with it,
and it’s sort of done until something breaks, and I think if you build
on stable foundations, as we talked about like go and The Linux user
space and things like that, things don’t break as much.
So I think in that way when you constrain those things a lot and kind of
build for yourself, I do think it’s possible to finish a piece of
software.
00:55:55 - Speaker 3: Yeah, I feel like in today’s world it needs to be
a very deliberate act to create software that you expect to be finished
because of the political economy, the software ecosystem, if you kind of
write down what Google or Stack Overflow tells you to do, this thing is
not gonna last a year before you have some package update advisory or
something.
But you can, if you are very deliberate, build it in a way such that it
might last 35, even 10 years before it needs serious operations.
Again, it kind of comes back to the idea of artistic software and today
even saying I want this thing to be running in 10 years without me being
heavily involved with it is a major artistic statement to make.
00:56:31 - Speaker 1: Right. Another thing that plays into this I think
is also building many small things versus a single large thing.
At this point, you know, I have a whole suite of these things I’ve no
top CRMs and. Twitter clients and whatever, and they’re all quite
independent.
Some of them rely on the same kinds of languages and frameworks and
things like that.
Like if one goes down, it doesn’t matter for the other ones. And if you
structure your sort of software ecosystem like that, then it’s possible
to like finish one piece and then if it needs to be improved and you can
just replace that piece and that way the whole system is kind of
evolving continuously as the world changes.
Maybe I need, you know, but no. or context app that functions
differently, but each little atom of that ecosystem is sort of finished,
which I think just as a matter of fact like a person working on these
things while holding a full-time job is also kind of a necessity because
being able to chunk these things up to atoms means that you can fit it
into weekends, you can fit it into these little breaks rather than
having to work on them continuously. It’s just a good conceptual model
to work on these as well, to have.
An ecosystem of these atoms rather than a single sprawling kind of
software grid.
00:57:39 - Speaker 2: Let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at EAHQ or on
email, hello at newsapp.com, and it helps us if you leave a review on
Apple Podcasts. So Linus, thank you so much for being a role model,
inspiring us to maybe creating that spark or that sense of it’s doable
for the thing we all want to do, whether it’s that personal CRM or
personal search tool, and I look forward to continuing to read your
posts about whatever you’re making next.
00:58:09 - Speaker 1: Thank you. Thanks for having me on the show.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: And I feel like this idea of really changes the
abstractions that operating systems should provide because maybe OSs
should not just be providing this model of files as a sequence of bytes,
but this higher level CRDT like model and how does that impact the
entire way how software is developed.
00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad. This podcast isn’t about Muse the product, it’s about
Muse the company and the small team behind it. I’m Adam Wiggins here
with my colleague Mark McGranaghan. Hey, Adam, and joined today by
Martin Klutman from the University of Cambridge. Hello. And we talked
before about Mark’s dabbling in playing the piano. I understand this is
a hobby you’re starting to look into as well, Martin.
00:00:49 - Speaker 1: Oh yes, I’ve been playing the piano, like trying
to do it a bit more consistently for the last year and a half or so. My
lockdown projects.
00:00:57 - Speaker 2: And do you have a technique for not annoying your
neighbors, or is this an electronic piano, or how do you do that?
00:01:03 - Speaker 1: It’s an electric piano, although I don’t think
it’s too bad for the neighbors. Lately I’ve been trying to learn a WBC
400 piece that I can play together with my wife, so she’ll play two
hands and I’ll play the other two.
00:01:15 - Speaker 2: Nice. I suspect a lot of our listeners know you
already, Martin. I think you’re within your small, narrow niche,
you’re a pretty high profile guy, but for those that don’t, it’d be
great to hear a little bit about your background. What brought you on
the journey to the topic we’re gonna talk about today?
00:01:31 - Speaker 1: Yeah, well, I’m a computer scientist, I guess. I
started out as an entrepreneur and started two startups some years ago.
I ended up at LinkedIn through the acquisition of the 2nd startup. And
they worked on large scale stream processing with Apache Kafka and was
part of that sort of stream processing world for a while. And then I
wanted to share what I had learned about building large scale
distributed data systems. And so I then took some time out to write a
book which is called Designing Data Intensive Applications, which has
turned out to be surprisingly popular.
00:02:10 - Speaker 2: Yeah, you wrote a nice kind of tell-all, you
showed the numbers on it, which it’s been financially successful for
you, but also one of the more popular O’Reilly books just by kind of
copy sold in recent times. I like that post, like the candor there, but
yeah, it makes you a pretty successful author, right?
00:02:28 - Speaker 1: Yeah, it’s sold over 100,000 copies, which is,
wow, way more than what I was expecting for something that it’s a
pretty technical, pretty niche book, really.
But the goal of the book really is to help people figure out what sort
of storage technologies and data processing technologies are appropriate
for their particular use case. So it’s a lot about the trade-offs and
the pros and cons of different types of systems. And there’s not a
whole lot on that sort of thing out there, you know, there’s a lot of
sort of vendor talk hyping the capabilities of their particular database
or whatever it might be, but not so much on this comparison between
different approaches. So that’s what my book tries to provide.
Yeah, and then after writing that book, I sort of slipped into academia,
sort of half by accident, half by design. So I then found a job at the
University of Cambridge where I could do research full time. And since
then I’ve been working on what we have come to call the first software,
which we’re going to talk about today. The nice thing there is that now
then academia compared to the startup world, I have the freedom to work
on really long term ideas, big ideas which might take 5 or 10 years
until they turn into like viable technologies that might be used in
everyday software development. But if they do work, they’ll be really
impactful and really important and so I’m enjoying that freedom to work
on really long term things now as an academic.
00:03:53 - Speaker 2: And certainly it struck me when we got the chance
to work together through these Ink & Switch projects that because you
have both the commercial world, including startup founder, but obviously
you’re very immersed in the academic kind of machinery now and again
just that long-term mindset and thinking about creating public goods and
all that sort of thing. And I found that I actually really like now
working with people that have both of those. Another great example there
would be another former podcast guest Jeffrey Litt. He was also in the
startup world, now he’s doing academic work at MIT.
00:04:26 - Speaker 1: Yes, and I’m actually doing a project with him
right now, right, I forgot about that.
00:04:29 - Speaker 2: There’s a current Ink & Switch project there.
So I find that maybe if you live your whole life in one of those two
kind of commercial slash industry or academia, you get like a fish
doesn’t know what water is kind of thing, but if you have experienced
both models, then it’s easier to know the pros and cons and understand
the shape of the venue you’re doing your work in in the end.
The point is to have some meaningful impact on humanity through your
work, whatever small piece of the world you hope you’re making better.
In our case, it’s computer things, but that the venue you’re in is not
the point, that’s just a vehicle for getting to where you want to go,
and each of these styles of venue have different trade-offs, and being
aware of those maybe makes it easier to have your work have an impact.
00:05:19 - Speaker 1: Yes, I think it is really helpful to have seen
both sides and I find it allows me to be a little bit more detached from
the common mindset that you get like in every domain you get, you know,
there are certain things that everyone believes, but you know, they’re
kind of unspoken, maybe not really written down either. And so like in
academia, that’s like the publishing culture and the competitiveness of
publication venues and that sort of stuff, which seems ridiculous to
outsiders. But if you’re in it, you kind of get accustomed to it.
And likewise in startups, it’s like the hype to be constantly selling
and marketing and promoting what you’re doing to the max crushing it,
always crushing it, exactly, and to an outsider that seems really. it’s
kind of a ridiculous show that people put on frankly.
But to an insider, you know, you just get used to it and that’s just
your everyday life. I find that having seen both makes me a bit more
detached from both of them and I don’t know, maybe I see a little bit
more through the bullshit.
00:06:21 - Speaker 2: So as you hinted, our topic today is local first
software.
So this is an essay that I’ll link to in the show notes. It’s about 2
years old, and notably there’s 4 authors on this paper, 3 of them are
here, kind of almost a little reunion, and actually the 4th author,
Peter van Hardenberg, we hope to have on as a future guest.
But I thought it would be really fun to not only kind of summarize what
that philosophy is, particularly because we’re actively pursuing that
for the Muse sinking persistence model, but also to look at sort of what
we’ve learned since we published that essay and revisiting a little
bit. What do we wish we’d put in, how’s the movement, if that’s the
right word for it, how’s that evolved, what have we learned in that
time? But I guess before getting into all that, maybe Martin, you can
give us the elevator pitch, if I’m to reference the startup
terminology, the brief summary of what is local first software.
00:07:18 - Speaker 1: Yeah, local first software is a reaction to cloud
software and so with cloud software, I mean things like Google Docs,
where you have a browser window and you type into it and you can share
it really easily. You can have several people contributing to a document
really easily, you can send it for comments. Very easily and so on. So,
it has made collaboration a ton easier, but it’s come at a great cost
to our control and our ownership of the data, because whenever you’re
using some cloud software, the data is stored on the cloud provider
servers, like Google servers, for example. And you know, as users, we
are given access to that data temporarily.
Until that day where Google suddenly decides to lock your account and
you are locked out of all of the documents that you ever created with
Google Docs, or until the startup software as a service product you’re
using, suddenly goes bust and decides to shut down their product with 2
weeks’ notice and maybe allows you to download a zip file full of JSON
files as your data export. And I find that tragic because as creative
people, we put a ton of effort, time and our souls and really our
personalities into the things that we create. And so much now the things
that we create are computer-based things, you know, whether you’re
writing the script for a play or whether you’re negotiating a contract
or whether you’re doing any sort of endeavor, it’s probably a file on
a computer somewhere. And if that file is in some cloud software, then
there’s always this risk that it might disappear and that you might
lose access to it. And so what we try to do with local first software is
to articulate a vision for the future where that does not happen, where
We have the same convenience that we have with cloud software that is we
have the same ability to do real-time collaboration. It’s not back to
the old world of sending files back and forth by email. We still want
the same real-time collaboration that we get with Google Docs, but at
the same time we also want the files stored. On our own computers.
Because if there are files on our own computers, then nobody can take
them away. They are there, we can back them up ourselves. We can
optionally back them up to a cloud service if we want to. There’s
nothing wrong with using a cloud service as long as the software still
continues working without the cloud service. Moreover, we want the
software to continue working offline so that if you’re working on a
plane or working on a train that’s going through a tunnel or whatever,
the software should just continue to work. And we want better security
and privacy because we don’t want cloud services scanning through the
content of all of our files. I think for creativity, it’s important to
have that sense of privacy and ownership over your workspace. And so
those are some of the ideas that we try to encapsulate in this idea of
local first software. So how can we try to have the best of both worlds
of the convenience of cloud software. But the data ownership of having
the files locally on your own device.
00:10:15 - Speaker 2: Yeah, for me, the core of it is really agency and
much of the value of cloud, and I think there’s a version of this also
for mobile apps, let’s say and app stores and that sort of thing, which
is not what we’re addressing in the paper, but maybe there’s a theme
in computing that we’ve made computers vastly more accessible by In
many cases, taking agency from people, and that’s actually a good thing
in many cases, right? You don’t need to defrag your hard drive anymore.
You lose your device, your email, and your photos and all those things
are still in this cloud that’s managed by experiencedmins and product
managers and so forth at companies like Google and So forth, and they
can often do a better job of it in a lot of cases than an individual
can. I mean, I think of managing my own email servers, SMTP servers,
years back and needing to deal with data backup and spam filtering and
all that kind of thing, and Gmail came along and I was just super happy
to outsource the problem to them.
Absolutely. They did a better job managing it.
So I think that’s basically in many ways a good trend or as a net good
in the world, and I don’t think we feel like we necessarily want to go
back to everyone needs to do more of those data management tasks, but I
think for the area of creative tools or more, I guess you call them
power users, but it’s like you said, if you’re writing a play, that’s
just a very different kind of interaction with a computer than the
average person doing some calendar and email and messaging.
Yeah, maybe they want different trade-offs. It’s worth doing a little
bit more management and taking a little more ownership to get that
greater agency over something like, yeah, my work product, the script of
my play or my master thesis or whatever it is that I’m working on is
something that really belongs to me and I want to put a little extra
effort to have that ownership.
00:12:08 - Speaker 1: Right, exactly. And I feel like it’s not
reasonable to expect everyone to be a sys admin and to set up their own
services, you know, you get this self-hosted cloud software, but most of
it is far too technical for the vast majority of users, and that’s not
where we want to go with this.
I think you still want exactly the same kind of convenience of clouds
software that, you know, it just works out of the box and you don’t
have to worry about the technicalities of how it’s set up.
But one part of local first software is that because all of the
interesting app specific work happens client side on your own device, it
now means that the cloud services that you do use for syncing your data,
for backing up your data, and so the cloud services become generic. And
so you could imagine Dropbox or Google Drive or AWS or some other big
cloud provider just giving you a syncing service for local first apps.
And the way we’re thinking about this, you could have one generic
service that could be used as the syncing infrastructure for many
different pieces of software.
So regardless of whether the software is a text editor or a spreadsheet
or a CAD application for designing industrial products or music software
or whatever it might be, all of those different apps. Could potentially
use the same backup and syncing infrastructure in the cloud, and you can
have multiple cloud providers that are compatible with each other and
you could just switch from one to the other.
So at that point, then it just becomes like, OK, who do you pay 6 cents
a month to in order for them to store your data, it becomes just a very
generic and fungible service. And so that’s what I see makes actually
the cloud almost more powerful. Because it removes the lock-in that you
have from, you have to use a single, the, the cloud service provided by
the software offer. Instead, you could switch from one cloud provider to
another very easily and you still retain the property that you’re using
all of the cloud providers’ expertise in providing a highly available
service and you don’t have to do any admin yourself. It’s not like
running your own SMTP server. So I feel like this is a really promising
direction that local first software enables.
00:14:24 - Speaker 3: Yeah, for sure, indeed, and you could even
describe local first software, I think, as sort of generalizing and
distributing the capabilities of the different nodes.
So in the classic cloud model, you have these thin clients, they can
dial into the server and render whatever the server tells them. And then
you have the servers and they can store data and process it and return
to clients and when you have both of those at the same time, you know,
it works great, but then if you’re a client like you said, who’s in a
tunnel, well too bad you can’t do anything, and the local first model
is more that any node in that system can do anything, it can. Process
the data, I can validate it, it can store it, it can communicate it, it
can sync it, and then you can choose what kind of typologies you want.
So it might be that you just want to work alone in your tunnel, or it
might be that you want to subscribe to a cloud backup service that does
the synchronization storage part for you while you still maintain the
ability to process and render data locally. This actually gets to how I
first got into what we’re now calling local first software. I was in a
coffee shop with Peter Ben Hartenberg, who’s one of the other authors
that Adam mentioned. And we’re talking about working together at the
lab when he was a principal there, he’s now the director, and he showed
me the pixel pusher prototype. So Pixel Pusher was this Pixel art app
where you color individual pictures to make a kind of retrographic
thing, and it was real time collaborative, but the huge thing was that
there was no server, so that you had this one code base and this one
app, and you got real time collaboration. Across devices, and that was
the moment that I realized, you know, I was a fish in the cloud
infrastructure water and I didn’t realize it. Just assumed, oh, you
need servers and AWS need a whole ops team, you’re gonna be running
that for the rest of your life, it’s the whole thing. Well, actually,
no, you could just write the app and point at the other laptop and there
you go. And we eventually kind of realized all these other benefits that
we would eventually articulate as the desiderao property to the local
for software article, but that was the thing that really actually kicked
it off for me.
00:16:19 - Speaker 1: Yeah, and that’s aspect that the apps become
really self-contained and that you just don’t have a server anymore, or
if you have a server, it’s like a really simple and generic thing. You
don’t write a specific server just for your app anymore. That’s
something that I’m not sure we really explored very well in the local
first asset as it was published, but I’ve been continuing to think
about that since, you know, this has really profound implications for
the economics of software development.
Because right now, as you said, like if you’re a startup and you want
to provide some SAS product, you need your own ops team that is
available 24/7 with one pager duty so that when the database starts
running slow or a node falls over and you need to reboot something or
whatever, you know, there’s just all this crap that you have to deal
with, which makes it really. to provide cloud software because you need
all of these people on call and you need all of these people to write
these scalable cloud services and it’s really complicated, as evidenced
by my book, a lot of which is basically like, oh crap, how do I build a
scalable cloud service.
And with local first software, potentially that problem simply goes away
because you’ve just got each local client which just rights to storage
on its own local hard disk. You know, there are no distributed systems
problems to deal with, no network time outs and so on. You just write
some data locally and then you have this syncing code which you just use
an open source library like automerge, which will do the data syncing
between your device and maybe a cloud service and maybe the other
services. And the server side is just non-existent. And you’ve just
like removed the entire backend team from the cost of developing a
product and you don’t have the ops team problem anymore because you’re
using some generic service provided by some other cloud provider. And
you know, that has the potential to make the development of
collaborative software so much cheaper. Which then in turn will mean
that we get more software developed by smaller teams, faster, it’ll
improve the competitiveness of software development in general, like it
seems to have so many positive effects once you start thinking it
through.
00:18:22 - Speaker 2: Yeah, absolutely. For me, yeah, maybe similar to
both of you, my motivations were, well, both as a user and as a, let’s
say a software creator or provider on the user side, we have these 7
different points we articulate and I think you can, in fact, we even set
it.
Up this way is you can give yourself a little scorecard and see which of
the boxes you tick. It’ll be fun to do that for the muse syncing
service when that’s up and running, but the offline capability is a
huge one to me, and it’s not just the convenience. I mean, yeah,
it’s.
Every time I’m working on the train and my train goes through a tunnel,
and suddenly I can’t type into my documents anymore, for example, or I
don’t know, I like to go more remote places to work and have solitude,
but then I can’t load up Figma or whatever else, and Yeah, that for me
as a user is just this feeling of it comes back to the loss of agency,
but also just practically it’s just annoying and you know we assume
always on internet connections, but I wonder how much that is because
the software engineers are people sitting in office. Or maybe now at
home in San Francisco on fast internet connections with always connected
devices versus kind of the more realities of life walking around in this
well connected but not perfectly so world we all live in. That’s on the
user side.
00:19:42 - Speaker 1: Yeah, I feel like there’s a huge bias there
towards like, oh, it’s fine, we can assume everyone always has an
internet connection because yes, we happen to be that small segment of
the population that does have a reliable internet connection most of the
time. There’s so many situations in which you simply can’t assume that
and that might be anything from a farmer working on their fields using
an app to manage what they’re doing to their crops and something like
that and you know, they won’t necessarily have reliable cellular data
coverage even in industrialized countries, let alone in other parts of
the world where you just can’t assume that sort of level of network
infrastructure at all.
00:20:17 - Speaker 3: Yeah. Yeah, it’s funny you mention this because
we often run into this on the summits that we have for Muse. So we were
recently in rural France and we had pretty slow internet, especially on
upload. I think it was a satellite connection, and we always had this
experience where there are 4 of us sitting around a table and you’re
looking at each other, but you can’t, you know, send files around cause
it needs to go to, you know, whatever, Virginia and come all the way
back.
00:20:43 - Speaker 1: It’s crazy if you think about it, it’s
ridiculous.
00:20:46 - Speaker 2: Yeah, and I don’t think you even need to reach as
far as a farmer or a team summit at a remote location.
I had a kitchen table in the house I lived in right before this one that
was like a perfect place to sit and work with my laptop, but the
location of the refrigerator, which it really couldn’t be any other
place, just exactly blocked path to my router, and the router couldn’t
really be any other place.
I guess I could run a wire or something, but I really wanted to sit
right there and work. But again, it’s this ridiculous thing where you
can’t even put a character into a document and I could pick up the
laptop and walk a meter to the left, and now suddenly I can type again
and you can be that to something like. G, which does have more of a
local is probably one of the closest thing the true local first software
where you can work and yes, you need an internet connection to share
that work with others, but you’re not stopped from that moment to
moment typing things into your computer.
00:21:38 - Speaker 3: Yeah, and furthermore, from the implementation
perspective, even when you have a very fast internet connection, you’re
still dealing with this problem.
So if I’m using an app and I type in a letter on my keyboard, between
the time when I do that and when the round trip happens with the AWS
server, which might be 50 or 100 milliseconds, the app needs to do
something useful. I can’t wait for that full round trip. It needs to
immediately show. Me what’s happening. So you inevitably have this
little distributed system where you have your local process and app
trying to display something immediately, and you have the remote
server.
And the great elegance, I think, of the local first approach is that
that’s just like another instance of the general problem of
synchronizing across nodes, whereas often in other apps, that’s sort of
like an ad hoc kind of second special case thing, like, oh, It’s only
going to be like this for 100 milliseconds. So just kind of do a hacky
solution and make it so that most of the time the right letter shows up.
And that’s why you have this behavior where apps will have like an
offline mode, but it like never works, because I think we mentioned this
on the podcast before, there’s systems that you use all the time and
systems that don’t work. This is a maximum we can link to. But again,
with local first, you’re kind of exercising that core synchronization
approach all the time, including when it’s just you and another server
on a good connection.
00:22:50 - Speaker 1: Yeah, and from a sort of fundamentals of
distributed systems point of view, I find that very satisfying because I
just see this as different amounts of network latency. Like if you’re
online you have network latency of 50 or 100 milliseconds. If you’re
offline, you have network latency of 3 hours or however long it’s going
to be until you next come back online again. To me those are exactly the
same, you know, I don’t care if it’s a few orders of magnitude apart.
Both the network latency both need to be dealt with and if we can use
the same techniques for dealing with both standard online latency and
being offline, that just simplifies the software dramatically.
00:23:25 - Speaker 2: Going back to sort of the infrastructure, fewer
moving parts thing and speaking to our personal motivations, for me, the
experience of running Hiroku was a big part of my motivation or fed into
my interest in this because Hiokku was an infrastructure business. I
didn’t quite grasp what that meant when we went into it. I just wanted
a better way to deploy apps, and in the end, I enjoy writing software, I
enjoy creating products that solve problems for people, but
infrastructure is a whole other game. And you know, it became the point
where once you’re, I don’t know if mission critical is the right word,
but just something people really care about working well and you’re in
the critical path.
So for example, our routing infrastructure, if it was down for 3
seconds, people would complain. So the slightest hiccup, and as they
should, that was part of the service that that company is providing, and
so that’s fair enough.
But then when I go, OK, well, I’m building software, when I think of,
for example, Muse, where I’m providing this productivity tool to help
people think and that sort of thing. I don’t want to be paged because
someone went to move a card 5 centimeters to the right and our server
was down or overloaded or something, so then they can’t move the card
and so then they’re writing into support angrily. I’m pretty
comfortable with there’s some kind of cloud syncing problem and OK, I
can’t easily like push my changes to someone else, and that is still a
problem, but it feels like it’s on this slightly different timeline.
You’re not just blocking the very most basic fundamental operation of
the software.
And so the idea that exactly as you said, it changes the economics, for
me personally, I want to spend more of my time writing software and
building products and less of my time setting up, maintaining and
running infrastructure. So I guess looking back on the two years that
have elapsed, I would say that this is probably, it’s hard to know for
sure, but the Inkot switch essays, there’s a number of them that I
think had a really good impact, but I think this one probably just my
anecdotal feeling of seeing people cite it by. it in Twitter comments
and things like that. It feels like one of the bigger impact pieces that
we published, and I do really see quite a lot of people referencing that
term, you know, we’ve sort of injected that term into discussion again,
at least among a certain very niche narrow world of things. So, yeah,
I’d be curious to hear from both of you, first, whether there’s things
that looking back you wish we’d put in or you would add now, and then
how that interacts with what you make of local first movement or other
work that people are doing on that now.
00:25:59 - Speaker 1: I’m very happy that we gave the thing a name.
There’s something we didn’t have initially when we started writing
this and we’re just writing this like manifesto for software that works
better basically.
And then at some point we thought like it would be really good to have
some way of referring to it and you know, people talk about offline
first or mobile first, and these were all kind of established things and
terms that people would throw around. And we also wanted some term X
where we could say like I’m building an X type app. And so I’m very
glad that we came up with this term they first because I’ve also seen
people even outside of our direct community starting to use it. And
just, you know, put it in an article casually without even necessarily
explaining what it means and just assuming that people know what it is.
And I think that’s a great form of impact if we can give people a term
to articulate what it is they’re thinking about.
00:26:50 - Speaker 2: Yeah, language, a shared vocabulary to describe
something as a very powerful way to, one, just sort of advance our
ability to communicate clearly with each other, but also, yeah, there’s
so many ideas. I mean, it’s a 20 something page paper and there’s so
many ideas, but you wrap this up in this one term and for someone who
has downloaded some or most of these ideas, that one term can carry all
the weight and then you can build on that. You can take all that as a
given and then build forward from there.
00:27:19 - Speaker 1: Yeah. One thing I wish we had done more on is I
think trying to get a bit more into the economic implications of it.
I guess that would have made the essay another 5 pages longer and so at
some point we just have to stop. But I feel like it’s quite an
important aspect like what we talked about earlier of not having to
worry about back ends or even just like not having to worry generally
about the distributed systems problem of like you make a request to a
server, the request times out. You have no idea whether the server got
the request or not. Like, do you retry it? If so, how do you make the
retry? Is that potent so that it’s safe to retry and so on. Like all of
those problems just go away if you’re using a general purpose syncing
infrastructure that somebody else has written for you. And there are
other implications as well that are less clear of what about the
business model of software as a service. Because there a lot of
companies’ business model right now is basically pay us, otherwise
you’re going to get locked out of your data. So it’s using this idea
of holding data hostage almost as the reason why you should pay for a
product. And you know, it’s like that with Slack. Like you put all of
your messages in Slack those messages were written by you and your
colleagues. There’s nothing really Slack did to own those, they just
facilitated the exchange of those messages between you and your
colleagues. But then once you go over the, whatever it is, 10,000
messages limit, then suddenly you have to pay slack to see the messages
that you wrote yourself. And generally that’s the business model with a
lot of software as a service. And with local first, it’s not clear that
that business model will still work so clearly. But of course, software
developers still have to be paid for their time somehow. So how do we
find a way of building sustainable software businesses for collaboration
software but without holding data hostage? I think that’s a really deep
and interesting question.
00:29:07 - Speaker 3: Yeah, I think as an aside that uh you might call
it the political economy of software is understudied and
underconsidered, and I would put in here like the economics of software
business, but also the interaction with things like regulation and
governments and the huge amount of path dependence that’s involved.
I think that’s just a huge deal.
I think we’re starting to realize it, but yeah, there’s a ton of stuff
we could do and think about just for local first. Like just one kind of
branch that I hope we get to explore is we mentioned how local first
enables you to do totally different topologies. So with cloud software
almost by definition, you have this hub and spoke model where everything
goes through. The central server and the central corporation. Well with
local first, you can very easily, for example, have a federated system
where you dial into one of many synchronization nodes and you could even
have more like a mesh system where you request and incentivize packets
to be forwarded through a mesh to their destination, sort of like TCPIP
networking, but for like the application layer, and it may be, you know,
it’s still kind of TBD but it may be that a mesh or a distributed
approach has totally different political implications from a centralized
node and that might become important, so. I just think there’s a lot to
think about and do here.
00:30:15 - Speaker 1: Yeah, I think so too.
And like, I would take email as an analogy maybe, which is a federated
system just like what you described, like you send your email to your
local SMTP server and it forwards it to the recipient’s SMTP server and
the system works really well.
Certainly as criticisms like spam filtering is difficult in a really
decentralized way.
Maybe spam is not a problem that local first software will have as much
because it’s intended more like for collaboration between people who
know each other rather than as a way of contacting people you don’t
know yet.
But certainly like I think taking some inspiration from that federation
and seeing how that can be applied to other domains, I think would be
very interesting.
00:30:55 - Speaker 3: Yeah, and this brings us to the topic of like
industrialization and commercialization, and I feel like there’s more
promise than ever around local First and more people are excited about
it, but I still feel like we’re just in the beginning phases of getting
the ball rolling on industrial and commercial applications. And if I’m
being really honest, I feel like it might have been slower than I had
initially hoped over the past few years, so I’m just curious if Adam
and Martin, you would reflect on that.
00:31:21 - Speaker 2: It’s always hard to say, right? The thing with
any technology, but certainly my career in computing, this has always
proven to be the case, is that something seems right around the corner
and it stays so for 20 years. I don’t know, maybe VRs in that category,
but then there’ll be a moment, suddenly it’ll just be everywhere,
broadband internet or something like that.
So as a people who are both trying to advance the state of the art but
also making Business decisions, you know, should I start a company?
Should I invest in a company? Should I keep working on the company I’m
working on based on what technologies exist or where you see things
going? Yeah, you’re always trying to make accurate predictions. So
yeah, I agree on one hand it felt very close to me on the basis of the
prototypes we’d built, the automerged library, the reference, Martin
I’ll link that in the notes here, but basically that’s a JavaScript
implementation of something called CRDTs which Just I guess as a
sidebar, it could be easy to think that CRDTs and local first software
are kind of one and the same because they are often mentioned together
and in fact our paper talks about them together, but CRDTs are a
technology we find incredibly promising for helping to deliver local
first software, but local first is a set of principles. It doesn’t
require any particular technological solution.
Yeah, based on the strength of those prototypes, many of which worked
really well, there’s the networking side of it and whether you can have
that be fully kind of decentralized versus needing more of a central
coordination server. But once you get past that hump, it does work
really, really well.
But I think that comes back to the point you both made there about the
economic model side of things, which is we have a whole software
industry that’s built around people will pay for software when there’s
a service connected to it.
Right, so Sass, in particular B2BASS is just a fantastic business to be
in, and as a result, we’ve seen a huge explosion of software around
that, but connected to that is, for example, the Fremium model, exactly
like what you mentioned with Slack, the docs is one of those. Notion is
one of those. They do this kind of free for individuals, but then you
pay when you’re a business and then you need to come up with the
feature stuff, the kinds of features that seem to be selecting for you
being a business with more serious needs and something like retaining
your message history is there.
I wrote a whole other shorter essay about paying for software. I’ll
link that in the notes, but I think we got into a weird corner. The
industry got itself into a weird painted itself into a corner because
Things like Google giving you so much incredibly high quality software,
Gmail, Google Docs, Google Maps, etc. for quote unquote free, but then
how you’re really paying for it is your attention and your data, right?
And that being kind of montizable through being able to essentially
serve you ads.
And I think that’s fine and I’m very glad for Google’s existence and
they found that model, but it almost feels like then it taught people
that good software should be free and that you shouldn’t pay for, maybe
that’s a little bit connected to the concept that software R&D
basically costs nothing to make additional copies of it. So therefore,
if you make this big upfront investment and then the software exists and
you can duplicate it endlessly, but I think there’s a lot of things
flawed about all of that. But the end place that gets you to is, OK, if
someone has my data and I’m paying them to maintain it and run the
servers that it’s on, I can stomach that. OK, now I’ll pay $5 a
month, $10 a month for my Dropbox account or something like that. But
other than that, we’ve become accustomed to, oh, if it’s an app on the
App Store, the App Store is a good example of these kind of consumer
economics, we just expect it to be vastly lower cost or free and good
software costs money to make, and as we kind of talked about earlier, I
would rather be building the software, not maintaining the
infrastructure, but when you set it up so that The only way you can make
money is to build software that has infrastructure, you’re actually
incentivized, build that back end as soon as you can and get the user’s
data in there and not necessarily hold it hostage, but just take
ownership of it, because that’s what people will pay for. They won’t
pay for software where they own the data themselves.
00:35:34 - Speaker 1: Yes, one thing that a friend has suggested is that
when talking about the business model of local first software, we should
just call it SA, like label it as SAS, market it in exactly the same way
as SAS. Don’t even tell people that it’s local first software and just
use the fact that it’s a lot cheaper and easier to implement local
first software and use that for your own benefit in order to build the
software more cheaply. But don’t actually market the local first
aspect.
And I thought that’s quite an interesting idea because, you know, it is
an idea that people are accustomed to and to be honest, I think the
amount of piracy that you would get from people like ripping out the
sinking infrastructure and putting it for something else and then
continuing to use the app without paying for it, it’s probably pretty
limited. So you probably only need to put in a very modest hurdle there
of say, OK, like this is the point at which you pay.
Regardless of whether that point for payment is, you know, necessarily
enforced in the infrastructure, it might just be an if statement in your
client side up and maybe that’s fine.
00:36:38 - Speaker 2: Muse is basically an example of that. We have this
membership model that is, you know, subscription is your only option and
there are a lot of folks that complain about that or take issue with it,
and I think there are many valid complaints you can make, but I think in
many cases it is just a matter of what.
Folks are accustomed to and we want to be building and delivering great
software that improves and changes over time and maps to the changing
world around it, and that’s something where as long as you’re getting
value, you pay for it and you’re not getting value anymore, you don’t
have to pay anymore. And then a model like that basically works best for
everyone, we think, again, not everyone agrees.
But then again, you do get this pushback of we are running a small
service, but it’s not super critical to the application, but maybe that
would be a good moment to speak briefly about the explorations we’re
doing on the local first sync side, Mark.
00:37:32 - Speaker 3: Yeah, so right now Muse is basically a local only
app, like it’s a traditional desktop app where files are just saved to
the local device and that’s about it, and you can manually move bundles
across devices, but otherwise it just runs locally and the idea is to
extend be used with first syncing across your devices and then
eventually collaboration across users using a local first approach.
Now we don’t plan to do, at least initially the kind of fully
distributed mesh networking peer to peer thing. It will be a sync
service provided by Muse and kind of baked in to the app, but it will
have all those nice local first properties of it works offline, it’s
very fast, all the different nodes are first class and so forth while
eventually supporting syncing and and collaboration.
So, yeah, we’re going through this journey of, we had a lot of
experience with um basic prototypes in a lab, but there’s a big jump to
have a commercialized and industrialized product, not just in terms of
charging for the business model and stuff, but in terms of the
performance and it’s like all the weird things that you deal with in
the real world, like versioning and schemas and the idiosyncrasies of
networking and All the things that go around the core functionality,
like one thing we’re thinking a lot about is visibility into the sync
status and how it’s different in a local first world. Yeah, so I’m
excited that we are now investing a lot in bringing local first into the
real world with MS.
00:38:57 - Speaker 1: Yeah, and I feel like more generally, if we want
the local first ideas to be adopted, we need to make it easy in a way
that people can just take an open source library off the shelf, not have
to think too much about it, plug it into their app, have a server
that’s ready to go, that’s either it’s already hosted for them or
they can spin up their own server and make that path. Super easy and
straightforward and that’s kind of where my research is focusing of
trying to get the technologies to that point.
So right now, we have some basic implementations of this stuff. So
automerge is a library that does this kind of data synchronization. It
includes a JSON like data model that you can use to store the state of
your application. It has a sort of basic network protocol that can be
used to sync up two nodes. But there’s so much more work to be done on
making the performance really good, like at the moment it’s definitely
not very good. We’re making progress with that, but it’s still a long
way to go.
Making the data sync protocol efficient over all sorts of different
types of network link in different scenarios, making it work well if you
have large numbers of files, for example, not just single file and so
on. And so there’s a ton of work still to be done there on the
technical side. I think before this is really in a state where people
can just pick up the open source library and run with it. Part of it is
also like just uh getting the APIs right, making sure it has support
across all the platforms, just having a JavaScript implementation is
fine for initial prototypes, but Obviously, iOS apps are written in
SWIFT and Android apps will be written in coin or whatever people use
and so you need to have support across all of the commonly used
platforms and we’re gradually getting there, but it’s a ton of work.
00:40:43 - Speaker 2: And conceptually seeing how autoerge is evolving.
And how people are trying to use it sometimes very successfully,
sometimes less so, but I see this as a case of technology transfer,
which is an area I’m incredibly interested in because I think it’s
kind of a big unsolved problem in HCI research, computer science,
honestly, maybe all research, but I’ll stick to my lane in terms of
what I know, which is there is often this very excellent cutting edge
research that does sit in the labs.
So to speak, and never graduates or it’s very hard or there isn’t a
good path often for it to jump over that hump into what’s needed in the
production world and of course in the research world you’re trying to
do something new and different and push the boundaries of what was
possible before and in the production commercial side you want to choose
boring technologies and do things that are really reliable and known and
stable, and those two, there’s often a bridge that’s hard to divide
there.
Sitting in your seat as again someone who’s enmeshed in the academic
world right now and you’re creating this library, you know, started as
a called a proof of concept for lack of a better term, and then you have
customers if that’s the right way to put it, but as an academic you
would Shouldn’t have customers, but you sort of do because people want
to use this library and in fact are for their startups and things like
that.
How do you see that transition happening or is there a good role model
you’ve seen elsewhere or just kind of figure it out as you go?
00:42:16 - Speaker 1: Well, I think where we’re trying to go with this
is it’s great for automerge to have users. I don’t think of them as
customers. I don’t care about getting any money from them.
But I do care about getting bug reports from them and experienced
reports of how they’re getting on with the APIs and reports of
performance problems and so on.
And those things are all tremendously valuable because they actually
feed back into the research process and so I’m essentially using the
open source users and the contributors as a source of research
problems.
So with my research hat on, this is great because I have essentially
here right in front of me a goldmine of interesting research problems to
work on.
I just take like the top issue that people are complaining about on
GitHub, have a think about how we might solve that. And often there’s
enough of a nugget of research problem in there that when we solve the
problem, we can write a paper about it.
It can be an academic contribution as well as moving the open source
ecosystem gradually towards a point where we’ve ironed out all of those
major technical problems and hopefully made something that is more
usable in production.
So, I actually feel those worlds are pretty compatible at the moment.
There are some things which are a bit harder to make compatible like
sort of the basic work of porting stuff to new languages on new
platforms, that’s necessary for real life software engineering, but
there’s no interesting research to be done there, to be honest. But so
far I’ve found that quite a lot of the problems that we have run into
actually do have interesting research that needs to be done in order to
solve them. And as, as such, I think they’re quite well compatible at
the moment.
00:43:56 - Speaker 2: And like imagining or the mental picture of
someone submits a bug report and one year later you come back and say,
here’s the fix and also the paper we published about it.
00:44:08 - Speaker 1: I’ve literally had cases where somebody turns up
on Slack and says, I found this problem here. What about it? And I said,
oh yeah, I wrote a paper about it. And the paper has a potential
algorithm for fixing it, but I haven’t implemented it yet, sorry.
And they go like, WTF what you put all of this thought into it. You’ve
written the paper. And you haven’t implemented. And I go, well,
actually sorry for me, that’s easier because if I want to implement it,
I have to put in all of the thoughts and convince myself that it’s
correct. And then I also have to implement it and then I also have to
write all the tests for it and then I have to make sure that it doesn’t
break other features and it doesn’t break the APIs and need to come up
with good APIs for it and so on.
So for me actually like implementing it is a lot more work than just
doing the research in a sense, but actually, Doing the research and
implementing it can be a really useful part of making sure that we’ve
understood it properly from a research point of view. So that at the end
what we write in the paper is ends up being correct.
In this particular case, actually, it turned out that the algorithm I
had written down in the paper was wrong because I just haven’t thought
about it deeply enough and a student in India emailed me to say, hey,
there’s a bug in your algorithm, and I said, yeah, you’re right,
there’s a bug in our algorithm. We better fix it.
And so probably through implementing that maybe I would have found the
bug, maybe not, but I think this just shows that it is hard getting this
stuff right, but the engagement with the open source community, I found
a very valuable way of Both working towards a good product but also
doing interesting research.
00:45:39 - Speaker 3: I think it’s also useful to think of this in
terms of the research and development frame.
So research is coming up with the core insights, the basic ideas, those
universal truths to unlock new potential in the world, and it’s my
opinion that with local first, there’s a huge amount of development
that is needed, and that’s a lot of what we’re doing with Muse. So
analogy I might use is Like a car and an internal combustion engine. If
you came up with the idea of an internal combustion engine, that’s
amazing. It’s pretty obvious that that should be world changing. You
can spin this shaft at 5000 RPM with 300 horsepower, you know, it’s
amazing, but you’re really not there yet. Like you need to invent
suspension and transmission and cooling and It’s kind of not obvious
how much work that’s gonna be until you go to actually build the car
and run at 100 miles an hour.
So I think there’s a lot of work that is still yet to be done on that
front. And eventually, that kind of does boil down or emit research
ideas and bug reports and things like that, but there’s also kind of
its own whole thing, and there’s a lot to do there.
There’s also a continuous analogy. I think once the research and the
initial most obvious development examples get far enough along, you
should have some. Unanticipated applications of the original technology.
So this should be someone saying like, what if we made an airplane with
an internal combustion engine, right? I don’t think we’ve quite seen
that with local first, but I think we will once it’s more accessible,
cause right now to use local first, you gotta be basically a world
expert on local first stuff to even have a shot. But once it’s packaged
enough and people see enough examples in real life, they should be able
to more easily come up with their own new wild stuff.
00:47:11 - Speaker 1: Yeah, we have seen some interesting examples of
people using our software in unexpected ways.
One that I quite like is the Washington Post, as in the newspaper,
everyone knows. They have an internal system for allowing several
editors to update the layout of the home page. So the placement of which
article goes where, with which headline, with which image, in which font
size, in which column. All of that is set manually, of course, by
editors.
And they adopted automerge as a way of building the collaboration tool
that helps them manage this homepage. Now, this is not really a case
that needs local first, particularly because it’s not like one editor
is going to spend a huge amount of time editing offline and then sharing
their edits to the homepage.
But what I did want is a process whereby multiple editors can each be
responsible for a section of the homepage and they can propose changes
to their section. And then hand those changes over to somebody else
who’s going to review them and maybe approve them or maybe decline
them. And so what they need essentially is this process of version
control, Git style version control almost, but for the structure of
representing the homepage.
And they want the ability for several people to update that
independently. And that’s not because people are working offline, but
because people are using essentially branches using the Git metaphor.
So different editors will be working on their own local branch until
they’ve got it right and then they’ll hit a button where they say, OK,
send this to another editor for approval. And that I found really
interesting. It’s sort of using the same basic technologies that we’ve
developed with CRTTs, tracking the changes to these data structures,
being able to automatically merge changes made by different users, but
applying it in sort of this interesting unexpected context. And I hope
like as these tools mature, we will expand the set of applications for
which they can be sensibly used and In that expansion, we will then also
see more interesting unexpected applications where people start doing
things that we haven’t anticipated.
00:49:19 - Speaker 2: Maybe this reflects my commercial world bias or
maybe I’m just a simple man, but I like to see something working more
than I like to read a proof that it works.
And both are extremely important, right? So the engineering approach to
seeing if something works is you write a script, you know, fuzz testing,
right, you try a million different permutations and if it all seemed to
work, kind of the Monte Carlo simulation test of something, and it seems
to work in all the cases you can find, so it seems like it’s working.
And then there’s, I think, the more proof style in the sense of
mathematical proof of here is an airtight logical deductive reasoning
case or mathematical case that shows that it works in all scenarios that
it’s not a Monte Carlo calculation of the area under the curve, it’s
calculus to determine precisely to infinite resolution area to the
curve.
And I think they both have their place kind of to Mark’s point, you
need to both kind of conceptually come up with the combustion engine and
then build one, and then all the things that are gonna go with that.
And I think we all have our contributions to make.
I think I probably, much as I like the research world at some point when
there’s an idea that truly excites me enough, and local first broadly
and CRDT. in this category, and I wanna see it, I want to try it, I want
to see how it feels.
In fact, that was our first project together. Martin was, we did this
sort of trello clone essentially that was local first software and could
basically merge together of two people worked offline, and they had a
little bit of a version history. I did a little demo video, I’ll link
that in the show notes.
But for me it was really exciting to see that working, and I think maybe
your reaction was a bit of a like, well, of course, you know, we have 5
years of research. Look at all these papers that prove that it would
work, but I want to see it working and moreover feel what it will be
like because I had this hunch that it would feel really great for the
end user to have that agency. But seeing it slash experiencing it, for
me that drives it home and creates internal motivation far more than the
thought experiment is the right word, the conceptual realm work, even
though I know that there’s no way we could have built that prototype
without all that deep thinking and hard work that went into the science
that led up to it.
00:51:42 - Speaker 1: Yeah, and it’s totally amazing to see something
like working for the first time and it’s very hard to anticipate how
something is going to feel, as you said, like you can sort of
rationalize about its pros and cons and things like that, but that’s
still not quite the same thing as the actual firsthand experience of
really using the software.
00:52:01 - Speaker 2: All right, so local first, the paper and the
concept, I think we are pretty happy with the impact that it made, how
it’s changed a lot of industry discussion, and furthermore, that while
the technology maybe is not as far along as we’d like, it has come a
long way, and we’re starting to see it make its way into more real
world applications, including news in the very near future. But I guess
looking forward to the future for either that kind of general movement
or the technology. What do you both hope to see in the coming, say, next
2 years, or even further out?
00:52:38 - Speaker 3: Well, the basic thing that I’d like to see is
this development of the core idea and see it successfully applied in
commercial and industrial settings. Like I said, I think there’s a lot
of work to do there and some people have started, but I’d like to see
that really land. And then assuming we’re able to get the basic
development landed, a particular direction I’m really excited about is
non-centralized topologies. I just think that’s going to become very
important and it’s a unique potential of local first software. So
things like federated syncing services, mesh topologies, end to end
encryption, generalized sync services like we talked about, really
excited to see those get developed and explored.
00:53:18 - Speaker 1: Yeah, those are all exciting topics. For me, one
thing that I don’t really have a good answer to but which seems very
interesting is what does the relationship between apps and the operating
system look like in the future? Because like right now, we’re still
essentially using the same 1970 Unix abstraction of we have a
hierarchical file system. A file is a sequence of bytes. That’s it. A
file has a name and the content has no further structure other than
being a sequence of bytes.
But if you want to allow several users to edit a file at the same time
and then merge those things together again, you need more knowledge
about the structure of what’s inside the file. You can’t just do that
with an opaque sequence of bytes. And ICRDTs is essentially providing a
sort of general purpose higher level file format that apps can use to
express and represent the data that they want to have just like Jason
and XML are general purpose data representations and CRDTs further
refined this by not just capturing the current state, but also capturing
all the changes that were made to the state and thereby they much better
encapsulate the what was the intent of the user when they made a certain
change and then capturing those intents of the user through the
operations they perform that then allows different users changes to be
merged in a sensible way.
And I feel like this idea of really changes the abstractions that
operating systems should provide because maybe OSs should not just be
providing this model of files as a sequence of bytes, but this higher
level CRDT like model and how does that impact the entire way how
software is developed.
I think there’s a potential for just rethinking a lot of the stack that
has built up a huge amount of craft over the past decades. And potential
to like really simplify and make things more powerful at the same time.
00:55:17 - Speaker 2: Yeah, local first file system to me is kind of the
end state, and maybe that’s not quite a file system in the sense of how
we think about it today, but a persistence layer that has certainly
these concepts baked into it, but I think also just reflects the
changing user expectations.
People want Google Docs and notion and Figma. And they expect that their
email and calendar will seamlessly sync across all their devices and
then you have other collaborators in the mix, so your files go from
being these pretty static things on the disk, you know, you press
command S or ControlS and every once in a while it does a binary dump of
your work that you can load later and instead it becomes a continuous
stream of changes coming from a lot of different sources.
They come from, I’ve got my phone and my computer and Mark’s got his
tablet and his phone, and Martin, you’ve got your computer and we’re
all contributing to a document and those changes are all streaming
together and need to be coalesced and made sense of.
And I think that’s the place where, for example, Dropbox, much as I
love it, or iCloud, which I think in a lot of ways is a really good
direction, but both of those are essentially dead ends, because they
just take the classic static binary file and put it on the network,
which is good, but it only takes you so far, cause again, people want
Google Docs, that’s just the end of it.
And that puts every single company that’s going to build an application
of this sort. They have to build the kind of infrastructure necessary to
do that. And we’ve seen where I think FIMA is the most dramatic
example, they just took sketch and ported it to a kind of a real-time
collaborative web first environment, and the word just there is carrying
a lot of weight. Because in fact, it’s this huge engineering project
and they need to raise a bunch of venture capital, but then once you had
it, it was so incredibly valuable to have that collaboration, and then,
of course, they built far beyond the initial, let’s just do sketch on
the web. But any company that wants to do something like that, and
increasingly that’s not table stakes from user expectation standpoint,
they want to be able to do that, but you have to do that same thing.
You’ve gotta drop, you know, tens of millions of dollars on big teams
to do that. It seems strange when I think many and most at least
productivity applications want something similar to that. So, if that
were built into the operating system the same way that a file system is,
or, you know, we proposed this idea of like a firebase style thing for
local first and CRDTs which could be maybe more developer
infrastructure, maybe that’s also what you guys were speaking about.
Earlier with kind of like AWBS could run a generic sync service. I
don’t know exactly what the interface looks like, it’s more of a
developer thing or an end user thing, but basically every single
application needs this, and the fact that it is a huge endeavor that
costs so much money and requires really top talent to do at all, let
alone continue running over time and scale up, just seems like a
mismatch with what the world needs and wants right now.
00:58:25 - Speaker 3: Yeah, and now I want to riff on this, Adam,
because the strongest version of that vision is not only are all these
apps using a local first file system, they’re all using the same one in
the same way that now for our legacy apps, all your files from different
applications are written to the same disk in the same way.
And furthermore, any application can access and read and write any other
data, so you sort of disconnect the data from the application. And you
can end to end them on top of each other.
And then this gets to the final thing here, which is one of those
programs could be programs that users right.
So you sort of end user programming against real-time synced and
collaborative data.
And not only is that cool because end user programming is interesting,
but programming against data doesn’t really work when it’s halfway
around the world, like it just kind of physically, if you need to
navigate the data or follow links, it’s just too slow. You need all the
data locally, which is indeed the whole promise of what we’re talking
about here.
00:59:23 - Speaker 2: Well, not to mention maybe the off token dance and
whatever, and you’ve got to register your application. It just comes
back to this, yeah, end user programming is 100% about agency, which, as
we said in the start is kind of at the core of local first, and yeah,
it’s gotten increasingly harder to program your own stuff for a bunch
of reasons, but one is, yeah, the data is way over there and in the care
of this company and they give you their one front end to it.
If you’re very lucky, they’ll build an API and if you’re even
luckier, they’ll.
You allocate an API token as an individual, not a company, to just write
a little script to do something, whereas I did a lot more automation in
my personal life back when so much was just a Unix shell and a file
system on my local computer and a world where you can write, not so much
scripts, but I think of them more as bots.
I think we even Prototype this at the very tail end of that Trello clone
project which as we said, now that you’ve got this stream of changes
that you are consuming from different places, the bot could be just one
more of these.
And if you want to do something like automatically moving a card to a
new location when something is triggered, that should be straightforward
to do.
And some world like that, where you have now these streams of events,
streams of data that they are being coalesced, that includes not just
the devices of all the people, but also the individual programs that you
may choose to write that sort of contribute to this whole evolving
document. That’s a very exciting future for me.
01:00:55 - Speaker 1: Yes, and if we can get to that point where it’s
so easy to write the collaborative software that you can just have
software be collaborative by default. And so easy to have this streaming
integration with bots that you just do it by default. Then we’re in a
situation where like this can actually be used in practical reality.
01:01:15 - Speaker 2: Well, I think we should wrap it there. Thanks
everyone for listening.
If you have feedback, write us on Twitter at @museapphq, and we’re on
email, hello at museApp.com.
You can help us out with a review on Apple Podcasts, and Martin, I’m so
glad that you’re pushing this vision of the world forward, even though
we’re not working together as directly right at the moment.
We hope that our efforts over here to try to prove local first in a
commercial context, both that it can be viable for a small team. but
also produces a great user experience that’s at least for now our
contribution, and you’re continuing to push the state of the art in the
science world.
Hopefully we can together and along with all the other folks who are
doing great work in this field, see it reconvene maybe in 2 years and
have some good news to report.
01:02:04 - Speaker 1: Definitely. Thanks for having me.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Also, in your field that you say, OK, I need this
programmer with this designer and together with them and the right
vision, we can build something. I think it’s very similar with film
production. We all work at the end of what’s possible, and we want to
go beyond.
00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
thought on iPad, but this podcast isn’t about Muse the product, it’s
about Muse the company and the small team behind it. My name is Adam
Wiggins. I’m here with my colleague Mark McGranaghan. Hey, Adam. And
joined today by Maximilian Becht of Cosmovision.
00:00:41 - Speaker 1: Hi Adam. Nice to meet you.
00:00:43 - Speaker 2: And Max, I know you just got back from a pretty
intense film shoot. Tell me about that.
00:00:47 - Speaker 1: Yeah, I’m just back in Berlin. I was shooting for
30 shooting days. That’s like a little bit more days all around it
because we had 6 weeks of prep and 6 weeks of shooting and now 2 weeks
of. Post production for my production team. I was a production manager,
shooting theatrical movie in southern Germany and this was my rough
summer and yeah, I’m looking forward to be back in Berlin and have a
good conversation with you today.
00:01:20 - Speaker 2: Yeah, the intensity of these shooting schedules. I
used to live in Los Angeles, and had a lot of friends that were in
Hollywood, and I think sometimes it’s nice to have sort of an intense
work period, but then maybe a longer break in between, but it often was
quite surprising to me. Puts even the intense work schedules of Silicon
Valley, gives it a run for its money, you might say.
00:01:41 - Speaker 1: Yeah. I think for the last weeks, my workdays had
around 12 to 15 hours and the weekends were not really weekends. So
it’s like a vacation camp. This filming feels sometimes like this
sprint. Maybe you can compare it to the tech industry when you really
have this one project, this one program you want to finish and you
really give every effort and After it, you feel it drops sometimes in
like an emotional hole because you’re way, there’s something missing.
I have to be working right now, not, so you were always wondering, oh
yeah, what’s happening.
00:02:20 - Speaker 2: Actually I have very strong memories of my first
experience of exactly that drop, which was in the video game industry at
the beginning of my career.
And we were just working these, yeah, basically every waking moment for
weeks on an E3 demo, so E3 was the big conference, you gotta have a
great demo, and I remember when we finally, well, we shipped it because
E3 happened, so there was no more time.
After that, I just didn’t know what to do with myself for a day. I
couldn’t remember what my life was like when it wasn’t just nonstop
working, not a great place to be. But in a way, it had its moments,
maybe because I was sort of young and had no other responsibilities in
my life.
00:02:57 - Speaker 1: Yeah, I’m always reflecting on that part, whether
how much energy and, yeah, you put into your work. And with film, it’s
always because it’s a passion thing for most of the people I know, that
way it’s hard to divide it strictly between your personal life and your
professional life because you always do it out of a passion, out of the
lust to really create awesome images, awesome films.
00:03:25 - Speaker 2: Yeah, definitely a problem we have in the software
world as well. So Max, you’re a video producer or a film producer, I
don’t know exactly how you title yourself, but tell us a little bit
about your background, how you got into this field.
00:03:37 - Speaker 1: Yeah, I’m a film producer. I would specify it
more as a creative producer because I like to create a content and
develop content together with someone, but also have the production side
in my head to know how to finance a product, how to organize the
product, and how to really finish it in the end.
But the part at the beginning where you develop a story where you
imagine ideas, where you Look for a concept that’s the part I like most
about filmmaking.
I, after my A Levels, I had some years of internships with production
companies and working on sets as a runner, set runner, you are on a film
set and see that all the infrastructure is working well. You run from
the set to the base to get a cable or something or to grab a coffee for
some important person. But that way you learn the infrastructure, the
how film work, how every department has its purpose on the set. And then
I applied for film university in southern Germany at Film Academy, uh,
Baden Wittenberg. It’s a very renowned film school and yeah, I studied
5 years of film there. I produced several short films, mid-length films.
With different formats like starting with uh fiction, also documentary,
but also I got glimpses into animation, visual effects, and interactive
storytelling. And now I’m back in Berlin and I have my own company, my
own office, and I work as a freelance producer for other companies, but
also try to develop my own stories together with writers, directors, and
I offer my services to companies who needs a sparing partner to produce
and develop content.
00:05:40 - Speaker 2: And I’ll link folks to your portfolio, there’s
quite a diversity, as you said, there’s, including these short fiction
films, you could say maybe high concept or things that maybe submit to
film festivals, that sort of thing, very artistic, maybe those are more
labors of love, and then you also have things that are maybe more
commercial in nature, so there’s quite a variety, although my feeling
and maybe part of why I was drawn to it and we’ll talk soon about how
it is that we came to work together, but it seemed like a lot of your
work, whether it’s maybe fiction isn’t quite the right word, but a
story versus documentary, it seemed like you really focused on the
people, the characters, showing their lives, their environments. It
feels like that’s a, it’s quite a theme, but at least I saw that
across your portfolio, but.
00:06:26 - Speaker 1: Yeah, always people ask what kind of films you
like to do, but this question is hard for me to answer because there’s
no genre I would like to be in or just one field, like I’m just a
commercial producer or I just do documentaries or nature films.
My engine for motivation for filmmaking is always the story and what is
behind it.
Like, for me, a story has to make sense, has to have an impact and has
to be of a topic I find of relevance. So there has to be some kind of
political or I would say, the value which a film contributes or puts to
the screen that has something I share.
And at the same time, film can be an experimental way of pushing
boundaries in fields you also find interesting or getting into topics
you don’t know anything about, but you want to learn more about.
So I give one example. For example, I am producing a documentary about
prison television station in a German high security prison. So I don’t
know anything about prison. I’m lucky to not have been in one yet, but
I was really curious how criminals Live in German high security prisons
and how is their view on media and how do they consume media and what it
would be if they produce an on television channel.
So, this changed my perspective. on how we in a society want to handle
people who don’t follow the laws. And if you have been in a prison, you
know what it’s like to be in there. So that’s a reflection I find very
valuable for me.
00:08:19 - Speaker 2: So our topic today is filmmaking, perhaps
obviously, and there’s two reasons for this. It might seem like a bit
of a non sequitur compared to our usual world of product design and
having ideas and so on, but There’s 2 layers here, 2 reasons to talk
about this today. One is I’m really interested in the creative
process.
Generally, I read a book some years back called Making Movies. I’ll
link that in the show notes. I’ve even mentioned here before maybe, and
I was really struck by how much similarity there is, not on the
practical level of what you do in terms of how films are made. Shooting
and getting actors together and things versus writing code, but that
there’s a lot of similarities between making great software products
and making films, where they have this pragmatic aspect as well as this
artistic aspect as well as this team aspect. And so I thought it would
be really interesting to dig into the creative process there and find
those parallels. But the other reason is that we are doing a little
experimental, let’s say a little launch of a small film project. That
you and I worked together on Max along with a couple other folks on our
film crew, to create a sort of mini documentary series about the
creative process. So, just to briefly speak to that, that’s called
Create. And I’ll link the launch memo, as well as the pilot episode
here, and you can read all about why we wanted to do that, why we think
that’s really relevant to Muse and our mission, but I thought it would be
great to talk a little bit about the experience of working together on
that and how we ended up at this final result.
00:09:53 - Speaker 1: Yeah, I was kind of surprised to be contacted by
you because you’re an American company and I’m here.
Upcoming film producer, I just finished my study two years ago and
building up my portfolio and I was not actively reaching out to people,
but I’m open for, because I’m always also busy with other projects,
but I find your reaching out to me very interesting because your product
was something very cool because I use productivity apps myself as well
and I’m not an iPad user, so I didn’t know Muse, but as I think I got
a, a fast idea what it was about, and I was thinking to myself, OK, what
kind of content would you want or need? Did you want something animated
to like show what your app can do best? And I was Very happy to see that
you wanted something bigger or wider than that. So that stands more for
the core values or ask the question about what Muse stands for and how
does branded content work? Because I share the idea that a good
commercial is not always showing all the benefit of a specific product,
but to Show what it stands for or what the idea is behind it. And I
thought it was very powerful to search for creatives and people who have
very unique ways of working and their own way of productivity and where
do they have their source of, yeah, structure of energy, of creativity.
00:11:47 - Speaker 2: So it’s just a tad more context. I think what we
wanted to do here, you mentioned the term branded content, which I think
is kind of a film concept that I guess there’s what you would call
traditional commercials, and so those are usually sleekly made, they’re
usually 30 seconds, and they show, maybe there’s something clever or
funny, but they show really directly.
Here’s this product, it exists, here’s why you might want it, you
know, linked to a place you can download it or buy it or whatever, and
those are fine. Certainly for the Muse brand generally, but also for me
personally, I saw a more interesting opportunity, or at least for me
more compelling than a classic advertisement was instead to take what we
had learned through interviewing with really hundreds of creative
professionals in our research lab days and now thousands that we’ve
interacted with, maybe tens of thousands through our support channels
and try to tell their stories. Cause it really struck me that, I mean,
use exists because of this research that we did, of going to people who
make things, create, call them knowledge workers, I usually go with
creative professionals, but think people who make things and inspiring
things to me, and try to understand how they work, and in particular,
we, we narrowed in on the ideation process, that early stage is
something that’s not really well supported by computers, and this is
why Muse exists. And so the contents of those interviews, those early
interviews are things that are all now essentially baked into the
product, all the insights we got from those interviews. But as I speak
to people individually and feel inspired by that, again, now just kind
of through supporting our product naturally, but even if I flip back
through the old interviews and review them, and I think there’s some
amazing stories here and some amazing creators, what’s another way that
we can share that stuff and film seemed like the right media for that.
00:13:38 - Speaker 1: Yeah, I think we are also still on the journey
with the product because at the beginning, we said, OK, let’s talk to
one or two people and we find the right one and we’ll do one shooting
day and then we have our product.
Then on the way, we saw that we have to meet so much more people, have
to prepare, like we have to get to know them a lot better before really
deciding on.
They are the protagonists for our shooting day because we have just one
shooting day. That’s a budget wise restriction or also, I think for
this format, 5 minutes, 1 shooting day should be enough. And we have to
kind of know the script before we shoot. So the script and a documentary
portrait may seem kind of OK. This does not make sense, but It makes
sense in a way that we need to know before what kind of facets of a
specific person we want to show, because I think everyone has so much
interesting stuff to tell, but for us and for this product, we need to
condense it and also we need to find visually compelling situations that
are not just someone sitting in his flat and talking to the camera, but
also doing something and That with, I think a lot of your users are not
people who build something with their hands, but also are programmers
and people who have very static work environments, but they have also
sites in their lives which are visually interesting if they do sports to
clean out their head or something like that. So we had to find that with
the protagonists.
00:15:26 - Speaker 2: Yes, so for me it was surprising that how much of
your time, and particularly how much of the director, that’s Marcus
Hannaish, how much of his time, and the cameraman, how much of their
time was this, I guess, scoping locations to shoot, they would have
things that were visually interesting, so that we can better relevant to
the story that we want to tell.
So, clearly you got these protagonists, as we’re calling the subject of
the film, they do inspiring work and you see that in the end result, but
how they do that work doesn’t, I don’t know, if you’re filming
athletes, for example, that’s a naturally very dynamic thing, or
they’re out in nature or whatever, so how do we make visually
interesting film out of this, and that was a big part of the film based
or the visual storytelling that for me was totally new.
00:16:16 - Speaker 1: Yeah, I think this is a good bridge to tell
something about, because I’m the producer of this product, but this
film was made with a lot of effort of Marcus, the director, and Jasper,
the cameraman. And we also had more with our sound designer and music
composer. So I wanted maybe to share something about how this team came
together because my process from starting at the beginning was to
propose several directors to you because I thought it would be
interesting to get Different ways of thinking how this format could
work. So I looked in my bubble kind of what are the directors I know or
I heard of which are interesting.
00:16:59 - Speaker 2: In the tech world we’d say your network.
00:17:00 - Speaker 1: Yeah, in my network.
I just didn’t find the word but yeah network bubble, yeah, and I
contacted them and I pitched the idea and then I wanted them to not know
everything about our product, but to come up with something, a visual
world, storytelling, a kind of a style. Even if it’s kind of similar,
every director has its style and he has work he can show which reflects
the style, but he also can look for skills for images which could go in
the direction of what we want to produce and You liked what Marcus was
doing and that was a very good coincidence for me because I worked with
him before on a short film and also with the cameraman. So we were a
good team already because that’s also a very big thing in film industry
is the creative trust. That we know how the other works and what the
other needs for his work, how much time and how much feedback and how
much input a director and a cameraman need and how a producer can work
with them. It’s always new to find out and every relationship is so
different, but this was very good for me and I think for the product
that we already knew each other and knew how to Work together.
00:18:25 - Speaker 2: Creative trust is absolutely something that’s
necessary in making great software products as well. I mean, I think
part of why certainly Mark and I are working together on this venture as
well as Julia. We had all worked together before, we know we work well
together and when we had a new product we wanted to pursue through a new
venture, you could say we de-risked, but you’re just excited to work
again with someone that you know you have that working chemistry with.
One interesting piece of the story here as well is it should be noted
that of course we’re not a venture funded startup with a lot of money
to spend on some kind of slick production, so we were looking for
something we could really do on a shoestring budget, and I had kind of
assumed we’d be able to, or what I was looking for actually when I went
searching was someone who was kind of all in one, right? Someone who
could film and produce and do the software editing and I don’t know, we
could talk about some of the software tools after effects and That sort
of thing if we want, but that exists now, particularly with the YouTube
world of things. There are people who are all in one, and of course, if
you’re a generalist, you can’t be great at each individual thing, but
you can make something pretty solid. And you, when I approached you and
said, I like your work, and you pitched me on, look, we can get a crew,
probably helps a lot that we’re here in Berlin, which increasingly does
have a pretty impressive film scene, I think a lot of things like
Queen’s Gambit was shot here, a lot of other Netflix films, some of the
Apple stuff like the foundation series. was shot here, but also probably
in general, just wages overall are sort of a bit lower than they would
be in, I don’t know, let’s say California. And so all of that means
that probably we can shoot. More cheaply than we would in other places.
But you convinced me, look, I think you’ll be better off with the crew.
I can get a crew together, we shoot it in one day, we can do it on a
budget that’s within reach for us, and the quality and the
professionalism and just the power of the story you can tell will be
much better, and I was compelled by that, which is why we went forward
with that.
00:20:19 - Speaker 1: Yeah, I think a big strength of mine is when I can
tell it like that, that I have worked in so many different fields of
work from a documentary style, really a one or two film team to a big
set of up to 100 people.
And each product in the end was good, but you have to find out what is
necessary and what it means. And I think there’s a difference between
the One guy who films, does the concept, edits, of course, he can do
with a budget of something.
For him, it’s so much more, but he does not have the reflection with
someone else to really come up with a high concept and a high visual
concept.
And if you put together director and cameraman, even those two people,
they work and discuss a visual style for this product. And if you put in
A sound designer and music composer, you have someone really taking care
of the sound level, which often is falling under the table.
But for me, it was pretty clear, OK, we need someone like that to,
because we have a small production crew, the sound will be kind of
rough, recorded. We need someone who cleans it at the end and to just a
little bit of sound design, mixing and composing. So we have audio that
you really Like and which has a production value in the end.
Film is doing art. Also, if it’s for a company or like for a brand, it
still is an artistic way of working and of course, you could have find
someone who really sees it as just the product, but for me, even so,
it’s always searching for an artistic, unique piece and not something.
Which repeats something already, which already exists. I like to really
create and that’s also the title of this, create something new, which
each piece I do produce and collaborate with others.
00:22:25 - Speaker 3: Yeah, and I think this idea of creative energy is
really important, and it’s one of the reasons I was so excited about
this series.
We’ve talked on this podcast before about how creative or
entrepreneurial act is so unnatural, and you really need some impetus
and reason to do it. And obviously, you’re discussing how that’s the
case for you, even for a project like this.
But also with the series, my hope is that it causes a sort of creative
contagion, where when you see someone Doing beautiful, inspirational
work, you are more inclined to do it yourself.
And I think we are sometimes reluctant to admit how big of a factor that
is. And you can see this in practice because there are these huge
creative clusters like San Francisco and Berlin, where if you are there,
or increasingly the equivalent virtual ones, you’re just much more
likely to be doing that sort of creative work. So I’m hoping we can get
some of that contagion going with the series.
00:23:17 - Speaker 1: What really was a discovery for me, producing or
researching the protagonist, we were sometimes going in the direction,
OK, let’s search for the most renowned or most famous artist or
programmer or whatever person we know, which could be an interesting
protagonist.
But on the way, we also thought, OK, let’s search for the more regular
guy or regular women and We talked to so many different people and
everyone seemed like kind of a small superhero when we got to know
them.
Even if they are not well known, they are at the beginning of their
professional career, they are a freelancer, just earning their money by
doing their job, but also they have such unique And interesting styles
and way of working and how to re-energize themselves in their private
life and how to balance themselves.
These are also important questions for my own life because work-life
balance always problematic in the film industry, but Besides that, I was
just so compelled by what these people said, so that I thought, this is
kind of the gold piece.
If we can, in the series, get something to really get to know the guy or
the women around the corner and search for their unique magic in their
work. What’s so unique about their work and how they do it. And each
episode shows a little different side, a little different angle of
someone’s work. And that adds something to your own view on your own
work and on your collaboration with your colleagues. And that would be
something I would really love to achieve with a series like that.
00:25:12 - Speaker 3: This is one of the reasons why I love the maker
biography genre, which is a term that at least Adam and I have given to
these studies of individual creative lives, because when you look at an
individual life, and you look not just at their eventual accomplishments
and triumphs, but the whole process, it’s this incredible fractal,
detailed, ultimately beautiful thing where there’s all these, you know,
struggles and you know syncrasies and weird ups and downs and weird
habits and stuff and That’s something you can only get if you look at
an individual life. If you zoom out to all people who, you know, paint
stuff, what are you gonna say, oh, you know, they study colors and they
put stuff on a canvas and some of it’s good, you know, but if you look
at the individual, you learn about their studio and their upbringing and
how they got inspired and their individual subjects, it’s so rich. So
I’m a big fan of this genre.
00:25:58 - Speaker 2: Yeah, Mark, I think you coined the term, or at
least as far as I know, the Maker biography, but maybe it was when we
were speaking about that I kind of had discovered this what felt like a
genre of book, but I guess it’s just biographies about people who start
companies or do science or make art, and it’s really not just about
seeing that final piece that final result of their work, which you may
already know if they are someone famous, but actually the process how
they get there.
So for example, I read a biography of Charles Darwin. Recently that kind
of talked about his, you know, life journey. I’ve read a lot of famous
scientists biographies, but there’s also entrepreneurs and product
creators, so there’s something like there’s an autobiography by the
Pixar founder and CEO, super interesting story there, or there’s a
biography of Ruth Handler, who started Mattel, and basically invented
the Barbie, has a really interesting entrepreneurial life and journey.
So there’s a number of these, but to me it’s the behind the scenes.
It’s the struggles they went through, the false starts, the uncertainty
that they experienced along the way.
It’s that journey, and that is so inspiring to me because I’ve been
through that journey, obviously not on the scale of success of those
folks I just mentioned, but they’re similar, right? And that’s part of
what we’re hoping to get in this series is. You watch each of these
individual ones and even if these folks do very different work from
whatever your particular discipline is, you see something similar in
their journey or as much of it as we can show in the 4 minutes or so we
have budget to film.
00:27:33 - Speaker 1: What I would be curious because we kind of also
want to find the similarities or differences between filmmaking and the
tech industry and your software programming.
I think a lot of your work is also to reflect the product and ask the
people how do they find it, how you can make it better and You really
always updated your product and with the film, it’s always or mostly a
finished product and then you get the feedback.
Sometimes you have the money and the effort to get a test screening and
of course you have feedback loops before, but if we would proceed this
series, I would very much be interested in what the viewers say about it
and what would be protagonists or Jobs or what kind of fields of work
people would like to dive into or what kind of facet they really love
and what not to really like put these way of work from your field a
little bit more into the filmmaking world and because that was really
interesting in the The way you worked with me, it was so different with
how I worked with clients or with, like, sometimes the client is more
the director or other producer and you are the production team. And I
really love to experience a different style of collaboration, always so
easily technical, organized and very much on point and very structured.
It’s something I really sometimes miss in my everyday work and talks
and discussions, which sometimes get out of hand and never ends, you
know.
00:29:20 - Speaker 3: It’s interesting that you have this inspiration
from how software is built and technology firms operated. I think Adam
and I have drawn a lot of inspiration from how film is produced.
So typically with software, you would have a big standing firm that has
a bunch of full-time staff who are hired for 2 to 4 years or whatever,
and those people would build a series of products, and that’s one way
you can do things, but I’ve always been fascinated by what Adam is
termed the Hollywood model, which is you have these loose networks of
people who each other to varying degrees because they’ve worked on
projects together in the past. And then when you have a new project to
work on, you bring together a team just in time around that particular
product, and you work on it for some weeks or months, and then the team
disbands, and you have some stronger or weaker connections based on
that, but you will reform with different people for subsequent
projects.
And I’ve always thought that that’s a very interesting model to play
with in the software world, and Adam in fact did some of that with the
lab, but you can think of it more generally as a sort of continuum where
on the one hand you have the fully salaried standing firm where people
are there forever, and the other hand you have like whatever these gig
sites are, where you hire people to do one hour of work, and playing
with that continuum, you get different trade-offs, and I think it’d be
worth people on software learning more from how the film industry
operates more dynamically in terms of staffing. And also, by the way, in
terms of hiring, the way you hire in film, as I understand it, is it’s
based on your portfolio and then an audition or equivalent, right?
Whereas the way typically you’re hired in tech is based on your resume.
Can you imagine hiring someone for your film project based on like, I
don’t know, where they went to school or something, it doesn’t make
any sense. You would look at their portfolio and then you have them do
an audition. And again, I think that’s something that we can and should
learn from in software.
00:31:09 - Speaker 2: I’ll just add on to that that, you know, we
mentioned the networks earlier and you see this often if you look at the
film credits or even more dramatically famous directors like ah
Christopher Nolan or something, you know, they often have many of the
same actors will show up in subsequent films, even though those films
don’t have anything to do with each other in the sense that they’re
not sequels or part of the same.
Cinematic universe, but that director likes to work with this actor, and
you see that also if you go and look at the credits, you see they’ll
often have the same camera people and producers and costume and lighting
people because again they have that network, those people they’ve
worked with in the past that they know they have a good relationship
with, or they think this person would be great, you know, I know this
camera person is really good at the kind of wide angle shots that I need
for this film, so I’m going to call them in on this. And so you get
these loose networks, but it’s not the, I’m signing a contract to be
full time and work nowhere else at this one firm for the next 4 years,
10 years longer. It’s a very different model.
00:32:11 - Speaker 3: And by the way, I think it’s not just different
or interesting cause it’s unique. I think you could argue it’s
empirically more successful.
So let’s go back to the world of software engineering management. You
see people say, oh, you know, it’s a super creative project, it’s very
risky, it involves all these different functions and by the way, a bunch
of these people are total personalities, you can’t manage them.
There’s no way you could bring together 5 or 10 people to build such a
thing with any amount of certainty or predictability.
But then you look at movies and they have these $100 million dollar
things involving thousands of people, hundreds of different disciplines
all the time. There’s something that they figured out there about how
to bring together these incredibly complex and creative endeavors with
some amount of predictable success, not obviously not all movies work
out, but they mostly all ship at least, and then a lot of them do work
out, and that’s much more than we can say for even much more moderately
scoped software projects. So again, I think there’s something to be
learned there.
00:33:03 - Speaker 1: It’s really awesome to listen to you because
it’s so much reflects on what I’ve been through the last month with my
future project because there were a lot of individuals and amazing film
will come out of it, but it’s always a struggle and it’s always a risk
and you need someone or more people than one. To bundle them together
because a lot of creative potential is also everyone goes in their
direction. Everyone wants to get out everything they see and want, but
you all have to put it in one pro, come back to product, but into one
film.
And usually it’s the director who makes that creative choice and the
producer who makes the choice financially, organizationally with that,
but also on a creative level and For me, I’m kind of the manager of a
lot of creative and disruptive people and I have to keep them together
so that a film will come out which works and that’s such a complex.
Thing to do, but I think if you find out what are the people, the
players I need to put together to really get a dynamic here with the
product, also in your field that you say, OK, I need this programmer
with this designer and Together with them and the right vision, we can
build something.
I think it’s very similar with film production.
We all work at the end of what’s possible, and we want to go beyond,
and you have to have a big understanding. Of the creative vision of
everyone in your team to really know how I can handle those people and
if you can, then you can really do an awesome film. Otherwise, it’s
just a mediocre product and it will maybe work. And I would not say
I’ve accomplished that fully, but I think that’s something if you
really can do that, put the right people together with the right vision
and know how to put them together and when to say something and when to
go to script development, the very beginning of like a, a feature film,
for example, or a pitch paper with a commercial project. It’s always
the question, how much more rounds you need to go, how much further you
can push it. And then you need to know the other person of how far I can
push him or he can push me back with what he wants for his realization
of something.
00:35:39 - Speaker 3: Yeah, well, I don’t want to pull too much into
the industrial organization of film versus software, but one other point
I’ll make here is that I do think another thing software can learn from
this multidisciplinary person who’s responsible for pulling together
and synthesizing and software you obviously have that with founders at
new companies, that’s their job by default, but it’s often missing in
larger firms where you have The product person and the engineering
person, the design person, but there’s really no one who’s necessarily
responsible for pulling it all together, and I think that ends up
typically being a mistake. And one thing I like about the world of film
is that there is that director and producer role, obviously in the
biggest films, but even in the smallest 234 person operations, you still
expect such a person to be that synthesizer, and I just think it’s
really important.
00:36:25 - Speaker 2: Yeah, so that’s to compare to our little kind of
miniature crew here, that’s the role you have Max. You’re the
producer, your job is to make sure everything fits together, it works.
There’s obviously nuts and bolts elements like can we do this on time
and on budget and does everyone show up at the right time and all that
sort of thing, the herding of cats, sometimes we call it in the software
industry.
Whereas Marcus, the director, he’s more about the visual style and
maybe some of the creative elements, the camera person is focused on
maybe some of the particular shots and particular visuals, but I
certainly would say, I mean, you talked before about describing yourself
as a creative producer. It is a very creative role because I think
making all those pieces fit together holistically.
The trains run on time, hurting the cat stuff is how you get there, but
the end result, like you said, if it’s something magical that fits
together really well, that conveys a strong story versus being a grab
bag of everyone’s weird ideas that don’t. Fit together well, which is
very easy to happen when you get together a bunch of creative,
opinionated people that all have their own agenda, their own ideas,
maybe very good ideas, but if those ideas don’t fit together in a way
that makes sense or in a way that’s practical, you don’t get a good
end result.
00:37:37 - Speaker 1: Yeah, I think we should not talk small the
organizational part because I just experienced it with my last project
where I was working a lot in the organizational side as a production
manager. To be detailed and to really have everything there you need for
the film set, sometimes 40 people wait because you don’t have a shovel
and you are in the forest and you need the shovel to dig a hole and
everyone is there, everyone is on time.
The creative vision is there and everyone functions, but the shovel is
not there and you are in the remote location in the forest and Everyone
gets crazy.
People drive from the set to the next store to buy it. People from the
office drive to the next store to buy it at the end, they shot something
without a shovel because they came up with a new idea.
You know what I mean? To be detailed, to be on point is. Also very
important in film production. You can’t be lazy or forget something
because if you forget to record something, to do it in post is not the
easy sentence to say.
Some people joke about it and say, oh, let’s do it in post. We didn’t
manage to do it here, but the people who have to do it in post, it’s
crazy, much effort to do something in the post-production. You really
missed by an easy thing on set, on shoot. So, I think it’s really also
important for film industry to be very detailed and the groundwork needs
to function.
00:39:10 - Speaker 2: Let me return to a point you were making earlier
there, Max, about learning from kind of how the software world works and
how we brought a little bit into the Create series, and this is actually
a bit of a call to action for the listeners here.
So in the software world, we typically do betas. And certainly the way
the muse does it, I try to do it on every product I work on, which is
whenever you make a new thing, a new feature, a new capability that you
treat it as an experiment with kind of the default is the null
hypothesis. People won’t want or need this feature, and you should just
remove it.
And the best way to do that. If it’s kind of a beta that is not part of
the shipped product that people can opt into, they can try it and then
you find out pretty quickly, is this something really useful that
becomes a key part of someone’s workflow and then you can and should
roll it into the finished product, or sometimes it turns out it falls a
little flat and you decide to change it, or maybe even just cut it out
in the beta, for example. So that’s a little bit what we’re trying to
do with create.
So you can think of this pilot episode here as kind of a beta. And we
wanna put it out to our audience here. I hope everyone listening will go
watch it, as well as read the memo about some of the motivations, and
tell us, is this something you’d like to see more episodes of. And I
certainly hope the answer is yes, because not only because it was
enjoyable to make, but also I think the power of the series actually
would come from seeing multiple types of creators and seeing the
similarities, seeing the patterns across them. That’s what we get
through our user research, we’ve spoken to so many of these folks, and
so seeing that even if there’s a brand designer and an architect and a
writer, that they share a lot in terms of how they at least come up with
their ideas. So I’m hoping that we will be able to continue, but we
want to get folks feedback so you can think of this first pilot as kind
of an early beta, and basically you should watch it and send us your
feedback, as well as help us find new protagonists.
So, the way that we looked for subjects for the film was largely through
our own networks a little bit, as well as trying to keep it local here,
just so we could not need to send the film crew anywhere far away.
But now that we have this first episode out and you can kind of see what
we’re trying to do here, we’d like to put the call out to our audience
to say, who do you know that would be awesome to profile here? And they
could be a muse user, we’d like some of them to be, they don’t
necessarily have to be, and maybe we’ll do a mix, but whatever it is,
they should do something inspiring and interesting.
Maybe there’s something interesting about their personal story, and as
you said, you know, we spoke to a number of folks to be protagonists for
this first pilot, and every one of them, as you said, in their own way,
they’re the hero of their own story, and they were inspiring to speak
to and see not only the work they create, but how they create it. So
we’re looking forward to finding more folks like that and so the calls
to action for the audience here is not just, should we continue this
series, but who else should we feature. Well, before we wrap up, I
always like to be a little future facing. So Max, if we do get the
chance to work on more episodes of this series together, what did you
learn, what did we learn together on the pilot that you think we would
do a little differently for future episodes?
00:42:22 - Speaker 1: Thanks for asking and I really hope that we have
the opportunity to do more episodes.
In the beginning, when you come up with the idea or you come with the
idea to me, I calculate it, I try to schedule it, I try to schedule the
time of everyone and how we produce it and now I would do it in a
different way to have more time with the research, maybe to even have a
person or someone who dedicates itself if we do 5 or 10 more episodes,
so we can meet 20 to 40 people which are already pre-selected. And to do
the interviews we did, I think this is very important to have the
preparation time and to have enough time and space to plan and produce
the script for it. I think.
Also, I would like to work more on a unique theme for like a musical
sound design theme for this kind of series which you can recognize it
too, but this also needs more time and, yeah, more energy to work on.
And that would be two things I would say spontaneously that we would do
differently. What about you?
00:43:41 - Speaker 2: For me, a big surprise was definitely how much the
protagonist search, not just the initial kind of coming up with people
we could speak to and having those initial conversations, but really the
process of explaining to them what we wanted to do, trying to suss out
what their story was, which of course is, you know, for a stranger, near
stranger to them.
Then they’re exposing things about their personal life and how they
work and so forth, so that we can then evaluate what sort of narrative
arc would come out of that, and so there was sort of a trust building
process that we were going to make something interesting and worthwhile
to spend their time, and so, yeah, all of that ended up taking quite a
lot of time.
We spoke to some really great people and got pretty far in the process
with many of them, but yeah, surprising amount of the time and energy
was spent on that, but in a way, you see how it pays off, right, with a
documentary piece, you know, we’re well literally documenting the life
and the work of someone, and so they’re finding the right subject,
finding the right protagonist is huge, right? That’s the center of it.
If you have someone great, that’s your Source material and from there
you can build a good narrative and you can make it visually interesting
and so on. And so really giving some good time to that.
But I feel like we learned better how to do it through this process. If
we were doing more episodes, we could do them in parallel. I think we
just learned a lot of the process of how you build that relationship,
find the story, and then build up to that filming day, which is really
asking quite a lot of the person who’s being featured.
00:45:17 - Speaker 1: What I just thought of while you were talking is
that the core strength of it is that it’s authentic, that, that’s real
people, even if we try to condense what we want to tell about their
life, about their work, it’s real and they didn’t rehearse it with
us.
So the time we spend with getting to know them is also a key element to
the success of it later. So they trust us.
They trust us coming in their life, showing their children, showing
their workspace, showing their raw, unfinished work.
I think to build that kind of trust with the protagonists is very
important and I think with Katherine, our first protagonist, we got that
far. She really opened up to us. She told about her past, she showed her
kids, she really opened up and I think that’s important to keep for
future episodes.
00:46:14 - Speaker 2: Yeah, very well said, and of course a huge thanks
to Katherine for going out a limb on us a little bit, especially now at
least we have a pilot episode, we could show future protagonists and
they know sort of what they’re getting into, but she showed a lot of
trust and spent a lot of time with us for something quite unknown, and
yeah, absolutely, building that relationship, it’s a partnership
between the protagonist, you and your film crew, and the Muse team and
me who, you know, have something we want to express through this medium.
00:46:43 - Speaker 1: And I think the best case would be that the
protagonist as an, I don’t know, artist and a programmer, I don’t know
what kind of work he does, but gets something out of this video
production as well, that he thinks he is portrayed well and he’s
respected well and that he’s eager to show it to his friends or even
put it on his website as, hey, that’s how I work and That would be the
best case scenario. I don’t think we will achieve it with all
protagonists, but that’s something I would really like that they are
proud to share it and feel respected with it and their work is
respectfully shown.
00:47:25 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, you can write us on Twitter at UAHQ or
via email hello and Musapp.com. Help us out by leaving a review on Apple
Podcasts, and Max, it was a real pleasure to work with you, get an
inside view on how film was made, particularly for a person with
prodigious talents such as yourself, and I very much hope we get the
opportunity to continue the series and continue to document the lives of
inspiring makers.
00:47:56 - Speaker 1: Thank you, Adam. Thank you, Mark.
0 min

About Metamuse

From the publisher's feed

Tools for thought, product design, and how to have good ideas.

Share Metamuse

Sign up to save your podcasts

Metamuse

Metamuse episodes

About Metamuse