Transcript

00:00:00 - Speaker 1: Rather than giving someone this hermetically sealed box, can we use an analogy like build a beautiful Lego set for them and hand it to them, where if they like it just as it is, that’s fine. And if they want to add one Lego right there, it’s not a big deal. They sort of see the composition of how this thing was made, they have a little bit of flexibility to tweak it because it’s made out of parts they understand.

00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. I’m joined by Jeffrey Litt.

00:00:40 - Speaker 1: Hello, hello. It’s good to be here.

00:00:41 - Speaker 2: So Jeffrey, one thing I’m thinking about these days in raising my young child is growing up in a multilingual household, since both of her parents are from two different countries and we’re living in a third country. I know you grew up in a multilingual household as an adult, what are your reflections on that experience?

00:00:59 - Speaker 1: Yeah, so my mom’s Japanese and I grew up sort of half my childhood in the US, half in Japan, and when I was a kid, my mom sort of forced me and my brother to learn Japanese when we were in the US and I was just thinking about how I’m so grateful now that she sort of overrode our preferences as children, and that now I have some proficiency in the language and so raising kids is complicated.

00:01:20 - Speaker 2: There is going to be, I can see this already at this young age, and I think if it gets only more so as children get more agency naturally with age, which is parents do know better. They’re just older and wiser and know how the world works and At the same time, a kid needs to find their own way, and authoritarian upbringing doesn’t sound particularly like a good way to blossom as a person. So finding that balance between what’s prescribed by parents, you’ll thank me when you’re older. In this case, literally so versus let a kid find their own path. I think that’s an ongoing philosophical moral dilemma.

00:01:57 - Speaker 1: Yeah, especially for something as difficult as learning a language. You know, I do think with whether it’s sports or music or these skills that take a lot of time to master, I’ve also been grateful that my parents helped me learn to love Japanese and build some of that motivation, whether that’s from visits to Japan to hang out there as a kid. I tend to believe that the goal of education at a young age isn’t primarily to transfer the skill. It’s to, as they say, light that fire that eventually keeps learning going, and to this day. I’m practicing my Japanese trying to keep it up, and so I think that’s an important balance this track too.

00:02:31 - Speaker 2: What’s that saying? If you want to set sail on a boat you’re building, you don’t teach someone to build a boat, you teach them to yearn for the ocean.

00:02:40 - Speaker 1: Yeah, exactly, I think there’s a lot of that at play.

00:02:43 - Speaker 2: So Jeffrey, I’ve been wanting to get you on the podcast for a while here. We got the chance to work together on the Cambria project at Ik and Switch last year, but I’d love to hear just a little bit about your background, how you came to be doing this work in the tools for Though and independent research space.

00:02:59 - Speaker 1: Yeah, so I’m currently doing a PhD at MIT in computer science. I’m in a lab called the Software Design Group, led by my advisor Daniel Jackson.

And at the highest level, the questions I’m trying to explore are how do we empower more people to kind of take full advantage of the medium of computing? I think it’s very ironic that we’ve invented this infinitely flexible thing called software, and most of the way that we use it ends up being a small group of people, make some stuff and throw it over a wall, and everyone else uses it. And I’m just interested in new approaches to building software that changed that dynamic.

But before coming into this academic side of things, a lot of my thinking on this area actually came from working in startups and shipping real software to people.

If you had asked me 5 years ago, are you gonna be doing a PhD, I would have laughed at you and said, you know, no, I’m not that kind of academically minded person. But over my time in startups, I got really interested in these topics and I decided that Rather than go try to start a company or something, the academic environment offers a certain amount of freedom from the need to ship real software immediately, the need to make money immediately, that I thought would be really valuable for kind of thinking more deeply about what the problem actually is here, and maybe bigger picture ways to reorient the way that we build software.

00:04:19 - Speaker 2: Yeah, that makes sense. You have both industry background, as they might say, ship stuff fast, solve real customer problems, and kind of academic mindset, longer time horizons, more of a search for basic truths, trying to think bigger and more expansively and more philosophically, and that’s actually, I think, a place. That I and Switch kind of excels or part of its reason for existence is to kind of be in that middle space between those two worlds which I think is not well occupied and certainly for creative tools generally I feel like that at least right now is the space where we need the most minds and the most effort.

00:04:56 - Speaker 1: Yeah, that’s part of why I have really enjoyed following and can switch his work over the years and have gotten to collaborate a bit with the lab, and I think it fills this really important middle place between those two worlds.

Too often I think startups are kind of not reflecting on the larger possibilities of what they could be doing if they had more than, you know, 3 months ahead to think about.

And on the other side, you have academics who, I think sometimes It’s not really clear to me how idea transfer really happens from academic human computer interaction research to the real world sometimes. I don’t think it’s a smooth process where, you know, startups are devouring papers that are being written and trying to implement them in the real world. I think it’s a much messier process. If you look at even someone like Doug Engelbart, who I think is a hero for a lot of people in this community, it was really hard for him to get his ideas out into the world, ultimately succeeded, but through a pretty circuitous path. So I think it’s really valuable to have institutions that are thinking about both of those worlds simultaneously, with the ultimate goal of actually deploying in some form, their ideas, as opposed to just sort of just handling the ideas half of things.

00:06:07 - Speaker 2: Yeah, well, that’s why I think I really enjoy following your work so much, is that you do fit in that middle space and hopefully can be a role model for the rest of us on that.

00:06:17 - Speaker 1: Yeah, I’m trying to, it’s tricky. There are a lot of tensions to navigate as I’m sure that you guys have experienced.

00:06:23 - Speaker 2: And I also thank you for being one of the very early users of Muse during the beta as well as a customer. I hope you’ll consider renewing your subscription when that comes up again.

You’ve both tweeted lots of screenshots about how you use it, which is, I think, really great for other people seeing how you use things and the every publication even wrote an article. of detailing your work and you talked about a lot of different tools in your flow, include some screenshots of use there so very much appreciate your business, but probably even more than that, the kind of very public moral support makes a big difference, especially in the early days of a product when you know you don’t have so many believers just yet.

