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: My experience as a team lead is that if your team
is aligned going into a project, you get this incredible execution.
It’s fun to do, you know, maybe hard work, but you’re all rowing in
the same direction, you’re seeing those results when you put the pieces
together, they’re all harmonious.
Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and
Mac, but this podcast isn’t about Muse product, it’s about the small
team and the big ideas behind it. I’m Adam Wiggins here with Mark
McGrenigan. Hey Adam.
So Mark, it’s been snowing recently here in Berlin, quite cold, and of
course I need to not only walk a dog 3 times a day, but now take my
daughter to Kita, which is kind of a daycare kindergarten thing in the
stroller. So spending a lot of time in the cold these days.
How do you feel about kind of places with the full 4 seasons, which I
think you grew up in the kind of East Coast United States versus the
West Coast or perhaps more southernly lifestyle that is Yeah, I’m a
huge fan of the Four Seasons, probably because it’s what I grew up
with.
00:01:02 - Speaker 2: Actually, especially here in the Pacific
Northwest, now I’m in the inland Pacific Northwest, and it’s just
beautiful in the winter with the snow on the evergreens, and it’s very
quiet and peaceful. I’m a big fan.
00:01:16 - Speaker 1: I certainly find that change of the seasons just
keeps life interesting in a way. There’s something about the passage of
that day night cycle. And there’s a similar thing with the 360
something days around the sun, and these quarters, essentially, they
each have their own distinctive look and feel, right? The blooming
flowers of spring, the high sun of the summertime, the rich autumn
leaves in the fall, and then winter with it’s cold and snow and people
wanting to stay inside and stay warm and cozy. I don’t know, there’s
something about that cyclical aspect that works for me somehow.
00:01:56 - Speaker 2: Yeah, and you’re not only enjoying the current
season, there’s an element of anticipation for the next one. So now
we’re looking forward to, OK, we’ve shoveled the driveway enough
times, we’re looking forward to the snow clearing out, and then perhaps
it’ll get hot again, but then once it’s 90 degrees and smoky, you’re
like, oh man, I can’t wait for the winter when it’s just cold. So
around and around it goes.
00:02:15 - Speaker 1: So our topic today is leadership.
I thought this would be a fun one because this is something both you and
I have spent a lot of time on in our careers.
I’ve been in some way or another leading sometimes reluctantly or with
some surprise, small teams for over 20 years now. You’ve done quite a
bit of that in your career also, and it’s come up a little bit recently
in terms of our work on use for teams, in terms of the kinds of people
we’re seeing that see the need for this product, we can talk about
that. A little bit later, but as always, we like to start with basics.
What is leadership? What does that word bring to mind for you?
00:02:51 - Speaker 2: I’d probably say creating an environment where
the team achieves success. Now, you can unpack every word in there and
it would be a whole podcast in itself, but I think the main idea there
is that ultimately you’re accountable for results, that’s why you’re
there, and you can’t do it directly, so you have to build the team and
create the environment such that it happens.
00:03:13 - Speaker 1: I suspect a lot of people who are successful at
being leaders do come to it, not from the perspective of, I just wanted
to grow up and be the boss, you know, as a kid I always dreamed of being
the one in the corner office or something. I don’t think that happens
too much, but rather that you have some end you want to achieve,
something you want to do in the world, and in the process of trying to
do whatever that thing is, you realize, oh, I can’t do this alone. I
need the help of others, and then that leads you to attracting those
others to try to help you with that, and that of course leads you into
team building and pretty soon you find yourself in this role of a
leader.
Another piece of your definition here is the team, and I think implicit
in that is the assumption that there is a team, right? And that’s not
something that comes from nowhere. I mean, maybe you get hired into some
kind of leadership or management role and you inherit a team.
But at least in my thinking, kind of coming from the more
entrepreneurial perspective, or even if you are hired into a role,
you’re often expected to build a team. And so essentially the
pragmatically we can say hiring, but even more broadly, you can say the
identifying what kind of people you need to achieve your ends, figuring
out where to find those people, figuring out how to attract them, you
know, what do you have to offer them that would make them want to join
up with whatever it is you’re trying to do and Help you achieve the
end, and then the onboarding process, as we talked about in our hiring
episode, which is a way bigger deal than a lot of people make it. You
don’t just hire someone and then they’re suddenly a fully functioning
member of the team. There’s this long process that could take many,
many months or even up to a year, I think, where someone can find their
place and brings their unique skills to the team in a way that Enhances
it, and more than offsets the cost of just having one more person around
that needs to be in the loop communication wise, as well as the actual
just cost of their salary or fee or whatever.
00:05:11 - Speaker 2: Yes, recruiting team is perhaps the most important
aspect of leadership, especially in our domain, and I think that also
leads into the ongoing personnel management. There’s a great document
called the Netflix Culture deck, which we definitely linked to, and one
of the insights from that was that. The things that your company values
is not what you put on the plaque in the lobby. It’s what you hire for,
it’s what you promote, it’s what you reward, and as a leader, you’re
gonna be doing a lot of that and therefore creating and disseminating
what are in fact the values of the organization. So by that channel and
by other channels, I think setting the values of the group is very
important.
00:05:52 - Speaker 1: Yeah, I would list setting vision and values as
one of the top jobs of a leader.
There’s obviously many leaders in an organization, particularly as it
grows, but here, if we think of a small team, you know, something like
the Muse team, for example, that, you know, less than 10 people, there’s
probably sort of one person who’s mainly responsible for sort of
leading the overall thing, and In that case, yeah, the setting of the
vision and the values, the ongoing understanding of the values, which,
as you said, are less what you write down or claim are your values and
more what you live every day, and it’s partially determining what those
are, which sometimes flows out initially from kind of some of the
personal values of the founders. Obviously the vision is something that
evolves over time as you get better understanding of the problem and
work the idea maze.
00:06:41 - Speaker 2: And this matter of vision is very interesting to
me.
I think there’s a piece of vision, which is setting out someplace in
the distant future, like you go and you sit and you think real hard and,
OK, this is where we should be.
That’s kind of the easy part of vision.
I find that the harder part, and where the rubber really meets the road
is conviction and belief. It’s actually incredibly hard to believe in
something for the amount of time and the amount of work it takes to
accomplish great things. Because if you don’t believe in it, why
shouldn’t anyone else? So there’s a lot of, basically emotional work
you gotta do to get out there and put yourself out there and put your
beliefs out there in front of the team.
00:07:19 - Speaker 1: Believing and especially believing in something
that is in the beginning, a true article of faith, something you believe
in, but you really have no evidence for it, and part of what you’re
doing in the entrepreneurial journey is creating that evidence.
And we talked about this with Mario from the generalists when he was on
the podcast. We’re talking about narrative and part of the job of a
leader, especially a CEO is to create a narrative that captures that
vision that is a dream, but an inspiring dream and feels achievable, and
there’s a version of that that can become, you know, we’re talking
here about faith and belief and narratives and all this starts to sound,
you know, a little bit like cult leader like and indeed you can go off
the deep end with that, and that is how you get some of these maybe bad
examples of companies that seem to suck up all these resources and build
this big internal culture of what turns out to be pretty false belief
around some cult of personality. That’s like a far extreme, maybe
failure case, but there’s a middle ground where you take a visionary,
you know, take a Central, kind of almost mythological figure in our
field now, which is Steve Jobs, and he would create that reality
distortion field, tell that big story, inspire people, and then be able
to make that thing come true that seemed impossible at the start.
The balanced version of that is the belief, the faith, believing in
front of the team, believing in front of the outside world and
especially doing that when the going gets rough. It’s easy to believe
in time when things are going well and everything’s up into the right.
It’s harder to do that when you’re struggling for some reason or
other, and there’s always moments of struggle in every company’s
story.
00:09:00 - Speaker 2: Yeah, and I think it’s also easy to have
conviction in a way that’s basically a fantasy. And again, we come back
to the importance of results and accountability.
The real reason it’s important is that the variance in human
performance and achievement. Potential is enormous, and often people
don’t realize it.
Perhaps it’s because they’ve never seen it, they’ve never had anyone
that believed they could achieve at a higher level, and the
responsibility with vision and belief and foresight is believing that
the team can operate at a higher level, and then seeing that they do, in
fact, achieve that level.
You gotta do both parts, right? It’s not enough just to say, you know,
I believe we can do amazing things. Well, sure, don’t we all? But it’s
taking the team there and really achieving it.
OK, well, let’s pull out Adam Wiggins trick here and refer to one of
the items from your crou lessons for leadership. I think the document
was pull link to it. But one of the things that I remember was make it
concrete. So, let’s talk about some concrete leaders that you’ve
looked up to or learned from.
00:09:57 - Speaker 1: Well, certainly offhand, I think of people who
have been leaders to me, which includes someone like Byron Sebastian,
who we hired to be the CEO at Hiroku, and I learned a lot from someone
like Ida Tin, who’s the founder and CEO of Clue, and, you know, these
were both people that just inspired you, but also made you feel like
they personally cared about you because in fact, they did.
And they did for everyone that was on the team, and made it possible for
me to do great, great work with under the umbrella of the leadership
they were providing.
But I think it’s interesting here to look at maybe public cases, people
who are famous enough or maybe just got around to writing their
autobiographies that you can sort of reference. We’ve mentioned Steve
Jobs already. Bill Gates is another, obviously many folks have questions
about maybe some of the ruthlessness he exhibited back in his Microsoft
days, but you know, each in their own way, Gates and Jobs, maybe they
had some.
Problems with being a little too tyrannical in their own way, but this
incredible drive, the vision, the unwillingness to compromise and shaped
the computing industry of their eras in their own vision of how they
thought things could be better, you know, Bill Gates believed in a
computer on every desk and he achieved that, and Steve Jobs put a
computer in everyone’s pocket and made design a household word. But
those are sort of obvious cases.
I was just flipping through some of the Books I’ve read, particular
biographies or autobiographies, and it’s interesting to look at folks
maybe outside the tech field as well. One that comes to mind right away
is Ruth Handler. She co-founded Mattel, the toy company, and invented
the Barbie doll, and also did other entrepreneurial things in her
career, but obviously that was the big success, and there’s an
excellent biography about her called Barbie and Ruth, the story of the
world’s most famous doll, I’ll link that in the show notes. That is a
good example of someone who, I guess maybe more an entrepreneurial
leader who’s someone who looked at the toy industry as it existed at
the time, looked at the dolls that kids, especially little girls were
playing with and said, I think there’s a better way here and ended up
not only inventing a new product, but founding a whole company around
that and that, you know, company went on to essentially change the, the
whole industry to match that vision for that better way.
Some other examples there are Bill Walsh, who’s, I think, a coach of
some MA football team, and he wrote a book called The Score Takes Care
of Itself and the Philosophy of Leadership, lots of interesting stuff in
there. That’s kind of what we’ve been talking about already, setting
vision and values, you know, we came into kind of a struggling team. And
did a bunch of things there in terms of setting a new precedent for how
they would collaborate together and what kind of standards they would
have, many of which was unrelated to, seemed unrelated directly to just
playing the sport. A lot of it was about how they hired people, how they
kept their facilities, how they treated each other, that sort of thing.
So maybe that comes back to your point about kind of environments.
And then the last one I’ll name is, it’s actually more of a book that
covered a few different folks in the television industry, which is
called Difficult Men, and this is about showrunners, which showrunners
are sort of leaders of these within the media industry, but they’re not
like film directors, which are sort of these, you know, one off two hour
things and they’re not. Directors of individual episodes, they are
owners of these big epic stories like I think a few that were profiled
here is like The Sopranos, Mad Men, The Wire, and these are long, long
projects with big teams, lots of writers, lots of directors, etc. but of
course they’re quite a bit more involved at every level compared to
conventional TV. It’s very interesting to read about how they do things
and actually one of my takeaways from that book was, and indeed is in
the title there is that people with strong vision can often also be very
difficult.
In fact, they can be, again, I used the word tyrant earlier, I think
that people often use that to talk about Steve Jobs style and you see a
lot of that with these folks. Now, one exception I do want to point out
there is the showrunner from Breaking Bad, who apparently was kind of
the sweetest, kindest person and ran the show there and all of that
without all of that kind of classic intense boss stuff, which I like
that a lot because it shows it can be done and there’s probably a
conventional, probably pretty masculine way of kind of leading that is
sometimes based on intimidation and I don’t know, various traits that I
find not that compelling. But in any case, these TV shows, which are
huge artistic efforts, big budgets to manage and over a very long period
of time, right, like something goes for 78 seasons, there’s obviously
all the build up before that, pilot episodes and things like that. And
so, yeah, I don’t know if it’s quite right to say that I look up to
any one of these showrunners specifically or see them as Great role
models, but just that there’s good patterns across them. These are
people who managed to make something unique in the world through
organizing a lot of resources and people, which is something I find
inspiring.
00:15:08 - Speaker 2: Yeah, I think that domain is incredibly rich, TV
and movies, because it’s one where there’s this very complex
multidisciplinary, creative, high risk project, and there aren’t that
many great analogies, I think, to software development.
It’s kind of a weird thing, but perhaps actually the closest is making
a movie or a TV series. So I think there’s a lot we can learn from
those domains.
And by the way, This is a pet peeve of mine, you know, people always
say, oh, you can’t estimate a software project. There’s no way to know
if it will ever, you know, work or when it will be done, you know, you
can’t say anything about any of that. I don’t know, man, people
estimate complete movies with thousands of people literally filmed all
over the world. I don’t know. I sometimes I don’t believe you when you
say you can’t estimate a 5 person software project.
00:15:51 - Speaker 1: Do you have anyone that either you’ve worked with
personally or is a more public figure, like one of the ones I’ve named
there that you find inspiring or anti-examples, people you think that
are not effective leaders or have traits that you think are
counterproductive.
00:16:07 - Speaker 2: Yeah, I’ve certainly worked with a lot of
different leaders in my times and feel like I’m developing notions
based on those experiences that I try to give things more time and
distance before I really weigh in. But what I’ll mention is Peter Van
Hartenburgh at the lab. I’ve worked with Peter in several different
domains, and he’s someone who’s just like a magician with getting the
right team together and getting that alchemy happening. And I don’t
know how he does it. And frankly, it’s often pretty messy. Leaders have
different styles, but man, somehow people show up and they start doing
amazing stuff. It’s really amazing to watch.
00:16:40 - Speaker 1: Yeah, Peter the great one, he comes to mind for me
as well, and also to your point about styles, he and I could not be more
different.
I’m all about like structure and clarity and so on, and he has this
more, you know, warm, but also kind of loose and flowing approach, and
indeed we have together been in kind of like co-leadership positions,
maybe I’m, you know, leading on the product and design side and he’s
more leading. Engineering team to take one example, and there’s ways
those styles don’t really fit together, but then when I’m just
watching him do his thing and see the results that come out, it’s just
undeniable that he’s got something that really works, even though it’s
kind of a mystery to me because I come at it from such a different
perspective.
00:17:22 - Speaker 2: And I also look a lot to history. I feel like in
the case of historical figures, we have more distance and perspective.
Often there’s a lot more data, and because the stakes were often so
high, often indeed existential, it really lays everything bare, right?
Like there’s no excuses, there’s no ifs ands or buts, there’s no
mitigating factors, you know, kind of it is what it is, and it’s
settled on the world stage and that’s that.
Whereas, you know, if you’re a leader at a big company, is what you’re
doing working well because the company is doing well or, you know,
whatever, it’s kind of hard to tell. You need more time and perspective
and distance. So one example for me is George Washington, who is an
incredible example of, well, a personal character, but also B, this idea
of vision and belief, you know, believing that you’re going to create a
country contrary to the global superpower and, you know, fight a
revolutionary war with farmers and merchants, it’s just an incredible
story.
00:18:21 - Speaker 1: And one of the things I love about the Washington
example as well is he did what was needed in the moment, right? There
was fighting a war, but when the war was over, he didn’t try to
continue that because he was pretty good at being a general. He moved
into a new kind of leadership position, which was being the president of
a young nation and trying to preside over building up a government and
building up good processes for this new democracy.
Something I at least aspire to do in my own.
Kind of career as a team lead, which is do what the situation demands,
do rise to the moment of what this exact team, this exact company or
organization or situation calls for, which often means doing things way
outside my comfort zone or having to educate myself about stuff that I
have not done in the past, and it would be easier to stick to a thing I
know, a skill set I already have, but that’s not what’s really needed
in the situation.
00:19:18 - Speaker 2: Another reason that I like to look to history, is
that I feel like much of leadership is made in the small details, and
unfortunately, we don’t have the small details, we don’t have access
to the small details for most contemporary leadership cases. Like the
CEO of Microsoft, you know, we don’t really know very much about how he
operates unless perhaps you work directly with him at Microsoft.
But if you go back to the historical examples, we have, you know,
basically all their papers, we’ve triangulated massively. There’s all
these different angles that we have on it. We’ve collected all the
accounts and you get a richer sense of how they operated day to day.
So it’s not about just making a few big decisions and that’s it, even
though when you zoom out, you’re seeing this huge global event. It’s
really about the individual interactions you have each day, you’re
hiring and firing decisions, who you promote, who you don’t, you know,
how you motivate the one guy who’s struggling.
That’s the really rich texture that I think you need to be able to
develop a good sense of leadership. And unless you’re lucky to have a
few of those in your life, which I think to varying extent, we’ve been
lucky to have that, but there’s this, this incredibly rich historical
bounty that we have if we’re willing to go back and look at it.
00:20:26 - Speaker 1: Now going back to a word I think you’ve used a
couple times here so far is accountability. I feel like that’s an
important one to zoom in on. What does accountability mean in the
context of the leader’s job?
00:20:40 - Speaker 2: I think it ultimately means that your success is
measured by whether your team achieves the goals that you set out to
accomplish. And what’s tough about that is that that being accomplished
or not is going to be a function of all the work that the individual
people on the team do. So you basically, you’re not directly pulling
these levers, that would be responsibility in the management language,
right? Like you’re the person actually doing the frontline work, but
you still need to be accountable for the results. The sum of all that
happens rolls up to you.
00:21:11 - Speaker 1: Roll up is a good word for it, because I think the
accountability or holding the organization, the team accountable is a
combination of the leader themselves feeling accountable for the overall
results, separate from any individual domain that a person might be
responsible for, and that includes we just don’t have someone that owns
a particular domain, that’s a big gap for us, and we need to do
something about that because you’re accountable for what’s there
overall.
But then there’s also a holding people on the team accountable, and
hopefully the team holds itself accountable.
Individuals do, and they make commitments to each other and want to keep
that commitment in terms of what they’re going to deliver and so
forth.
But I think the leader’s job is to be accountable themselves, and maybe
that somehow goes up to, you know, if you’ve got a board of directors
or shareholders or something like that, but in the end, it probably
boils down to also just like, if your company fails, you know, that was
fundamentally, that was the leader.
Failing more than anyone else, but then that also gets echoed back into
holding team members accountable, or if you have whole teams that are
sort of under your, again, umbrella of leadership that you’re saying
like, OK, look, I don’t necessarily know every detail about how you do
your work. I trust that you know your skill and your craft better than I
do or ever.
Well, but look, we need to deliver X and here’s the resources we have
to do that. And if you don’t think we can accomplish that, we need to
come up with a different plan, for example, and then kind of keeping
again coming back to that, repeating yourself and the reminders, not
just forgetting about it, but coming back to it to say, OK, how are we
doing on this?
00:22:50 - Speaker 2: Yeah, and I think there’s a related idea in there
of standards. I think an important role of a leader is setting the level
of standards within an organization and holding the team to that, and
it’s not as easy as it sounds because, of course, we would like to have
infinitely high standards and to see.
Everyone reaching them, but what happens is if you set the standards too
high, that is, you know, of course, if they’re not possible to
accomplish, or it’s just the team members don’t believe they can do
it, or they don’t feel like they have the support to do it, or they
don’t feel like they’re gonna be rewarded if they do do it.
Not only are you not reaching the level that you had set as a leader,
you’ve lost credibility. So, You need to find the right balance of
raising the standards such that the performance of the organization
increases but not trying to raise it so high that you detach from
reality.
Again, I think this is so important in our domain because the level of
variance is enormous, and I think people still, even though we have now
several decades of experience and Making software. I think people still
underestimate a lot, but it’s possible, how fast it’s possible to
move, how high quality the software can be, how fast it can be, how
reliable it can be, and so on. And so I still think there’s a lot of
work left to be done as leaders in this area.
00:24:05 - Speaker 1: Um, one example that I read just recently is
Patrick McKenzie and his nonprofit Vaccinate CA, which was basically a
kind of information website for availability of vaccines first in
California and later in the rest of the United States during our recent
pandemic, and he wrote up a in his His usual sharp and humorous style,
the full story of their experience and spinning up this nonprofit, the
work that they did, and then eventually shutting down when they weren’t
needed anymore. But that concept of what’s possible and what standards
we hold ourselves to, I feel like permeated the story because there it
really was about speed. And they’re doing kind of like a low tech,
fast, but accurate thing that would ultimately result in their
organization’s mission, which was to get more shots in arms. And so
Patrick as a leader in this case, was holding his organization to the
standard of speed because that was just everything in this case, getting
this information, getting accurate information out to people as quickly
as possible, getting the website built and the infrastructure that went
with it. And that that sort of was in contrast to what, for example, is
pretty commonplace in, let’s say government organization or even
government contractors who are used to long cycles and a lot of process,
and he came in and said, no, what’s important here is to do it quickly,
and holding his team to that standard through a set of sort of practices
allowed them to accomplish things that no one else could.
But importantly there, and I think in most cases, as you said, it’s the
trade-off of what standard are we holding ourselves to in the context of
how that helps us achieve our mission. It’s not that we want to, for
example, make the most beautiful design possible just because, just
because we want the highest possible standard. There needs to be some
reason, something we accomplish with a lot of craft put into the design,
or for another organization, it might be. A beautiful design doesn’t
matter very much, and we hold ourselves to high standards on other
things. For example, safety might be something that an airline wants to
hold themselves to a very high standard for. So I think it has to be set
the standards in a way that fit with the reality of the world, but also
the mission of the company and what you’re trying to accomplish and
what you’re trying to deliver. Well, maybe now would be a good moment
to mention why this topic is on my mind to begin with, which is our team
has been working on our new product Muse for Teams, and part of what
we’ve done in this alpha program is we have a survey where people can
essentially fill it out and describe what they do, what their team is
like, and how they idea today and so forth and what their frustrations
are, and We didn’t really know what kind of people were going to answer
that survey, and indeed we’ve had quite a wide mix, just similar to the
new user base, architects, doctors, many students, many professors or
other people in the academic space. But one pattern I think that we’ve
seen quite a lot of is team leads signing up, and this is interesting
because it seems that the problem of, let’s say, a shared collaborative
whiteboard or shared documents generally to be a space for a team to
idea is something that is a problem that team leads are just Very
intimately familiar with, they feel this pain most directly, maybe more
than the individuals on the team, and that caused me to be kind of
reflecting that, OK, well, why is that? And maybe that’s not a
coincidence, right? Part of why I’m driven to build this product is
I’m also a team lead, and something that I consider a key part of that
job is Yeah, manager speak for this would be alignment, you know,
getting everyone on the same page or the basic idea that you can bring
together a bunch of amazing craftspeople, but if you don’t agree on
what you’re building and what you’re doing here and a direction and
you have a meeting and you talk about it, but it’s kind of like subtly
wrong and then everyone goes off to their individual things and they’re
building stuff. And a week later, a month later, whatever you try to put
it together or you come back and look at it and realize you just had all
these false misaligned, mismatched assumptions about what you’re really
doing there and then that slows everything down and people are
demoralized and work has to be undone and so forth, and that my
experience as a team lead is that If your team is aligned going into a
project, you get this incredible execution. It’s fun to do, you know,
maybe hard work, but you’re all kind of rowing in the same direction.
You’re seeing those results when you put the pieces together, they’re
all harmonious, and I think this is something where the historic
solution to this called it alignment problem is these analog tools,
right? We get together in front of the whiteboard and we talk about it,
we go to the conference room, you know, maybe on a bigger scale, you got
the all hands or whatever. But then when you come to remote work, OK,
now it’s harder to take advantage of some of those, and I think this is
where you have shared documents, you know, I got big into Google Docs
basically once I got more into remote teams because that could be a kind
of like internal memo. I’ve used email for that, that sort of thing in
the past, maybe Slack to some extent or some of that, but I think
there’s really nothing like a more kind of free form ideation space,
and that indeed seems to be what folks who are Filling out our survey,
who are founders or CEOs, particularly of small to mid-size teams, are
seeing is that OK, I now have this remote team, we have these time zone
differences, we do have all these collaboration tools and different
kinds of shared documents, but none of them quite have that same
flexibility and kind of all encompassing aspect that you can get out of
just physical ideation tools. And as a result, that can be a real
impairment for remote team to execute well, and again that moving more
slowly and undoing work and frustration as people feel like the pieces
don’t fit together. I found that very interesting. I’m curious how you
see all that.
00:30:18 - Speaker 2: So we talked a while back about this book called
Sketching User Experiences, and one of the key ideas from that book was
that the medium that you choose to work in, it sort of tunes your
wavelengths that you’re listening into and operating on. So, if you
have a very precise medium, you think very precisely and you might
therefore lose the bigger picture. If you have an extremely messy
medium, you might not get concrete enough. And there’s an important
middle there, which he called sketching, which has the benefit of being
concreteness, but it’s not about being pixel perfect. And so, one of
the original ideas with Muse was that you needed the same thing for, well,
ideas, for creative thinking, for planning. It wasn’t super linear,
like a text document, it wasn’t. Super mechanical, like a Gantt chart,
but it also captured the richness of thinking that people and teams
have, it’s multimedia and so on. And so, one of the things we’re
hearing from team leads is that According to the medium that they
choose, that tends to tune the thinking of the team.
So if a team jumps right into Figma, for example, they’re tuned to
think about pixels and what’s the radius of this curve and is the
shadow rate, or if you jump right into Git and GitHub, you’re thinking,
what’s the name of this function be, and so on. Whereas if you center
the team around, you know, traditionally it would have been a
whiteboard. OK, they’re stepping back a little bit, they’re thinking a
little bit more expansively. They’re not worried too much about the
details, but it does need to be concrete enough so that you can see
where the boxes and arrows are and so forth. So I think the muse does
help teams idea on the proper wavelength, if you will, for when you’re
brainstorming and forming new ideas and starting to anneal plans
together.
00:32:04 - Speaker 1: Yeah, the sketching user experiences book, which
is Bill Buxton, if I’m not mistaken, I’ll link that in the show notes.
That’s a great one, a little rambly in a way, but lots of good ideas in
it, and he also talks about a sketch as being, it’s not about being a
drawing specifically, although it often is, and more that it is a thing
that proximates the final shape. So it’s cheap to make, so you can make
a lot of them and compare them, but it is, as you said, still concrete
and you can look at it and discuss it.
And another important quality of the sketch is that it’s kind of vague,
which is good in the sense that it invites a lot of interpretations, so
you can have this kind of ideation experience, particularly between two
or more people where you think, OK, here’s kind of what I’m thinking
and you sketch it in whatever medium you’re using and someone looks at
that and says, oh yeah, I see that that would solve the problem this
way. You say, oh, no, no, that’s not what I was thinking. But wait, now
that I kind of look at it that way too, well, that’s an interesting
idea. So like, The sort of open to interpretation aspect of it serves as
a launching off point for the kind of divergent thinking that you should
be doing when you’re in the early phases of a project.
00:33:15 - Speaker 2: And that reminds me of another important aspect of
ideas and plans is that it’s not just about the final artifacts.
It’s about working through it, but I have one called chewing, and if
you’re chewing an idea or a plan together as a team, you’ve, well,
digested it better to continue with the analogy, right? Like everyone
has a better sense of what’s going on, they feel more invested in it.
They’re more aware of the trade-offs that you sort of traverse together
and things like that.
And so that’s part of the vision with use for teams being multiplayer
is that instead of having a team lead, write up a document. And cast it
about on the team and everyone going from there, it’s more a matter of
the team is building this together incrementally, and not only do they
share the artifacts at the end, they share the experience of having
worked on it, and are therefore more invested in the final result.
00:34:07 - Speaker 1: And that highlights something that was a major
piece of learning for me in my leadership career, which is working
through the problem, you know, you start with all the inputs and you
think about all the constraints and the opportunities in front of you,
and you eventually come up with a solution, which might be a plan of
action, it might be a rough design or a vision, it might be specific
kind of task assignments, and I would tend to think, OK, well, let me
bring this.
To the team that I’m working with, because this is the plan, but
actually that doesn’t work very well. You need to make the plan
together, because otherwise, the people don’t feel shared ownership.
They weren’t there for the process of seeing why we’re doing exactly
what we’re doing. And in many cases, all the different disciplines you
may have on your team and the different perspectives, those need to be
folded in.
Now, it’s not necessarily designed by committee, there does still need
to be kind of a central organizing. single mind that can kind of look at
everything and make sure it all fits together holistically, but you do
need to take into account, you know, the classic example here would be
if designers make a design without consulting with engineers, they’re
gonna be unaware of both the limitations and the capability of the
technology, and they’re gonna ask to be implemented maybe out of step
with what’s possible with whatever technology they’re working with,
just to take one kind of classic example.
So yeah, that process of planning together as a group.
And coming to that, like, this is our shared plan is immensely valuable,
and I even resist the urge, you know, I like to think strategically, I
like to think about what’s next after we finish this current work and
What have we learned and how do we fold that into what our next step
should be, but I’ve really learned that, you know, hold off a little
bit, do it with the team because we need to all do it together, and
it’s that experience of going through it together that is going to make
it so that when you go to execute the plan, you can do that far better.
00:36:04 - Speaker 2: And I think the most effective version of this, by
the way, isn’t all or nothing.
The weakest thing you could do is come up with a plan as an individual
and cast it over the wall to the whole team. We understand that’s not
very strong.
It’s slightly better, but still not very good to jump into a meeting
with an entire large team and just start planning from scratch. And then
end of the meeting, yes, also a mistake, a mistake, right? And so what
actually needs to happen is there’s this very organic process. I use
the analogy of the spiral, spiraling outward.
So typically, you start with some kernel of an idea, like you have this
notion that the team should move in some direction, and then you go and
you balance that idea off one or two of your close trusted advisors.
These are people who you trust to, you know, give you candid feedback,
but also kind of keep the idea private because you’re still in the
process of nurturing it.
And then you might take that idea which is starting to take basic shape
and discuss it with your leadership team. And you do some more shaping
there, you gather some more data points, and then you might have each of
those managers do a brainstorming session with their team and then take
the results back to you.
And then you might have, you know, some of the managers talk to each
other and then you might develop a draft plan and go message test that
with a handful of individual people on the team. And then you might send
it out to the whole group, right? This is just one example of how a
typical kind of communication development and dissemination process
might happen. It has many steps with different size groups with
different configurations. So one of the original ideas with Muse was to
try to facilitate that better and to create this environment where you
can have things that are moving between private, semi-public and public
and back, and along the way, accreting information.
00:37:47 - Speaker 1: Indeed, and I feel that also touches on the kind
of synchronous versus asynchronous discussion we had in our remote work
podcast and certainly has come up a lot on the news for Teams product,
which is people have the question, is this mainly for synchronous?
We’re all on a call together and we can see our cursors flying around,
or is it mainly for asynchronous, we’re gonna Send documents back and
forth to each other, and I think some of each is the right answer. I
think you get different kinds of ideas, different kinds of consensus and
buy-in from each of these, but yeah, I think it’s too, I don’t know,
laborious, probably wasteful of time, but also for me as an introvert, I
just need time and space to think on my own, and I think many folks.
It’s too much to try to kind of think in a group.
Now you could bring ideas together and that’s where if you’ve all
prepared a bit within the new world, you created boards. We do this
exact thing, especially for really significant, you know, bigger
planning meetings or just discussions about our future, where we say,
look, you should think about this on your own if you can, if you can
find the time, you know, write up your thoughts, which is could be just.
of bullet points, but it could be a really extensive board. We’ll get
all those boards, those kind of individual boards together on one shared
board, and then we can go through it a bit synchronously and get to
shared understanding and hopefully synthesize all of this together into
our best solution.
So I think there’s really places for both of those in the ideal work
process from my perspective.
Well, maybe a good place to end would be books or other resources that
have been helpful to us and discovering our own path to leadership and
what works well on teams. I think you’ve already mentioned the Netflix
culture deck, I’ve mentioned a few books that I’ll link in the show
notes. Do you have any that you think we should mention for our
listeners?
00:39:37 - Speaker 2: I’d actually re-emphasize the history idea. I
think it’s just incredibly valuable.
And if I was to give concrete advice, it would be to pick some event or
time period that you’re really interested in and try to read a half
dozen or a dozen books on that same topic, because again, it’s all
about getting that richness of Of historical perspectives and angles and
information and really understanding the texture of the day to day
decisions.
And you can learn a lot of the same things from different periods
because people have been and are the same. So just find one that you’re
really interested in would be up for reading a dozen books and go for
it. If I was to pick some more classic management books, the number one
book that I recommend to new managers is Slack. I almost feel like it’s
mistitled.
00:40:21 - Speaker 1: I mean, the core thesis of the book is I wanted to
briefly interject to point out that this book predates Slack, the
software product and is unrelated to it, and instead is about the
concept of slack in the system in terms of making your team work at 100%
efficiency means there’s no slack in the system and that has all kinds
of negative downstream consequences for your business, even besides
tired and burned out workers.
00:40:44 - Speaker 2: And if I was to give a bit of an oddball
recommendation, I would say principles of product development flow. This
is a highly analytical book. It’s a cutheoretic analysis of project
management, which I know is quite a ways from what we’ve been talking
about today, but there are a lot of important ideas, especially for
people who work in engineering type domains. So if you have any affinity
at all for that sort of stuff, I really highly recommend it. What about
you, Adam?
00:41:10 - Speaker 1: Yeah, I think for me I get the most value out of
stories, autobiographical or biographical accounts of the lives of
leaders or sometimes teams in a particular high stakes situation.
So certainly when you’re talking about history, I think of, I’ve read
biographies of Abraham Lincoln, for example, and the challenges of
keeping the nation together and everything else going on during his.
Presidency.
Another one I really like is about Catherine the Great, who was a really
pretty visionary and forward thinking leader for Russia at the time and
established a lot of precedents, including writing a super long
manifesto about sort of some perspective on making Russia into something
a step closer to a modern liberal democracy, which is quite
interesting.
So yeah, when you read these stories, they’re not telling you, hey,
Lincoln. was effective because of this thing or Catherine did a good job
because of this thing and therefore that’s a lesson you should apply to
your leadership.
It’s more, I don’t know, just examples and then those may or may not
be directly applicable to what you do, but then you can bring those
stories to mind sometimes if you find yourself in a dilemma or a
circumstance that resembles in some way. What they went through and
think about these examples you’ve seen and how they turned out for them
and then think, OK, what can I learn from that? How can I apply that to
my specific circumstance, my specific leadership style? And I think that
tends to work better, or just be more memorable for me maybe than
something that’s a little more prescriptive or abstract.
But that said, something a little bit more pragmatic. There are the
classic management books, take it, for example, high output Management
by Andy Grove or Management by Peter Drucker.
Although that actually leads me to maybe a final question here, Mark,
which is, do you think that leadership and management are synonymous,
essentially two words for the same thing, or do they represent different
disciplines?
00:43:11 - Speaker 2: I think they’re very closely related. I think
management done well, is just a superset of leadership. Now, when people
use these two words, they’re often saying management in such a tone
that they’re quite dismissive of it and think perhaps these circles do
not overlap at all. And, you know, perhaps it’s valid based on their
experience with managers, but I think management done well, includes all
the aspects of leadership that we discussed, plus you necessarily have
the people responsibility. What about you?
00:43:39 - Speaker 1: Yeah, I really was curious about this and thinking
about how we would cover this topic. I think of it as a Venn diagram to
the point of your circles, and there’s quite a bit of overlap, but they
aren’t necessarily quite the same thing. I think of leadership as more
of forging a new path, and I think of management as something that’s
more continuing or having something operate smoothly.
But I think it’s wrong to think that those can be completely separated
or unrelated because so much of keeping, whether it’s a business or a
property or anything else, kind of thriving is some element of change,
some element of reinvention, so there needs to be some forging a new
path.
If nothing else, just cause the world is changing around you and you
need to keep up with that. And similarly, I think earlier in my career,
I, as an entrepreneur, I was so focused on the forge a new path side of
things that I didn’t give enough weight and importance to the
management side, which includes people management, but also includes
Yeah, just what it takes to run a business or keep your offices open or
that sort of thing. There is this very pragmatic operating element that
is part of what I think of it as management and you can’t really build
a thing and lead it without some portion of that. So yeah, I don’t know
if that’s enough to do a whole podcast on management in the future or
maybe the two are So bound up that it’s not helpful to differentiate
between them. But for me, I think it was somewhat of an epiphany moment
to realize that there is this discipline called management that it is,
as you said, maybe it’s a super set of leadership or maybe it’s just
an overlapping piece, and indeed that name or term or concept appears in
product management, for example, and I think there’s a Subtle meaning
to that that is useful to understand, at least for me, when I did start
to understand it, also greatly expanded my understanding of what it
means to be a leader and how I wanted to grow in my career. So, yeah,
it’s a tricky one.
00:45:44 - Speaker 2: Flipping this around, I think it’s the case that
one doesn’t need to be a manager to be a leader. Perhaps that’s a good
message to close up the podcast with, but this is something that anyone
can step up and do. And indeed, it’s the nature of leadership that
people aren’t going to give that to you, something that you have to
take on yourself and demonstrate initiatives going back to one of our
very first points about vision and belief and conviction.
00:46:06 - Speaker 1: Yeah, to me, that’s actually one of the best
moments on a team is when someone sort of unexpected steps up, takes
ownership of something, takes the lead on something, and they don’t
need to be the boss, and they don’t need to have vested authority. They
just see a problem, see an opportunity for things to be better on the
team and find a way to lead.
In the direction of how that can be improved, and seeing that happen,
spontaneously seeing that person grow into whatever that leadership
moment is for them is, to me, it’s one of the best parts of being on a
team and doing the work we do. Well, let’s wrap it there. Thanks
everyone for listening. Join us in Discord to discuss this episode with
me, Mark, and our community, the links in the show notes. You can also
follow us on Twitter at MA HQ, and Mark, thanks for all the leadership
you’ve shown in all the various teams we’ve been on together over the
years.
00:47:02 - Speaker 2: Right on, well, learned a lot for you, Adam.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Often when you ask an expert who’s accumulated a
large amount of experiential data around a problem area, they’re
fabricating an answer. They actually have way more information than they
could possibly convert into a verbal symbolic language, and the
inability to articulate something doesn’t mean that there isn’t
knowledge there, right? Taste is real and experience is real, and you
can have a lot of knowledge that can be extremely difficult to
articulate.
00:00:31 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product. It’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with my colleague Mark McGranaghan. Hey Adam, and joined
today by our guest Connor White Sullivan of Rome Research.
00:00:49 - Speaker 1: Thanks for having me on.
00:00:49 - Speaker 2: And Connor, I happen to know you have a dog
companion. There’s a husky, right? He is.
00:00:55 - Speaker 1: One thing I like about them is that they’re not
bred to be obedient dogs, cause you didn’t want somebody who was an
inexperienced sled driver to drive the whole team out onto thin ice. So
the dogs sort of take a light suggestion, which is one of the reasons
they’re particularly hard for first time owners.
00:01:13 - Speaker 2: I feel like they take light suggestion also is a
good training for being a manager of software engineers and designers.
00:01:20 - Speaker 1: Or maybe a parent too, but uh, yes, a parent of a
toddler, absolutely.
00:01:23 - Speaker 2: And I think our audience probably knows who you
are and knows about Rome cause you’re definitely a notable figure in
the tools for thought scene that we consider ourselves part of, but for
those that aren’t familiar, maybe you could give us a brief
introduction.
00:01:39 - Speaker 1: How would you introduce from?
00:01:42 - Speaker 2: I consider it having created not only the kind of
modern phenomenon of tools for thought, which obviously that concept
extends well back in time.
Indeed, Mark and I did a whole podcast on it, but in terms of
popularizing it in kind of the last few years, it’s really, I think,
opened the aperture for a lot of tools, including us and others to say
there’s more to productivity software than, I don’t know, email and
note taking in calendars, and that’s what I think of as the collective
kind of tools for thought, scene.
And then the, the specifics of the product, I think it really is all
about the value of linking thoughts together and bringing things that I
think of as being part of obviously the internet, part of things that
have been in our knowledge tools in different ways over the years, but
putting them together into this kind of notes and Personal memory and
personal thinking space in just a new way that really struck a chord
with people indeed to the point that I think it’s been widely copied
now and I would say you basically invented or at least pioneered a whole
new category of software, which is quite a special thing to do in one’s
career, I would say.
00:02:46 - Speaker 1: The thing that is interesting to me is that part
of my frustration in the last few years is that none of the folks who
have supposedly copied us have copied the things that I think are
actually important or are even indicative of the direction of like why I
built Rome or what we’re aiming for.
I think of writing as a tool for thinking. We’ve talked about this in
past discussions, just one on one. I don’t have a great extended
working memory. Like, I’ve worked with people who are actually geniuses
who are able to visualize complex systems in their head, who are able
to, you know, recall any piece of information they need, but I have a
hard time just Laying out all the steps of the problem and trying to
think through all the variables that are there, and just trying to keep
my head straight, especially around things like software design, let
alone systems design or building a team, or any kind of complex
decision.
So, Rome, what you see right now as a product is something that did
largely evolve as a sort of cognitive prosthetic for me.
Largely I handled my ADHD and trying to learn as an autodidact, all of
these things that I needed to do to be able to build Rome.
I’m self-taught engineer, self-taught designer, self-taught manager,
maybe not good at any of these things, but I had to learn how to
fundraise, had to learn how to do marketing, like, I studied none of
these things, had no formal training in anything, and I had to figure
out how to get good enough at a lot of things.
At the same time, more or less, or in various sequences.
So, I built Rome as a tool for helping me to organize my own learning
and also just to, I’ve had very severe ADHD for my, my whole life, and
it runs in my family, but it is not. I think Mark, I might have heard
you say it on a podcast, or maybe it was some other colleague of yours
that was on saying that they were characteristically unemployable or
something. Well, I was fortunate for startups to exist because I don’t
think I could have held down like anything even remotely resembling a
white collar job, for any amount of time if I had not been able to, to
build my own companies where I couldn’t get fired. So, a lot of Rome
was built as a tool for me to be able to just organize my own thinking
as I was thinking. So, I think of it first and foremost as an extension
of my working memory, so that I can Zoom in, eliminate all the
extraneous things, have a clear workspace, but then at any point, I can
pick up pieces from, I can break problems down into smaller chunks and
know that I will have the relevant information available the next time
I’m able to pick it up, which might be some indefinite point in the
future. So, R Rome is a tool for writing, but it’s also, and I’ll talk
a little bit about It’s a little hard to fully explain, especially what
we’ve been doing over the last few years, if you don’t know the
context of why I started Rome, and what it’s trying to get to, and why
I, like, even got interested in software in the first place, but I
don’t want to tangent too far yet. So yeah, it’s a different medium
for writing and thinking and trying to Organize your brain so that you
can think thoughts. The way I said it before like this, there are things
you can’t see with the naked eye that you can see with the telescope,
and there are things that you can’t hear, but, you know, if you’ve got
a powerful microphone, you can hear them, and I think that there are
thoughts that we can’t think unless we’ve got some sort of cognitive
AIDS. And Brett Victor has talked a lot about this. I know you guys are
probably fans of his work. I’d love to chat a little bit about some of
those ideas, but I think that a lot of our diagramming tools,
mathematical notations, programming languages are all cognitive
prosthetics that allow you to think thoughts you couldn’t otherwise
think, and Rome is It’s also a programming environment. You can write
code and execute it in code. We’re trying to create a whole new kind of
medium for expressing your thoughts first to yourself, but then
eventually be able to create a communication medium that can allow for a
different kind of coordination and knowledge transfer, and a new kind of
collective action, collective thinking, collective intelligence, and
that’s the real thing that has been motivating me for at least the last
15 years. Which kind of leads me into the questions that I want to ask
you guys.
00:07:07 - Speaker 2: Well, please do. I have something to say about
what you just said.
It’s very inspiring, especially because in many ways you’re not
talking about the specific features or exactly the way that how does
this writing slash thinking slash notes slash memory tool differ from
what comes. Before, but this underlying why, which is exactly as you
said with Brett Victor, I think Andy Metzek talks about this a bit in
his work, talking about, for example, Roman numerals versus Arabic
numerals and how that allowed us to, yeah, essentially do new things,
think new thoughts, do new kinds of Math and the computing medium
obviously has all this potential to open that up, but to date, even as
far into this computer thing as we sort of are in many ways we are just
transliterating, OK, I’ve got a sketchbook. OK, now that I’ve got an
iPad, let me make a direct transliteration of what’s on paper. I’ve
got. A typewriter, let me turn that into a word processor and so forth,
and I would say most notes programs, even pretty sophisticated ones, I
don’t know, you take every note in prime 10 years ago can obviously do
a lot of things that like a paper filing system can’t do, but in the
end it kind of is just that on a computer. And it seems very clear to me
that there’s so much more potential if we truly embrace the dynamic
medium of the computer, and there’s probably 1000 different experiments
we need to do, and different people will need different things, to your
point about what exactly is the right thinking prosthetic for you
probably is also for a lot of other people, but maybe not everyone in
the world. Different people need different ones, and that’s why I think
it’s so. experiment and break out of our established categories, but I
felt like a few years back you couldn’t get past the like again
productivity software just kind of like notes, email, word processors,
spreadsheets, and happily the tools for thought seeing that you really
helped seed, I think has opened our minds to like, OK, let’s do some
innovation here.
00:08:57 - Speaker 1: Even the idea that you could have end user
customization where people could actually write code, I mean, like, We
got so much push back when we let people run arbitrary JavaScript
inside, and I mean, rightly so, because it’s also a multiplayer tool.
Obviously there’s some security concerns, but my entire thesis is, I
want to give people power, right? And I know I’m extremely neuro
atypical. And I know that a lot of systems, which worked very well for
plenty of other people, worked horribly for me, right? Schooling being
the sort of most obvious one. So I know the feeling of being put into a
box and the box not being extremely constraining and wanting to do more
and needing people who do not want to give you their permission. I hate
asking for permission. And so, that’s one of the reasons that first I
was like, well, Wild West, you wanna run JavaScript, we will give you
the ability to completely break everything in your graph.
Like, if you wanna really mess yourself up and just like grab some code
that you found off the internet and put it in there, and like, maybe
you’ll lose, you know, all your notes because you’ve got some random,
I don’t, especially in the early days when it was still a small amount
of attention there.
I have a very different attitude than folks with the security mindset
of, well, what if hypothetically, somebody might be trying to steal my
notes? I’m like, you’ve been using the product for a day and a half.
Like, I don’t think this is a hard target yet, but I get ahead of
myself. I have been really excited to see that proven out, you know,
that people now are trying to Do something that was pretty common in
things like text editors and for Emacs and Vim and for professional
programmers are very used to the idea of being able to modify their
tools.
And if you work in the trades, like my recreational activity is doing
metalworking, you know, I like welding for fun, right? And one thing I
like to do is like making my own tools and making jigs, and like, if
you’re doing any kind of carpentry, You know, oh, you don’t have the
exact right tool for it. Well, if you’ve got an angle grinder and
you’ve got a welder, and you’ve got some scrap metal, like, you might
be able to jerry rig something up that might be able to serve the
purpose of what you’re trying to build a one-off tool, and we haven’t
had those for knowledge workers, except for in the domain of computer
programming, and I think that people who do other kinds of work, it’s
been very exciting to see so many like, Folks who are doctors, who’ve
never written a line of code in their life, and they’re able to learn
in the weekend enough to build some functionality into Rome that like,
is not my priority. I don’t care about it. It would never occur to me
to make it, but it’s ideologically important to me that they not have
to get my permission to make the tool do what they want to do.
So here’s the question I’ve got for you guys, which is, when did you
guys start caring about computers at all? And what was it that made you
care about them?
00:11:54 - Speaker 2: Yeah, I usually peg myself for 8 years old, and I
think it was an Atari with 1K of RAM, since I’m old enough that that
was the kind of computing.
I think we had one of these in our entire school, the elementary school
I was in.
I don’t know what drew me to it, maybe this is just a classic young
nerd thing that you can’t identify it, but I like to at least post hoc
rationalize it that I saw the potential for creativity and I immediately
want and all you could really do with program computers back then was
program them, right, like they could use logo, maybe later basic and
you’d get in there and just in the same way that a kid just wants to
pick up that piece of paper and the crayons and start drawing scribbles,
and that it’s this form of expression. I saw the same thing in the
computer and just was endlessly fascinated with it.
00:12:42 - Speaker 3: What about you, Mark? Yeah, similar story for me.
I did not have the experience of programming very young. I didn’t do
any really substantial programming until I was in college. And the
specific impetus for me was, I was studying economics, among other
things, and I wanted to do agent-based simulations to test out some
economic ideas. And so, OK, I got to teach myself Java. And I remember,
in retrospect how completely terrible that Java program was, just the
incredible amount of copying and pasting. You wouldn’t even believe it.
But anyways, at that point, I got into that track that Adam was
describing where it’s an incredibly powerful and accessible medium for
creating. I’ve always liked creating things like I did model airplanes
and other stuff like that. But there’s actually a pretty narrow set of
things you can actually do that’s both powerful and accessible. Maybe
you are into welding, but as a 19 year old in rural Maine, it’s kind of
tough, right? But you can get a computer and do whatever you want. And
you don’t need to ask anyone’s permission, and the sky’s the limit.
So it’s pretty cool.
00:13:39 - Speaker 1: I want to touch on both of those. Adam, you’re
talking about being a nerd. If you can imagine it, I was such a nerd I
didn’t have enough friends to play D&D with. Let’s say that, like, I
used to play this single player D&D type book.
It was like a choose your, I don’t know if you guys might have been
actually maybe. Too old to remember the RL Stine Choose your own
adventure books, those were like really big in the 90s. 0 yeah. There
was a game called Quest, and it was individual paragraphs, each with a
number, and it was like, oh, if you go down the right hallway, go to
232, if you go down the left one, if you fight the goblin or whatever.
But I remember playing these games all the way through, and then I
actually made the multiplayer.
I did have two friends who were nerdy enough to indulge me in this for
like, A couple recesses before they were sick of it, but I played the
games all the way through and then continued the rule set for the game
and just started writing paragraphs at the end of the book to try to
like keep the game going, because they were originally supposed to
publish, like, 10 of these game books, but only 2 of them got published
in the US so, and in some ways actually there’s something reminiscent
of Rome in that sort of backstory.
You’re talking about agent-based simulation for economics, Mark.
Here’s the next question I’ve got for you guys. What’s the first
problems or bigger problems that you remember and awareness of, or even
caring about?
00:15:00 - Speaker 3: I’m gonna give you sort of a half answer here. So
there’s certainly problems if I go back in my memory when I was a very
impressionable kid, you know, whatever.
The 3rd grade science teacher says, you know, all the turtles are dying,
so everyone, you know, goes home and clips all the six-pack plastic
things and, you know, stuff like that.
But something that’s still sticking with me is when I was working in
computers and originally I had this very unalloyed excitement about the
cloud. Coming out of college, I was like the cloud services in
particular. This is before I was even at Hiroku. It’s just so powerful
to be able to have a hosted service that does everything for you, and
the end game is everything moves to that model.
And I would say I still think there’s a lot to that.
But it was only with the experience of living in a society that has
embraced that model that you realize some of the really tricky downsides
of it. Something I’m still grappling with is someone who works in
computers. So we could do a whole episode about that, but that’s one
that I’ve definitely thought about.
00:15:53 - Speaker 1: Our follow-up question. You guys know the phrase,
you can’t solve the problems you have, it’s attributed to Einstein,
you can’t solve your current problems with the thinking that got you
into them. Yeah. Do you know the exact quote?
00:16:06 - Speaker 2: We can’t solve the problems by using the same
kind of thinking we used when we created them. Yeah. Yes. Yeah, and I do
think there’s a maybe a positive spin on that, you know, one is like,
we had dumb thinking and then that led us to be in a bad situation and
we need to be less dumb.
But another way to put it might be that in moving yourself or your group
or society forward with better thinking, well, that creates new problems
like the cloud. Version there that Mark mentioned and now you need to
solve those new problems, but on net you’re probably better off than
where you were before. It’s just that the idea that anything is going
to bring a panacea utopia where all your problems are solved and now we
don’t need to have new thinking and new solutions and be aware of the
downsides of the world we’ve created, that will basically never happen.
00:16:55 - Speaker 3: I think you can even generalize it and say, even
if there’s not progress, there’s change, the world is different.
There’s no going back, you know, that’s the way it is. The only way
out is through.
00:17:06 - Speaker 1: So I thought that’s The potential hope is
networks. I politically became really alive when I read Yochai
Benkler’s The Wealth of Networks, and, you know, saw lay shirky,
organizations, institutions.
My life plan was to sell John Deere tractors in Africa cause it seems
like the coolest job I could do. I was planning on like doing a few
years in college and then like going and being like a heavy equipment
salesman in Africa because I wanted to travel, and that looked like a
job that would pay for me to travel to really crazy places.
And I thought, you know, excavators and tractors were cool. So I was
like, yeah I’ll probably do that. That was like my freshman year plan,
and then I was like, oh, but actually, we might be at a period of
history that is as important as the printing press.
00:17:50 - Speaker 2: Part of the thesis, I guess, of the wealth of
networks is that the creation of this network society through the ever
increasing communication capabilities, the internet being the kind of,
at least to date, the ultimate manifestation of that creates a moment of
opportunity to have an impact, to change the way the world works. Again,
that’s certainly where the startup world sees itself as an This highly
dynamic, you know, early stage thing where you have the opportunity to
maybe have more impact than you would as an individual. So was it that
part of the book that sort of inspired you to think, OK, well, it was a
couple of things.
00:18:22 - Speaker 1: It was the idea of non-rival goods. So first, the
idea of, I’d make something and it costs $0 for there to now be a
million versions of it, right? And That because the goods are non-rival
and they’re post-scarcity, like, they have a different kind of economic
pattern to them.
That was one aspect of it. And so he sort of had a four part quadrant,
that he was sort of laying things out.
He was thinking about the state, the firm, the market, and the network.
So, a state would be something which is public goods, like, you know,
they’re trying to manage resources that cannot be sort of carved up
into small pieces, you couldn’t have property rights on things like
Clean air, you know, so places where there’s lots of externalities and
like one person could hurt the commons.
But there isn’t less private incentive for people to maintain or
protect the commons.
So the state historically has used coercion for the governance of the
Commons. So the state would be centralized management of a commons, the
firm would be centralized management of private resources, the market
would be decentralized management of private resources, and the network
is decentralized management of public resources. So, like, it allows for
the creation of new kinds of commons, particularly information commons.
00:19:43 - Speaker 1: And so here we’re thinking what open source or
the way that like DNS works where there’s no, I mean, I also was
interested in Ray Kurzweil at the time, so I was thinking general like
techno utopian post scarcity, like what happens when we can 3D print
organs and the more we can get to actually we might be on the cusp of
technology that allows you to take things from the digital world into
the physical world, and this could be potentially somewhat revolutionary
in terms of if I can get any medicine that I need. By like downloading
it, and if someone can make an open source version of the medicine that
I need, like, that was the kind of one aspect of what I was thinking,
that was that book.
But the other thing, I think it was mostly just I got some hope that
like, hey, there’s, you know, Linux.
I also got then disillusioned but I did a bunch of open source stuff. My
undergraduate thesis was on trying to create a way of we finding a local
government and actually like making a more direct democracy type
approach. Under the assumption that, you know, people have a ton of
tacit knowledge, like, there’s voices that are not heard that have
expertise that is not like, recognized and you need culturally relevant
solutions. I was coming from anthropology background, so I was thinking
a lot about like, the thing that is gonna work in a rural village in
Ghana is like not gonna work necessarily in Boston, Massachusetts,
right? And even the thing that’s gonna work in Southie is not gonna
work in Jamaica Plain, maybe. Like, you need to tap into the resources
and the culture and like the actual lives and local contexts, lived
experience of people who are in a community.
00:21:11 - Speaker 2: You know, I’m a huge fan of being close to the
problem, let’s you, like you said, tacit knowledge, understand it in a
way that you just can’t, but yet as our societies get bigger and
literally this is just a scaling the number of humans thing that exists,
which is governments are going to naturally get further away from the
people, right? The government of the United States 200 years ago when
the population of the United States was a tiny fraction, you know, it’s
much closer to those people whose problems it’s hopefully trying to
solve.
00:21:40 - Speaker 1: Do you guys remember your first ideology?
00:21:44 - Speaker 3: Baby’s first ideology?
00:21:46 - Speaker 2: Ba’s first ideology. Yeah, I mean, the classic
thing you have with, yeah, let’s say university students is, yeah, they
get really into environmentalism or something like that, and it becomes
almost the purism of it, right?
00:21:57 - Speaker 1: Do you remember the first thing you were
ideological about? I, it’s easier to call it an ideology if you’re
like post, if you’ve left it in some ways.
00:22:03 - Speaker 2: Yeah, probably open source actually.
00:22:04 - Speaker 1: Open source. How old were you?
00:22:05 - Speaker 2: And Linux specifically, this is the year of Linux
on the desktop, you know that this year is Linux on the desktop?
00:22:11 - Speaker 2: Well, being the kind of lover of open source
belief in what that could bring and thinking, OK, commercial software’s
days are numbered, eventually we’re all going to be running, you know,
things that are developed in the common for the common good. It’s just
a matter of time. So yeah, I think that was probably one of my first in
the late 90s.
00:22:29 - Speaker 1: I was definitely in that ideological camp until I
try to run an open source project. And then I realized it’s a lot
easier if people actually can make a living and do the thing full time
and yeah. What about you, Mark, do you remember your baby’s first
ideology?
00:22:44 - Speaker 3: Oh, I was gonna give you another half answer,
which is, I’ve always been more of an is than an art person. I
associate isms with thought, you know, the world ought to look like
this. And there’s something to that. And of course, people having aught
notions feeds back into what is.
But for me, I keep myself busy just trying to understand what’s
actually going on and the dynamics that are unfolding. As you understand
things better, you certainly develop notions about how they might be
different, or how you might want them to be different, but I try to keep
a real close eye on how The world actually is, cause just understanding
that is quite hard.
To give you a concrete example, you had talked a little bit about
technological determinism. Just understanding how the various
technologies that have and are evolving, what that means for us is
incredibly not obvious. Even something like computers, or even
networking is networking going to be centralizing? I don’t know, it’s
right in the name, shouldn’t it be? Or is it gonna be highly
centralizing as, you know, for example, Samuel Burge has argued in one
of his pieces that we can link to. It’s not obvious to me.
00:23:43 - Speaker 1: All right, well, I mean, we can take a second on
this because I think the best kind of prophecy is worth telling, right?
Where certain kinds of things, like the most interesting predictions are
self-fulfilling predictions, right? Something where because you imagine
a thing to be possible, and you believe that it’s worth your energy to
try to make that thing possible, you can make the thing possible, right?
I mean, both of you guys have made startups happen out of nothing. Like,
nobody makes anything happen out of nothing, but like, The early stages
are crazy, because it’s not a Ponzi scheme per se, but like, you need
to convince investors that you’re gonna be able to convince engineers
that you’re gonna be able to like convince customers, like, it is a
crazy balancing act where you have to make a vision into a reality. Even
just in the assembling of the early team, and the raising of enough
capital for people to quit their jobs for long enough to get the proof
points to convince more and yeah, I think there is a faith based element
to it.
00:24:38 - Speaker 1: Yeah, I mean, my thinking is there are two ways,
you know, the idea of a map territory conflict?
00:24:41 - Speaker 2: Yeah, right.
00:24:42 - Speaker 1: If the map I have in my head doesn’t match the
territory, there’s two ways I can change things. I can try to update my
map, or I can get a bulldozer and I can try to change the territory,
right?
00:24:51 - Speaker 2: Yeah, there is something to that. The power of the
ideological person and often the world are changed by young people that
have sort of like an unrealistic vision because they aren’t stuck in
the status quo and they are willing to take that bulldozer in, but it
has to be balanced somehow by pragmatism.
00:25:08 - Speaker 1: My first company was trying to make an online town
common. The idea was if you could get the for any local issue, and every
issue could be made into a local issue, was the sort of the hope, right?
If you could accumulate political capital, Online. So if you could
confirm that all the people on this little forum thing were actual
registered voters in this town, was the mechanism that we had for trying
to accumulate political capital, then you could sort of force a more
responsive local government and start to sort of decentralize the place
where people are most likely to influence and get some power.
And the idea At the time, I was hoping, you know, oh, if you gave people
that like, then we could actually have democracy experiment everywhere,
you know, like, but it totally didn’t work. It totally, like, I didn’t
even want to use it because I realized I didn’t care that much about,
like, you know, the property taxes and like the paving of the roads, and
like, what to name the new library, like, just the local politics issues
were so boomer. And I was like this little 19 year old, like libertarian
socialist, like, we’re gonna have an internet anarchism revolution, and
all of my users for that product were like 60+. I was so glad that I had
no power to coerce anyone to do anything cause I just didn’t understand
the world. So I became even more pro startups because there’s something
beautiful where you have to Be right about making something people want.
You have to both have a vision, but that vision does get tested against
reality of like, will it blend? Like, can you ship it? Like, when you
ship it, will anyone care? Like, if you build it, will they come, right?
You kind of have to believe it in order to build it, but reality will
test you there, which is one of the reasons I like startups, and it’s
also one of the reasons why I’m hopeful for more. diversity of
political entrepreneurship or things like that. Like, it’s one thing I
really do share in common with biology and the hope that there will be
more micro nations someday in the future and actual entrepreneurship and
meaning bounded communities or something, something like that. Utah is a
great example of like, somebody put out a vision and a bunch of people
with the same kind of ideas. Utah is the original network state.
00:27:32 - Speaker 2: Certainly makes me think of charter cities, which
is certainly another kind of libertarianism type sphere idea, but yeah,
it is that idea of it’s not just about self-governance and getting to
choose, but also the let 1000 flowers bloom. We have to try a bunch of
stuff because, as you said, Ideas have to be tested in the real world,
and we can sit around and debate them, and indeed people do, but until
you can try it at scale, over time, see how it actually impacts
people’s lives, do people really want to live in that place that does
change society in some fundamental way?
00:28:03 - Speaker 1: Yeah. So here’s another question I’ve got for
you guys, which is like, and I’ll give my answer first, but I’ve been
thinking recently about just Beliefs that sort of lodge in your head
that end up propagating into all sorts of other things, and you don’t
necessarily go back that often to reexamine them. So I’ll give one,
which is the idea that like, creative work can’t be coerced. And I
think this is part of why I’ve been so pro volunteeristic type
associations and like trying to figure out networks for mutual aid and
ways for people to help each other, where it is a very opt-in system.
But I think it might also be just directly related to me having a pretty
oppositional, like low agreeableness personality where I really don’t
like to be coerced in anything, so, like, I just, I assume that good
work can’t happen under real coercion because I won’t work under
coercion, therefore, you know, I don’t know if anything jumps to mind
for you guys in terms of like, little beliefs like that that might
color.
00:29:08 - Speaker 2: The core of critical thinking, I think, is trying
to examine beliefs that are in your mind and how did they get embedded,
and the reality is it’s rarely a I encountered a new idea, fact checked
it carefully, and then decided to make it part of my worldview. It’s
more you get exposed to something a lot over and over again and it just
through osmosis sinks into how you see the world, and I always find it
funny.
To stumble across little beliefs, even just things like, you know,
should you keep this particular food item in the fridge versus is it OK
to, you know, sit on the shelf stable and sometimes there’s just
something I picked up when I was a kid from one of my parents or
something, and I didn’t realize until I was an adult that actually you
can stick that on the shelf. I just never examined it, right?
00:29:51 - Speaker 1: What did you keep in the fridge that you didn’t
need to keep in the
00:29:53 - Speaker 1: fridge.
00:29:54 - Speaker 2: Remember what maybe it was uh potatoes was one
that was like that. It does slow down they’re like budding or something
like that, but I don’t know, I think my mom always stirred potatoes in
the fridge and then yeah, I had a roommate that was just like, I’m just
going to put them on the shelf. We don’t have room in the fridge. I’m
like, wait, you can’t do that, you know, they’ll spoil, but then I’m
stopping and thinking, well, wait, how do I know that or why do I think
that? And the answer is, you know, it’s just something I absorbed.
00:30:17 - Speaker 1: What about you, Mark? Do you have any things
you’ve noticed that were like, it’s the most general question. Do you
have any unexamined beliefs? Yeah. With a terrible question, I, I
apologize.
00:30:28 - Speaker 3: I’m not sure if this is exactly what you were
asking, but there are some lenses I keep in my pocket. I’m always
putting them up and using them to look at the world.
So one lens is the lens of trade-offs from economics. It’s very easy to
speak in absolutes or to speak in terms of improvement, integradation.
The reality is almost always one of trade-offs.
Another one that I use all the time, relatedly is Distributed
information processing.
This kind of is related to your idea of mutual association. The world is
so complicated that there’s no way for it to be understood,
essentially, especially when you consider that a lot of the things that
are important to understood are matters of personal preference.
So it’s not physically possible to bring that information into one
place, compute, and to spit out results about what ought to happen. So
it has to be done in a distributed way.
And it’s so easy to fall into the trap of, you know, what if we just
brought all the information in one place and figured out what to do? It
just, it can’t be done. And when you remind yourself of that all the
time, you come across many cases where you see people trying to do that,
to try to extract the information and put it through an explicit machine
and turn out an answer. And you have to instead just let it be out there
and let the network process the information and decide what should
happen.
00:31:41 - Speaker 1: Can you go into more detailing?
00:31:42 - Speaker 3: Well, this is the whole key tenet of Like Austrian
economics or Hayakian economics, people can look up those things and
read about it.
There’s a famous, I think it’s an, I wanna say it’s an essay written
about the manufacture of a lead pencil. And something as simple as that,
there’s actually no one in the world who knows how to manufacture a
lead pencil. Like it has to involve many different people from around
the world, and they all have their own test and knowledge and
understanding of what kind of wood is right, and, you know, they know
about the quirks of the machine and like how it’s always off by one
degree, so you got to counteract that right. That’s sort of thing that
it seems so simple, but even something as basic as that can’t be known
centrally and needs to be distributed out, by the way, not even to
mention. Like how many should be produced at what price, where, what
materials, there’s an incredible amount of complexity that can only be
computed on and distributed way. I just find that a handy idea to go
back to it often.
00:32:33 - Speaker 1: Can you think of examples besides the market?
Like, the first thing that you’re making me think of was, I feel like
I’ve only in the last few years, Gotten language for thinking about why
it makes sense to listen to emotions so much. Like like thinking of
emotions almost as like bass net massive information compression systems
where you’re just getting a vibe about like, oh, this feels off.
There’s an essay called The Limits of Legibility, or it’s like a less
strong post that I like, but often when you ask somebody, especially an
expert, or somebody who’s like accumulated a large amount of
experiential data around a problem area or around a scale or something
like this, like, well, why do you think we should do it this way or that
way? They’re fabricating an answer, like, they actually have way more
information.
Then they could possibly convert into a bit stream that is compressed
into, you know, verbal symbolic language. And so, if you treat the
answer that somebody gives you of why as if it’s actually meaningful.
Many people actually treat the why, especially if they want to argue
about it, as though that’s the real thing, rather than a like tiny
symbolic representation of like, what in that moment they were able to
generate, which might not even be the real thing. Right. And the
inability to articulate something doesn’t mean that there isn’t
knowledge there, right? That is like such a like taste is real and
experience is real, and you can have a lot of knowledge that can be
extremely difficult to articulate. I found this to be extremely
challenging when I was trying to introduce sort of counterintuitive
cultural norms into the company, and I was bringing people who were used
to working in, like, all right, so, since I finally found a moment where
I actually made a point, Rome is not a normal company. It’s because I
think normal companies are what got us into the situation we’re in,
right? I wouldn’t want to work at Google. I wouldn’t want to work at
Microsoft. I would have no interest in being there, like, they’re not
building products for people like me, and also, like, they kind of are,
but like, the thing that I’m interested in is trying to figure out a
different way of thinking together and in a bunch of different ways. But
Especially as I was having folks coming in who I’m trying to
communicate certain practices, especially practices around how I work
with Rome, that had just evolved over time, right? I’ve got a whole
very different way of using the tool than, you know, your average user,
and trying to communicate why I do things a certain way or why I was
even asking somebody to do something a certain way, it was very hard to
do. If there wasn’t trust that there was some intuition there, and that
the words that were going to be used as the explanation for why we’re
trying a thing, we’re not the actual only reasons. Like, I could come
up with a 100 reasons for why we might try to do the thing.
00:35:26 - Speaker 3: Yeah. It’s such an important point, and we’ve
mentioned it on the podcast many times, but I think it’s worth
reiterating that experience and judgment and expertise, they’re
incredibly multi-dimensional, you know, millions. Millions, billions of
dimensions, right? And there’s no way to compact it down either in
terms of the model itself of experience, say, or the answer to some
discrete symbols, as you were saying. And furthermore, when you get
discrete symbols out, they’re often just back solved, like this huge
multi-dimensional model spits out in an intuitive answer.
But then it’s unsatisfying to convey that so the brain just like finds
a way back through symbols it knows to convey something that sort of
ends up at the destination, and it sort of plausibly sounds like a quote
unquote argument or quote unquote reason, but it’s just totally
backstop of that how they actually got the answer.
Now I’m gonna turn this around, because this is an idea that I’ve
embraced in my own thinking, but what does that mean for a tool like
Rome or other tools for thought, which are inevitably collections of
discretized pages and links and things like that. How do you reconcile
those two worlds?
00:36:29 - Speaker 1: TLDR, my first startup, I started as an open
source project, could not recruit anybody to actually work on it, was
somehow able to pitch it as a business plan competition, like at
business plan competitions, got 10K, suddenly could get actually better
engineers and the ability for them to work full time.
And so I found having an open source like political project, plenty of
people who were interested in the idea, but nobody could actually help
me build the thing.
A lot of the talent, as soon as I framed it as, oh, well, like, I guess
we’ll make it a media startup and maybe we’ll sell the data. Like,
it’s disgusting to think about the idea of selling political data now,
but at the time, I was just trying to figure out how do I win this
business plan competition, so somebody will give me some money.
I worked construction before I got into tech. That was my summer job.
But it was a terrible business. You know, I got to give like some TEDx
talks and go to the Aspen Institute, and we did end up getting acquired
by AOL, but It was not a good business model.
We were selling software to newspapers to get high quality uses
generated content on like super niche issues that they were like,
civically important for the mission of newspapers. It was just a bad,
bad business. And I was trying to solve so many problems at once, in
terms of how do you build a user interface for collective intelligence?
How do you think about the political dynamics of like, OK, what people
are excluded if you’re using real names and you’re using local, like
voter registrations. The problem of political coordination plus how do
you crowdsource from a large body of people the actual best ideas from a
broad perspective, so that you don’t have to read every comment. I was
trying to solve a bunch of things at once, and I found that I actually
had to do some sort of science, and the fact that I couldn’t isolate
any variable was like just blah.
So after that company was bought, I was still interested in how do you
build a better way for groups of people to In a weird way centralized
their decentralized knowledge.
So maybe the Hayek point is, it’s not even perfect execution, this is
just a bad idea. I’ve wasted my whole career. Maybe like, if I just
read Hayek, I’ll be like, OK. The collective intelligence stuff isn’t
gonna happen, but I wanted to simplify the problem. And so my first
thought was, if I am able to be as a single player, Able to take the
best writing that was done. So, like, one problem we had in the first
company was, how do you get critical mass for a social network, and then
how do you create a ecosystem that actually inspires people to be as
articulate as they possibly can be about what their position is, or like
why you should do the thing. How do you actually get people to give
really, really high quality content, and then how do you from a large
mass of users. Identify the best content from a diversity of
perspectives, because instead of just having people vote down ideas that
are good articulations, but they happen to disagree with, how could you
actually get the best ideas from many different perspectives and see
this sort of multi-dimensional object of, like, any kind of question,
but we were particularly starting with these local political questions.
And my thought was the simplified version of this problem is, well, one,
we had only been able to launch in places where we had critical mass for
my first company which is called Local Acracy. And so I was like, the
tool has to work without critical mass. It has to work as a single
player tool. And if I can start with the best writing throughout all of
history, and I can be the one who’s aggregating it, and I can figure
out how to like map these different perspectives together. Well, now
I’ve just isolated a bunch of variables because I don’t have to worry
about getting the best, like, articulation of an idea. I’ve got the
entire corpus of human history. I can just pick out what I think are the
best articulations of the idea, and I don’t have to worry about
critical mass, cause as long as I’m interested in the problem, I can do
this, or as long as anyone’s interested in the problem. And so, There
was a book called The Sentopicon. They’d spent like 50 million bucks.
It was from Encyclopedia Britannica, and it was a great books course of
all the best ideas of Western history. And the first two sections of the
book are an index of these ideas where they sort of summarize it, and
they point to the paragraph number of, like, where the ideas articulated
by Descartes, or Hegel, or Marx or Kant or Plato, or whatever, right? So
I was like, well, if I can make a digital version of this, and I can
make it for a single player. And then I just charge money for that. I
don’t have to worry about selling software to newspapers who then run
into advertisers, and like, I have to convince a bunch of other people.
If I can just find people who want to organize thoughts, and I just sell
it to single players, then I can maybe get the iteration cycles that
I’m gonna need. I can basically keep this company alive long enough to
run through all the iterations to solve this potentially impossible UX
problem of how do you actually create these high dimensional objects.
That represent many different perspectives around a single sort of truth
thing. Like, how do you build a truth engine? How do you build a system
that actually allows you to sort of create this base net so that your
beliefs could propagate.
00:41:27 - Speaker 2: Well, I see the breadcrumbs now. You start with
kind of collective action and you’re thinking in terms of governance,
but you’re also thinking in terms of networks and how to bring together
sort of computing and some of the open source and maybe kind of more
freedom oriented ways of organizing ourselves. You tried to do that with
software for kind of participation in government and that was a total
bust, but it leads you into the like it was so poor.
00:41:52 - Speaker 1: I mean, it’s like. Imagine selling software to
government. Now imagine that you have to sell software to government and
to the newspapers that are going through like massive decline at the
same time, and the subject matter that is gonna be discussed on there is
like extremely boring.
You guys familiar with Michael Nielsen’s reinventing Discovery? That
was the book I was looking for for forever after my experience with
Localocracy and then trying to work on, cause when I ran a labs group
briefly and poorly at Huffington Post, cause after we were bought by
AOL, we ended up in the editorial division for HuffPost, and then I just
was able to spin out my own little labs group for about a year, focusing
on kind of collective intelligence, crowdsourcing knowledge, figuring
out ways of doing new stuff. And anyways, the book that I found that was
sort of one of the better textbooks on thinking about the problem of
collective intelligence is that one.
And he talks about things like The problem of a conference where, even
if you have all the experts in the same place, you’re not necessarily
routing the right people for the right conversations. You have to worry
about when you’re making everything synchronous, whether people had
enough coffee or whether they’re distracted by something, like, you
want to be able to allow for a certain kind of serendipity to be more
Predictably happening and like remove the sort of constraint of they
have to be in the physically right place at the right time, they have to
just happen to bump into each other.
When you run into somebody, you don’t know that they know something
that you need to know in order to solve the problem that you’re working
on, but you don’t know what the name of their knowledge is and blah
blah. Like there’s certain kinds of human routing or information
routing problems that he lays out pretty well in there. He calls it
efficient allocation of expert attention.
And so one of the reasons Ro is block-based even is just trying to work
with that.
So not just thinking about thinking in terms of Blending, programming,
and writing. So you’re not just writing paragraphs, you’re actually
trying to think about a kind of data structure of a pattern of thought.
And that’s a lot of what I’ve been trying to create as a medium is,
you know, if you think about block references, which is something that
none of these so-called roam clones do at all.
I don’t know any of them that are actually multiplayer, right? The
reason I’m referenced your offline talk is like, we’ve been
multiplayer from day one, even though we’ve been a single player tool.
Right? That was actually architecturally some of the hard stuff to
figure out was like, how do I make this thing work as sort of a
collaborative real-time thing with a graph database and start thinking
about the interpersonal dynamics of referencing somebody else’s
thought, or like, what are the different ways that you write when
you’re trying to write almost as statements that you’re expecting to
be reused by other people? How do you think about version control of a
statement? Or like the way someone might transform a statement or
rephrase a statement. Like, these are the kinds of, you know, it, it’s
thinking about language in a different way than paragraphs or pages,
because we’re trying to think about how to create an object where
you’re not gonna have to read the entire history of a Slack channel
when you go into it to get up to speed.
You know what the group knows, actually, if you’ve got a new piece of
knowledge that really would have unlocked something that the group was
talking about 6 months ago, you know, and the group kind of shelved that
whole discussion because they didn’t have that knowledge, how does your
knowledge immediately fit in and unlock that? Right? So, it’s thinking
about a different kind of collaborative thought data structure. And so
things like block references and the ability to build a statement up out
of other statements, having unique ideas for those. Yeah, that’s the
kind of work that I think is important about Rome and something that
never gets talked about on any of the YouTube videos of users. I’m not
complaining about it because if people weren’t happy with the things
that I thought of as basic, which is the stuff that everyone imitated,
right? I needed to get those basic things. To even get to the place
where I could think about the block references and all these other
things, which are still rough.
Therefore, a problem people don’t know they have. Like, nobody’s
trying to, like, reinvent prose. I’m trying to reinvent prose. I don’t
think prose works for large scale collaborative problem solving. Like,
essays do not work. I mean, they can work. They’re the best that we
have right now. I saw you shaking your head, Mark, right? Like, and in
fact, there’s a whole other thing which is like being able to go from
Convincing rhetoric that is storytelling where like the author is taking
you on a journey with them into the structure, you kind of may wanna
have both. You wanna have a sequentially ordered narrative that is being
presented, but then if you’re trying to analyze the logic of it, or
like debug the program, you might wanna have a more sort of structured
graphical representation of it for the analysis of, like, where are the
weak points in the narrative, but.
00:46:41 - Speaker 2: I find it very interesting, you know, your vision
for where you want to be longer term, which is really about collective
intelligence more than individual intelligence, but you can’t bootstrap
into getting everyone to use something at the same time.
00:46:54 - Speaker 1: Also, your past and future selves are totally
different people, right? The past is a foreign country.
So the other reason that I started with the single player tool is that I
didn’t have to convince anybody else to use it to be able to iterate on
it.
Other authors were other people, and myself across time was other
people.
And so it is an easier and still extremely difficult problem to solve
the problem of organizing your own thoughts over time as your thoughts
change, being able to go back and actually reexamine them.
These are actually more related than people think.
Like, people don’t realize how many selves they have, right? I actually
think the idea that you are just one self is kind of, you have up so
many different sub-agents running around. Like, one day you think this,
if you’re hungry, you think that, if you’re tired, you think that,
like, how do you actually bring your all your internal family systems
is, yeah, I don’t know if you guys have ever gotten into that kind of
stuff, but like, You’re many, you are many. Yeah.
00:47:48 - Speaker 2: Contain multitudes, absolutely. Certainly, writing
is a technology for not only communicating with others, but also
communicating with your past and future self is a powerful piece of it.
00:47:58 - Speaker 1: And present self, I don’t know what I think until
I write it sometime.
00:48:01 - Speaker 2: Um, so yeah, the externalizing the thought, the
conversation with the page, you see what’s there, and that becomes a
loop that’s different from the kind of thinking inside the brain.
00:48:11 - Speaker 1: Or to tie back to Mark saying, you know, when you
were talking about you got into programming so you could build those
multi-agent models for doing economic simulations, like, that’s the
kind of stuff I want people to be able to do in Rome, right? It’s like,
Rome is the database of all their notes, all their thinking, right? And
so if they want to just start playing with stuff, they shouldn’t have
to worry about setting up a web server or web page or whatever, like,
it’s like, OK, they write some JavaScript and suddenly they’re
embedding a little.
And that’s one of the cool things with closures, like, closure
interpreter inside Rome, and a JavaScript interpreter inside Rome. So,
hopefully someday, the future mark is thinking through his economics
thoughts with little simulations inside the notes, and like, they’re
part of his scaffolding of his own thinking, and he’s gonna be able to
go back and not just read his old thoughts, but like, play with the
simulations that he was writing.
00:49:02 - Speaker 2: That’s super interesting and definitely the
programmability built into the tool that again, programmers, editors
have had since forever, but bringing that to something that’s more for
other kinds of knowledge workers or other kinds of, obviously power
users, but people who are more working in the realm of ideas, not
necessarily code. Putting those two things together, I think was a
surprising but important innovation.
00:49:25 - Speaker 1: I’ll say one word here too, which is that someone
asked. What are we working on? What have we been working on? One thing
that is still an open research problem that I’ve seen no one else even
thinking about is the idea of that there are higher order functions for
regular thinking, right? If you do weird San Francisco hippie like
intentional relation stuff with other groups of people, like, you get
used to these kind of patterns of questions, right? For instance, I ran
a learning cult, cause I was trying to do it with work flowy and Excel,
like, I was trying to build a sort of peer to peer research group with,
you know, just friends and folks that I met when I was in the Bay Area.
I was trying to figure out the minimum thing I would need to build for
Rome to build a decentralized research group, right? And so I was, in
order to stress test, I was like, how close could I get to the ideal
social and like information structure without building anything with
like off the shelf tools. And I used Workflow, which was a tree-based
outliner, and I used Google Sheets. And I would do stuff like, I would
ask people, what are the like 7 best books you’ve read in your life.
OK, for each book, like, what were the 3 big ideas? For each of those
big ideas, how did that impact you? For each of those ideas, can you
find two quotes from the book? Can you go back and do these things? And
even just a simple thing like a for each function, right? Even just like
being able to separate out, I want to ask. Questions, and then I wanna
take those answers, and I wanna map new questions onto the answers onto
these things, and I want to create a data structure out of this. Map,
filter and reduce, like, we don’t have higher order functions for these
basic qualitative kinds of, you know, personal interactions. And so one
of the main things that I’ve been working on with R is trying to build
a programming system for And maybe for like teachers or like group
facilitators or something like that. For me, this was a very important
practice for being an autodidact was I had a methodology for like
deconstructing books, for like, managing my attention, and it was always
really inconvenient to have to go back and forth between like what step
am I on right now? And then I couldn’t just like set up, this is the
sequence of events that I wanna do. And just like look at each thing one
at a time, and separate out the sort of cognitive scaffolding from the
actual thinking. And so, I’m trying to build a sort of higher order
programming language for creating cognitive scaffolds for guiding your
own thinking, for like, you know, intentional, either reflection or
investigation, or like that kind of stuff like that, because I think
there’s a whole domain of programming that is about programming your
mind. You being the programmer of your mind and being able to be like,
let me think about the thinking I want to be doing, and let me create
prompts for myself, where like, I’m the evaluator. So, that is what
Rome really is. It’s about building a programming language for human
cognition, which could be the individual or multiplayer.
00:52:23 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. Join us on Discord to discuss this episode with me, Mark, and
our community. The links in the show notes, and you can follow us on
Twitter at @museapphq. Connor, I’m so glad that you’re helping us think
big thoughts about how we can just be better at collective intelligence
cause it’s pretty clear that that’s a place that humanity can get a
lot better. And thanks for coming on the show.
00:52:47 - Speaker 1: Thanks so much.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: It’s very common that you want 3 views. You want
a view which is temporal, what is the team working on this week? You
want a view that’s personal, what is Mark thinking about right now?
What does he want to have at hand. And then there’s a view which is
subject base. What is the design of our sync system? And what link cards
allow you to do is to have any given thing appear in each of those.
00:00:27 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product.
It’s about the small team and the big ideas behind it. I’m Adam
Wiggins here with my colleague Mark McGrenigan. Hey, Adam. So a little
bit of news from the new product side.
We recently released a feature called Linked Cards to everyone and been
quite surprised and happy with how useful these have proven to be. It
was in beta through the Backstage Pass with our pro members for a few
months, but yeah, it just seems so valuable to everyone.
We are really happy to launch it broadly, and that’s especially true
within the Muse for teams. Context.
So we’ll talk about that. We’ll talk about the future and our
approach, and we’ll talk about some of these use cases that we’ve
seen.
But of course, we have to start with something philosophical and
historical to set the context. So our topic today is linking. So, what
comes to mind for you, Mark, when you hear that word?
00:01:26 - Speaker 1: That’s quite a rich set of precedents there.
Perhaps the very first thing one thinks of is web links. Although, as we
discussed, I don’t think that’s actually the closest case of prior
art. Also comes to mind things like citations, but really dialing into
linked cards, things like file system sim links, wiki backlinks, the
knowledge graphs that you see in emerging knowledge management tools,
things like that.
00:01:51 - Speaker 2: To me it’s an interesting topic because it is
such a simple idea. It almost seems too simple. It’s just one place or
work or piece of information is referencing another place or work or
piece of information, but I think there is something very powerful
emerges from that.
I would say a lot of the current. Sort of tools for thought, excitement
or revolution, if you want to call it that, and the productivity
software space is largely built on the foundation of linking as a core
idea, as well as the web, obviously, hypertext and hyperlinks, even
though there’s much more to the web than just the link, that actually
is a very foundational piece.
And so it’s quite surprising what emerges from that.
Yeah, you mentioned citations, be fun maybe to talk about that a little
bit more towards the end, but I think that was sort of the original
thing is, I don’t know, 1000 years ago, someone is writing a book and
they want to reference another book or I don’t know, maybe it’s not
even a book, maybe it’s a scroll and you just name it, right? You say
the item titled this, maybe you give the author and when it was written
as a way to kind of Hopefully unambiguously refer to this thing, and
that implies that there is this greater canon of human knowledge, which
indeed at some point we started to have a, if not unified, perhaps today
you can say it’s a fairly unified sort of sphere of books and videos
and newspaper articles and all that sort of thing.
But yeah, you go back in history and just a simple idea of referencing
another work that is not the one that you’re currently reading implies
the larger sphere and indeed then you start to build this network and
these connections and this implication of shared knowledge. So again,
this one simple idea, just this simple reference of naming another thing
from that comes this sort of giant hive mind of all human knowledge.
00:03:46 - Speaker 1: Yeah, and I think it’s really important because,
as we’ve said many times on the podcast, knowledge is built up in this
web. It’s not a linear process. It’s this very messy, organic,
incremental growth of knowledge that happens over time, and so things
like citations help reify that.
00:04:07 - Speaker 2: And Another piece of prior art that’s more on the
technical side is file systems. I think this was probably my first
exposure to thinking about links as a first class item.
So in Unix you have what’s called the sim link or symbolic link.
There’s also hard links, but we don’t necessarily need to get into
those.
On Windows you have something that are called shortcuts, which I think a
lot of people are familiar with just because there’s a little kind of
icon that indicates this isn’t the original item, this is a pointer to
that item, and you often get that on your desktop, for example.
The application doesn’t live on your desktop, you just have a, well, a
shortcut to it there for convenience.
And Mac also has something called aliases, although of course it’s also
Unix under the hood, so you can use some links, but regardless, this
idea of linking things together where a file lives in one place in the
hierarchical file system or on your hard drive, but you can reference it
from another, that was my first real exposure to both the power of it,
but also sometimes can be confusing, or you can tie yourself in knots
with, you know, circular references or whatever.
00:05:08 - Speaker 1: I think file systems are interesting because they
illustrate, there’s actually several very different types of things
that can be happening here.
So let me enumerate them quickly.
You can have a duplicate to make a copy of a file. You could potentially
recognize that those copies are the same objects by content addressing.
You can have a transparent pointer.
This would be like aiming or an alias where The second object is of a
different type. It has a little arrow thing. It’s not a regular icon,
but when you, for example, double click on it, it opens the underlying
pointed to objects. So it’s mostly but not entirely behaving like the
original thing.
And then you can have something that behaves exactly like the original
thing.
If you have the recent tab in your finder, for example, the items there
are the same thing as when you go to the original location in your file
system, it’s kind of a different view. So when we talk about linking,
we’re often referring to one or more of these things.
I think it’s useful to remember that there’s several quite different
types of objects in play.
And maybe one more that we could add is the actual file system path.
This would be comparable to the HTTPS URL on the web. Some people call
that a link, some people would say the actual underlying hyperlink thing
where you click the link, but these are all different objects and they
have different properties.
00:06:22 - Speaker 2: Yeah, I would call the path, but I would think of
the generic term for that is the address. And within a single computer
system you usually have this unified way to reference a file, which is
the path.
Actually I would argue citations are probably a place where you know
there’s all these standards, right? You use the Chicago Manual of style
or the this or that. Basically how you do a citation is actually
there’s a lot of specific formats and if you mess it up, you get in
trouble, especially if you’re trying to do a scientific work.
But coming to the web, one of the things that is so miraculous there is
this totally unified address format. So there’s links and links have
appeared in a lot of different computer software, but maybe what makes
the World Wide Web and HTML work so well is that you have the URL, the
Uniform Resource locator. And that that single address is unique in the
world, or at least in the internet, which is, you know, our digital
world, and that now that that is deployed so universally both in desktop
browser software, but also in APIs and so on, that if you just have that
one string and you don’t need to understand how it works or how to
break the pieces apart or even certainly how the packets are routed, you
just know that your web request is going to go to where you need it to.
Which is again quite a miraculous, not just technical achievement or
design achievement, but really kind of human coordination achievement
that we’ve managed to deploy that so widely.
And probably as long as we’re talking about the history here worth just
giving a quick nod to, you know, links and well, the term hyperlink was
coined by Ted Nelson, who’s quite good at these rather bombastic terms.
Tranclusion is another one of his that we use with some frequency. But
then also, for example, Doug Engelbart’s NLS included a version of
linking Hypercard. A lot of that is about how cards link together. And
so there’s the web, I think rolls together or is the best manifestation
of all of those ideas, but the history of it in computing goes back to
really to almost the beginning.
Now another invention from the 1990s, sort of piggybacking on the web is
the wiki, right? And I think Ward Cunningham was the inventor of the
first of these, and it certainly builds on that foundation of the web.
But one thing it brought that’s unique is what I usually call the
double bracket notations, the idea that you can put in brackets a
keyword, a very human readable keyword that is a link to someplace else
and not the entire internet. It’s not a complete Globally addressable
address, but it more makes that keyword into something we’re saying
there’s a reference for this in this system in this wiki. And one of
the interesting things about that, certainly there’s the accessibility
that it’s very easy to use, but I think one of the fallouts of that or
one of the implications is that you can link something that doesn’t
exist yet. Which is an interesting idea, right? And I’ve certainly used
this in Team wikis, for example, where there’s a project page I know I
need to write because we’re talking about doing this project, but I
haven’t done it yet, but I want to reference that. I can put that in
brackets, and sometimes that link shows up in a different color or
something like that. Wikipedia has a version of this as well, where you
basically can link something that’s not there, you click on it and then
it tells you this isn’t here yet. Would you like to add some content,
but it’s a nice way to stub something out.
00:09:39 - Speaker 1: And there’s another very important behavior
difference.
So if we go back to the example of the file system, if you want to refer
to a file several times, the first operation is very different.
You gotta create the file and write the contents, and then subsequent
operations create a different type of object, a similar link or an alias
or something. So there’s a huge discontinuity and Typically on a file
system, it’s not as native to go the other direction to get the
so-called backlinks, and one of those backlinks that you’re basically
missing it because there’s nothing pointing back to the place where you
did the original operation from. Whereas on a wiki, for example, when
you make a double bracket, that’s the same the first time, the second
time, the 3rd time you do it. And furthermore, when you go to the
backlink page for whatever was in double brackets, those backlinks are
all symmetric. I believe, like there’s not special treatment for the
first double bracket that you happen to have made mentioning some noun
that is the current title of the page. Those properties are subtle, but
as we discuss the muse approach to link cards, I think that will become
important.
00:10:41 - Speaker 2: Yeah, I think backlinks were present for a long
time and things like Wikipedia and other places, but I really think the
modern, call it linking back linking trend really came with what are now
usually called knowledge graphs.
So Rome kicked that whole thing off. The notion it always had linking,
but they added backlinks, I think somewhat in reaction to the overnight
success of Rome, then you have all these kind of Rome descended products
like obsidian, LogSeek, even classic kind of text editor note tools like
I writer or get.
Into that now and I think what you referenced there with the backlink
and links being symmetric, I think that’s why they call them the
knowledge graph is this idea that the nodes are the notes and those
notes might be something about a person or a thing or a concept or an
event or a meeting or whatever, but the edges, those links in the graph
represent relationships and actually seeing those relationships and
again treating them as symmetric as you said. Of course, it gives you
these cool visualizations where you see all the time you’ve invested in
your notes and how they all fit together, or if you look at more like a
larger scale Wiki like Wikipedia, you can see the relationship, the
clustering of different knowledge, but sometimes the relationship
between things is as important as the things themselves.
00:11:59 - Speaker 1: Yeah, and I have to be honest, I’ve been
surprised by how taken folks are with linking and back linking and
explicit knowledge graphs. I certainly think that they’re useful in
their own ways, but there’s something about them that people get really
excited about.
00:12:15 - Speaker 2: Indeed, well, I certainly think of this trend
scene, community.
Around tools for thought in the last 3 or 4 years. Obviously I’m very
happy. I’m sometimes surprised as well. I certainly find it very
powerful. I’m also glad people get excited about it and in general, I
think that’s part of what’s been great about this tools for thought,
scene or community or just trend that we’ve had in the last few years,
which is people getting excited about productivity software and excited
about their knowledge tools.
Now, sometimes I do think it gets a little bit narrowly focused on
Linking and back linking knowledge graphs and lots of different
variations on that, but I think that was a really good starting place.
It’s a good example of showing how just managing our information in
different ways can unlock new possibilities for individuals, for groups,
for humanity as a whole, and obviously computing, the dynamic medium of
computing has so much untapped potential that we are really just at the
beginning of it, so I Certainly hope that the excitement over knowledge
graphs is just a door opener to a wider world of tools for thought,
productivity, and in general just continuing to explore what’s possible
in the world of knowledge and information systems. Well, I guess that
naturally brings us to the muse approach and this linked cards feature,
and it came up a lot in the very early days of our product because we
were part of the tools for Though scene from the beginning and people
naturally think of the linking back linking knowledge graph stuff that
that’s kind of like a foundational feature and obviously we are more
focused on the visual and spatial elements, the free form sketching,
bringing together your research materials to ruminate upon. But we
always knew, hey, yeah, linking is super useful for all the reasons we
just described, and we always knew we would want to bring it to the
product at some point, but we wouldn’t necessarily, it wouldn’t be
right to just straight up copy the double bracket notation or something
like that. I mean, you know, maybe that could fit in, but we wanted
something that would be more in tune with how we do things, the visual
and spatial approach, and that’s what brought us to linked cards.
00:14:22 - Speaker 1: Yeah, and Muse, we think there’s a lot of value
to each piece of content having a place, and for a long time, we said
that a piece of content should have exactly one place, but we found that
to be a little bit too limiting.
So often you would have a board, for example, that you wanted to be able
to access that made sense in the context of Say your daily work in the
context of a longer term project and that presented a conundrum, what do
you do in use to be able to access, say that board from both locations.
Now, one thing you could do is the file system type approach where you
have some canonical board in one place and you have a second class
pointer board in another case, but that felt unsatisfying to us, like we
didn’t want this two-tier system and this notion of like a pointer
board versus a regular board.
So this is where we come to linked cards. And the idea with linked cards
is that it’s a set of cards, 2 or more, that point to the same content
symmetrically. I think actually back some years ago now, we had this
notion of like portals or mirrors, which I think are not as suitable for
a public product, but I think described the notion of the sort of two
views from two different locations into the same.
Underlying content. So you can access the content from either place A or
B, but when you zoom in, for example, you’re at the same place. And
there’s also a sort of back leaking tight mechanism where you can from
any of these linked card instances, say, where else is this card
present, and you can seamlessly navigate to those other locations to
move across different contexts.
And then to close the loop here, if for some reason you were to delete
one instance of two of these linked cards, you gracefully go back to the
base case of a simple piece of content that’s in exactly one location.
00:16:13 - Speaker 2: Yeah, you mentioned the concept of location quite
a bit there, and I think that ends up being key to it. This is something
that’s different compared to a, for example, a notes tool that does not
have the spatial component.
The spatial component is so core to muse and what Muse is offering you
as a thinking tool where something is located that’s in a little pile
of some things over here versus this other pile over here might be
really important for your thinking process or how you’re making sense
of a set of materials.
So naturally then where something lives, if it’s going to live in two
places or more than two places, you need to have some concept of that,
and key to this ends up being this little icon that basically goes in
the upper left corner that lets you see all the places that it is, and
then really importantly switch between them quickly. So you can use it
as kind of a portal to essentially teleport to this other location in
your larger knowledge sphere, and this proves to be a really helpful and
useful concept that preserves the spatialness and preserves that sense
of place that we think is so important, but kind of breaks the 1 to 1
relationship and gets you a lot more of the ability to build a more
complex knowledge graph.
00:17:29 - Speaker 1: Yeah, and by the way, there’s a pretty slick
animation that happens when you change locations like this that I think
really nicely reflects what we’re trying to get after, which is when it
works correctly, it’s hard to get it to work correctly in all cases
because of the literal dimensionality of the canvas and the objects, but
the content that is linked in multiple locations sort of stays in the
same place, and the background around it shifts. So you are appearing in
this new location, but you’re still anchored by this content that was
meant to appear in multiple locations. I think that’s pretty slick.
00:17:59 - Speaker 2: Yeah, that was a really clever creation by Leonard
and Julia because so much of how you are oriented is based around this
navigation in and out of boards and panning around them and so we were
worried or even in the early prototypes, I think when you saw you could
just jump, it’s disorienting. So this transition animation serves more
than the purpose of just being fun to look at or something like that,
but actually helps you keep that sense of being oriented.
00:18:30 - Speaker 1: And now that I think about it, I’m actually not
sure how common it is to have this backlink style navigation available
without going into the object in question. Do you know what I mean? So
like on a wiki, you can click on a link and then click on backlinks, and
from there, get to a sibling page. But I don’t know how common it is to
be able to go directly to a sibling page from the, say, link.
00:18:53 - Speaker 2: Hm, cause yeah, typically you’re viewing the
board sort of from the outside, you’re seeing its thumbnail
essentially, and then you’re deciding to go to this other place where
it is located.
Yeah, that’s true. This is why we needed to do our own take on this is
that when you’re in that spatial setting, it’s just a different thing
than when you’re in lists of documents that aren’t organized or you
just don’t have a visual metaphor for it that works in that same way.
Speaking of that, animation in general, the transition of being able to
quickly jump between locations, this was actually quite a technical
challenge to implement.
So I thought it might be fun if we could get our colleague Yullia on the
phone here briefly and see if she could tell us a little bit about how
that worked.
00:19:41 - Speaker 3: Hello.
00:19:43 - Speaker 2: Hey, Julia, congratulations on shipping linked
cards.
00:19:47 - Speaker 3: Oh, thanks, yeah, it’s been a long time coming. I
guess it’s been sitting there in the backstage pass for a while, but
it’s nice that we can finally give it to the whole world. And yeah, it
looks like you are pretty excited about it.
00:19:59 - Speaker 2: Yeah, well, I feel like it was one of our smoother
betas in the sense that we actually went pretty quickly from, I think it
was in the backstage pass for I don’t know, 3 or 4 months, something
like that, but it basically worked really great from the start. We
needed to make a couple small tweaks, but nothing too dramatic. And
yeah, people were finding it really useful, so it just sort of made
sense to bring it into production.
But Mark and I were just talking about the location switching and the
transition animation as well as the challenges there, and I seem to
remember in that first implementation there was a lot of technical
challenges.
I was hoping you could give us a little insight into that.
00:20:35 - Speaker 3: Yeah, there’s quite a few. I mean, I guess we
could start with the transition since we were just talking about that,
but um there’s actually quite a bit to uncover. So let’s see if we get
to all of that.
But yeah, one of the things that made this a bit challenging to
implement is that of course, as being news, we had kind of high stakes
for the UX and how we wanted it to feel. And Leonard, our designer, had
initially prototyped something where you could just super quickly like
hit a button and cycle through all of the different places where this
link card existed. That ended up not being quite feasible, but we still
wanted to make it pretty fast so that you can just go and select a
different location and you’re basically there quite instantly.
But yeah, depending on how large these boards are that these cards live
in, rendering a big board can actually take quite a bit of time and
there’s some tricks that we do when you transition from one board to
the next, kind of just in a normal zoom in, that makes that feel
instantaneous, even though it’s actually not quite instantaneous.
So for every board that you have, we store a snapshot. They’re
basically PNGs that render your entire board content into an image. And
those are actually what you see in the little cards that represent your
boards, and when you zoom in, we actually load a higher resolution
version of that image kind of seamlessly as the transition happens so
that when the transition finishes and you’re zoomed in for the first.
Depending on how big the board is, 0.5 a second to maybe 1 2nd or 2,
you’re actually still looking at the image of the board, and then as
everything gets loaded in the background, we switch out that image for
the actual board view that where you can interact with the cards and
everything.
So this usually happens behind the scenes and ideally the user never
actually notices it.
So for these transitions for the link cards, we basically had to do a
similar trick. So when you first select from the drop down menu on the
Mac or I think on the iPad, it’s a context menu as well, tapping on
this button. When you first select a different location, we actually
immediately load in the high resolution snapshot of that board. And we
transform it to match exactly the position of the card in the board that
you came from. So the idea is basically the card stays in the same place
and then the content around it just changes. And yeah, to do that really
fast we have to. Load in the JPEG, put the card on top of that image,
then in the background, we actually load the entire board hierarchy and
the real views, and then once that’s done, we remove the image and
you’re actually in that board and you can start interacting with the
content.
00:23:27 - Speaker 2: And it feels very quick to me, but certainly your
brain needs a moment to process the new scene that you’re looking at
before you’re gonna go do anything to it. And so that sort of like, is
part of the stage magic there is use that moment of the human is
reorienting themselves to the new location to do the work of rendering
the interactive view.
00:23:49 - Speaker 3: Yeah, and most of the time it works actually quite
nicely. Of course, since the card in the new location that you’re going
to might actually be in a completely different position.
Let’s say you come from a board where the card is on the very top left,
kind of the first thing that you see in the board. And then you go to a
board where it’s all the way at the bottom right, like maybe several
screen widths away.
Then there’s also the thing that we sometimes see where it kind of
jumps a little bit because in the destination board it’s actually so
close to the edge that you can’t scroll it into the place where the car
was in the previous view. Maybe that’s getting a little bit too much
into the details.
00:24:30 - Speaker 2: And I also remember really well we were in the
midst of implementing this that a lot of other operations in the
application that seemed unrelated to linked cards got really slow as a
result, once we had this in our internal test flight builds and it just
so we were at our team summit last August when we were working on this,
and I remember you and Adam Wulf furiously drawing complex graphs and
talking through the problem on the kitchen table in the house we were
staying in. Can you tell me about what that was all about?
00:25:01 - Speaker 3: Yeah, so this was kind of a surprising turn that
the whole thing took. We initially thought seems like a pretty
straightforward feature. We just basically create a new card that points
to the same document and then we display this little kind of link icon
in the top left corner of the card to indicate that this is a link card,
so there’s other cards that represent the same document.
And the initial implementation of all of this was actually really fast,
like kind of done in a few days, and then we noticed the app got really
slow and it wasn’t initially clear why that was, but as we looked into
it further, it actually turned out that the kind of database queries
that had to happen to actually determine whether a card is a linked card
or not a linked card. Ended up being extremely expensive.
So the first thing that needs to happen is that we check for a given
document how many cards actually point to this document. So that’s kind
of one database create. That’s relatively simple. And if we have more
than one card, you would think, OK, surely this is a linked card, so we
should show this little icon. But it’s actually not enough to just look
at the number of cards that point to this documents because some of
these cards might actually not be in your corpus at all. They might be
unreachable from the home board.
And this is because when you delete something from your corpus, let’s
say you delete a board that has a bunch of subcontent. We don’t
actually go in and prune every single subboard and every single document
that is contained in the subtree that is that board. We just set the
board that you deleted to delete it and it disappears from your view
hierarchy and as far as the app is concerned, you can’t actually
navigate to it anymore from anywhere.
But there might be somewhere in there a board or a card that points to
that same board that you have also linked somewhere else, and that card
is technically not deleted. It just happens to not be reachable from the
home board. So we actually also for each card that points to the board
we need to determine. Is this actually in the user’s graph? Is this
card something that is in quotation mark deleted, so the user can’t
actually reach it from their home board? Or is it actually in the corpus
and we should include it in the list of linked cards for this particular
document? And that actually ended up being an extremely expensive
operation because you kind of have to tee up multiple queries to find
the parent board of the parent board of the parent port.
And if you eventually end up at the root of the corpus, then yes, this
card is reachable. But doing this kind of on every render just because
you want to display a board with a couple of cards in it and determine
whether or not they should get a little icon in the corner. Just ended
up really slowing down the app, just kind of rendering a pretty basic
board structure started becoming very slow and affecting all kinds of
parts in the app.
So what we ended up doing was something that we had thought about on and
off anyway because it was kind of a data structure that would help us in
all kinds of different scenarios and working on the app and kind of
working with the user’s content.
We ended up creating a graph structure that actually maps out the
user’s content in a very easily queriable way. So in this case we’re
only storing the IDs of all the documents and their relationships to
each other. So if a card displays a board, that’s basically one node of
the graph, and then we build out the graph this way. And every time
something changes, every time you add a card or delete a card or you
move a card around, we update that graph immediately. So then every time
we want to render something, we don’t need to do all of these database
queries again. We just need to go to this graph and say give me all the
cards that point to this document or give me all the parents of this
cards, and from there on it then got very fast.
Now of course you have kind of an additional. Data structure kind of
model around the user data that you constantly have to maintain. So
that’s of course leaves new surface area for bugs or kind of forgetting
to update this as the code grows, but it’s so far had been really
helpful and has made the app a lot faster in that regard again.
00:29:27 - Speaker 1: Yeah, and this is all in memory, right?
00:29:29 - Speaker 3: Yes, exactly. This gets built once when you launch
the app and then just continuously updated.
00:29:35 - Speaker 1: Yeah, and we have a similar thing on the server
and it’s definitely true that it’s a little bit troublesome to get all
the details right of maintaining basically a second view over all the
data, but at least it’s just a memory, so you get to blow it away each
time the app starts, it makes it much more forgiving in my experience,
versus something on disk, which is a whole another level of ordeal.
00:29:55 - Speaker 3: Yeah, that’s true.
00:29:56 - Speaker 2: And I think that’s always a trade-off with
database or persistence layers is that the more indexes you have that
slice the data in different ways you want to view it, the faster it will
be, but now all those indexes have to be maintained, and if they get
messed up, you need to regenerate them or something like that, and
that’s the fine art of data persistence.
00:30:17 - Speaker 3: Yeah, exactly.
00:30:19 - Speaker 2: As Mark and I were talking about earlier, one
thing that introducing linked cards to Muse did was to break this strict
1 to 1. Cars are only in one place. Everything is a very direct
hierarchy, and that changed things in the user interface.
Certainly, for example, that you can navigate into a board from several
different locations, and that comes up, I think, in both the individual
user just, you know, when you pinch out, you expect to go back to the
board you were on.
Originally, but it also comes up even in our multiplayer world in terms
of like where we’re going to show an avatar floating over a board
relative to the path they took to get into it. Curious to know what
kinds of challenges there’s been in adapting all of that.
00:31:04 - Speaker 3: Yeah, this is something that we kind of noticed in
hindsight when certain things in the app that used to be really easy,
like navigate to a particular document based on his ID now suddenly had
kind of unclear implications because that document isn’t just in one
place anymore.
So if for example, I have a deep link that points to a specific document
and I open news. Clicking on that deep link, where do I actually go?
Like, of course I go to the document, but what’s the context? Is it the
linked card on my home board or is it the one that’s 5 levels deeply
nested in one of the subboards or is it one that’s, you know, linked
from somewhere else? So we can’t actually describe a position in your
corpus anymore just by a particular document or board ID.
This also became evident when Something that seems really trivial, like
you close the app and then you open it up again, and we have to like
launch it afresh and ideally bring you to the place that you’ve left
off because that’s probably where you want to continue working.
Previously we just basically always stored the idea of the board where
the user was last on, and when the app launched, we opened that board
and built the view hierarchy underneath it, so all of the parent boards
all the way up to the root board underneath and that was it.
So now we actually have to store the entire navigation stack, including
every card, basically kind of leaving bread crumbs of where the user
went to end up on the board that they’re currently viewing.
And this all gets serialized to disk when the app quits so that when you
launch the app again, we can look at these bread crumbs and retrace the
steps to exactly where the user had come from. And we’re going to have
to do that probably with all kinds of things like deep links or like
sharing URLs for go to this sports. Well, which one do you mean? Do you
mean the one on the home board or the one? levels deep down below, so
we’re, we’re gonna have to start encoding these path information into
all kinds of things, including, I think like you said, the presence of
avatars in a board. Like if you’re in this board, you’re technically
in 5 different locations, but we don’t want to show you avatar and all
of these different locations. We want to show exactly the path you took
to get to that board.
00:33:26 - Speaker 2: Do you remember anything about detecting cycles,
like sort of putting a linked card inside itself and dealing with that
as being part of the initial technical challenge as well?
00:33:37 - Speaker 3: Yeah, so detecting cycles actually has always been
a big challenge for M and linked cards actually was a big relief for
that because now instead of having to be really careful to prevent
cycles, we can kind of allow them and embrace them. So in the pre-link
cards were, there were. A few weird edge cases, for example, when you
had two windows of muse open, so like split screen on the iPad or two
actual windows on the Mac.
And let’s say you have board A, B, C, where A is your root board and B
is the board in between and then C is deeply nested, and you have board
A in the one window and have board B open in the other window. And then
you pick up board B, the card for board B in the window of board A, and
then drag it into the other window and drop it into board B. Then you
just drop B into B. So now B is contained in itself and you’ve
effectively detached it from the view hierarchy. This is now also
something that we can nicely detect with the corpus graph.
And previously we had to really make sure to prevent these accidental
operations. So basically disallow you from dropping the card there
because that could very easily lead to not technically data loss, but
data loss in the sense of you can’t get to that content anymore and we
didn’t have any UI of kind of surfacing these detached cycles. So now
when you do this instead of disallowing the operation, it’ll just drop
a linked card of itself into B. And keep card B and A, but then also put
a link card of B into B. And so now you have an endless loop of B and B,
and you could try it out. I think you could basically go indefinitely
navigate and probably at some point the app will crash because you have
put hundreds of view controllers onto the navigation stack. I’m not
actually sure what happens, but it does work well for quite some time
and I guess technically if you’re 10 levels deep into B and you’re
still on B. When you then quit and relaunch the app, we should also
build the stack 10 levels deep, although I guess in this case, the card
is actually the same, so I’m not quite sure how that would work, but
yeah, there’s definitely lots of fun little edge cases like this.
00:35:52 - Speaker 2: And I think almost always if someone does one of
those things you described, it’s an error essentially or they’re just
doing it to see what happens. So it’s not so much that we need to make
it make perfect sense, but more that just we need to not yet have the
app crash or screw up your data or get you into a state that you can’t
get out of. Yeah, exactly. Well, my head’s spinning a little bit with
all the complexities here. I’m glad I get to just be a user and not
need to load all of that into my brain. So thanks for taking us through
it, and we’ll let you get back to your ex code.
00:36:26 - Speaker 3: Yeah, my pleasure. Have a good one.
00:36:29 - Speaker 2: Bye bye. Bye.
Few, I actually didn’t fully know what was there. I had a sense of it
because we actually have one of our earliest boards that we have in our
Muse for Teams shared workspace is one of the kind of scribblings that
Wulf and Julia did together when they were thinking through this whole,
what she was calling the corpus graph, this kind of relationship index.
So, I had a sense there was something there, but I didn’t know quite
how deep that rabbit hole went.
Now another area to talk about is the design considerations that went
into this.
I think Yullia mentioned some of those in the sense of what happens when
you do particular edge cases in the sense of the user’s mental model
about this. I think you also mentioned briefly in passing the idea of
having cards which were more of a reference, more like that file system
shortcut. was one of our first prototypes.
So if I remember correctly, they implemented prototypes of what we ended
up with, which is this kind of each card is a mirror of each other and
essentially any change you make to one happens to the other and there is
no kind of source or original, but they had also mocked up something
where there was a link card that was very similar to our web links,
which of course are a reference, not a mirror.
But that had a little richer of a preview, and we basically tried that
out, and that actually felt pretty good.
We liked that in a lot of ways, but somehow I think the mirror felt just
more of the kind of embodied or physical or spatial style that fits with
Muse. And actually that fed into the the name of it as well.
When I was chatting with Leonard about this, he mentioned or he pointed
out that we call them linked cards linked ending with an ED, not link
cards, right? Link cards, which we have for web links, for example,
where you can put deep links to other iOS apps. It’s really clear that
that thing is not in use. It’s someplace else.
This is a reference that will take you there. We’ll open it in a
browser, that sort of thing. But the idea with the linked cards, which
are usually boards, but can also be a PDF or a video or something else,
they really are like the same thing and they are linked together and the
content will always stay the same.
00:38:38 - Speaker 1: Yeah, and if you think about it from first
principles, I think it makes sense that we ended up here, because when
you’re dealing with external content, you don’t really have a choice.
It has to be a link without an ED object, because it’s not something
that you control. But when it’s internal, why not? You have full
control over this, including the magical ability to make it appear in
multiple locations.
00:38:58 - Speaker 2: Another design consideration here is what you do
with things that are untitled. So this is something we consider a key
feature. It was part of the Muse white paper that we published from the
research lab a few years back, which is the ability to create something
and not have to give it a name. Which I’m a fan of generally, I don’t
necessarily want to have to name a project before I’ve decided what’s
gonna go into it, but usually, of course, you end up with something
that’s called Untitled, and then you end up with untitled parentheses
234, and so forth. That’s a really common thing you see in, I don’t
know, classic word processors or whatever. But in Muse, you can put all
kinds of items.
In fact, most of your items don’t have names necessarily. You may only
title a board or an image or something later, once you kind of know what
it is or what it’s about.
But of course, what that also means, the location switcher is showing
you a text representation, so then we need to show you basically, this
is an untitled board in the case, or an untitled card of some kind. I
think that’s not fully solved. I think Leonard is still kind of chewing
on that a little bit in the best way to manage that, but certainly as we
get into more and more things that are not pure spatial and visual,
things like search, for example, that’s gonna come up more and more. So
I think this untitled boards design or untitled cards design challenge.
That’s a key feature of the app. We want to keep that, that’s
desirable, but at the same time, how do we handle that in a more of a
text or list kind of setting like this.
00:40:26 - Speaker 1: Yeah, we’ll continue to noodle on that. I think
in practice it hasn’t been too bad because the places that you tend to
put linked cards are relatively important and therefore tend to have
titles. It has been my experience. So, more often than not, you have a
suitable title in place, but yeah, I agree that as we get into more
non-spatial content types, as I’ve been calling them, it’s gonna
become more important.
00:40:47 - Speaker 2: Yeah, well, maybe that brings us nicely to just
talking about linked cards in practice, the use cases we’ve seen from
users and customers as well as what we’ve experienced ourselves on the
team, and definitely going into it, we didn’t necessarily know what all
the use cases would be or what the best use cases would be, which is
sort of a funny thing. I think you even raised the flag on this a little
bit, which is you want to have a lot of clarity usually about what your
use cases are before developing a feature. And we had a list of them,
but it was sort of more driven by where we started the podcast, which
was linking is just really useful, and probably if we add it, things
will emerge that we wouldn’t have even predicted necessarily and I
think that’s kind of how it panned out.
Many and most of the use cases that we had in mind initially did come to
light, but basically immediately once we released this in beta and then
we had some lively discussion on our Discord and the beta’s channel
where folks were trying this out and sharing what they were using it
for, and we were almost immediately surprised by some of the interesting
stuff that folks were doing with it.
So maybe we could start with how we are using it personally or on the
team. How have you found linked cards that fit into your new workflow,
or have they?
00:42:01 - Speaker 1: Yeah, for me a little bit.
So in both my personal corpus and on the team’s corpus, I’ve seen us
use them for what I might call workflow purposes, where you have a
board, it’s usually a board that you find that you want to access from
a few different contexts.
It might be, for example, you have a technical design for something that
you want. On the one hand, in the context of your larger technical board
and also in the context of your weekly planning, say, that sort of thing
I find happens pretty frequently, and I do some stuff like that for
personal projects where I want it on some maybe more temporal board
versus more subject matter board, and it’s helpful to see the thing in
both places.
I also use it a little bit as a sort of bookmark feature where there’s
some topic that you know is referenced in a few different places in your
corpus, and you can create a board for that notion and then make a
linked instance of that board in those handful of other places and you
have a sort of bookmark access portal network, you know, underground
tunnels to your different boards.
Now, what I don’t use it for is the really high cardinality. Super
dense reified web that you sometimes see with knowledge graph tools
where like, each page has 10 links and you’re trying to form this
really explicit graph of concepts. I’ve argued that I mean, I think
there’s something to that, but the in fact network of concepts is so
massively dense. It’s like the branching factor is thousands or more
that I think you’re kind of fooling yourself if you think you’re gonna
fully reify that in the tool. There’s still some uses to it, right, but
in my mind, that stuff happens in my head, and where I find myself using
the links is more for workflow purposes where I know I’m gonna want to
traverse these networks of boards and non-hierarchical ways.
00:43:52 - Speaker 2: Yeah, well, I was surprised how useful it turned
out to be. I guess I didn’t feel quite the burning desire for it, but
again, we heard this just so often from users and customers and a few
folks on our team also were really, really driven about it.
And of course this reflects, yeah, a very flexible and general purpose
tool like Muse. People use it in lots of different ways. Everyone has
their own approach, not everyone uses every feature and so forth, but I
was surprised how much I did find myself using it. Certainly a good bit
in my personal muse, but where I’ve really been surprised about how
useful it is is the team setting, and I guess I shouldn’t be so
surprised from this because, you know, using something like Notion or
even Google Docs back in the day when that was when we used more of our
internal memos and project documentation. Yes, it’s just really, really
useful. You’re going to build up this network collection of projects
and concepts and processes and so forth, and it’s just very good to be
able to reference them to each other. A really simple version of that
that comes up basically every week in our planning is we’re having a
discussion about, OK, these 3 people are working on this task this week,
and they’re doing this and this and this, and by the way, they had
previously had. You know, a whole design sketching section and talked
through exactly what they’re going to do next. Here’s the board for
that. And so kind of in the call, what will happen is someone will go
and grab a linked card for that and drop it in the planning document
right alongside. There’s the explicit list of tasks and assignments of
what we’re doing for the week, but here’s the reference to and as
these projects get more complex, particularly as our team is growing and
so forth, sometimes it’s, you have 3 lines. Of tasks for the team that
just describe what they’re doing for the week, but then you double
click or you pinch to navigate into that subboard and you see this huge
world of things whether it’s technical or design or whatever it is, and
you either get a glimpse of it or maybe you think, OK, I’m going to
sort of make a note to go review this later because I think it touches
on my work or maybe you just go, Oh man, I’m glad those people are
working on that and not me because it’s a whole huge world and I’m not
going to load the context into my brain. But just that ability to just
drop that reference there, and very casually, I think it’s just a
really nice way to offer the depth if you want it, but you don’t
necessarily need to go into it right there in the meeting.
00:46:10 - Speaker 1: Right. Another way to describe this might be
different views into the same data.
So I think it’s very common that you want 3 views. You want a view
which is temporal, what is the team working on this week? You want a
view that’s personal, what is Mark thinking about right now? What does
he want to have at hand.
And then there’s a view which is subject base. What is the design of
our sync system? And what link cards allow you to do is to have any
given thing, boards say appear. And each of those.
And really importantly from you, as you alluded to this, it’s all
symmetric because often the way this stuff happens in practice is
someone is off noodling in their own world and, you know, how to do
graph indexing for linked cards as he was describing. And it would
really be a shame if You either disallowed or made it look weird if that
was to get promoted into the weekly work and then into the sort of
canonical subject matter board for sync or the client and what have
you.
But with linked cards, these things get promoted and they’re really
peers among each other, so it’s very natural for stuff to Flow in
organically versus you can imagine a world where there are 2 class links
and then the subject board, for example, is this weird mix of like
boards versus second class link boards, it just be kind of weird.
Whereas here you get this very nice minor link icon to indicate that
this board appears in other places, but otherwise it’s all symmetrical.
00:47:34 - Speaker 2: Another thing I’ve noticed is that the number of
links, the number of other locations, I guess number of linked cards
that is in that Droptown serves as a sort of measure of importance.
So as one example here, you wrote a description of the roadmap
essentially for multiplayer or multiplayer features in terms of
technical capabilities we needed to build as well as some of the user
facing stuff, and you wrote that pretty early in our process, and
that’s been An important reference point for a lot of project planning
and design work and so on. And so now there’s a pretty good list of
stuff there and almost an interesting parallel there with, I think
citation count in scientific papers where you can measure the influence
of a paper by how often it’s cited some.
Similar for boards. Our most important boards tend to get referenced a
lot, and notably, I don’t think you necessarily know ahead of time
which you’re going to turn out to be that, and maybe that’s to your
point about the canonical location, which is something that might start
in a board that I call Adam’s weird ideas in November. And it turns out
that one of them is useful or interesting enough that it keeps coming up
and gets referenced a lot, and the fact that it started life there
isn’t important for its longer influence that it’s going to have on
what our team is up to.
00:48:56 - Speaker 1: And speaking of personal workspaces and then
promoting content into team spaces, I think the elegant transition from
single instance to multiple linked instances is going to work really
well because, so right now in our use for teams, basically everything is
visible to everyone.
Each of us has our own little workspace that’s carved out and some of
it a little like pseudos screens over it so people don’t, I don’t
know, annoy us too much or, you know, look in before stuff is ready. But
ultimately, if you, Adam, have something in your personal workspace and
then link to it from the team’s weekly planning board, for example,
that backlink is gonna appear to everyone in the current views for Teams
space.
But you can imagine a world where the backlink calculation is done per
user. So, in a world of more granular sharing that we’ll have in the
future, it could be that when you do that promotion and you go to the
weekly team planning board, you see the backlink to your personal
space.
But when I go, I don’t see that backlink. And in fact, it might just
look like a regular board to me because that’s the only place that
appears for me. And then perhaps if I want to link it from my scratch
board, then I see the two ends. Says it’s on the weekly planning board
and it’s on my personal space. So that’s, I think an important example
of how the linkedness is a property that emerges of how many times a
given document is visible to you. And right now that’s all the same
because we’re all sharing the same team space, but eventually it’ll be
more granular.
00:50:21 - Speaker 2: Right, right now you got your personal muse where
it is by definition only visible to you, and then you’ve got teamwork
spaces, which in our current data are essentially everyone on the team
can see everything.
But in the future world, we have in mind is one of much more granular
sharing, as you said, the ability to share individual boards, as well as
even within a team space having a private office, private workspace
where you can get stuff ready, even though it is intended to be in that
bucket of There’s something I’m doing for work or for this particular
team or project, and it may be something that has some kind of a privacy
screen over it, but you can relatively seamlessly move it into the
shared space when you are ready to work on it.
So yeah, it definitely opens up or it fits really cleanly into that
paradigm.
Well, maybe as a place to end, we’re gonna reference Ted Nelson again,
I mentioned earlier, he invented the term for hyperlinks, but he also
invented this term transclusion, and the muse take on transclusion so
far is that you can grab what we call an excerpt from a PDF or an image,
or even a frame from a video, and have a source link and indeed a little
portal that takes you back to that place.
But in some ways, linked cards have some of the same transclusion
quality to them, and indeed, I think something we would like to see in
the future is essentially a called a linked section or a linked portion
of a board or other card, and actually at that point, then you start to
see it as a sort of transclusion, right, a portal to that source,
something you could potentially not only see but potentially change, you
can obviously navigate into it. And the fact that it is this one
specific subset, I think is also part of the potentially usefulness.
Now, what the interface for that would look like, I think would be quite
a design challenge, but I think the value of that would be fairly
obvious and hopefully would make Ted Nelson proud.
00:52:24 - Speaker 1: Yeah, I think that would be very powerful. I’ve
definitely found myself wanting something like that and have received
several support requests looking for that kind of capability.
And just reasoning by analogy, this is super useful on the web. You have
vanilla URL links, and then you have so-called anchor links where you
have the URL, the pound sign, and then some anchor tag, which typically
corresponds to some heading or some other section of the web page. And
when you click on that link, it takes you to the web page and scrolls
right to the point. And sometimes with jobs you can even make it
highlight the particular thing that you scrolled right to.
Super valuable. And importantly with web links, the former is sort of a
special instance of the latter. It’s like you’re basically link into
the whole thing, and I kind of wonder if we can make that same thing
work in Muse where instead of having separate linked card and excerpt
slash transclusion features, there’s sort of a continuum. So you can
think of a linked card as you have underlying content. You make an
excerpt, but the excerpt is like the whole thing. If the window is the
size of the entire document. And there’s another thing you can do,
which is make an excerpt where the window is smaller than the entire
document. But you can see how those are on a continuum, and then things
like the back linking, for example, would be unified. I don’t know if
that’s gonna work out. We need to think about it more, but I think
that’d be pretty powerful if we can get to work. I also think both
linked cards and excerpts could be relevant for maybe you call them
computed views or derived views. The example that I constantly go to is
search. So there’s one way to do search, which is like search is a
totally separate thing with a totally separate interface, just kind of
its own world. And then you click on links and it brings you back into
the main app. The vision that I have for search is more like there’s
some content type that you’re programmatically. Computing. So in the
current muse, you can imagine you type some search terms and it computes
a board that has a bunch of linked boards on it, which correspond to
your search results, which would be a little bit weird, but you can
imagine if a muse eventually has a non-spatial content type, basically a
set type, which is more comparable to like a Maciner, and there. When
you do a search, you compute a set of results in order to set maybe or a
list and you present that in the same way that if you want to make a
manual list, it would be, you know, very comparable how the set is
built. And then furthermore, you can imagine. If you’re searching for
text, for example, and it’s searching within PDF, it actually computes
an excerpt object so that you can, you know, see where in the PDF the
result is popping up and when you click on the excerpt in the same way
that you animate a manually create excerpt, it goes to the PDF source.
So I think these are pretty cool building blocks for eventual computed
types like search results.
00:54:59 - Speaker 2: Yeah, I know something I always find myself
wanting with search, generally, Google does a version of this, but I’m
also thinking of Unix text search tools like Grap has a command line
option to essentially give yourself a couple lines of context around the
search term, maybe log search tools like Splunk.
And when they don’t have that, you’re struggling to see, OK, like I
found the error I searched for, but I really want to know what happened
in the few lines before it. That context is really important, but
sometimes there’s not even a way to get to that.
So the idea of the excerpt where you can easily see the context or even
go completely to the source, is something that’s generally very
powerful in computing.
Well, then maybe I’ll just encourage our listeners, if you haven’t
given linked cards a try yet, to go check that out and use. You can
basically use the right click contexts menu on your Mac or the context
menu on the iPad and make yourself a little linked card and fool around
and see if you like the metaphor we landed on there and tell us if you
have any feedback, and we can wrap it there.
Thanks everyone for listening. Join us on Discord to discuss the episode
with me, Mark, and our community. I’ll put the link in the show notes.
You can also follow us on Twitter at mAppHQ. And Mark, I think the 1st
50 or so years of linking and computing have been pretty good. I’m
looking forward to seeing what the future holds.
00:56:28 - Speaker 1: Great I.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: There are a lot of other projects that have very
similar models to this dynamic land database, but it definitely pushed
me to think a lot more in terms of having state exposed by default,
ambiently, and the value of being able to make little quick debugging
tools that can piggyback on this global state. That was a super
influential model on the way I think about programming and the way I
think about debugging, this idea of being able to make really
lightweight tools or jigs to help myself as I work.
00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac. This podcast isn’t about used product, it’s
about the small team and the big ideas behind it. I’m Adam Wiggins here
with my colleague Mark McCrannigan. Hey, Adam. We’re joined today by
Omar Rizwan.
00:00:49 - Speaker 1: Hi.
00:00:50 - Speaker 2: And Omar, I understand you have a collection of
metro cards.
00:00:56 - Speaker 1: Yeah, I mean, I was just looking at this shelf
above my desk, and it turns out I have this giant, basically the only
thing on the shelf is this giant plastic pencil case that looks like a
giant metro card. And so, I think a lot of people do this, but I’ve
just started this habit of just filling it every time I get a metro card
or transit card from wherever I go. So now there’s like, I don’t know,
there’s a lot, there’s a lot of cards in here. It’s pretty full.
00:01:20 - Speaker 2: So let’s see, what must you have? It’s certainly
a Bay Area transit card, and maybe, I don’t know, an Oyster card from
London, or what, uh, you know, does this reflect kind of like a travel
log of your places you’ve been?
00:01:32 - Speaker 1: Yeah, in a way, it’s kind of a nice, I guess we
can connect it to one of the themes, which is that there’s like kind of
an object for each place. There’s an octopus card from Hong Kong,
there’s a card from Paris. It’s sort of like, instead of entries
written down in a book, it’s like I have these like little cards that I
can kind of pull out and look at.
00:01:50 - Speaker 2: Nice, and then it’s sort of like, I like the idea
of keeping it around because it implies you’re gonna be back, right,
that you’re a globe trotting, you know, person of the world, and you
never know when you’re gonna need to whip out your Hong Kong transit
card.
00:02:06 - Speaker 1: I think there’s also something like comical about
the like very large metro card, like very large version of anything.
It’s like, uh, you know, a prank we used to do in like middle schools.
If people left their laptop unattended, we would just go and make the
mouse pointer really big and like not do anything else and just like.
00:02:25 - Speaker 2: And you are an independent researcher with a very
diverse set of interests, lots of things that overlap with the niche
interests that Mark and I, and I think a lot of the listeners have,
including end user computing and embodied computing, file systems,
vintage computing, and so forth. But why don’t you give us a little bit
of a summary of some of the stuff you’ve worked on over the years and
where your interests in the computing world lie.
00:02:51 - Speaker 1: Yeah, I mean, so my background is mostly, you
know, in programming, you know, I learned to program very early, and I
sort of got interested in, like, new ways to interact with computers.
Like, when I was a teenager, there was all this stuff on, like, building
your own multi-touch table, and then I kind of got involved with Brett
Victor’s work at Dynamicland, but also did a bunch of other different
projects, kind of in that space, and just in general, I’ve always been
interested in like, Different ways to interact with computing, both like
future looking and also historical, like, what are their operating
systems that people have done, what are other interfaces that people
have done. And so, that’s my background.
00:03:28 - Speaker 2: And I feel like just looking down your portfolio
the right way to describe your list of of projects, your research
provocations, perhaps they’re quite varied, but they seem to have in
many cases a sense of less of a like, here’s a, I don’t know, a
library you’re gonna use or an application you’re gonna use and more
of a Almost like an art project element of like, let me make you think a
little bit here.
For example, one kind of near the top, at least at the moment is hijack
your feed, and if I’m not mistaken, this was one you did together with
uh Jason Yuan, is that right? Yeah, yeah, who we’ve had on the podcast
before as well. And yeah, I feel like that’s as much uh asking
questions about social media feeds and the place they fill in our life
and how we can like take a little more control of our computing world.
But then you’ve got, for example, TabFS which mounts the open tabs in
your browsers as files and lets you basically do, you know, The kinds of
shell programmatic things that you can do with normal files, but with
sort of your web browsing kind of history or current open topics. So
I’m not sure how much, I mean, maybe I don’t know, Tabafest is in
quote unquote production and you have people using it for serious
things, but as I look down this list, I feel like they’re more of a,
yeah, again, it’s just kind of like art project to make you think and
question assumptions about the status quo in computing. Is that a
correct conclusion to draw?
00:04:52 - Speaker 1: Yeah, I think that is a lot of them. And that’s
also, I think a lot of what I do, you know, on Twitter or in my writing,
or whatever, is sort of try to provoke people or come up with these
really striking images. And I think, like, I’m often very skeptical
when people sort of try to articulate this like philosophy of like what
computing should be or, you know, explicit tenets of these are the
things we want. I’m much more on the side of like, we should have a few
very striking, like, concrete examples of like, things you might want to
do, or like, interactions that are possible, and then those will kind of
drive people in a certain direction.
00:05:28 - Speaker 2: I think the project of yours that was the first
one I ever came across was Screenotate, which is essentially it seems to
combine a couple of your interests here, including Provenance and OCR,
but essentially it’s a screenshotting tool that makes it very easy to
grab the text out. Now I’m not sure how much the latest changes in
MacOS and iOS where there’s some of that built into the OS. Well, maybe
we’re even inspired by what you did there, but that is well’s product.
You can download it, you can pay for it, presumably you’ve been
maintaining it for a while, so it’s not pure research in the sense of,
and I use it also, you know, all
00:06:04 - Speaker 1: the time, that’s key, like I’ve probably taken
30 or I’ve probably taken like 40,000 screenshots in it, so, wow.
Yeah, and I think there is, with a lot of the projects you’ve
mentioned, there’s also this theme, and this gets at this idea of folk
practices a little bit. There’s this theme of like, this is very vague,
but like, connecting different universes in unexpected ways, like this
idea of like, there’s your browser and your file system, and you jam
them together, or there’s this like social media interface, and
there’s this idea of tasks or productivity, and you jam those together,
or even the dynamic land stuff, I think, has a little bit of this, like,
there’s the objects in your computer and there’s the objects in the
real world. You kind of try to Combine those in some way where you can
use operations that you are familiar with on one and apply them to the
other. And I think that also something that connects really well with
people, because you’re sort of familiar with both sides, and so you
kind of immediately see the combination of them, and you’re like, oh,
this is really cool or really interesting, or like, I can quickly
imagine how it would apply, you know, to my life in some useful way.
00:07:06 - Speaker 2: So you have the anchor points of the two things
that you’re familiar with, and the novelty or the provocation, or the
picture of what could be comes from thinking about how those two would
combine.
Yeah. So our topic today is folk practices, and this is a term Mark and
I use quite a bit here on the podcast and even on our team as we talk
about ways to look what people do naturally with existing tools or
existing features.
In, you know, a product that we or others are building and then sort of
extract from that what they’re trying to do and in many cases you can
even shape a product or a set of features or an operating system to
embrace those folk practices.
And I think Screen notate, the project we just mentioned, is one good
example of that because the idea that like People sometimes complained,
screenshots full of text, this is so annoying.
Why not have the core text, you’re spending way more data to represent
it, you can’t reflow it or do other things you can do with the text,
and to some extent, Folk practices, I think is a saying like, look,
screenshots of texts are really here to stay, and there’s a bunch of
reasons why that might be, but just empirically, this is a thing people
do and they do a lot. And so maybe we should learn from that and find
out how to kind of roll with it. Like, if you can’t beat them, join
them kind of thing, rather than kind of, you know, basically complain
that you’re not doing it right.
00:08:32 - Speaker 1: Right, or at the very least, you might not join
them, but at least you should look at it and be like, OK, why do people
do this, rather than lecturing people about, you know, you should do
this other thing instead.
00:08:43 - Speaker 2: We were at a conference together recently and you
did a little demo to the group, and this is called Screen Matcher. Can
you tell us about, yep, that one?
00:08:52 - Speaker 1: Yeah, so this is a project that I’ve been working
on a little bit this year, and basically the idea is it’s this Daemon,
it’s this app that sort of runs in the background of your Mac
continuously, and it’s constantly watching your screen, so like the
screen on your computer.
And so this screen matcher, you can teach it to look for patterns on
your screen. It’s like you’re taking a screenshot, like, you drag out
a region of your screen, and then you kind of feed that torematcher, and
it’ll look for whatever you took a screenshot of from then on.
The example I usually give is like, you know, in the corner of every
window on your Mac, there’s these traffic lights to like close,
minimize, and maximize. And so you can teach Screen Maer to look for
that pattern, it’ll find it wherever it sees it. And then you can draw
on top of it. So, effectively what that means is you can add like a 4th
or 5th button to every window on your computer.
But, you know, there’s a lot of other things you can do once you have
this kind of continuous screen matching mechanic.
Like, you can kind of just like add buttons or draw or scribble on
anything on your machine, and have these like automatic behaviors.
So the other example I usually give is like, with the screen matcher,
you can build like an alarm clock without traditional programming,
because what you do is you’d be like, OK. I want to wake up at 7 a.m.
tomorrow. So you’d set the clock of your computer into the future.
You’d be like, pretend it’s 7 a.m. tomorrow, and then you tell Screen
Matcher, hey, when you see this pattern in the top right corner of the
screen, when you see it say 7 a.m. I want you to play a sound and wake
me up. So there’s this idea of like, you can extend the functionality
of your computer in a very natural way, and there’s this idea that you
can do things you might normally take like programming or scripting or
whatever, just by pointing at your screen.
00:10:25 - Speaker 2: It reminds me a bit, especially that example you
gave there of an if this then that or a ZAPA or something like that,
which do have this element of automation without real programming, but
those really rely on APIs.
So you need to have an API integration that that means that the vendor,
the creator of whatever the thing is, in this case would be the clock or
the operating system or whatever needs to supply an API that you can
consume through some probably fairly complicated procedure.
And I feel like a hypothesis or a concept that’s embedded in this
project and maybe some of your others is to sort of say, well, look,
it’s nice to have APIs on things, but realistically the output from
computers is pixels on a screen. So if we want to give some kind of end
user programming capability, basic automation, rather than trying to
browbeat program creators into creating an API, just sort of give up,
and maybe give up isn’t the right way to put it, embrace that folk
practice or embrace that reality that That GUI interface exists and by
the way, computer vision is really good now, and so something like
recognizing the widgets in the corner of your window or a clock value is
actually relatively straightforward, so therefore maybe that should or
could be the sort of an everyday API.
00:11:45 - Speaker 1: Yeah, I think that’s right, that there’s this,
instead of this closed world of whatever is available via API you have
this open world, much like when you take a screenshot, you know, you can
take a screenshot not just of things that are selectable text, but if
anything on your screen.
Similarly here, you know, you can automate based on anything on your
screen, not just things that happen to be an API.
But I think there’s also kind of like an interaction argument for this,
which is that Even if you have all the APIs available from the end user
point of view, it’s like, OK, I want to do this automation. I guess I
have to like read the, like, dictionary of APIs and like figure out what
the right APIs are, or if they’re even available, I have to figure out
like what kind of input and output they take, and that it’s always felt
to me like very disconnected from the actual experience of using the
computer. Like, you know, if I want to make an alarm clock, why can’t I
like point at the actual clock on my screen, instead of figuring out
that there’s a clock API that’s like based on the same source as the
clock on the screen. Like, it feels like you should be able to point at
the actual things that you’re already familiar with, instead of having
some like API dictionary that’s completely separate, that feels like
this like skeleton of the app.
00:12:50 - Speaker 3: Yeah, I really like it. And Omar, so the idea with
Screen Matcher that you can both sort of scrape the screen for input,
but then also do, I guess you would call output of typing things and
clicking things, moving the mouse around.
00:13:03 - Speaker 1: I think so. You know, the current prototype,
basically what you can do is you can just add but so you like can search
for a pattern and then you can be like, every time you see this pattern,
I want you to draw these extra scribbles next to it, and then when I
click one of these scribbles, I want you to run a bash command.
I see, I see, but I think it’s very easy to imagine being able to have
other responses. To seeing things on the screen, whether that’s like
playing a sound. I mean, someone proposed to me that you should have all
the effects happen by drawing stuff on the screen and then Screen
Matcher would like match those things and do the effect directly.
Uh, I don’t I don’t know if that makes sense, but it has like a very
nice, like, kind of aesthetic elegance to it.
00:13:40 - Speaker 3: Yeah, I also kind of like the baseline of anything
that you can do as a human, whether that’s things you can see or inputs
you can do with the keyboard or the mouse, you can script. Yeah, that
seems like a reasonable invariant. Yeah. And as far as that’s a floor
on automation, so no matter how hard the programmers try to deny you the
ability to have agency over your own environment, you can’t take away
my eyes and my hands. And therefore, if I can control those things, you
know, basically I have scriptability of them.
00:14:08 - Speaker 1: Right, right. You could imagine if you wanted
something that could deal with keyboard shortcuts, like, let’s say
every time I hit like control 9, I want the computer to send an email or
something.
You can imagine a plug-in that actually maps your keyboard into like a
larger like screen space. So you have your actual screen, but you can
imagine you have a bigger virtual screen and you like map your keyboard
into it, and there’s like a virtual keyboard on the virtual screen that
lights up when you have keys. And so you can sort of imagine mapping any
sensor or actuator if you go the other way. Into screen space, and that
would kind of make this like an entire programming system in a sense,
cause you’d be able to address any kind of IO which, again, I don’t
know if that’s useful, but it’s kind of like a cute idea, and I think
this is like an interesting programming model, and it is in some ways a
lot clearer than traditional programming, because like, if it goes
wrong, you’re like, OK, it didn’t match the right things, like,
that’s why it didn’t work.
00:14:57 - Speaker 2: Well, well, almost by definition, everything is
what you are seeing, the computer is also seeing, and then what you are
responding to that with by yeah, drawing something else or playing a
sound or something like that.
I mean, that’s one of the things that makes programming so incredibly
difficult. It’s obviously very abstract, but the connection between the
set of symbols and the thing that’s actually gonna happen as a result
of it is so disconnected, and that’s what makes kind of professional
programming, professional software engineering.
Particularly really complex systems, you just have to model so much of
what the computer is doing in your mind, that’s almost the hard part of
it as opposed to just expressing concepts and symbols, for example,
right?
00:15:37 - Speaker 1: And here, I think you sort of by default, get this
ambient awareness of what the computer is doing. Which I think is
something that’s also true of dynamically to some extent. I mean, I
think that’s something that’s true of a lot of interesting programming
systems, is like, you don’t have to go in and like, inspect what the
computer is doing because your program didn’t work. You just like, look
at the screen and you’re like, oh, that’s why that didn’t work, even
though it may be a little wasteful from a sort of traditional
programming point of view to be running all this state through the
screen.
00:16:03 - Speaker 2: Mark, your earlier point about they can’t take
away your eyes and your hands reminded me of another dimension of folk
practice, which is what’s usually referred to as the analog hole when
you’re talking about DRM digital rights management, where, OK, we’re
going to give you this music, you can download this music and listen to
it, but you can’t copy it, for example, but in the end, you can always
basically just like take a recording device and hold it up to the
speaker, and that’s the analog hole that no matter what you do with the
computer.
And screenshots are, I think, an even more pervasive and useful version
of that. It actually happened to me just the other day. I think someone
sent me a PDF maybe a financial document. I can’t remember what, but I
need to copy paste something small out of it and I don’t know, the PDF
you or said something like, oh, you have to have the master password to
unlock the whatever to copy paste, and I’m like, cool, man. And then,
you know, took a screenshot and immediately use the OCR to just like
copy paste it out, right? There’s a version of this in the Kindle app
and whatever, and they’re just working so hard at it, but like in the
end, it’s like I’m looking at the words on my screen. In a really
worst case scenario, I could just manually type them out if I wanted to.
And so it feels like a lack of acknowledgement of the reality of I’m
looking at it and part of what my computer can do is manipulate images.
So how in the world are you really going to stop me or anyone else? It
feels like a weird denial of reality. Now talking about the debugging
visibility that you might get from, for example, an on-screen keyboard
or just the fact that all of these things are flowing in the, let’s say
the concept that’s suggested by this project that you sort of see
everything and that visibility is going to make it more approachable and
more comprehensible to sort of non-professional software engineers. I
noticed one of the notes or prompts you put into our little shared notes
document here was whether visual programming was overrated. I feel like
those are related. The appeal of visual programming is if you can see
everything, it becomes more approachable and more comprehensible, but it
seems like you have some feelings on that subject.
00:18:09 - Speaker 1: You know, I think there is a notion of visual
programming, which is like, you put together blocks on the screen, or
like boxes and wires, and I think this like, Uh, especially blocks, I
think that like doesn’t really have that much to do with the kind of
visual programming that’s suggested by the screen matcher, because in
the Srematcher, the visual things are actually the data, you know,
you’re like, these are the patterns that the system is matching, and
then these are the things I want you to produce. Whereas in block-based
visual programming, the visual elements are like actually like if
statements and for loops and stuff like that.
It’s actually like not normal programming.
But I think they’re actually fairly different in the model of what is
visual.
And I think it’s a very easy thing to fall into that like, there’s a
lot of people who don’t like normal programming with a text editor and
a compiler and whatever, but that doesn’t mean that they all have the
same conception of what programming. It should be. Like I think there
are actually many different ideas that are not necessarily compatible,
and I think you know, visual programming is maybe too broad, at least
it’s maybe too broad a category to be useful, and we should talk more
specifically about what kind of visual representation you want for
programs. And I think the other criticisms of visual programming that I
think about a lot are One, it’s just like really annoying to manipulate
visual elements on your screen with a mouse, compared to manipulating
text for the keyboard. Like, you have this sort of bottleneck of like,
oh, I have to drag things one at a time, I have to select things from a
toolbox. I think this is part of the appeal of the dynamic lens stuff is
it’s much, much easier to manipulate things on a table than it is to
manipulate individual items on your screen. That might be better on an
iPad or a multi-touch display. I think there’s like a lot of
interesting work that somebody could do there, but I think that is
actually a very serious problem, and I still don’t see it talked about
enough, that it’s just like the ergonomics of visual programming are
not that great compared to the ergonomics of text, on like current
computing hardware.
00:20:03 - Speaker 3: Yeah, and I think the typical use of quote unquote
visual programming tends to conflate a few different things. One is
using the visual medium for high bandwidth feedback, which I actually
think is really good. I’ll return to that.
But another is it kind of forces programs to be structurally correct
often, you know, the visual programming blocks, like you can only put
the circle inside the circle and stuff like that. But then it also
necessarily enforces the sort of 2D program, which is very limiting,
usually catastrophically so.
So I think some of those things are better than others, and also you can
get some of them without going to a, what we typically think of as a
full blown visual programming.
So for example, the idea of things being visible, taking advantage of
the enormous bandwidth that you get over the visual channel, I think
that’s great. I use it all the time and you can use it without using
one of these typical visual programming language and actually leads me
to a couple of my favorite folk practices. I know, a very simple one,
but a super common one is just print after debugging, you know, it’s
like dumping a huge amount of visual information from your regular
program.
Another is this idea of shelves or scratch space and the related idea of
lightweight copies. So an extremely common pattern that we see with
great professionals is they’re working on something like a design for a
web page. And they want to explore a branch, you know, a variant, and
the proper programming way to do that is like get branch and so on. What
people actually do is they select it all and they copy it and they paste
it, you know, next to it, and they go fiddle with that. And if it works
well, they delete the old thing and if it doesn’t work, they delete the
new thing, and they’re off. That’s a very lightweight branching, but
critically, you have both of them visible and it’s not like implicit in
this really weird like get graph thing.
00:21:44 - Speaker 1: Right, right, like that’s another bottleneck
cause like your git raff can only point at one thing at a time, and
it’s hard to do comparisons unless you go into like comparison mode.
Yeah, I mean, like, with your example of like high bandwidth visual
information, I’m constantly like, oh, I wish I could print off like a
graph this graph of the state of my program.
And there are people on Twitter who do this regularly and have a good
practice. But like, is that visual programming? I mean, it’s not like
normal, you know, text programming with like string print off, but it’s
also not block-based programming.
Like, it’s somewhere in the middle, and I think there are a lot of
things that are in that space of like, you can’t do it on a
traditional. You know, stack where you’re running in a terminal, run
your compiler, running your program, but it’s also not like you threw
all that stuff out and you have this sort of your dragging and dropping
workflow.
00:22:32 - Speaker 2: Wulf and Julia to the engineers on our team
recently were debugging a pretty complex, essentially there’s an
in-memory graph structure that’s used and things were getting
complicated once we added linked cards within the app and they ended up
dumping it out, I think, to JSON and then there’s a tool I say it’s
called Mermaid maybe that does a nice diagram visualization, and it was
actually like fun to look at. It was really interesting.
Usually when you watch someone debugging, it’s like picking through
these like monospace font logs and scrolling through the IDE but these
visualizations were compelling and easier to understand, maybe for
someone who is not someone deep in the problem space, like they were.
So, yeah, there’s a lot to be said for that.
I will point listeners to the classic Meta Muse episode with Maggie
Appleton, where we talked about visual programming, and she makes this
exact point that that is a label that is very broad. It covers a lot of
things.
There’s some good taxonomies, but her basic concept for it, an argument
for visual programming is a thing to explore more is you start From hey,
how do we make the whole program out of, I don’t know, boxing and
arrows, but you start from how do we just make more visual parts of
programs we already have today, things like the DOM Inspector and the
browser is one possible example, and you could imagine those as we get
better and better at visualizing both running programs and at rest
programs and code paths and Get branches and whatever else that there’s
an accumulation of making a more accessible programming environment
because it’s more visible and more tangible and can be interpreted in
different ways other than just reading the code, it’s sort of mentally
running it in your head and that for her is kind of the argument for
visual programming.
00:24:14 - Speaker 3: This is making me wonder if there’s powerful
primitives we could add to help with.
Leveraging the visual channel for debugging.
So, OK, it seems obvious, but actually having the standard of a single
stream of MySpace font logs is huge. We can’t take that for granted,
but we would be totally down in the water if we didn’t have that as
programmers, right? But you can also imagine some other really simple
basic printers that could help a lot. So one would be in the browser
environment, you get this thing where if you log like JSON or a
JavaScript object. It sort of gives you a nice rendering of it where it
automatically expands or contracts when you click it and it kind of
pretty prints the stuff and it highlights it with different colors.
00:24:55 - Speaker 1: Right, it doesn’t flood your console if it’s a
giant object, like things like that that make it, yeah.
00:25:00 - Speaker 3: And often in web-based environments, there’s this
pattern of like, you basically use a web page or a piece of the web page
as the debugging panel, and you have HTML and CSS and I almost wonder if
that could be almost like a standard, like in the same way that you have
the log output, you have a little HTML page output and it has to be like
HTML and CSS, but then you could write your own little debugging panels
with like heat maps and graphs and stuff like that. I don’t know.
00:25:26 - Speaker 1: Yeah, I mean, I’ve played with things like, you
can actually console log like a bitmap image, and so you can do these
really twisted things where you like render something and then like,
console log it out, and even that, you know, can be very useful
depending on what domain you’re working with.
Like, if you have some domain object that’s like you have like a graph
or a map or whatever, and you want to see that or like compare different
instances of it, if you like log a bunch of sequence, that can be very,
very useful, I think.
I would also say, and I think this gets at the point you’re making
also, that I think another probably unheralded issue with this whole
space of visual programming, visual debugging, it’s just it’s just
like very, very hard engineering. It’s like you have to reinvent a lot
of stuff that you get for free if you’re using normal text, if you want
to do visual stuff, you have to invent your own editors, you have to
invent your own consoles, you have to come up with interactions that
work, you have to make sure they can post correctly, it’s like quite
hard.
00:26:20 - Speaker 3: Yeah, and it feels like there could be a little
bit of an easier layer there. One example I’ll give is, I’ve often
wanted to have terminal output that was in the, what’s it called, in
cursive style. That means that instead of each line coming one after the
other and scrolling, sort of replaces the screen as if you’re using a
command line program. But oh my goodness, that’s a whole ordeal in a
lot of languages. Like you’re looking at these weird libraries and
you’re admitting these like crazy control characters and it’s a whole
mess. It feels like it could be a lot easier.
00:26:46 - Speaker 1: Yeah, and I think about that. I thought about that
specific example before too, where I think the nature of terminal output
where you’re like logging one line at a time, it’s like, if you have a
program like a game engine or like a web browser or something that’s
live, that’s interactive. And your console logging, like, you just end
up with this flood of console locks, right? Like, a lot of the time, the
logging model you actually want is to see this live view of whatever the
variables in the system are, and then they just like update immediately,
rather than this sort of log that just like will spill out because
you’re running at 30 frames per second, or 60 frames per second, or
whatever. And I think the terminal makes it really hard, like, you have
to do a lot of extra work to get to that point, just cause the model is
not really compatible with interactive programs.
00:27:27 - Speaker 2: One term we’ve touched on here a couple of times
and I think is known to the audience of the podcast here’s end user
programming, but Omar would be very curious to hear what does that mean
to you or what’s interesting about that space. So I think the audience
here has heard Mark and I and our take on it, but I’m guessing you have
a different perspective.
00:27:46 - Speaker 1: Yeah, it’s funny cause I was kind of asking this
question on Twitter a few months ago.
There’s something I think a lot of people are very attracted to about
the idea of end user program, like, it’s almost this like charismatic
concept of like, oh if only end users could program their computers. I
mean, I think in a sense, everything end users do on the computer is end
user programming, like programming is sort of an artificial concept,
right? Like, if you’re using Microsoft Word or Microsoft Excel or
PowerPoint, like these are all kind of like subsets of programming in a
sense.
And so it’s, it’s one way to think about it is is it’s just a
question of like giving even more agency to the computer user um uh than
they have right now. I mean, I mean, I think part of my Thoughts about
this come from this dynamic land context where I think, like end user
programming was very deeply built into the system.
Like the idea is if you showed up at a dynamic land, a lot of the way in
which you use the system is by programming it.
And so, you know, if you had a community of people built around a
dynamic land, they would all know how to program in the same way that we
all know how to read and write.
Some of that comes from the technical architecture of the system, but I
think some of it would also just come from the social expectations.
Like, it’s not particularly easy to learn how to read or write, but we
do it because it’s useful to operate in the society that we live in.
And I think part of the premise of dynamic plan was that you would kind
of construct a context in which that was true for programming.
00:29:07 - Speaker 2: Maybe it would be worth taking a sidebar here to
talk about dynamic land for a minute. I know that’s a topic of interest
to a lot of our audience. I know you were there for a while. I think it
was a pretty formative experience in your career to date. Maybe you
could briefly just tell us for those that don’t know what is that and
what did you do there and what were the kind of core concepts.
00:29:26 - Speaker 1: Sure, so this was or is research lab started by
Brett Victor in Oakland, California. Basically, the idea of dynamic Lane
was to build this physical computer, where, like, there was literally a
room or an office that was the dynamic lab, and you would show up. And
you would have these pieces of paper, and each piece of paper was
basically a computer program. And the idea is you would have a computer
where you interact with the computer by manipulating real objects like
pieces of paper or eventually like cups or like handwriting or like
things that actually exist in the real world, rather than having, you
know, current computers where you have a screen or a mouse or keyboard
or a touch screen. So you have this completely different mode of
interacting with the computer.
And I think importantly, it’s, this is a programmable computer. So not
only do you use the computer. By moving real objects around, by
manipulating objects, by pointing objects at each other. You also
program the computer in this way. So you could actually do almost
everything you wanted to, you could build software systems without
needing to bring your laptop, without needing to bring your smartphone.
So it’s this completely kind of self-contained end to end system in
which you could do computational work.
00:30:34 - Speaker 2: And notably, I think everybody in the room is kind
of in the same computer, if you do have a, I don’t know, a hackathon
and everyone brings their laptop, they have their own. Discrete systems
and I guess we’re all connected to the internet or you could connect to
a shared server or something like that, but here if the room is the
computer and we’re all in it moving the elements of that computational
environment around where we’re all participating in the same computing
environment. Do I understand that correctly?
00:31:02 - Speaker 1: That’s right. So basically, well, number one,
there’s the physical element of like, you could see what other people
are doing and kind of like go over their shoulder or work with them in
that way, but there is also If you and I were around the table
programming, each programming our things, there would be shared memory
between our programs. So we could kind of insert things or respond to
things in the same sort of room scale database.
00:31:22 - Speaker 2: And what were some of your either contributions on
that project or maybe takeaways, especially now if you’re on the other
things like, what were some of the core ideas that you carried with you?
00:31:33 - Speaker 1: Yeah, I mean, I think this idea of programmability
is very, very important, and I think that’s something that’s missing
in a lot of other physical computing work, whether it’s ARVR or also
projection mapped or a lot of that kind of stuff, I think is from more
of a traditional HCI uh or game development or whatever perspective.
Like, in some ways, the dynamic line system was less advanced, you know,
in any particular respect, like, less advanced in computer vision, less
advanced programming languages, but like combined, it was a novel system
because you could program that, and because it was a platform on which
you could do lots of different physical computing stuff.
So I think the program melody is uh is very important. I think that the
sort of dynamic database architecture was really interesting and hasn’t
been written about that much. It actually has a lot of close Relatives
and I think a lot of what people are trying to do now with state
management on the web or uh with distributed systems. There are a lot of
other projects that I think have very similar models to this dynamic
land database, but it definitely pushed me to think a lot more in terms
of having state exposed by default, ambiently, kind of like in the
screen matcher, and the value of being able to make like little quick
debugging tools that can piggyback on these global state. So, you know,
if you’re writing a program in dynamic, and it’s an idiomatic program,
you would not use like variables and functions. You would kind of run
everything through this database. And so, other programs could also
respond to the state of your program just by querying the database, and
everything would react live. So that was like a super influential model
on the way I think about programming, and the way I think about
debugging this idea of being able to make really lightweight tools or
jigs to help myself as I work. And this idea of the value of like
ambient state by default.
00:33:19 - Speaker 2: Jigs and visual ambient state, both of those
concepts where I could see the thread into something like screen matcher
even though that’s on the screen, because one takeaway you could have
from the, I think it’s what we usually talk about as embodied
computing, physical objects, you’re interacting with the physical
world, you’re getting away from the glowing rectangles that
Fundamentally are the core part of the computing experience that we all
know and mostly love, and instead replacing that with something that’s
more physical and in the world and humane, as Brad Victor puts it in one
of his talks. But maybe for you, the takeaway was less the embodied
computing and more some of those things like ambient. Visualization of
state or programmability or you also have interest in the embodied
computing, I think in some of your RFID work so I don’t know, maybe
you’re just sort of following those threads in different projects.
00:34:11 - Speaker 1: Yeah, so the RFID work, we’re just getting
underway, but we’re excited about that. I mean, I think there are a lot
of directions. Like, I think this is a huge open space, and that was
also one of the takeaways is that there’s just a lot to do, and there
are a lot of problems with the dynamic client system, and there are a
lot of areas where I think we were technically constrained, where I
think there’s a lot of interesting things to do. And so I think the
RFID stuff is kind of getting at that in some ways.
00:34:36 - Speaker 3: Yeah, and that reminds me of something that I
thought was really important about Dynamic land, and this relates to the
end user programming discussion.
When people talk about end user programming, they usually focus on how
you program. Now, here’s the IDE, here’s the programming language,
here’s how you debug. What people care a lot more about is what you’re
programming.
And everyone cares about their physical environment. So that alone like
almost immediately makes dynamic land.
A huge win.
And I remember, I walked into the room and just had this sudden urge to
start programming stuff. You know, I want, you know, when this door
opens and I want when this light turns on, I want to do this and that.
It was a very natural urge. And by the way, one of the emerging end user
programming use cases like the, the smart home, automated home, again,
it’s because people care about certain things. And if you look at the
history of successful end user programming environments, Unix,
spreadsheets, SQL, MySpace, game scripting.
A, these are all environments that people have absolutely fanatical
interest about. It’s basically the center of their lives or one of the
most important things in their lives, and B, it is an enormous pain to
program these. You think about SQL, for example, like you’re going to
send a single string to your production database that, you know, who
knows what it does and It’s gonna give you back a result or like
spreadsheets where entire pillars of the financial economy are contained
in like a 500 character formula in a single cell, highly questionable,
you know, programming language design, but people get through it because
they really care about the data.
00:36:04 - Speaker 1: Yeah, I mean this is one of the lessons, and if
you talk to Maggie, this is one of the lessons in the Bonnie Nardi book
where she does like ethnography of end user programming. It it’s like,
yeah, you know, Excel, it just has these formulas which are just like
this, you know, it’s literally a text-based syntax that you type in,
like, people will learn it because they want to learn it, like, and so
this is also maybe another sense in which the visual programming is not
quite, at least it’s not like the only thing you need, where it’s
like, yeah, you can make it as easy as you want, but like people are
willing to learn, even if it’s really hard in the same way, you know,
people are willing to learn to rewrite or whatever. Like, if there’s
value in it, I think people will be willing to learn it, even if it’s
not, you know, pedagogically like the best thing ever.
00:36:42 - Speaker 3: This does to my mind imply a sort of lesson to
aspiring end user programming environment designers, which you got to
start with the environment, I think it’s so tempting to start with.
I want to design a new end user programming language or IDE. It’s just,
it’s really hard to get traction beyond like the educational and
academic use case, but if you find something or create something. That
people want to program. OK, OK, here’s an example. Minecraft. The way
you program Minecraft is like you place these little blocks around in 3D
space, and then you make your character walk around and poke them, like
what? But it’s one of the most important programming languages in the
world right now because people love that stuff, right? So you got to
create an environment that people care about. Mhm.
00:37:20 - Speaker 2: Another one I like to point to is an end user
programming success is Flash, because it did start from this kind of
animator use case. You start from these animations and then you kind of
use the dynamic medium of computing, and you go from static animations
and something that become sort of games or full programs. Omar, I
noticed you had some thoughts on software as a cultural thing, perhaps
connected to that programming environment.
00:37:47 - Speaker 1: Yeah, well, first I think something that’s
interesting about Flash and about Excel is this idea that like, it’s a
useful system, even if you don’t get into the programming part, you
know, like in Excel, you can just like write a list, and that’s a
useful thing. Like, you don’t have to write formulas to feel like
you’re being effective with Excel.
And in fact, if you do want to write formulas, it’s a relatively, you
can just do that in one cell, it’s a relatively quick ramp up, and the
same is true with Flash, right? Like. You can just use it as a drawing
app, and then you can be like, OK, maybe I want to animate a little bit.
So I think that is like an interesting common element between those.
But yeah, I mean, I was thinking about this, you know, I’m sure you all
remember when the iPhone came out and it didn’t support Flash, there
was this whole Sort of like Steve Jobs wrote the letter about how like,
yeah, about how, you know, Flash is terrible for battery and you can do
everything in it on HTML 5 anyway, and so we’re not going to support
it.
And of course, I think, you know, what is it 12 years later, it’s just
like that was completely false. Like people don’t do in HTML 5, the
stuff they were doing in Flash, and in fact there was an entire sort of
flash. Cultural ecosystem of like new grounds and mini clip and all
these other places and people making flash games and like being inspired
by the flash games other people have made, that was completely
destroyed.
Like it just does not exist anymore, kind of partly as a result of
that.
And so I was tweeting about this and some people were like, Well, how
can we make a new flash? Like, we could make an animation ID? And I
think I see the appeal of that, but I also think, even if you made
exactly the same IDE and it did exactly the same things, without that
sort of culture, community, ecosystem. Of people, you know, playing
flash games that they like and being like, I wanna make a game like
that. I think it’s hard to replicate the same thing.
Like, I think the IDE and the technology is only part of a I don’t know
if you all know Max Kraminsky on Twitter, they had a good comment that I
think you see this in a lot of programming systems, or even just like
creative systems, people, I think they were talking about twine games,
like twine is this sort of like interactive fiction creation tool, and
they were like, you know, my students are not that excited about it. And
then I show them some twine games and then they get more excited about
it because people want to feel like they’re participating in this
conversation with other people who have been working in the same medium
as them. They want to feel like there’s like a canon of things that
they can aspire to. They wanna feel like they’re placed in some kind of
culture of stuff. And so I think, you know, when you’re thinking about
making programming tools or creative tools, that’s a really important
thing to think about is like, you know, if somebody looks at this, are
they able to participate in some like medium or conversation or canon of
things that are already out there?
00:40:19 - Speaker 2: Do you think that that’s something you can design
for in creating a tool or is culture something that emerges kind of not
quite serendipitously, but it’s some mix of things going on in the
broader environment and what people want to do and to your point about
the, you can make a flash style animation authoring environment for the
web or that outputs to quote unquote HTML 5, probably people have, but
Something about the way the world is now, probably you wouldn’t get
that same kernel that then develops into that flash game culture that
was so influential.
00:40:57 - Speaker 1: I mean, I think you can fail to do it, like, I
think a lot of HTML 5 stuff has this property where, you know, like you
can output stuff, but it’s just a web page like any other web like
it’s sort of not constrained enough to constitute a medium in a way
like I think you probably want something that has a more distinctive
aesthetic. And then that kind of creates a distinct medium where people
can look at like examples in that medium.
00:41:21 - Speaker 3: Yeah, I think something that supercharges this
social propagation is being able to take some discrete artifacts and
share it with a friend or they can copy it or fork it.
So the classic example is a spreadsheet.
And critically, when you copy a spreadsheet, you get both the output and
the source code. And I think early web pages had this property where
back then, you know, when I was a kid, the HTML and JavaScript and CSS
was readable, so you could copy the source and paste it and then edit it
yourself. But then to your point about these newer programs. It’s like
this miniified compiled, you’re basically hopeless, so you can see the
output like that’s cool. We have no agency to copy and fork it
yourself, right?
00:41:59 - Speaker 1: Or I mean, with iPhone apps is another example,
it’s like, yeah, you can’t copy an iPhone, or you could make an iPhone
app, but it’s a huge process and like compared to, you know, making a
web page back in the day where you just like make a dot HTML file and
you put it online somewhere, it’s very easy to see yourself as a peer
of the other people who are making stuff.
00:42:19 - Speaker 3: I’m gonna reiterate this, I think it’s so
important. If you look at the successful end user programming
environments, they all propagate this way. We gave the example of
spreadsheets. The way SQL works in practice, it’s not like someone
reads the SQL manual and then sits down at their company database and
types out a query. It’s Mark has a query and he shares the query, and
then Adam varies the query and then Henry varies the query from that.
It’s like this like tree of life of SQL queries propagated socially.
00:42:46 - Speaker 1: Yeah, and that almost tells you that it’s
something that’s genuinely useful and that’s like immediately useful,
whereas it’s like, I feel like one of the problems with traditional
programming is you have to learn how to program, like you have to go and
like take a class or like work through a book or whatever, whereas with
spreadsheets or SQL or whatever, you know, you can just copy and modify
and like you’ll have something that works and it’s like a few lines.
Something I was thinking about with this screen matcher thing that I
think is interesting in this general area, is this idea of like trying
to unlock, like latent demand.
So, there’s a system called buttons in the early 90s, there’s like
paper about it. It’s sort of like, I think of it as a predecessor to
the screenmaer work, where they basically added this capability to this
OS where you could stick buttons on the screen and make them do things.
And that was the the only extension capability, like, it was not like a
plugin system, it was like, we just added this concept of buttons.
Maybe you could like record things into them or whatever, but it’s
really interesting reading their reports of how that affected end users
thinking, because now, once you have this concept of buttons, you can be
like, oh, I wish there was a button to do this. Like, you can, I wish
there was a button to do that, like, because before you didn’t have any
way to articulate the fact that you wanted to automate something, but
now that you have this like, actually fairly weak concept. There’s sort
of all this demand for like, oh, I wish my computer could do this, I
wish my computer to do that, that you can now talk about in terms of
buttons.
And so I think that’s one of the hopes for the screen mattress stuff is
that, you know, having this automation capability brings out some kind
of latent demand for things that people might already have been thinking
about in an undirected way, but now there’s like a sort of means or um
concrete way to talk about it.
00:44:23 - Speaker 2: as we think about the input and output of
computers and that our ability to automate things which exactly as you
said earlier, is just an extension of our agency, our general ability to
control computers, and so we want to enhance that for people hopefully
rather than reducing it or having it stay the same. And so, you know,
here we’re talking about the IO of pixels. I know another one that you
think about here is FFI is an underrated kind of problem area. Can you
tell us about that?
00:44:52 - Speaker 1: Yeah, I mean, I think partly it comes out of This
sort of frustration with like, If you get a programming language,
whether it’s Ruby or Haskell, or JavaScript or whatever, it’s usually
really easy to take in text and output text, like that’s built into
basically every programming language.
But if you want to like take in images or output images, or if you want
to like respond to multi-touch gestures, or if you want to, you know,
put up a web page that other people can browse like, basically any
actually interesting capability, you need to talk to other parts of the
computer in ways that are often not available in whatever programming
language you’re working in. And so I think in practice, You know, at
least I personally, I’m like, oh, I can’t use like most programming
languages because I actually like want to do things that are not just
like computing things and taking in text and putting out talks,
computing Fibonacci numbers.
00:45:41 - Speaker 2: Yeah, yeah, it was uh I’ve been in the position a
number of times in my life where I’ve either encourage people to learn
a program because I think they’ll find it interesting that they have
the right kind of mind for it, maybe because career potential for them.
So I’ve seen folks go through this over the years. I actually think
there was kind of a golden age, at least web-wise in the era of PHP,
HTML, and FDP, where there was this very simple mapping from files that
would save out of a text editor and those mapped pretty 1 to 1 to URLs
and the concept of query parameters would come in and you could start to
sprinkle in dynamism through the little PHP tags. A friend of mine went
through a just Of an intro, it wasn’t even a boot camp, it was more
just kind of like a little intro to programming course, and I was really
curious what they were going to show them, and it turned out they did
Python at the console, which means, of course, that they’re teaching
these folks how to like boot up the, you know, these are like most
people are using Windows, they’re loading a DOS console and installing
Python to run Python programs so they can use, you know, essentially
printF and get from the console. And this actually is a totally foreign
interface because most of the folks taking this class have never done
that kind of terminal input output, but it’s just such a good
fundamental way to get started, exactly to your point of take some text
in, do something with it, and then spit it back out compared to what you
would actually want to do is let me make an app on my phone. Or let me
make a web page, or yeah, let me like take an image and like, you know,
turn it into a cat meme, but that stuff is just like a wild tool chain
of dependencies and moving parts and who wants to even get into that,
that’s just not the place to start, even though those are the things
you would actually want to do as a person that’s dabbling in
programming.
00:47:32 - Speaker 1: Right, like, there’s this weird tension between
like, OK, what’s good pedagogy, what’s simpler, and like, what is the
actual well motivated thing? And then, I mean, this is very similar to
our discussion earlier, where it’s like, the things that are well
motivated are the things that you’re already seeing around you. Like, I
go to web pages all the time, I use apps on my phone, but those things
are so complicated that you kind of end up having to learn by doing
these things that you’ve never seen before, and like, not having any
sense of why this is interesting or important.
00:47:59 - Speaker 2: Yeah, it’s probably unreasonable to hope for, but
I’ve certainly a future I would dream of is something where the average
person with their phone would have the option to, I don’t know, long
press an app on their home screen, and one of the options down at the
bottom is like, make a copy of this and edit its functionality.
00:48:14 - Speaker 1: Right, right. And I think those are important at a
cultural level, to like communicate to people that this is the thing you
can do.
00:48:21 - Speaker 3: Yeah, this connects to a very long running theme
on the podcast around the system’s problem.
And I usually describe that problem as something like, you want to be
able to write a program in an end user accessible language that has full
capabilities into the system, and that is also fast and secure.
But because of the way that we structured our systems to date, we’ve
kind of boxed ourselves out of that. And indeed, if you want to write in
an appropriately high level and safe language, there’s almost no way to
avoid. Reduce capabilities and high latency and inability to be promoted
up into the proper application or even proper OS level. So I’ve long
advocated that a very important research project that we or someone else
should undertake is trying to squash all these layers down, so you would
have. A programming environment that has direct access to all of the
critical IO, so visual, sound, keyboard, mouse, pen, and it all comes in
in a very direct and clean way. So for example, the touch screen should
not give you just XY coordinates. It should be a full heat map of the
pressure sensor at every point on the touch screen. Yeah, but it just
comes in as a simple two-dimensional range, your programming language.
So it’s not some weird API that you need to go through. And likewise
with graphics, oh my goodness, graphics. I don’t know if you all have
tried to do. Graphics programming from scratch these days. You know, it
used to be, they had a pixel buffer and you would put an RGB value into
the pixel buffer and it would show up on your screen. Now you gotta
like, instantiate the driver and initiate the shader compiler and
compiler and give it the vectors and start the pipe. It’s incredible.
00:50:04 - Speaker 1: Yeah, I tried this and then I gave up because I
spent like 3 days straight trying to like install Vulcan or like, if you
look at the Vulcan example to draw a triangle, it’s literally like 3000
lines of C code.
00:50:15 - Speaker 3: It’s absolutely wild.
00:50:18 - Speaker 1: I had a professor in college who, his doctoral
thesis was about this concept he called exokernel, and he wrote a paper
called Exterminate All Operating System Abstractions, which you might
want to check out if you hadn’t seen it, which is basically the title
communicates the message of the paper, which is that like operating
system should, like, that sounds up my alley.
Yeah, you know, it needs to like multiplex, like, the different programs
can use the same resources, but it shouldn’t like turn your disk into
files or turn your touchpad into XY coordinates, it should just like
give you access to the underlying buffer and like do the minimum needed
to multiplex it. And then if programs want a higher level interface,
they can just like link that in, like, that should be the program’s
responsibility, and not the operating systems. Yeah.
I think it’s partly because of the kind of projects I’m interested in.
You know, a lot of my projects are about pushing some system to the
limit of its capability, like the web browser or the operating system,
even the dynamicle stuff, it’s like, you know, we had to talk to
webcams and we had to talk to projectors, you know, and like a lot of
that stuff, if you want to do it well, you have to go to a pretty low
system level. You want to like, get these buffers and not have to copy
them, all this other stuff. And so I think from that experience, my
default these days is usually like, well, I guess if I’m in a browser,
I’m gonna write in JavaScript, and if I’m on like the desktop, if I’m
in Unix, I’m gonna write and see, cause then I know I have all the
capabilities. Whereas if I write in anything else, it’s like, OK, I
have this third party like bindings, and maybe they’re not up to date
or like, maybe they don’t expose the right things, like, it’s just a
mess. The only guarantee you get is if you like, write in these super
low level languages.
00:51:46 - Speaker 3: Yeah. Now it’s also the case that if you write in
one of these lower level languages currently, you might have an
intractable amount of work to get up to the full capability and richness
of an app.
So for example, if you wanted to write like an iPhone app on equivalent
hardware up from C, it would be an enormous undertaking.
That to me points to a really fundamental issue here, which is that a
lot of programming language, I don’t want to call. Design, but like
programming language, bringing into its existence and programming
environment bringing into existence is an economic problem and not a
technical design problem.
The amount of resources you need to actually build out one of these new
programming environments is enormous.
You know, I don’t know. Maybe it’s a billion dollars, maybe it’s $10
billion maybe it’s $100 million. You know, it’s a lot of zeros,
right? And so the only way that you can realistically get there is to
have some multi-step strategy.
And I feel like not enough people are kind of considering that, cause
like, I wish, you know, we had this ideal programming environment where
you could do X, Y and Z, but you gotta have some way to start. And by
the way, I think a lot of it goes through like toys, games, fun stuff,
you know, playing around with your home.
Programming environment, that’s kind of a way to get some initial
bootstrapping and resources, which is why I keep advocating for doing
experiments in that direction. We could probably do a whole podcast
about economic thinking at some point, but I just wanted to mention that
I think you got to consider this resources and incentives and
motivations angle.
00:53:07 - Speaker 1: Yeah, probably you all have seen, you know,
there’s the whole famous essay about Unix worse is better, but I think
like one of the interesting arguments, I don’t think it’s quite an
argument against it, but it’s pretty close, is, you know, the reason
Unix succeeded was not because worse is better, it’s because AT&T like
gave it out for free to universities and like that meant that everybody
learned it in their university, and then it was kind of like the model
operating system that you would base your computer around.
00:53:31 - Speaker 2: I’m thinking of the meme first time founders
think about products, second time founders think about distribution, and
in this case you know the distribution.
00:53:39 - Speaker 1: And that is kind of like a weird artifact of like
1950s like US antitrust. Like it doesn’t really, I mean, I don’t know
if there’s really a lesson there, but like, yeah, I think like thinking
too much about the technical construction is maybe a mistake compared to
thinking about the economics.
00:53:54 - Speaker 3: Yeah, and this reminds me, I recently saw someone
asking on Twitter, why don’t more programming languages have this nice
property, and I think the property was there’s a small number of
primitives.
00:54:07 - Speaker 1: Orthogonally applied to many problems which Oh, I
saw this, yeah, I think that was Patrick Groy maybe, yeah.
00:54:12 - Speaker 3: OK, nice. Yeah, we’ll like the tweet in the show
notes, you know, and by the way, it’s a thing that I’ve advocated for
many times on the podcast, it’s very nice, but the correct observation
was that this basically never appears in practical industrial
programming languages, and my thought on that was that.
Well, unfortunately, as we’ve discussed on this podcast, the success of
programming language is not determined by their design quality. It’s
primarily a matter of what they’re programming against and the economic
resources behind it.
So why did JavaScript succeed? That’s basically nothing to do with the
programming language design and everything to do with it was the
scripting language for the browser, which is incredibly important.
You could basically done anything there, I think, and it would have been
enormously successful.
And so the reason why we don’t have these nice properties in
programming languages is because They’re very hard. You have to
constantly fight against entropy and accidentally bad designs, and given
enough time, you know, basically no one could do it. And so you just
have these high entropy programming language designs out there,
basically by accident, I would argue.
00:55:07 - Speaker 1: Yeah, I remember making this joke a few years ago
that, you know, imagine if we all sat down around a table and we’re
like racking our brains, we were like, why is Objective C been so
successful in the market? Like, what did they do in it that made people
want to adopt it so much? And it’s like, obviously it’s because the
iPhone, like, yeah, and it’s like really nothing to do with the
programming language design other than like what made Apple willing to
adopt a.
00:55:28 - Speaker 2: Right, and there I would say that the programming
kind of stack for the Apple world, especially now with SWIFT and Xcode,
and certainly all the APIs and stuff that’s there, is one of the better
ones that captures some of the qualities of using kind of a, in this
case, it’s a native language that’s sort of fast and you’re not going
through some abstraction layer to get to the capabilities of the
platform.
But at the same time, Apple provides just a huge number of APIs that are
relatively high level for doing all the various things you might want to
do, both hardware-wise, but just sort of capabilities of the system.
But yeah, you want to talk about economic incentives.
Well, OK, it’s that the App Store and Apple’s cut of that and the huge
success. of apps on this platform just means that there is great
incentive to or there’s a lot of money to sort of make it be
successful, and also kind of coincidentally, Apple really cares about
design and craft and put a lot of effort into making it pretty good as
programming environments go, but You know, it could have been that you
had this incredibly successful platform, they needed to make a
programming environment for it, and it was not a company that cared
about that stuff, and then you would end up with something that’s just
much more random. So it’s sort of not a well designed programming
language in a way, it’s not a sort of like a fitness trait in in any
particular way other than for, I don’t know, programming language, you
know, design nerds.
00:56:55 - Speaker 1: Yeah, I mean, I think the Apple stack is, I mean,
most of my background was in Web programming.
I’ve done a little bit of stuff on the Apple platforms, you know, with
the screenshot stuff and with other things, partly just cause that’s
what you have to do, like, you know, if you want to be taking,
monitoring your screen or seeing what’s underneath the screenshot, you
know, you better be writing an objective C like you don’t really have a
choice or Swift.
But I think if you have a web programming background and you haven’t
looked at the Apple stuff, I would definitely recommend it cause it is
like a very, just from a cultural point of view, it is like just a very
different ecosystem. It’s like actually designed in a way where, you
know, there’s one company that built the ID that built the language,
that built the APIs, and they can kind of unilaterally make changes. I
don’t think it’s all good, but it’s like, it’s different and it’s
interesting.
00:57:40 - Speaker 3: Omar, I’m looking at our shared notion doc and
you’ve written wiggly computer. What does that mean?
00:57:46 - Speaker 1: Yeah, I, it’s a good question. I feel like I’m
trying to figure that out too, but Like a lot of things on the computer
are like these buttons and toolbars and commands that you run, and
they’re very much like, you hit a button and it’s this very discreet
way of interacting with the computer.
And so I think there’s a question of how can we make computer systems
that are wiggly, where instead of these discrete actions, you kind of
can continuously move things, like the motion that you do as a human,
where you’re like dragging something around or pointing out something
or like wiggling something to highlight it. Like, how can that motion be
carried through into the computer and into the application, and like,
what are interactions that work like that, instead of interactions that
work like you’re tapping or clicking something or hitting a key on your
keyboard. I don’t have like a super well thought out philosophy of
this, but I do think that that’s whenever I encounter things like that,
it feels really nice, and I think there’s actually a lot of power there
in terms of like, you can simplifying your computer system. By not
having a lot of options and buttons and functions, and just sort of
trying to carry through human movement.
00:58:53 - Speaker 2: A reminded mark of your probabilistic gesture
input system where the system is sort of simultaneously guessing which
gestures you’re starting and assigning probabilities, which there is
some amount of in touch systems, so some of that’s built into iPad and
what have you where it’s sort of a particular finger down could resolve
into a pinch or a drag or something, something else, and it doesn’t
quite decide which one it’s going to be until you are.
Was in, but I think you had a version of this which goes even beyond
like a simple heuristic of, OK, it’s two things until that second
figure comes down within 100 milliseconds and instead is much more of a
fuzzy guess that eventually resolves and maybe even post hoc rewrites
which you’re seeing visually to match what it now has decided to have
done.
00:59:39 - Speaker 3: Yeah, I think there’s a lot to that, and by the
way, it would interact very well with this visualization of programming
state idea that we’ve been talking about.
You can imagine some little corners up on the top of your screen that
appear and get brighter and dim, you know, that has like a two-finger
gesture or a double click gesture according to what you’re doing. And
also, by the way, These could be parameterized and end user adjustable.
My belief is that basically any user impacting parameter in the code
should be user adjustable on a slider. So two that already are typically
are font size and key repeat speed. So when you hold down a key on your
keyboard, it like eventually starts repeating and the delay until the
repeat and the repeat rate is in good environments, it’s configurable.
In the best environments, you can like hold down a key and then drag the
slider back and forth and see how fast it’s going. That’s cool, until
you get it right. And I think that’s how all UI should work, at least
at the developer level. So something that we often try to do with Muse
is we have like a debug menu, and there’s some parameter like, you
know, ink curve, delineation, you know, variable or whatever. And
instead of hard coding that into the code and asking a developer, oh,
you know, I think the curve is too curvy, can you make it less curvy?
That should just be a slider. Maybe there’s a detente, which we think
is the current correct value or the default value, but then you could be
drawing with one hand and sliding around this variable with the other
and immediately seeing how it reacts.
01:01:00 - Speaker 1: Yeah, I really like that probabilistic gesture
thing. I was actually thinking about something similar too. Cause like,
right now, basically there’s like a gesture recognition layer, and then
there’s the actual programs and they respond to the gestures.
But if you had a sort of end to end program that like could do the
gesture recognition and then like generate a probability distribution,
and then like run the program on the entire probability distribution,
and then like, you wouldn’t have to resolve anything the program does
until you’re like done with the gesture. Yeah, I don’t know if it’d
be useful for anything, but I think it would be cool to see, like, you
sort of see these overlays of like different universes, and then they
kind of fade in and out as you move your finger. I mean, I thought about
this a little bit in the dynamic line stuff of like, well, a lot of
recognition systems are like probilistic, like you’re not totally sure
what you’re seeing, so maybe you can kind of have this super position
of like different things you recognize and what the effects of those
are, and then you wouldn’t have to resolve them until the end.
01:01:47 - Speaker 2: Wiggly. Now one thing we mentioned earlier, but
haven’t talked about much is your project TabFS and this is something
where you essentially use a fuse file system to mount the open tabs in
your browser as folders that you can then browse through and do
programmatic operations on them. Now that’s interesting because that
ties a little bit back to that we talked about the Unix kind of
everything or the Unix philosophy and kind of text as input output
pipes, but of course another piece of the Unix philosophy is everything
is a file. And yet we do live in this world that is more kind of
increasingly with mobile platforms, files are just kind of mobile and
cloud basically means you know files are on their way out. How do you
think about files and particularly in the context of this TFS project,
do you think of that as something where you want more of your system to
be Controllable through files, or do you see that, you know, I don’t
know, files are more of a retro computing thing in the same category as
a, you know, a Game Boy emulator.
01:02:47 - Speaker 1: Yeah, that’s a good question. It feels somewhere
in the middle to me, like, I don’t have like a deep attachment to files
as like the interface of the future or anything, but I do think that
there is, at least like files are objects, and like, you have operations
that you can do to them.
Like, you can copy them, you can move them around, you can cap them. You
can look at them in Finder, you can look at them in Emacs, you know, you
can grab them, you can watch them and do things when they change.
I think with the web, without that, there’s nothing like that on the
web, like, you kind of have to build everything from scratch, and so
mapping things into files is a step up from what we have now, even
though I’m not like 100% committed to files as an interface.
01:03:26 - Speaker 2: Yeah, for me that agency that you get from these
very, I guess, uniform operations, which is, you can always move it, you
can always delete it, and you can always duplicate it.
And duplication is nice for backups.
I’m a big fan of, I think we talked a little bit earlier about the
iteration process, whether it’s Git branch or something that’s more
like a, you know, copy paste to kind of like riff on a few different
variations of an idea of a thing that you’re working on, duplicate has
that capability where I can say, OK, I want to try something out, but I
want to be able to return to my current state. And I just know in the
old school world the files, you know, I close the word processor, I copy
my file.doc to my file to. doc or my file experiment.doc. I open that
file and I know I can do stuff to it and I know. Won’t touch the other
one and that’s something that’s often missing in cloud services, for
example, where it’s like, OK, I want to do this big operation to like
reorganize my email or something like that, but I’m not sure if it’s
going to get messed up. So can I just snapshot the current state, but
like, no, there’s no concept of that. That’s a good point. It’s some
database somewhere, I guess some DBA who’s not me and works for a
company that I’ve never met, could potentially do that, but it’s just
not within my control as a user, right?
01:04:47 - Speaker 1: Like there’s no like Omar.gmail file that I can
like duplicate.
01:04:51 - Speaker 3: And this is sadly actually one of the dying folk
practices.
So, especially in games, they used to save the state of the game often
as a SQL database, and then often the game files was compiled a code
plus images.
So there were two ways you can like basically go in and poke at your
game. One is you can look at the. To like save file and read it or even
write to it, so you could like find the road that’s like your sword and
like increase attack by 1000 or whatever. So you could also go in and
edit the images. So people would do all kinds of stuff. Like, for
example, if you had trees in your game, and it was Christmas time, you
could like turn it into a Christmas tree so that you would be in this
Christmas wonderland for your game. All kinds of stuff that people used
to do when you could go in there and poke at your files.
01:05:35 - Speaker 1: Yeah, and it’s like, even if, you know, you have
a cloud service and it has like a little pseudo file system, and you can
do things like that, you don’t necessarily know that you can do things
like that, right? Whereas like, you know, not everybody knows how to use
the file system, but if you know how to use the file system, you know,
your knowledge will generalize to anything, any application that uses
the file system. There’s an element of like, are the operations
available, but there’s also an element of like, you know, do users know
about the operations, which I think is also important.
01:06:02 - Speaker 2: Yeah, I think the simple mental model of files,
which on one hand, I think files and file management is one of the
things that confuse, let’s say, non-power users, but basically average
people with computers. I think that and the like Windows and the
difference between like minimizing a window versus like closing an
application.
These kinds of distinctions and so I think that was a reason why both
mobile and cloud essentially getting rid of the idea of closing an
application or managing files or worrying about your hard drive or
backing up your hard drive, that stuff was just tough for non kind of
power us. or computer professionals, but for someone who did go a layer
deeper and understood the basic mental model, it was very simple and
easy to understand that it didn’t matter if it was a Photoshop file or
a spreadsheet or a text file or whatever. The duplicating, moving,
renaming, deleting is kind of always the same.
And once you grasp that simple set of operations, it feels very
empowering.
Yeah. Well, maybe as a place to end. I’d love to hear what projects are
on the horizon for you, where are your interests drifting to next.
01:07:18 - Speaker 1: Yeah, I mean, there’s a bunch of different
stuff.
I feel like I have queued up at the moment.
There’s the screen matcher work. I mean, I think with a lot of these
projects, it’s like more of a question of like getting it to the point.
Where we can at least publish something and like, get people excited
about it, because I think there is like a huge, even with TFS, you know,
there’s a lot more that could be done on top of that, I think. And I
have a lot of things written there that this would be cool to do, that
would be cool to do. But yeah, so like, getting some of those things
released, you know, looking at some of the physical computing stuff, the
RFID stuff, but, you know, I’m always on the lookout for interesting
projects to do also.
01:07:54 - Speaker 2: It does beg the question is, what for you is
finished in the sense of one ready for release, and then 2, the degree
to which these are things you’re going to maintain or extend or improve
over time versus, you know, when I think of a pure research, you know,
like an Ink & Switch piece, we rarely build on kind of the prototype
because the point was to publish about it. Yeah. Have the discussion,
but then a future project, even it’s gonna research on the same kind of
area, you might start from scratch or do you just might start in a
different place. The goal is not working software to maintain over time.
01:08:30 - Speaker 1: Yeah, I mean, I think it varies and it also varies
with the project, you know, like the screens is working software and I
use it regularly. I mean, I think often the way I put the goal is like,
I would like to get it to the point where I think that People reading it
will understand the point that I’m trying to make. And I think, you
know, that implies a certain level of polish, that implies a certain
level of interesting examples or demos that may imply people should be
able to download it and try it, but it doesn’t necessarily imply that
it needs to be a fully working product or that I’ll maintain a.
01:09:01 - Speaker 2: Well, certainly, that would also say that the
storytelling or explanation or yeah demo, whatever it is, is equally
important, if not more so than the software itself.
01:09:13 - Speaker 1: I sometimes make a joke that I write a lot of
these projects as an excuse to write the read me for the project, which
is basically like an essay.
01:09:22 - Speaker 2: That makes sense. And in some cases, I guess it
depends on exactly how much is conveyed through the project through a
simple video, through installing it yourself, through a screenshot, how
much like longer description is needed, but we had Jeffrey Lead and Max
Schoening on recently talking about their income switch project. They
basically said, you know, we spent Longer, I think on the writing and
the trying to understand what we learned from doing this weird thing,
and then of course writing itself is this whole own giant production
process, making something comprehensible and deciding on the terminology
and all that sort of thing.
01:10:00 - Speaker 3: Yeah, well, Omar, your projects have definitely
had a big impact on me. You’ve gotten some very interesting messages
across, and I think that’s the case for a lot of people who follow your
work, so really looking forward to what you come up with next.
01:10:11 - Speaker 1: Thanks.
01:10:12 - Speaker 2: 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. And Omar, thanks for challenging us and
inspiring us with your combinations of unexpected things.
01:10:29 - Speaker 1: Thanks for having me on. Thanks, Mark. Thanks,
Adam.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: Everyone gets into a room, you have a brainstorm
and out comes the ideas. The reality is so much messier. You have
individual to group back again, you’re bouncing around among
individuals, you’re bouncing around among different levels of fidelity.
The ideas get mutated, even corrupted, if they get passed from person to
person. Almost like this pulsating network, right? With all kinds of
weird patterns happening is what’s really needed to produce good ideas.
So the substrate, the tool needs to embrace that.
00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product, it’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with Mark McGrenigan. Hey, Adam. And Mark, I’m
excited to say that we’ve given a name to the next major release of
Muse. We’re calling it Muse for Teens, and we’ve got the Alpha program
underway right now.
00:00:58 - Speaker 1: Yeah, we’ve had this phase penciled into the
master plan for years, and it’s great to see us finally bringing it to
fruition.
00:01:05 - Speaker 2: Exactly, yeah, it really is a whole other
dimension. I think it’s true of most tools, you know, whether it’s a
video editor or a word processor or whatever else that you add some kind
of multiplayer collaboration or sharing capability, and it really is a
whole new dimension to the tool, but I think that’s doubly so for Muse,
which is an ideation space.
So, you know, when I’m gonna start a new project, for example, the
first thing I’m gonna do is make a board to sit down and essentially
get my thoughts together on it. And so here, doing that with a team,
when that team is starting a project, well, we’re finding it to be very
powerful indeed and sort of almost a multiplier effect on the value of
the rest of the product. So it’s a lot of fun.
We got a little demo video online, I’ll link that in the show notes,
and yeah, we have a couple dozen teams in the Alpha program here, really
giving the local first sync and sort of the capabilities, the product of
solid pummeling here, or we hope it can.
Stand up to everyone’s needs, as well as we continue to just discover
what are the most interesting things to add in the collaborative
setting. You know, we start with the obvious stuff like comments, for
example, but I think there’s a lot of non-obvious stuff that we’ll get
to pretty quickly, so.
Very exciting stuff and of course I’ll put all the necessary links for
that in the show notes, but I thought it would be a great chance to talk
about something we’ve mentioned in passing in a number of episodes,
which is remote work. So that’s our topic for today and of course the
muse team is all remote and part of the reason it’s so salient, I
think, is the muse for teams. product as it’s shaping up for us in our
internal use, but also with our customers in this alpha here is really
seeing the role it can play for especially for remote first team. So
there’s a lot of interplay between how we personally think about remote
work, I think, and where we’re going to go with the product.
00:02:48 - Speaker 1: Yeah, and it’s also a very ripe time in the
industry with a lot of companies exploring this way of working,
basically whether they wanted to or not, because of the pandemic. And
you saw a bit of a phase shift over the past few years towards this
approach. It’s also notable that you and I have a lot of personal
experience with many pieces of the spectrum. We’ve kind of gone, I
think, through almost the whole range. And so I’m sure we have a lot of
personal things to say about it as well.
00:03:14 - Speaker 2: You know, the timing topic is a funny 11 thing
that occurred to me, or if I was a listener of this podcast and I saw it
pop up in my feed, I would think, hm, remote work, wasn’t that a hot
topic circa 2016? You know, I seem to remember a lot of blog posts and
especially medium posts when that was the hot thing. actually right
around the same time that I shifted to remote work, which was we started
in Switch in 2015, we started that as an all remote research lab, always
figured, well, you know, this will work to get started, but once we
scale up, you know, we’ll need to get serious or whatever and get an
office, and that never happened and I think the remote nature actually
unlocked new possibilities for how we could do these research projects
and the kinds of people we could bring in. And it turned out to be, in
addition to just having these benefits of letting us focus on the
business rather than, I don’t know, office leases also seemed to have
these other benefits as well.
But at least I remember in that time, the 2015, 2016 window, most of the
posts were really from the perspective of individual contributors who
were basically saying, hey, I want to reclaim my commuting time, or I
want to be able to be home for my kids’ bedtime, or I want to eat
healthy, you know, listing out the benefits to an individual
contributor. And I think the timing there was probably also not a
coincidence that that was probably around the time this kind of first
generation stack of tools, that’s Slack, Zoom. Google Docs, Figma, and
obviously those are all slightly different age pieces of software, but I
feel like there was a critical mass if you could put together some
subset of those and get a pretty good working collaboration, not
certainly at the same level of bandwidth as working in an office, but
maybe you kind of crossed a threshold where the benefits started to
exceed the cost or where it was even possible, maybe was one way to put
it.
00:05:00 - Speaker 1: Yeah, at least for the vanguard of individuals and
companies. I think it is true that called around 2016, there was a lot
of discussion about it, but let’s say it’s probably from a pretty
vocal minority, which I don’t mean in any negative way, but if you look
at the bulk of economic production in the software industry, it was done
by on location firms, and in the past few years, that has turned over in
a big way. So you get a whole new swath of data to talk to.
00:05:26 - Speaker 2: Indeed, yeah, well, I guess it was 2020 that it
suddenly seemed that every single person I knew became aware of what
Zoom was, and of course we’d been using that piece of software along
with many others for some time and had developed habits and techniques.
Uh, about social mores and just ways to use them effectively and so the
whole world was kind of getting a crash course on that and accelerating
the adoption of these tools, and you could argue that there was maybe
even an almost an over exuberance, and I don’t exuberance is the right
term. I guess it’s just like we were forced into, the whole world was
forced into this or as much of the world. feasible to do, which is
basically most knowledge workers as well as schools, and that in turn
probably caused a lot of Silicon Valley folks and investors and so forth
to think, OK, this is a huge market and indeed if you looked at the
stock price of Zoom at one point, I mean it was pretty wild in the
middle of the pandemic somewhere, its peak, I think I saw some stat that
it was something like the Market cap of Zoom was larger than all of the
airlines combined in that moment, all the US airlines combined in that
moment, and of course their stock was massively down, and you look at
many of these companies that did well, e-commerce and so forth in the
pandemic, and if you look at the 5 year graph of their stock, they had
this huge boom over the pandemic time and essentially they returned a
little bit more to earth since then. And so I think in some senses there
was almost a boom and investment and new people working on Zoom
alternatives and things like that and maybe in some ways here now 2022,
2023 we’re kind of going back to the office and maybe folks are like,
OK, maybe that wasn’t as big of a boom as we thought, but I almost feel
like this is looking at the hype cycle curve, you know, again, it’s
weird to call the hype cycle because it was. necessity, but that peak
that we had in the 2020, 2021 period was kind of like that peak in the
hype cycle curve and where we are now is maybe a trough where it was
overhyped or overdone or something, but actually now we have a lot of
data like you said about like what the benefits are, what the downsides
are, and we can feed that into how we develop practices and tools.
00:07:36 - Speaker 1: Yeah, and I think it’s a more healthy and
honestly more interesting place now during the height of the pandemic,
where, you know, you basically weren’t allowed to go outside, you
really feel on top of the world if you’re a remote software provider,
because people have no choice, right? Or if you’re Uber Eats or
something, right, you’re just making money hand over fist cause people
don’t have any other option.
But now you have to confront the reality of success can’t just be, you
can do it and you enjoy working from home in your pajamas or whatever.
It has to be you successfully produce valuable software for your
customers, and some people are gonna try to do that remotely, some
people are gonna try to do that from the office, and your proposed
mechanism has to be successful in delivering those goods.
00:08:13 - Speaker 2: Yes, well, we’ll get to see kind of how these
companies perform in the market, the companies that choose to be
co-located in the same place, invest in an office, get all the benefits
that come with that high bandwidth, maybe more personal trust and human
connections and things like that, but of course there’s a literal and
logistical cost there. Maintaining offices and requiring people to be in
the same physical place and so forth and so we can compare the teams
that do that against the teams that don’t. And I hope there’s room for
both possibilities in the world or maybe we’ll discover certain types
of products or ventures, sort of demand, co-location and others it’s
less important for. So yeah, the grand laboratory of the free market
will give us a lot of information.
Maybe we can start with the kind of personal motivations of let’s call
them knowledge workers or creative workers.
This would have been some of the contents of those medium post circuit
2016, and I think the lifestyle aspect, the flexibility, being able to
control your workspace, reclaiming that commute time is obviously part
of it. Are there others either for you personally or you’ve heard
others discuss?
00:09:25 - Speaker 1: I think a big one is location flexibility,
especially as the lifestyle quality in certain American cities was
declining, and also some people just didn’t want to live in America,
like, you know, you want to move to Germany, there would have been a
time where You would have basically written yourself out of most of the
software industry if you did that, but now you’re still very much in
the game.
So I do think location flexibilities, but some people wanted to move
closer to their kids or to their parents, right? I think that’s a
pretty big one because there was a time where there was only really a
handful of cities that you had to be in if you wanted to be at the top
tier of pure software firms, and that’s no longer the case, which is
great.
00:10:04 - Speaker 2: Yeah, completely, and some of that is just
preference. We talked about that in our cities episode in our personal
decisions, my case to move to Berlin, yours to Seattle, and certainly
many folks have chosen to leave a city altogether and live someplace
more in nature. In many cases you do want the ability to live near
family or I know the For example, we had Tyler from Cam Fund on our
podcast and he talked about that he was in Mexico City because that’s
where his wife needed to be for her career. And that’s great that you
don’t have to necessarily have this conflict between two people who are
pursuing careers if one of them is very flexible at their location.
00:10:42 - Speaker 1: Yeah, and you might put this in flexibility, but I
think a big one is just control over your physical work environment,
towards the end of the peak of the cycle in San Francisco, it was
getting pretty wild with how tightly they were packing people in there,
just couldn’t hear yourself think, right? At least I couldn’t. So
people would go in with like, you know, earplugs plus noise canceling
headphones to try getting your work done. Meanwhile, you’re combating
all of the mechanical keyboards anyways. It’s just being able to go to
an office that is soundproofed and you know cars driving by all over the
place. It was a big win.
00:11:15 - Speaker 2: Yeah, control over your personal space, which
includes, yeah, obviously things like desk or chair, noise levels, and
honestly, some people like more, right? They got to go to a coffee shop
where there’s some hustle and bustle for them to be able to think,
whereas, yeah, I’m more of a quiet room kind of person. And then
you’ve also got the element of your hardware. So there’s your desk set
up, there’s your, again, the mechanical keyboard or not, there’s what
kind of headphones do you have that sort of thing, and obviously
companies Do potentially give you the option to make purchases, but I
think this leads maybe a little bit to the maybe the responsibilities of
being a remote worker, which is a lot more self-management. And so
that’s something like, yeah, when it comes to hardware, certainly
everyone on the Muse team, I don’t know exactly how other teams do it,
but we basically say, OK, here’s your budget, basically make sure you
have the right hardware to do this job, and sometimes that’s podcasting
mics and sometimes it’s iPads and pencils, and sometimes it’s just a
really fast computer, but it’s sort of really kind of more up to you
and in that sense, you know, close to being a freelancer, you need that
ability to make wise decisions about, OK, I’m gonna spend this money
for equipment in order to, you know, maximize my productivity as well as
my just comfort and enjoyment in the job. And then it’d be remiss if I
didn’t mention an idea here that comes from Hilary Maloney, someone we
collaborated with a little while back, who had this concept of a work ID
list, and she actually discovered this in looking through our customer
feedback and kind of some different surveys and things and trying to
understand the kind of person that wants to use and purchase Muse, and I
found this so interesting. I would not have in any way zoomed. In on
this and thinking about our target customer, but she defined it as
someone who is not doing the work just for the paycheck if that’s the
right way to put it, but they’re driven to be in tech or a creative
field of some kind because they feel they can find a lot of meaning
there and they want to bring their strategic skills, their creativity,
their intellect to the table to work on something they find
intellectually interesting, challenging, meaningful. Obviously it’s a
great privilege of being in a field where your skills are in demand to
be able to kind of go higher up the Maslow’s hierarchy, I guess, in the
work you’re doing, but it’s really true. We do have this option and
one way you can choose to optimize your career is say, well, I’ve got a
set of skills, whether it’s design or software engineering or product
manager or whatever, and therefore I’m going to use that to maximize my
compensation, which usually is probably going and getting a big comp
package from a fang company. But another way to think about it, which of
course is the decision I think you and I have made as well as everyone
on the Muse team is actually we want a balance of things, we want to be
compensated reasonably, but we also want the kind of work life. And
meaningful mission in the company and you know, values in the company
and frankly started part of that is the flexibility in our day to be
able to spend our work time and our creative energy and the time and
place of our choosing, if that makes sense, or at least something that
finds a balance between the needs of the greater team and the company
and what we would like to do personally in terms of how we work best.
Another one of the items in her kind of breakdown of this work idealist
persona was the concept of actively designing your day, and in
particular designing it to maximize your focus work. That could be
something like the deep work concept, you need a big block of time,
you’re gonna mark that off in your calendar, you’re gonna aggressively
defend it from meetings. But that also just connects to the workspace
exactly as you said that you have a quiet space at home and you can,
unlike in an office, you can turn off distractions by turning off your
notifications and choosing to really focus on something and it’s a lot
harder to do in an office. There’s some meeting happening, hey,
there’s the all hands, hey, we’re going to lunch. And sometimes being
connected to that is part of the value of being in an office. You have
this ambient energy and this kind of natural background hubbub of
activity that you can hook into. But then if you are someone that wants
to design your day to be able to spend your precious work hours in the
most productive way that you can, that gives you less agency on that
front.
00:15:28 - Speaker 1: Yeah, so lots of potential benefits from the staff
side. How about looking at it from the point of view of a company going
remote? What are the benefits, challenges and considerations there?
00:15:39 - Speaker 2: The huge thing that I didn’t really realize going
into what a big deal it would be, but is the ability to hire from the
global talent pool.
So when we started in Code Switch, and it was just a few of us, and we
decided to work, you know, together remotely, and I was really thinking
of it in that perspective of that as a person on the team, this is just
useful for me and how I want to live my life at the moment.
But once I was in the position of staffing up projects and looking for
people, particularly in the very, very specific areas we were trying to
hire for, I mean, I remember we were going to look for someone to work
with on some CRDT projects circa 2016, and, you know, we made a list of
everyone who had expertise with that in the world, and the list was like
10 people, right? And they were, of course, spread all over the world as
you might expect.
And so being able to potentially have the ability to hire any one of
them. And especially on a short term basis.
So this is something I’ve done a lot of in my career, which is, you
work hard to recruit someone, but then getting them to relocate can be a
huge deal.
I mean, first of all, obviously moving is a big deal for people, it’s
expensive, it’s emotionally demanding, but then you often have
immigration things, right, where you have folks who are in some cases
takes them years to get the visa they need to come work with you.
And then if you do get in the thing where someone comes, works with you
for a little while, turns out it’s not a fit and you’ve gone through
all this and they’ve uprooted their life, boy, it becomes really hard
to consider, you know, for them to think about quitting, especially if
it’s tied to their immigration, on the employer side to think about
letting them go. Because you just know what a huge deal this was to work
together, and with remote, you say, what are you available? Well, next
week, great, let’s start working together. And it’s just a much more
lightweight operation, and you sort of decoupled all of these other life
choices from your employment, and so that’s this huge benefit on the
employer side, the team builder side, the company side is that global
talent pool and the lightweight hiring process, and I think that single
benefit is so big that it basically makes up for a huge number of other
downsides of remote work.
00:17:50 - Speaker 1: Yeah, that’s a great point, and I feel like it’s
still underappreciated in the market. People have spent their whole
careers with this baseline unremarked upon assumption of because it’s
so expensive in many different senses to relocate someone in order for
it to make sense, it has to be a longer term commitment or at least
expectation. And we’ve removed that constraint, but it hasn’t fully
propagated through the system, I would say. But while that’s the case,
it’s to our advantage for sure.
00:18:20 - Speaker 2: Now there’s a, call it administrative piece of
this as well, which is increasingly you can kind of decouple the legal
jurisdiction of the entity, the employee location, and yeah, the owner
location. Which is quite interesting.
I think Stripe Alas was the first mover on this first base is another
company that makes it easy to just incorporate a US legal entity,
whether or not you’re located in the US. You also have up and coming
services like Wise, which makes it really easy to do currency
conversions and sort of international transfers, or you got something
like De DEEL, which is kind of like an international HR kind of
platform.
And all of these things acknowledge this reality of that I think in some
ways probably the legal frameworks that exist haven’t quite caught up
to yet, which is, you have what I’ve sometimes heard referred to as
micronationals.
The Muse team would fit into that, right? We have some folks from
Europe, we have some folks from the United States, and historically, if
a company got big enough to have teams in two different countries, let
alone two different continents, you would be huge. And so of course you
could set up maybe, I don’t know, all kinds of HR process and things
like that to kind of manage the. Relationship between the legal entities
and the employees and comply with all the local labor laws and things
like that. But now it’s quite common, even just a founding team, and
just two people who are gonna work together might be from two different
countries, and they don’t have any plans to relocate or whatever. Where
do you incorporate, where is your bank account? And I think increasingly
it’s become possible and even a common practice to think of the
jurisdiction where the company lies is, yeah, so completely independent
of where the employees may happen to be located.
Now, you still have to deal with lots of complexity potentially moving
between them. So as one example, The fluctuating USD to euro currency
conversion rates in the later part of 2022 is a challenge for the Muse
team, but it really is possible to have a small team where people are
located in different countries, and yeah, you can kind of make so much
of this virtual and do all that in a way that’s legal and practical.
00:20:31 - Speaker 1: Yeah, it’s definitely very doable now and only
getting better with these various services that you’ve mentioned.
Frankly, it’s a bit of a mess, like currency conversion and tax law and
employment law, it’s like it’s kind of all over the place, but just
grind through that and it’s very doable.
00:20:45 - Speaker 2: There’s a great article I read a couple of years
back called The Legal Implications of Remote, which I think was someone
looking at the UK specifically, but I think the general concepts are
broadly applicable, which is honestly, it’s not a fully well fleshed
out area of law because it is so new and especially if you think of
something like workplace.
Safety, which isn’t really a huge concern for knowledge workers for the
most part, but you know you have someone like our colleague Julia, you
know, she’s a German citizen. We’re a US based company. She spends
several months of every year in the winter months, usually in some place
like Mexico or someplace in Central or South America, and if she has a
workplace injury. When she is a citizen of one country employed by a
company based in another country while she is physically in a third
country, which labor laws apply there. And yeah, it’s a brave new
world.
Now one thing we considered when we set up Muse was the compensation
question. Gitlab has some nice documents on this where they have their
kind of weighted. They have a waiting relative to basically where you
live because of course it’s pretty normal to pay rates that are
relative to your local market.
So this is a bit of a debate, you know, is it do you just pay everyone
the same, or do you wait it according to where you happen to live? Does
that create opportunities for people to move somewhere, you even have
companies who have paid you to move someplace less expensive. What do
you think about that debate?
00:22:10 - Speaker 1: Folks understandably develop very strong opinions
about this matter, but a lot of what I’ve seen is a little bit, I
think, too shallow and doesn’t address the dynamics. I think you need
to understand this is a process that’s playing out over time. So let me
use a little economic story example. Let’s say that initially, You have
like two markets, you have the high-end software market and the regular
software market, and those are strictly geographically co-located, or
people on the high end software market get paid twice as much for
whatever reason, you know, cost of living, make something out due to
where they are, and you can’t work across those boundaries, and then
some single individual. Invented a magical technology, let’s call it
voom, and they can work on either side. What should their compensation
be? Now there’s two kind of legitimate arguments. There’s the argument
of, I’m Doing the same work and even though I’m from a moderate cost
area, since I’m doing the same work as your highly paid employees in
the new area, I should be paid twice as much, or it should be your cost
of living or whatever you want to make up is only half of our other
employees in this high cost area. Therefore, you should be paid your old
wage which corresponded to your old cost of living.
And what this shows that the actual issue is that there’s a lot of
surplus generated. That’s an economic term, which is basically a
difference between the value that’s being produced and the cost of
producing it, right? And the question becomes how do you allocate that
surplus? Does it all go to the employer? Does it all go to the employee,
or is there some mix? And when you phrase it in that way, you see that
the idea that it should be exactly equal to one of those two extremes
is, uh, it’s a little bit doubtful to me. So what I expect is Over
time, the markets blend. So while you’re in that initial step of the
process where there’s very few people who are crossing geographic
boundaries, there’s big surpluses that are unlocked, but it’s also
very contentious to negotiate the salaries because deciding how to split
up that pie. And we’ve seen that play out with, you know, very strongly
worded statements about, you know, you should definitely pay full SF
rate or you should definitely pay cost of living rate. But what’s gonna
happen over time. I this is basically gonna become one market, I would
think, where in the fully remote world, your salary is gonna be a
function of your effectiveness or your be believed effectiveness, and if
it’s really the case, you know, asterisks, if it’s really the case
that there’s no difference on your Impact and productivity for the
company based on where you live, that will be reflected in salaries.
Now, by the way, that goes both ways. It might be the case that it
becomes uneconomical to be a software developer in San Francisco because
it’s too expensive versus the market rates in the same way it’s
uneconomical to be like a textile factory in San Francisco. Now, I think
we’re far from that, but I do expect and If it’s true, if the premise
is true that we’re moving to a fully remote world and that that’s just
as effective as the local world, then I think things will equilibrate
and that will have some winners and losers. But it’s not gonna be that
everyone in the world gets paid what was formerly the very top rate. I
think that’s unlikely. And by the way, this also connects nicely to an
element of personal responsibility and it ties into a little bit of how
we approach Muse. A company can say, we think kind of a fair global
market value for Software engineering services is X and you can choose
to live wherever you want with that. You know, if you want to live in
Mexico, for example, very low cost of living, and you’re able to work
there and it’s in the right time zone, great. If for whatever reason,
like say you have family in New York City, you really want to live
there, you know, OK, you know, we’re also not obligated to support you
and wanting to live closely to your family. Maybe you should find
another job. So there’s kind of an element of personal responsibility
and finding a good match with the company in the market.
00:25:49 - Speaker 2: Right, so we’ve sort of described here why a
knowledge worker or a creative person would be motivated to work
remotely, a lot of which has to do with flexibility and autonomy and
their lifestyle.
We’ve talked about the company’s motivation, namely around hiring,
accessing a global talent pool, perhaps even this compensation.
Piece of the puzzle, but we’re sort of talking about it as if, well,
obviously this is something that can and should be really broadly
distributed, but in some ways we’ve seen a quite a retraction in recent
time from the peak of remote work. People are going back to the office,
so to speak, and we mentioned kind of towards the beginning that part of
what made this start to become possible indeed what made us founding and
switches and a remote first team, what made us found Muse’s remote
first team was the tool chain. That Zoom plus Slack plus GitHub plus
Figma plus Notion plus a few other of these products, you put those
together in the right combination and with the right set of practices,
and you have something where you can get to 60, 70, 80% of the
productivity of an in-person team, but with all these other benefits and
that sort of cross some threshold of like, OK, this is the cost exceed
the benefits.
But that brings us to Muse for Teams, so we’re working on this product
here now, and we always knew we wanted a multiplayer component of Muse,
but in the process of actually starting to roll it out to our first
users and customers and using it for ourselves and realizing how much,
how we think about remote work and how much we work as a company is
baked into the Product vision is too concrete a word, more like our set
of problems that we want to work on and the territory that we want to
operate in, I think is really a lot about saying, hey, we think we have
something we can contribute to the remote work tool chain, something
that is missing right now.
00:27:42 - Speaker 1: Yeah, and in particular we see Muse as a tool to
help you and now your team have better ideas to idea, and there’s good
remote tools for more transactional and production oriented work. You
can have collaborative databases and spreadsheets, and you can produce
things like presentations and UI designs together. Obviously you can
convey transactional messages in something like email or Slack, but what
replaces The work that used to be done over the whiteboard, around the
punch table, as you’re taking a walk outside with your colleague,
that’s a place where we see music video.
00:28:21 - Speaker 2: Yeah, I think one thing that’s missed in the
discussion of two office or not to office is the fact that different
parts of the work benefit from being a person quite differently. And
there’s a lot of intangible things about like culture transmission and
so forth, but putting that aside for just a moment, I do think that just
looking at the, I had the first spark of an idea to, I shipped it to
customers or to a client.
There are certain parts that are more production oriented and heads down
and individual that probably are just as good to go, for example, go
back and forth on a pull request in GitHub, whereas there’s other parts
that are more loose, sketchy, still trying to figure it out, you need
the high bandwidth of being together and kind of gesturing, and we often
talk about being in front of a whiteboard and partially that’s about
the whiteboard, but I think we use it as a stand-in for that kind of
meeting where You’re trying to get together with your collaborators and
figure out what you’re even, but even there’s a problem or you know,
really trying to develop an idea, and that’s the sort of thing that I
think is very hard to do in these tools, which as you said, are
typically designed to be transactional. You send the email, you send the
slack message.
I think people tend to use, or certainly we’ve seen this from our
customer interviews and so forth, they use a Google Docs notion to some
extent, kind of write up. Ideas and then they go back and forth in the
comments, but it’s all just very structured and it’s all very kind of
flat in a way, and yeah, I think that is sort of the big gap in the tool
chain right now.
00:29:57 - Speaker 1: Yeah, and we’ll talk more about this when we turn
to how well and whether remote works, but importantly this ideation
thing, you can get away for a while without doing it, or in particular
having coasted on your previous ideas.
So if you’re in an office together and you’re coming up with all these
great ideas, high level designs, directions, then you can go and produce
and transact for, I don’t know, a year or two, basically in this
direction and it can work quite well.
But it’s only when you’re 2 or 3 years in that you realize, wait, we
need better ideas, but we can’t do it because we don’t have the
appropriate medium and tools.
So I think part of the reason why we’re as an industry, only slowly
starting to realize the gap here is that it actually takes a while for
it to become a parent.
00:30:40 - Speaker 2: So mentioning whiteboards naturally leads one to
talk about another category of software, which is the infinite canvas
kind of collaborative whiteboards. I feel like there’s quite a few of
these, some of which have been really successful in the last few years.
Miro is probably one of the biggest ones. FigMA launched Fig Jam a
couple of years ago, and there’s numbers of others as well. So one
question would be, we still feel the need to build Muse.
And obviously we can talk about the personal tool and what we do there,
but I guess the question would be, why doesn’t Miro scratch the itch?
If we’re saying we need to have good ideas in front of a whiteboard,
Miro gives you a virtual whiteboard, case closed.
00:31:18 - Speaker 1: Well, I certainly think there’s something there
with tools like Miro.
I had also used Mylonote in the past, but I found myself using those
more for visual presentation of multimedia ideas and collecting
multimedia data, like mood boards and doing almost like PowerPoint type
presentations where you had something you wanted to share, but it
wasn’t appropriate for something like a linear notion document.
But it’s also quite polished and rectilinear and high fidelity, and
we’ve talked about how that isn’t always conducive to ideation. It’s
also a very focused on the desktop, doesn’t really have a strong iPad
presence. So I think there’s something there, and there’s a lot of
overlapping elements that we share, but I think there’s a slightly
different focus and emphasis.
00:32:10 - Speaker 2: Yeah, I posed this question to myself over the
last couple of years we’ve been working on Muse whenever I think about
when we get to that stage of multiplayer, which again was always the
kind of step 3 in our master plan, and we’ve tried using these products
ourselves internally for yeah, team planning and things like that,
including, yeah, exactly Millinode, Myro, fig Jam.
Apple’s got free form now, yeah, there’s a long tail of these that
we’ve tried out, and yeah, they never really, in some cases, I’m like,
oh, that’s pretty neat, but they don’t really stick. I don’t find
myself wanting to come back to them or reference it again.
You certainly can’t use them, in some cases literally can’t use them,
but perhaps you just see they aren’t built for personal thinking. So
I’m never sure what to think when I try out a product like this, but it
doesn’t really stick for me. Does that make me go, huh, maybe this
whole idea of an infinite canvas with multiplayer capability is not as
useful as I would have thought. Maybe we shouldn’t bother to build it.
But the other interpretation is more the now famous story of what the
Dropbox founder told investors when they asked him why are you building
this? There’s hundreds of products that purport to do this exact same
thing in the market. And he basically says, well, do you use any of
them? And they say no, and he says, well, that’s cause no one’s done
it right yet. I’m gonna do it right, and indeed he did.
So whether Muse can be as useful and successful as Dropbox is remains to
be seen, but one of my takeaways from me is like, OK, there’s something
there with those products, and indeed I have used some of them somewhat
extensively, but in the end, I feel like they don’t quite hit the mark
for me, and so, yeah, we’re gonna take our swing at what it could be.
Now, the vision of what use for teams will be, what actually happens
when you have multiplayer capability to this previously, more kind of
private ideation space is something that we’re discovering as we go.
But I think already based on what we talked about here and ideas we’ve
developed on the team generally, you can see there’s already some kind
of principles that are emerging, right? We talked about the benefit of
an office and being in an office for those early ideation. Stages, well,
one thing that we’re finding ourselves thinking of Muse as is kind of
like a virtual office where it’s this place you can go where you can
get ambient awareness of what everyone’s working on, for example. And
once we have that frame, it leads us to implementing features like for
example, the fact that the avatars for your colleagues are always
visible no matter where they are in the workspace, so it has this kind
of one continuous world feeling.
Whether that’s the right thing or not, you know, we’re actually gonna
find that out, obviously through real world usage, but I think that’s
an example of something where we can take what we’ve learned from those
first generation tools. For example, FIMA, I think one of the reasons it
does so well or struck such a chord is it has the sense of place, you
feel like you’re gathering with your colleagues on this document, but
of course that’s within the document, it’s within that one document.
If you go to a different document, you’ve lost track of them. And so
with the muse kind of world, you are able to have ambient sense of where
people are and what they’re doing, you see where they are, and you kind
of peek in if you want, but that’s sort of rude a little bit, and yeah,
it actually gives me a lot of energy to see y’all’s avatars just kind
of move around on this big kind of space of like nested whiteboards, if
you want to think of it that way. And yeah, it’s kind of like a fun way
to meet. It feels like a place to meet and You know, how much can that
be a replacement for what we get out of offices? I’m not sure, but
that’s what we’re gonna find out through this process.
00:35:43 - Speaker 1: Yeah, I think it’s really important to dial in
carefully to why and how ideation works.
I think the high level answer for why not tool X in the past has been,
it doesn’t quite resonate with how ideation really works, and
importantly, the reality of that has no obligation to You know,
basically makes sense to you or to be fair, or to be simple, or to be
straightforward. It might be, for example, that seeing little circles
with your friends’ faces on them next to a document makes you much more
inclined to go there and look at it, you know.
And that regardless of the document itself, and that’s just the way
people are, people are messy. And there’s all kinds of weird stuff like
that with ideation.
Another one of my favorites is, maybe you have better ideas when you’re
sitting down in a couch than when you’re at your desk, you know. Maybe
not, but you gotta be open to weird stuff like that.
And what we try to do with Muse is really tune into those weird
principles of ideation that maybe been lost to the rectangles in the
screen focused that is traditional for software, and I think we’ve had
some good success with it, but like you said, the proof is really in the
market, so we’ll see.
00:36:47 - Speaker 2: Another potentially counterintuitive piece of how
ideation works, particularly ideation across a set of people, is what I
would call the asynchronous component.
I think when you naturally think of group ideation, you think of live
brainstorming, a very real-time aspect, and indeed a lot of when we
think of collaborative tools like a Google Docs, we are thinking of that
very real-time nature you’re seeing someone typing in the document.
But I think for sure a big part of having good ideas and developing them
over time is that like you said, the taking a walk and that has this
asynchronous or spread out across time.
You often have talked about things like letting stuff stew or feeding
your sleeping mind and you literally sleep on the problem and come up
with another idea, and I think there’s a version of that within a group
as well. bouncing ideas back and forth in a kind of virtual sense, and
that’s a very interesting overlap with something that I think is a big
part of the emerging best practices around remote work, which is
embracing asynchronous and some of that comes from this practical aspect
of like, hey, you’ve got people across time zones, so if everything has
to happen in synchronous meetings, then it makes it real tough for
people.
And so there’s a practical element of it, but I actually think that
when it does come to many types of the work pipeline and that early
stage of ideation is one piece of it.
There are parts that really benefit from real time live, energy, and
there’s other parts that actually suffer from that, that if you don’t
have the time and space to go off and have your own thoughts separate
from the group, the combined group idea is going to be worse than it
could be.
00:38:31 - Speaker 1: Yeah, this to me is very important, especially as
we get into muse for teams, again this is very caricatured model of
ideation, which is everyone gets into a room, you have a brainstorm and
out comes the ideas.
The reality is so much messier. You have individual to group and back
again, you’re bouncing around among individuals, you’re bouncing
around among different levels of fidelity. The ideas get mutated, even
corrupted, if they get passed from person to person.
Sometimes they bounce like all the way around the circle and come back
to you in a different form.
Style, there’s all kinds of wild stuff that happens and that full
process, almost like this pulsating network, right? With all kinds of
weird patterns happening is what’s really needed to produce good
ideas.
So the substrate, the tool needs to embrace that. And that’s one thing
that I think is doing pretty well.
00:39:18 - Speaker 2: Now it’s no secret that we’re gonna have a lot
of these kind of big ideas or counterintuitive insights or philosophies
behind what we’re building here with the collaborative product. That’s
also true, of course, with the personal tool in that element.
Many of those same ideas are obviously gonna come across like ideation
being a little bit being freeform or even messy, but one question that
came from someone on our Discord, that’s Antoine RJ Wright.
In his question he asked about tools, but I think the underlying thing
is that if you have a group working together and they have different
styles or different approaches, how do you resolve that? And so, for
example, we think that spatial visual, this nested board approach is a
great way to explore. is, but if you’re someone that prefers plain
text, top to bottom, don’t give me a bunch of fancy pictures. I’m
confused or overwhelmed by this kind of big open space, which is very
reasonable.
Different people’s brains work different ways.
OK, well, for a personal tool that’s fine because of course you can
just pick the one that fits your brain, but once you’re on a team, you
kind of all need to agree. about a tool but also working practices. So
to answer Antoine’s question, how do we see about trying to have a team
come together around tools if indeed when it comes to something like
thinking tools, it’s so personal and so about what fits with your mind?
00:40:47 - Speaker 1: This is such a fascinating question, and I’m not
surprised that it’s come from Antoine, one of our earliest and best
customers. I almost challenged the kind of framing that you had of how
do we get people who are currently using disparate tools to use a more
unified approach, which, you know, I’m sure is probably one personally
likes and approves. So the question could actually mean different
things. It could mean, how do we help the group converge on a tool or
set of tools, or it could be how do you manage the chaos and complexity
of people using different tools, and I think there’s different answers
to both of those, maybe we can take the framing of how do we get some
convergence. I have a couple of thoughts here.
One is a very powerful truism that I heard about management is people
don’t show up to work to do a bad job. It’s one of those that sounds
so simple when you say it, but it’s very easy to catch yourself
basically making that implicit assumption.
And so why are these people coming in to work using old tools and
there’s some reason, so you gotta have some curiosity about what their
context is, what their personal history is, why they think this is the
best way for them to do a good job. So a counsel curiosity there, which
is hard to take much further without additional context on the team, but
that’s one idea.
Another sort of management pattern that I might advise here is starting
with a single person. So often people present these leadership
challenges of, there’s this group, and I want the group to do something
different, I can’t group X. The thing is groups don’t do things,
people do things. So the way to start is to find one individual human
being and to convince them and help them have success with a new path.
And this actually has several important benefits. One is it forces you
to confront concrete details cause it’s easy to speak in abstractions
when you’re talking about the group.
You know, the group is using old tools, the group is using too many
tools. The group is using tools like, well, when you talk about what
Alice specifically is using and why, again, you’re getting grounded in
the details.
Another thing is that it’s much easier to convince a group when
there’s already one person convinced they become a sort of lieutenant
who could help you advocate for the tool and affect the roll out when
there’s often a lot of mechanical stuff that needs to happen. I don’t
know how well that actually answers his questions, but those were some
of the things that came to mind for me.
00:42:55 - Speaker 2: Well, I think this is why it’s interesting to
think about this question in the frame of, we have a bunch of Weird,
hopefully interesting, hopefully compelling ideas about what a group
ideation space could look like or remote first group ideation space
could look like, but you could imagine that there are some folks that
that resonates with and others that it doesn’t, and I think maybe
that’s OK, maybe they have again, their minds work differently or they
have different kind of motivations for how to hook into the work.
But part of the idea is that you know, if you develop ideas or part of
our hypothesis, if you develop ideas together as a group, you have
shared ownership over those ideas and then when you go to
implementation, you’re more on the same page in a kind of figurative
and literal sense, but then if different tools just don’t Suit everyone
on the team and now you just need to find some consensus around that.
I think there’s always going to be some potential level of friction on
that and some folks will just end up going along with tools they don’t
love or aren’t the perfect fit for them vibe wise, but you know,
that’s just what the rest of the team is using, so that’s fine.
And by the way, this is our Discord, which has been running for a while,
some great discussion there. It has been up until now just for pro
members. You get a link from your backstage pass, but by the time this
episode airs, it should be possible for anyone to join. So I’ll put a
link there in the show notes and pop in there and you can propose
questions for future episodes slash comment on this one.
Now another question from Discord is from Robert Stevens and he
basically asks, how do we think about hybrid in office and remote. Mark,
you had referenced earlier that we’ve had experience with all pieces of
the spectrum, so, what do you stand on the feasibility of that or the
techniques that work there, or maybe that’s the future that actually
blends the best of both worlds.
00:44:51 - Speaker 1: Yeah, it made me I actually have less experience
with this. I mean, everyone who used to work in an office has some
nominal experience of just didn’t go to the office one day for whatever
reason.
This one’s interesting cause I think it’s pretty easy, and I think
it’s likely that firms will evolve from the all local position into
this. This is the, OK, we can see after the pandemic that the whole
world didn’t stop, so therefore, Tuesdays and Thursdays, you can work
from home, right? But it’s kind of a one-way ratchet, like, not only
can you not Easily bring that back in, by the way, there’s a whole sub
thread on like the Wall Street firms trying to bring people back to the
office 5 days they’re having a really tough time.
But even more obviously you can’t bring a globally distributed firm and
say, oh, now we’re gonna do partially remote and partially local. It’s
kind of all or nothing to be able to have more than 0 days at a given
local office. So, I think there’s certainly a future to this. I think
there’s a lot by volume to this, of a lot of currently all or mostly
local firms are gonna adopt some element of working remote part of the
time, but I think it’s harder to see, yeah, existing highly distributed
groups coalescing around single locations, but I wouldn’t right off the
possibility. There’s also the mechanism of the summit, which maybe we
could talk a little bit about where you get this, but in a different
way. Which is you are remote part of the time, you know, maybe it’s 7
out of 8 weeks and then 1 out of 8 weeks you meet up somewhere, but that
place isn’t where you maintain your primary residence, right? It’s
some place that you pick off Airbnb.
00:46:21 - Speaker 2: Yeah, my personal experience with Hybrid, which we
did quite a bit of at Hiroku towards the end of my time there. was
trying to kind of plug remote people into an in-office culture was
really challenging.
First, you get into all kinds of just AV stuff, trying to like mic up
conference rooms and things, and we spent a lot of money, if I recall
correctly, trying to get the perfect setup there in the end, the thing
that worked best was for everyone to be on their own laptop with their
own headset, even if they were in the same room, for example.
And in that sense, what you’re describing, which is starting from a
remote first or distributed team kind of as the baseline and then you
come together in some location, whether that’s a co-working space or an
office pod or a team summit or something like that where you kind of go
from remote as the default and then Choose to gather at certain times
and places, and those kinds of places could be a lot. It could be an
office 2 days a week or 3 days a week, but that’s the kind of, I don’t
know if you would call upgrade or the escalation of both bandwidth and
cost to the individual people that come together and that your default
state is virtual.
00:47:31 - Speaker 1: Yeah, and now I’m realizing there are at least
two very different meanings of hybrid, which at least I didn’t
differentiate my answer, so I wasn’t even sure if I’ve answered the
original question correctly, but there’s hybrid in the sense of
everyone is on the same local remote schedule, or at least on some local
remote schedule, like everyone in the office 3 days a week and everyone
not in the office 2 days a week.
And there’s hybrid of 70% of people live in San Francisco and 30% of
the people live somewhere else.
So the former, I think there’s there’s quite a future for. The latter,
I shared a sentiment that that was very difficult.
Not only was it difficult, it can be a little bit corrosive, because if
people who uproot their lives to move to San Francisco might do that
because they enjoy and value the in-office collaboration environment.
And so, Adding the remote element can be a detraction for them, just in
and of itself, not to mention it’s incredibly difficult for the people
who are remote and the firm overall to metabolize that. So it can be
done. It’s just it’s really against the grade. Like, just to give you
one example, it’s very often the case that the senior. Leadership of
the company, you know, is coincidentally, all located in the HQ. It’s
often the case that a lot of important decisions and meetings don’t
have the correct conveyance via the remote channels like Zoom and Google
Docs or whatever, for people who are remote to fully plug into those
decisions. It’s kind of like our friend Peter Van Hartenburg’s
statement that diligence doesn’t work. Like, if there’s a way for this
stuff to go off the rails, it will. And so the only way to make it work
is like basically force everyone through the remote channels, even if
you’re in the office, go into a phone booth and dial into Zoom like
everyone else, that I think can work, it just gets kind of weird at that
point.
00:49:07 - Speaker 2: Yeah, it’s always funny when you see, you know,
some open office plan office with a bunch of folks sitting at their
computers with their noise canceling headphones on Zoom calls and sort
of begs the question of why we need these bodies together in the same
physical place.
And again, you could probably talk about hallway conversations and lunch
bonding and so forth, and the ability to in some cases, kind of upgrade
to meet in person, but yeah, I agree the synchronization on when you’re
going to be together and when you’re not. is quite key to success.
Well, maybe we could just take a moment then to briefly talk about the
mechanics. I don’t think we need to go too deep here, but we have a few
techniques that worked pretty well for us on the Muse team. You wanna
describe those briefly?
00:49:52 - Speaker 1: Yeah, maybe we can focus on the ones that I think
are a little bit more unique or differentiated versus, you know, write
stuff down on Slack so people can see it, you know, yes.
One is what we call core hours. So this is a set of shared hours,
usually about 3 hours where folks have overlap in their time zones and
we set the expectation that you’re available for more synchronous work
during that time. So that’s when the team planning meetings are
scheduled, that’s where you do a lot of real-time collaboration and
discussion.
And that way people know that there’s these kind of 3 hours where they
are expected to typically be online, but so are their collaborators and
so you can get all of your synchronous work done during that period, and
then you have the rest of your day, A for flexibility in your personal
life as we talked about as a I see benefit, but also to do
asynchronously your heads down focus work without distractions.
00:50:46 - Speaker 2: And the core hours concept was when we came up
with that Ink & Switch, and even we have a special notation for it. It
always sort of rubbed me the wrong way a little bit to declare a
particular time zone as the company time zone, that sort of implies that
that place is the center of the universe and everything else orbits
around it.
00:51:05 - Speaker 1: Yeah, unless it’s UTC, which just makes everyone
mad, right.
00:51:08 - Speaker 2: At least then no one is the center of the
universe, just everyone has to suffer.
But yeah, so we have this little notation, which is basically SOC, which
we’ve declared as noon US East Time, which also suits the particular
distribution of our team.
I suppose that if you had quite a lot of folks who are based out of
Australia or India or Singapore, you might want to do something a little
different, but for us it works at noon Eastern time, start of core, and
then we can declare something as, you know, most of the time you can
have a meeting, let’s do it at start of.
Or we’ll do the demo. Let’s start a core plus one, something like
that, and that works pretty well and that the expectation from team
members is that you’re available for synchronous work during that
time.
It’s not to say it’s back to back meetings, in fact, hopefully it
should not be, but the idea is during core hours, if you say, oh, you
know, I have a bunch of questions about this code review you gave me,
can we just jump on a quick programming session that there’s High
likelihood that they will be available, kind of in the same way with a 9
to 5 in an office, those are sort of these, you call them working hours,
that’s not quite correct, they’re really collaborative, synchronous
collaborative hours, and that you do the rest of your work on whatever
other time of day you want to.
00:52:23 - Speaker 1: I still remember very vividly when I was an
engineer at Hirou, and we had one day a week, I think it was Wednesdays,
maybe it was Thursdays, where I can make it Thursdays, yeah, I think it
was Thursdays,
00:52:35 - Speaker 1: where there were no meetings, and I would look
forward to that day every week because even one meeting in the middle of
your working block really throws you off as an engineer. This goes back
to the old PGSA which I’m sure we can link, but it’s so true. But the
nice thing about the core hours is you have a big block every single day
for doing a maker work, and it makes a huge difference.
00:52:58 - Speaker 2: Yeah, absolutely. I think it’s sort of a feature,
maybe an embrace the constraints type of thing that you have to fit all
your synchronous meetings into this more limited chunk of time, you
know, for me it’s around 2.5, 3 hours. I gotta fit all my meetings for
the day into 3 hours, and the rest of the time is essentially by default
open, and that means First of all, of course, getting to work when I
want to, when is the most productive and creative time for me, but also
it implies that, you know, if you think of a, say, a 7 hour workday, 3
hours are the synchronous time, well then you got 4 hours. That’s a
really solid block or 2 really pretty solid blocks of deep work and
focus. And yeah, that’s just an incredible thing.
Now you mentioned the summits previously, how do those work?
00:53:48 - Speaker 1: The intuition with summits was that you weren’t
gonna have enough very high bandwidth collaboration and relationship
development if everything was totally remote, if you never saw your
collaborators face to face. But we didn’t want to solve that by having
everyone in the company moved to San Francisco or whatever.
So the idea that we had, and I think we borrowed this from Inc and
Switch who’s been doing something similar for a while, is summits where
everyone works. Remotely and then with some frequency every 2 months or
10 weeks or whatever, the whole team meets at some location, which could
be different each time. It might be Mexico City or Philadelphia or Aspen
or whatever, right? You can kind of pick a location that’s convenient
for the whole team to get to, and then you do, you know, 234 days,
maybe, maybe it’s about a week with travel on either side. Where you
take advantage of everyone being in the same place. So that’s where you
might do things like, you know, relationship development, bringing new
members into the team, road mapping, making strategic decisions, making
big calls as a group, things like that can happen at summits, and then
you take that back for the next 8, 1012 weeks and build on that day to
day with your work, and then it starts a new. With the next summit, and
then also naturally leads into a sort of chapter rhythm, as we call it,
where corresponding to each summit interval, you’ve taken this heads up
moment, you’ve got a refreshed and clarified direction corresponding to
what we call chapters.
00:55:13 - Speaker 2: Yeah, I think the summit technique works really
well. It creates a natural rhythm. It kind of takes some elements of
what you get from being in the office together, those human bonding
moments, the gaining of ambient contexts, the culture transmission.
Sort of packs it all into this one week every 2 months or 4 months or
half year, whatever your rhythm is, which is probably not as good in
some ways, but I think it’s probably like 80/20, it’s probably 80% is
good for 20% of the effort. You still get all the value of flexibility.
You do have this challenge of travel, depending on where folks live, and
you need to be sort of able to travel, which is not totally possible or
easy for everyone, but sort of compared to moving someplace, it’s
certainly vastly easier and so you get to get a lot of that and by the
way you put it together with, yeah, going to an inspiring destination,
whether it’s an urban place, we’ve done a few cities, whether it’s a
rural place, we’ve done some nice nature retreats, and that’s
something about being in an inspiring creative space with folks that you
don’t get to see in person all that often, you’re doing these big Zoom
out, yeah, strategic, you know, what’s the next N months gonna hold?
What do we want to accomplish as a team, all that stuff, that that
combination of things is just a really potent brew.
I’ve come to quite look forward to them and I just find it to be a, not
necessarily a complete replacement for the in-office culture, but kind
of a parallel thing that serves a lot of the same purposes, better in
some ways, certainly worse in others, but also just has its own. Perks
and benefits that I’ve come to quite like, including, by the way,
we’ve talked about in how to have good ideas that in many cases just
being in a new place and a novel surroundings can spark new ideas, and I
even remember in many cases a particular thing that developed into a
major new product or feature or initiative that we had and I associated
with the place that we thought of it, because we are going to these new
places all the time for these kind of strategic big picture ideation
sessions.
00:57:24 - Speaker 1: I do feel that how often you do these will tend to
vary with the nature of the company.
Basically how many critical decisions you’re making, how often, how big
a chef they are, how many new people you’re trying to bring into the
company, the more of those things, I think the more you need to do these
with higher frequency.
So when we started the company, that’s almost definitionally when
you’re things are the most uncertain, you’re changing directions the
most, you’re making consequential decisions very quickly, you’re
bringing on new people.
We did them quite often.
I want to say once every 8 weeks. And then at the other extreme, if you
look at quite mature software companies, I think it’s typical for them
to do them once a year or maybe twice a year at a big company summits
with 2 to 5000 people or whatever, and neither of those schedules would
make sense for the opposite stage of company. It wouldn’t make sense, I
think, to try to find a company and then not see each other for a year.
I also don’t think it’s practical to bring 5000 people together every
8 weeks, right? So there’s tradeoffs involved and I think there’s a
natural correct cadence according to what your company is trying to do.
And by the way, you could, you can go the other way, you could say, you
know, we need to make faster decisions, we’re moving too slowly, we’re
being too static. I think you can go the other way and say, let’s shake
that up by getting together somewhere and almost try to spark new
decisions and new connections.
00:58:42 - Speaker 2: Completely, yeah, in a way, a summit is almost
disruptive, but in a way that can be positive when you need to shake
things up and reconsider and find what’s next, but at the wrong rhythm
or the wrong cadence would be disruptive in the negative way of you have
your direction, everyone’s executing their heads down and zooming out
or going into divergent thinking mode is at best a distraction.
00:59:10 - Speaker 1: Another thing that I’m realizing, just thinking
out loud here, is that summits are a useful forcing function.
So I think in general, and it’s quite a general statement, but it’s
better to limit software efforts by time than by scope, because when you
do the ladder, when you limit by scope, it just tends to go on forever.
This is an empirical observation I have with many years of engineering.
And with the summit, it feels really bad to carry through a line of work
over the boundary of the summit unless it’s a very deliberate long-term
project.
So you always find yourself wanting to wrap before a summit. And I think
generally that’s healthy and useful. And by the way, the urgency and
the cadence of that is gonna roughly correspond to the stage of your
company. You know, you can have one year efforts pretty easily if
you’re a very mature company, but that will kill you if you’re a
startup. So again, I feel like it works pretty well.
00:59:54 - Speaker 2: Yeah, that’s true. I actually think of the
feeling that we get on the team as the summit approaches and end of
chapter approaches is, OK, we wanna tie off loose ends, which is weird
to say because we’re gonna do this little summit and then be back at
work again, so it’s not like we’re not going to continue.
Working on the things we were working on before, but there is a sense of
wanting to have some kind of interim conclusion or have reached some
kind of milestone with all of our open projects so we can kind of clear
our minds to think bigger picture and then have sort of a fresh start,
even if in the end we end up picking up the sort of next iteration of a
particular project, which by the way, is also something I like just in
my personal work for taking holidays. which is if you’ve got that one
week holiday booked, you know, you kind of need to just wrap up your
open threads, your open discussions, get any meetings booked that you
need to do and everything else is just gonna have to be put off for the
future and it’s most satisfying, or maybe there’s just a natural human
desire to want to have a kind of sense of a conclusion, end of the
season, you know, wrap up some storylines, and then you’ll start some
new ones in the next season.
01:01:02 - Speaker 1: By the way, an important function of some, which I
didn’t mention is celebration. There’s something that’s very easy to
miss as a software team, to go work for years and years on something and
don’t celebrate your accomplishments. Again, looking back at my own
history, I very vividly remember the celebration that you put together
when we first launched production postgras databases on Hirokuro, kind
of the new version of that. And it’s a small thing, but it really
builds the energy of the team for picking up the next task. So something
to be sure to include in your summits.
01:01:31 - Speaker 2: Or maybe as a place to end. I think we’ve been
largely positive in talking about remote work, but I think we’re mostly
thinking about our own experience and our own little company on a
broader scale. Do you think remote work really is going to work in the
long term?
01:01:50 - Speaker 1: So I think this is a fascinating question, and my
position is that I think people need to have more humility and curiosity
about this. It is highly not obvious to me whether and how this is going
to work out.
And furthermore, I think it’s not really possible to know for a reason
that I can explain, but it’s so important and so consequential, and I
see a lot of, you know, basically flipping remote work partisaning in
either direction.
There’s so much to it. I would just encourage more curiosity and
thinking through all the different things.
Like one example that’s incredibly important is the coasting effect.
So, you know, a lot of people got in-person training, went to work at an
in-person firm for 10 or 20 years, developed networks in person over the
course of their entire life. They go remote for a year. It’s like this
works great, you know, I can work from anywhere now. I’m very
productive, my company is very productive. OK, yes, maybe. And how much
of that is due to the in-person momentum, basically that you built out
and that one is now coasting on, and how much could be replicated for
scratch.
So, as a thought experiment, if through the course of your entire
schooling, your entire training, the founding of your company, including
finding a co-founder, you never were in person, you were never at some
hub or whatever. And how well would that work? You know, I think that’s
a very interesting thought experiment, and I can go on and on about
this, but I think there just needs to be more curiosity and patience
about how this might actually play out.
01:03:15 - Speaker 2: Yeah, the early stages of the career is a great
point.
Even just thinking about kind of how individuals work together, you
know, we started Muse, me, you and Yula, but we had all worked together
in offices in person quite a bit.
You and I at Roku, me and Yula at Clue, and we already started with this
baseline of knowing and trusting each other and understanding each
other’s work styles in that way.
And then you add in the, yeah, you’re at the beginning of your career,
you’re trying to pick up tacit knowledge about how certainly a company
works, but also how people in your field work, what the customs are,
what the best work practices are, and there’s just so much of that you
can absorb by being in the same physical environment, and so, yeah, we
basically don’t know yet, and we certainly need more data.
01:04:05 - Speaker 1: Yeah, and I think we really owe it to people who
are earlier in their careers or changing careers to be mindful that
they’re in a very different situation.
Again, I think it’s very easy to say that this is all smooth sailing,
but basically leave out people in that situation. I think it would
actually be useful for for someone to go and do some investigation on
that.
Like I’m sure some people have looked into it a little bit, but, you
know, what if you just interviewed 100 people who are starting out in
their career, but have to learn everything over Zoom. I don’t know, I
feel like that’d be really hard, but one can only know empirically.
And speaking of empirically, the matter of firms being all local or all
remote or some mix is going to be determined empirically by their
success in flourishing.
As much as we might like to be able to work from wherever we want, the
bulk of the jobs are gonna be determined by which companies effectively
deliver software to users who value it.
And again, I think that takes a long time to play out. I think you need
5 or 10 years anyways. And you might even need something like 20 years,
and you might need much longer than that if you want to get the full
life cycle of you’ve kind of cycled through all the momentum from
previous in-person networks, skills, firms, and so on.
So my humble pie answer here is we might not know for like 40 or 50
years how this exactly works out, and in the interim, we should keep an
open mind.
01:05:25 - Speaker 2: 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. And Mark, I’ll see you in our virtual
office.
01:05:38 - Speaker 1: Yeah, a lot of I’m very glad this remote
revolution of sorts has allowed us to continue to work together even
though we ended up on different sides of the world.
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 luxuries of industrial research is that
you’re not bound to the traditional rigor and neutrality required of
academic research or just science in general. We’re allowed to have an
opinion. We had a number of people who are reviewing the essay comment,
what’s what the feelings, take this feeling section out, it’s not
defensible, and I felt like it needed to be addressed, because to me,
that’s the most important part.
00:00:30 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac. This podcast isn’t about Muse product, it’s
about the small team and the big ideas behind it. I’m Adam Wiggins,
joined by our guests today, James Lindenbaum. Hey there. And Shimon
Kjeski. Hello, both from Ink and Switch. And James, you and I have been
colleagues and friends for a pretty long time now, so I happen to know
that similar to Muse team member Yula, you are a huge cocktail nerd. Any
experiments in that area these days?
00:01:04 - Speaker 1: Oh, there’s always ongoing experiments. Yeah, I
recently decided to move to keging cocktails when you have a bunch of
guests coming over. I often will batch up a cocktail. So it’s faster to
serve, and you can also be really persnickety about, you know, micro
adjustments to amounts and things like that and really dial in the
recipe, and I decided to move to kegging the cocktails on low pressure
nitrogen, so they could be cold and pre-diluted and ready to drink.
It’s basically front loading the work so that I don’t have to do much.
I can actually hang out with my guests, but there’s always interesting
things you learn when you start changing things around like that.
00:01:40 - Speaker 2: And I do feel like the cocktail preparation is
part of the experience of being a host or something like that. I guess
if you have a lot of people there and then you’re doing nothing but
being heads down in your bar, then that’s not really being a very good
host, but there also is something to the, yeah, the prep tool, I guess.
00:01:59 - Speaker 1: Well, as you well know, I’m a bit of a
perfectionist. I enjoy having the time to really like try to perfect a
cocktail, really dial it in. And one of the ones I made recently, I
stole from this really awesome bar in San Francisco called Kona Street
Market, and there’s this drink called the Banana stand. It’s an
Arrested Development reference.
00:02:18 - Speaker 2: It’s the first thing that popped into my mind,
always money in the banana stand.
00:02:23 - Speaker 1: And it really blew my mind when I had it, and then
I’ve talked to the guys there about it, and then I’ve been just like
gradually trying to recreate it on my own and get it dialed in. But I
think we’re there, I think we’re close enough to perfection. We’re
certainly close enough that you would have made me ship it at this
point.
00:02:37 - Speaker 2: It’s a little inside joke there for the
listeners, James and I have a long time, let’s call it productive
tension, usually productive of, I like to ship stuff, and he likes to
make it perfect, and hopefully somewhere in the middle of that is sort
of an ideal place to be. And we’d love to hear a little bit about both
your backgrounds, maybe Shimon, you can start us out.
00:02:57 - Speaker 3: Yeah, sure. So, for the last 2 years or so, I’ve
been principal investigator at GSwitch and occasionally doing consulting
research projects. Before that, my background is I’ve been running a
small R&D studio and we’ve been basically working on unusual interface
problems, things like designing and building the Spola acting engine for
European Space Agency or some kind of like interface for exploring
machine learning for molecular synthesis. And before that, my background
was in actually creative coding. I was doing work on museum art pieces,
doing for interactive art, data visualization, stuff like that. What I
do also, other than work, I make a little bit of experimental music and
various computing projects for fun.
00:03:40 - Speaker 2: Yeah, I feel that the music experiments that you
do and performances sometimes, right? Also bleeds into your, yeah,
creative coding, artistic interfaces, a little bit.
And I think I personally take a lot of inspiration from the prosumer
world of like audio gear and the interfaces there that are sort of
designed to create art but also intended to be pragmatic, right? You’re
doing a performance or something like that and those knobs. You gotta be
able to grip it in the right way or whatever, so I feel like you often
bring your music world, electronic music world stuff, and you work in I
can switch, and I always enjoy that personally, but I’m also a person
with a little bit of an electronic music background, so maybe that’s
why it appeals to me.
00:04:21 - Speaker 3: Yeah, the word there is definitely a little bit
different and interesting, so I know if there are any UI designers
listening to this, I encourage you to just browse Pinterest for music
stuff. There’s a lot of interesting differences there.
00:04:33 - Speaker 2: And James, you and I have worked together for a
very long time, including perhaps most notably in co-founding Hiroku,
and we also created the In Code Switch Research Lab together with some
other great folks, but maybe you can fill in a little more of the story
there.
00:04:48 - Speaker 1: Sure, yeah, well, I have always been, as I like to
say, constitutionally unemployable, so I started a number of things over
the years, but yeah, most notably was probably Hiroku with you and our
other co-founder O Ryan.
After that, I found that there were a lot of people coming to me,
founders of developer facing companies who, you know, wanted help, and I
ended up advising and sitting on boards and whatnot, and eventually
starting what is now a venture capital firm called Heavy Bit, which
specializes in, you know, developer facing infrastructure kind of stuff.
And so I’m still there, I spent a lot of time there, though I’ve kind
of worked my way from being a founding full-time partner there to being
a more part time. Yeah, and then you and I co-founded the lab and can
switch, which is where I spend, let’s say more of my time these days.
I’d like to spend all of my time there, but, you know, there’s so many
things to do.
00:05:39 - Speaker 2: Well, let’s be honest, when it comes to paying
the bills, investing in developer tools companies is probably a better
gig than weird research.
00:05:47 - Speaker 1: Yeah, I mean, you know, the path to money is more
clear, that’s certainly true. It’s still enjoyable though, there’s so
much innovation happening on that front, it’s still intellectually
interesting, and there’s a lot of fun stuff happening there, but it
certainly feels a lot closer in than the weird stuff we’re doing at the
lab.
00:06:04 - Speaker 2: And you both recently published an essay on your
latest research project called Ink Base. Of course, I’ll like that in
the show notes, but can you give us an overview for folks who haven’t
read the essay yet?
00:06:14 - Speaker 1: Sure, yeah. So, in the lab, we have a research
track that is all about programmable ink, sort of a combination of doing
stuff on tablets, thinking about digital ink, and thinking about end
user programming.
And this project Inkbase, it was basically the 5th, depending on how you
count the 5th project in that track of 8 that we are now that we’re
currently working on project number 8.
Yeah, in that track, and we’re publishing this essay a little bit out
of order because we wanted to take the time and this one to sort of lay
a little bit more of the groundwork, sort of define what the problem is,
what we’re trying to do. So we spent a little bit more time writing it
than some of the write-ups of projects that came subsequently, like
Crosscut and Untangle. But yeah, we’re happy to have this out there and
have people, you know, start to grok what it is that we’re doing here
with this weird program of link stuff.
00:07:05 - Speaker 2: Yeah, so this whole track of end user programming
is certainly one that, I mean, you know, that concept is something that
even fed into Hiroku.
It was something that was a kind of founding idea that we knew we wanted
to bring into the lab.
The three of us worked on an essay titled End user Programming that kind
of touched on a history of that field and some light experiments, some
of the first work you had done with the Lapshaman.
But part of what I like about this ink-based project specifically is
this is taking the idea of sketches and trying to kind of take what do
we like about spreadsheets and the rough computation that you can do
there kind of on the fly interacting with the document in a way to take
advantage of the dynamic medium, but not something that’s writing an
app per se.
Certainly has much in common with, for example, potluck.
We had Maxson. Jeffreon just recently, but they were very focused on OK,
classic plain text and the searches, etc. and I feel like this is almost
a complete other take on that tablets, stylus, sketching, kind of very
loose and informal, but informal and programming are not things that we
normally think of as being combinable and indeed it is that for me, at
least observing this kind of track of research from the outside in this
specific project, it is that tension between the formality of
programming.
And the systems thinking and so forth that we want from our
computational tools and the looseness, sketchiness, I’m just figuring
it out, I’m not sure yet, messiness that is part of thinking tools,
tools for thought.
So I think it’s a very evocative idea to start with and then the
resulting project itself, which you can see some videos of in the essay
also is only further teases that.
00:08:49 - Speaker 1: Yeah, that’s one of the reasons we like working
with digital ink. I mean there’s a number of reasons, but one of them
is that it sort of forces you into this sort of sketching, informal,
loose, fast and loose kind of mindset, and It just underscores how not
fast and loose most of our programming capabilities are.
And so it kind of forces us to think about, you know, what are the right
affordances, how could we design a system that would let you stay in
that sort of frame of mind but still get some of the benefits of a
dynamic medium. This sort of weird analogy that was sort of the prompt
for the Inkbase project was, you know, we look at spreadsheets and I
personally am a huge fan of spreadsheets, as I think many of us are, and
I think about the analogy, you know, if you think about spreadsheets as
we have them today, as they compare to their analog predecessors, you
know, a giant pad of paper and a slide rule or a calculator, it’s not
just that modern spreadsheets let you do what you would have done with
the analog version a little bit faster, it’s that they actually let you
have thoughts you wouldn’t have had. Using the old version, because you
can see this dynamic model and you can get intuitive understanding of
how it works. You can play what if scenarios, it sparks new ideas. And
so, we think, OK, you’ve got the traditional sort of actual
spreadsheet, you know, the paper analog version, that is to modern
spreadsheets as sketching in a notebook is to Question mark, right?
Like, what is the thing that goes in that box? And I don’t feel like we
know what it is or have really seen it. And so, Inkbase was sort of a
little bit of a study or an experiment around that prompts. Like, what
would that thing look like? What would it feel like? What would it be
like to be able to work in that spreadsheet like way, but with ink.
00:10:28 - Speaker 2: Now I think a question that might be in the
audience’s mind is how this prompt that you just described relates to
visual programming, which visual programming is something where, yeah,
maybe it’s more accessible to the average person or requires less
programmer brain, less symbolic manipulation. Do you see it as related
to that world of things or is it its own beast?
00:10:51 - Speaker 3: So I have a little rant.
00:10:53 - Speaker 2: I forgive you that.
00:10:54 - Speaker 3: Yeah, that might be too early in the podcast for a
rant, but I don’t think a lot of these projects that people mention as
visual program are really visual in the sense that we talk about or we
think about, uh, things like, like not to taxonomize the whole field,
but there’s things like projection editors, maybe scratch comes to mind
where you have blocks of code that just snap together or maybe things
like Max MSP for musicians, which is Basically nodes and wires
interface. So, these kinds of interfaces.
Still require thinking in this very like abstract symbolic way. You just
manipulate the code, not in a text buffer, but on a screen, like moving
it around in dimensions. What we think about in this thread is more
about visual programming as a way of working with like actual embodied
objects that you can see on the screen and interact with. So you’re not
thinking symbolically, but concretely about the domain, the problem at
hand, and this is kind of the thread we’ve been following. So, In a
sense, both are visual, you could argue that code in a text box is also
visual, but the meaning of visual is kind of different, the way we think
about this and the way these sorts of projects think about it.
00:12:05 - Speaker 2: Right, when you think of one of those nodes and
wires, kind of visual programming languages or something like Scratch,
which I think is a great product for kids to learn to program, it is
really about sort of taking a conventional program and making it not
text, not pure text, but something that’s a little more gooey, point
and clickable. There’s a lot of value to that and there’s many domains
where that makes sense, but that does seem like almost a different realm
from I have the sketch and I want to bring it to life using the dynamic
medium of computation.
00:12:36 - Speaker 1: Yeah, there’s a really important distinction
between programming with ink versus programmable ink, right? So, you
know, what we’re not trying to do is help you write programs with the
use of ink. What we’re trying to do is just use ink, you know, for the
properties that ink has, digital ink, but also allow it to be dynamic in
the ways that you would expect from, you know, the dynamic digital
medium, and so, The programming is not the end, it’s the means to have
ink that does more interesting things than just, you know, sit
statically on the page.
You know, a lot of times we have these amazing devices and we have this
pen and all this computational power in the iPad, let’s say, but a lot
of the iPad apps that make use of that basically just let you paint
pixels on the screen with the pen. And it’s just, there could be so
much more there.
And that’s a big part of, you know, what we’re thinking about with
digital ink in general at the lab, and then with the programmability in
particular, you know, what if that ink could respond the way that a
spreadsheet does reactively to other things on the canvas, or, you know,
what is the nature of digital ink even at all, right? I think that’s a
question that we’re still kind of asking ourselves and doing studies
around, you know, what if it worked more like string that you could pull
around the page, or what if it worked more like paper clips, right? Like
a little wire thing. Where you, you drew it, but then it wants to retain
its shape. So when you pull on it or bend on it, it tries to retain some
of its shape so it preserves a little bit more of the intention or of
the movements of the person who made that mark, right? A fun prompt that
I like is thinking about digital ink as a byproduct of someone moving
their hands. It’s more the moving of their hands that’s interesting
and the ink is a byproduct. And if you think about it that way, then you
start thinking about totally different kinds of affordances and ways to
treat ink. So there’s a whole realm there that we’re kind of thinking
about that sort of intersects in this Venn diagram with sort of end user
programming and dynamic behavior.
00:14:27 - Speaker 2: I think you already teed up our topic there, which
obviously is programmable ink, and I always like to start with
definitions. I think we’ve gotten into it a little bit, but yeah,
you’ve mentioned digital ink, and I assume here maybe the first thing
that comes to mind there is I scribble on an iPad or potentially another
tablet and stylus, and yeah, some ink like marks appear on my screen,
and that’s it. Is that basically what you mean by digital ink or is
there more nuance to it than that?
00:14:56 - Speaker 1: Yeah, I mean, I think that working out that
definition is sort of part of the work that we’re doing that, you know,
I expect to take a while, so I, I don’t have a crisp answer on that.
When I say digital ink, yes, I’m mostly thinking of, you know, the
things that appear on the screen when you move a, you know, pen or
stylus around on an iPad or a a remarkable or, uh, you know, some kind
of device like that. But I think there is this interesting question of,
aside from those pixels, you know, what is it really that’s there? What
is ink in general and certainly what is the digital version? I think
those are really interesting questions.
00:15:29 - Speaker 2: And then, how would you define programmable link?
00:15:33 - Speaker 1: Well, you know, again, I think, or maybe taking a
very shallow stab at it with this ink-based essay, but, you know, when
we think about programmable objects or dynamic objects, we often think
about objects that they have some behavior, you know, they respond in
some way, or they change in some way, or they’re able to be changed by
some part of the system.
And so that’s mostly what we’re thinking about when we think about
programmable ink or dynamic ink is just something that is aware of its
environment and can be manipulated either by itself or by something
else, you know, on the canvas or in that environment, or even by the
user.
I mean, a lot of ink that you make in these tablet programs are It’s
sort of dead, ink, it’s difficult then to pick that ink up and move it
around, you know, some will allow you to have selections or drag some
things, but even basic things like scaling or deforming ink in a way
that’s smart, like a classic example is you draw an arrow from one
thing to another in your notebook, and then you wanna move. One of those
items around, the arrow doesn’t follow. You then have to manually move
the arrow yourself and reposition it and rotate it and scale it. And
when you scale that arrow, it scales proportionally, sort of naively,
and it no longer looks like an arrow, right? Or it no longer points in
the right direction or the arrowhead, you know, isn’t facing the right
way or whatever. And so, That’s a very difficult problem to solve from
a sort of computer science perspective, from just like a human doing
stuff on a screen perspective, it seems crazy that that doesn’t work
correctly. And so, we try to look for places where there is that strong
sort of dichotomy, where it seems like we’ve just gotten used to
something being a certain way, but it actually seems kind of terrible
from just a human experience perspective, especially when you get in the
context of tools for thought, where I think The tools have a really huge
impact on the thoughts that we have and the work that we do, and the
output of that work. And so these small differences or small bits of
friction, or small biases that the tools create actually are really
important.
00:17:31 - Speaker 3: I think it’s hard not to mention McLuhan at this
point, right? Like, first we make the tools and then they make us. I
think we really believe in this feedback loop of how the things you use
impact what you can do. And this is like a hope of being better at
sketching, being able to sketch dynamic models.
00:17:48 - Speaker 2: Yeah, maybe one way to think about the, it’s
called the current implementation of digital link, of which Muse, you
know, counts in with us, but I think it’s something we’ve thought
about a bit more than others, probably because I think it’s pretty
clear if you’re procreate, you know, you’re a pure art tool and it’s
just like you want nice brushes, so you can create a beautiful picture.
And maybe if you’re a diagramming tool, it’s really clear that it’s
important that your arrows and boxes connect to vertices on the thing,
and you don’t want to just like draw a rough circle around something or
underline something.
But one of my favorite small examples that I certainly hope we’ll
implement at some point is the idea if you highlight something with a
highlighter, and then you go in and like, type in that text, as the
highlight kind of stretch out the way that it would if you had selected
the text and, you know, right click, select highlight, something like
that. And that does get into the realm of, OK, how much do you want it
to like automatically detect what you’re doing and make inferences
about it. But if we do think of today’s digital link as mostly being
just a direct transliteration of well I could draw on a sketchbook
before, now I’ve got an iPad or a remarkable or a Android tablet and
that more or less looks like a sketchbook and I can load an app that
gives me a blank page that probably looks like a sketchbook and I can
draw things and yeah, maybe I have a few more tools for manipulating. I
can erase, I can undo, I can select and move things, I can duplicate,
that’s nice, but it’s a pretty direct thing, maybe in the same way
that the first word processors were essentially just, hey, what if we
had a typewriter on this computer thing? And it was only later on that
we started to get into much richer things like say hypertext, where you
could never, yeah, that concept doesn’t make sense in a tight document,
but once you’re in the virtual realm and the dynamic medium of the
computer, now you can do more, but you start with that transliteration,
and then over time you figure out how it can grow into something that
goes beyond its kind of analog roots.
00:19:39 - Speaker 1: Yeah, I mean, I think there’s a lot of shared
roots obviously between Muse and this track of work, you know, they have
kind of shared roots philosophically and some of the ideas of the lab,
and I think one of those big areas is when we talk about tools for
thought, I think there are a lot of questions around what is thought
work, right? What is thinking, what is thought work, what is the product
of thought work. A lot of our current tools today don’t really respect
the work product of thought work. You know, just a basic example that
I’m always ranting on is browser tabs. One thing that a lot of people
spend a lot of time doing these days in the course of thought work or
knowledge work is basically curating their own sort of research path,
right? Whether you’re researching, you know, a new toaster to buy or
doing real serious academic research or whatever. A lot of times it
starts in a browser and you click a bunch of links and open a zillion
tabs, and then you go through those tabs and you decide, you know, each
of these tabs, is it interesting or not, is it? relevant or not, you
close some, you leave some open. Maybe you open some additional tabs
from links that you see in there.
And that is actually work that you’re doing. And then you end up with
this sort of browser window full of tabs or multiple windows full of
tabs, and that’s your work product. You just spend a bunch of time and
used your brain to produce that work product, and you may want to come
back to that or do something with it, or pause or whatever, but most of
our tooling. With the exception of some interesting, you know, newer
experiments, most of our tooling does not respect the placement of those
windows or the locations of those tabs or the fact that they’re open or
not as your actual work product. And so, it’s treated as ephemeral, it
gets lost, it’s very difficult to manage.
When we make notes in a notebook, most sort of personal note taking apps
treat your notes as like this very important sacred thing that they
shouldn’t lose.
But to me, they have the same value, the same amount of work has gone
into them as, you know, these browser tabs that are open, for example.
And so, I think when we start thinking about what is thought work, what
is work product, we start to get into these questions of what would
tools look like that are more respectful of these different stages of
thinking. And to me, you know, rumination, I always thought was an
interesting word that was used around a lot of the muse idea, you know,
there’s this point where you’ve piled all your stuff, at least for me.
I think that there is a point where I’ve kind of gathered all my stuff,
laid it all out on the floor, and I just want to stare at it for a
while, and just like, move it around with my hands. And that’s a really
important step that most people can relate to, but it’s not really
supported directly as a first class thing by most tools. That are
available today digitally.
And I think similarly sketching, not the art version of sketching, like
you might do with Procreate, but sketching, as in thinking with your
hand, you know, sketching by putting marks on a page, whether it’s
words or drawings or doodles, or whatever, that is also, in my opinion,
a very under-supported activity. That is a really critical activity. And
the earlier you are in the process of having an idea, the more fragile
that idea is, and the more sensitive to your tooling. Those ideas are.
So, you know, imagine trying to do that thinking type of sketching in a
tool like Adobe Illustrator. It’s basically impossible because the
interface is designed for this high precision, high fidelity outcome,
and so, you just wanna like, stick a box in the corner and keep going,
but in order to make that box, you’ve got to select the right tool,
you’ve got to decide which kind of box, you gotta decide what kind of
corner radius you want. Does it have a drop shadow? By the time you’re
done with all of that, You’ve lost, at least for me, maybe this is ADD
brain, but I’ve completely lost the idea by then, you know, ideas are
like these little wisps that you’re trying to capture quickly before
they, you know, dissipate. And so the nature of that tooling is really
important.
00:23:09 - Speaker 3: Yeah, I’d like maybe to add two things to this,
both kind of tangential. Like one thing that we started talking about,
or maybe being able to like vocalize lately at the lab is this idea of
the same way we have like napkin math or back of the envelope like
mathematics, just figuring out orders of magnitude or something or
whatever. And interesting parallel is back of the envelope computation,
like how do you make these little interactive things with the same
approach of like roughly just hand waving at the thing. And another idea
bookmark maybe here is I lost it.
00:23:41 - Speaker 1: So you’re just proving my point.
00:23:45 - Speaker 2: Well, actually one thing I’d love to hear from
you, Shimon, is, you know, there’s been a number of projects in this
track. thinking base is certainly a very notable one, but you have
become pretty accomplished.
Obviously you were instrumental in creating the tool, but you also are
probably the most accomplished user of these various research tools, you
know, prototypes in the world, and indeed you’ve given some good talks
including recently. Strange loop where you kind of give live demos or
maybe they’re videos, I’m not sure, but in any case, it shows your
depthness with these different tools. So I guess I have to just ask
like, what does it feel like? What does it feel like to have
programmable link at least in this early stage?
00:24:26 - Speaker 3: The phenomenology of to use.
It’s kind of maybe hard to describe, right, like. It definitely feels
distinctively different to how you approach doing things on your
computer.
So like, for example, like one thing that comes to mind is an idea we
play around with crosscut, like a different paper in the same thread,
where we basically create like a little drum machine, just about
connecting a couple of dynamic objects together.
We have one that moves left to right. We connect the line that says
vertical, a box that finds things inside that box and that controls a
drum rhythm.
So working this way is completely different to how like, Create my own
drum machine if I wanted to, which I did a couple of times, which often
means I have to turn on my Max MSP or like Python or whatever, figure
out what is the correct like MIDI signal to send somewhere, basically
switch to this logical thinking, Oh, I will have like 16 steps, so
there’s an array that I need to care about now. And this array has
values in it and whatever and start thinking about very symbolically.
I’m trying to solve versus kind of the tinkering pre-college like
approach of the other things we’re doing.
And there’s a lot of parallels like that to me where I have a very
strong maybe programmer brain because I’ve been doing it for a while
where The way you approach solving problems in these tools is totally
different. Like, you explicitly tried not to have these things that feel
wrong in programming.
Like one example often comes to my mind is this spooky action at a
distance, where you say, oh, there’s this database over there. It has
like an abstract ID. I’m gonna grab that entity. And bound it,
whatever, like grab a property from it, and so on. Where in inkbase, you
say, oh, this thing the left, make it red. And that feels like very
concrete. You can see results of your actions immediately and you also
think it is very humane spatial way where like something to the left is
much more obvious that ID with like UI ID that has 64 characters or
whatever, right? Like there is a different way you use your brain and
think about things and that really left a strong impression on me.
00:26:27 - Speaker 2: I think that is somewhat how research works,
right? If you were starting with like a really burning pain point to
solve in the kind of classic sense, you’d really be starting a
commercial product.
Whereas research, I think is, at least for me, is driven by a sense of
how things can be different.
You see the capabilities of the computational medium, particularly maybe
emerging new technologies like tablet, you know, low stylus latency as
one example that I think was an inspiration for us. And you think about
how you would like computers and our computing tools to be, and you see
what the potential is with either the way technology is today or the way
it’s evolving, and you can kind of extrapolate out and think of some
end state. You you’re not really starting with a specific use case,
you’re starting with a vision of how things could be, so necessarily
use cases do get a little bit kind of backed in there. To me that seems
natural.
00:27:21 - Speaker 1: I also think we often have, at least for me, I
have a lot of use cases that I want to have a tool like this for, but
you need to have a pretty full fledged version of this tool in order to
actually carry out that use case and experience it, and we’re quite a
long ways from being there, I think.
And so, with some of these projects, we’re trying to see how one of
these use cases could be implemented.
In some of them, it’s really more about the feeling of the tool, and
Inkbase is one of those projects. We explicitly said with Ibase. OK,
we’re gonna kick the can down the road on, like, what is the right
programming model and what is the right interface for doing this
programming and all that, and we just want to get to a place where we
have dynamic ink that we have programmed, that’s on the screen that we
can interact with, just so we can get sort of a little glimpse, a little
vignette of that and see what it feels like. And I found the results to
be very compelling, but again, these feelings are very sort of subtle
and nuanced, and I think important for when you put them in context of
the way that the tools you use bias the results, I think the nuanced
differences and feelings of tools are really important, but they’re
also kind of hard to describe, and we’re kind of grasping at that in
this essay, one of the things we’ve started to talk about in the lab
when we think about the design of different tools, is sort of the quote
unquote natural grain of the tool. And we give a little definition in
this essay, we think about how tools, most tools, physical hand tools as
well as digital tools, have some sort of natural grain. A way or set of
ways that the tool can be used that are easy, fluid, efficient, sort of
encourages you to use the tool that way, and then there are ways to use
tools that are against that grain. And not that you can’t use them for
those things, but they just don’t work super well. Think, you know,
using a machete as a screwdriver instead of as a machete, or think using
Microsoft Excel to do artwork, you can absolutely do that. It’s just
kind of against the grain of the tool, and so a lot of times we ask,
what kinds of use, what kinds of feelings do we want to be with the
grain? Like, what direction do we want this grain to go? And for
example, With sketching and sketchy ideas, and early thoughts, we want
the grain to be very much encouraging you to keep thinking and not get
distracted with, you know, high fidelity thoughts, you know, is this
thing pointing to the other thing? Is my square, you know, a perfect
enough square, whatever. Another thing in that bucket in terms of trying
to develop a sense of what things feel like we’ve started to talk
about, I think this is one of Simon’s originally, is working with the
material. Sort of a phrase we talk about, which sort of evokes this.
More physical thing you might experience, like, like in art, if you’re
working with, let’s say, clay or some medium charcoal, it has a very
specific kind of feel, and certain things that it wants you to do and
certain things that are difficult to do, and just having your hands on
those materials kind of shape the outcome. You kind of just let the
material in some ways guide where you’re going. And I think that we
found that this ink base has a little bit more of that working with the
material feeling, which is what we were going for, where you’re
actually It’s sort of like, we talk a lot in the sort of end user
programming world about direct manipulation. You know, where you’re
working on something directly versus indirectly from some program on the
side or whatever. This is sort of a flavor of that, but even more
direct, where you’re not only directly touching the thing that you’re
trying to manipulate, but you’re actually being influenced by how it
feels. And ink, I think, is one of those things where when you interact
with it, the way you move it around, the way you create it, you’re
having something change color or change shape while you’re drawing on
it, and not after you finish your stroke, but live while you’re doing
it as a very specific working with the material kind of feel. And it’s
hard to put my finger on exactly what that means, or it’s hard for me
to describe exactly how your results would be different with that
feeling versus another, but it is quite distinct, and it’s something
that I personally am drawn to, and it’s something that I like about the
real world that I feel is missing in a lot of our digital tools. And so
I think part of this is a quest to obtain some of that in the digital
realm.
00:31:24 - Speaker 2: I support your quest.
The feelings or obviously you used that word a lot, how does it feel or
what feeling does it create or what things does it encourage in that
direction.
You had an interesting aside in the essay titled Research and Feelings,
which I’ll just read the first sentence of here. It says, perhaps
controversially.
At the lab, we believe, seeing what it actually feels like to play with
an imagined system is itself a valuable research result and goes on to
talk a bit more about that.
And actually I think that is an interesting, I don’t know, meta
learning or something like that site contrarian insight of the lab and
something we were able to do because we’re somewhat unique, not quite
academic, not Quite industry position, and I, I think it was Martin
Klepp and I feel like was the first one that called out when he first
started working with us, which is he said, basically the fact that we
are not constrained by the conventional definition of rigor, which is,
OK, we user tested this with 10 people, and with this P-value of
whatever they were able to complete the task in 2 seconds less. Which is
a very good reason science focuses on those kinds of very concrete,
measurable, rigorous findings, but I think that misses something huge in
the computing tool space.
00:32:40 - Speaker 1: I do think that’s a really interesting aspect of
what we do at the lab, and the lab is engaged in what we call industrial
research, which, you know, has been talked about a bit before on this
podcast, and To me, one of the luxuries of industrial research is that
you’re not bound to the traditional sort of rigor and neutrality
required of basic or academic research or just science in general. You
know, we’re allowed to have an opinion, we’re allowed to chase
intuitions, and I, in fact, put that into the essay as sort of a defense
or an explanation because We had a number of people who were reviewing
the essay for me comment on, you know, what’s what the feelings, like,
take this feeling section out, it’s not defensible. And I felt like it
needed to be addressed, but I wasn’t going to cut it because to me
it’s, that’s the most important part. So I kind of wanted to add a
little side note, defending having a research result that says something
about feelings. But, you know, I do think that that’s a schism that we
often see where in sort of academic circles. Oftentimes it’s about
novelty, and if an idea has been described before, then working on it
further is not interesting. It’s not an interesting result, and we
disagree with that. We think actually taking some idea for how something
might feel different or work differently and actually building it and
seeing if that is in fact true, is actually valuable. And sometimes we
do that and we are compelled by the result and it directs, you know,
further research, and sometimes it’s a disaster, and that’s
surprising. It doesn’t work and we learn things about why it doesn’t
work, and sometimes the results are sort of meh. You know, it’s, we
have these great expectations about how this thing could feel different
and then we make a thing and then it’s like, yeah, it’s kind of a
hassle and it’s really not that much better. And I think all that’s
really interesting fodder for understanding the nature of this problem
and where we’re headed. I also think conversely, on these sort of more
pragmatic sort of startup engineering, product oriented side of the
spectrum, people build things all the time, but they often don’t stop
to think for long enough about, you know, why they’re building them, or
what the nature of those things are, or what the most important aspects
of those things should be. You know, it’s sort of in the quest for ever
closer to to use. To research, doing what the users are asking for, you
kind of start to get away from these first principle kind of based
approaches. So at the lab, we’re trying to strike this balance between
this sort of overly pragmatic staring at your feet, just doing the next
step kind of thing, and this overly, you know, impractical sort of ivory
tower pontificating without actually seeing what the results are. We’re
trying to be somewhere in the middle. And I think our research hopefully
reflects that, and I think our talking about feelings is sort of part of
that quest.
00:35:30 - Speaker 3: So if I can expand on this just a little bit,
maybe from a different perspective, I think it might be on the metal. I
think maybe a common critique of HCI as a field is that you’ll get what
you measure kind. So if your focus is on making things that are
measurable, there’s a bunch of research that you just won’t do because
you, you can’t really measure it.
Like I think that’s why a lot of people think that’s the problem with
focusing on measuring mouse click speed or like how quickly you can get
to a task done or whatever. Which prohibits this very like exploratory
programming system kind of style of research, which is very hard to
measure because what do you even measure and against what else which has
its own problems.
The Second thing that comes to mind is we keep research logs as we work
at the lab on the mental level, and a lot of things in these projects
start with like this specific approach just feels correct or feels
right.
For example, one of the recent ones in the project we’re on right now
were about like measuring angles of things and someone made this example
of just making like a little thing that you snap to the angle and that
turns into a number that just felt good. That’s why we’re pursuing
this further and I think this following feelings at some level is, is
kind of correct of like leads to very interesting places, places that
academia would go to basically because, yeah, again, how do you measure
that?
00:36:49 - Speaker 1: Yeah, I mean, maybe back to this sort of the right
tool for the job idea. Most of the things that we’re trying to do with
these tools are certainly things that you can do with other tools,
right? You can make a sketch a number of ways, you can think a number of
ways, you can do calculations a number of ways. It’s more about You
know, sort of having the right context, having the right tool, bringing
the tool to the problem rather than the problem to the tool, those kinds
of things. You know, maybe a concrete example, just yesterday, I was
trying to get the square footage of a small space, and I made a sketch
of the shape of the space, and then I went around with my Little laser,
you know, measure and measured the lengths of all the walls. And I did
this as a sketch because it’s very difficult to walk around a room with
a computer and then put those numbers in and describe which wall those
numbers are associated with. It’s much easier to just write those
numbers on a sketch of the shape of the room. And it doesn’t feel right
to sit down and open up a graphics program and try to make a perfect
version of that room before measuring it. It really feels like a thing
that wants to be a sketch on a napkin or whatever. However, once you
have done that, I then need to break that shape up into a bunch of
squares and calculate the area, and that starts to feel like a
spreadsheet problem. Because once I do that, I often, when you measure
things in the real world, they often don’t entirely add up. You know,
the two segments of the wall on the left side don’t add up to exactly
the wall on the right side, and you kind of need to figure out if you
made a serious measuring error or if it’s just, you know, the world
isn’t perfect.
And so, you need to do this math, but then you need to check the math
against the other side, and you may need to make some adjustments. It
feels very spreadsheet like and that you want the machine to sort of
help you check your math versus Pulling out a calculator and doing these
things like 30 times. And so now I’m suddenly sitting here with this
thing that should be a sketch with some numbers on it, wanting to do a
little bit of math, which I want the sort of power of the digital medium
for, but my options are basically, I have to set the sketch down and
look at it while I open up a spreadsheet and do it in a spreadsheet,
sort of disembodied from the sketch where I can’t associate this set of
numbers being multiplied with this area on the diagram. Or I’ve got to
do it with a calculator, and I don’t get the power of the spreadsheet,
and it’s hard to check my math. This isn’t an important problem.
It’s not like a thing I can’t solve. It’s not a thing that people
don’t solve every single day. You can open up a sketchup, and then you
can put all the numbers in there, and it’ll tell you the area, for
example, but it just doesn’t feel like the right tool for this job. It
feels like you should be able to sketch this thing out on your iPad,
walking around with it, and then You know, do that math, and like, draw
the boxes on there yourself, and then, you know, do the multiplication
and see what it adds up to, and maybe jiggle the drawing a little bit.
That’s when you realize that, you know, they don’t add up. And I think
having tools like that, it’s hard to imagine exactly what we would do
with those things, but I find personally that I have uses, little use
cases like that every day. That I would reach for this tool if I had it.
And then you start thinking about situated software and the way
spreadsheets, one of the things I think is interesting about
spreadsheets is that often a piece of software evolves out of that
process. So you do that once and then you throw it away, it gets lost in
your, you know, Google Drive or whatever, but then you go to do it
again, and perhaps you want to, you know, rework some of that logic. An
example from my life is batching cocktails, which we we talked about a
bit earlier. You know, often when you want to scale up a cocktail,
certain things don’t scale linearly and you start doing a bunch of math
and you need to convert units, and it’s easier to weigh things than
measure volumes when you’re doing large amounts and Blah blah blah. So,
you end up building a little spreadsheet to do this thing and you throw
it away after you make your cocktail, but then maybe you go to do this
again a week later, and it saves you time to open that thing up and
duplicate it, and then adjust it for a different cocktail. And then
after you’ve done that 2 or 3 times, you might start to say, you know
what, this seems to be a thing I keep doing over and over again. Why
don’t invest a little bit of time cleaning the spreadsheet up, making
it a little bit clearer, making it More, you know, sort of input output
driven, so I can just paste in the ingredients and have everything turn
out the right way. Maybe I’m going to invest in adding a table that
does unit conversions from ounces to, you know, milliliters to weights
or whatever, and you eventually end up with this little piece of
situated software. And this is a true story from my life. I have this
thing, and then a friend sees it, and then they’re like, Oh man, I have
the same problem all the time. Will you send me your spread? Sheet so I
can start using it. And now we’ve basically made a piece of software.
And I think that’s a really important sort of flow that this is
something we call gradual enrichment in the lab for lack of a better
name, we’re still grasping at what the right name is for this, but this
idea that you start out loose and sketchy like you would on a napkin and
you end up with a piece of software, and at no point did you sit down to
write a piece of software. You just keep incrementally adding little
bits of behavior over time. And only as the payoff is obvious. You’re
only investing little bits at a time when you’re gonna get an immediate
sort of payoff for that investment. And we would like to see that same
gradual scale up with sketching, staying right in place where you make
that sketch, like having to stop and change tools to throw away the
sketch, move to your laptop, open up Illustrator or whatever, that feels
very discontinuous. And I would really like to be able to just do this
continuous thing. I think the reason this happens in spreadsheets is
that you’re doing the whole thing in the spreadsheet in the same place
the whole time with the same tooling, and I think you need the same
ability. To start with the sketch, stay in that sketch app, stay on that
device, indefinitely come back to it in the future, keep adding little
bits until you eventually have what is effectively a piece of software
that started as a sketch, but all stayed in that one place. And I think,
you know, for me, that’s the grand vision that we’re trying to get to
eventually, and figuring out what that looks like in each of these
steps. It’s sort of the aggregate of the research, right? You know, if
we look at the first step, the middle step, the end steps, some of the
end steps of this are a little bit more clear, you know, how do you add
complex behavior to a big complicated thing already in an app. We know
what that looks like. What we don’t know. Is what does it look like at
the beginning? You know, we, we, we know you, you start with a blank
canvas, you break some marks on there, and then fast forward a year,
you’ve got a piece of software running in this canvas app. What’s the
dot dot dot in the middle? And I think that’s sort of a set of
questions that we’re working on in this track.
00:42:52 - Speaker 2: That very beginning moment with software creation,
there’s a lot of ceremony, right? It isn’t, let me first make the
sketch and add a computation, for example.
And I would say potluck, another project I referenced there earlier, has
some of this coming at it from a text angle, but you’re sort of
starting with data that you collected or something you’ve written down
in some format, and then you’re adding bits of computation to that, and
the programming world is really built around the complete opposite flow,
which is I am writing a program now and I begin with, I’ll say. new.
I’m sure the kids these days have something sexier, but whatever it is,
you’re creating the new project in the IDE and you’re initializing it
and you’re setting up your unit tests or your models and setting up
your database schema and it’s actually quite a while and quite a lot of
super abstract programmer things before you get to the point of your
specific data and Or specific problem that you’re going to work on.
And of course I think is part of the reason we reference spreadsheets so
often when talking about end user programming is this really is one of
the few cases of successful commercial software or successful kind of
end user application where you really don’t start with, I’m going to
write a program, you start with, I’m going to enter my data, I’m going
to type in a couple of numbers and then you can add computation to that.
00:44:14 - Speaker 3: It’s interesting that you mentioned potluck and
not to put words in Jeffrey’s mouth. There’s been some interesting
cross pollination from this project and that inba. So historically in
based predates potluck and from a couple of conversations I had with
Jeffrey, some of the ideas around like spatial matches and thinking
about problem in a way where you find things on the canvas in a text
document and enhance them with additional dynamic behavior. It’s
interesting to see the parallels between these two projects, what I’m
trying to articulate maybe. And have the same ideas in the lab keep like
appearing in different places.
00:44:47 - Speaker 1: Yeah, potluck is a really interesting project, and
certainly all these projects have influenced each other quite a bit. I
think one of the most interesting things about potluck is this related
problem that you don’t have structured data when you’re starting to do
something in one of these tools, whether it’s something like Inkbase or
something like potluck, which is based on plain text. Whether you’ve
got a bunch of ink marks or a bunch of plain text, the goal with potluck
was, you know, to take something that you would otherwise The way you
would normally do something, like tracking your, you know, recipes or
tracking your workouts or whatever in a plain text file where there’s
no fixed format, and you can kind of enter them however you want, and
maybe you’re not 100% consistent about the way you enter those things,
and you stick little notes in there, use different units, don’t leave
the units off some days cause you know what they are. That’s not very
acceptable to a program, the way we normally do programming, but you
don’t want to have to clean all those things up and normalize them,
standardize them in order to be able to do something with them.
And same with, there’s this analog in Inkbase where you want to do
something like, I don’t know, you wanna attach something to the left
side of an object, but if you have like a squiggly mark that you made
with the pen, what is the left side, right? You want to align things or
snap them together, but, you know, the bounding box and the actual shape
of the rectangle that you drew are completely different. You didn’t
even close the rectangle, it’s not even a closed polygon, it’s, you
know, non-orthogonal, it’s probably not even a quadrilateral, whatever.
So, It’s a very similar problem where you need to be able to work with
semi-structured data or data that’s sort of evolving slowly from being
totally unstructured towards being totally structured.
Maybe it never gets to totally structured.
And you know, I think the spreadsheet is another example of this where
often you start out just throwing numbers in boxes all over the place
and it’s kind of a mess. And maybe eventually you kind of Things up
into columns and you make sure they’re all the same type or formatted
the same way or whatever. But spreadsheets are very tolerant of this
semi-structuredness. You know, if you sum a column of numbers in the
spreadsheet and one of them is text, it doesn’t break. It doesn’t just
break, the whole thing explodes, gives you a bunch of errors. Generally,
it just coerces that text into a number or it ignores that. It has some
Fault behavior where it still allows you to get an answer. And maybe it
shows you that there’s this weird thing happening and you need to go
fix it or whatever, but it’s very tolerant of this sort of looseness
and this semi-structuredness. And I think that’s one of the interesting
things explored with potluck is how do you do computations on a thing
where some of your ingredients are structured as ingredients and some of
them aren’t, or some of them have units and some of them don’t. And I
think there’s a very significant parallel to what we’re doing. In
Inkbase, and I think the sort of querying is one of the solutions that
we’re both grasping at in Inkbase, you’re doing spatial queries, you
know, find this thing to my left, find this thing inside of my bounding
box, find this thing that I, it’s overlapping with me, and in potluck,
you’re doing a text query, you know, find this thing that looks like
this, that, you know, has these letters or whatever, and then you could
do something and build on the results of that query.
00:47:40 - Speaker 2: And importantly in both systems, it’s a live
query, so this isn’t run a query, look at the results, then iterate. I
think you hinted at this earlier, Shimon talking about as you’re
drawing and as your dynamic behavior is being applied, so something like
turn this checkbox green when I check it. It happens as you’re going,
and if there’s a problem with the dynamic behavior, or if there was a
problem with your check that it didn’t land inside the box or something
like that, you’ll really see that right away. It’s not an iteration
process, it’s a just a completely live process.
00:48:15 - Speaker 3: Yes, interestingly, this also opens up a different
way of solving problems, right? It’s like, You could fix your program
so it catches the check mark a little bit off the side or whatever, or
you could just wiggle it and move it into the checkbox because it will
turn green as long as it’s like as quickly as it matches or finds the
solution or whatever.
Like this way of basically seeing responses from the machine as you
interact with it, like promotes this different way of solving problems.
You don’t always have to think in this very programmary way, you can
feel this very like loose, sketchy vibey way where I’m just gonna
wiggle some things until the machine does what I, what I wanted to do.
00:48:52 - Speaker 1: Yeah, we have a little saying on that team, just
jiggle it a little bit. You know, it’s sort of like the old fix the TV
reception by banging on the side. It’s sort of like, uh, just jiggle it
a little bit.
But it’s a really interesting interaction because, you know, you do a
query, let’s say you’re trying to recognize the shape and it doesn’t
recognize that shape. You could try to rewrite the recognizer, but you
could also just like jiggle that line segment. Little bit, so the path
looks a little bit more like what it’s looking for. And now, bam, it
gets recognized and the thing starts happening.
And this does lead into a way of solving problems.
We were just the other day talking about this little sort of geometry
problem. It stems from a real world use case where you’ve got like a
counter sunk hole and you’re trying to figure out what angle the hole
is at, so you can order the right screws with the right angle screw
head.
And it’s a similar to my example of the area of a floor plan. You sort
of draw the thing and take a couple of measurements, but then you need
to do some trigonometry to figure out what the angles are. And you’ve
now got this sort of semi-structured information where you’ve got a
sketch, which is not the scale, and you’ve got some numbers which are
correct, and you’ve got to do a calculation, and there’s this question
of, you know, different ways to solve that problem.
One is to just do some math on the side. Next to this drawing, but
another is to actually attach the functions that take, let’s say, the
angle, you know, read out the angle of a sketch of a shape, attach those
to your sketch, and then manipulate the sketch until the lines are to
scale. Basically drag the lines around until the computer says that they
are the lengths that you measured. And then you will know that the angle
is correct.
It’s a very different approach, but it feels very natural, if you’re
working sort of with pen in hand, and you’re just kind of working in
this sketchy way, and you can sort of just jiggle this around. Or
there’s also examples that Simone demonstrated from the Untangle
project, where it’s looking for matches against things, and sometimes
it doesn’t catch one, and you just kind of jiggle the model a little
bit until it does, and then you move on, and it’s just a very
interesting way of working.
00:50:44 - Speaker 3: So this is maybe an interesting drawback to when
we started talking about feelings, which is a lot of these interesting
ways of using these things like are like second order, basically, you
have to working in some way, you start interacting with it, and you
realize that this is the way to do something in it, which is not a fault
I would have one step back, right, without working with the material,
working with the concrete thing that feels a certain way.
00:51:09 - Speaker 2: And wasn’t there also a concept in another
project in the same research track around the bidirectional connection,
that is to say in the sketch example there of like you have a number and
you have a line and you want to make the number and the line the same
size, and typically in programs you have a one way flow.
I rate the HTML and that gets rendered by the browser. I can’t scribble
on the screen in my browser and have that get reflected back in the HTML
code to take one example.
And there’s, I think, a world of bi-directional linking research that I
think you folks did some with, and some of the prior argue list for
Inkbase as well includes apparatus, now there’s cuddle, which I think
was a good example of this of trying to make it so that you have these
two ways to represent something, the line and the number, for example,
and that you can change either one and they each update each other.
00:52:03 - Speaker 1: Yeah, I think it’s a really interesting way to
work, and it feels very natural. Things that only flow one direction
feel a little bit strange sometimes.
You know, you imagine you draw this little sketch of, let’s say, a
triangle, and you write some numbers from your real world measurements
on there, you then tell the system this line segment is, you know, 27
units long. Well, what happens, right? Are you asking the system to make
that line 27 units long, or are you asking to just leave it alone, but
think of it as 27 units long, and then what happens to the other lines
on the page? Are you rescaling the drawing based on that line, or are
you mixing structured and unstructured data? You know, in spreadsheets,
spreadsheets obviously are very one directional in their flow. Things
get very confusing if you try to, you know, sum numbers and then change
what the sum result is and have that back propagate into the column. But
it also can be very powerful, and the number of people have made
bidirectional spreadsheets, which are quite interesting to play with.
But in this case where you’re associating sort of some freehand work
with some numbers or something else structured, it feels very much like
they should stay in sync. And you should be able to edit either place.
It feels very strange not to be able to change your drawing that you’ve
made, or not being able to change the number that you’ve associated
with it.
So it feels almost necessary for it to be bidirectional in order to not
feel like you’re constrained arbitrarily by the tool.
But then you get into these interesting questions of, you know, you’re
creating error in the system when you change one of those things, and
what do you do with it? Do you push it, do you back propagate it to the
other side? What does it mean to change a drawing to match some numbers
that you put in there? And I think those are really interesting
questions, and and even just exploring the affordances, you know, what
kinds of UI elements do you want to have on the screen for doing that
sort of thing is a really interesting question and a sort of focus of
work for us.
00:53:51 - Speaker 3: Yeah, and to add to that, this way of thinking is
maybe very foreign to software developers like discovering these
techniques or reading about them, like definitely felt very alien at
first to me. It definitely feels interesting and more correct to work in
this meeting where you have two representations for a thing to be able
to manipulate each one of them.
The problem is, of course, in the details and this leads to. Some very
strange artifacts, a lot of technical problems or things like doing a
lot of calculations on these values.
Not everything is clearly solvable backwards in a way that feels
natural, and then you start thinking about how do I adjust my
calculations so the system does the thing that I wanted to do. And at
that point, you’re lost doing the abstract symbolic thing again that we
want to avoid. So there’s a lot of dials that we need to turn in proper
ways for the system to make sense.
00:54:40 - Speaker 1: One of our early projects in this track was called
Rectoverse, and it was a relaxation-based constraint solver, and, you
know, you’d put things on the canvas and then you’d specify these
constraints, you know, I want this thing to be next to this thing, I
want these things to be the same width or whatever, and then you could
interact with the model live, and the constraint solver would try to
maintain those constraints, and it often felt in the beginning, like,
You know, the classic tale where there’s a genie in a bottle and you
get 3 wishes, and every time you wish for something, you technically get
the thing that you wished for, but like everything else goes wrong. It
sort of felt like that where, you know, it’d be like, oh yeah, they’re
definitely the same length, but it did it by making the width of one of
them negative or you just like took it off the can. It made me get a
massive, you know, X value that took it off of the canvas or whatever.
And so it’s like technically, yes, you solve the problem, but that is
not what you want. And so then you have to be able to add more
constraints relatively easily and quickly to sort of coax the machine
into where you want it to end up sort of like giving hints to the query
planner and SQL or something like that. And that’s also an interesting
way of working. And it can sometimes feel like the right tool for
certain kinds of problems, but if you end up having to specify 47
constraints just to like keep two things, you know, next to each other,
it starts to not feel productive or ergonomic. So there are a lot of
different approaches to how you specify computation. And you know, that
was a constraint-based system, inkbase, we intentionally sort of punted
on thinking about that problem and so we just implemented a Lip
interpreter inside the iOS app, which is, you know, clearly not an
ergonomic thing to do, but it was pragmatic for us and so it was a very
specific implementation of dynamic functionality, but it uses sort of a
data flow like thing, sort of like in a spreadsheet where it’s
declarative and reactive. And then Crosscut was an attempt at sort of
going far afield on how else you might specify the programming model,
and it was sort of this wires and boxes way to sort of connect value
between different elements on the screen, and this idea of meta-inc
versus ink and specifying sort of dynamism with meta-inc, and then the
regular ink was sort of concrete ink, and then untangle, another project
in this track was a totally different way of looking at it using You
know, sat solvers to basically specify a set of conditions that needed
to be met, and then let the system figure out whatever permutations it
can come up with that will meet those constraints. And sort of one of
our conclusions from Looking at all these different things, when we
started out on this track, we were hoping to find the one true way, you
know, the one correct way to do computation that makes sense in this
environment. And what we ended up, you know, discovering, perhaps
unsurprisingly, is that there is no one best way, and there are a lot of
different ways, and some of them are better suited to some problems than
others. And so we’ve sort of concluded that you’re going to need to be
able to approach any problem, any use case you have. With different
kinds of computational strategies or engines or whatever, mental models.
And so now what we’re really working on is a nice substrate in which
you can combine different kinds of computational model, you know, bring
in the one that makes sense, you know, you have a use case, you have in
your mind an easiest way to solve that problem with tools that you know,
you need to be able to just bring that tool in and do it and have those
tools be able to interoperate. And so that’s a big part of what we’re
working on now.
00:57:57 - Speaker 2: And I’ll link the essays to the projects you
mentioned, which have been published, you mentioned some either things
we haven’t published yet, or in some cases we may never have an essay
for sadly, we don’t manage to get to an essay for every project we ever
do, since often writing the essay is at least as much work as doing the
project itself.
00:58:17 - Speaker 1: That’s right. Ink-based, crosscut, and untangle,
there are all essays for Rectiverse is a very old one, for which there
isn’t, and I don’t wanna make any hard promises, but I’m pretty sure
we will have a solid essay for the current project we’re working on.
00:58:30 - Speaker 2: Excellent, yeah, because I do feel that certainly
for Muse, you know, if you look at the progression of research papers,
which included one that I had written as a medium post, wasn’t even
really a research paper, just talking about kind of the tablet as a form
factor, the capstone project. And eventually we have them use paper and
you can see these threads that start to come together and they’re
rougher and rawer. Not to say that there’s one output, as you point
out, there’s these different tracks which may all be fruitful and cross
pollinate with each other and so forth, but in some cases, it’s not the
single essay, but indeed the progression of them, for those that have
the patience to read multiple 5+1,000 word essays on a particular topic.
00:59:13 - Speaker 1: It’s a lot of words. I think the length of the
essay is inversely proportional to our understanding of the problem, so,
hopefully they’ll get shorter as we get smarter.
00:59:25 - Speaker 2: Now another thing that I do think makes Inkbase
and a few of the other projects in the track that you both have worked
on stand out relative to some of the other examples we’ve given here is
the embrace of the tablet form factor. And of course we talked about
digital ink earlier. I’m curious how you both see the tablet as being
important or not to this. Kind of realm of research, or is it that it
really is about the digital ink and so you could kind of do that with
like I don’t know, Wacom tablet connected to your computer, that’s
probably fine, or is there something really to that form factor that is
very sketchbook like and you see the ink appearing under the stylus, or
is there something else altogether? How important is the tablet in all
this?
01:00:08 - Speaker 3: So I can start maybe with the meta level, which is
one of my favorite quotes from Monolike is, I won’t like, won’t give
it for per word, but what he says is to be really creative, you need a
lot of constraints. And he often chooses like one synthesizer to make a
new song or whatever. And then here, like the tablet is a very hard
constraint. Like it has a lot of interesting properties. It’s like a
page size, it’s very human scale. You have the stylus and fingers as an
evil mechanism.
All of that is like a double-edged sword, right? Like you’re so
disconnected from what you learned about keyboards and mouse and
pointers and whatever that you have to kind of invent everything from
scratch a little bit. And that is both like very good, I think for
research, right? Because it opens up this new way of thinking about a
specific fields, but also very hard because at the same time, we’re
trying to figure out both with this and also how to do things on it.
01:01:03 - Speaker 1: Yeah, to me, the jury is sort of still out on the
tablet form factor, but there are some compelling aspects of it. I mean,
we have a whole series of weird hypotheses at the lab about, you know,
form factors and in HCI specifically, I do think that for me, I’m
really fascinated with hands. I think human hands are really
interesting.
They have an incredibly high number of degrees of freedom and we have
large portions of our brain sort of devoted to using them without
interfering with our thinking.
And so, you know, outside of our sort of visual cortex, I think our
hands are sort of the highest bandwidth connection between our minds and
the world. And right now we don’t, in my opinion, make particularly
good use of the size of that channel when we’re just sort of like, you
know, tapping on a keyboard or pointing at something on a pane of glass.
And so getting at more of that richness of interaction with our hands is
really interesting to me.
I think holding a pen is in some ways an improvement. It doesn’t
obviously open up that entire channel, but I think holding tools in your
hand and doing things with them is a higher bandwidth modality, and
we’ve done some experiments with having multiple kinds of tools that
you can use to interact with a tablet at the same time, you know,
multiple pens, straight edges, knobs, you know, whatever. There’s a
whole sort of tangent on that. But I do think having pen in hand and
working is an interesting and compelling way to work.
I also think some of the things that were exciting to me about the
origins of muse in the lab, for example, you know, I’ve always loved
the idea of being able to use both hands at the same time. It has always
seemed strange to me that most of the touch interfaces. And even the
APIs for those interfaces are not really designed for using more than
one hand at the same time, or using a hand while using a pen, which is a
very natural thing to do. We do all the time in, you know, the real
world. And so, a lot of our early lab experiments in that track were
around just seeing if we could do that even with the existing hardware
and software, and turned out the answer was yes, and it was really
compelling.
To have that feeling of using both hands and felt very freeing, just
turns out to be quite a pain in the butt to do, because it’s sort of
against the grain of the APIs, as you guys well know at Muse, and I think
you’ve done a lot of hard work to retain some of the aspects of that,
and then I think there are aspects of it that are only viable in a
research setting because they’re not reliable or Apple doesn’t want
you doing them that way or whatever. But I think that’s really
interesting, and so that’s to me, one of the reasons the tablet is
interesting is that it’s a way to have the pen in hand. I do think
it’s critical that you have the visual feedback, right? As you move the
pen along the screen, something is happening on the screen at the
location where the pen is. We’ve experimented with Wacom tablets and
other kinds of, you know, stylus-based input tools where your hand is
doing something somewhere and where you’re looking is somewhere else,
and it completely breaks the high bandwidth interface between your brain
and the real world, I think does not really tolerate that very well. And
so, I think that’s one of the reasons we like tablets.
Another is the portability. You know, I have this pet theory that like a
drafting table is sort of the ultimate correct form factor for like a
personal sort of thinking station.
Part of that really has to do with the ergonomics of the human body and
like the length of the forearm, you know, you want something that’s
sort of the forearm radius, you know, size. But the portability of the
tablet, I think is really important. I think that, as you guys agree
with it, Muse, you know, thinking and creativity requires sort of moving
around a lot of times, going somewhere, walking around, sitting at a
coffee shop, or taking the device to the place where the problem is. You
know, walking around the room, taking the measurements, which is just
not possible with other kinds of form factors, and I think, you know,
the phone or the really mini tablet is maybe not big enough to really be
able to hold and you have enough screen space, enough canvas to make
marks. So the tablet kind of ends up being in this interesting
intersection.
But most people that I know who are sort of accomplished makers, when I
talk to them about tablets, they all basically say, yes, I have one,
it’s in a drawer. Or somewhere. I go through, you know, phases of using
it and not using it. And I think that’s really interesting that we have
this incredibly powerful device with this, you know, stylus that seems
to have so much potential, at least on paper, but then people often
don’t really find meaningful uses for them.
And there are people who do their whole life on the tablet, but when I
look at their workflows, it seems a bit strained. Like, you have to be
quite dedicated to really do everything on a tablet, I think. And so,
one of our sort of prompts at the lab is sort of hypothesis is maybe
this tablet is really great, and we just don’t have the right software
for it yet, but the UI, the UX, the mental model for working with it
just isn’t quite right yet, and that’s why we spend a lot of time with
them at the lab.
01:05:49 - Speaker 2: Well, it’s all very exciting research and with
each subsequent essay we fill in more of the picture. Where do you both
see maybe the medium to longer term future here, which includes maybe
something practical like when can I get a usable production app to do
the floor plan sketch problem you previously described there, James, but
maybe also just more broadly, what is the long term direction, what do
you hope to get out of this? What can we hope to see in the future?
01:06:17 - Speaker 1: I think it’s a really interesting question, you
know, people often ask us, when can I get a version of this to use for
myself, and we in the lab, in fact, would like to have versions of some
of these things to use on a daily basis. Most of them are sort of
prototypey research experiments that are not very well suited to real
use. I think we are working in the direction of things that might
actually be able to be maintained and start to accrete features and, you
know, be usable.
One of the other luxuries of the lab is that we don’t have to think too
hard about, is this a thing that can make money? Is this an app that
people will buy, Is there a market? How much will people pay? We get to
not think about that at all. We do care about whether we’re solving
what we think is a real problem or whether there’s a real context of
use, you know, we care very much about that. So, I think our primary
motivation is to understand the nature of the problem so that we can
work towards some various solutions which might eventually result in
products or software or, you know, maybe if we talk enough about the
nature of the solution, lots of people will make software and that’s
fine too.
I think with this specific track where we’re headed is, you know, the
current project we’re doing now, which is sort of code named Habitat.
It’s the first one where we have spent a bunch of time investing in the
underlying infrastructure, you know, sort of the substrate for the app.
You know, normally, every time we do one of these projects in this
track, we sort of start from scratch from first principles, what’s the
right set of technology stack, what’s the right architecture, what are
the right things to use to build this, and That’s important to not be
arbitrarily constrained by your technology stack, but now that we’ve
sort of converged over time on sort of one stack that we think is
correct or the best, we’ve started to be willing to invest in building
sort of a shell of an app that we can then use for multiple projects. So
we’re now investing in Building a thing that we hope will be reusable,
and that is sort of the first step towards being able to actually build
on top of previous projects with future projects, and be able to
actually start to create features that stick around, and also invest in
some basic things we don’t always have. Time for during research
projects like, you know, persistence working correctly, apps not
crashing all the time, fighting against the constant bit rot of, you
know, Apple’s API changes, etc. So, as you guys are much more
intimately familiar with that Muse. So, I think we are headed in that
direction, but I think we’re still sort of in the early days of
understanding what is it that this thing is for, and therefore, what are
the most important features that we need to build. But we’re headed in
the direction of dog fooding some apps for ourselves inside the lab, and
then hopefully if we can get to a place where that works, we can sort of
expand the use outside of the lab. But yeah, that’s kind of where we
are now is just sort of thinking about interchangeability of these
different programming models and starting to invest in. Nicer and nicer
ink engines, for example, which is a thing we often punt on as well, so
we can spend some time on performance optimization, that sort of thing,
all in the name of being able to get a true sense of what it feels like
to use one of these tools.
01:09:31 - Speaker 2: Maybe to close on the feelings subject again,
since that seems to be a theme here. I think the question of, you make a
prototype, you know, we usually time box things to some pretty small
amount of time, and when you’re, as you said, starting very blank
slate.
And then you’re getting to a usable thing in a month, 2 months, you
know, it’s not a lot of time, and you always have this question of if
the feeling is met or it’s not quite clicking, or it’s not quite able
to show that it could fulfill the vision that maybe you had for in the
beginning, is the problem that it needs a little more effort to be
better, because indeed, even the greatest painting in the world, you
know, You look at that very early line sketch that sometimes you can see
under an X-ray on the canvas or something, no one would be moved by
that. No one except the original artist understands what that means, and
you have to get it to a certain level of fidelity or a certain level of
completeness before it makes sense. And when we’re trying to kind of do
this real time iteration of we have an idea for a thing that we think
could Work and indeed feel a particular way. The thing we may doesn’t
feel that way is it that we just need to do a little more in this
direction, or is it the direction is wrong and it’s just a constant
judgment call. I feel part of the way we’ve hacked that is just the
time boxes where we say, well, we’re going to try this direction for
this period of time where a period of time is weeks or months, but not a
long period of time, and then we’ll go back and kind of start a new.
01:11:01 - Speaker 3: Yeah, I think one of the things that maybe is
obvious in retrospect that we discovered with the approach of very
aggressive type boxing is that the starting anew to get to a specific
point where the thing starts to look like something takes a lot of
effort and time.
And I think this is one of the things we’re trying to solve with this
project, like, can we move that effort. Outside of the project. So you
start with a position where you already have some reactive ink on the
page and can start building in that medium versus coming up with the
whole stack of functionality just to get to a point where you actually
start your research project and it’s like 3 weeks left of the 3 months
that we have.
01:11:40 - Speaker 1: Yeah, I mean, I think there’s sort of a question
of, are we on the right track, right? Are we on the right track, and if
so, then if only had a couple extra features, if only it was a little
more performing, if only whatever, it would be great. I mean, I think
there’s no way to know. I do think it’s sort of a follow your
intuitions, follow your nose kind of thing.
But I do think one of the signals that I look for is at the end of a
project.
And especially this sort of interstitial time between when a project
ends and we’re sort of wrapping up the essay, and when folks are
thinking about the next project, you know, sometimes we finish a project
and it’s sort of like, we summited a big mountain, and everyone’s
like, well, I’m glad we did that. Definitely don’t want to do that
again. Let’s maybe go over in this other direction.
And other times people are like, man, that was so great. I’m really sad
to stop working. I just all these things. It feels right at my
fingertips, just out of reach, these things that I wanted to add that
would make it better, and there’s a lot of sort of momentum and desire
to keep going. And I think that sort of indicates whether something was
interesting but weird sidetrack versus maybe on on the main path.
And I think we’ve increasingly been starting to feel like we’re more
on the main path in that.
We have a lot of folks who have worked in these various tracks who are
just, their excitement seems to be going up, and their desire to keep
working on it seems to be going up, and our desire to do projects that
are sort of follow-ons to the previous project versus let’s break new
ground, go in a different direction. There seems to be more convergence
happening. And, you know, that doesn’t necessarily indicate we’re on
the right track, but it certainly feels that way, and I think we’re
gonna focus a little bit more on going further down this path that
we’re on, rather than finding new paths, which is sometimes a mode that
we’re in.
So, yeah, we’ll see what happens. Stay tuned.
01:13:26 - Speaker 2: 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 muapp.com. And James Sermon, thanks for stretching our
minds with what might be possible with a different way to think about
using the dynamic medium of computing and digital ink, and very excited
to see what comes next.
01:13:48 - Speaker 1: Thanks for having us, always fun to chat. Yeah,
thanks.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: We can do the basics that Spotlight can do, but
also much better. We invested a lot in the speed to make it faster to
launch. We invested in file search to search files in a more predictable
way. And then when you have those basics, then there’s the question,
what else can you bring to this so you can start navigating and
controlling your computer in a new way.
00:00:26 - Speaker 2: Hello and welcome to Meta Muse. Used as a tool for
deep work on iPad and Mac, but this podcast isn’t about amuse the
product, it’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. Joined
today by Thomas Paulman of Raycast.
00:00:43 - Speaker 1: Hey there, happy to be here.
00:00:46 - Speaker 2: And Thomas, I understand you have some travel
coming up for you and your team.
00:00:50 - Speaker 1: Yeah, that’s correct. So yeah, we had Raikas, a
fully distributed company, but once a year we get together with the
whole team and it’s gonna happen soon. So next week, we’re gonna go
all to Greece, having a good time there. And we really enjoyed it. It’s
the second time we do it. The first one we did was a huge success. It
was especially the moment when the pandemic came a little bit to an end
as well. So it was really good for everybody getting there. It just
makes a huge difference as a remote company seeing each other in person.
00:01:19 - Speaker 2: Yeah, that’s been sort of a secret weapon for us,
or maybe not so secret, which is those in-person summits fill quite a
lot of what you do get out of being in an office together and gets
coupled with getting to go to nice destinations and so forth.
00:01:33 - Speaker 1: It’s also cool because last year we had a few
people joining us before they actually worked at Rayos, which was also
the perfect onboarding for those kind of people, because, yeah, in a
remote company you usually don’t see everybody always in person, but
it’s made a huge difference for them.
00:01:50 - Speaker 2: And tell us a little about Raycast.
00:01:52 - Speaker 1: Sure, yeah. So for the ones who don’t know about
Rayos, we often describe it as a general productivity tool, mostly
targeted towards developers, but also designers and other people who
really work on a computer use it.
For Mac users, the easiest to describe it is actually A spotlight on
steroids. So everybody works on a Mac. No spotlight.
The basics are to launch an app, search files, do a few calculations.
But with Breakers, we put another level on top of that.
So we’re connecting to third party apps like GitHub, Linar, Figma, and
have like a public store where people can build extensions for, but
other people can experience.
So you can think of it a little bit like an app store. So people can
build something, share it with others, others can immediately install
it. So it makes your work more productive, faster to do.
It’s all driven by keyboard shortcuts. It came out of an idea from me
and my co-founder.
We, like, hugely obsessed with productivity, and we’re a little bit
frustrated that nowadays on a computer, oftentimes there’s a lot of
friction in the small and little tasks that pile up. And we thought we
can do better and basically build it right cause there’s this layer on
top of all the other apps that you can use them in a frick. And less
way.
And so far that seems to be working very well. A lot of people enjoy
that.
Building extensions with us together. We have a huge community behind us
that’s helping us building those experiences. And sometimes they’re
ranging also to more fun things like a gift search that you can put in a
request, a nice gift, and those kind of things.
00:03:24 - Speaker 2: And we’d love to hear a little about your
background, what brought you to this venture.
00:03:28 - Speaker 1: Yeah. So I’m a software engineer and my career
started in mobile development.
So I worked in iOS and Android. For me, the passion there was I could
build something that I can immediately experience.
And that basically, since then, I enjoyed doing, like building something
that I can experience and share with others.
Before Aos, I worked at Facebook on a desktop application, also on the
Mac, which was called Spark AR.
What I often described as a Photoshop for augmented reality.
So for the ones who don’t know it, it looks a little bit like
Photoshop. You have a few port in the middle. You can track in 3D
objects, and then you can, for example, attach it to your nose and it
sticks to your nose with the augmented reality efforts that were there.
What was really interesting there, it was also community driven. So it
was a tool to create something and then you can share it with others on
Instagram and Facebook, and they can use those effects.
And this community aspect is really something that I fell in love with,
because if you build a tool that other people can produce something
with, it’s really interesting to see what they’re gonna produce with.
And so with Rayos early on, what we did there is we wanted to make our
work flows faster, right? So we build up the stuff for us. And then
after a while, we realized there were so many things out there or tools
that we may never heard of that like a platform where people can build
extensions for and share it with others is actually the way to go.
So now we have an API. People who are familiar with React can use the
API very seamlessly, and then they can get into creative ways, building
those extensions and share it with others. So now it, you have pretty
much for every service you know of, you can find one of those
extensions, can install it immediately, and can basically gain little
productivity boosts throughout the day.
Which then oftentimes cut away entire friction points by interacting
with slower tools, and that’s what brought us initially to rate us,
right? We wanted to make. Little things faster that then have this
compound effect that you just enjoy you work more, and that to this day
is still our mission which we operating on to every day.
00:05:34 - Speaker 2: And we’ll link the Raycast store in the show
notes.
I can certainly see the connection between the Spark AR and, you know,
that’s a creative tool, certainly you’re helping other people create
things, and then the joy one gets from seeing someone make something
with a tool you have created that does seem to be a common theme across
people that are drawn to building tools as opposed to sort of end user
experiences.
I’d be curious to hear a little bit about the technical stack. So it is
a native Mac app, but I noticed when I just briefly poked at trying to
build an extension for Raycast that the hello world is very much like a
React component, feels very web technology-ish. How do you do that? Is
it ultimately kind of all a pretty fancy electron app or is it just the
extensions are kind of like using web technologies, but you use classic
native development for the core app?
00:06:24 - Speaker 1: Yeah. It’s actually a question which we get asked
quite often. So the app itself is 100% native. It’s written in SWIFT
and doesn’t involve any HTML or CSS. So everything is rendered through
Apple’s A kit.
Actually, we don’t use Swift UI yet. So that was an early decision
because we felt like we’re building this app which sits on top of the
system and we want to make it really part of the system with the look
and feel, but also What you can integrate it with.
So early on, we thought like, hey, Swift is the way to go.
Also, like, we worked on iOS and Mac OS before, so we knew the tech
stack really good, which helped us initially to just bootstrap the app
really, really quickly.
But then when it comes to building an extension platform, you have a
different problem to solve, right? So they actually want to extract the
system away and rather want to make it accessible to as many developers
as possible. And we went there a little bit on the journey to really
figure out how we should build those extensions and especially the API
for the extensions.
So initially, we started with like more of a version where you have
basically finding a chasing schema that you give the app, and then the
app renders basically what you describe in this chasing file.
But then this brought a lot of like issues when you want to build
something more complex, like think about networking requests and then
depending networking requests, maybe some optimistic updates to make it
snappy.
So what we then saw is like, OK, there are already really good UI
frameworks out there, and React is one of the most known ones.
So why not using React to build extensions and What we did is basically,
you can almost describe it as a lightweight react native. So what we do
is you literally write react, but instead of rendering HTML, we’re
actually rendering swift components. So we’re exposing components like
a list and a form, and then you can use those elements to build your
extension. And then we just render that with our native engine in, in
the application.
And it has two benefits, like one, Every developer who knows React can
immediately write a Rayo extension without learning anything new. And 2,
we keep it very consistent across extensions because we expose these
high-level components like a list, and then a list has list items with a
leading icon and a title and a subtitle. So all of the extensions look
and feel very similar, which was very important to us.
But we also have basically the flexibility of React where you can write
something really, really complex. So you see now extensions like Gitlab
is a good one. It integrates with everything from Gitlab and is nowadays
quite complex. It involves all else and optimistic updates, caching, and
makes it really, really fast. So it’s a nice abstraction away. And
it’s funny now when you have built those things initially natively, and
now look at our extensions API. You actually can build those things
oftentimes much faster with the extensions API now than what we have
done initially natively.
00:09:24 - Speaker 2: It’s a pretty clever way to slice it because for
sure, something like a quick launcher of this sort, first of all needs
to be really fast, and second, absolutely has to be integrated to the
operating system in a way, I think that would be hard with one of these
web technology shims, but on the other hand, extensions are something
that are pretty naturally.
Yeah, using some variation of web technologies fits naturally with that
one because I think so many developers know it, and then maybe there’s
other benefits as well in terms of, I don’t know what sandboxing or
something like that, but yeah, you’re using each technology for the
thing that it best suits for and then sort of bridge that gap through
your system.
00:10:03 - Speaker 1: Yeah, exactly. I think it also is just a nice
separation of concerns, right? So you have natively where you can make
this pixel perfect UI components, and then you expose a very high level
API that extension developers can use.
We’re working at the moment on a file picker, for example. It’s
entirely built natively because, well, you need to interact with the
operating system to pick files, right? You need to open the finder and
so on. And then on the UI side or on the extension side, you can just
make it a lot easier, but just say, I want to pick this file or this
directory and show me hidden files as well if you want to. So you’re
abstracting like a lot of stuff away that an extension developer just
doesn’t need to care about anymore.
00:10:47 - Speaker 3: Yeah, I was so interested when I saw the
extensions angle on Raycast, because it connects to this idea that
we’ve been thinking about for years in the lab, and it’s still a
background for us in Muse. It’s like end user programming,
extensibility, and so on.
Yeah, and the holy grail that I’ve been after is how do you get the
very high performance of a low level language like C or objective C with
the security or something like a high level language and the end user
approachability or something like JavaScript and React. And I think
fortunately, in your case, it’s constrained enough that the
performance, for example, of extensions isn’t as big of a deal in the
sense that like it’s like you’re doing wild computations in the
extension itself, right? So that’s kind of a degree of freedom that you
have.
But the end game that I’ve long imagined is being able to write
extensions that are no compromises, and that can eventually be promoted
all the way up into the app and even the system, so that you don’t have
the like extension world in the app world, in the OS world. It’s more
like a continuum where you move back and forth according to your degree
of certainty and trust. So I’m always interested to find out how people
are tackling this problem because As much as I want that thing, that
thing doesn’t exist, you know, it’s an open research problem determine
if even can be made. So I’m always curious to see how people are
tackling it.
00:12:05 - Speaker 1: Yeah, it’s a super tough problem, right? You want
to have flexibility, but on the same side, you want to constrain a
little bit that it fits still in the system.
So one thing which we did initially when we build the first extensions,
we just build them natively to figure out essentially what we need to
build and to understand DUI and the UX of something. And then we quickly
came up with a paradigm. It’s like, OK, everything you do in Rao is
launching a command and that command is basically a standalone thing.
That can operate on its own.
And then this is basically a constraint you’re giving to a developer.
Hey, as soon as this thing is launched, you can do what you want to do,
but you need to launch it, right? It cannot run just randomly.
That adds certain constraints.
And then when we then came to basically the, the extension world, that
was really nicely applicable because we then can say, OK, you build
commands, they get executed when you launch them run within Ray cost.
And then we had enough of this primitives like lists and forms that we
can expose, that they can use. They’re very high performance, and then
look and feel like the system. So it plurs this line of like, what is
actually part of Rayos versus what is an extension to it. Like, a lot of
people nowadays don’t longer know that, right? Initially, there was
what we had, like core extensions and then some third party ones, but
nowadays it’s like just a blurred line because all of them look and
behave very similarly. And one missing ingredient that I haven’t
mentioned before is like we also have all of the extensions open source
and refill them. So to submit an extension that goes into the store, you
essentially open a pull request with your extension. So that helps us to
also keep the UX and the UI and all the behaviors very similar across
extensions because I think that’s, especially for Ray cars, um, which
is a tool that you use, basically about muscle memory at some point,
it’s very important that the things behave very, very similar.
And then from the performance aspect of things, so one thing which we
did is we run Node as our JavaScript run time. So with Node, it’s
actually very performant for the little operations we do. You have also
the benefit if it becomes performance and issue, you could get native
modules going as well to integrate them, to get performance out of it.
And then React is also for the sizes of extensions to build fast enough
to produce DUI. And then we are not constrained and rendering the UI
because that again we do natively. And then one thing which I think is
very interesting when you integrate something in your main app, you want
to make sure there is a certain boundary between main and extension. So
if an extension crashes, the app should stay alive, right? So what we do
is we run all of that extension code out of process. So it has a
separate process. So if there is something corrupt going on in the
extension that doesn’t block the main app, it stays responsive, can go
back.
And I think that’s just a good user experience, right? Because we all
know as developers, they’re gonna be bugs, unpredictable things,
networkers fails, you maybe don’t handle it properly. So you want to
make sure that the app itself behaves correctly, especially with an app
like Rayos, which I use hundreds of times a day. You can’t really
afford that this thing is gonna crash when there is something wrong by a
third-party developer.
00:15:21 - Speaker 3: Yeah, I feel like we could do a whole podcast on
this area. I think we sometimes caught it on the show the platform
problem. How do you navigate the performance, security, sandboxing,
isolation, consistency, developer experience. I also suspect that Adam,
you want to talk about the space of wrong.
00:15:40 - Speaker 2: Indeed, as you were talking there, Thomas, I was
flashing back to our platforms episode with Joe Webkin, where we talked
about maybe not some of the OS level stuff you’re referencing there,
Mark, but definitely some kind of store slash plug-in directory and a
review process, as well as the constraints that are created for the
extension developers you mentioned, for example, you know, these lists
and You know, an icon next to an entry is kind of a standard thing to
get back as a result of one of your extensions, and that’s potentially
desirable. When Joe talked about building a slack app, he said, this is
really nice. We don’t need to do much design because there’s so many
constraints, like it’s just an icon and some text.
It’s only kind of so many ways to do it and in a way that is nice
because you have fewer decisions to make and you can just focus on
getting the thing built.
00:16:27 - Speaker 1: Yeah, I think what’s also interesting with
constraints comes creativity. I mean, that’s a common phrase that you
probably hear a lot in those tools that allow people to create
something. But it’s actually really true. Like, yes, we provide just
lists, but then if you look around with lists, you can actually build a
lot of stuff, right? And then with forms, you can do a lot of data
inputs. And then we have things like grits, which you can do a little
bit more visual style, like showing images. But you will be surprised
what people come up with.
Like one thing which I remember is just, we can render markdown and we
have this detail for you where you can rend the markdown, and somebody
just came up with playing snake and just rendering markdown. So it’s
obviously a huge constraint if you just have markdown, but developers
are creative, right? And so you can build an entire game with just
markdown rendering.
So it’s always inspiring, and that’s what I mentioned initially with
communities. You have like certain ideas what you can build with it,
right? When you decide an API, you think like, oh, there are just
certain use cases and you maybe prototype, but then when you put it out,
the minute you put it out, people interpret it differently and come up
with something new. And that’s super exciting about wait and see other
use cases that you haven’t thought of before. And I think that’s
always the interesting bit was Pretty much every platform that is built
out there. It was initially with the iOS App Store as well. There were
fun apps initially and then people figured out what are good apps. And
then it shaped this whole ecosystem, which we now nowadays live in. But
I bet at the beginning, there wasn’t really a plan where this leads,
and it’s this iterative process. You put it out and see what works,
what doesn’t work, and iterate on it. And a lot of people are involved
in this process. By sometimes not even knowing about it, right, because
they’re just building for the platform and coming up with something
that pushes the boundaries.
00:18:23 - Speaker 2: So our topic today is launchers and a closely
related element, which is command palettes.
Now for me, launchers is usually the term I use or the category to
describe, you mentioned Spotlight earlier there, Thomas, that’s the Mac
OS built in. There’s a similar one for iOS and iPad OS if you swipe
down on your home screen on your phone or your tablet, you get a kind of
search bar slash launcher thing. There’s quite a long history of this
stuff.
One of my first introductions to it was actually the KDE Linux desktop
system, and I think somewhere in, I don’t know what it was like,
2002-ish, they introduced a feature, I think it’s called KRunner, but
you essentially you would press a hot key Al FF2 and you’d get this
little Mini command line where you could just run a program or do some
very basic things, but it was an absolute revelation because before
there was always this trade-off of you’re in the terminal, the command
line’s great for a lot of things, but of course it also is, can’t do
many things from the GUIY world or you then you’re in the GUIY world
and everything’s about clicking on menus or the occasional hot key.
So that was my introduction to it, but I feel like there’s a pretty
rich history of this, and I’d love to hear. You probably are one of the
most knowledgeable people on it, so I’d love to hear you walk through
that a little bit.
00:19:38 - Speaker 1: Yeah, I mean, we’re working in this space, right,
and looked in a lot of those things.
And as I say, it has a long history.
I think, actually, I would almost take a step back and like, you touched
on the terminal, right? I think that’s kind of where all of this
sparked.
I mean, it was the first interaction we had with computers where you can
just interact with it by text input. And I think this is for the
launchers and command pallets that dimensions.
It’s still the thing today, right? You navigate this without a mouse by
text input and keyboard shortcuts. I think the true roots come from the
terminal and also what I mentioned in Rayo, you run commands, which you
have in a terminal.
And we also have arguments for those commands that you can give it
arguments to do different things.
And when I look back into the history, I mean, after the terminal, the
GUI came, right, where we made functionality available with, with
elements you can click, which obviously made it a lot more user
friendly. But it also came with a little bit of a downside. What you
have there is you just have limited real estate, right? So you have
buttons and you can only place that many buttons on a screen. And I
think that at some point, you run into the limitations of that, and
there are these clutter to your eyes. I think one of them. It’s quite
known for its Photoshop, which has just a ton of menus, which you’re
losing yourself, and there are tutorials on how to use it. But I think
it just came out of the need of like software growth and functionality
and you’re adding more and more, but the display stays the same, right?
Uh, the real estate you have to put those things stay the same, and it
comes at some point very cluttered.
00:21:14 - Speaker 2: A metaphor I used to use when explaining to people
why I used the terminal.
This was, I don’t know, decades ago and I think Folks once, for
example, Windows came along and made GUI’s pretty mainstream and they
would see me using this computer, what they saw as a more archaic way,
and I would usually describe it as, OK, well, menus are like going into
a restaurant and ordering from a menu where you’re pointing to pictures
on the menu, but like, exactly, you can’t have a lot of nuance. You can
point to this picture or that picture, but that’s kind of it. Whereas
if you want to have a more in-depth conversation with the chef about all
the fine flavors that are in it and how you’re going to tweak it and
that sort of thing, like, then you need the power of full language. And
that’s to me what a command line is more like having a conversation
with the computer.
00:22:03 - Speaker 1: Yeah, I think that describes it actually very
nicely because it’s oftentimes even a back and forth, right, where you
give the computer one command, it gives you back an answer.
You use this answer to pipe it to a different command and do something
with it. And this is just very hard to replicate in GUI, right? If not
even impossible.
But I think in GUI, but then at some point, people realize that there is
too much and they try to put in a search for those functionality.
And one of the first ones that I remember was in Mac the help menu. So
if you click on Help, you have this search field, you can put something
in and you search all the menus that you have there, and then you can
click that. And that was actually quite nice to use the software you
have there. And so it made it more accessible, can find those things.
But it was a rather hidden feature, right? Like, it was behind the help
button, and usually you don’t like to click help, right? It feels like
you can’t use the software. You need to press the help button. So it’s
really not. What do you want to click that often?
00:23:02 - Speaker 2: Yeah, I use the help Mac OS search as a quick
launcher all the time for, yeah, functions I don’t use all that often,
maybe like spell check and sublime text. The way I invoke it is I click
help and I type SPE and then I click, you know, basically the first
result, and probably there’s a similar thing with, yes, so my video
editing software where there’s just so many functions in it. And yeah,
I guess that one thing, there is some key command I could memorize, but
I just don’t use it quite enough, but I know what to search for and
it’s very quick to type it in, so I just do that.
00:23:34 - Speaker 1: Yeah, and it’s quick enough, right? And the other
thing is like what the help menu, I think struggles with is it’s just
constrained to one application at a time.
So you couldn’t use it in your video editor to search something
completely unrelated to the video editor and do an action outside of it,
like launching a link or another app, right? So it wasn’t possible back
then.
But then other apps also picked up this behavior. I think one of the
first ones that I know that had kind of like a built-in command palette.
It was for me sublime. I think initially it was just the file search,
but it was extremely efficient. It just popped up the keyboard shortcut,
you search for it. And that’s how I learned navigating around files. I
lost then basically the sidebar wasn’t really relevant for me anymore,
right? It was really just the opening it up, search for the file,
continue where you want to program, and then again, opening it. And then
they added also functionality in a similar menu. It had a different
keyboard shortcut. But you can then search the actions that you can do.
This were just menu items I think initially and then even more
functionality which wasn’t available in the menu item. And I think a
big difference there was it was just front and center. You press this
one keyboard shortcut, and you know, you can do everything with it. So
for me, that was the point when I almost stopped using keyboard
shortcuts that heavily because I knew there was a lot of functionality
in there that I don’t use that regularly, but I know how to find it and
it’s reliable. And I think that’s, for me, was one of the first
experiences where I felt like, this is really good. User interface,
it’s still has a very clean UI. It’s not distracting, but you have
this full power available via the keyboard without touching a mouse or
navigating around in the menu, which is quite cumbersome.
00:25:22 - Speaker 3: Yeah, I actually find it helpful to think of all
these UI inputs holistically as follows. So imagine you have a huge grid
and the rows in the grid are all the operations you can do in your app.
It’s like jump to file, increase text size, indent here, collapse code
block, and the columns are the different ways to send inputs to the UI.
So you have the menus. You have keyboard shortcuts, you have maybe the
command bar, maybe you have Siri, and you have the help menu, and I
think the best systems have a few properties.
One is they actually use all those inputs. They’re systematically
connected.
The example of the help menu was a good one where you go to the Help
menu and it like literally shines a light on the menu where the command
is. And likewise, in the best systems, all of the operations are
available in as many of the columns as possible and ideally the user has
agency over managing those mappings, so they can change the key binding.
And that might be reflected in the menu, you know, a little gray icon
that shows what the chorca key is next to it changes as well.
00:26:32 - Speaker 1: Yeah, I think that’s interesting like to
basically expose the functionality in different ways.
What’s interesting about that one is also you talk to different users,
right? So I think not everybody want to use a command palette. It’s on
the one end inside a simple system, but it might also be more for
advanced users that really rely on the keyboard all day, but you can
expose the core functionality also a very good SUI, right? It’s still
very useful to have those buttons because they also tell. A story, what
is an important action you want to do at the moment. It can highlight
something like you have on Zoom calls, the leave button, it’s, it’s
red on the end button, right? So it says to you, like, hey, there is a
button. If you press that one, it’s red, so be careful about that. But
it teaches the user certain interactions that are in the context very
important. But then as you mentioned, there is like probably too many of
those actions that you can take at any given moment that then the other
utilarian things like a menu and a command pallet can shine to give you
access to those actions in a more concise way.
00:27:36 - Speaker 2: Yeah, they’re much more discoverable and
approachable.
00:27:39 - Speaker 3: Yeah, and in fact, a key benefit of often it’s
the menu and the command palette is a complete enumeration of the
options. One of the most annoying things for me about software is when I
can’t discover the full set of things that are possible, it’s like
hidden and there’s no way to enumerate them. But typically, if you open
up a command pile and then don’t type anything, you can just press down
arrow a bunch and find out all the cool and obscure stuff the app can
do.
00:28:03 - Speaker 1: Yeah, definitely. It’s a good way to explore the
functionality of applications, especially like the more hidden ones as
you mentioned that are maybe further down.
00:28:11 - Speaker 3: And while we’re talking about the properties of
these systems in general, I just want to make two kind of theoretical
comments.
One is, we call them different things like launchers and command bars. I
think there’s a bit of a dichotomy in here. So there’s what I would
call launchers, which is like you type an app name and it launches the
app. There’s search, which is you type like plain text and it finds
documents that have that text in them, just like look up where you know
the name of your document and you type that and it opens the document
for you. There’s commands like calc, you get a calculator. And then
there’s hybrid systems that do a mix of all of these, and I don’t
think any of those are better or worse. I just think it’s useful to
understand there’s quite a spectrum, and that often it’s pretty useful
to just combine them all into one thing as Raycast does. The other point
I wanted to make, and you knew this was coming, was the importance of
speed and performance in these systems, and it’s subtle cause it’s not
just that. The system responds quickly to input, although they usually
do, and that’s often a benefit of these things, is that you often
don’t need any branches at all. So if I want to increase tech size by
going through a menu, I have to look at my screen, find the place I want
to go, move the mouse there, visually confirm that I’m over the menu,
click, confirm that it comes down, move the mouse down. To confirm, each
of those visual confirmations is a branch and anytime you’re round
tripping through your whole sensory system and making a conscious
decision to click or not click, like you’re kind of already hosed,
it’s already hundreds of milliseconds. Whereas, like another example,
if I want to open the sublime map, I just hit command space SUB enter,
and I don’t need to look at my keyboard. I don’t need to think. I
don’t need to check any branches. I can do that all basically in one
string, and a little bit later, the app will pop up. That’s a huge
benefit of these systems and other kind of keyboard input systems in
general.
00:29:52 - Speaker 1: Yeah, I totally agree. Speed is like a fundamental
thing to this.
And it’s not only speed, it’s also the predictability because you
described, you type in SUV for sublime, hit enter, right? At some point,
it becomes just muscle memory. So you don’t really think about it
anymore. You know, you need to go to sublime, you do the sequence that
you described, command space, SUV, enter, and then you dare. So the
system also needs to be predictable in a way. And that’s also sometimes
a challenge, right? Being fast. Predictable, sometimes conflicts. You
can’t do many things in parallel because then it becomes unpredictable
what finished first, or you need to sequence it somehow. So there’s a
huge technical implications there. And then also, what’s very
interesting with that you can optimize as well, because it becomes a
very fundamental part on how you navigate your computer. And you do a
lot of interactions through it, so it becomes smarter as you type in
there. So if you type SUB all the time, it recognized that maybe even
earlier, if you just type SU, it already uprk because it knows, well,
you’re gonna type sublime and make sure that you hit that even faster.
And that’s also an interesting angle, which you can’t really have with
the UI that you described in the menu where you need to do the steps
yourself, and it’s just a lot slower than what the system is capable of
doing.
00:31:12 - Speaker 2: Predictability is a huge one for me, and this is a
place where, unfortunately, the default system ones for me fall a little
short, Spotlight on Mac OS, for example, I use the file lookup aspect
quite often. Or you talked about the launching applications, looking up
files, searching, and for me those first two are the most important. But
yeah, Spotlight will kind of maybe like it updates its cache, sort of
lazily, which is fine, but what happens is you type something in. You
think you see the result, you hit enter and then it changes the moment
before your finger comes down. Which is to me it’s just a no go.
Similarly, on the phone and on the iPad, I do use the home screen search
quite a bit, often for launching applications, but sometimes for looking
up documents. And if you tune it to turn off a bunch of junk, mainly the
Siri suggestions that basically go out to the web, but that just takes
time, especially if your network connection is not ideal, and so you
tend to get this thing where it just changes underneath your finger, and
to me that’s just a total no go.
00:32:13 - Speaker 3: Yeah, I feel like I’ve seen this on my Windows
machine, which I don’t use very often, but occasionally I’m on it, and
it’s like, you open up that whatever it is now. When I was a kid it was
the start menu or whatever that is now, and it like starts searching for
news stories, and like it’s looking at online help articles, it’s
like, I’m looking for to do that TXT on my computer, calm down.
00:32:30 - Speaker 1: Yeah. That’s one thing which we deliberately did
in Rayo.
So if you open that, it’s very predictable. We basically make sure that
it’s a fast algorithm that matches all your entries, but it doesn’t do
async operations like going to the network, trying to fetch something,
which just ruins the predictability, or it makes it just a lot slower.
So there is a lot of engineering work went into The initial version and
we did recently an iteration on top of that to make basically that as
fast and predictable as possible.
And then functionality that needs to go to the network, for example, to
search your linear issues.
They are in a separate command.
So you launch this command and then you’re in the command, and then
they can perform an async operation, but even there, We basically build
it in a way that there is always cash available, that it is fast by
default, and if you need additional data, it’s getting updated in the
background.
But yeah, like, I think this is sometimes undervalued. Um, making
something predictable and keeping it predictably fast is sometimes
tricky, but it’s hugely important for such user interfaces.
00:33:40 - Speaker 3: Yeah, and now that I’m thinking about it more,
I’m realizing that the moment you stray from totally deterministic
predictable, user controlled search, or basically an algorithm for that,
that’s totally within the user’s control, it just becomes
overwhelmingly tempting for the platform to do nefarious stuff.
The example I’m thinking of is Twitter, where Twitter, like every few
days, will try to opt you into their algorithmic timeline, but you can
go in there and say, no, just show me the tweets of the people that
I’ve explicitly followed in the order that they posted them. And the
reason I do that, like, you know, a lot of times Twitter has interesting
suggestions, but they kind of can’t help themselves but suggest
clickbait. And I feel like you kind of get the same dynamic whenever you
have algorithmic lists. And so this is a little bastion of user control
that I’m trying to maintain in my computing environments, both Twitter
and the launchers.
00:34:28 - Speaker 1: Yeah. It’s interesting. One thing we did, we made
it configurable how sensitive you want to have to search because the
search is very personal.
People search for things differently. There’s obviously a huge overlap,
but certain groups search differently. So we had initially just, um,
searching for prefixes and we switched recently to Fuzzy search where
you basically can search for letters that are not directly followed by
each other. And that opens up just a lot more search results. So you
need to rank them differently and cut them differently off.
So what we did is we basically added a preference, and we very not keen
on preferences because we feel like we should ship really good defaults.
And then here and there, you maybe need a few preferences. This was one
of the ones which we went for, because like, we test everything with our
team and we’ve already realized there, there are different styles of
searching for it. So we went for a preference and made it a, a nice
slider, which you basically can Configure the sensitivity of how you
wanna have those mats appear in the route search and ray cost.
00:35:29 - Speaker 2: And we had started a little bit on the history of
this stuff and the discussion of fuzzy search also reminds me of the
first time I saw that, which was in Textmate, I think it was the command
T as kind of a different way to quickly pull up files, and it felt like
a an amalgamation of search and the command line, which maybe is is in
the same realm as all the stuff we’re talking about here.
And we started to talk about the history a little bit. I’d be curious
to hear where you think this stuff went mainstream, Thomas, because
clearly, yeah, this is built into Mac OS, iPad, iOS, whether or not you
like the system, default or not, it’s acknowledged by the platform
maker that this is something that should be available to everyone.
Windows indeed. Has it also, again, I don’t know if start menu is the
right term for it these days, but I know when you use a Windows computer
these days, you hit the Windows key and your cursor focuses on a field
that is pretty simple, but still like kind of one of the launchers.
So clearly all the platforms have said this is a core feature, but that
wasn’t always that way. They were third party apps at the beginning and
it’s interesting also in the case of Raycast, you’re kind of coming
full circle and saying, well, actually we could do a lot better than
what the core operating system is.
00:36:41 - Speaker 1: Yeah, definitely. I think in the early 2000s, it
was the time when you look back, where a bunch of those third party
launchers appeared, and Mark touched based on launchers that are
basically things to launch as applications. But I think also one
critical thing for launchers is that they, globally on your system. So
they don’t live in an app. They’re an app themselves, which basically
sits on top of everything else. And the first ones were, I think,
launched by Quicksilver, both of them.
00:37:10 - Speaker 2: I have great memories of Quicksilver, yeah.
00:37:11 - Speaker 1: Yeah, Quicksilver got a lot of love back in the
days. And yeah, basically, they started, I think, with launching
applications, but then also thinking a step further, what is it, what
you else do? You have files were big in the early 2000s, right? And you
need to do something with this files. You may be opening in specific
tools, you may want to send it via an email. So there were more this.
I think verb, noun input, like you find something and then you do
something with it.
Initially, on the Mac, at least, this was, um, located on the top right.
I think they’re done also the spotlight position that was initially
there on the top right where you had this little search symbol, the
magnifier glass. You clicked on it and there was a search feed popping
up.
So it was highly inspired from the help menu that we chatted before, but
it was just globally, right? So you clicked on it, you could search an
app. And then you launch the app or you can search for files, and it
launched the file. And it was the very early days of this. And then
later in the 2000s, this became more of a redesign. When Spotlight
became, I think, very mainstream was when they did in Yosemite, the
redesigned to make it a front and center bar, that when you have the hot
key command space, it pops up, and then you have this one big search
field to input something. And then it finds results and you can execute
on that. I think that was, for me, the tipping point when it became
really mainstream because it was a really big feature in Mac. It was
basically how you launch your apps, how you find your files. It was a
core part of the system by then. And then a few years later, also this
became basically part of iOS and basically having the same experience as
you described that them to search apps and launch that as well.
00:38:58 - Speaker 3: Yeah, this history overview is quite the trip down
memory lane, because this is where you start your computing when you sit
down, that’s sort of like a series of pictures of all the living rooms
of all the houses you’ve ever lived in. It’s pretty wild.
00:39:09 - Speaker 1: Yeah, good memories also for old operating systems
to see how those evolve over time.
00:39:16 - Speaker 2: It is always vaguely shocking to see screenshots
of even relatively recent past, you know, 10 years ago, Mac OS or really
any operating system, certainly a, a phone screen, which of course will
be massively lower resolution than what we have today, and therefore
tiny when rendered 1 to 1, and yeah, it’s, you know. Technology moves
fast, both in the sense of what computers can do, but also the fashion
of it, I think the stylistic elements or something that are constantly
evolving for good or for ill.
00:39:48 - Speaker 1: Yeah, definitely. And I think after then,
Spotlight became this main thing and other third party apps built like
similar feature sets out. I think another tipping point that I saw is
like this just a few years ago when we chatted about text editors like
Sublime or text made before and VS Code is a modern version of those as
well, who has this command palettes inside. But there were other apps
outside of developer tooling coming up with command pallets integrated.
There were Superhuman, which is an email client, which is very focused
on keyboard shortcuts and had this command pallet to make all the
actions on emails accessible. There’s linear and issue tracker,
similarly, where you can Navigate through it with a command panel that
is built in into the tool. And then also other apps like Notion, which
oftentimes focus only on search, but even that, they follow a similar
interface right where you have this keyboard shortcut, oftentimes it’s
either way command K or command P, which seems to be the primary
keyboard shortcut that those apps select. But I think that was something
which made this even more mainstream because then It got out of this
more niche developer space where people experience in, in those other
applications or sometimes websites, and even it goes so far that
companies nowadays advertise with it, right? So you see on homepage
like, oh, we have this fast user interface which is totally accessible
by command pallets and that’s just super fascinating to see when such a
user interface change happens, right, which we Haven’t really had that
many in the past. We started with buttons, we’re still with buttons. A
lot of the things are still the same primitives. I think that’s one of
the primitives, at least that I remember, that just popped up rather
recently in modern UI development.
00:41:42 - Speaker 2: Yeah absolutely. Also, give a shout out to one of
the friends of the podcast, which is the Arc browser, and they quite
cleverly took, I think it almost feels like a natural extension of the
fact that you have a URL bar in browsers, and people know you go there
to type in the website you want to visit.
At some point, Chrome merged that with search, so right there, that
almost mark covers two of the three you were talking about. You’ve got
search and the sort of look up by name.
The kind of the web version of that, and then arc take it a step
further, which is now when you press that same keyboard shortcut that
you would normally press to make a new tab or to activate the URL bar,
that’s command to or command L, you get something that is indeed can be
used as a search or URL entry, but basically is a command palette quick
launcher. So I thought that was quite a nice evolution or it feels like
this gradual enhancement of what was originally just a place you typed
in a web address.
00:42:38 - Speaker 1: Yeah, that’s true. Yeah. I think even with just
what you mentioned with Chrome is interesting, right? Initially, you
just type in an address, then it became Search for history, then it
became just search with the suggestions. It’s just a nice evolution of
what seems to be a simple text input can actually be quite powerful and
saving again a bunch of clicks or network navigations that you need to
do if you don’t have that.
00:43:04 - Speaker 2: And how do you think about the fact that given
that this is a built-in platform feature essentially everywhere now and
you’re building, presumably what is a better version of that? I mean,
I’m a recast user, so I can definitely say it is better than the
built-in spotlight, but do you see that as like a challenging, I don’t
know, marketing problem or sales problem to pitch the value prop of
we’ll install this extra app, it does what you already have, but more
or something.
00:43:31 - Speaker 1: Yeah, it’s definitely a problem we’re thinking
about. I mean, one thing, Adam, that you mentioned before is people are
sometimes frustrated with the buildings due to like the nonpredictable
results. So often sometimes people come with those frustrations to us.
One thing that we always say is like, you will always have one of those
global launchers or command pallets installed, right? Because You have
this one keyboard shortcut that you remember and then you’re gonna use
that.
So at some point, there is a situation where you go from the building
and spotlight one to recast and hopefully replace it with the keyboard
shortcut that you had before to keep your muscle memory. And so one of
the things that we did very early on is basically said, hey, there is
this moment when you switch. So what we need to make sure is that we can
do the basics that Spotlight can do. But also much better. So that’s
where we invested a lot in the speed to make it faster to launch those
things. We invested in file search to search files in a more predictable
way. And then when you have those basics, and there’s the question,
what else can you bring to this, right? And that’s when we decided on
the platform aspect, because then you can integrate with pretty much
anything else that is on your computer, so you can start really
navigating and controlling your computer in a new way. And that goes
often that far that people use third party services like Chia
exclusively in Rayo because the daily operations they have is, oh, I
need to create issues, or I need to see what is assigned to me. And then
when I see my assigned issues and Rayo, you also can modify that and
update your status. So there is nowadays, a really full flexibility and
functionality in there that is not longer just like searching and
launching. We rather think about what is actually the workflow you want
to do. For example, I want to create a bug report. I’m writing my
editor, but I don’t want to jump to the browser, navigate to Chia, open
the link, open the create issue form. I would rather just press my
global hot key for Raycast, search for the command, type in what I want
to have for the bug report, create it, continue where I left off. So
we’re really on the path of like covering full workflows instead of
like just finding and opening because we believe that’s obviously some
part of it, but it’s much better when you can close the loop entirely.
And that’s what we kind of said with Rayos, that it really removes the
friction that you usually have in a bunch of other things as well.
00:46:03 - Speaker 2: Also occurs to me you’ve gone a little bit full
circle in terms of being a platform provider. So, if you started your
career as building mobile apps, that meant you were dealing with the
often frustrating process of going through app review. So now you’re in
the position of reviewing people’s extensions, and I think the way I
understand it is you can run your own local extensions as much as you
want, that doesn’t need to go through a review, but if you want to put
it in your store to make it really easy to share with other people, now
you have to, yeah, review that pull request, right?
00:46:35 - Speaker 1: Yes, that’s correct. So you can start developing
and use the extensions happily yourself. But then when we share it, we
want to make sure that other people have a really good experience.
And the motivation from that actually came from a different angle that
Mark mentioned. We want to blur the lines, what is built in, and what is
third party contributed to Ray cost.
And for that, we really want to make sure that every extension is as
high quality as possible and follow certain guidelines to make this
seamless experience. So the only way we really thought about it is one,
we need to have a good API that restricts so much that you can’t really
break too much out of the system. But you also need to have a little bit
of a refill to make sure that the UI pattern are followed properly. So
that led us to making refills, um, which on iOS and went through Apple
refills can be sometimes a little bit frustrating, especially if you
work on something which pushes the boundaries here and there a little
bit. So what we decided to do is being very transparent about that. So
we thought about a lot how we do refills and we work with developers
directly, right? It’s not that there’s like some marketing department
in between. We work really directly with developers together. So when we
think about development, there is one review process that all of us
know, and it’s the pull request review process, right? We do that every
day in our companies. So we thought like, why not do the same. So for
our platform, we decided having one big repository where all the
extensions are in. And if you want to put an extension into the store,
you just open a pull request with your extension, and then as soon as
it’s merged, it’s getting pushed in our store, and then other people
can install it right from Rayo. So that it’s I think a really good
transparency because on the pull request, we discussed with the answer
or, hey, how about you do this, give a few hints here, help them, which
maybe making the code here and there a little bit better, and then it
gets merged. And so far we haven’t had any pushback here because it is
so transparent. I think that makes it just A no brainer for a developer,
right? You just open a request and not really questions asked. There is
one downside to it that we experience nowadays. Like, we have, I think,
more than 600 extensions by now in the repository, but this becomes
quite a big repository. So the collaboration is a little bit harder. But
on the flip side, if you now build the new extension, you have 600 other
extensions to look at how you do something. So it’s a huge source of
inspiration. It’s a huge sort of templates, essentially, because a lot
of the commands are similar. So you can copy other things, or you can
also contribute to it, right? That’s also very often happening right
now, where people use an extension and think, Hey, actually, I would
like to have this functionality, and then they can just go to the source
code, modify it, spin out a pull request, and then the author can look
over it, and then we can merge it together.
00:49:34 - Speaker 2: I like that a lot, and maybe it also works well
because the scale you’re at, or the fact that you are sort of, these
are largely kind of developer or developer-ish people, certainly power
users who have some level of programming capability solving their own
problems and wanting to share that with others, so maybe it doesn’t
quite have the huge scale problem the iOS app store does.
Now, have you been in a position where you’ve needed to, I don’t know,
reject something or reject isn’t quite the right word, I guess, say
we’re not ready to accept this because you’re not complying with these
things are maybe almost more subjective, you could say obviously flat
out like it breaks or it’s, you know, abusive or. Tries to do something
nefarious with the system. I think that’s an obvious case. But if it’s
something that’s a little bit more of a judgment call, this doesn’t
quite comply with RUI and as you said, someone thinks, well, yeah, but
I’m pushing the boundaries in an interesting way. Essentially, you
disagree and it becomes contentious. Has that happened yet? And if so,
have you found a good way to sort it out.
00:50:30 - Speaker 1: Thankfully, not that often. We had a few
situations where there were a few discussions, but then you usually find
a way to compromise on a few angles from all sides and then we push this
thing through.
Also, oftentimes you’re very proactive and just help people. Hey, this
is how you could do it. Here are examples. Maybe sometimes we even push
to the same branch, um, and help them modifying it in the right
direction, because it’s also sometimes we aware of that people
oftentime build those extensions in their free time, and we want to also
make sure to respect that.
But so far we’ve been lucky. Like, we didn’t have that many outliers
there. And I think it’s interesting when you work with developers
together.
It’s obviously a specific audience, right? I know they handcraft very
well, but they also like usually in our community, very friendly and
very collaborative. And at the end of the day, everybody wants to build
something which purposes other people as well.
And I think now that we have this big amount of extensions. It probably
became a little bit easier for us because there are so many examples
that you can just follow. So it became more of like, hey, there is a
standard you should follow. And if you’re a Ray cost user, you see
basically what is a good extension UI. So you experience it yourself. So
when you didn’t build it, you’re just following the same patterns.
Initially, we had to form that, right? The first step, we had to form it
ourselves and then we had it to bring to the community.
And then, Nowadays, I think that’s easier because we just having more
people in the community, helping with that as well, and having other
people who build at the 3rd or 4th extension, and I just now already
know what is a good extension. And we also wrote a little bit of
guidelines around that. But, well, documentation is sometimes not that
everybody reads it, right, as we all know, but at least we have a
reference to point people to words, and then when they read it once,
they know it for the next time.
00:52:25 - Speaker 2: Yeah, I can see how the element of, let’s
collaborate on making this extension you’ve made fit into our ecosystem
in a way that meets our standards or will be good for everybody, that
that will feel quite different from the distant reviewer who only has 10
seconds to look at your thing and issue some kind of judgment that often
is even hard to understand what they’re complaining about and, you
know, gestures vaguely at a rule. From this long set of guidelines that
you feel like maybe doesn’t even apply.
And again, that’s partially a scale thing, but I do think that that’s
certainly very powerful, being able to come back and suggest a
modification in the branch of like, well, actually, you know, you do it
this way, and then it’s like we’re building it together, even though,
you know, they’re basically doing most of the work, but you’re working
together to make this thing.
00:53:14 - Speaker 1: Yeah, we’re relying there basically on open
source, right? And because it’s also open source, I think also people.
I want to be presented that well and also this way collaborative. I
think that’s also benefit of that and just the transparency with those
modes are just much higher and nicer for everybody who is involved.
00:53:36 - Speaker 2: So as we’ve mapped out this transition over the
history of computing, right, going from the terminal command line, which
itself, I think was a step forward from the punch cards, the very long
feedback loop, and the terminal is something that evolves into something
that feels like having a conversation with the computer, going to the
GUI, which obviously has its pros and cons, and then perhaps some of the
merging of those two together and launchers and command pallets and so
forth.
Something that certainly comes to mind for me is audio interfaces, which
are maybe less of a hot thing right at this moment than they were a
couple years ago, but I do feel like Siri and Amazon’s Alexa are
something that could potentially fit into this story, right? We talked
about how terminals like having a conversation with a computer, while
these voice interfaces are actually having a conversation with the
computer. How do you see those as fitting into the story, or is that
different because natural language is just fundamentally kind of a
different branch in the user interface history of computing.
00:54:38 - Speaker 1: Yeah, I think, as you mentioned, they became quite
prominent over the last couple of years on various devices, where they
were the standalone devices like the Amazon Echo, but then you also have
things like Siri building to iOS initially, and nowadays also on the
Mac.
It’s certainly a new way to interact with your computer via voice,
which is interesting, but it’s also, I think, very challenging. I think
they come from a similar pattern, especially when we look back to the
terminal, right? As you say, you really have a conversation. There might
be a little bit more forgiving in a way that you don’t need to specify
directly a command. You can rather talk about prompts or intents, like,
oh, I want to buy something or tell me something about this.
That is, I think, a big step forward to make it more forgiving.
The hard part about it is that I see is the feedback loop that you have.
So, You say something, but you don’t really know exactly what you’re
getting back. And it’s very hard to learn that, where you’re then
falling back properly into certain patterns and try to figure out how
you really need to communicate with the computer that they understand
you, which I think is the tricky bit, which almost reminds me a bit of
the terminal where you also need to figure out how to talk to this
computer.
Because there is not that much help. We now have things like
autocompletion there, but it’s still like a little bit bumpy to use a
terminal.
I think similar is on an audio, versus when I compare it to launches and
command pallets, you have a really quick feedback loop because you enter
something, you get suggestions that you’re essentially filtering down
to what you’re looking for, and then you execute that. So it’s very,
well, predictable, as you mentioned before. But it’s also very
intuitive, whereas the audio is much more abstract and you don’t really
have a good grasp on what the computer can do for you, how does that
recognize what you’re saying, which I think is the main downside of
it.
On the flip side, you use cadence for it. I think things in the car,
where you basically have your hands and your concentration on something
else. I think the input mechanism of voice is just super interesting for
those kinds of things. But I find it hard to believe that this is how
we’re gonna work if professionally with computers because it’s so
different to what we used to, but I might be a little bit old school
here.
00:57:02 - Speaker 3: Yeah, this is a very interesting prompt. So I’ll
be honest that I was not, and I’m not a fan of the original black box
audio interfaces, so Siri and Amazon Echo, and it was for two reasons.
One is they were totally black boxed and cloud connected and I felt like
you were just putting an always on microphone in your home, which was
always extremely suspicious to me, but also, They were black box in the
sense of you kind of didn’t know what they could do or what they were
thinking, but now I’m thinking back to our big grid, and it would be
amazing if we made audio, just one more column, like keyboard shortcuts
and command palace, and if you had the same level of agency and
visibility.
So imagine if you opened up Your launcher app, and you started saying
things, and it started narrowing down the commands and highlighting more
brightly those that sounded closer to what you were actually talking
about. That would be a great way to get feedback and to be able to
understand the full palette of options, if you will, for the command
interface.
And now going back to our discussion about performance, it’s
interesting to think a little bit theoretically about the speed, if you
will, of these different input methods. So typing is quite fast because
it’s very precise as well as having a high number of hits per second.
Each key you hit is, I don’t know, it’s probably a couple bytes, and
you can do a lot in quick succession. And voice, if you think about
where it might be most useful, it’s probably cases where you have a
relatively high number of bits to input, and you can have a relatively
high degree of confidence that you’re gonna get the right answer,
because as you were alluding to before, the feedback and follow up is a
bit of a mess on voice. Like I had this in the car sometimes where I’m
like, you know, give me directions to the gas station, it’s like
calling mom’s like, why not, you know, what are you talking about? But
if you have a relatively long input and you have a high degree of
confidence that it’s gonna get the right answer, then voices are pretty
good.
And but as well as there are just cases where, for whatever reason you
don’t want to be using your hands like you’re in the car or you’re
doing something else with your hands or you’re out walking. So I think
it could be interesting. The avenue that seems most promising to me is
integrating it as a complementary mechanism versus a wholly different
vertical silo.
00:59:11 - Speaker 2: Yeah, I certainly love multimodal interfaces and
the idea of using hands, but voice, but also, yeah, keyboard, touch
screens, and putting all of those together rather than just picking one
or the other, picking the thing that’s right for the moment, whether
it’s because of discoverability, whether it’s because of performance.
Yes, I can certainly speak to needing to, or wishing to operate a
computing device when I barely even have one hand free, which is often
the case when you’ve got a young child. So there’s a lot of value
there.
But it’s funny, Thomas, because, yeah, I think the way you described
it, I was originally thinking, OK, sort of naturally, voice naturally
does slot in a bit with more like being like a command line because it
is a language literal conversation with the computer as opposed to the
gooey pointing to pictures about what you want. But the way you
described it, it occurs to me, OK, well, earlier you said the key things
about these launchers and command pallets is that they’re predictable
and they’re fast, and those are the two things that voice are not. And
some of that is probably weaknesses in our current ability of voice
recognition that will get better with time, but some of it is
fundamental to the format, right? You speak more slowly than you type,
at least for a power user.
And the feedback mechanism, it can vary, you know, maybe if you have
something on screen, you can get some degree of live feedback, but of
course, especially if it’s something that is not a screen oriented
thing and you need to wait for the computer to talk back to you, that’s
a very slow feedback loop, and then certainly the Predictability of it
probably at a minimum because we tend to lean towards natural language
in those, we’re not using a direct example of a command line, right? If
I was actually speaking Unix commands or something of that nature, you
know, would that be more precise or more predictable? I’m not sure.
01:01:01 - Speaker 3: Well, now I’m thinking of really leaning into
this.
So in the same way that you can set a keyboard shortcut, what if you
could set a voice shortcut for stuff that you use all the time, you
know, for example, something I would love to have as a timer, and what
if I just said T 5 minutes, and it, and I could say that when I say T,
that means set a timer versus like Siri, yes mark, Siri, set a timer for
5 minutes, you know, I’m not gonna do that.
I’m also wondering now. And this ties back to our platform conversation
a little bit. It might just as if in the last few weeks become viable to
do this outside of the big behemoths like Microsoft and Google and Apple
because of these open source voice recognition algorithms. So, I think
it would be a very interesting test of the extensions platform because
can you run those programs within it? And the answer is probably no, not
right now, but it’ll be interesting test case.
01:01:51 - Speaker 1: That would be indeed interesting. I like the idea
of the shortcuts, right? Because I think one of the problems that Adam
touched based on is like voice is just fundamentally slower. And when we
talk about productivity, we want to make everything as fast as
possible.
But like what Mark mentioned with the T 5 minutes, like interpreting
that as a timer, that’s a an interesting twist to it, right, where you
Tweak it to your personal needs, because you oftentimes don’t need it
to be very general, right? You have a few specific use case that you
know about.
Um, I sometimes turns, turn my lights off in the evening and use voice
commands for that. It’s a low friction task. I don’t really care if
they’re turned off immediately or like a few seconds later.
Similar with the timer, you probably also don’t care much about it. You
just want to have the timer to cook your pasta or whatever.
I think those are really good use cadence for it, where it like doesn’t
really matter the performance. That is, I think the conflicting with the
work environment where performance really matters, which is why we still
with the keyboard, every professional user, right, and types as fast as
they can to put in, input into the computer.
01:03:01 - Speaker 3: Yeah, and this is also where I think it’s
fruitful to try to be pretty precise and scientific about speed, because
there’s speed and like bits of information per second, in which case I
think voice is actually quite fast. I think it’s faster than typing.
Don’t quote me on that, we have to, you know, type it out and say it
out, but I think it is, but there’s also a higher startup time for
voice, kind of higher overhead, and then there’s the sort of loss
factor that you get from the reduced precision of voice. But again, that
suggests ways in which you can use and mitigate these different
technologies that you could introduce voice short codes and you can
target areas that have low loss from reduced accuracy. I think just kind
of going in there with a little bit of precision is gonna be helpful.
01:03:41 - Speaker 2: Yeah, you can even imagine shaping the voice
commands around what the computer can understand more precisely.
There’s a whole, I’ll pull in my interest in dog training here, which
is the ability for, even though dogs have very good hearing, their
ability to make out things in the frequency range that humans use to
speak is actually not very good. And so, it’s much easier to speak to
them in a way they can understand if you use single syllable words that
have really kind of sharp consonants, so this is why it’s good to name
your dog something like Spot or Spark, versus something like Tobias, I
don’t know, because that really sharp single syllable is more likely,
and yeah, maybe there’s a version like that, not unlike the Unix
commands of yo, that would sort of cut out, you know, unnecessary vowels
just to make sure they could get down to 3 or 4 letters. Maybe there’s
a version of this that we get some kind of voice. Shorthand for speaking
to a computer that’s more efficient, more comprehensible to the
computer, easier to recognize, easier to disambiguate in a noisy setting
or from different speakers, but that we learn to adapt our speech a
little bit to add this new kind of input to our repertoire of ways we
can interface to our devices.
01:04:57 - Speaker 3: Yeah, and this is a bit of an aside, but this also
reminds me of some noodling we had done in the lab around probabilistic
interfaces, and so the context there was touch and touch like voice is
not precise, you know, you got these big fat fingers that cover like
1000 pixels, you know, you got oil on your hands and the cat’s walking
across your screen, it’s a mess. But our intuition was that you could
use the domain that you’re in to more reasonably interpret.
Touch input. So, for example, if you get touch input that’s like right
where the person usually puts their non-writing hand, there’s a higher
probability that it’s palm, and it should be rejected. And if there’s
a finger that goes down right next to the OK button, there’s a higher
probability that’s a real press.
And we were thinking, is there a way to incorporate this all
probabilistically, so you don’t need to have these super deterministic
yes no answers until the very end of the pipeline. That is when you’re
spitting on an application action, not when you’re spitting out an XY
coordinate on the screen. And I can imagine something similar with voice
where they know that this user, the overwhelming thing that they use
Alexa for is setting a timer. So when you hear anything that sounds like
T or timer or time or set or clock, you know, there’s like 99% chance
that the timers just called that. And I had the intuition that if you
consider the problem holistically like that, these messier inputs could
become actually quite useful and precise.
01:06:18 - Speaker 1: I think an interesting angle to that is just the
channel awareness of context that you’re in. I think the timing during
the day when you execute those commands might matter if you’re on a
computer, what you use at the moment.
They have different functionality.
I think all of those things are not used in the most efficient way yet.
There are things like serious attractions, which try to be smart and it
sometimes works, it doesn’t work. I think a huge problem with that is
accuracy.
Like, if those things are too often false, you’re losing trust in them
and you no longer rely on them, which is unfortunate.
But I think context, awareness can basically speed things up, right?
Because a computer can make certain predictions that you’re very most
likely doing this. So, as you mentioned, like, hey, when you say
something that’s similar sounds to timer, it’s probably gonna be timer
because you say that 100 times before.
01:07:12 - Speaker 3: Yeah, and by the way, the thing with these
probabilistic systems is the hard part is getting the label data. The
statistics to spit out an answer, giving labeled data and input is quite
elementary.
This is another benefit of using the unified table of actions, because
you can see when they’re using the keyboard and the command palette and
the menu and the help, they’re always going to like set time or
whatever it is, or increase fund. Size or open file to do.txt and then
they can use that as sort of labeled inputs into the probability
calculator to determine what are you likely to be saying.
Whereas if you’re Alexa or Siri starting from scratch, it’s kind of
hard to assume anything. You know, maybe they know that people ask for
music or timer slot, but what can you really assume whereas you have all
this labeled data from your unified table of operations for your app or
your OS or whatever, it’s quite good for bootstrapping.
01:07:58 - Speaker 2: Well, Thomas, I don’t know how soon we’re gonna
get recast on the phone responding to probabilistic voice inputs. So
perhaps more nearer term, what kind of things are on your road map?
What’s your team working on at the moment?
01:08:10 - Speaker 1: Yeah, definitely. So yeah, we’re a little bit
more crowded, I think, in the here and the yet, what we work on, we have
a very active community that basically sends us suggestions, feature
requests, pocket boards, day in and day out.
And we read all of them, enter all of them, and basically those things
form very often in our roadmap.
So we’re working on a lot of the features that throughout the year,
people popped up and want to address them throughout the rest of the
year and then starting with bigger efforts next year. I think that’s an
interesting thing when you have this community of very loyal users, they
want to push the system with them, and we’re very happy about that and
trying to make as much as possible happen with the small team that we
are.
01:08:55 - Speaker 2: Yeah, like being able to spend some time on kind
of directly addressing the most common feedback, just, you know, give
the people what they want kind of thing. But also, you also need some
periods of time where you can focus on bigger things that maybe people
wouldn’t have known task for because they reflect your long term vision
or things you see opportunities you see as the creator of the product
that is thinking about it night and day, more than any user or customer
ever could. So I think it’s healthy on a team to have some time devoted
to each.
01:09:29 - Speaker 1: Yeah, definitely. You want to strike a good
balance there. I think it’s one thing which is unique when you work
with those developers together. They give you a lot of input and we
really value that. And the least we can do is basically coming back as
quick as possible with answers to this. Sometimes that is, we’re not
gonna do that, then we’re also honest about it, but then we try to
build as much as possible into the tool. Because at the end of the day,
we’re building the tool for other people, not only us, and then we get,
we listened to and try to formulate our own opinions afterwards.
01:10:05 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at museAppHQ via
email, hello at museapp.com. And Thomas, thank you for continuing to
push forward the world of launchers and command lines and doing things
with keyboards here in 2022 because I feel like even though that may be
something we’ve had have been part of computers from the beginning, I
don’t think we’ve taken that all the way to its terminus.
01:10:36 - Speaker 1: Thanks for having me. It was really fun being
here. And yeah, we’re not gonna stop working on the next world of
keyboard navigation.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: One thing that really stood out to me reading the
original research article was that so many pieces of software I try out,
they don’t really feel inspired, doesn’t feel like there was like a
real driving passion behind like why this had to come into the world.
00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Muse is software
for your iPad that helps you with ideation and problem solving. But this
podcast isn’t about Muse, the product, it’s about the company and
small team behind it. I’m here today with my colleague Adam Wiggins.
Hi, Adam. Hey Mark. And a guest on the show today is Lachlan Campbell.
Lachlan, welcome.
00:00:39 - Speaker 1: Hey friends, thank you so much for having me.
00:00:42 - Speaker 2: Today’s show is about the journey of views and
products generally from a research lab, an early idea, a private beta
all the way through to being a commercially available product. And the
way Lachlan fits in there is they were one of the very first uh users to
try and really get news. So Lachlan, do you want to introduce yourself
briefly in terms of your work and what you do with that club?
00:01:04 - Speaker 1: Yeah, for sure. I describe myself as a web
designer developer. My primary creative work is uh designing and
building websites, and I also am a student at NYU. I just finished my
first year majoring in interactive media arts, which is uh making art
with technology, so it’s not coming at it from a technical side, but
more coming at it from an art side. And I work at a nonprofit called
Hack Club, Hackclub.com. We’re a network of high schooler led coding
clubs and high school makers around the world. I started a coding club
back when I was in high school and then got involved and I’ve been
working with the team for 3 years now, making websites and doing
marketing and I my official role is head of storytelling. So I do a lot
of open source coding and art making slash political advocacy as well as
working at Hat Club and going to college. So it’s, it’s many hats.
00:02:05 - Speaker 3: And I’ll also throw in that you’re a pretty, I
would say sophisticated iPad user or maybe passionate one, you have some
great posts in your notebook about using the iPad for web development or
how to install fonts, things like that. And I think that’s even in our
first communication when you basically wrote in to um join the waitlist,
you did a pretty long multi-paragraph, maybe multi-page thing about all
these different apps you’d use on the iPad for research and so on,
which is certainly part of what caught my attention and why you were in
that first, that first batch.
00:02:36 - Speaker 1: Yeah, I, I got the original iPad when I was in 3rd
grade back in 2010. It just kind of blew my mind downloading an app for
the first time.
That’s kind of what got me into building software and thinking about
computers in the first place, downloading an app on that iPad. I tried
to like use my iPad as my primary computer back in 2010 and it did not
go very well.
But fast forward a few years and then in sixth grade, I started looking
into like building iOS apps. And eventually got into web development.
Then back in 2017 with the 10.5 inch iPad Pro, I got that and switched
to using that for most of my work, most of the day.
Over time, then getting the 2018 12.9 inch, I’ve only increased and I
use my iPad for the majority of my coding and design work as well as my
everyday. I just absolutely love it and it works great for school and
I’ve found coding and design setups that work and everything in
between. So iPad has been a foundational piece of technology in my life,
as well as something I use daily and love.
00:03:45 - Speaker 2: And so to set the stage a little bit, Adam, maybe
you can briefly describe the arc of this journey and then we can go into
the details and the philosophy behind it.
00:03:51 - Speaker 3: Yeah, this is something I’m pretty passionate
about because I’ve been through this whole journey quite a number of
times in my career because I’ve been doing this work for quite a
while.
The Muse origin story is a little different because we started in a
research lab, but something I’ve seen in all of these examples
throughout my career is this process where you start with something very
raw and unfinished, and you’re still trying to figure out if it’s even
useful, let alone. Uh, making it work in a lot of different cases on a
lot of different devices for a lot of different people and then the slow
process by which you bring it to a production ready released product.
I think the the way we label those points in the in the story is quite
interesting and yeah, it’s going to be fun to talk through the, the
history of news, particularly right now where we just came out of beta.
00:04:37 - Speaker 2: So with that arc, Lachlan, maybe you can describe
with Adam how you came into the story as one of our very first private
Alpha users.
00:04:45 - Speaker 3: I’d I’d be curious to know where you even found
out about it. Do you remember?
00:04:49 - Speaker 1: I don’t remember exactly where I found the
original link, but I read through the entire uh research page that you
made, um, exploring the initial interactions.
It just felt like someone had finally answered my silent calls for, oh,
a better way of kind of thinking and creating an iPad. Because it feels
like so many creative tools lock me into like, I can only use a
keyboard, or I can only draw something and then I have either too many
tools with all this flexibility that I don’t want, or not enough, and
Muse just felt like such a natural extension of thinking with an iPad.
That you could just kind of interact with anything, drawing on it, or
you could type or you could bring other stuff in.
So I remember sending Adam an email with, I think a lot of all caps and
exclamation points um that about how excited I was and um describing
some of this.
Systems I used already, um, like good notes and I writer and tons of
shortcuts and other systems, and how I really wanted Muse to fit in. We,
we got things started and I’ve been, I’ve been using, using Muse on
and off, um, but a lot more recently, over, over the last year.
00:06:05 - Speaker 3: Yeah, well, maybe that design article you
referenced was actually a good place to talk about sort of how this
started, which was the research lab. We’ve talked about I and Switch on
the podcast before, but essentially, I guess it’s true for any kind of
product, you know, it starts with an idea that someone has, but we did a
much more rigorous process through basically building multiple
prototypes, including a thing called Dossier that was on iPad, a thing
called Capstone that was on the Chrome uh platform and then because
we’re a research lab rather than a commercial entity, we wrote these
kind of academic style publications about what we found and actually
that Muse design article, I think we had that was just right around the
time we decided to start calling it Muse for one thing. Um, and then we
were publishing, you know, they have these little videos and the design
methodology that went into it, the studio for ideas concept, which was
Mark’s Mark’s brainchild, but we were at this point right around the
time we published that article, or maybe a little bit after when we
started to say, you know, if we’re thinking about which things we’ve
built in the lab that have the potential to spin out and become a
commercial product, this one seems pretty promising and it was partially
the response to that article, including the the. Uh, lovely emails like
the one, the one you sent in as well as the talk that Julia gave a
little bit later that basically made us say, yeah, we think there’s
some potential people are are excited and they see the potential of
these weird ideas that we developed in the lab and we tested in like
usability tests, but not any real usage. Um, and so that was the, the
transition to OK, let’s spin out the separate entity that’s going to
be explicitly for profit and it’s not about publishing research, it’s
about making a thing that people can use and then potentially buy and
notably at that point also, so around the time you emailed in was when
we were trying to, we had a kind of a collection of people who had
written in based on that article. And we were trying to think, OK, we
have this really, really rough prototype, but we want to make sure we
give it to the right people who can maybe see the diamond in the rough
or have the right use case, or if they’ve certainly if they’ve tried
lots of other kind of apps, yet note taking or research or annotation
tools and have been a little dissatisfied and they feel like from
reading this design article that they have a sense that this This
product might potentially fulfill a thing they want because of course we
knew it was so rough and so raw and so, you know, so many weird
interface ideas or whatever and so many things it doesn’t do, not to
mention bugs or, you know, doesn’t doesn’t even work in portrait mode,
etc. etc. etc. So we needed the right people to potentially see its, uh,
see its potential. So I think at that point when we were making the
commercial entity, that’s when I what I is basically what I would call
like an MVP, which is minimum viable product in the startup lingo. The
idea is, OK, this we can use not just to test research ideas but to give
it to people and see this fundamental thing of like, is it useful? And
it’s actually hard to ask that question in a way of people,
particularly if you have design minded people. That includes you
Lackland, but also a lot of other folks that wrote in, they’ll tend to
focus on, well, this corner isn’t rounded very well or this animation
is glitchy, but at this stage, that stuff doesn’t matter. You can
polish that later. What we need to know is, does this thing, is it
fundamentally useful and is it useful enough to sell it for a price, uh,
that, um, you know, would make the whole thing a sustainable business.
Now Mark, I’m curious your your perception of that kind of lab to MVP
stage.
00:09:35 - Speaker 2: Yeah, that all lines up with my thinking on that
process. I would add another angle to it, which is at each stage you’re
trying to validate or de-risk or gain information about something in
particular. When you’re in the research lab, what we’re trying to do
is convince ourselves that we have some spark of novelty, things like
the zooming UI plus mixed Media canvas plus 120 FPS plus Inc everywhere.
That felt to us like a spark and we wanted to. pursue it further. So on
the next stage, which is like the private alpha or private beta, you’re
testing, does this spark go off for people outside the lab who don’t
have our contexts. Now, importantly, you can’t quite jump all the way
to do you have a product that properly works for everyone. So you have
to find a way to test just that core spark. So you end up working with
people who are very, you know, excited, they like to test new software,
they’re willing to put up with some rough edges. they’re willing to
see through, you know, a few months and a few iterations.
So for example, when we had this original Private Alpha, I don’t think
you could do much import export. I think it crashed a fair amount. Oh,
you couldn’t turn it, uh, vertically, like you can only use it in
landscape mode if you want to turn your iPad around, too bad.
But despite all that, we had, I think, a half dozen people or so who
were like, yes, I, I see the promise here. And yes, there’s all these
rough edges, but there’s something more.
Here and then once you have that, then you go on to the next stage,
which is can you consolidate your design into something that fits more
into the standard iPad app container. So for example, you can rotate
your iPad, you can do import export, but early on, you’re really trying
to validate that core spark.
00:10:59 - Speaker 3: I’d be curious to hear your perspective here,
Lachlan, which is you read this article, maybe naturally an article like
this has these little video clips representing the idea in its purest
form, and you’re not seeing those rough edges as much, then you got a
chance to try it.
Um, and of course, as Mark says before we’d even, I don’t think there
was even an action bar, there was no on-screen menu, everything was like
how you grip the stylus and all this craziness, how much did the thing
you got, you obviously did see a spark with it because you stuck with
it, but how much did the thing you got match what you imagined or
pictured in your head based on this article?
00:11:33 - Speaker 1: Yeah, I mean, one thing that really stood out to
me reading the original research article was that so many pieces of
software I try out.
They don’t really feel inspired. They feel like a natural result of
other forces around them that resulted in these, and then it’s been
polished up into use San Francisco and nice rounded corners, and it’s a
nice product, ostensibly, but it doesn’t feel like there was like a
real driving passion behind like why this had to come into the world.
That was a real differentiating factor reading that original research
article was that it felt like you were focused. a lot less on rounding
the corners and a lot more on like, what is the actual idea here. And it
also didn’t feel like you were building a tool to make a tool. I know a
lot of people love notion and things like that, but oftentimes I use
them, they feel kind of like setting out to build a better tool instead
of trying to do something and along the way, feeling like we needed to
build something for it. Muse really stood out right from the beginning as
feeling very inspired. That spark was amazing. And so yeah, the original
version I remember being very rough. It crashed a lot. I, there was no
drag and drop, there’s no rotation, there’s no split view, there’s no
dark mode, there’s no like hundreds of other features. One day I like
lost my pencil for like an hour and so I was just unable to edit any of
my notes.
00:12:56 - Speaker 3: Um, yeah, the thing was completely unusable
without a pencil, right? You couldn’t even move a card.
00:13:00 - Speaker 1: Yeah, I had to keep like trying to re-grip my
pencil at different angles to try and figure out where the hidden
gestures lay.
Um, so it was definitely a lot of like secret incantations at the
beginning, and there was like a frames per second indicator like
flashing on screen all the time. It was definitely rough. Um, so it
didn’t totally match like what I saw in the article, but it felt like,
I mean, one, it felt really special that I was getting to like use such
an early version and provide feedback at a time when there was still a
long ways to go and making it something real.
And it felt like such a special thing to be using that like I could
forgive all the all those rough edges. And so I would just email Adam
every 2 weeks with a list of like 20 bullet points and like 1500 words
of like, here are all the features that I want this week.
00:13:48 - Speaker 3: Lots of enthusiasm, which I really enjoy. We we we
fed off of of that for sure and and you’re displaying that now as well,
so that’s great. Also plenty of sharp critique, like I hate this, this
is terrible kind of kind of thing and that that obviously is really
useful as as well. It’s the two together that make make for good
feedback.
00:14:07 - Speaker 2: I think this points to another aspect of the arc,
which is as you’re annealing a product at the beginning, you’re going
to want to have a very high bandwidth customized, personalized
relationship with your, you know, 5 users and then as you go to a large
scale commercial product, you’re going to want to have mostly
self-service, automation, things like that over the course of going from
the prototype. To the products were kind of ascending that ladder. So
Lachlan, when you first tried the app, like you said, there was no
instructions, it was just a blank screen and basically you got in a car,
got the email chain with Adam, and he explained everything to you
personally and answered all your questions.
00:14:42 - Speaker 3: Uh, fun little anecdote there, we got a rejection
the first time we submitted to the app store, and the reason was, when I
run the app, it’s a blank white screen and we came back with that’s a
feature.
00:14:55 - Speaker 2: Yeah, exactly. Around that time we were doing
onboarding. Lachlan, I’m not sure if you had this, but we were getting
on video calls with all of our initial customers.
00:15:02 - Speaker 3: Yeah, we did one, I think, part of the both, both
the first walk through so I could kind of give a little demo because it
just was so incomprehensible otherwise. But then I also wanted to watch
kind of over the shoulder, so to speak, it was just like a screen,
screencast. Yeah, share screen sharing thing. I wanted to watch someone
using for the first time what that discovery process was and where they
got tripped up and what things made their eyes light up and that kind of
stuff.
00:15:26 - Speaker 2: And we were trying to do a combination of showing
our motivation and use cases for the app, showing mechanically how you
use it, and then also assessing where the potential customer was like
how they use their iPad, or other apps they use, what their use cases
are. And then our general MO is to try to do that until we basically
start hearing the same thing repeated over and over again, cause when
that happens, you’re not gaining any information.
So everyone says they want to use their iPad, but there’s nothing that
feels right, or they bought an iPad, but they ended up just using it for
Netflix and they put it in their drawer. These are, these are stories
that we heard constantly. Absolutely.
Then you go to sort of the next phase where maybe there’s uh and maybe
it’s an email onboarding where we send you some instructions and answer
questions, but it’s a little bit less high bandwidth and therefore a
little bit more scalable.
00:16:09 - Speaker 3: One note there, Mark, you mentioned um the those
early people that um are excited to provide input or Lachlan, as you
were saying, like it’s fun to be a part of something early on, even
though it’s so rough around the edges or even sometimes painful to use,
but it’s fun to know that your your input is going to be high. Um, or
your feedback is gonna have a big impact, um, but I, I think this is one
of the reasons why these pieces of terminology we use like prototype,
MVP, beta, and then I don’t know, general availability release,
something like that is important. For so that users or potential
customers know what to expect. If it’s a beta product, for example,
then you know that it’s still fairly early, but it should work. Whereas
if if it is in that right out of the lab, basically just a prototype,
you can expect both something fairly raw, but then you have a chance to
have that input. Maybe people don’t feel like they have time for that,
they’re just looking for a tool to solve their problem. They don’t
want to give a bunch of feedback, they just want a thing. And so then
they should probably stay away from that, but for others that might be
fun or they might have the time for it to have the interest for it. Um,
and so I really like if you, if you put the right label on each stage as
you come to that stage, it’s a signaling externally so people know how
it, how they should engage with that product and also for the team
internally to know what what they should be doing again rounding those
corners or fixing every la. little edge case bug may not be important
when you’re still trying to establish the basic is this thing even
useful? Should we even make this? Um, whereas later on when it’s
something that you’re selling to people and you’re calling a general
ailability product, it’s really important to, you know, do that fine
craftsmanship for all those little details. Yeah, absolutely. So what
point Mark, would you say that this felt like a sort of fully being a
beta? And I’m reminded of the classic um Gmail beta, which I think
lasted for 3 years, 4 years or something crazy, they had millions of
users, um, and people joked that it wasn’t and it almost became a
little bit of a trend because Gmail was so successful. I think people
kept that beta label on for a really long time because it somehow seemed
cool or something like that. But I think that’s an example of probably
labeling it the wrong way. People have the wrong expectations, but I’ve
also seen things go the other way, which is actually one of the very
first technology products I ever worked on, and we were getting ready to
roll out the first release of this, this product, and someone on the
team said, oh, we got to call it 3.0 because people don’t trust
products unless they’ve been around for a while. And that’s really the
tail wagging dog because There, there you’re, you’re, you’re being, I
would, I would argue a bit deceptive, but at the very least, you’re
not, you’re not setting expectations correctly either for the people
that are using the product or for your team internally. Um, so yeah,
what, um, at some point I feel like news became a beta and not a
research prototype anymore. What, what, what made it that, I guess.
00:18:58 - Speaker 2: Yeah, I think for me that was when We had
validated to our satisfaction, the core premise, this mixed media canvas
with a zooming UI ink everywhere, fluidity, and that was basically there
to stay, we wanted it, our customers wanted it, and we were moving on to
the phase of making it a full and complete stable app. So probably the
first thing we did there with the with the quote unquote beta is making
sure that the data was reliable, so we started to be able to tell people
this is an app that you can put real work in and you can have some
amount of trust that you’ll keep that data.
And then we had to go down a whole list of things that you need to have
while you’re in beta to make a real app.
Things like it needs to obviously be much more stable and crash less,
but also all the fit and finish of being an iOS app, so being able to
rotate, being able to split screen, be on drag and drop, iOS shares
sheets, and that when we were in the beta, that’s kind of the the stuff
that we were working through, as well as I would say, having more of a
commitment to making the app more usable to like regular human iPad
users. Uh, so this is things like putting some consideration into
onboarding and more generally I would say consolidating the design. So
when you come out of the lab, you have all these wild ideas and you’ve
made all these weird choices, and they don’t all fit together and they
don’t fit with the standard iOS model. So when I say consolidate, you
need to pick where you’re going to keep your unique choices and then
find a way to mesh those with a normal iOS app in the regular ecosystem.
00:20:21 - Speaker 3: That actually makes me think of, I think it was
around this time. That we removed the excerpting and wormholes feature.
Lachlan, you brought this up right before we were recording that the
wormholes were really cool and really quite distinctive feature of um
was it in the version that you first used or did you just see it in the
design article?
00:20:39 - Speaker 1: I believe I did have it at the beginning, but
yeah, and then a few months later I was like, where did those go? I want
those back. So yeah, I’m really excited to see what you come up with
for a new version of excerpting.
00:20:50 - Speaker 3: Yeah, those are, those are on their way back in
we’re working on that now. Um, but it’s actually a good example of
something that was one of our weird research ideas, I think would prove
quite successful in the.
But when we’re in this process of trying to, as Mark says, consolidate
the design and there was some technology things around it as well, we
realized it was essentially in our way to make the rest of it, the more
foundational pieces work well, both in terms of again design but also
just the huge amount of code that was devoted to it.
And we made the difficult call to remove it temporarily. There were some
other things that that um such as the shelf, I think was probably an
aversion. Um, that you originally had, which was kind of our, you know,
our, our take on split screening, and, you know, we hope that those
capabilities might come back, but at some point in a research prototype,
you can do try a lot of weird ideas and then once you collide with the
real world, so to speak, you need to conform to all these things, be a
good IOS citizen and so on, it gets a lot harder to maintain all of
those. So we made some selective choices to snip things out, which was,
which was difficult at the time, but I, I think it was the right call.
00:21:57 - Speaker 2: Adam, you mentioned being an iOS citizen. For us,
a big part of that is navigating the Apple App Store and pricing and
testing both of those.
00:22:06 - Speaker 3: Yeah, that was, that was tricky in a lot of ways.
I think the assumption normally is if you’re in the App Store, you’re
a general availability released product and if you’re on test flight,
which is Apple’s system for distributing builds to test users, um, that
you’re in beta or still in testing. I feel strongly that the purchasing
experience and the price is a part of what the product is.
And you need to be to test that just as much as you do the what you
would call the core functionality of the app, but unfortunately, the way
that Apple’s payment system works is you can’t take live payments
unless you’re in the app store.
So we went through this little dance here where we basically implemented
payments, got the thing in the app store, but very specifically did not
distribute.
The the App Store link kind of kept that up, not quite a secret, but
you’d have to really be looking for it to hunt it down. And then at
some point, we switched from inviting people to our test flight beta,
which we’ve been doing for a number of months, to inviting them to the
App Store version and that had this pricing in there.
We were able to use that to get our first customers and essentially ask
them questions about What felt fair and what the experience was like and
things around this card limit on the trial and stuff like that, as well
as just to buy dialogue and what it’s like to get your receipt and what
happens if someone wants a refund and all of this kind of stuff. We were
able to test all that while we were in the app store, but we were still
in beta in the sense that our website says in beta and that’s the way
we position it. So now going live is really just pointing more people to
the App Store version, and then the test flight beta, uh, will basically
won’t won’t ship features there anymore.
00:23:38 - Speaker 2: Yeah, so as we were testing this App Store
version, we didn’t at the same time want to require that all of our
earliest beta testers who had made a big bet on us be forced to migrate
over to the new paid App Store track. So we’ve kept for some time our
beta app, our early beta users can continue to use that as is for free,
for some time and then at their discretion migrate over. So Lachlan,
I’m curious about your experience with the beta versus App Store.
00:24:04 - Speaker 1: Yeah, at the beginning, definitely like for all of
2019, it was not something that I would pay for cause it felt like I’m
using this and it’s like putting the data on the edge of a cliff, and
like, I don’t know if I’m going to be able to use this in 3 months.
It was really exciting to be using, but I definitely didn’t didn’t
want to be paying for.
Now, I still feel like even though I, I don’t have issues thinking and
stuff, it still feels Like putting it in a place where like, I don’t
have 100% confidence that like in a decade, I’m still going to have
everything.
And I think that’s, that’s a really important, like that kind of
security is a big part of like paying for a subscription for a work tool
is knowing that like, it’s going to be around and it’s not going to go
away and the data is going to be corrupted and it’s going to get lost.
I haven’t switched over to the App Store version yet. I’m still on the
test flight, but planning too soon. And I think we’re really moving
into an era, um, I think especially after when they’re sink, um, it’ll
really feel like I can fully invest and like fully plant my feet and not
be like, have always have one hand on a parachute that’s like, if this
all goes wrong, well, there wasn’t anything really important in here,
stability, trustability, that’s a lot of what you’re paying for in a
released product, even if the feature set is actually all the same.
00:25:17 - Speaker 3: As a particular beta sense that the company is
behind it, it’s here for the long term, they’ve done basic things
around, I don’t know what backup or data export formats or whatever,
um, as well as just the simple fact that what’s that heuristic where,
um, maybe you know it offhand, Mark, but there’s a heuristic where you
can basically say you can expect that something will be around roughly
as long as it has already been around for.
Um, and so you can say there’s a piece of software, I don’t know what,
you know, email’s been around for 30 years, it’ll probably be around
another 30 years, that’s a pretty good guess.
Um, and that’s always tricky with a hot new startup or whatever hot new
product, you get excited about it, what it’ll do for you, but the
reality is it’s just hard to know what the future holds, and even
though we’re really trying to make this a Built to last company and a
product, built the last product and Mark and I have even written about
this in the local first article long now and data the importance of your
data integrity and owning your work and all that stuff for makers.
The reality is just like, yeah, we have only been doing this, you know,
a year, uh, and change since we left the research lab maybe 2. 2.5 years
if you count the lab time, um, and so that’s over time it will get
easier to justify paying for it and just even aside from that, uh,
investing your data into it like you said, counting on it, um, not
because something changed fundamentally with the product, but just
because it’s been around and things that have been around are easier to
trust both companies and products.
00:26:48 - Speaker 2: Yeah, and even though clearly not everyone was
ready to jump from a beta type app to a paid app store. Generally
available app, we still thought it was important for us to take the
leap. We thought the right time to make that was when we felt like we
were ready to stand behind the products for the long term, and we felt
like we should have a non-zero number of people ready to make that jump,
because people are going to be ready at different times because of their
different use cases or their different relationships to this type of
software.
And we wanted to, as soon as Possible, but no sooner validate that there
were some people who, when they came in cold to the Muse website, we’re
going to be willing to pay $100 a year for the software. And I think
it’s a big milestone for us that we’ve gotten to that point. And now
we go through the long process of trying to expand the set of people who
fall into that group.
00:27:38 - Speaker 3: One place I take inspiration on that a little bit
is Uh, things like early access on Steam, or a lot of these Kickstarter
campaigns or even Patreon, maybe where when people invest and there’s
ways this can go wrong for sure, but often people will pay for something
that is still in development or even in the case of a lot of these
Kickstarter campaigns are really just a concept, and it blurs the line
between investing. In the sense of Investor and purchasing something
where I think when you choose to buy an early access on Steam, you’re
saying I, I believe in this thing, I want it to exist. I’m willing to
kind of proactively fund it, not for what it is today, but what it might
be 6 or 12 or 18 months from now and certainly my tendency is to want to
wait until something is really good and and. Uh, unequivocally worth
whatever the price is, but we pushed ourselves, our team, it was a
challenge actually, because I think we’re all craftspeople. We want to
have something we feel is just amazingly good, and we pushed ourselves
to charge a little earlier than we might have normally, partially
because we structured our company in a way that that’s necessary if we
want to survive, but partially also because we wanted to have that. Uh,
those people that wanted to support us monetarily, there’s certainly
the beta testers that gave us great feedback like you Lachlan and many
others. We’re very thankful for that. There’s other people who say,
well, I don’t have as much time for feedback, but you know, basically I
want this product to exist. It’s already fairly useful for me today. I
think it will be even better in 6 months or 12 months if you keep
working on it. Here’s some money to go do that and I’m certainly very
thankful to the folks that have taken that leap, uh, for us already. And
then it becomes kind of a a a nice kind of loop or self-fulfilling loop,
which is we, we charged maybe even a little before we were really ready
to do, but now we really feel motivation and the people that trusted us
and gave us that money early on. I really want to live up to what
they’ve, what they’re expecting from us.
00:29:32 - Speaker 1: I also have really enjoyed this model with a
website called Future Fonts. You can buy a font early on when there’s
just like one style or version and it’s still in development by the
designer, and so actually I found Hack Club’s font, it’s called
Phantom Sands on Future fonts, and we bought it early on when there was
like just regular and bold, and then over time they’ve added more and
like it allows us to do more with the typography as they add to it.
And so it does feel kind of like supporting creators with an idea where
they’re not sure if there’s going to be a market for it early on.
And I think Kickstarter obviously is is another example of that. I think
it’s really exciting and kind of blurs the the line of validation and
the traditional like startup MVP model of where validating and selling
can be happening at the same time.
00:30:19 - Speaker 3: I hadn’t seen Future fonts before. I’m looking
at their site right now. This is, this is amazing. I love this. It is
totally steam early access for typefaces, and that fits together well
also with, um, I think a lot of typeface designers are just independent
people and they’re probably taking time away from there. Client work or
whatever to work on this and having to wait until the thing is
completely done versus getting support, monetary support from people
that like what they’re doing, and then that also means those people
presumably get a better voice or input into the evolution of it, and it
is a kind of validation of a bunch of people. are interested enough in
your work in progress typeface to give you some money for it, then that
means you’re probably on to something and maybe you’re more motivated
or more just, it’s just more rational to make the leap from, all right,
I’m going to turn down that big client project so I can really crank on
this thing and get this typeface finished because I think I can, you
know, make a good chunk of my living from from this work. So going
forward, we’ve got a fully released product that will stand behind and
we’re charging money for and we hope to be as useful as possible to as
many creators as possible, but we still need feedback. We’re gonna have
new features including more radical, you know, there’s some features
and capabilities I think that are just obvious and straightforward to
implement. We need feedback and we need testing for bugs and whatever,
but then there’s also the more, let’s not call them quite research lab
wild ideas, but still. Slightly more, um, slightly more high gamble
ideas. Mark, what are some of the ideas or what are some of the
approaches that we want to use to continue to get this kind of high
quality feedback for work in progress stuff while also not disrupting or
cluttering people who just want to use the product’s stable features
and not be bothered with, you know, they don’t have time to get
feedback or interest or whatever.
00:32:04 - Speaker 2: Yeah, one thing we’re doing there is collecting a
lot of.
Feedback. So we have this feedback feature in the apps we can just
quickly pull that up, type some ideas and send us stuff. And that’s
relatively low fidelity, but we can pick up patterns there.
For example, a lot of people might ask about a smoother ink or being
able to add more ink colors, things like that. Um, and I think you
complement that with having still some people who you have a deep
relationship with. These might be testers who use the app from the very
early days and who we’ve maintained correspondence with. It also might
be new people that who for whatever reason you you choose to establish a
deeper relationship with them and have a video call or have an in-depth
email conversation.
00:32:42 - Speaker 3: Yeah, one thing I was thinking about a little bit
is you and I together worked on this thing called Haruku Labs.
Which we explicitly modeled after Gmail labs, Gmail Labs is a way to
kind of go to the settings page inside Gmail and turn on some features,
experimental features that they’re they’re working on.
So it goes into your real Gmail for lack of a better word, you don’t
need to use some separate website or separate product, but it turns on
this thing that they don’t offer any guarantees, it might not be
around, they might sunset it. It’s not yet, they haven’t yet decided
whether they’re gonna make that part of the main. Uh, product, and so
we borrowed that idea for Hirou with something called Hiroku Labs, and
at least I felt like that was quite successful in terms of making it a
lot easier to both experiment with, but also get feedback and real world
validation from, from users. I’m curious what your experience was with
that or what things you’ve done in other places for that same purpose.
00:33:35 - Speaker 2: Yeah, I think structures like that are really
important because the environment that’s conducive to doing early stage
validation and shaping is different from the one when you’re polishing
an existing product.
And when you’re first starting a company, you have that naturally
because the whole company is undergoing that metamorphosis from a very
early stage company and therefore early stage feature development
towards mid-stage company and mid-stage feature development.
But then once you’ve reached your first stable point, You want to go
back and add more novel risky features, so you need to sort of detach an
organizational container that can incubate uh that type of work, and
that can look like things like a labs type feature flagging system. I
think it can also look like structuring your time as a team, so you
might carve out and say for these 4 weeks, we’re going to build a
guaranteed to be throwaway prototype that we just try something and see
how it works, and you’ve cleanly delineated the experimental new idea
from the production app.
00:34:34 - Speaker 3: Lachlan, do you have any thoughts on what you
think Muse’s future should be, especially in terms of continuing to
experiment and try new things and branch out. We’ve obviously only just
gotten started, but now we have this core product that we want to be
stable and trustable. What do you think, uh, what do you think that
looks like?
00:34:52 - Speaker 1: Yeah, one thing that strikes me, it reminds me a
lot of IA writer at the beginning, back in 2010 was like using an app
that felt very opinionated and I think that one way that manifests
itself is that both apps had no settings, that like there’s no settings
pane where you can customize literally anything. I think early on that
makes a lot of sense because you can just you can like reduce the number
of things that you have to do in cases to accommodate for.
And also just like make a very clear statement to users about what this
is for, and kind of not fear, like making peace with the fact that
it’ll also drive away some people who wish they could change a few
things and it makes the app untenable for them. And so, I find one thing
in Muse that, you know, Iriter now has several panes of settings, and
they’ve kept a very distinctive voice and it’s stayed a very
distinctive piece of software and its ideology. And I, I see a similar
future playing out for Muse that like by default, it, it has very
opinion defaults and some of those things you can’t change. Like, I am
glad that I don’t have a full rainbow of 200 colors in Muse to choose
from, because that’s one of the reasons I switched to using it instead
of an app like Goodotes. And so I think there will be finding a balance
of like, well, there are a few settings that just dramatically expand
the range of users that want it, while also keeping keeping the
distinctive ideology um very present in the app.
00:36:22 - Speaker 3: I like your framing of talking about an
opinionated product. I writer is a great inspiration as far as that
goes.
And if you’re making something truly unique, it comes from with this
unique worldview and you and you’re conveying that through the product,
then you also need to mesh with the real world and the fact that just
different people have different needs and settings pages are one.
Example of how that manifests in the real world and so finding a way to
both mesh with the real world and accommodate what people need and want
is practically, but not losing your soul because fundamentally an
opinionated piece of software has something to say. There’s a
philosophy, a point of view that it expresses and too much ability to
change those things, you might as well just use a different piece of
software.
So I think that is a very nuanced, tricky balance, um, and it gets
harder as time goes on, and you have more users and more customers and
they’re asking for this thing and that thing, I got to have this, I got
to have that. And you get pulled in that direction by the simple
operation of the business, which is as it should be, you need to
accommodate the accommodate the practical needs of the real world, but
keeping that soul, keeping that fundamental philosophy or opinion alive
and adhering to what your reason for existence is, well, I think that’s
the ongoing challenge.
Well, I think we can probably leave it there then. If any of our
listeners out there have feedback, feel free to reach out to us at
@museapphq on Twitter or hello at museapp.com by email. We always love
to hear your comments and especially ideas for future episodes, and I’m
very much looking forward to Muse being a real product out in the world,
and Lachlan, thank you so much for your support and enthusiasm and
critique and just following along on. Story, it’s really, really
motivates me personally. I do this because I want to see makers make
things with the tools that I create and nothing, nothing drives me more
than both good enthusiasm and good critique.
00:38:16 - Speaker 1: Absolutely. It’s been a joy since the beginning
and I still love opening news every time. So thank you so much for
having me on the show and bringing me along on this journey.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: You’re saying come dream with me a little, and if
you get too much into the fantasy world, it becomes almost religious,
and that’s where you get something like a WeWork happening. But when
you can make the argument in a coherent way and are able to earn parts
of that argument, then that come dream with me can be extremely
compelling and can take outsiders along for the ride with you.
00:00:30 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac, but this podcast isn’t about Muse the
product, it’s about the small team and the big ideas behind it. I’m
Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. And
joined today by Mario Gabrieli of the Generalist.
00:00:49 - Speaker 1: Hey, great to be here.
00:00:51 - Speaker 2: And Mario, I understand that before your life in
tech, you were working in a Michelin star restaurant. What was that
like?
00:00:59 - Speaker 1: It was fascinating.
I should clarify that I was truly the lowest man on the totem pole in
the Michelin Star restaurant, so a lot of chopping vegetables and sort
of assembling geometric and intricate salads and ceviches and things
like that, but it was pretty fascinating to see what a high performance
team in that environment looks like, and I don’t think it’s so
different than a startup, you know, we had a very Strong sort of
charismatic but efficient leader, a really well run team and like
extremely high levels of motivation that, you know, I don’t know if
I’ve seen even that many startups that have that level of drive from
folks that were on their feet 1112, 16 hours a day, and obviously, you
know, it’s not the most lucrative industry, so there’s a lot of
passion and a lot of art in that that I respected a great deal.
00:01:53 - Speaker 2: I also feel like from what I’ve seen in the
restaurant business, you know, chef’s table and other fictional
representations that it’s almost has this performance element because
of the timing and the real-time nature of it, you know, a startup,
things may be fast paced, but ultimately, Maybe you, you know, ship once
a day if you’re a very focused, continuous deployment type team,
that’s something where you have, OK, it’s show time, you know, from 7
to 10 p.m. or whatever, dinner rush hour, all the food has to come out
together and be the right temperature and so on. It feels like, yeah,
there’s something almost theatrical to it.
00:02:30 - Speaker 1: Yes, 100%. It always felt very bad if I did a
plate that chef was like, no this can’t go out. You’re like, oh gosh,
I forget that we are judging it, you know, minute by minute here. Yeah,
that’s an interesting thing to adapt to.
00:02:45 - Speaker 2: Now the Generalist is a publication, if that’s
the right way to put it, I think so.
00:02:50 - Speaker 2: That covers business and technology. It’s
something I’ve been reading basically since you got started, absolutely
fascinating, very long form pieces that dive really deeply on a variety
of topics, but often profiling specific companies, and I’ll reference
some of my favorites there, but maybe you can tell us what the
generalist is for you and yeah, the story that brought you there.
00:03:14 - Speaker 1: Amazing. Yeah, I think you did a great job
describing it and have always very much appreciated you being a reader,
so I’m grateful for that.
The generalist is a what I hope modern media publication. We’ve started
out with our deep dives, which are once a week we put out a deep piece
of research usually about a company, as you mentioned, could be a crypto
project, a venture fund or a trend.
And the goal is to tell the story of that company in a way that both
surfaces what makes it interesting and unique and the lessons behind it,
but does so in a way that it really does feel like a narrative. And
that’s both, you know, I think because of my own interests in
storytelling and more sort of fictional styles of writing, but also
pragmatic, you know, I think we all remember stories much, much better
than we do. drier recitations of a subject and so the position of the
generalist has always been If you really want to learn about these
companies and the way that they’re impacting the future, the most
efficient as well as the most enjoyable way is by packaging it in this
sort of grander tale. And so the ultimate goal is, you know, build the
most thoughtful publication in tech that has the depth of research of
equity analysis, but a style that is closer to the New Yorker than a
hedge fund.
00:04:42 - Speaker 2: I think when it comes to business analysis pieces,
you might think of, for example, a high profile example would be stray,
and you know, his analysis is excellent, but it is pretty dry stuff.
You have to be really interested in the nuts and bolts and the inside
baseball.
Of technology companies and the industry and so forth, so yours strike
me perhaps differently maybe that you spend time on the personal
backgrounds of the founders and in many cases going back to who their
parents were and what brought them to this place, but also telling the
story in a context that’s I don’t know, it feels more like almost all
of your briefings me feel like there’s something that could be adapted
to like an HBO fictionalized, you know, TV show, not in like a
sensationalist sense, but in the sense of a gripping narrative that you
want to like follow through to the end, which is good because they’re
also very, very long and detailed.
00:05:39 - Speaker 1: They are very long. Uh, thank you, that’s very
kind.
00:05:42 - Speaker 2: To give some examples, we’ll link these in the
show notes, but just some ones that struck me.
One is the story of Telegram, which is a messaging app that basically
almost everyone I know here in Europe uses it, especially after WhatsApp
kind of went the Facebook terms of service route. And the backstory of
that fellow and his time in Russia doing social media and then kind of
his commitment to privacy because of that experience and just how huge
it is. It’s like, hey, it’s a little messaging app all my friends use
and it seems to be well executed, but the story there is pretty epic.
Another example would be one called Andoril, and this is a defense
contractor that uses software, and I think there is a natural, maybe
knee jerk to anyone who’s making weapons of war or something adjacent
to it, that that’s not a good use of computing or that there’s some
moral questions there, but I think you do a good job of making an
argument of why defense technology or war technology, which can be used
for defense and offense is important. As well as just telling the story
of this group that modernized it.
And the third one I’ll mention is more of a blockchain kind of web 3
world company which is Helium, and this one’s also interesting, and
maybe we’ll talk about your interest in the cryptocurrency and
blockchain worlds, but it’s one that I’m probably a little more
skeptical of and you seem to have more interest and enthusiasm for, but
perhaps reading some of these deeper dives gives me more of a sense of
like, OK, you know, there’s a lot of noise in this space, but there are
some interesting call them success stories there.
00:07:16 - Speaker 1: Yeah, I think the helium one is a good example of
how crypto can sort of divide people and you can look at the same set of
facts and come up with, you know, very different conclusions.
That one sparked a rather public debate on Twitter and amongst other
media publications of, you know, whether helium is a success story or
not, the usage is low, but the scale is broad, and so it’s always
interesting to see.
Which parts of the story matter to people? I think, you know, for better
or worse, when I see something extremely novel, working at least in some
really meaningful way, that to me is like extremely exciting, but you
know, I think there’s also plenty of value in people saying yes, but
here are all the things that aren’t working about it and, you know, the
rooms for improvement.
So that was a fun one and a stressful one.
00:08:09 - Speaker 2: And can you tell us a little about the journey
that brought you from, at one point, working in a high intensity
kitchen, and ended in creating this tech publication with these in-depth
weekly briefings?
00:08:22 - Speaker 1: Yes, well, it might surprise you to hear that it
wasn’t particularly linear. It was a lot of exploration and wandering
from one place to another. I, despite my very American accent, grew up
in London to an American mother and Italian father and sort of always
spoken an American accent at home, just a lot of code switching, and
came to the US for undergraduate, went to college and was very much of
the mind that I was going to.
Be a lawyer and then sort of move into the public sector. That was
definitely my sort of mental model of how people made impact in the
world and followed that, you know, rather assiduously through undergrad.
All of my sort of internships were on the hill. I was extremely into
mock trial and going every couple weekends to Iowa or California to
compete in these, you know, literally sham trials, which was extremely
nerdy and really had a pretty clear path there.
But at some point I decided I wanted to study abroad and You know, like
every good sort of truth seeking young undergraduate who has a passing
interest in Buddhism, I went to Kathmandu and spent 6 months there, and
it was extremely, extremely difficult, but also I think a valuable
lesson in dealing with one’s own narratives about oneself.
I know that’s sort of the topic of our conversation today, but You
know, I think we are all predisposed to either inherit lessons that
others have told us and take them as our own or develop them ourselves.
And in the isolation of Kathmandu, you know, it’s very hard to get
internet there. Time difference alone makes communication difficult. I
think I started to recognize the cracks in my logic, although it would
take a few years for me to. Sort of shake it all out.
So, left undergraduate, got a job at a law firm that had a very
interesting program in theory, which was, you know, you can do the work
a 1 or 2nd year associate at a law school might be able to do. You can
draft cross exams, you can write briefs. And so I got to work on some,
again, theoretically interesting cases, one of the first Madoff cases,
New York’s involvement with sort of reconstruction after Hurricane
Sandy, but really quickly realized like, wow, my brain does not work in
such a way as it is able to get enjoyment from this work. It is
extremely like detail oriented and really much less about storytelling
or writing or anything else.
Or even, you know, if you want to get sort of righteous about it,
justice or any of these other things, right? Like, once you see how the
sausage actually gets made, you’re like, oh, we spent 9 months working
on this case and then all of that was just to settle, you know, it was
all a sort of game of chicken, like that is infuriating. And so I sort
of realized, oh this is not gonna be the thing, and while trying to
avoid doing as little work as possible at the law firm, I started to
spend a lot of time on TechCrunch. And that was when I started to think
like, oh, actually a lot of the interesting things happening in the
world aren’t happening through government or nonprofits or anything
else. They’re happening through tech. That’s where the impact is
occurring, and that’s what is making a real difference. And so there
were several other steps from there that, you know, I’m happy to go
through, but that was sort of the moment that I started to become
interested in this world.
00:11:49 - Speaker 3: And did you jump right to writing about it, or was
there be steps between there?
00:11:56 - Speaker 1: Yeah, so I left the law firm. I had started at
that point taking night school classes at NYU in fiction writing. Always
loved writing growing up. I, you know, was writing a novel for most of
my teen years in one way or another, you know, I’d sort of get like 100
pages in and then start on something different. And so that always
really appealed to me.
And so I thought, OK, I’m gonna take a year. I’ll apply to grad school
because I need to be outwardly doing something. But really I will spend
the year finishing a first draft of this novel I’ve started in night
school classes. And take it from there.
So I spent a year doing that, got into grad school, and after I had
gotten into grad school and finished a draft of this book, I decided
then to spend that summer going to culinary school and cooking at this
Michelin star restaurant, which was a great like modern French place on
5th Avenue. Unfortunately it doesn’t exist anymore, but it was a ton of
fun. And then again, sort of another few chapters of this exploration
without a clear sight of what I was supposed to be doing. I did my
masters in international development with a focus on tech and emerging
markets. That to me felt sort of like a good interstitial, you know,
intermediary phase between this international relations, politics,
interest, and this sort of less certain thing about technology.
So I did that. I worked in Bogota for 56 months, one summer working with
like an incubator down there, getting to see these different startups.
And then once I graduated, I really sort of more formally entered the
world of tech for better or worse.
So joined a startup called Eco, which was a fast platform for
freelancers. We were acquired by Fiver after a couple of years and then
joined a venture firm called Charge Ventures. Which was preceed and seed
investing in New York. And it was while I was at charge that I basically
had an old boss say, you’re an investor now, it probably would be
useful for you to start writing about tech and sharing your thoughts
online. And you know, ever since that NYU night school class, I
developed this habit of getting up an hour or two before work to work on
my novel at the coffee shop, you know, around the corner. And so I sort
of was like, all right, like I think I know at least how to write a bit.
Let’s see what this could become. And so, yeah, the generalist was born
out of that little experiment and sort of quickly absorbed my interests
and enthusiasm.
00:14:36 - Speaker 2: Timing wise, I feel like you went all in on this
with a sort of paid subscription to your publication around the time
that paid newsletters generally were starting to get popular, being in
the zeitgeist, something like that.
We talked with Dan Shipper from every, they started their business and
were early on Substack.
There’s obviously, yeah, Substack is a platform, but also other ways of
kind of subscribing to individual writers or small groups of writers
where you like their perspective and their take and you’re willing to
just pay them directly versus the mediated stories that we get through,
whether it’s something like social media feeds, Facebook. Reddit,
Twitter, whatever, or even something like, you know, the classic kind of
magazine you mentioned, the New Yorker, The Economist or something like
that, that sort of bundles up, writing and reporting from many different
sources, puts it all through a copy editing thing and then you purchase
that bundle and this kind of direct relationship with a creator seemed
like that’s pretty new in the last few years and maybe you. I don’t
know what the order was there, whether you saw that that was kind of a
growing opportunity and you wanted to be part of that, or if you just
happened to start doing this around the same time, that was also an
emerging trend.
00:15:49 - Speaker 1: Oh, absolutely, it was definitely luck.
I had never read a sub stack before, but I remember seeing, I think, a
friend of mine saying they were starting one, and I was like, oh, OK,
for this new thing where I’m gonna write.
Every week I’ll just try out this new tool since it seems like it’s
interesting and it’ll be fun to use and that was, you know, I think in
sort of late 2019, and then I went full time on the generalist by August
2020, and it felt like the landscape had changed a ton during that time.
I mean, obviously COVID also massively impacted this world because I
think there was just such an appetite for Online content, but also the
way that the creator economy as a category in tech and venture capital
emerged and the legitimacy of being sort of an online solo writer
proliferated, both of those were, or all of those things were real
tailwinds for me in a way that I didn’t necessarily recognize at the
time. It just sort of felt like, you know, good luck, wish it was.
00:16:59 - Speaker 2: So our topic today is narratives. Now we’ve
teased at this already a little bit. You’ve talked about your interest
in narratives and certainly taking a class for fiction writing or
writing novels, you know, that’s the purest of narrative one that’s
pure invention of imagination. But here we’re talking about narratives
for real world events. It’s always good to start at the beginning. What
does that word narrative mean for you, Mario?
00:17:25 - Speaker 1: To me, a narrative is just a story, and it can be
either fiction, nonfiction, the real sort of part of it that I think of
is almost just like this unit of meaning that has been built in such a
way that our minds really grasp onto it and take meaning from it, that
is maybe different than just information or data, right? There’s like
this other element feathered or ribboned into it that Makes it extra
sticky for us because it follows an arc that our brains are just
predisposed to latch onto.
00:18:03 - Speaker 2: Yeah, I find myself mentally referencing
storytelling as kind of a closely related thing.
We did a podcast on that sometime back and talked about great
storytellers like Steve Jobs, for example, or the TED Talk format, but
one of the things I think that makes something a story as opposed to,
like you said, just data.
And it is especially relevant to, yeah, the business world where you’re
often talking in abstractions, what are the best practices for running
your startup, for example, or you do actually want data about a company
or you know the market, what’s happening in the market in terms of
trends that you as an investor or an employee or a company founder might
care about, but it’s much less powerful to present the abstraction or
the data like. People who don’t look both ways before crossing the
street are 20% more likely to be struck by a car versus telling a story
of one day Joe wanted to cross the street, he didn’t look both ways,
and he was turned into Broad pizza by an oncoming truck, and his friends
were all incredibly sad. And it’s just like, even with something as
dumb and simple story like that, that is more likely to stick in your
mind or have an emotional impact and therefore stick with you and maybe
make you think about looking both ways when you cross the street next
time than that first abstraction.
00:19:23 - Speaker 1: Yes, it’s fun actually to sort of brainstorm this
live with you guys a little bit, but it’s almost like data plus tension
or something. There’s somehow this notion of stakes or drama that
you’re adding to it that fundamentally changes that information and you
sort of only get that tension by tying it to something that we can
relate to or see some of ourselves in.
00:19:49 - Speaker 2: Yeah, certainly the concept of stakes or tension
or conflict is, I think, important in a story.
I remember watching a little bit of uh Master Class by Aaron Sorkin, who
I think is one of the great storytellers in the kind of television and
movie world, often doing workplace dramas, you know, something that
could easily be very boring, things like the West Wing, but instead
makes it really exciting and gripping.
And he talks about the fact that yeah, you need some goal and then a
thing that makes it really urgent to reach that goal, but then a thing
that is standing in your way. And the more you can ratchet up both sides
of that, the urgency and the difficulty that has to be overcome to reach
the goal, the more interesting and compelling the story is.
Mm. One of your articles I think it would be great to zoom in on, and
again I’ll link this in the show notes as you’re writing about soft
power and you contrast this with traditional marketing, maybe a little
call back here to where we started, which is you give the now very
classic example of the Michelin star, Michelin guide, restaurant guide
as a form of soft power marketing where essentially they wanted to sell
more tires because that’s what they. But that means actually just
expanding people’s desire to take road trips, and that means, or led to
this concept, which turned out to be a good one and a counterintuitive
one, that making a guide of restaurants that you might visit around the
country or around the world would be in the long game, a good way to
sell more tires.
00:21:23 - Speaker 1: Yes, it’s one of the weirdest business stories in
my opinion. Like you could never have pulled a management consulting
team together and said, hey, you know, we really want to sell more
tires, what’s your plan? There’s no shot they would come up with this
idea because it’s so sort of left field.
But even if they did, I think the average company at least would sort of
laugh you out of the room because it is just so orthogonal, but that is
also I think like what makes it so brilliant.
And I think it is potentially one of those things that is particularly
potent today, because I think we’re also all very aware of the
advertising we are receiving as consumers. And so the ability to tell
one’s story in this slightly more indirect way that appeals to the
fundamental parts of one’s business, I think can be extremely powerful
and is probably under leveraged a lot in the tech world and beyond.
00:22:22 - Speaker 2: Yeah, well, it is a long game.
You give a lot of other kind of more modern examples in the story, one
that I think folks who listen to this podcast will be quite familiar
with is Stripe, and they have a lot of sort of initiatives in this
realm, but Stripe Press is a good example, and you could wonder how in
the world publishing these books about human progress or stories that
are obliquely related to things that nerdy technology people are
interested in. How does that help them? You know, sell more credit card
processing. But at the same time, it has been incredibly powerful for
their brand, which you could think of as a recruiting thing, maybe if
just, you know, tech nerds like a company, then they’re more likely to
go work there, but I think you’re saying there’s more to it than that.
00:23:09 - Speaker 1: Yeah, I think the way sort of I have thought about
breaking soft power down is into these sort of two constituent parts.
You have the core message, the real story that you’re wanting to tell,
which, you know, in Michelin’s case is something like, you know, the
world is smaller than you think.
And then you have to find the vehicle that helps you tell that story in
a way that doesn’t feel like marketing that is indirect but still
powerful. And so with Michelin, they had the Michelin Guide, which is
all about discovering great destinations within a driving distance.
Stripe, I think, has something pretty similar going on, which is, if you
really abstract back from Stripe. Almost main thing that they are trying
to say it feels like across their different vehicles and initiatives is
that progress really matters. It isn’t an accident, it requires
intentional work. And when you sort of see it through that lens, things
like Stripe Press, even indie hackers or their sort of developer
magazine increment.
Actually start to, I think, make a lot of sense for reinforcing that
story. And when you have a story like that, I think it Has power in ways
that are often hard to define.
Yes, it definitely I think helps with recruiting. It helps because it
separates you from every other payments company in the world, right? No
one gets cachet from working at PayPal and anything like the same way as
they do at Stripe or Adan or whoever else. It also, I think allows them
to sort of command a much bigger territory than they might control right
now. Because Stripe is always talking about things on this historic
civilization scale level. When Stripe then says, hey, we’re gonna do
crypto, you never really feel like, ah, they’re not gonna be able to
pull that off, or like, are they really dedicating time to that? You
always get the sense they have thought about it extremely deeply, they
are aware of the big moves of history and are willing to dedicate real
resources and time to whatever they put their minds to. It ends up
having a broader reach than many other traditional companies, I think.
00:25:27 - Speaker 2: I wonder if this connects also to the startup
approach, I guess, which is one often of wanting to change the world and
obviously that term has become almost a little bit hackneyed, but it’s
true that usually you’re trying to do something disruptive in the sense
that there’s some corner of the world, even if it’s some little piece
of business software or some big piece of infrastructure software like
payments, and you think that the way it’s done now is not as good as it
could be.
But the improvement needed is not an incremental one. It’s not the sort
of thing that, for example, if you’re working in payments or you’re
working in social media or you’re working in thinking tools, say you
think that the companies that already exist there aren’t really in a
position to kind of incrementally go to this new world that you picture
because maybe it includes some sort of contrarian takes or some
discontinuous jumps.
And so, in building the startup and trying to make that jump to this new
world, there’s like a worldview, and in some cases that can be almost
cult-like in some senses, you come to believe that almost, you know,
there’s a fine line between vision and delusion that the world can be
more the way that our mission describes.
And to believe that is this leap of faith, and we all have to have a
almost vaguely cult-like belief in that, but that needs to extend beyond
our team, and certainly it’s recruiting and certainly it’s investors,
but it’s also customers. And this is something we saw pretty
dramatically at Hiroku, which is when I wrote this manifesto, the
twelve-factor app, that really made a difference for customers
understanding and getting in the headspace of what we were doing, which
is making it possible to deploy apps in this true cloud native way that
made servers less relevant or even not a part of the equation. And that
was a confusing jump for people, but once there was this I don’t know,
philosophical piece that described that in a way that was somewhat
independent from our product that that could have more weight or you
could engage with it on a level that was less of a, here’s some
propaganda trying to get me to buy a product and more like Maybe here’s
some propaganda getting me to buy into a worldview, but if you buy into
that worldview, the product makes sense. Now, once you’re in that
worldview, maybe there’s multiple products that you might choose to use
or multiple tools or whatever that would work there, and then those
tools and products can compete on their relative merits within that. But
first you have to buy the worldview or else the product just doesn’t
even make sense.
00:27:57 - Speaker 1: Yes, I think that’s a really well articulated way
of putting this.
You’re sort of saying come dream with me a little, and if you get too
much into the fantasy world, it becomes almost religious, and that’s
where you get something like a WeWork happening, but when you can sort
of make the argument in a coherent way and are able to earn parts of
that argument.
I think then that come dream with me actually can be extremely
compelling and can take outsiders along for the ride with you. I think
you guys do this, you know, a lot with Muse too, right? Like there are
probably many more dry and pragmatic ways of describing what you’re
doing or presenting what you’re doing, but the way that you guys
obviously seem to think about it is as this. Sort of step forward in the
way that we’re able to think with computers. And so, I would submit
that you guys are probably doing a lot more in terms of soft power in a
very intelligent and thoughtful way than most others.
00:29:02 - Speaker 2: Oh well, thank you.
Yeah, I mean, part of it just comes from our personal motivations to, it
is in many ways the world we want to see come true is, I think.
Equally important, perhaps even more important than the business
itself.
Now, we have a duty to our team, to our customers, to investors, to,
yeah, a fiduciary duty, in fact, to make the business be successful, and
you do have to pay attention to those pragmatic needs and try to sell
your product and otherwise make the business successful, that’s all
important.
But there is this element where I care more about seeing these ideas,
whether it’s people being a little more thoughtful in a world of social
media and hot takes, or maybe some of these technology pieces like local
first sync and the benefits that has over cloud or infinite canvas and
why I think that’s a really interesting document type as compared to
the classic top to bottom linear documents of text. And I hope each of
those ideas has a chance to succeed on its own and part of what we’re
doing here is bringing those ideas forward.
And you know, if they all come together well and we put that together
with a product that’s well made and the right price and the right go to
market strategy and all that sort of thing, it can be a very powerful
combination. And some of these examples that you’ve named here like
Stripe or some of the others that are listed in your article, they’ve
managed to do both of those together, which makes them into these
incredible juggernauts. We’re not a juggernaut, at least not yet, but
certainly, No matter how things turn out in terms of overall success of
the business, if I can look back and say we had some really compelling
ideas and a better vision for the way the world could be or some piece
of the world could be, and we helped to advance those in some way, and
that those goals are just as valuable to me as the kind of more
pragmatic success of the business.
00:30:51 - Speaker 1: Yes, I think as a result, you know, if you were to
describe or someone was to describe Muse as a whiteboarding app, you’d
be like, oh, that doesn’t feel quite right, you know, that feels too
simple or not sufficiently thoughtful. And I think a lot of other
companies don’t necessarily earn that elevation, or don’t even try for
it per se.
00:31:11 - Speaker 2: Yeah, which is always a trade off when it comes to
just the pragmatic side of the marketing.
I mean, we do on our website at the moment say include whiteboarding is
one of the things you can do with Muse cause at some point, There’s the
loftier things of let’s be more thoughtful or let’s use a computer or
the capabilities of computers to help us be more thoughtful, but at the
same time, then you go, OK, that sounds nice, but what actually is it?
And he goes, well, it’s kind of like a whiteboard, right? And then it
does feel very reductive and if you have just that, I think it’s too
simple and doesn’t make clear what we’re trying to do.
But you need both, you need this simple reductive piece just to
understand what actually it is, and then there’s the other pieces that
maybe help elevate and help frame and help put into a context that
hopefully makes it matter more.
00:31:58 - Speaker 1: Yes, agreed.
00:32:00 - Speaker 2: Well, next, I’d be curious to hear a little bit
about the business side. How does the generalists work in terms of how
big is the team, how do you work together, how do you make your money?
It’s all well and good to have these extremely long and detailed
write-ups, but how do you make this work as a not only a full-time gig,
but indeed a whole business.
00:32:21 - Speaker 1: Yeah, so the generalist is right now 2 of us full
time, and the two of us full time are married to one another, so it’s
me and my wife.
00:32:31 - Speaker 2: How does that work out in practice?
00:32:33 - Speaker 1: Honestly, fantastic. I know that there’s a lot
of, I think, reasonable apprehension about working with one spouse, but
I think if you end up having complementary skills. It can be extremely
powerful because hopefully you have a large long track record of solving
problems together that is useful in the business realm as well, and also
just so many shorthands for things and, you know, depth of understanding
that would be quite hard to replicate with someone fresh. So, I started
the generalist part time just as a little side thing in 2019. Went full
time 2020, and my wife Alessandra joined around this time last year, and
we had thought about it for a long time.
She comes from a creative production background and had always been a
really important sort of advisor to me and the person I would talk
through strategic decisions with and I’d always wanted to see if I
could sort of poach her, but as she decided to sort of look for a new
chapter, she took some time off and Started to think about it more
seriously and yeah, thankfully we gave it a shot. So it’s now, as I
said, about a year in and has been definitely a step change improvement
for the generalist in terms of what we’re able to take on, the level
that I think we’re able to execute at both hopefully on the writing
side and beyond, and I think just puts us in a much better position sort
of going forward. The business itself has, I think, very fortunately
continued to grow really well.
So the main ways that we make money are through sponsorships and then
through the subscription to our private community. The big change for us
was actually initially that we had a subscription for extra content or
you know, roughly 50% of the content wepagated.
And the big lesson of 2021 on that front was that actually that doesn’t
really make sense, particularly for a business like the generalist. The
content is, as you might expect, quite general, and as a result, you
might have one week where the topic is extremely important and, you
know, immediately valuable to you. If you’re a crypto investor, the
week where we publish 15 sort of snippets about interesting crypto
companies is like, yeah, a no brainer, you would definitely have paid
for that. But the next week when we’re talking about, you know, the
playbook of Stripe or something else might be outside of your
wheelhouse. And so I think by having this broader approach, it means
that a sponsorship model makes more sense. And so yeah, we made that
switch, it was Yeah, clearly the right decision and also ended up being
for the benefit of the subscription side, limiting that just to the
community, I think increased the perception of how valuable the
community was and improved conversion because I think it was just a
clearer sell that if you want a community, great, this is what you’re
there for, and that made the messaging a lot easier.
00:35:52 - Speaker 2: It’s also always tricky, I think, in the content
business to decide where those paywalls go, like you said, which
articles are behind them or not, or is it that all articles are readable
from the beginning, but then you at some point halfway down where it
says, you know, enjoying this article, please become a subscriber and
anything like that is going to limit the spread of your content, which
sort of limits your top of funnel. So it’s always a difficult
trade-off.
00:36:18 - Speaker 1: Yes, I think also. I still have not at all cracked
like which pieces will go viral when, which ones are gonna be the ones
that drive a ton of new sign ups, and so having sort of more swings at
that and not saying, oh, actually, you know, 50% of these are only gonna
go to a small audience because their paywalls has been important as
well. So yeah, it’s been really interesting and hopefully we’ll
continue to get sharper on those different aspects of it.
00:36:50 - Speaker 2: And I’d love to hear about your creative process,
how you pick subjects for your stories, what the research looks like, or
how you get access to what’s occasionally inside-ish information, and
then, yeah, with the writing process of like, especially with such a
small team and a relatively demanding schedule of weekly publications.
00:37:10 - Speaker 1: Yes, process may be too generous a word for what
is me sort of feeling like my hair is on fire a lot of the time and
running to learn as much as I can as possible.
It does sometimes feel like I’m just sort of trying to shove as much
information in one ear and then, you know, a bit like final exams. By
the time the next weeks happened, you’ve sort of forgotten about 50% of
it, but it’s extremely fun, so that’s the part of it that I think
makes it addictive.
The process goes sort of something like this, which is, I think
hopefully a few weeks ahead of time, what pieces I want to write.
For the first time ever we’ve actually like booked our content calendar
out for the rest of the year, which is kind of a miracle, but usually it
was much more short term. Then there’s sort of usually a bit of time
where I’m thinking it over in the background while I’m working on
pieces that are coming up.
Two weeks beforehand I would say I really start seriously doing my own
research, reaching out to people from the different companies, their
investors, customers, jumping on calls, sending them questions, and then
the week of the piece itself is. You know, a little bit of chaos in
terms of the writing front.
So Mondays tend to be pretty relaxed where I’m getting to do those
things like having calls and doing more passive research. Tuesday’s a
little tighter. Wednesday I’m like, OK, I have to get an introduction
written, otherwise I’m gonna start feeling terrible tomorrow. Thursday
I’m usually like, ah, I’m a little behind, like, let’s go a little
faster.
Friday I can’t do anything else but write. I just have to, you know,
make sure that is entirely clear.
Saturday the same, you know, you’re very much in sort of the bunker
where nothing can disturb you, and then Sunday is unpleasant where I
sort of like get up at 4 a.m. usually cause I’m like, oh God, I didn’t
finish this, like, there’s something that isn’t quite right or
there’s something I’m missing.
And so my poor wife will have the Amazon Alexa chirp 4 a.m. I sort of
trudge out into the office and then by the time she gets up, hopefully I
have something for her to take a read at. And then it’s just a, yeah, a
mad dash to the end.
There are some images to do, there’s some graphs to pull together, and
then we publish. And so that is probably not a scalable solution. But it
has worked for now, and I will need to find new solutions as we grow.
00:39:42 - Speaker 2: I got a small peek at how you guess research
information from sources insofar as you were writing an article about Y
Combinator and their whole now pretty long and storied history. I had a
very small piece of that insofar as participating pretty early on.
And you sent me just a little, basically Google Doc questionnaire with
some questions about what I see and, you know, just prompts for me to
reflect on the experience, and I don’t know, there was, forget if you
quoted me, or maybe there’s just a paragraph or something that
mentioned some of the things there, but assuming that’s reflective of
how you do research normally, How do you identify the sources? Yeah, how
many people do you try to talk to? Are there some, you know, they’re
really canonical source, and if you can, you get a, you know, 3 hour
interview with them, what does that process look like?
00:40:33 - Speaker 1: Yeah, I’d say that’s reasonably typical and
grateful that you were game to share your thoughts. It depends a lot.
So, for example, when you’re writing about a lot of these mega funds,
like when I wrote about Tiger. Or I just wrote about SoftBank this past
week, you can pretty much never get the people at the company to really
be on record at the very least, and so then it’s a little bit more
thorny, where you have to find folks that maybe used to work there or
have interfaced with them as founders or co-investors.
There is often one person that you end up finding who can kind of give
you the scaffolding of the whole story, and that’s when the story like
totally transforms in your mind and it’s like such a relief, you know,
you get these kind of episodic things and then someone who has been
there for enough time can say this happened with Tiger, for example, can
say like, hey, here’s actually how it went, and here’s how people were
thinking about it at the time, and here’s why we made this decision,
and same for several of these others, and that is when it like.
Ah, you’re like, I got it now, but often you don’t find that.
So sometimes there’s stories where I haven’t been able to talk to
anyone. That’s increasingly rare now that the generalist has gotten,
you know, larger, and then yeah, there’s plenty of times where you
actually get to talk to the people behind the scenes or, you know, who
are running these organizations, so. Jeff Ralston at YC was generous
enough to sit down and do an interview. Lots of the CEOs of the
companies I write are now sort of open to have these conversations,
which is super helpful. And in the very, very rare cases, you get
someone, you know, like a Sambankment Freed who is like, hey, here’s
our whole data room and lets you kind of run riot, and so that’s
unusual but possible.
00:42:23 - Speaker 2: Yeah, it seems like now that you have a track
record of writing these thoughtful pieces that dive deeply and in
general, I would say that they’re certainly not puff pieces, but
you’re writing about the company because you think they have done
something impressive, important because they have this incredible story
to tell, and so Given that track record, it seems very desirable indeed
to be covered by you and getting to give the information from the
company, rather than from perhaps ex-employees who might have their own
ax to grind or just a smaller piece of the picture. I could see why that
would be valuable to them.
00:43:00 - Speaker 1: Yes, thank you. Hopefully that it continues to be
the case. I definitely do probably 95% filter for things that I, a
priori, I’m like, this is an amazing company doing something really
interesting that we have a lot to learn from. And I always, you know, to
your point, want to identify the risks and the parts of it that maybe
aren’t working or could fail, but I don’t think I would find it super
fun to pick companies that I thought were, you know, poor. And so that
does help in terms of allowing for collaboration.
00:43:34 - Speaker 2: Yeah, certainly haven’t fallen into the what I
feel like there’s an increasing trend, maybe it’s people outside of
tech, but where there’s almost a sort of joy in documenting a mess,
whether it’s WeWork or you know, maybe Uber, like I feel like both of
those had even TV shows that kind of dramatize. their worst excesses and
didn’t put a lot of attention on the hard work or the technology
innovations or things like that, which is totally fine. There’s room
for things that aren’t necessarily, you know, pro-technology and indeed
are questioning maybe some of the worst excesses of the industry.
But yeah, even in, you mentioned the Softbank story. I had read a little
of that actually just before our call, and certainly there’s a lot of
ups and downs in that story, and the ending is not clear, you know, is
this gonna be one that’s looked back on as an epic success or Or one of
these like hilarious laughable failures or something in between, we
don’t really know when you’re trying to sort of document it midstream
with what we know so far and hopefully in a way that is fair to all
parties involved.
00:44:44 - Speaker 1: Yeah, I hope so. I think that’s the part that for
me is really interesting is this little gray zone where for the most
part, you know, none of these companies, well, no company is perfect,
right? There’s always some aspect of it that is working or not working,
that is maybe poorly thought through versus, you know, brilliantly
strategized.
And SoftBank I think is, you know, at both ends of the spectrum at once,
perhaps more than many others, where there are some things they do where
you just think, oh gosh, why would you have done that? That doesn’t
seem to make much sense.
But then when you sort of put it in the context of their whole story and
How Masayushisson has made and lost and made fortunes, it all starts to
kind of make sense and you can see a little bit of the intelligence
behind it, even if it doesn’t work out. And I think that’s always fun
because you don’t want to write off an idea entirely, I think a lot of
the time. A lot of the time maybe there was some merit to the idea, it
was badly executed or the timing was off, or, you know, we were just
looking at it from a perspective that wasn’t complete. And SoftBank is
a little bit like that, where The Vision fund has, by most accounts, I
think, especially VF one, which we have more data on, performed very
poorly. But there was something to that idea of like, how do you
capitalize a leader so that they can take the long term bets that the
market won’t kind of let them do? How do you give them the latitude to
make those big swings themselves? How do you create a monopoly through
capital? Like those are not obviously dumb ideas. The way they were
implemented, you know, left a lot to be desired, I think, but I love at
least sort of trying to wade through that.
00:46:35 - Speaker 3: Yeah, and I think this topic of what does one
write about is actually a really important aspect of narrative that
maybe we kind of skipped over in our original discussion because
there’s all these things about the narrative once you’ve chosen it,
you know, the form and the content, whether it’s oblique or, you know,
there’s all these different aspects, but maybe the single most
important thing is just what you choose to speak about and therefore
bring attention to.
And that actually becomes one of the most powerful things that a
narrative teller wields.
Now you tell some good narratives, people realize that they start to
listen to you, and then when you get up to deliver your next one,
they’re by default going to pay attention to the thing that you start
speaking about. It’s very powerful.
00:47:14 - Speaker 1: Yeah, that’s so true. Every narrative feels like
there’s something you’re highlighting and something you’re pushing
into the shadow, at least to some extent, and the way that you decide to
draw that line between sort of light and dark, you know, bright and
shade, whatever that is, obviously entirely changes the story, right,
which is, you know, I think why you can get so much disagreement.
00:47:37 - Speaker 3: Yeah, and I would argue that it’s not just light
and dark within a given topic like within SoftBank or whatever. It’s
SoftBank versus semiconductors versus shipbuilding, right? You know,
which of these is more important, the world is so vast and there’s so
many things going on. There’s no way you can pay attention to all of
it. So a critical aspect of narrative becomes, what am I going to speak
about and what am I going to pay attention to?
00:48:01 - Speaker 1: Yeah, totally.
00:48:03 - Speaker 2: I think that touches on something that I like
about the creator economy perhaps, which is I’m choosing creators I
want to follow partially because I think they have good taste or
judgment about what’s interesting.
So yeah, YouTubers who are film critics, your work, Mario, where just by
seeing the title of the article and knowing what company you’re
covering, it may take a company I’ve heard of that I just don’t have
much. Feelings on or knowledge about and it just instantly makes me go,
OK, there must be something really interesting there because Mario chose
to write about it because I trust that he has a good nose for what’s
interesting in tech.
And I think that’s the same thing is true for yeah newsletters I
subscribe to, for example, people that do political analysis where just
literally they’ve chosen to write about a given topic automatically
because I already trust their judgment about what’s important in the
world and what’s worth giving our attention. To that already elevates
the subject to me. And of course, if I read a lot of their work and I
find that I’m not getting the payout from the pieces that I feel like,
why did they write a piece about this? This doesn’t seem that important
or just relevant to me, then that might make me lose interest and it
really is that I guess you could have a version of that for more classic
media, which is OK, if the economist wrote about this, it must be
interesting or important, but for some reason there’s something about
the individual or the judgment of an individual person. And that’s what
kind of what you get with the creator economy.
00:49:32 - Speaker 3: Oh man, I got a whole theory, we could talk about
some time about the difference between sole proprietors and people in
similar positions versus people in larger corporations, but I think
it’s a super important point, and I also agree Adam, I tend to listen
to individual narrative weavers because They are putting their own
reputational capital on the line and they’re making their entire living
from that, right? And there’s no ability to, you know, you might say
draft behind or parasitize a larger reputational entity, which the short
version of my argument is that that temptation becomes overwhelming when
there’s a huge reputational draft that you’re sitting behind. It
almost doesn’t make sense to invest in your own research and writing
when you could just latch on to the behemoth draft behind it, whereas
you know with an individual. There’s no choice but to make a valuable
product.
00:50:22 - Speaker 1: I think especially in media because the behemoths
have so well served true news, like breaking news, and that, you know,
doing that requires such massive teams to actually sort of be in the
mix.
It’s almost forced the smaller players to say like, OK, let me look a
little further afield and make time less of a variable.
And I think that often leads to more important stuff or more interesting
stuff, because a lot of the time the things that these bigger
publications are telling you are important, they are important only
because they just happened, and for these smaller publishers, they’re
saying, no, no, no, it’s important for all these actually other
interesting reasons that might actually appeal to you in a deeper way.
00:51:11 - Speaker 2: So in the creative process you described, it may
be a matter of weeks from when you start researching something or you
have a hunch about it to when you’re publishing this finished piece,
and certainly the pieces come across as authoritative is quite the right
word for it, but it’s not like a, here’s Mario’s blog and here’s my
opinion, man. It’s clear you’ve researched this substantially and
you’re trying to present. The facts again in that narrative frame
you’re telling a story, there’s emotional impact, there’s conflict,
there’s tension, but in the end you are also documenting something true
and real about the world. How do you find it is this sort of like
learning on the fly and then needing to publish something authoritative?
What is that experience like? Do you ever feel like you’re wrong or you
got it wrong later on, or yeah, what’s that like?
00:52:04 - Speaker 1: Yeah, in many respects it sort of forces you to
fall into that phrase often wrong, never in doubt. You’re forced on a
weekly basis to create massive conviction and understanding on a topic
where in some places you might be starting reasonably close to zero.
Like maybe you understand the moving pieces, you understand what venture
capital is or you understand what crypto is, but Looking at an entirely
new project that’s doing something different or a fund with a totally
different strategic approach takes time and trying to do that in sort of
a speed run, I think has some real benefits but also definitely some
drawbacks.
I mean, the benefit is that you, I think, have to really sharpen your
thinking as quickly as possible, talk to people much more intelligent
and knowledgeable than you about this subject, which is a huge gift. And
then sort of, you know, commit to something that you want to stand
behind and that you know that 60,000+ people hopefully are going to take
a look at many of them who might have worked in that industry for
several years, some of them who might work at the company, and they will
know how much of it is true. And then, you know, there are often moments
where sometimes you get that really right and I think for example,
SoftBank is one that From what I have heard so far, I think I got it
mostly correct. But then there are also cases like Tara, where I wrote a
piece about Tara and I touched on the danger of a death spiral and
outlined that risk, but by and large, I sort of made the position that I
thought it was an interesting venture style bet, like huge upside,
definite downside, and you know, that was 100% wrong. And those are the
parts where learning in public. can feel painful where you look back on
your old self and you think, oh, how did I overlook this or how did I
get that so wrong?
00:54:00 - Speaker 3: Yeah, I can definitely see how it’s challenging.
One of the interesting results that we keep coming back to on the
podcast, this idea of the robustness and power of teaching and
learning.
If you look at whether it’s the master apprentice relationship, whether
it’s teaching hospitals, whether it’s the academy, it’s traditionally
conceived, whether it’s the cities that have the highest concentration
of any given industry.
The act of teaching and learning just has some really powerful way of
helping people climb the learning curve faster. It always feels messy.
It feels like it shouldn’t be the case that teaching hospitals, we have
all these students running around, should have good medical results, but
just because you’re constantly going through the motion of teaching and
learning, it somehow triggers something in your brain where you learn
faster. And so I think that’s related to this idea of working in
public. You know, it does have a personal element, has a marketing
element, but there’s also something to actually get into the truth
faster.
00:54:49 - Speaker 1: Mm, that’s super interesting. So I’m actually
not familiar with like the data about that. So when these teaching
hospitals tend to outperform those that don’t have, you know, a similar
structure.
00:55:01 - Speaker 3: You know, I would want to go back to literature
before I made a really definitive statement here. I feel like I’m
recalling this from a Gande book, who is a doctor who wrote about the
practice of medicine, and that’s kind of an interesting
self-referential thing there.
Yes. But anyways, I think you. Without looking at the literature, I
think we could agree that a lot of the best hospitals in the country are
so-called teaching hospitals, where it’s not all doctors at the top of
their game.
A lot of it is these medical students, you know, they basically don’t
know what they’re doing yet. They’re running around, they’re doing
procedures for the first time. They’re getting instructions from
doctors on the fly, you know, all this stuff, and there are risks and
challenges with that for sure. But It seems to be that it nets out
pretty well, at least better than you might intuit given just the raw
where these people are at in their career measurement.
00:55:48 - Speaker 1: That’s super interesting. I really like that
analogy, and I, I’m gonna try and sniff out where it comes from to
learn more, so I’m glad to know it.
00:55:58 - Speaker 3: Yeah, and it’s, that’s completely wrong. Our
will tell us and we will do some learning in public.
00:56:02 - Speaker 1: I also want to know what osmotics are.
00:56:05 - Speaker 3: I I don’t know if that’s the thing.
I wrote it down when you mentioned something earlier about you learned
or someone was learning from the people that they’re around.
One of my long term theses is that the way people learn and develop
values and change behavior is just by osmotically observing and subtly
copying the people around them, especially in childhood and early
adulthood.
And so, for example, there’s all these theories and practices about how
you Teach kids stuff and how people learn, and what the purpose of
college is, and I so often see people missing what I think is the main
point is just like being physically next to people who have some mores,
some values, some ways of being, some habits that are what you basically
want to copy.
I just feel like people weigh under index on this.
00:56:56 - Speaker 1: It’s interesting. There was this, I think it was
in the Atlantic where they published a piece detailing the results of a
fairly extensive research project into the effect postal code has on
outcomes later in life, and it was basically something like your
child’s earning potential is 25% determined by The zip code in which
you live, and they created a massive map where you can search by zip
code, like what the outcomes are, and I think the point that, you know,
they were making or the sort of conclusions were that being around
people who have stable jobs and stable family structures and act in a
certain way and value certain things, like all of those actually.
There’s a certain amount of uniformity or presence versus absence in
these different zip codes, and that like has a huge impact on a child.
00:57:52 - Speaker 2: As the parent of a toddler, I can say they are
absolutely imitation machines.
You know, there’s the things that you sort of want to quote unquote
teach them, they sort of copy you on, but they copy you on everything,
even the things you don’t think you’re teaching them, and I think that
extends into adult life as well.
I always like this concept, I don’t know that it’s scientifically
supported, it’s more just a folk philosophy, if you like, but that you
are The combination of the five people you spend the most time with, and
so, choose your friends, colleagues, whatever with care, not just people
you like or drawn to, but also that are people you admire and you want
to be more like cause you will be more like them whether you like it or
not.
00:58:33 - Speaker 1: Yes, that’s so true.
00:58:33 - Speaker 3: And I think this ties back to our narrative
topics.
We were talking about narrative as the zero step is you choose to talk
about.
And so, if you are what you’re surrounded by, and the narrative
environment is what you’re surrounded by, basically people tend to
become Whatever the narrative choices are of the people that they look
up to.
It’s actually extremely hard to have original thoughts.
At best, most people are just recombining narratives that they’re
existing within. So it becomes very important and powerful in terms of
what the narrative environment is. And we see this all the time because
there are these super important topics in retrospect that just weren’t
on people’s narrative map at all. And they get blindsided. And it’s
not because at some point they sat down and said, what are the most
important things in my world, and they picked wrong is they never did
that. They just, one of the top 5 narratives in my environment and, you
know, that was quote unquote wrong at some point. On my current example
here is the whole energy infrastructure thing, but we could pick a
zillion examples.
00:59:33 - Speaker 1: Yeah, it feels like it’s why one of the most
generous things I think someone can do for a friend or a child or a
colleague is just to sort of recognize and tell them that they can
probably do an order of magnitude more than they might be sort of
mentally expecting of themselves in a given moment. Like I think we’re
very accustomed to sort of Acclimatizing or matching our ambition to the
people around us and the things we see, and having someone who can say,
no, no, no, don’t worry about that. Like, the thing that you can do is
100 times greater or 100 times more wild is such a crazy gift.
01:00:14 - Speaker 2: And perhaps that is part of the power of Silicon
Valley, and the idea that this is a place you can come to do way more
than not only that you thought was possible for yourself, but that you
thought was possible at all for any person.
01:00:30 - Speaker 1: Absolutely. It feels like there’s sort of an
interesting moment for tech from a narrative perspective where I do
think Silicon Valley definitely has some of that story still. But it
feels like in many respects outside of the tech world, it is perceived a
little bit like, you know, banking might have been around 2008 or, you
know, something like that where it has sort of become the synecdoche for
Excess for fantastic visions without enough meat behind them for sort of
the tech bro hubris, yeah, whoever the hubris of mankind, yeah,
01:01:13 - Speaker 1: which I think is a pity, and that is a narrative
that I hope we can in the generalist in some small way and through many
other things, try and correct to an extent because really tech is such
an engine of progress that we should be wanting. To work and absorb more
of people’s energies and efforts.
01:01:36 - Speaker 2: Indeed, I feel I see that theme in all your
writing, which is, even without it being spelled out, it seems that in
telling these epic stories in Choosing the companies that you do choose
to talk about, talking about the challenges ahead, but the way that
they’ve changed things, there is a kind of optimism or positive outlook
on technology and how it is already changing our world, and what more it
can do to change the world in the future, and that that is something
that should be celebrated, the companies should be celebrated and the
founders and the leaders who helped bring that stuff to pass should also
be celebrated.
Now that’s not that they get a free pass for bad behavior or mistakes
or failures, but rather that overall there’s something good here and
perhaps in some contrast to what’s an increasingly a mainstream.
The idea that, yeah, tech is a place for greed or manipulation or as
sort of a net negative on society, that indeed reading through the
generalist pieces, you come away thinking this is a net positive
already, and it’s only just getting started.
01:02:43 - Speaker 1: I hope so, yeah, you never want it to be this, you
know, hang glossy and look at tech and everything is so amazing and
these people are perfect.
All of the corruption and excess and all those other things make for, I
think a good story and make for that tension that we talked about, but,
you know, compare it to so many other. Industries and the level of
invention and progress it contributes I think is hard to argue with, you
know, we want, I think people who are very willing to take big swings to
maybe fail and try again with something equally ambitious.
And so, especially I think at a moment where almost every large western
democracy feels especially dysfunctional. Technology at least feels like
it is still able to run productive experiments and contribute.
01:03:39 - Speaker 2: Well, let’s trap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at museAppHQ or on
email hello at museapp.com. And Mario, thanks for documenting and I
would say celebrating the works of the technology field to date, and I
look forward to continuing to read your briefings.
01:04:00 - Speaker 1: Well, thank you so much for reading and for having
me on. I really enjoyed it.
0 min
January 12, 2025
Discuss this episode in the Muse community
Follow @MuseAppHQ on Twitter
Show notes
00:00:00 - Speaker 1: The importance of solo activity in the ideation
process. This is not well supported in existing tools. I think it’s so
important that you have a place where you’re just thinking by yourself.
That might be because you’re generating the initial ideas that you’re
going to bring to the bigger group, or it could be you have some
intermediate products from the group and you want to take that back to
your private sanctuary and mark it up or sketch it or remix it.
00:00:31 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for
deep work on iPad and Mac. This podcast isn’t about Muse the product,
it’s about the small team and the big ideas behind it. I’m Adam
Wiggins here with my colleague Mark McGrenigan. Hey, Adam. Mark a book
I’ve been reading lately was suggested to me by our mutual colleague
Julia is called Exhalation, which is a collection of short stories by
Ted Chang, hope I’m pronouncing that right, who I think is best known
for writing the book that Arrival was based on, but is a pretty prolific
science fiction author in particular short story. Are you familiar with
his work?
00:01:09 - Speaker 1: Yeah, well, I’ve seen Arrival, but I don’t think
I’ve heard of his writing.
00:01:12 - Speaker 2: Yeah, I can highly recommend it, and I don’t
think Yuli is even a huge sci-fi fan, so that’s why it stood out to me
when she recommended it, but it’s really fascinating because I think
each story, some of them are really short, just pose sort of a
hypothetical universe or hypothetical setup.
Where, what if the world was like this, and let’s just explore that
philosophically.
So one of my favorites in there, which I think also the collection was
named after, is about a creature who is essentially what we would
consider kind of a robot, but their whole circulatory system and neural
system is based on the flow of air. And their whole energy source comes
from pressure differentials within their universe, and physicists in
their universe have discovered that basically there’s a fixed pressure
differential from outside like I don’t know, a bronze sphere or
something that contains the entire universe and it’s just kind of like
a alternate reality. Posing of a, I’m not even sure way to put it, but
it’s fun to read and explore the universe, but it also ends up posing
questions about our own world, I think, in the way that only science
fiction can. So, yeah, recommend it if you’re looking for something of
that nature.
00:02:20 - Speaker 1: Ah, interesting, and that alternate physiology
idea reminds me of, I think it’s called Hail Mary, Project Hail Mary,
yeah, by Andy Weir, that’s a fun sci-fi book.
00:02:32 - Speaker 2: Hm, I wanna know this one. I’ll put it on my
list.
Well, there’s a fun little announcement here.
The Muse team has started work on a multiplayer or call it a
collaborative version of Muse. In the very early stages of that, but
this is something you and I have talked about a bunch of times on the
podcast, typically when questions of roadmap come up, right? I always
think of the Muse master plan as kind of being the step 1 iPad app for
thinking, private thinking, step 2, sync to your devices, your different
devices, and then step 3 is being able to bring other people into the
mix. And step 4 is end user programming, but we’ll save that topic for
another day. That match with how you usually think about it.
00:03:14 - Speaker 1: Yeah, that’s the master plan.
00:03:16 - Speaker 2: And we wrote a little memo that we’ll talk about
in some detail here today, but importantly it links to a survey, just a
very short survey where we’re looking for some teams to help us out in,
I would call it alpha testing, but really it’s about understanding how
teams might work in a setting like this.
So of course the Muse mission is to help individuals be more thoughtful
through the tool. We’ve done that through our private thinking to date,
but if we come into a team or group, I ideation setting where there’s
any other person involved, now we kind of have to go back to our early
principles and figure out how that fits in.
And so one of the things we want to do is work really closely here with
teams that have a particular shape. They’re a certain size, they’re
working on certain kinds of problems. Problems to help us craft, not
just kind of features or whatever on the product, but really understand
the best workflows and the best way so we can help, in particular remote
first team.
So I’ll link to that survey as well as a memo on group ideation here.
So naturally our topic today is multiplayer, or I think collaboration is
what I historically had called it.
Maybe in the local first paper we use the term real-time collaboration
to refer to the kind of Google Docs era of you expect that there is a
single location for a document that you’re working on with someone
that’s sort of always up to date. Anyone who has the right permissions
can make edit. It’s, I think multiplayer become the trendier word, so
what exactly we’ll call it is still up for discussion.
But anything in which you’re bringing in another human to your thinking
process is just a whole new area for you and traditionally we’ve even
been, I would call it a sanctuary for your private thinking. It’s
almost like this notebook and The fact that it is just yours is part of
maybe what makes it special. So, what does it mean to bring other humans
into that process? What’s the first thing you think of on that front?
00:05:07 - Speaker 1: Yeah, well, we had joked about this long running
master plan, but we’ve had such a consistent vision behind this because
it reflects our long running understanding of how ideas are made.
You know, recall the original impetus from you was, can we write
software that helps people have better ideas? And in order to do that,
the zero step is understanding where ideas come from.
And yes, as you get new and better tools, it changes around the margins,
right? But there’s very long running patterns and practices and how
ideas are formed, even from before there were computers.
And we’ve studied those a lot in the labs and at Muse. And one of those
ideas, for example, was that you have these different form factors that
you use for different parts of the creative process, the tablet, phone,
and the desktop.
Another important finding was that ideas don’t come from single people.
They tend to be recombinations of existing ideas which overwhelmingly
come from other people. And in fact, we’ve called the original versions
of Muse a private sanctuary, but the first thing you do is you bring in
inputs. That’s the first step of the creative process that we’ve
talked about. And those inputs tend to come from other people. So, even
in its early forms, Muse was embracing this idea of thinking and forming
ideas as a multiplayer activity. It’s just that the person crossing
boundary aligned with the Muse software boundary. Now we’re expanding
the new software boundary.
00:06:28 - Speaker 2: Mm, right, so in this case, if I wanted to remix,
recombine ideas, input from other people, let’s call it the outside
world, I bring that into my private sanctuary, I bring in the tweets, I
bring in the PDFs, I’ve got my excerpts, I’ve got my web clippings,
I’ve got a copy paste or something, someone sent me in an email. I’m
kind of putting all that together in one place on a board, so I can kind
of see it together, start to connect the dots, start to see patterns
across it.
But once I’m inside the bubble, let’s say, of muse, then, you know, I
know that that is mine. Nothing is put there by another person or even
by an algorithm, right? Anything that’s on a board is cause you decided
to put it there. That’s part of how we approached it.
Yeah, and maybe that’s the input side, right, the snippets, the
gathering, the reading notes, the inspiration from elsewhere, but
there’s also an output side, which is at some point you do need to
transmit these ideas to someone else.
In many cases that is gonna mean you could do something like directly
sharing a board screenshot or a PDF. A lot of people do the Choctaw
style thing where they Share muse over a Zoom screen share or something
of that sort and just kind of talk through it, or maybe like a loom, you
know, folks who, they basically walk through their boards full of, say,
like design crits or something like that, and then they share that kind
of recorded video with their team, and you don’t need muse, but you’re
using the muse boards as a visual to help transmit the ideas that
you’ve come up with.
But sometimes it’s going to a production tool from there. So for me
that would often be something like just an email or a slack thread, or
if a little more seriously you want to impress someone, a client, an
investor or something, maybe you’ve got a slide deck. So I’ve got the
rough shape of what I want to say in muse now I’m gonna copy paste
pieces of it into an email or into that slide deck creation software and
that kind of pseudo. Yeah, it’s partially copying, maybe partially
it’s transcription, rewriting, but I’m taking this rush sketch of an
idea and taking it into this other tool where I can make it into
something that I guess is consumable by other humans.
00:08:32 - Speaker 1: Right. Yeah, and so when we talk about muse
embracing multiplayer or collaborative capabilities, really what we mean
is that middle stage, the stage of ideation, brainstorming, outlining,
sketching, forming, reforming, that going from The single player
activity that has been amused to date to involving multiple people.
00:08:55 - Speaker 2: And here I would be remiss if I didn’t reference
a big influence on my thinking is Nicholas Cline, who we had on the
podcast some time back.
Of course I’ll link that episode in the show notes, but he has a whole
sort of career spanning hypothesis, you might say about what he calls
collaborative creativity, and there’s a very revealing diagram there
which is that In many cases, the process for an individual thinking
through something is you have an idea in your mind, but then you go to
externalize it in some way. That could be just jotting down in your
sketchbook or writing it into a text file or even explaining it to
another person, and it is that process of getting it out that you kind
of get new perspective on it and you’re able to refine, there’s a sort
of a feedback loop on that.
There’s also some famous quotes from Richard Feynman about his process
of thinking through, you know, physics problems, where the notes on the
page, he basically argues they’re not an artifact of his thinking, they
are his thinking. The page is a sort of an extension of his brain in
this case.
And so, Nico’s concept of collaborative creativity, which obviously is
very heavily informed by the work he’s done at FIGMA the last few
years, is one of, OK, can we add another person into that mix in a way
that’s productive versus disruptive, and yeah, again, we’ll link that
in the show notes for those who are interested, but I think there’s a
potentially an interesting parallel for the right kind of collaborative
thinking.
And I think this to me comes to an important distinction between the
kind of relationship you have with a collaborator where you’re truly
going to think together versus one that’s maybe more someone that you
want to, let’s say, impress, I mentioned like clients or investors or
applying for a grant. There you definitely want to externalize your
thinking, but your goal is not to collaboratively think through.
Something with the person on the other end, your goal is to transmit it
to them or impress them or get them to buy your product or get them to
invest in your company or whatever it is, whereas I think the
collaborative creativity perspective and where I think we have more to
say is one where you really have this true back and forth, and that
includes What I would call creative trust. This is a term I’m borrowing
from Hilary Maloney, who was on our podcast a little while back as well,
but here, this brings you to being a team. And I think we talked about,
well, too many Metamus references here, going back to the hiring
episode, but the difference between me maybe pitching to a client and me
bouncing ideas back and forth with someone that’s on the same team with
me, that there’s a different quality in how we have creative trust in
each other, and I think that Second one, that team or colleague, where
we have this shared purpose and we’re working together, and we have
this trust in each other, that can and I would argue, should create a
setting where we should think things through together.
00:11:52 - Speaker 1: Yeah, exactly, and I think relatedly, there’s a
difference between a production process versus an ideation process. To
some extent this is kind of the other side of the coin you’re talking
about, for example, with producing a deck for investors. There’s
different output desiderata, there’s different constraints, and you
come in hopefully with a relatively well-formed idea of what you’re
actually trying to say. And we can elaborate more on this throughout the
podcast, but it really is a different type of tool and kind versus a
production tool for presentation and dissemination.
00:12:25 - Speaker 2: Yeah, that part of things is very parallel to how
we think about the individual tool, which is, you know, part of the that
we’re making with our company and part of the argument we’re sort of
making to the world is that it is worth having a purpose-built tool for
thinking and ideation and have that be separate from your production
tool.
So, one articulation of this might be, if you’re a writer. is the best
thing to do to sit down at the typewriter in the kind of historic
setting, or maybe nowadays the word processor, and you’re looking at
that blinking cursor on an empty screen, and I would argue pretty
strongly no. And we’ve even pointed to examples of purpose-built
writing tools like Scrivener, where they actually have a separate
product that is a companion product that is an open canvas for ideation
and figuring out your story. I think they focus more on fiction writing,
because they really recognize that you don’t want to do that in The
writing tool because that’s a production tool, and if you’re figuring
out the flow, your characters, and the flow of the story and the big
arcs and that sort of thing, it’s just kind of the wrong level of
detail in a way.
And there’s a similar argument that could be made for, don’t just sit
down at a blank code editor when you’re building a new piece of
software, you know, get out there and whiteboard some of the basic
architecture in what you’re building, or similarly with the design that
you don’t necessarily want to start in a hyperfocused design tool where
you can be hung up on corner radiuses and font sizes, you wanna be
sketching it out in kind of very, very broad strokes.
So, we’ve made that argument on a private basis, but there’s a team.
Or kind of group version that’s very similar, which is, if you’re
jumping into those tools of the trade, you’re gonna be pretty focused
on production details when what you need to be figuring out is, big
picture, why are we doing this? What are our values, what are the goals,
what are the non-goals, what do we hope to accomplish, etc.
00:14:20 - Speaker 1: Yeah, now I’m wondering if we try to enumerate
what these key differences are. An example of that would be if you and I
were scientific collaborators and we were ideating, we would go to a
blackboard and sketch some diagrams and some, you know, equations maybe
and if things are going well, maybe you and I can read it. Whereas if we
are publishing a scientific paper, we’re gonna go and type that in
Latte, which is a whole ordeal, but it’s gonna be read by thousands of
people, hopefully, so it’s worth that investment. And on the flip side,
you already know what you want to say, so you don’t need to be figuring
that out on the fly.
00:14:52 - Speaker 2: I really like the idea of Blackboard is on one far
extreme and Latech formatted paper that’s, you know, been through peer
review and is published in a journal, is on the other extreme. You know
for sure that that latter thing is a huge production process, that’s
writing the article and going through the peer review, all the
typesetting, and so the ideas need to be good and right first. And some
of that is gonna come from, of course, the research you do and again
your private thinking, but also if you’re doing anything in a group at
all, like a team of researchers, you need to be on the same page,
aligned, da da da, there’s various like manager speak pieces of
terminology for this, but precisely because it is so important. If you
get in there and you’re working on the law tech formatted paper, but
you don’t agree on what you’re gonna say or what your key findings
were, or what you really learned from the experiment, that’s bad news.
Well talking about blackboards brings us to another key issue, which is
this question of remote work. So, Muse is an all remote team, we have
been from the beginning, which predates just a little bit, but not by a
lot, let’s call it the acceleration of the shift to remote work with
the pandemic starting in 2020, and so many of these loose ideation,
let’s get on the same page, have big ideas. Settings that you can think
of are something like, yeah, the researchers in front of the chalkboard,
their product people in front of a whiteboard. I think of the TV writers
room is one of the classic group ideation settings. We’ve written about
war rooms before as well, which is kind of a similar concept in the
startup world.
So most of these things do rely on first of all, these kind of loose and
sketchy and low fidelity physical things like whiteboards and Post-it
notes and sketchbooks, but they also rely on the benefits of body
language and tone, and you can tell when someone’s getting excited and
you can tell when someone’s kind of bored or disengaged or not quite
with you, and I think all of that is so important for this part of it,
which is Both the earliness and the rawness of the idea where you’re
not again in that production tool and thinking about font sizes, but
you’re just getting the big picture right.
And then when you talk about the group side of things that we’re truly
all on the same page and we agree, versus that, I don’t know, someone
wrote a document, people claimed Yeah, that sounds good, but maybe
you’re not really on the same page. I don’t know. It feels like a very
hard problem, and actually some have even concluded, yeah, that any
remote team is just perpetually going to be at a huge disadvantage
because of this kind of ideation, early phase, and alignment that’s
related to that.
00:17:38 - Speaker 1: Yeah, it’s interesting having worked remotely for
a few years, and I almost forgot about the previous world of in real
life, frequent collaboration, but it is a big deal. And even if we
don’t always think about it explicitly, I think we have this intuition
that there’s all these high bandwidth signals and conventions that you
have in person. And so it has been a background thread for us with
collaboration slash multiplayer. What do those mean for a virtual world?
00:18:06 - Speaker 2: Well, maybe this is a good point to talk about
some of the ideas that are in the memo we published recently on group
ideation.
So here was a place where we dived a little bit, actually, Linda dived
into some of the academic literature on exactly this, how to have good
ideas and often in the setting of a group environment. So, one paper
that was influential for us is called Idea Generation and the Quality of
the Best Idea. And this is also quite interesting because they come up
with various ways to rigorously, as much as that can be possible,
measure what counts as a good idea and a developed idea, and that sort
of thing, and they’re looking at individuals, but also groups.
And the first thing you might start with actually is, does it make sense
to develop ideas together? Like, do we even want to do that? Is getting
a bunch of people together in a room to like throw ideas out good and a
seminal work there is wisdom of the crowds, which basically argues that
groupthink is exactly what you think, which is the effect of people
trying to Either come up with or develop a set of ideas together, kind
of creates the lowest common denominator or loud voices crowd out the
quieter ones or it just doesn’t produce good results and actually that
is true. Certain kinds of classic brainstorming settings actually make
your ideas worse than if just one individual came up with it
counterintuitively, but there are ways to do it that can work. And to
me, when you look at both the literature here, but also just reflecting
on my experience of working on teams for now 25 years or whatever it is.
There is a lot of value developing ideas together, and one of those
reasons is essentially that, you know, when more people are either
pitching in ideas or contributing to developing an idea, you just get
more diversity of ideas and more diversity of ideas means better results
typically because, you know, you’re just looking for that one great
idea, the extremes are what matter, so there’s a lot of value to that.
00:20:03 - Speaker 1: Yeah, this starts to get into the Topology of idea
networks, if you will. I think it’s easy to make the mistake if you’re
thinking about coming up with ideas together, you think of, you know,
the team, which is a fixed number of people, the idea team goes into the
idea room and makes some capital ideas, right? Sometimes you try to do
that, it doesn’t work, obviously. I have a much more organic, even
messy model of how ideas happen with people that, critically, the set of
people that you’re talking with at any one time is changing constantly.
Sometimes it’s just you alone, you’re thinking, in the shower,
whatever. Sometimes it’s a one on one conversation with a close
colleague. Sometimes it’s you’re sending or receiving a big broadcast,
like you’re reading a Paper, you’re writing a paper. Sometimes it’s
you’re going to a conference and you’re having a bunch of people
mixing together. Sometimes you sort of stir the pot and you change jobs
or you move to a different part of the country and you are situated in a
new intellectual environment. And it’s kind of like these atoms
constantly colliding with different neighbors all the time. And that
process is the more organic process that I think of, of where ideas come
from.
00:21:06 - Speaker 2: Well, that sounds good if confusing. How do you
think that worldview fits in with creating a great group ideation
product or what kind of tools can we create to improve parts of what you
just described there?
00:21:22 - Speaker 1: Well, I think it works best when the tool
recognizes and supports those different workflows. And ideally you’re
kind of minimizing the number of hops that you’re doing with the tool.
You can’t have one tool that does everything, but if you’re constantly
hopping back and forth between tools, that becomes too much friction.
So while you’re in, say, your core ideation process, the aspiration is
that Muse embraces the handful of key flows. You have your private
individual sanctuary where you do your private ideation. You maybe have
some lightweight sharing or broadcasting where you share a sketch of a
memo with one or a few colleagues. Maybe you have capability to have ad
hoc work groups where it’s, you know, I’m grabbing my colleague to go
to the blackboard and sketch some stuff, and maybe you have the ability
to have these longer term, more durable teams where people are tending
to come to the same room over and over again and a create an
intellectual corpus. I think if you’re able to support those handful of
archetypes, you’re well on your way to embracing this more organic
model of idea generation.
00:22:26 - Speaker 2: That certainly makes me think of what is now a
pretty standard pattern for how you can share documents. Again, Google
Docs, Notion, Dropbox, something like that, which is you have either the
one off share, just give me a quick URL, you know, anyone that has the
URL can view it. Maybe it’s read only, maybe they can add comments,
maybe they can edit.
And then you have, on the other extreme, the more like persistent team
workspace.
Here’s our Dropbox account, here’s our FIA account, here’s our notion
workspace, and everything in there, basically everyone can see.
And then I don’t know if there’s as good a support for ad hoc work
groups, but certainly I know we’ve made do with just kind of like
making a top level notion page or Google Drive folder that’s like, I
don’t know, we’re gonna go back and forth on some tax things with
various bookkeepers and accountants, and so we just make a top level
folder and everything that gets thrown in there kind of is shared for
the whole ad hoc work group. So I think of that as being the gold
standard or just sort of the state of the art. How much do you think
that kind of does correctly map to the process you’re talking about
there versus something that could stand to be improved on?
00:23:36 - Speaker 1: Well, I certainly think you can make it work.
We’ve made it work, you know, we use Notion for some of the stuff, for
example, but I think there are a few areas where it doesn’t quite feel
right.
One is the ad hoc work group thing. This varies by tool, but often that
feels a little bit wrong. For example, it’s sometimes labeled as like a
private or secret place. Like, you know, the default is everything is
visible to your whole org. But you know, if you want to be, you know,
one of those guys, you can make like a private Slack channel and only
invite certain people. Whereas that doesn’t really reflect to me the
very natural and normal process of, you’re not speaking to 1000 people
at once, you’re speaking to people who are in the current room.
00:24:14 - Speaker 2: Two products I’m reminded of there would be one
group chat, or I think you know, group chats have become a pretty major,
what do you call it persistent but ad hoc, exactly as you said, way to
do everything from keep in touch with family to organize around a shared
trip to alumni from school to whatever else. Obviously that’s purely
communication, but kind of has some of that quality, I think.
00:24:40 - Speaker 1: Yeah, I actually think group chats do this better
because they index on the set of people. You have a set of chats for
every unique set of people. At least this is how like iMessage works.
And so you know when you’re going into this room, you’re talking to A,
B, and C, and that’s very standard. That’s how the whole thing works.
And it’s not like your default is to broadcast to every single person
in your address book, right?
00:25:01 - Speaker 2: Another one I think of that goes a very literal
approach with trying to create a more virtual online meeting place is
Gather Town, where essentially they have a little video game app you
walk around on, and the audio for people actually fades in as you get
closer to them, and people have the ability to, I’m not sure how it
works exactly, but basically lock into a private conversation, but you
can actually see that on the map, you could see that they’re talking,
but it’s not something you’re invited to. You can also walk into a
room, a literal room on the map, and hear something, but it’s sort of,
even if you aren’t really supposed to be there, there’s these sort of
just general social mores that cause you to go, oh, you know, I don’t
belong here, or maybe I’m not invited, or I should ask first, or
something like that. Those are two maybe interesting examples of ways
that some of these Call them like real world ways of communicating and
working as we might do in a physical office, have made their way into
digital tools.
00:26:05 - Speaker 1: Yeah, and I think on the flip side, I feel like
Google Docs, for example, whenever you try to do ad hoc work groups,
plus nested content, it gets really messy. It basically you get lost,
like, who’s on this document? Do I belong in this document? Is someone
accidentally here because they’re shared on a folder, 3 levels up,
cause there’s no structure and grounding to it, you tend to get lost
and accidentally share people on stuff. And whereas at least with
something like slack, cause there’s only one layer of hierarchy, you
don’t have the combination of ad hoc plus nesting, plus arbitrary
degrees of freedom that tends to get you confused in Google Docs.
00:26:40 - Speaker 2: Yeah, and some of that may just be sort of design
implementation of Google Docs gets a lot of credit for essentially
defining a whole category of multiplayer tools and really setting the
standard, you know.
That big share button, and the ability to add people by email, and the
ability to make a link that’s a quote unquote private link, that’s
something that’s been widely copied, and I would say notion basically
has borrowed a very similar concept and improved on it, sort of design
wise, let’s say, not major conceptual changes, but incremental
improvements and just making stuff a little clearer.
But I do think I have the same challenge with both of those tools and
others that followed the same model, which is I feel like I’m just
always messing up the permissions.
So I go to share something with someone and they can’t actually see it,
and then I realized I put it on the wrong email, or maybe I forgot to
add them, or in some cases, you know, I did want to work on it in a
private space, maybe I have it in the notion kind of private area, and
then I go to send someone the link, and then I realized I haven’t
actually moved it into the workspace or shared them on it or made it
visible.
And yeah, then similarly being surprised that something is visible to a
lot more people than I thought, which may or may not be a critical
problem, but it just sort of like is this disconcerting.
I don’t know, like I’ve had this happen very occasionally in the real
world where like you think you’re speaking to one person and you turn
around and you realize there’s like 5 other people that were in the
room that you didn’t notice there and it’s just maybe it’s not that
you said anything that they couldn’t hear, but just as humans, I think
we decide what to say or what things to express based on that who we
think is listening. And so I feel like my mind is constantly modeling
who’s listening to me right now and how should I shape what I’m
saying. According to that, I think basically all humans do some version
of that. And so when the permissions, and I’m not even sure that I like
the term permissions, but just the who’s listening or who’s likely to
hear this, or who should be hearing it slash reading it, when that
doesn’t quite match with what I think it’s supposed to be, then it’s
just constantly disconcerting to me somehow.
00:28:47 - Speaker 1: Yeah, for sure. Oh this is reminded me of another
aspect of ad hoc work groups, which is people inside the org versus
outside the org.
My perspective on ad hoc work groups going back to this very organic,
messy, fluid model of ideas bouncing around, is that Idea landscapes
aren’t neatly partitioned into organizations. Those are key nexuss
where you have a lot of atoms bouncing around in close proximity. They
tend to be talking a lot to each other within and around an org, but
there’s also critical connections outside the org.
And there are also whole fields where the notion of org doesn’t quite
work.
I keep coming back to this academic example where you might be a
professor at a university, but your collaborators are almost always in
different. Universities around the country and around the world.
So what’s the organization in that case? Is it your research program?
Is it the University of X? Is it economics? Who knows, right? And I feel
like for a lot of tools, they do well, or they do OK if you want to form
an ad hoc work group within whatever org is paying for yourself.
Software.
But if you want to go outside.org, well, I don’t know, do you have
admin permissions? Do you need to give them an email address at the same
domain, you know, is that a new billing seat? It becomes a bit of an
ordeal, and it doesn’t reflect how easy it should be if it was kind of
honest, the underlying social dynamic.
00:30:11 - Speaker 2: Yeah, ordeal is a great word because I’m a big
believer of things that you do regularly in your creative process, at
your work and your life should be smooth and easy and low friction.
And to me, something like people coming together to form a work group of
some kind is a really common frequent.
Activity, and it also doesn’t have super clear boundaries.
Maybe this just reflects a slightly different way that I think about
companies, but referencing our hiring episode there again where we do
these pilot projects with people.
So we have a candidate, we do the pilot project, we’re giving them
access to a bunch of stuff like GitHub repos and Google Docs, and Figma
and other stuff, just for that week that they’re doing the pilot, then
we might do a longer segment there, and so there kind of is this
progressive getting more.
Involved with them in some cases, or in other cases we’re working with
a freelancer and we actually have a pretty long term, pretty detailed
project, and we do share a lot of tools, but they’re never joining the
team, they’re never gonna have an app use app.com email address, or
maybe they will, maybe actually we do a freelance project for a while,
and then we actually decide, you know, this is a great fit, they’re
gonna have them join the team.
And so I guess you could say there’s these maybe concentric. Rings of
how deep in the org they are and how much kind of direct responsibility
and access and all that sort of thing that they have, but I often feel
like the ordeal of bringing someone into a space to work with them, that
friction doesn’t reflect the more fluid nature of the way that we
collaborate in the world today, or at least the way that I collaborate.
00:31:42 - Speaker 1: Yeah, and now that you mentioned this, I’m
reminded that this is also a function of ideation versus production.
Production is going to tend to be more isolated within an org. If, for
example, you’re producing your end of quarter financials, like, yes,
that’s gonna be pretty contained within the organization, although I
don’t know, maybe have some accountants, but when you’re doing things
like ideating, brainstorming, discovering. Often that just involves
stuff outside the organization. You’re reading papers, you’re talking
with colleagues, you’re bouncing ideas off friends, and so even if it
works mostly in the production world for ideation, you want something
that’s more organic and fluid.
And one last thing I’ll say here, cause I think it’s really important.
We’ve talked a lot about the mechanics, for example, of adding someone
in the permissions and so on. I think the vibe is also really important,
even if the mechanics were the same, but outside collaborators got like
an outsider badge whenever they were in your channel or space, just that
alone makes it feel weird and impairs the creative process, I think. So
that’s ad hoc work groups, which I think is a pretty big gap with
respect to ideation.
Another big one in my mind is the importance of the solo activity in the
ideation process. Often, this is, again, not well supported mechanically
or vibe wise in existing tools. You can kind of make a private thing,
that’s always within, you know, the orgs that kind of always belongs to
the org, and whenever you make something, it has to belong to one or
another org, it can never belong to you, in many cases. I think it’s so
important in the creative process that you have a place where you’re
just thinking by yourself. That might be because you’re doing your very
early stages of the creative process where you’re, for example,
generating the initial ideas that you’re going to bring to the bigger
group, or it could be, you have some intermediate products from the
group. And you want to take that back to your private sanctuary and
noodle on it. You wanna, you know, mark it up or sketch it or remix it.
And I think supporting having both a private space that feels absolutely
first class in the same way that a professor of private office feels as
first class in the classroom. And being able to easily move things back
and forth, take things from your private space into the group spaces,
whether they’re ad hoc or durable or broadcasting, and bring things
back in. I think that’s really important, and I don’t see it super
well supported in existing tools.
00:34:09 - Speaker 2: Yes, well, you hit on something really key there
and it certainly fits with my personal experience of working on teams
that the private thinking that you know today we support in Muse is
actually just as important for group ideation, which is a little bit
counterintuitive.
It’s not really one or the other and in Doing the research here for the
memo, I was pleased to discover that the academic literature supports
this exact thing, and they sometimes refer it to a hybrid model, which
is in contrast to uh what’s called classic brainstorm.
Everybody get in the room, talk through everything until we completely
agree about what we’re gonna do, and then we leave the room and go
execute that a hybrid model is one that mixes private thinking.
With coming together to filter through ideas, merge our ideas together,
argue about them as the case may be, pitch them to each other, influence
each other’s thinking, and that there may be even multiple iterations
of this, then you leave again.
And of course, it probably depends on how big the thing you’re working
on is, if it’s the figuring out, you know, your roadmap for the next 2
years, then maybe it’s worth really spending a good chunk of time on,
and if it’s something smaller, then maybe you only want to go through
this process once.
But this hybrid thinking, hybrid group ideation means that a private
place to think, whether it’s actually an office or leaving your
physical office to, you know, go to a coffee shop, take a walk, whatever
is important, so that’s kind of the physical space side, but on the
tool side, it says, OK, if we want a tool that helps us think in groups
effectively, That tool also has to be great. Maybe it’s even more
important that it be great for private thinking.
00:35:52 - Speaker 1: Yeah, it’s a really good point about the
importance of private thinking for groups, which seems obvious in much
respect, but I hadn’t quite thought about it in those terms.
So to my mind, those are the two big ones, the importance of the solo
sanctuary and the ad hoc organic networks. And those are two pretty big
deals.
Now, like I said, I think that the existing model isn’t wildly off. I
think there’s a lot of good workable stuff there. So I don’t think
we’re looking at something that’s radically different, but I do think
those are two important aspects on the collaboration architecture.
Now we can also talk a little bit about the product architecture in
terms of features or mental models that support group ideation. I think
some of this we’ve kind of talked about in previous podcasts, but there
are a couple of things that I think are worth going over again.
One that we’ve already mentioned today is the importance of the right
level of fidelity, which is this idea of like sketching. So I don’t
think we need to rehash that one more, but that’s what I wanted to
mention.
Another is the right level of durability. So for example, if you have a
team ideation tool that only lasts one session, that’s not gonna work
because ideas take days, weeks, months, multiple sessions going back and
forth between different size groups to form. So we think it’s important
that the tool supports that level of durability, which is, you know, I
would say kind of days, weeks, maybe months. I think ideas that take
multiple years to form tend to rely on bigger superstructures and tools.
Like journals and so on, and ideas don’t form instantly, generally, it
takes takes time. So I think having something that supports that level
of durability and persistence is key.
00:37:31 - Speaker 2: Yeah, so with that description, the ideation,
especially team ideation becomes something that’s in this middle
spectrum on the time horizon, like you said, days, weeks, maybe months,
where one extreme is totally ephemeral and like whiteboards tend to be
that way unless you take a photo or whatever, it’s gonna get erased.
Someone else uses it, it’s gone tomorrow, or in the digital space,
something like just a Zoom meeting, right? You have a conversation, I
don’t know, I guess you could record it or something, but whatever said
is just kind of lost other than the memories of the participants or any
notes you take.
And on the other extreme you have what I would usually call knowledge
management, and so for individuals, that’s usually note taking tools.
So, Evernote is classic there, right, and their logo is an elephant
precisely because they say we don’t want to forget. You can put
something in there and no, you can still get it 5 years later, and I do
think a lot of the, let’s call them team knowledge management tools,
team wikis, like a confluence notion ends up kind of being in this
category is a lot about, I want to carefully put this garden
information. Into this tool and know it’s gonna be there for years,
maybe evergreen, or at the minimum that I’m not gonna lose or forget
anything.
And I would argue, especially based on the description you just made
there, that being in this middle ground between ephemeral and super long
term, but being more on the scale of like weeks or months, sort of the
duration of a project, and then you move on to produce the project and
the Aviation materials are, you know, they’re very interesting. Maybe
they’re good historical references to have. Maybe it’s good for new
people on boarding the team to go back and kind of read this, but
they’re not really current anymore in a way it’s desirable that they
would kind of fade into the background or be archived or something.
00:39:15 - Speaker 1: Right, they’re gonna either need to get burned
into produced artifacts like papers or slide decks, or burned into your
mind, you know, eventually these patterns become ingrained in our neural
architecture, and we don’t need to constantly go back to written boards
or whatever. If something doesn’t meet either of those two bars after
369 months, I’m not super optimistic that it’s gonna ever escape.
00:39:38 - Speaker 2: Well, some of those things might turn into
cultural knowledge or team culture, and you may indeed encode that into,
for example, an employee handbook, but that is more of a produced
transmission.
Here is a thing we took time to sit down and write out because we know
our company’s core values and way of working, and that’s not going to
change over the next 5 or 10 years.
We can hand this to all new employees. It’s not an idea. process. It’s
just a transmission of existing ideas, but in those early days when
you’re still figuring out how do we work together, what are our values,
the process of coming up with that very much is in that we’re still
thinking it through and figuring it out. That’s not something done in
one brainstorming session, it’s something done over time.
00:40:21 - Speaker 1: Now, another thing that I found really important
for ideation is the 2D infinite canvas. And I was thinking about why.
I think a key reason is that you have a lot of raw material and you
don’t know where it should all go yet.
And so if you’re forced to linealize it, it’s already an impossible
mess and you’re doing all this work that you don’t want or need to do.
And I guess it only becomes more acute if you have a bunch of people
throwing cards onto a board.
It’s almost like going into flat world.
If you have to linearize it into a single document, why do we have to
put all this stuff on a single line? Doesn’t make any sense. It’s much
more flexible and empowering to be able to have two dimensional space to
be able to expand that space as needed and to be able to take advantage
of the 2D positioning.
We use this so often for doing things like rows versus columns, where
rows is an aspect of the product and columns are timeline or something
like that. It’s a really useful group ideation tool.
00:41:16 - Speaker 2: Yeah, the infinite canvas, I think is absolutely
key to what will make this work.
I also think of it as a call a product risk maybe, both courses
technically difficult to implement, although I think we’ve managed to
handle most of that already, but the other part of it is that people
find this document type overwhelming.
I know Figma has run into this. I know Miro and other kind of classic
virtual whiteboards have run into this, which is when people come into a
top to bottom, you know, mostly text document, you know where to start
at the top, and there’s only one direction you can go downwards. It’s
essentially truly one dimensional in the sense that the line, you know,
the characters flow and they just wrap around.
And so it’s more approachable and when you go into, especially when you
bring in some kind of zooming elements like free zoom, like you have a
design tool or like we have with the nested boards, it can be
overwhelming. Where do I go, where do I look first, what order do I go
through this in.
So that’s simultaneously the strength and the weakness.
And I think for an individual tool, it’s one thing because the people
who self-select into using the tool, they get it, they decide they want
it, that works fine, but on a team, it could be tricky where you’ve got
a 5 person team and two of them love the infinite canvas. Three of them
are like, uh, I don’t know, this is sort of overwhelming. I don’t know
what to do, but really, you know, if it’s gonna be truly a space where
everyone can bring their ideas, you know, it needs to be somewhat
accessible to everyone on the team.
So, I think that’s a big product challenge ahead for us.
00:42:50 - Speaker 1: Yeah, I think it’s a good point. It’s easy if
you’re the person placing all these random cards on a board, you know,
to understand your master scheme for what it all means, but it can be
harder with a group. I see that, yeah.
At the same time, I go back to the physical analogs, like the writer’s
room in the war room, and you couldn’t imagine such groups limiting
themselves to a single line, right? It would just be goofy. But there
are some subtle constraints or guardrails that they have.
For example, there’s basically one level of zoom, there’s flexible but
not totally infinite, you know, you can’t go below the floor above the
ceiling.
In fact, it usually tends to be about an eye level. You know, there’s
things that are way below or way above eye level or are understood to be
less important.
There are some things that you bring in there to make it more
approachable. So I think we’ll need to figure out what those things are
for the digital medium.
00:43:41 - Speaker 2: And so far we’ve been talking about all the
foundational ideas that went into this, things we’ve been thinking
about and working on with this product for a long time and the more kind
of private ideation space, as well as what we knew we would want to work
into the team or group product, but Actually, we have a working alpha,
and it is very, very much an alpha, to say the least. We kind of wired
something together. This was your idea actually was to say, hey, we can
make a thing that is a standalone app that would never be shippable as a
product, but can use the basics of our local first sync technology to
make it possible to kind of simulate the multiplayer experience.
So we’ve had that working for a couple of months now, and we’ve been
using it on our team to do all kinds of group ideation. What have we
learned so far? What kind of workflows have come out of it and what
things have been surprising? I’m curious your take.
00:44:35 - Speaker 1: Well, I think it’s been awesome. We’ve been
using it a ton. I actually just came back from a little vacation, and I
had 1 gigabyte of content to catch up on from all the stuff the team had
been doing over the past week or two.
Just goes to show how much stuff we’ve been putting in there.
But yeah, we’ve been using it a lot.
I’m looking at our team board now, and I’m seeing a lot of planning
and kind of ideation and a lot of sketching, you know, roadmap, sketch,
podcast, sketch, feature sketch, design sketch.
Yeah, I found it very helpful. And I think we’re starting to see the
idea network topologies emerge organically, at least those that are
supported by the current alpha.
So we have people doing independent work and then bringing it to the
group.
We have sort of broadcast modes where people, for example, put together
a board for an upcoming summit and share that with the whole group.
We have some ad hoc work groups, for example, you and I are on a board
for this podcast.
Yeah, overall, I think it’s been pretty cool.
00:45:31 - Speaker 2: Yeah, I’ve really been enjoying it as well. I
would say we do use it for a lot of things like planning that previously
we might have used notion for, and and it is more fun there just cause
it’s fluid, it’s colorful, you can sketch stuff and you put images or
have vertical columns or whatever, but I’m not sure that it’s
necessarily a breakthrough product in those areas where I find it
really, really helpful is the true shared ideation.
And so, for example, Linda and I have been working a lot on some of the
things having to do with storytelling, including things like demo video
scripts and writing memos, and so on, and she’s done a whole bunch of
customer discovery, let’s say user research, and it’s like collected
that together on a board, and we’re like trying to extract patterns
from that and see what we can learn, and the ability to go back and
forth.
In this setting as a kind of like slow brainstorming, I’m not sure if
that’s quite the right way to put it, a sort of an asynchronous back
and forth has been really just so much more fun, I feel, than either
scheduling Zoom meetings or doing it in Slack, or kind of a don’t even
remember quite how we did it before, but it seems just obvious that this
is, for me at least, is a great way to work. And then also observing
others and how their flows are, and so one good example here is a lot of
the work on the core app, or sort of the user facing interface tends to
be Yulia and Leonard, so Leonard does the design work, Yulias of course
are Master interface engineer, and so for example, I’m just looking at
their board right now in the comments card design, which does include,
of course, some mockup work and Figma or whatever, and he brings some of
those sketches out and includes it here, but then they’re going back
and forth in this way that I love going. The board overview and you have
this kind of branching conversation where it starts from the mockups and
some text blocks that Leonard’s written out about some of the questions
and the trade-offs and then there’s sort of like the comment threads
are sort of branching off in several different directions and you can
kind of follow those threads. And then there’s little inline sketches,
and I’ve seen the two of them go back and forth on this stuff, both
just kind of in sort of like pairing sessions, but very often also just
in slack threads, but those are, I don’t know, kind of excruciating to
read. I don’t know what it’s like to be on the inside of it, but it’s
just like, I’m Really interested. I love watching their process.
They’re both so incredibly talented, but these long slack threads with
an occasional image pasted in or an occasional video, kind of a little
bit dry slash, you know, I tend to skim it, but here I don’t know,
it’s just so interesting to follow the branching threads of the
creative process.
00:48:10 - Speaker 1: Yeah, a couple of things I would pull out from
that. One is, I think we’re seeing more ideas being co-developed by
more than one person. So the way this would have used to work is Leonard
would basically write a notion page, and he would become the owner of
the notion page, and you might, you know, leave some comments on the
notion page or, you know, send him a little slack message, but it was
basically Leonard’s page, and that was the common design, or would have
been the commons design.
But for some of these boards that I’m looking at between Julia and
Leonard and you and Linda, for example, it feels more like the idea is
being organically co-developed by a small team. And that goes back to
this idea of team ownership of ideas that you were talking about before,
and I think it only really becomes possible where we have a shared
medium like this.
Another thing that I noticed is, again, it’s very extensive use of the
two dimensions. I’d say about half of these boards are actually in some
variant of the row column format. Sometimes these are time, it’s
person, it’s chapter. It’s area of the products, it’s the ABC, you
know, there’s all kinds of different ways we use rows and columns, but
it’s quite common.
The other pretty common archetype is like the choose your own adventure,
you know, branching storyline type thing, where it’s like a roadmap
dependency graph or a design discussion branching thing. And I also
would reiterate your point about these artifacts being a cred a little
bit. I often had this problem as the person who wasn’t right in the
middle of these dialogues between Julia and Leonard, or you or Linda,
where I would see just hundreds and hundreds of lines go by and slack.
And I’d be like, OK, what was the conclusion? It was, you know,
basically telling me to go read the whole slack backs were all like, I
guess so. But now there’s this much more satisfactory like it isn’t
perfect, you know, sometimes you got to go back to Slack to get some of
the contexts, or sometimes. It doesn’t quite exactly reflect the
current state of our thinking, but it feels much better to have these
artifacts that are creating around all the key things that we’re
working on, roadmap, comment design, collaboration architecture, hiring,
all these really important things for us. There’s basically a board for
it, so it’s great to see that now.
00:50:14 - Speaker 2: One thing we haven’t had the chance to test yet
is having a new team member come on and getting to immerse themselves in
this world as a way to kind of understand our current thinking.
And again, we have used notion for a kind of a version of this in the
past. We tend to, yeah, put a lot of internal memos, here’s kind of a
technical design for something, or here’s a plan for how we’re gonna
handle, you know, support duty going forward or something like that. And
here’s a launch plan for a feature we’re working on.
But it’s exactly as you say, those, for some reason, the notion
documents, I don’t know if this is cultural or if it’s something to do
with the tool, but they’re very structured and once someone makes one,
it’s like you said, it’s that person’s document.
You don’t feel good putting things in it, only comments. But comments
are like, really, really limited, right? I don’t think you can even put
like a clickable link.
I wanna like add a comment which is like, well, what about, you know,
this citation and link to a paper or an article that could be relevant
and it’s just literally you have to copy paste it out of there, you
can’t even click on it, let alone an image or anything else like that.
And I wonder why that is.
We’re just tried in some cases, or I’ve either encouraged people to or
for myself, tried to like modify other people’s documents, and I feel
like it just doesn’t Work, it’s just like someone else owns this, I’m
not gonna touch it other than leaving comments. I wonder why that is.
00:51:38 - Speaker 1: Yeah, that is very real. I think part of it is the
level of fidelity, you know, notions is incredibly beautifully designed,
polished interface. It’s so good that you can present it publicly, and
many people do.
And so it kind of feels a little bit weird to go in there with your
half-baked feedback and just scribble all over it.
I also think there’s an issue with the linear realization of where do
you put your comments.
Now, the nice thing about comments and something like notion is that
they do correctly go next to the thing that you want to comment on, but
they don’t bust up the piece itself.
And the other pattern that I’ve seen there, by the way, is people will
scroll all the way to the bottom, hit enter 5 times, hit a bunch of
equal signs, and then say like, you know, Adams, feedback here.
But then, you get the full richness of all the different media types
like images and links and stuff, but it’s also disjoint from the thing
you’re commenting on.
And the nice thing about the 2D environment is you can just add more
space to the right, draw some arrows and say, OK, this is my feedback on
this and that, and it preserves the original flow of what it was of the
original document, but you have your own full richness medium to add
your feedback in.
00:52:41 - Speaker 2: You have actually done that explicit creating a
space for someone to write into, so we often use a shared notion
document.
This would be, I guess, an example of the one-off sharing. We have a
guest on the podcast where I say, OK, well, here’s the rough topic,
here’s some of the stuff we might want to talk about.
Feel free to add your own bullets and links to the document, and I found
when I did that initially.
Where I had just kind of sketched some stuff that we might talk about,
the guests kind of was disinclined to put anything there, but when I
started putting explicitly a section that is Adam’s notes, Mark’s
notes, and name of guests notes, it’s clear that there’s a place they
can put their stuff and they don’t feel like they’re disturbing the
rest of it.
And then in many cases, I copy paste from there into, depending on how
much prep I wanna do, I might copy paste some of their ideas into the
overall structure, but yeah, you have this thing where it’s just, yeah,
we don’t wanna mess with each other’s stuff, which is fine, but the
process, or I think it comes from a very naturally good place of not
wanting to Disturb someone else’s hard work, fair enough, but if we’re
going to come up with truly shared ideas together, we need to be willing
to mess with each other’s stuff, and maybe some of that is just
cultural and will change with time, but I think that the tool can
encourage that.
00:53:59 - Speaker 1: One other little anthropological nugget that I’m
thinking about is the form factor question. So, my observation of
creative professionals is they tend to have one of two setups. They
usually either have a personal iPad, personal laptop, and work laptop,
or a personal iPad and personal plus work laptop.
And I think that’s for a few reasons. I think historically has not been
a lot of work that happens on the iPad.
And conversely, I think the desktop slash laptop is the form factor of
choice for professional collaborative work. At least it has been
historic, but it just kind of is what it is.
And for me, I’ve often found myself using the desktop for even our muse
collaborative stuff, and I use the iPad a lot for My personal work and
for my like solo sessions on group ideas. I’m curious, Adam, how your
device usage breaks down and how you think about the different form
factors for collaboration versus solo work.
00:55:02 - Speaker 2: Yeah, I think I’ve gravitated to something very
similar to what you’ve described, that my computer, you know, laptop or
workstation is The place I go to do work-ish things or really
production-ish things, like even recording this podcast is a good
example. I’m in front of the big monitor, I’ve got the mic, I’ve got
the notes up, but I’ve also got the window up where I can see you and
see the recording progress and see my levels and so on. And I guess you
can do that stuff from an iPad, but it just feels like I want that full
kind of production studio set up where everything’s in front of me and
I have the space to spread out there.
And similarly, just looking at My use of our kind of team prototype
thing here, I use it way more from the Mac, and that’s more a function
of the fact that I’m very often Yeah, it’s just you’re working on the
computer. That’s kind of all there is to it. You’re at your desk,
you’re at the workstation, and there’s obviously thinking that goes
there, but there’s also just planning, and there’s referencing that
stuff where it’s like, OK, we developed this idea together of this, you
know, script for a video we wanna record. OK, now I need to reference
that while I’m recording a video, all that is happening on the desktop
computer.
And I do use the iPad for accessing the group ideation space, but this
really is the stand up from the desk, go over and sit down in some place
in a more kind of reclined position. I’m moving cards around with my
finger, I’m scribbling on stuff, I’m kind of recombining, sketching,
that sort of thing. But one effect of that is, yeah, it would be
interesting to just even do an actual measurement of this, but I think
what it comes down to is I use Muse way more on the iPad for my personal
stuff, and then some on the Mac, and then for work it’s sort of
inverse, which is I use the Mac way, way more and just pull out the iPad
occasionally.
00:56:53 - Speaker 1: One other thought on form factors has to do with
inking.
So, we don’t use inking a ton, but I do think it has some very
important uses.
It’s great for doing little diagrams and like connect the arrow things.
It’s great for quick markups of documents, and for me it’s very
important for the earliest stages of ideation.
I’m just trying to get my hand on something I like to use ink on my
iPad. And this brings me back to the Muse approach versus other existing
tools.
I think Inc is basically critical for ideation. I think it’s really
non-negotiable for the complete creative process.
And furthermore, it’s along with my opinion that the only place that’s
suitable for inking currently is native apps on the iPad.
And you think about it, there just are not that many native team
collaboration apps on the iPad.
Often they’re, you know, web-based apps, or they just don’t have an
iPad app at all.
And so this is in my mind, a small but critical aspect of the museation
story for teams.
00:58:04 - Speaker 2: Well, maybe that brings us to a bit of the
technology or platform choice side, which I think is a really important
part of the bet we’re making with our business, or perhaps just the
artistic statement we’re making about the way that we want the world to
be, which is, of course, local first. Now, that’s a syncing technology,
we can talk about some of the implications that has for collaboration.
But to the point you were just making, there’s really two types of,
let’s say work apps in the world. On one side you have those native
apps, and there’s many great apps with really good kind of sketching in
capabilities, usually much better than Muse, because they’ve been able
to make it their main focus.
Something like good notes would be a good example there, something like
Paper by 53, and these are fast, they’re beautiful, they use the
capabilities of the tablet really well, maybe they have a lot of
different options. Options for inking and that sort of thing, but they
have either no ability to collaborate or share or whatever it is, is
very kind of limited. It uses some clunky iCloud thing or just isn’t
real time or something like that, just the world of native apps just was
never built for a collaborative multiplayer kind of sharing type
setting.
And then on the other side you have the cloud, and certainly something
like Figma or Miro or there’s many others, of course, like we’ve
already talked about Google Docs and Notion and so forth, and those tend
to start from, there’s a page you load in your browser, collaboration
is, I don’t wanna say it’s an easy thing to add, but it’s a very
natural thing. It fits together with the fact that really your browser
is a thing client to the program is actually running on the servers.
Owned and or rented by the software provider. And so in that way,
because we’re all sort of connecting to the same sort of shared
computer or set of computers, we’re accessing the same program running
from the same database at the same time.
But that has the problem, of course, that your work is not at all at
hand, certainly doesn’t work offline, you don’t have real ownership of
it, it’s really in this far away computer, and it can’t be fast, and
it can’t really take advantage of the hardware capabilities. And of
course, you know, someone like Notion, I think even Miro does have an.
iPad native app, but they tend to just not really feel native to the
platform. They’re sort of a bit of an afterthought. I’m not trying to
disrespect the teams that have worked on those products, but you can
really just feel that it comes from a company whose culture is web and
cloud. And that always feels a shame to me. So, something we’re doing
with Muse product in the business that I think is totally unique, and time
will tell if the market likes this, is we’re bringing together a cloud
style of real time sharing and collaboration with, as well as sync
between your devices, with a fully native, fast, all your data is local,
take full advantage of the hardware app. And putting those two things
together is a huge technical challenge, but I’m really excited to see,
already we’re seeing the ways that that feels fundamentally different
from what we know from either the cloud world or the pure native app
world.
01:01:14 - Speaker 1: Yeah, and just to very briefly recap the
implications of that.
Local first means that you have a copy of all the data relevant to you
on all of your devices. In the case of a single player that’s
relatively straightforward, it’s basically all data that you’ve ever
written that hasn’t been deleted, at least, and you have a copy of that
locally. Now with multiplayer, it becomes more complicated cause it’s
all the data that you’ve ever written, or all the documents that
you’ve ever been shared on directly or indirectly.
But if you do all that right, you have a copy of everything that is or
could be relevant to you on your machine already. And the key
implication of this is that certainly any reads are gonna be super fast.
So whenever you go to zoom into a board, for example, there’s never a
spinner or anything that’s already there.
You’re not going to some server to load a board, you just open it the
same way you would open a local file.
And even rights can be faster because the app has a sort of complete
ecosystem locally can do everything it needs locally, as if it was
offline, so it can display your right instantly. It doesn’t need to
wait for some server to acknowledge your right to have gone through.
That all just happens in the background.
01:02:21 - Speaker 2: The real world implications of what this is going
to be like in terms of feel and user experience will be revealed to us
through this alpha program and then beta and then going to production
should we get that far, but you’ve already hinted at some of the things
we’ve already seen in this kind of early prototype which is you came
back from A week of vacation and had to download everything that the
team had been doing, because that’s the way that it works. It downloads
absolutely everything, and I think there’s probably a future version
where we need to do a Dropbox selective sync type thing where you only
download the stuff that’s relevant to you or that’s in front of you
right now or hasn’t been archived or something like that. But at least
for the moment, everyone has a complete copy of the work space, and that
means you’re downloading it.
Now it doesn’t block you from using the app while it’s doing that
download, and actually most of that data is the, I guess you call it
blob data, you can go back and listen to our Episode on local for sync
if you want to get into the technology, but most of the data is stuff
like PDFs, images, videos, and that download may take a little while,
but all the cards are in the right position, you can zoom into stuff,
the text is all there, and you’ll just have kind of a blur hash
download pending for things like images and videos and PDFs that
haven’t shown up yet.
01:03:37 - Speaker 1: Yeah, and I’m still a pretty big believer in this
idea that all the metadata is fine. You know, everything that you’ve
ever typed or drawn by hand in your life, or that any of your
collaborators have ever drawn, if it’s appropriately compressed, it’s
just not that much data. You should be able to download it all fine. And
then if you do some basic things around maybe lazy loading big blobs or
prioritizing them appropriately, things like that, I think it should be
fine. But, you know, it’s gonna be some engineering work and we still
got to prove it in production.
01:04:05 - Speaker 2: Yeah, and I think that proving is as much, you’ve
talked about how business ventures and product development is largely a
matter of testing your hypotheses against the laboratory of the world,
you know, what does the market want, what do people value, and so forth,
which is, I love, for example, the fact that everything is always fast
and at your fingertips. I love that I can work offline. I’ve already
had the chance once when I flew to a little conference to Essentially
work on a plane, on my iPad in our team workspace. All the data was
there, and just when I landed and reconnected to a network, it all
synced itself back up, and that worked great, and I didn’t feel cut off
from my work if I wanted to do some thinking while I was on the plane,
which for me is often a great place to think. And whether that specific
use case is important to people or not, or in general, whether that kind
of offline capability is important to people or not is, you know,
something we’re gonna learn through this process.
01:05:00 - Speaker 1: Yeah, I think another thing that we’re going to
have to grapple with is the implications for permissions. Now, this is
more different than the performance side of things.
Performance should basically just be strictly better, or almost entirely
so you do have this challenge around downloading big chunks, but the
permissions model is different.
In the classic cloud world, when you’re collaborated on a document.
You’re really only granted the temporary and revocable privilege of
accessing this document’s data on the server. You basically have
nothing locally, and every morning when you go to load up your to do
list, you’re either blessed or not by the server. And at any point,
your organization can revoke that from you. And once that happens, you
have nothing locally. And to be clear, there are lots of benefits of
this, and there are reasons it’s done this way, aside from just the
technical reasons of the historical cloud architectures. But in a local
first model, You have a copy of everything, and really strictly
speaking, once you have data, people can’t take it away from you. You
can be a nice citizen and say, you know, my colleagues have asked that I
remove this document. I’m therefore going to delete it from my device.
But the notion of revoking is fundamentally different. It’s more about
saying, you are no longer going to receive updates from us, and we’re
no longer going to listen to updates from you. But anything that you’ve
seen with your own two eyes, you know, how are we gonna take that away
from you? We really can’t.
01:06:19 - Speaker 2: And that, I think, leads into a whole set of ideas
that we have around work idealism and greater agency for individual
creative people in the modern economy, and indeed, I would love to do a
whole podcast episode on that, so maybe I won’t let us fall down that
rabbit hole right now.
But I think that some of the cloud model permissions, centralized
administration is connected to a particular way of companies working
that may in some ways be shifting a little bit, but we’ll see, we’ll
see.
There’s a place to end.
I’d like to go back to something we touched on briefly in the group
ideation memo, which is not just how do we best develop ideas together,
but actually why do we even want to do that in the first place? What’s
the value of shared ideation on a team? And for me this has very much to
do with the number of years I’ve spent in various kind of team lead
roles of different kinds, including here on the Muse team, and just
something I’ve learned over and over again is If someone has to execute
an idea that they weren’t involved in shaping, then it’s just really
hard for them to do a good job. They don’t know the why, they don’t
know where this came from, their sense of just excitement and motivation
for, yeah, doing something that’s truly theirs is limited.
Instead, they’re just sort of a worker bee that’s sort of cranking out
someone else’s plan.
And so something I’ve learned about great executing teams really is you
come up with the ideas together, and it’s not just about the idea in
the first place, but what I would usually call the developing of the
idea, which is the iteration, finding the nuance, it’s not just that
first spark of an idea that does usually come from one person.
But that you together are exploring the idea, exploring all its nooks
and crannies, and coming up with, I guess a plan would be the right way
to put it, but when you go in and get ready to execute, you really all
went through the process together. You ran the ideas together, and now
you know what you’re doing, and now you can execute really well when
you do that. And having learned that lesson the hard way, many times,
either as a team member or a team member who’s leading the team. It’s
just something I’m really passionate about, and so, something I hope we
can achieve with this product that would be, to me, an amazing
breakthrough, is if you can make more shared ideation on teams, and that
results in more shared ownership, those teams will execute much, much
better, and that to me is kind of a really exciting vision of the future
for a collaborative muse.
01:09:06 - Speaker 1: Yeah, I like that a lot. It’s as if the idea
isn’t just the result of this network process we’ve been talking
about. In some ways, it is the network itself and the pathways that
you’ve trodden through it. It’s just as important perhaps as the
artifact that you end up with.
01:09:23 - Speaker 2: Well, let’s wrap it there. Thanks everyone for
listening. If you have feedback, write us on Twitter at museAppHQ by
email, hello at museapp.com. If you’re interested in giving a try or
helping us shape this multiplayer collaborative muse, whatever that’s
going to turn out to be, certainly visit the survey link here in the
show notes. And Mark, I’m really excited to be on to stage 3 of the
master plan. Right on.
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