I think complexity gets a bad rep, because I think a lot of times people think complexity is the opposite of simple. And everyone loves simple because simple is elegant. How do you have your creator tools give people the knowledge of how to be able to address such complexity?
Hello and welcome to Metamuse. Muse is a tool for thought on iPad and Mac, but this podcast isn't about Muse the product, it's about Muse the company and the small team behind it. I'm here with Mark McGranaghan.
Hey Adam.
And our guest today, David Hoang of Webflow.
Hey, thanks so much for having me.
Now, something that we talk about quite a bit in the Muse world, maybe we take inspiration from physical workspaces, physical studios. But I understand you are creating your own physical studio screen-free these days.
Yeah. It's one of the pandemic projects, if you will. We've been working in our garage and trying to create a more creative space that just really fosters movement. And I think the inspiration just came from back pain, and just sitting in front of your desk all the time and just being on Zoom, which is a lot of my day these days. I was watching Bret Victor Seeing Spaces again and just really got a lot of inspiration of like, how do you leverage physical spaces to create stuff? My girlfriend's an interior designer and I used to do a lot of art. I went to school for art, which ties a lot into a lot of the work I'm interested in these days. And really just wanted to create a space for us to be like, let's just work all analog and really just to feel something. Just create something really physical just to really deviate away from what feels like a 100% digital world right now.
Doing things with your hands, the texture of paper, or certainly craft materials. I like to go to just art stores, craft stores and highlighters and I like chunky markers and I like butcher paper, and I like all that sort of thing. I have less, as the digital tools get better and better, and in fact, superior, particularly in their shareability, which is really important on your distributed teams. Those things become more of a curiosity maybe or something I keep around. But every once in a while I get them out for a similar reason to that. But maybe that means I should really just take up woodblock carving or something like that.
The thing that's interesting about that too is, I think in many ways our tools are processing way faster than we can think about our ideas. The thing I love about working on paper and those chunky markers, like you said, is it gives you time to really flush through the idea and work on it. Because the problem today is not the level of computation you have access to, maybe 10 or 20 years ago. It's like you can process and build anything, but it's just, how do you hash out the ideas? And I've really found this return to working on paper recently. Whether it's drawing up a user flow or creating low fidelity wireframes, it's been really helpful to work in that material that almost intentionally slows down and gives you time to think a little bit deeper.
I'd love to hear a bit about your backstory, days before Webflow, and then what you've been doing now that you're there.
Right before I join Webflow, I was the head of product design at a health tech startup called One Medical, and was there for about four years. I led design and research there.
Quick personal note, I was a customer there while I lived in San Francisco. This was kind of a doctor's office, but reimagined a bit in terms of being more user experience centric. Is that a right way to describe it?
Yeah, that's accurate. I hope you had a good experience with it too.
I did. I'm missing that there is no such thing in Berlin, as far as I know. User experience is not a key feature of doctors I visited here. It's sad to say.
Healthcare experience is something where I think we need more designers and more technology, thinking about that in the user experience. When I was at One Medical, one of the first features I started working on was our video visits platform. It was being able to do a one-on-one virtual call with you and your doctor. I built that prototype using Quartz Composer, and started that from the initial prototype of how we could even wire the EV and really test those use-cases. So a lot of what I've been interested in is design prototyping in a lot of ways. And prior to One Medical, I was director of mobile design at a company called Black Pixel that was really focused on iOS and Mac apps doing our own products, but then also doing a lot of client services as well.
What brought me to Webflow was, after I left One Medical... I think it's really great when you leave a place that you feel like you could be there for another four years. And that's how I felt at One Medical and was just looking for something a little bit different. So I took mini sabbatical, probably about two months off, trying to figure out what's next. And my original idea was considering to do a startup around prototyping on the iPad, because I think that was the year when SwiftUI came out. And I thought to myself, it'd be really cool to build tools for people to build and really build layout. And whether it was like a full on developer tool or prototyping tool, that's what I was exploring. But I think for me, I know how hard startups are and the life expectancy of those.
It is something that I was continuing to explore lately, but then got connected with Webflow. For those who don't know Webflow's visual development platform, it's really focused on websites, blogs and more dynamic web experiences. I think the thing that got me really interested in the that is this bridge between design and engineering. And it wasn't just prototyping, but the stuff you build goes straight into production right away. So you can build your site, publish it and wire up a domain, then you're done. And I was just like, wow. I think this is a really interesting space to be able to take the things that I was really excited about, which is visual programming. And that is naturally just a part of it too. I was like, "Okay, this is a company I have to join." I think at that time they were growing and still growing. I figured, you know what? Instead of doing my own thing, I'd love to join forces with a company that's already doing a good thing.
Thinking about the product positioning there, is the target user... I'm sure you have a lot of diversity of customers now, but when you're doing this design work, do you think of it as someone who's coming from maybe a simpler tool? I don't know, Squarespace comes to mind. Do they want to upgrade and do something that's more powerful and gives them more control over the CSS, more capabilities? Or is it actually the other way around? Which is someone who's been hand-coding their HTML and they go, "This is a little bit tedious and I'd like a visual tool that augments my ability to do that."
Oh man, that's such a good question. And I think it's something we're talking about a lot. The thing that I know for sure is, our end user and who we're targeting are designers. And not to get into this existential crisis, but it's like, what is a designer? There's so many different flavors of what a designer can do. I would say this predates my time at Webflow, but I would say when the early product was being developed, I think it was really focused on the web designer. And the web designer that really knew, really familiar with HTML and CSS, that material of code to create and build these sites.
But I think as our customer base has grown, you are seeing people who maybe their mental models are more from the Squarespace or using a tool like Figma or Adobe XD to really understand design. They're bringing those mental models in. So, I think the thing that I think about a lot is, what are the different types of personas, of designers that we're looking to serve? And that could be many different levels. It could be designers who know code really well or they want to use no-code tools so they don't have to know code.
If I can make a comparison to Heroku, this was similar I think dilemma we had, you might say, in our user base. And of course a good product can be used by different types of people, and it works to try to understand the different segments that you're trying to support. But Heroku both had developers who were people that maybe would have struggled a bit to get a production deployment of Ruby on Rails and a SQL database and so on. We made that much more possible for them to do, but it also had, the other way around, which was professional developers that completely knew how to buy a server, install Linux on it.
Put it in a co-location facility or set up a VPS or whatever, do all that server and operation stuff. They said, "I don't want to bother with that. I would rather outsource it to you, it's non-differentiated work. I just want to build my app." We had people coming from two very different skill directions that land on needing the same solution. But as you said, their mental models of how everything works is going to be wildly different, hence the huge design challenge to make a single product that works for both of them.
It's such a tough challenge, because what I ask myself is, who do you serve in that instance? And for me, the answer should be both. Approachable software for these sort of tools is, you want to be able to abstract away the complexity, but you also want to be able to pop the hood open, if you will. So if someone wants to use code and make things more extensible, there's a lot of challenges if we cap that from people and they don't have access to it. And to what you mentioned with Heroku, it's like, do people go with a different solution, or do you find ways where it can be a little bit more flexible for what people's needs are? And I think that's the sweet spot you want to hit. And it's really hard to find, which makes me really excited about this space. Because it's not only like a diverse persona, but it's also the different use-cases and how people learn too. So, really trying to figure out how you find that place where it meets both of those ends of the spectrum is really challenging.
Maybe that's a good moment to introduce our topic, which is designing for creative tools. Now, creative tools can include a pretty big gamut from word processors and video editing. Here we're talking about maybe the fairly far-end of the spectrum on complexity, which is dynamic modeling tools, web design, development. But if you think of that spectrum as being on one far-end is the pure consumer, very everyday apps. Something like a kitchen timer, weather, maybe things that are in the middle, but still closer to that consumer side. Might be social media, for example. Not to say there isn't a ton of complexity in that, but compared to what you can do with creative tools or what the user can do with creative tools, the variety of possible states, essentially, that a user can put their document into with anything on this end of the spectrum is vastly greater than some of those everyday apps. And that creates some pretty big challenges, but also for the right kind of person, and I would count I think the three of us in that category, those challenges can be very fun and interesting.
It keeps you on your feet for sure, and I think... The word I keep attributing to this is just dynamic. It's always changing, it's always evolving. And I think what's most interesting for me in this space is, you build a set of capabilities for people and you see what they do with it. That's different for what you alluded to, is that a lot of my background before was consumer apps or networks and eCommerce. They are more rigid in the user experience, so it's more predictable with what people will do. Of course there's flows you want to optimize for.
But I think there have been times where, I imagine a lot of spaces of people working in creator tools see this a lot, where end users just subvert and find new ways to use your tool, and you're always so surprised by it. I think rather being worried about what happened to you, embrace that and see where it goes. And I think that's really interesting. It's just like this whole notion of like, I think Microsoft uses the term citizen developer or end users creating stuff. Now it creates such an unknown journey map for a lot of these users, which I think is personally really cool.
That rigid design you mentioned in, for example, eCommerce, that's actually by design. You want a checkout form, for example. The number of forks in that path should be pretty minimal. The data is different, where I'm shipping to is different. Maybe there's a few options in there, but you don't want to choose your own adventure on a checkout form. And perhaps the work you did in the medical space was similar, that you want something pretty structured, pretty rigid. Everyone does it more or less the same way with some essentially minor variation, is really the complete opposite of a great creative tool. I think almost by definition is one that your users will use it to make things that you never expected, like you said. That subversive element.
I think that's why at Webflow we tend to call things capabilities versus features. And we wanted to focus on that lens where it's like, what are we equipping end users being able to do? Versus like, here's this feature that will do X or do Y. But it's more like here's this capability, here's this offering, let's see what you do with it.
I'd be curious to hear if there's any cases you've seen so far of Webflows' users and customers doing something interesting, unexpected, even subversive.
Oh man.
Have you had any Bitcoin miners like we did on Heroku?
Not yet. We'll see, there's still time for that. I'd love to hear the Heroku use-case. There's two that come to mind for me. One is, a Webflow community member created, I think it's called The Big Bed. And it's a children's story that he illustrated. I can't remember if it was directly about his daughter, but it was this narrative that they created. So, he created an interactive site with Webflow that had audio, and just this really great immersive experience. Then there's another use-case where someone in the Webflow community created a game that I used to love playing is, he actually recreated the intro and functionality of the game Civilization in Webflow. And I'm just like, "Oh my goodness, there's so many events, so many interactions built this."
And you could tell the people who build this, it's pure passion for learning and just love of creating stuff. When I saw those two things, especially, I'm just like, "Oh my goodness, this isn't just for building the website built on Twitter Bootstrap where they all look the same." It's returning this expressive form of the web, which got me really excited. Because I think in my iOS days, I think at that time the web was becoming a little bit stagnant and less expressive. But seeing these tools come back for people to be expressive on the web, I think is really awesome.
I think we talked with Weiwei Xu a bit about personalization in our online spaces. And I think I expressed my love of personal websites and the web. And HTML remains and has only gotten better with years. Even if there's fewer GeoCities style places for people to easily have their own spaces, what you can express through a personal site is greater than ever before. But that's balanced out or maybe just round out, would be the way to put it, by maybe social media profiles or even just sites that are designed to be a profile for you. And it's nice, because you upload a picture and you type in a bio. You click on three things you like and it gives you a nice looking page. But it lacks that personality, that expressiveness and certainly that handmade element. But that's still alive on the web in terms of what you can do with HTML.
You have to get away a little bit from the template driven world of, say, a Squarespace and a little bit closer to the metal, if we want to call it that. And I think hand-coded HTML is a great way to go, but not to drop in too many Metamuse references here, but we also talked with Maggie Appleton about visual programming. Which I think, David, discussing that episode is part of how you and I got talking. And she talks about, well, look, we don't want to replace code, but maybe we want to layer new kinds of visualization tools on top of it. I think the web is really perfect potentially for that, and you see a small version of that in, say, the developer tools of Chrome/fire bug-derived developer tools. But there's so much more we could do with that, I think.
For me, the word I keep coming back to is expression. And the expression of how you create. I don't like using web one, two, and three just because I think it's just a continuous evolution. But for the sake, let's say web two is a lot of social media, a lot of feeds, and that's where conversation happened. And I think for me, I grew up in the earlier days of the internet, having a GeoCities site using Dreamweaver to build my personal website. I use this analogy of visiting people's homes and you would go to people's homepages to be able to see that expression, and now things are in social graphs. There's still a lot of where web three might move, and I still think it's really early. But through all this, I think there's a lot of this interest to bring personal expression back and bring back personal websites, blogs, RSS as a technology that I continue to use and love today. And I think there's a resurgence of this because people want expression in the content, whether it's personal expression or that of the people they interact with.
Definitely hitting on some recurrent themes from a podcast here. Just to give another angle on it, this idea of a personalized space is so important for professionals. Because almost by definition, you're spending all of your waking, working time in it. And if you have no agency over how it works and how it looks and how it feels, that's very demoralizing and discouraging. So for that reason alone, it's very important. There's other angles like being able to do things that the creator of the tool didn't specifically envision. And in ways that's the very definition of a creative professional. It's someone who's doing something novel, who's doing these recombinations. Because if there was no novelty for it, it'd be more like turning a crank and why pay really high professional labor rates for doing that. So the tool has to facilitate it. You have to make this leap of, we're going to provide these primitives and building blocks, and people are going to reassemble them into games or whatever, Civilization, who knows? You have to be able to support that.
Going a layer deeper on what it means to design creative tools and design for creators, including designers and developers. One of the big topics in design is always mental models. And I'd be really curious to hear about the mental models you're using for Webflow, David. Maybe Mark, you could talk to Muse a little bit, or maybe we have some other examples from our collective experience. But maybe to start Mark, could you define mental models, just to make sure we're all on the same page?
A mental model is the platonic forms you're dealing with in a domain, it's the nouns and the verbs and how they interact. What is the way that you think about the space? What are the primitives? How do you build on top of them? How do you combine them? For example, with a desktop OS, you have things like files, folders, windows, things like that, mouse and so forth.
One trick I've always liked for coming to grips with the mental model of some system that I'm designing is to write a glossary, essentially a list of all your vocabulary. And these are things that you're surfacing to your user. For example, I think I might have first tried this for the Heroku add-on system. And in writing that glossary, I realized, first of all, we had way too many things. There was like 20 different things in there we were expecting people to keep track of, many of which were relatively new concepts, and certainly pretty abstract ones. So, we were looking for ways to reduce those. Second, I found that sometimes we would use two words to mean basically the same thing and that's confusing. But then third, it forces, me at least, to ask, does each one of these serve a really good purpose?
Is a person going to have a clear understanding of what this item is? They know this term refers to that and they can either connect it to something else they already knew before they started using the product or reading your documentation or whatever. Or for the very few you want to offer as new, is it worth your while to introduce this new term, this new concept? And of course, one of the tricks, I think you illustrated pretty well there, Mark, is to take physical world metaphors. So, your desktop computer is a literal metaphor to your top of your desk. Files and folders are also metaphors. Although, even there you see where it's an imperfect fit. My mom actually has commented on this a number of times, which is, she's worked with paper files and folders for a long time.
And from her perspective, a file folder is one kind of thing. And it's one of those folding Manila envelopes that you can put pieces of paper and documents into. So, she thinks that you should call files documents, and you should call folders files. Of course, we're set now, but it's a good example of where users have preexisting expectations. You're trying to borrow these metaphors, but they don't necessarily map perfectly. But you get some leverage there, because you're not asking someone to learn a whole bunch of new words that don't map to anything they know from any other domain.
My experience has been that the product architecture, which is the phrase we sometimes give to coming up with and naming these mental models, is incredibly important. If you get this even a little bit wrong, it's going to make everything much harder down the road. And in particular if you want people to be able to span the full range of use-cases, from very simple to very complex, and to be able to do unanticipated recombinations, they have to be really solid.
What kind of mental models do you make use of in Webflow, David?
I think a challenge in a lot of creator tools is to decide how opinionated you should be. And what I mean by that is, when you become opinionated, there's a trade-off with that. You can really help guide people in how they build certain concepts, or you be more open-ended and you give people the flexibility to explore that. And I think the thing that's tricky with that is, the question I ask myself is, what mental models do people come in with using Webflow? So someone who is a front-end developer, the way they approach using Webflow is going to be dramatically different than someone who may use Figma. And I think the thing that's hard is, in design, there's a lot of these things that are very similar, but not necessarily identical. For example, in Xcode, the auto layout engine is a lot different than auto layout in Figma, but yet these are things that people associate with how to approach using it.
So, I think when we're thinking about the mental models of Webflow, I think a lot of things that we're asking ourselves is, what do people come in expecting? Someone who's coming in and using layout may not think of things as divs and also think about things like nesting and parent-child relationships. They may be thinking of it as an infinite canvas that they drag and move freeform. And unless you set position to absolute, there's really no way of doing that in a way that produces good code. That can be frustrating for users if you're coming in, not knowing box model and some of these web design practices. So, I think a lot of things we're thinking about, it's like, how do we become more opinionated in our own product without biasing them on what to build?
For example, a lot of this can come from onboarding new users and teaching them, Hey, these are the core aspects of web design that's going to be really important for you to know. You already know this? Great, you can skip it. But if you don't know, it's going to be really helpful for people to really understand those mental models. Because I think for me, really being true to the material, and the material in this case being HTML and CSS, I think I personally wouldn't want to abstract it so far away where you're creating some proprietary markup or something. You really want to make sure that you can get as close to the native output as much as possible. But abstracting how people build with that, I think is key.
It also occurs to me that some of the mental models are things about, what do my users come in expecting? A front end developer versus a designer, for example. But also, as you said, the material, you just inherit a bunch of things that are just true, whether or not you want them to be. And certainly the web and HTML and CSS are full of plenty of quirks and history and that sort of thing. So something about how the grid system works or something about how flexbox works or what have you, you're just going to inherit that. Some of that may be good, because there's good mental models. Some of it may be more like baggage or gets in your way.
So presumably maybe... I'm realizing now I'm just restating what you said, but just for my own understanding, you're trying to figure out which things are abstractions you really want to surface to your users. Because they're useful, they're powerful, they're comprehensible. They fit well with the visual tool you're creating, which are weird quirks of the web that don't really help you to know and I don't need to know about. I don't know what Java script modification, we do that quietly behind the scenes and kind of tuck it away. And you don't need to really have a concept for that in your mind to get value from the tool.
And I think this is why I like the jobs-to-be-done framework, where you're focusing on that outcome that a customer wants. I think for us, when we think about it, there's like multiple ways to build a layout. But if we're looking at some of the best practices of, here are the things that people typically try to build and it solves 80% of those use-cases. How do we surface more of that? Because the likelihood of what people want to build with that is higher, and there's always going to be this option B, C, D, and E that people can explore. But when you give them A through E all at once, it's this paradox of choice.
So, if I drop a div and then you're asking like, okay, you can use display, flexbox, or grid. Someone who doesn't know what the difference is [inaudible 00:28:10], they'd probably just pick one. And then really just trial by error with that. But if we can be more opinionated about some of these things, I think it helps reduce the cognitive load of decisions that people have to make. So, can we streamline people to what we think is the best decision while giving them that option to subvert it, or explore other paths too? As opposed to give them all the divergent paths at once.
Now, here we've spoken a little bit about things within the page, a div, a flexbox, and that sort of thing. But actually the web has a huge number of abstractions or that mental model glossary for the web would include pages, would include URLs, would include links. I think all of those are pretty well understood even by non-creators, which is actually pretty great. So you can just rely on using those things, I assume. Even something like a website, what actually is a website, where are the edges of it. That may or may not be fully understood by the average person. They may not fully grasp when they leave Facebook and go to another site. But certainly I think for your target audience, those things are probably really well understood and you can totally lean on that. Is that right to guess?
Yeah, absolutely. And I think that's the beauty of building for the web, is there's such a rich taxonomy and a lot of standards already set on that. That even if people aren't familiar with it, it's not they're learning just Webflows' mental model. They're learning the mental models of building a website and its links, buttons. And even in layout, thinking about sections and some other elements that are offered to people. So I think that's the thing that's been helpful for us, is that it's like, as you're learning Webflow, you're learning the web mental model as well.
Can you give us an example of something... We've talked about this visualization element, which in many cases, I think a visualization tool is something that doesn't really add a new mental model. It just helps you better... Well, literally see what it is that... Understand, for example, margins and padding, because it shows you all those layouts. Is there some major new abstraction that Webflow gives you that's a new capability that's added to your user's toolkit, but it is not something that comes from the web, but is something you created as part of your universe of mental models?
Yeah. It's not something we originally created, but maybe I'll throw this example out here because we just had our no-code conference. We announced a capability that we call logic. Now when you have the UI side of things and you have logic and you have data with our CMS offering, it's essentially a one-to-one connection to model-view-controller. I think as we start exploring this is like, the question I'm asking is, do we teach everyone the fundamentals of model-view-controller and ask them to build it the exact same way?
Are there ways to leverage those ways of doing things in new ways? And I think for us, there's a lot to be able to explore there. Even with our CMS, it's like we're letting people buying data to layout and building collections with them, not necessarily knowing what a collection is and how you would build that in code. So I think it's not necessarily like inventing new definitions of things, but maybe new ways of manipulating and using it. And I think for us, now that we have data UI and logic, being able to manipulate layout or data based on events, there's a lot for us to really explore on how end users interact with that.
This brings us to another interesting aspect of designing for creative tools, which is the social aspect. Increasingly designing tools and then using the design tools takes place across many people. And there's interesting social dynamics there. Especially if you look at a domain like the web, which is very multidimensional, you can use absolute positioning or box model or grid or whatever. You have to come to some common language and understanding as a team. And sometimes you've just got to pick one, or be on the same page, or at least call things the same thing. So, an important job of design tools I think is helping teams reach that agreement. I can give you two examples. One is Heroku, where there's basically a lot of ways you can design and deploy an app. Heroku picked one, and there were good reasons why Heroku picked that way.
We said, "Basically, you should do this. You should use GIT, and you should not write to the local file system and so on and so forth. You should use environment variables." Yes, those were good choices to make in of themselves, but they also basically forced everyone onto the same path. Which was itself another example that's maybe more analogous to Webflow, is Ruby on Rails where basically just need [inaudible 00:33:08] pick a way to do NBC, like put this here, call this that, use this convention for converting between lowercase and uppercase. And just do it, you'll be fine. There's actually huge service and just picking these defaults and having these guardrails in place.
It's really interesting you bring that up, Mark. Because I think one of the things we are really thinking about, and that's really top of my mind is, how does collaboration work in web design and in a tool like Webflow? I can give some examples of that is, one, let's say you have an end user creating their site, but perhaps they find inspiration from our showcase and they pick a template to use. But that template is built flexbox only. And let's say they use CSS grid or something else for their site. They drop it in and just boom, the whole layout just collapses. So I think for us, that's something to really think about. It's just like, again, just how do users understand how the material is created? I don't know if it's something where we want everyone to use flexbox only and get rid of the other stuff, because there's implications with that.
But how do we nullify and make sure that when people are using other resources that people build, like in a community aspect, that there's clarity, there's good documentation, and there's some good best practices around that? I think the other thing that you touched on, Mark, that I think is really interesting is, how do you think about design architecture as a team? And if you have multiple designers working in Webflow on a larger team, it's like, how do you make these agreements and how do you declare these things? That's like, Hey, as we're working, this is our approach to naming our CSS architecture. Or this is how we want to approach building pages and having that. I think a lot of that lives off platform right now, today. Some of the things that we're thinking about is just like, how do we enable teams to work better in Webflow? And I think we're still doing a lot of research on it and trying to figure out what that best case is.
It seems inevitable that all design tools are going to become collaborative and social, at least have the capability to do things as a group. And it's interesting that we're working our way up. So the first thing was Google Docs, which is text. Then you add the whole Office suite and now we're working on complex tools like Figma and Webflow. I think eventually we'll get to video. That's probably the hardest one to do collaboratively because of bandwidth, but we're going to get there. It'll be interesting to see how that all plays out.
I'm starting to see a lot of startups working on collaborative video too, so I think definitely a really gnarly problem, but I think it's a sign. Like you said, it's inevitable that everyone's shifting to collaboration in as real time as possible too.
A bit of a tangent, but it's certainly a reminder of something I feel like comes up on Twitter from time to time. Which is, it does seem odd that you basically have all of these startups that are reimplementing collaboration, typically inspired by Google Docs or some combination of Google Docs and GitHub. And in fact, given that we want every single tool to be collaborative, couldn't you imagine that as an element of the operating system or the file system? And instead every single startup that does this has their own big engineering team and needs to build it all. One can't help but to envision that future operating system where, by default, that is part of anything you build.
I think about that a lot, about annotations too. Couldn't the annotations and commenting be more native across the operating system based on the objects that you're working with? But like you said, a lot of these tools, it's part of this walled garden. Everyone's building their own version of it, and there's got to be a way where... How do you take that a layer deeper, either in the operating system or being more open source about it? But it is interesting, everyone's building these same set of features. And I always think about annotations and commenting as ones that I would love something like that on the OS level.
Actually had the aspiration for such a thing existing, I think it could be an OS service or a web service like S3. And I repeatedly hear people ask for this and I think there are two big hurdles. One is, there's an expertise hurdle, which I think is not obvious until you try to do it, but it's very hard to build such a system. I think it's basically impossible to do without having a motivating example product. So, I think it's most likely this gets extracted out from either a company or someone who has experience with the domain of trying to build such a system.
And I think there's an important path dependence thing where, yes, everyone wants the operating system to support this. But it'd be very convenient if the operating system was the one that already ran my program. I don't want to have to rewrite all my stuff, or change my business or I lose my business for such an operating system. So, there's the first-mover problem. Basically I'm looking for the bookstore that wants to get into the business of web services in this space. And I think they're out there somewhere. If you are, remember, we're looking for such people, so contact us, please.
David, what you mentioned earlier about the dropping of flexbox component into a grid layout also makes me think of another thread here, which is the componentization element of things. I think a product with a good mental model, a good set of abstractions, the elements of it can be combined together in a lot of different ways. Again, ways the creator didn't originally expect. But you take that even a step further, which is not just that I, the person using the tool within my document can do interesting and different things. But then you can go from there to, as you said, the collaboration.
We're on a team and we're working together on something like a website or a document. But then the further step is to go from there to, you have these components that you can plug together where maybe I don't even know the person that made this calendar widget that I'm plugging in. But I feel like this has been a dream for a long time and maybe one that there's been many attempts. I think OpenDoc is a famous one there. Maybe ActiveX, Microsoft had a couple different iterations of object embedding. I'm curious if you have a take on that path of computing history attempts.
I can speak about the promise of OpenDoc, because candidly speaking, I never really had a chance to play around with it and implement it. But I think this idea of component software that is reusable and adds value for people immediately, I think there's still a lot of ways to the dream. When we think about community plugin ecosystems, it's still an aspiration I want to continue pushing. Now, there's a lot of trade offs in practice, because I think for me, someone who used like CocoaPods a lot, there was something around how open are these plugin ecosystems. And I think that's a tough trade-off for any platform that's being built. But I think for me, with OpenDoc... I felt like WebObjects was a lot of this too, in this world where you now have people who can build components that serve other people and really being able to open up how work is done, whether within your company or externally. But I think OpenDoc is just one of those, still waiting for that promise to be fulfilled. And then I think that vision is so inspiring.
I think this is a super-interesting frontier as well. And I think it's under studied and under theorized. I think people don't appreciate how complex it is, especially when these plugins are turing-complete and they have access to compute and data, that is your compute and your data. They can do wild stuff. And there's a duo of this problem in the engineering world of libraries. And I think we're still in the very early days of how we think about libraries, which is, basically we download a bunch of random code from the internet and run it on our computers. And who knows? A lot of it's probably mining Bitcoin or stealing my keys. It's a complete mess. I think it requires a very serious design and engineering effort, as well as, again, this respect of the path dependence problem where you need a way to bootstrap the ecosystem and to incentivize the ecosystem. So, I'm still optimistic, I just think it's a very hard problem.
I think in a lot of ways, you're right. It's still so early in the way that we're doing it. And I think one of the things... Let's take no-code for example, and use this OpenDoc analogies. I've always described as no-code being the 3D printer for building on the web. What it does is really it creates repetition and reusability in a great way. Now, no-code tools, there's always going to be this threshold where if you're doing something sophisticated, you might need to code it. So, it's never this like one or the other, but I think it evolves into that. And I see that with component software too. In the sense that's like, I think about this all the time. If I'm building an app, I'm like, why do I always to build the same authentication flows?
Or build these things that people predict. It's a very rigid solution intentionally, like eCommerce and checkout, some of these things. Why do these things have to be constantly unique? There's clear interactions of what people expect in those. And how do you do those things at scale so then the things that need to be unique for your business or your product, you can really focus on them? I think that's where... Again, I think this whole concept of component software, I still very much believe in it. It's a very ambitious vision. And I think in a lot of ways still pretty early.
By the way, probably is worth defining no-code briefly for the audience. Again, we suspect a lot of folks may have, at a minimum, heard of it. But given that you put on a conference with that name, seems like you might be an authority to speak to what you think that word means. What the category is, what the movement is, et cetera.
Yeah, absolutely. Maybe I should start with what it's not, which is not the absence of code or any existence of that. It's really more of the primitive that you build with. Instead of building using code in a command line interface or a text editor, it's through visual abstractions. So, there's no-code and low-code, but it is something funny where it's not even, in my opinion, combating with code. It's just the existence of these two approaches in a lot of ways. And I think the companies that are going to excel at this, they're probably going to use a combination of both, depending on some of the different use-cases. But no-code is starting with not needing to learn how to code, and you're focused on the visual abstractions of creating with code.
My sense is that it's often non-programmers doing automation, and particularly connecting services together. So, I think of the If This Then That and Zapier as being a starting place. Very simple, just... I don't know. We use a Zapier integration for someone tweets about X, then put it in the slack channel, for example. Or you get an email with a PDF, stick it in this Dropbox folder. Those kinds of basic automations. Certainly, I'm sure professional software engineers sometimes use such a service, just because it's easier, less work to maintain or whatever, than using their full on development stack. But I think very often it's a business person, or a designer, or some other person writing a, I don't know what, a shell script to do the same thing would probably be out of reach for them.
It makes me think about name any use-case, where before you'd have to ask an engineer to run a Rake task, to be able to get all these things done. Now you're empowering people, like you said, maybe they're on the business side of things or not on the engineering and product side, to be able to create their own automations in that way. And the question I always ask myself is, this is the stuff you want to democratize even within your own company. It may not be the stuff an engineer even wants to work on, so it's like... Again, it's not contrary to how you do it, it's just really thinking about some of these use-cases. I don't know, do you all remember Yahoo Pipes? That was another one that I think about with automations too.
I had to do some serious digging around in the web archives to find a screenshot of that, because I wanted to reference it for the Ink & Switch end-user programming article that we did. But I think of that as one of the-
Nice.
... original put together flow-based programming with, I guess the emerging idea of web services, or the fact that a URL over here has a web report. And another API over here is where I can feed in my travel plans, and maybe I can connect all those together with, well, Pipes. Maybe it was before its time, I'm not sure, but the concept there was so simple. And maybe coming back to our mental models point, you even look at the screenshot, you instantly understand what this is doing and what it might be capable of. Now, another thing that I think about when thinking of a tool like what you're making with Webflow, I think Heroku had some of this as well. And I think any kind of creative tool always has this. You talk about your ideal is the low floor, high ceiling. That's the idea. It's relatively easy to get started with, but you don't get constrained later on. There's also these powerful cases.
But I do think there are cases where you do want to say, "Okay, you are asking for something that actually is more off the edge of what we actually want to offer with the tool." Certainly we ran into this with Heroku, someone would come in, "I want to tune all these kernel parameters, whatever." We would say, "Well, look, this actually isn't the right platform for you, because that level of control and customization is exactly what we're trying to save you from. We've just made good choices there that will work pretty well for most people, and you can just remove thinking about all that stuff from your head." And an example that I like to cite a lot for end-user programming is Flash, which I think did a really great job of bringing animators, who we now call motion designers, into something that was essentially a programming environment. But it's been speculated on some of these Flash died postmortems that came along a couple years ago, that one of the issues that it faced was, in those early days, it was so accessible to animators.
Then people started making games. Those games would get pretty complicated. They would need all these things that just professional software engineer need, want, expect in terms of data layer, caching, complexity of the language, all that kind of stuff, ability to add libraries and dependencies. And eventually it became such a powerful programming tool that it actually lost that ease and that accessibility. Essentially, the floor crept up as they pushed up the ceiling. So, I also in designing a particular tool, it's very reasonable to decide our spectrum of use-cases. There's some that's going to be too trivial or too... We don't want to make things so easy, we'll push you out to some more beginner tool. But there's also a ceiling somewhere where we say, "Look, you actually reached the limit of what this tool is for, we're not designing it for you. You should go use this over here that's more powerful, but also has other trade-offs."
Furthermore, I think there are different ways to do this. I think the ideal way, again, if you have the right mental model and product architecture is to have basically a nested mental model, a nested architecture where you can peel back layers and get at the granular abstractions within. There's all kinds of examples on Heroku. I think we did do a pretty good job with this. If you git-push an app to compile and deploy, it just basically picks how I think it should compile based on what the app looks like. But if you want, you can swap in your own compilation step and say, "Here's the script that I want to compile this app." But critically, both the Heroku default and that script use the same interface. They're totally interchangeable. It's like basically peeling off that one layer and saying, "I want to insert something different into this interface."
It's not saying, "Oh, well, Heroku only deploys Ruby, I've got to go do my whole own thing on AWS from scratch." You get to granularly pick apart pieces, and there are all kinds of examples of that. In contrast, sometimes I see these programming tools that are like code generators, where there's a super-complicated problem and you invoke the code generator and it spits out a hundred files. As long as you don't need to do anything different, you're fine. But as soon as you need to do something different, you're completely out of luck. It's like you're often hand-editing these 100 different files. So, I think the extent that you can create a system where you can peel back these individual abstractions while still enjoying the stack overall, that's great.
It makes me think about... I'll give a small example. There's this note-taking tool I love called Obsidian. The thing I love about Obsidian is, easier, local markdown files. So, if Obsidian ever gets to a point where it's not scaling for me, which I think it serves my use-case, well, you still have the native markdown files and you're not stuck in that application layer. And I think great applications will figure out ways to be more of a facilitator than controller on that. I think for something like Webflow, we think about, okay, we no longer are meeting the threshold of what a certain customer wants. They can still export their code, but are there other things we can build to make that interoperability a little bit easier too? So, I think that's the trick, is like being an application that can be great at facilitating some of these things. If such things do evolve too, that you're not locked into that. But I think what you said, Mark, is spot on.
I guess in the ideal world, you design your tool so that you start with a basic set of primitive abstractions, mental model glossary that hopefully someone can understand and do something useful with. When they need a little more power in some particular areas, that's where they, as you said, Mark, peel it back. Or I think, David, you put it as popping the hood, and you can go down one layer at least for that spot, but you're not completely off in some new world. You're still within the universe of abstractions that all fits together.
Then there's a final step, which might be, which you referenced there, David, which is where you actually do get to the end of what the tool can do for you. But hopefully, now it's not... Now I'm really screwed, and I have to just recreate everything from scratch in some new environment. But rather you can, I think React Native uses this term eject, where you essentially can say, "I want to take my project out of the React Native world to just make it a standard Xcode or Android Studio project." And there's no going back once you eject, or no easy going back, but that's your out.
Interesting choice of words, React Native.
That's actually the kind of project that I was thinking of in my previous example, where if you have to eject in that case, I think it's pretty bad. I mean, you can still run. Another example of ejection would actually be with deploying apps with Heroku. If you have a standard app, you can deploy to Heroku, but you can also take that standard, like Ruby on Rails app, for example, and deploy it somewhere else, sort of an ejection in a sense. This is a very important concept, by the way.
Another way I think about this would be as an efficient frontier, where the axes are difficulty/complexity and the other axis is power. And what you want is, you want a smooth trade-off on those where you can always add a little bit more complexity to get a little bit more power if you need it. So if you need a little bit more power, you never have to undergo a huge complexity jump, like migrating your app to a whole different platform, for example. There's little changes you can make along the way. And furthermore, you want that frontier pushed out as far as possible, so that the minimal amount of complexity is needed for the given amount of power.
I think complexity gets a bad rep too, because I think a lot of times people think complexity is the opposite of simple. And everyone loves simple because simple is elegant, so then complexity becomes a sort of villainous thing. I think there are times where we do need to embrace complexity, but how do you make it approachable? I think that is the thing to solve [inaudible 00:53:26], is to figure out, when there is a time where complexity is called for, how do you have your creator tools give people the knowledge of how, again, to peel that layer back or pop the hood open, to be able to address such complexity? As opposed to avoiding it entirely.
Again, I keep coming back to this idea of mental models. Often with complexity, you're dealing with a fundamental reality of the underlying world. And if you ignore it or try to cover it up for long enough, you just make it worse. You have to address it. But on the other hand, you don't want to make that problem any worse than it is by, for example, combining two problems and giving yourself three problems.
I'm reminded of the Einstein quote, "Everything should be made as simple as possible, but no simpler." Which is, the world is complex. It can be messy. You're creating a tool for someone to model something about the world or create their own little, mini, made up world. And they are just going to need to deal with that complexity. In the web world, that's something like all the different browsers and all the different devices that someone might browse from. And different screen sizes, and the difference between interaction on touch versus mouse versus trackpad versus stylus. Those things all exist and you need to deal with them when you're creating something. An attempt to totally abstract all that away because it sounds too complicated, may impair the ability of the creator to make something that's really good.
Because abstraction still derive from the original thing. And I love the idea of really focusing on, where do you address complexity? As opposed to neglecting it or putting it everywhere. So, when you have these complex things to solve, what's the optimal place to solve it?
Yeah, absolutely. Well, I do think we're in a golden age or the beginning of a golden age for creative tools. That includes being more interesting, maybe, place for designers to go work on tools for thought and things like that. That the stodgy old, vanilla styles of the Office suites of the past and so forth are giving away to more stylish and interesting and opinionated tools for thought, and developer tools and designer tools. I'd be curious to hear from both of you, looking forward, the future. If we could fast-forward that trend three or five years, how does creative tools look different in the near future?
I think you're going to see a lot more participation in it. It's almost like the consumerization of creator tools, which I think is exciting. And the reason I'm excited about it is, I believe some of the people with the best ideas and things that can be life-changing and can really change the world, probably don't know how to code. They might not know how to design. So, being able to give a platform for people to explore and express, gives the continuation of such idea to manifest in other ways. Now, it may not be that person who ends up creating it, but maybe it sparks an idea somewhere else. I'm always a big fan of participation in anything. Because I think, for me, honestly, if it wasn't for visual programming tools like HyperCard and Quartz Composer, I may not have gotten into an interest in building software. And if I went the conventional route, I probably would've failed. So I think, for me, that's what I'm excited about. Like this whole notion of end-user programming and it being more accessible, just for people to play and explore, is pretty exciting for me.
It's funny, I'm obviously a huge proponent of end-user programming and more people learning how to grasp the power of the dynamic medium that is computers, not just as users, but as creators of software. But when you use the word consumerization, then that actually almost gives me a little bit of an opposite reaction. And intellectually, I think I agree with you that more participation, more accessibility is better. But I guess as a crafts' person, and I love my nichy and sometimes complicated, powerful tools, then what consumerization brings to mind for me, I don't know, Instagram Stories.
Or for example, you've seen this in some of Apples creator products, like they have for audio editing you've got Logic Audio, but then you've also got GarageBand, which is installed on every Mac. It's pretty simple and easy to use, which is nice. But then in some ways, they brought some of that design aesthetic to Logic, maybe taken away some of the things that the long time pro users of that could be described as a dumbing down. So, it's interesting to reflect on that reaction to myself. I don't think that's a good thing. I don't think I'm proud of it, but I just had that twinge when you said that word.
Oh Adam, I've got a different phrase for you. What if we called it end-user creating, as a generalization of end-user programming. And this is a road we're already part of the way down. So, it used to be that even end users couldn't do something like word processing, that was a professional activity. You had a typist or whatever. We've since brought the Office suite to end users, and now I think we're in the process of doing that for richer media. So audio, video, webpages, of course, those are things that are on the cusp right now of... Even a few years ago, it was quite hard for someone to casually do audio editing or video editing. But now, you go look on YouTube and there's these super niche, random people doing super-random stuff, but their video quality's like insane, because everyone can do video editing now. And I think that progress is going to continue.
Yeah, it's interesting. I think, Adam, even when I said that word, I had a similar reaction too. And it just makes me wonder, has the term consumer transformed in a way that needs to evolve a little bit? But I'll give you an example. There's an awesome iOS app called Universe, which lets you build websites on your phone. And I think for that... That to me is the consumerization of a creator tool. You're taking the mental models of what people are used to on their smartphone, dragging and dropping, these swipe gestures. But instead of consuming content, maybe it's more the consumers are becoming creators. So, it's normalizing creators in that way. And I think Universe is a great example of that. But just wanted to say, when I said that word too, I had a certain mental model that came to mind and I think it's... Maybe it's more turning consumers into creators rather, with the mental models that they know.
I love that. And certainly I have my own career to thank for that, in a way. As a kid had I loved video games, I was a consumer of video games, and that led me to think, I want to be able to create these for myself. How can I do that? Back in those days, that was breaking out your basic prompt and doing some turtle graphics and that sort of thing. Nowadays we have quite different tools at our disposal, but having that smooth on-ramp and folks have talked about how we've, in some ways, have lost that as computing has gotten more sophisticated. It means, that same eight year old with an iPad, they're playing the games and they're thinking, how can I create these games? And they can't, because basically the whole stack of software creation and design tools lives on a totally different platform and requires professional buy-in and is incredibly complicated.
But anything that brings us back the other way and puts that creator power into the hands of interested people who, they may just dabble in it and that's fun and satisfying and they never go further. And others may actually find their spark there and their inspiration. And they go from there to something more sophisticated, and both are great. Having that smooth ramp rather than gaps or a wall or a gap, whatever metaphor you want to use, on the other side of the "serious professionals." And you have to do some kind of ritual to prove your worth to be part of them. But in fact, if you have that spark, that bug to create and you pursue it, the opportunities are in front of you to take it as far as you wished to take it.
It's interesting you mention that, Adam, because I think what had dawned on me is, the same way I got into computers from playing the video games and understanding how sprites are created. That sparked this curiosity for me to create. I don't know if that's happened for mobile and tablets yet, because even though the inspiration is on-device, to be able to create it's off-device. And maybe this is where Xcode's going to bring a lot more things to the iPad and be more mobile centric. But maybe perhaps that's the reason we've seen so much hyper-consumerism on these smartphones, is that the tools on-device, we may not have had that evolution yet the same way as on my Apple 2 or name any old computer. It was on-device and you're creating on the same platform. I don't know if that's really happened with mobile. A lot of that still locked in. So, it'd be interesting to see how that evolves over the years.
I think the web has its own version of at. I think, in many ways, the web is better in the sense that maybe it's a little more hidden in the menus now, but you can still view source on any webpage. You've got dev tools, inspector, and certainly anyone that wants to grab a Glitch account or a Webflow account can start making simple web apps without a huge amount of ceremony. Nevertheless, there is still a bit of a gap you jump over, and certainly compared to the original vision for the web, which was something much more read-write. Something much more where you right click a page and say edit, and it takes you in. Or maybe something like Beaker browser has an interesting vision there, where essentially any web page you're on, you can click a fork button, you get a local copy and you can start editing it.
I like to see things like that, because I feel like it helps reverse, or provides a counterbalance to the tendency that as systems get more complicated, of course they get less accessible and the tools for creation get further and further away from the regular tools for using. So, hopefully we can say Webflow is part of that story as well. Well, let's wrap there. Thanks everyone for listening. If you have feedback, write us on Twitter @MuseAppHQ, or via email hello@museapp.com. And you can help us out by leaving a review on Apple Podcasts. David, thanks so much for help-making creation on the web something that's more accessible.
Oh, it's such a joy. I feel like it's a life purpose in many ways. Thank you so much for having me on the podcast.