00:07:00 - Speaker 1: Yeah, thanks for building such a great tool. I mean, I bought the big iPad Pro originally when I was starting to dip my toes into the academic waters and being confronted with a lot of 8.5 by 11 PDFs and decided I wanted a nicer way to read them, but something felt like it was missing there in terms of synthesizing across them. And when Muse appeared, I was like, this is it. This is maybe the early versions weren’t the perfect product yet, but I could tell the vision was exactly what I needed, and so it’s been a blast using it.

00:07:29 - Speaker 2: So our topic today is bring your own client, which is something you’ve written about, and of course I’ll link that article in our show notes here, but maybe you can tee up for the listeners a little bit what that’s all about.

00:07:42 - Speaker 1: Yeah, absolutely. So bring your own client means having the flexibility to pick what application you want to use when you’re working with some data, and for there to be some independence, especially I think between people who are collaborating on the same project, to pick the software that they want to bring to the table.

So I think like to give a concrete example, right, back in the old days when we used to email each other files to work on a document, let’s say I could email you a Word doc.

And then you might open that Word doc in Apple Pages or OpenOffice, whatever your preferred word processor is, and then you would send that doc back to me, and I don’t care what application you used on your end, as long as I get a file back, we can work together, right? And in fact, if we’re emailing files, I also don’t care what email client you’re using.

There’s sort of this inherent point of flexibility built in where we get to make these individual choices about how we want to work.

And broadly, the topic I’ve been thinking a lot about these days is how I think that we are starting to lose some of that flexibility with the way that computing is headed.

So I’m very interested in this overall ethos of bringing our own clients and perhaps even building or customizing our own clients, um, to gain a little more control over our experience with software.

00:08:56 - Speaker 2: I think email is one of the best examples perhaps because it’s this really one of the oldest standards in some ways, sort of the first internet protocol in some ways, and the plethora of different clients that have existed over time. I don’t know, I used Pine and later mutt, this kind of terminal-based clients. At university in the 1990s and going forward to Gmail was this big revelation in terms of lots of great interface innovations as well as backend innovations, but it could just work right away. You didn’t need the person on the other end to be also a Gmail user, they could be with any email client.

00:09:36 - Speaker 1: Yeah, and I think email is one of those domains that really demonstrates how valuable it can be to have this flexibility.

You know, I think sometimes it can be tempting to say, does this really matter? What’s the big deal? Can’t we just all agree on the same software to use? But if you look at something like email, I know a lot of people, some of them not that technical, who have really strong opinions about what email client they want to use because they’ve just found one that works well for them. I’ve had many moments of my favorite email clients sort of going out of business or being acquired and hopping from one to the next and searching for that elusive best client. And I think for anyone who’s sort of an email for like 8 hours a day at their job. You start to see why having this degree of flexibility genuinely matters for people, and it’s not just like a little convenience, it’s actually a big deal.

00:10:23 - Speaker 2: Right, and so you see this not only in the big example of Gmail that really revolutionized a lot of things about how email works, but even nowadays we have a plethora of new clients, superhuman, tempo is another cool up and coming one, or for example on the Muse team for our inbound support where you can just basically email hello at museapp.com that goes into a product called Front and so this is kind of a group inbox email thing that has quite different characteristics from what an individual might want.

But it’s nice because the person on the other end, they don’t care what we’re using, they can just send us an email, maybe they include attachments, maybe they include whatever we reply back within that, so that gives each party in this back and forth can use what suits them and what’s gonna suit a team that’s going through a bunch of support requests is just dramatically different from what might suit an individual doing their own personal inbox.

00:11:13 - Speaker 1: Yeah, I actually personally use Tempo, and I think it’s a great example of a niche product.

It’s really perfect for what I’m looking for.

They have a really minimalist design. They have this concept of batching your emails so you don’t get distracted.

And for me, as someone who’s at least trying to not check my email 100 times a day, it’s sort of aligned with what I want.

I don’t think it’s necessarily the perfect product for everyone or even the majority of people, but I think it’s right for me, and it’s just great that because we have this shared protocol, I can make that choice to adopt this niche product that maybe only 1% of email users will ever use.

Without convincing all this other 99% to join me in using this thing, we sort of take this for granted with email, but look at Slack. There’s not really a concept of a third party Slack client, right? And I think it’s easy to forget how monolithic that experience is.

Every team that uses Slack is stuck with the exact same user interface with no ability for individuals or even teams to really meaningfully customize it. And I think that’s a tremendous design challenge to try to make something that works well for so many different people and so many different workforces.

00:12:21 - Speaker 2: Maybe there you illustrate the trade off though Slack because it is an integrated product where they control every part of it, the client, the API, the data storage, all of it, they can work on a very integrated and sleek experience.

Twitter went through something similar in their early days. They were moving in this direction of being a platform. There was this initial explosion of clients that tried interesting things. Like TweetDeck and Tweety and so on, and ultimately they decided it was a product decision within their company.

We don’t want to be a platform. We don’t want to be the next email. We want to provide an end to end curated experience where when we are going to add a new feature, whether it’s images and video in line or something else that we can fully control what that looks like for all the parties in the equation.

And that’s a trade-off that I think you always have to make, an email is a good example.

You do get weird stuff that happens when you email between two clients and they don’t quite agree about how to display the results, and also it’s very difficult to add new things.

I say that speaking as someone who would really like to embed video into email newsletters and you just can’t do it. You got to use animated GIFs which are low quality and slow to download and so on, but it’s just not a standard that can quickly evolve.

00:13:39 - Speaker 1: Yeah, I think this is indeed one of the core tensions in this idea. How do we balance moving fast with a single decision being made about an ecosystem versus having this more distributed approach.

One idea that I find interesting though is kind of this idea of partial compatibility. Can we find sort of middle points between these extremes of a single rigid standard that hasn’t evolved since the 80s versus a company that just decides whatever it wants and imposes it on everyone.

I think we can potentially at least try to have app ecosystems where you might have two applications that share 80% of their functionality, and there might be parts around the edges that don’t work perfectly together, but that might be something you can manage as a team, especially if you’re working with people and you know what tools they’re using. I’m really interested in finding tools and sort of platform approaches to mediate this kind of fuzzier partial interoperability.

00:14:34 - Speaker 3: Yeah, I think there’s a really interesting spectrum here, or maybe even a whole world of different possibilities. I’m reminded, for example, of this idea of aftermarket support that you see in consumer durable goods like cameras, for example, and there through fiat or evolution, you have some standards, some connection points where people can.

Plug in often literally and you might have the core the proprietary, but there’s all these extensions and accessories that you can put on it and because of that, you get an enormous ecosystem of tools and so on that you can build around the core, like a good example of this would be tractor attachments, where there’s the 3 point hitch, and you can basically put whatever you want on a. you know, a plow, a snow blower, whatever. And that’s really interesting because you enable profitable commercial entities and there’s only a few of them to build the extremely complex integrated tractor. And then you have this whole world of mom and pop metal fabrication shops building random implements for 200 bucks. It’s really interesting balance, and I don’t see that very often in software.

00:15:36 - Speaker 1: Yeah, I think it’s also interesting in software to look at domains where you often have a lot of tools that look pretty similar to each other if you squint.

Take to do list software or like team issue tracker software, for example. Every time I see a landing page for a new project management tool, there’s a lot of concepts there that look pretty familiar. You have things to do, you assign them to people, you have some notion of projects.

And yet every tool has a little bit of some unique spin on that problem.

There’s perhaps new ideas that they bring for organizing stuff, and yet I think it’s reasonable to say that maybe 80% of the core ideas are shared.

So something we actually worked on on the Cambria project that I worked on at I can Switch last summer was, let’s say, as one example, you have one to do list app that’s decided that you can assign something to multiple people to work together on.

And another app says that a to do is assigned to a single person. And what if you want those apps to interoperate, you might just say this is impossible, but you could also say, well, if you assign something to multiple people, we’ll just show the first one on the other app that only allows a single assignee, and maybe that’s good enough for your use case to get by with that sort of partial little bit of bridging between those ideas. And I think if we can get creative about bridging between similar but not identical apps more, that opens up a lot more possibilities for how we can have tools work better together.

00:16:54 - Speaker 3: Yeah, exactly. Another thing that I’m reminded of here is the metadata that you can put at the top of HTML pages. I’m actually forgetting the name, what’s the right name for this?

00:17:02 - Speaker 1: The meta tags, the meta tags, I guess, yeah.

00:17:04 - Speaker 3: And there’s a whole world of emergent, somewhat adopted, partially adopted, somewhat conflicting standards for preview cards and Twitter preview cards and open network preview cards and, but it kind of works out, right, because there’s this basic platform entry point, which is the meta tags and then different platforms and users adopt different subsets of them, but in practice it tends to work pretty well.

00:17:28 - Speaker 2: I think the web obviously in many ways is a great example of an open and evolving standard that on one hand has innovated a lot and continues to over a pretty long period of time but also is not owned by any one vendor and browsers come and go and so on.

But one principle that’s often used there is this idea of progressive enhancement. which maybe is kind of what you’re pointing to there, Mark, which is you can drop in something like if there’s some fancy new audio thing or some fancy new video thing or some fancy new interaction capability, you can either first of all just handle the degradation case of this browser doesn’t support that, so let me do something.

Simpler, but in many cases just putting in, for example, those meta tags that produce, for example, a certain kind of unfurl card will just be ignored by older browsers that don’t know what that is. They just kind of skip over that and if you’re in that situation or You just don’t see that information and probably something similar happens with, yeah, you use an older browser to load a page that has, I don’t know, some fancy new video thing, you just see an empty box or whatever. That’s not great, but it still works for you, you can still get most of the content.

00:18:38 - Speaker 1: Yeah, I think we have a lot to learn from the web in terms of how to promote sort of a more flexible notion of what software can be.

One really cool thing about the web, right, is that people don’t have to build plug-in APIs into their UIs for you to mess with them.

So if you know a little bit of JavaScript hacking, or even, you know, how to open the DOM Inspector on a website, you can go in and delete ads, you can change stuff, you can install browser extensions that modify stuff and none of that is Using some official API, right? It’s just that the nature of the platform is that when you build a website, sort of by default, there’s a lot of hooks built in for people to reverse engineer how it was made and to pretty intrusively modify any part of it.

And I think that’s a really interesting goal to aspire to and more software as opposed to a more traditional plug-in API like in a lot of platforms, if there’s no API for it, you’re stuck, you can’t customize that aspect of the software.

Of course there are trade-offs, you know. The reverse engineering approach is harder, it tends to be less secure, and it’s a lot harder to maintain over time because things change out from under you.

But on the other hand, I think there’s a certain beauty to being able to make changes that not only did the original authors of the software not anticipate and explicitly authorize you to make, but even sometimes ones that they actively don’t want you to make, right? So ad blocker being the prime example of that. And so I’m very excited about the potential for browser extensions as a mechanism for a more customizable kind of software, especially as the web just seems to keep growing and growing as where all software is going to end up living.

00:20:12 - Speaker 2: Yeah, one of my favorite party tricks is opening the Dev Tools console in someone’s browser and doing something like just changing a background color or some text on any website you want Facebook, CNN.com, whitehouse.gov and you know, it can blow people’s minds, wow, you’re an Uber hacker, but I actually also use that as an entry point for getting people interested in programming, letting them see without needing to install any new tools in their computer. Kind of how the web works a little bit under the hood and that they could do this too.

00:20:42 - Speaker 1: I love doing that too. If I’m trying to teach kids about HTML, I’ll always have them vandalize their school website and the Chrome deaf tools inspector and they just get such a thrill.

I think it’s, you know, If you’re brought up in this world where software seems to be this immutable object that is just presented to you, and then someone shows you this little trick you can play, that all of a sudden makes it yours and something you can mess with, I think that’s just a really powerful ethos to instill in people. I think Alan Kay would call it.

Popping open the hood and seeing something sensible inside and just a little bit of that ability to mess with the internals, I think can go a long way.

Adults too, you know, I’ve shown like sales people how to fake a mockup in the browser, and I’ve seen people, adults scream with delight when they realize they can do this stuff.

I do think there’s also a problem, which is that stepping from a little bit of dom hacking and depth tools to actually making a real browser extension, is this enormous leap.

Like, if you think about it, you know, to publish a browser extension or even to save one for yourself, you go from messing around in depth tools to, OK, I’m going to learn. All these weird APIs and I’m gonna open up a code editor now, and I have to learn some JavaScript, and there’s just this huge chasm, and one of the things I’m interested in is finding ways to, I guess, bridge that gap, or just make it a smoother slope from that first hint of malleability to taking further steps down that path.

I think, for example, spreadsheets do this really well, and this is one of my favorite things about the way spreadsheets are designed.

There’s a lot of things that make spreadsheets magical for me, but one of them is that you can take your first step of just typing in some numbers, right? It’s just a data table, there’s nothing special. And then you want to add together some numbers, so you learn to use the sum function, let’s say. And then you just keep taking these little little steps. There’s not that much learning involved with any one of them. There’s not that many concepts involved.

And fast forward 2 years and you’re like running a whole business on like a bunch of V lookups, right? And I’ve met so many people who don’t consider themselves that technically literate, who are in fact incredibly capable in this medium, and I think that a lot of it has to do with the fact that you can sort of accidentally end up becoming an expert, because no one of those steps was too big.

Even though it is the case that, in fact, if you add up all the little steps, you did learn a lot. There was work invested, but it’s a much smoother path to mastery.

00:23:09 - Speaker 2: End user programming is something I think we’re all passionate about here and we’ve written about it in Switch and elsewhere, but this particular element of a gradual step by step rather than having this big jump from user of software to producer of software, I think is a really key part of it.

We haven’t cracked the code on that yet as an industry, let’s say. One great discussion of this. Again, coming back to the web, there’s there’s a YouTube talk I’ll link in the show notes, but essentially someone talks about how they had first were using, I think it was LiveJournal, they quickly learned that you can customize the background color or something by pasting this little magic snippet of CSS and that leads you to doing more customizations, and then you go from there to kind of going to full HTML and CSS.

There are some break points there if you’re gonna, you know, move off to your own home. Hosting or whatever. There’s a similar kind of path also with HTML that are just files that you FTP to a shared server, or shared host of some kind and then you’re just writing HTML but you can actually break out into PHP with these little codes.

So all of these technologies, perhaps not even purposefully, I’m not even sure they were specifically designed to have that gradual ramp, but they do spreadsheets, HTML. PHP all have that kind of ramp, and that ramp is how you can avoid hitting some wall where you have to have some deep intrinsic motivation. I want to learn to be a software engineer or manipulate computers in this way. And instead you’re just on the way to solving your problem. You find some ways to do that by pasting some magic codes into your thing.

Maybe you get a little curious and you follow where that leads, and pretty soon you’re an empowered computer user.

00:24:49 - Speaker 1: For me, this comes back to the bring your own client thing. One of the most frustrating experiences for me in software is when you’re in some sort of monolithic ecosystem, and you hit a wall of something you really want to do, but you can’t do, and depending on how the ecosystem around you is arranged, you might just have no choice. That’s sort of it. You can file a feedback request with the company that makes the software, and they will tell you, you know, we have put it on the backlog. Good luck with that.

00:25:13 - Speaker 2: Yeah, it’s on our roadmap. Honestly, I make that answer myself in a new support requests all the time and it’s genuinely true, but I’ve never. Worked on a software project that doesn’t have a roadmap backlog, whatever it is, that is just way longer than what you could ever hope to do in a lifetime.

00:25:28 - Speaker 1: Yeah, I’ve been on both sides of that too. Actually, a lot of how I got into this whole topic to begin with was from my experience being on the other side of that conversation.

So before starting a PhD and doing research stuff, worked in startups, I spent a while at an education technology company, where we were building software for K through 12 schools and When we started, we were a very small team. I was fortunate enough to join early. We were like 6 people living in a house together. We only had a few customers, and so we had the ability to focus a lot of attention on any individual request that came in.

But as we grew over time, starting to serve thousands of schools across the country, it just became harder and harder to manage all this feedback.

And I think the default answer and what you’re supposed to do, given the way software is currently arranged, is to just get better at saying no. So, you sort of assume, well, we’re a resource constrained team, we are the only ones who can change the software. We don’t have the time to do everything everyone wants, and so we’re just going to do less. And I think that on the one hand, that can reflect sort of a wise style of design where you’re not just building a faster horse, you’re like digging deeper and really building something better than they could have asked for, but often in my experience, it was not that at all. It was just that only 5 people wanted something. And I agreed with them, you know, sure, that makes total sense for you. I can see why you want that. I wish I could build it for you, but there’s only 5 of you. And so I’m sorry, and that just really, I think, was a frustrating experience for me, and I found myself wondering, why does my team, you know, in this office in Boston have to be making these decisions for these teachers in like Idaho or whatever.

One of the bright spots against that sort of philosophy though was coming back to spreadsheets. I remember this feedback call we had with a customer where We wanted to ask them, how did you like our data reports that we’re showing you, cause we were essentially building data dashboards for schools, and they told us, oh yeah, we don’t use your data reports at all. We use spreadsheets. Let me show you. And so they had exported the CSV and made their own thing. And on the one hand, it was sort of annoying for us having spent so much of our time trying to build this beautiful product experience for them. But on the other hand, it was so cool to see how they had built this really weird and ugly, but extremely functional spreadsheet that did exactly what they wanted for their school, and aggregated the data in a completely different way that had to do with how the teams worked within their school. And I thought what was neat about that was that spreadsheets were this flexible tool kit that they could use to build their own thing, even something as tiny as changing a single word of copy that might have been bothering them and causing friction in their whatever political environment in their school. There’s so many tiny things that I think people would change if they could, but it’s just that the way software is built requires everything to funnel through the original team building thing, which is who’s never gonna have the time. And so, I wish we could reorganize software to support more of that style of customization.

00:28:20 - Speaker 2: So we’ve already touched on some of your work here, Jeffrey. I’ll link your articles on bringing your own client as well as one about browser extensions being underrated, but then maybe you can also talk about some of the projects you’ve done that have to do with how you see solving this problem more broadly.

00:28:39 - Speaker 1: So on the topic of interoperability, one idea that I’m excited about is thinking about better ways to synchronize across existing cloud applications. So I think there’s a way in which, you know, if you’re using one app and I’m using a different app, and if we can establish a bridge between them, where let’s say I’m editing a doc in Google Docs and you’re using Dropbox Paper or your preferred editor, and imagine every single keystroke data is being transmitted live between them. That starts to create this more flexible feeling where the data is not locked in any individual app, and it more kind of lives between the apps. And so one new project that I’m sort of embarking on now is trying to create tools that mediate that kind of synchronization across tools.

Some of the hardest part comes back to that partial compatibility issue we talked about earlier, where if there’s changes I’m making that are going to mess up your experience or that aren’t going to propagate to the app you’re using. How can we help users understand the relationship between these apps and feel comfortable with the overall user experience of stitching them together? And I think this gets at some of the toughest challenges in these sort of more flexible software ecosystems is that if we’re all using the same thing, it’s really easy for me to know what you see and what your experience looks like, and the more we diverge. I think it’s really important that I’m at least able to preserve a mental model of maybe there’s some data I’m putting in that you’re not able to see for some reason, and if I’m not aware of that, that’s gonna cause problems, right? And so, a lot of my thinking these days is about building these sorts of sync tools to mediate that gap.

00:30:05 - Speaker 2: I can think of a few examples of that, particularly in the enterprise world, for example, kind of Salesforce to SQL database stuff where your sales team wants to use their CRM because that’s got all these tools and things that suit them, and they’re typing stuff into a web dashboard and getting reminders about who they need to follow up on.

But then your data team or your programmers, you know, they’re not going to go cook around in the Salesforce interface. They need to pull stuff into a proper database like a postres database and so syncing seamlessly between those is valuable.

Do you have other concrete examples you mentioned the project management tool case. What are some other ones that you see as kind of like key use cases?

00:30:45 - Speaker 1: Yeah, it’s funny, sales data is one I’ve heard a lot about too from people and it’s sort of a more mundane use case. I’m not sure I would classify it in sort of the creative tool space, but I think it points to how this need just pops up a lot inside of companies.

00:30:57 - Speaker 2: I’ll go ahead and count sales as creative work. I actually have this discussion of fair fair bit, which is sort of I like to use the term creative professional when I talk about sort of the target audience for muse, but also maybe just the kind of person I’m interested in serving generally. And a lot of people do respond to that with, oh, well, I’m an attorney or I’m an accountant, is that really creative work? And I think it is, I think there is creativity that goes into, for example, financial modeling, and absolutely there can be creativity that goes into sales. It’s not traditional artist type stuff, so I would go ahead and count that.

00:31:30 - Speaker 1: That’s totally fair, and in fact, I think it points to why tools matter in any profession. Like, there’s a reason that people want to synchronize HubSpot with MailChimp. There’s something going on there about what individual tools are good at in the entire life cycle of how you want to run your process, and the need for sync emerges from the reality that no one tool can do everything perfectly. And so I think that’s totally valid.

00:31:53 - Speaker 2: I’m reminded of the phrase toolmaker humility, which came up in our podcast withalant from Kraft where he really tries to keep that in his heart as he designs the product of knowing you’re not only, not the only tool that people are using. but you’re probably a large collection of both process and over time your toolkit is changing and that sort of thing, and I just feel it’s so easy for toolmakers to want to make the everything tool.

Don’t worry, we’ll just do everything and you can put everything in here and we’ll be all in one place and then it can all work together seamlessly and that has never been how the world has worked.

It is never going to be how the world works. If you can design your tool to play as well as possible and be aware of that reality, I think everyone’s better off.

00:32:38 - Speaker 1: I think it’s tricky though, because you need not only the willingness of the tool makers to play with other tools, but you need a platform that supports that interoperability in the right way.

So I think Kraft is the perfect specific example of this. I think they’ve done the best possible thing you could expect a writing tool to do today, which is that I think as Balant mentioned on this podcast, they let you save your documents either to their cloud, which gives you real-time collaboration, you can comment and things like that, or you can save it to a file, which gives you more control.

It is sort of locally stored with you.

You have the ability to save it wherever you want.

Other people can potentially open those files in different applications, I think, is the ultimate goal of that teams, but it’s an either or. So if you want to collaborate in real time and have that flexibility to open those files in other applications, there’s no technological solution to that today that exists. There’s no platform that team can build on to support that, and to me that’s the key missing piece.

There’s this ecosystem missing there, that means that even in this dream world where Google decides they want their party editors to exist for Google Docs or something, supporting that technically is very challenging, and so I think we need better platform support for that kind of thing, in addition to thinking about business incentives for people to even want to do in the first place.

00:33:55 - Speaker 3: Yeah, this is a great example to bring up. I agree there’s a huge technical challenge here. It’s one that I and many people around me and the Ink & Switch research lab have been working on for some years now.

Yeah, so you would need to have that in place, something like files for the real-time collaborative internet. What is that abstraction. And then on top of that you do have this whole issue of business and incentives and dynamics and path dependence because let’s say conservatively that creating this technology takes 10 engineer years. a million dollars, who’s going to put that up and then how do you actually turn that into a public platform that’s optimized for the benefit of all the individual users and not the creator? It’s a tough problem.

One of the things that I liked about this project that you mentioned, where you’re synchronizing data between cloud services, is that it does grapple with the reality of, here’s our initial condition of there are a bunch of proprietary. cloud services that do have important data and it’d be ideal if they had a perfect JSO API, but that’s not the reality that we live in. So we need to find a way to help our users get data back and forth between them. I feel like a lot of the conversations in this space, that is a space of open systems are of the form, we should X where X is design and build and use a perfect open system. That’s not gonna happen. In fact, it’s unreasonable for you to ask other people dedicate their moral lives to your pet projects, right? So you need to find a way to grapple with these dynamics and get out there in reality.

00:35:19 - Speaker 1: Yeah, this is a tension I think a lot about between sort of an incremental approach versus a first principles approach.

I think you could frame it. For example, the solid project, which is led by Tim Berners-Lee and is pretty prominent in this space, is one attempt where their idea is, you know, we’re gonna essentially fundamentally rearchitect how web apps are built. We’re going to give users these little, they call them pods, where the users control their own data, and then web applications can connect to your pod to access and edit your data, but the applications themselves don’t store the data.

And I think that’s a lovely vision. I would love to see something like that succeed, but as you’re saying, Mark, I think the biggest challenge is, how are we possibly going to get from the world we have today to that future? Are we really going to rebuild the web stack from scratch? And is the experience going to be better enough for both developers and users to incentivize such a massive shift? I tend to think that no amount of, you know, legislation or regulation, let’s say, is going to successfully push us to a solution if it’s not better for both developers and users. And so I think we need to think about making it incredibly easy and awesome for both of those groups in order to get from where we are today to that beautiful future.

00:36:34 - Speaker 3: Yeah, and to be clear, I do believe it’s possible to get to a future that looks very different from the present, a radically different future, but necessarily you are going to get there in incremental steps, which might be incremental steps from the status quo or incremental steps from zilch, basically where you’re building up a new system in the context of the current ecosystem. I think both of those are viable. I agree. I think what we need here is entrepreneurs in the broadest sense, not just of commercial ventures, but of ideas and nonprofits and politics and all these things to really work towards the future that they want to see.

00:37:04 - Speaker 1: I think another really important thing on the entrepreneurship theme there is being realistic about use cases. I think my favorite startup style thinkers are the people who can really focus on what is this technology actually useful for, and how can we focus in on that one killer app.

And I’m not sure that we’ve necessarily found that killer app yet in this space.

For me, I think collaborative writing might be the one personally, but I worry that you can make all the tech demos you want. But a lot of things take off in a particular niche. And I’m interested in finding where’s the place where people desperately are needing this real-time interoperability to the point that they would actually abandon their familiar tools.

00:37:43 - Speaker 3: Yeah, I feel like this actually afflicts quite a few projects in the space where, again, they’re thinking in terms of generalities and they don’t have a specific use case in mind. I actually called this the mark rule for product management, which is you need to have a single named human being like an email who specifically wants your projects. And that sounds like a low bar, but in a lot of cases, you ask people that and they’re like, oh, it’s salespeople. Well, do you have a specific one in mind that I can email? Well, not always, right? So it’s a good baseline.

00:38:11 - Speaker 1: Yeah, I think often, especially with this kind of customizable software, it’s tempting to get into wouldn’t it be cool if conversations that where it might be nice, but there’s no real pain.

One use case that I think is really compelling to me is I read a paper recently by some researchers at Northwestern University on accessibility issues and collaborative writing. And they talk about how people with sight impairments have a really hard time using Google Docs with their teammates, because there are certain accessibility issues around how that platform works. And what they often end up doing is they’ll either convince their team to adopt a different workflow, or they’ll just give up and copy paste text out into a Word doc or something, edit it there, and then paste it back. And it’s very, very cumbersome. It’s not just a little inconvenience, it really limits their ability to be a true member of their team. And they have to make this incredibly uncomfortable choice where they talk about the social anxiety around trying to convince all of their coworkers to use a different tool, or just internalizing that friction and deciding to try to live with it.

And I think that if you imagine a world of greater interoperability, could we have a text editor that is much more optimized for this specific group of people who have very different needs and still allow them to collaborate with their peers more effectively? The more that people’s needs differ, especially people with disabilities, I think often have fairly different kinds of needs and a lot of other people. I think that those are use cases I’m thinking a lot about in terms of where we really need better interoperability.

00:39:41 - Speaker 3: Yeah, it’s a great motivating factor. It’s easy to think of the what ifs in terms of cool conveniences and emojis and so on, but let’s not forget about that as well.

00:39:51 - Speaker 1: I also think as an antidote to cool conveniences, there’s sort of an interesting paradoxical way that software customization actually promotes very boring stability.

So I think one of the special things about, let’s say, programmers and their text editors, which is a place where we have some of this file-based interoperability, is that if you talk to programmers, often they’ve invested like a decade plus in using a particular editor, right? And they’ve carried it with them from job to job, they’ve really made it their own.

And they have successfully been able to avoid switching tools because of interoperability.

It’s not this kind of tinkering, trying a bunch of new things mindset. It’s exactly the opposite of just getting to invest deeply in one tool and to keep using it. I think that’s an underrated benefit of interoperability is just. Yeah, being able to make that deep investment.

00:40:42 - Speaker 2: The revealed preferences of software engineers is that yeah, very standardized file formats, usually plain text, wide variety of source editors, wide variety of different kinds of plug-ins and liters and things like that.

I guess you do have to agree on your version control system that needs to be at least somewhat standardized on your team.

Terminal, even things like database clients, you know, SQL is pretty standardized, so software engineers seem to prefer software that changes less.

And has more interoperability and it does have the problem of, as we mentioned previously with email or Twitter as a platform versus a product.

Yes, it is hard. Someone says, you know, programming editors or source code would be really great if you could drop in an image. I could put in a little diagram of my Architecture or something like that in a comment that would make perfect sense. I think that would be a big improvement, but that would be very hard to do because the plain text format we’ve all been using a very long time and all the tools are built around that, but essentially software engineers prefer that versus something sort of newer and shinier and with more features.

00:41:50 - Speaker 3: Yeah, in fact, it’s the ecosystem that is extraordinarily susceptible to customization and extension because all the participants are able and in fact inclined to do that.

So kind of competitively, it’s very hard to win without leveraging that.

I think a good example of that is the editor wars which to my mind are now kind of coming to a close and BS code is one to a large extent I think because of the incredible platformization they have with extensions and language servers and so forth, and typically there’s going to be a bunch of editors. I use a different one. But they’ve been able to really pull ahead while accelerating the whole ecosystem for developers because they lean so heavily into the open platform angle.

00:42:28 - Speaker 1: I also think though that the diversity of text editors can teach us something about how to reconcile this partial compatibility thing we were talking about, because if you think about it, yes, the base format of the code being shared between people can be really stripped down into this text format, but some editors like VS code, do a lot with that format.

They’ll run fancy analysis on top of it and do syntax highlighting and all these like autocomplete things, which are not inherently part of the data exchange format. They’re just Bells and whistles that each individual editor gets to add on top to that experience. But I’m not forced to opt into that. I can use a stripped down, I could use Microsoft notepad to edit code if I wanted to, right? There’s nothing stopping me from doing that.

00:43:08 - Speaker 2: Ed is the standard text editor.

00:43:09 - Speaker 1: Yeah. In fact, I think when I was like 12 years old, that’s probably when I started using to write code because I didn’t know any better. And I think That’s an interesting, for me lesson to reflect on is can we get more places where there’s this shared core and then more functionality built up as optional app specific extensions.

00:43:27 - Speaker 2: And then we touched briefly on, I guess, financial incentives, and we look at the interoperability problem writ large.

Certainly it comes from the world of files, kind of classic desktop files, and yeah, there was problems with sort of format openness like Word docs.

Files, for example, but ultimately files did seem to have a lot of that agency and interoperability, and it’s really both mobile and cloud that I think brought us these more closed up hermetically sealed systems, both for their own reasons.

I think mobile is more around kind of safety and security and comprehensibility to end users, particularly very non-technical users. But on the maybe cloud web app side, particularly B2B software, now you get into this thing where data is considered to be where the value is.

James Chen used this terminology data swamp. That that’s kind of like the aggregating a bunch of data together and that’s where the value is and you even see that in what people expect to pay for software.

We run up against that with Muse, we talked to Balant from Kraft about that as well, which is people are in the mindset of, oh, if you’re going to host my data for me, then you need to run a server or whatever, then I can justify paying a subscription.

But if I’m just buying the software, they feel like software isn’t valuable on its own, and of course that’s really restrictive for making truly great software and furthermore, it creates all these incentives around of course you want to lock up the data, of course, something like a two-way sync. Like you described, that’s hurting my business’s value.

So trying to find a way to create financial incentives and paying for the software and the value that provides you versus the data, the data swamp, that’s a tough one.

00:45:12 - Speaker 3: Yeah, it’s tough.

One angle that I like circling back to a previous podcast on games is, so to kind of recap the dynamic there is that there are some ecosystems that are so high powered because of their open platformized, scriptable, customizable, whatever nature that no amount of proprietary excellence can compete.

And I don’t think we’ve quite found or charted that path in the world of creative tools. You think about, I don’t know, Photoshop. Could an open Photoshop be so much better such that it displaces Adobe Photoshop? I mean, maybe, right? I don’t yet see the path for that, but perhaps in the world of multi devices or multi users or other use cases, there is. So I think that’s one promising angle. There are other angles, but that to me seems perhaps the most interesting.

00:46:01 - Speaker 2: That’s an interesting one to think of the way that for example the web and its open standards and interoperability displaced and was clearly a huge improvement on the more closed up formats like Flash or maybe Java Servlets that came before. Clearly the web was just so much superior and it In addition to being open, hackable, you can pop open your DOM Inspector and do stuff to any web page. So what would be an equivalent of that that would make Photoshop or even something a beloved current piece of software like Sketch or FIMA? What would make those things feel like a Java servelet by comparison?

00:46:38 - Speaker 1: I think there’s a really tricky balance here to strike because it is very valuable to have someone think through an entire unified product experience and make it all fit together in a coherent way.

I know this is something you’ve thought about a lot with when I use Muse, it feels like someone has taken care to design this whole environment and I don’t have to do much work to sort of put together a bunch of pieces. And 90% of people most of the time, don’t want to like assemble their own software from scratch, right? There’s a reason we pay designers. is to think through these problems for us. And I think that’s totally a good thing, and designers bring a lot of value in that way.

But at the same time, I think that we can think about rather than giving someone this hermetically sealed box, can we use an analogy like build a beautiful Lego set for them and hand it to them, where if they like it just as it is, that’s fine. And if they want to add one Lego right there, it’s not a big deal. They sort of see the composition of how this thing was made. They have a little bit of flexibility to tweak it because it’s made out of parts they understand. I think that’s a design ethos that sometimes I feel like we’re in danger of moving away from. There’s this great story in one of my favorite books about end user programming, which is called Changing Minds by Andy Dessa, who’s sort of an education and computing researcher, and he talks about this nightmare he had where he’s riding a bike, and he looks down at the gears, and they are labeled not with numbers, but with words, like this is gravel mode, this is like uphill mode. And he has no idea how to use the thing, you know, if I’m going downhill on gravel, do I use gravel mode or downhill mode? And he talks about how like, because we’re used to riding bikes with number gears, this sounds sort of ridiculous, but you can imagine the product manager that had that conversation where they said, these numbers make no sense to people. People don’t want to like, see 1234, they want to understand the function. We need to give them an easier way to understand what this tool is for. But what you’re robbing them of is a structural sense of what’s going on underneath to provide that functionality. So that the moment you go off the expected use cases for the thing, you have nothing to lean on. You have no coherent understanding of the system, and so everything just falls apart. And what he contends is that people can actually learn sometimes more than I think we give them credit for. Like, it’s not actually that hard to learn a bike. Everyone learns how to ride a. Like, even though it takes some practice and you have to feel out the gears to understand how they work. Once you’ve put in that little bit of effort, you have this sort of generalizable understanding of the system that can go a long way and is much more generically applicable. And so I think it’d be nice to see a little bit more of that style reflected in how we build software for people.

00:49:09 - Speaker 2: Well said, yeah, I think the design ethos often is kind of polarized towards the edges, which are either making pure consumer stuff. It just has to be as simple as possible, no choices, no customization, just can’t have no chance of going off the rails. And getting confused or we have the full on I’m going to build my own PC from parts and put together my own Linux distribution and assemble my raspberry Pi and you put together all my special VS code plugins and there’s kind of nothing in between sometimes.

00:49:43 - Speaker 3: This reminds me of an important point about these platforms and ecosystems. If you look at the successful spaces, whether it’s software or protocols or hardware, it generally is not, you have some platform and then a bunch of individual users completely customizing their setup.

What tends to happen is you have the platform, you have a small number of secondary market providers, if you will, who provide modules. Sanctions, implements, what have you, and a much bigger group that tries, by the way, but a lot of that stuff just kind of gets filtered out, doesn’t bubble up the top.

But if you create an opportunity for people to have a business or some other sense of fulfillment from providing these things to the community, you only need a few of them. To really enhance the ecosystem. And yes, you’re gonna have some users who want to build their whole tractor from scratch or who want to go in and fiddle with the HTML and CSS that’s fine, but often the real main potatoes of these ecosystems is the secondary market of service module extension providers. And the somewhat sad consequence of that as someone who’s really into end user programming is that often it’s not the end user programming experience that matters the most. If you look at how hard it often is to build a module or extension or an add-on, often it’s frankly a huge pain, but people who are doing that as a small business, as a major hobby, they’re willing to get over that and then they can provide the service for all the other users in the ecosystem. So it often ends up being important is distribution, obviously platform access, and some ability to monetize or get the equivalent personal fulfillment.

00:51:20 - Speaker 1: I’m not sure I totally agree that it’s sad for end user programming. I think you’re totally right that there’s this collaborative dynamic, but for me, that’s sort of just one part of the picture to keep in mind when we’re designing tools for this. So like, for example, and I think there’s a similar dynamic in spreadsheet usage, where there’s been some great studies by Bonnie Nardi, who’s kind of like a hero in the end user programming community of how spreadsheets are used in offices and What it turns out being is that there’s like someone in the office who’s like the spreadsheet person, right? And when you have a really complicated formula, right, you go to them and they help you and they figure it out, and then you go back to your desk and keep working on it. But the key thing there is that there is a large part of that ecosystem that is available to you, even as a novice, and you don’t have to like, again, ask someone to ship you a hermetically sealed thing. Maybe you can sort of read the formula they wrote and start to learn a bit. And so I think Having fuzzier boundaries of expertise and enabling more collaboration is a thing to strive for.

One project I’ve worked on that sort of embodies this goal a bit is this project called Wildcard, which is a tool kit for people to build their own browser extensions without programming. And the rough idea there is, like you were saying, Mark, it’s pretty hard to build a browser extension. Some browser extensions are extremely complicated. And when I install them, I have no idea how they work inside. If I want to tweak the extension, or maybe compose two extensions in a new way, that’s typically really hard to do. And the thesis of the Wildcard Project is that, yes, some extensions need to be really complicated like you said, but also there are some extensions that I think don’t need to be that complicated.

I remember using for a while an extension that added a checkbox next to every transaction on a bank statement, so you could just remember whether you’d already written it down somewhere else. And this had like thousands of installs on the Chrome extension store, you know, that’s not a sophisticated thing. But again, it’s really hard to even build something that simple as a non-programmer. So the goal of Wildcard is, can we take that subset of extensions, which is not that complicated and make it accessible to normal people to build. And actually, as you can tell, you know, I’m sort of a spreadsheets fan. And so the paradigm we went with was, what if you could edit a website in a spreadsheet is the vision.

You know, you open up a little pane, you see some data in a table that sort of represents what’s in the page, like on a news site, it might be a list of articles with their names and authors and whatever. And then, As you mess with the spreadsheet, whether that’s sorting and filtering or adding new columns with little formulas in them, all of that flows back into the page and modifies it. And the goal there is that if you’ve used a spreadsheet, you can maybe learn your way around this environment, you don’t need to like open a code editor, you’re just right there in the website and you can build and share these customizations with other people.

Now, again, it might be the case that 90% of users of this thing eventually will just install pre-made things that others made, but if they’re not written in JavaScript, if they’re in this sort of more user friendly paradigm, maybe more people will end up popping the hood there and making little tweaks of their own. So I think it’s this delicate balance there.

00:54:15 - Speaker 2: Well, before we go, one question I think that can come up sometimes is this question of designing software for other people, and maybe you can imagine that product designers who their whole role in fact is doing that and software as this abstract hard to understand thing you actually need another person with that expertise to design it for you. But you could actually swing back the other way as well and say, how can anyone else know your needs? And in fact, this is why some of the startup advice is solve your own problem, build something for yourself because you know it in an intimate way that no one else can. Where do you stand on this? How can others design software?

00:54:53 - Speaker 1: Yeah, this may be a slightly extreme way to put it, but I think I’m pretty pessimistic that it’s possible to design truly great software for someone besides yourself. Especially if the person you’re designing for is operating in a complex environment, like, for example, I had experience designing for teachers, and I’ve never been a teacher in a classroom before.

And I felt like no matter how many user interviews I did, there was nothing that could possibly replace a decade of teaching experience in sort of the depth of understanding there. And I’m sure, you know, I could have done better user interviews or whatever, but that’s sort of, I think, an initial hypothesis.

Then the question is, what do we take from that? Well, in some ways, that sounds really disappointing because You might say what that means is that you’re gonna end up with a bunch of 22 year olds in San Francisco building food delivery apps, because those are the people making the software, right? But I think there’s kind of a fun way to flip it, which is to say, well, maybe that just means we need more people to be able to build software. And you might say, well, I don’t know if, let’s say teachers can build software or if they’re interested in that. But I think that if we had more democratized tools, you could imagine that whatever it is, 10% of teachers who have an interest in this stuff, who have Some sensibilities around design. If we had more tools to help them build their own tools and maybe build tools for other teachers, I think you could imagine a world where we have much more sort of insightful software that draws on the experience of being the user, in a larger variety of domains, that’s not just programmers scratching their own itch.

00:56:21 - Speaker 2: That almost brings a moral argument to end user programming that it’s not just this is something that we as technology people think would be cool or fun or exciting, but in fact is something needed to bring this really important medium, this 21st century medium of software to the wider world, and that’s all the For professions that could need it, young people, old people, people in different places and different cultures, the only way that everyone will really get the software and the computer experiences they deserve is to make programming more accessible, not to every single person in the world, but to enough that we can represent all of those different people in the software world.

00:57:03 - Speaker 1: Yeah, and I think an important thing there is keeping an open mind about how our culture could change.

You know, people throw around the idea of computational literacy, a fair amount in the tools for thought community, and I think one of the lessons to learn from literacy is that it took a while to get to the point where everyone could read and write, and maybe before mass literacy, it would have sounded reasonable to say, why does this farmer even need that? They don’t care about reading and writing, it’s not important to them, but we ended up creating a new society where that was part of How people operated, and I think that you could make a similar argument for building software, where, you know, just because people genuinely don’t think they need to do this today, or don’t care about it or don’t want to, that’s not a reflection of the way society will always be. I think we can, in an optimistic sense, imagine sort of a feedback loop where if we change our tools, eventually society will catch up.

00:57:55 - Speaker 2: I think that’s the perfect note to wrap it up. Thanks everyone for listening. If you have feedback, write us on Twitter at @museapphq or via email, hello at museapp.com. You can help us out by leaving a review on Apple Podcasts, and Jeffrey, thanks so much for carrying the torch and inspiring us all on end user programming and data interoperability.

00:58:16 - Speaker 1: Thanks so much. This is a lot of fun.