Transcript

00:00:00 - Speaker 1: I think complexity gets a bad rap because I think a lot of times people think complexity is the opposite of simple and everyone loves simple because simple is elegant. How do you have your creator tools give people the knowledge of how to be able to address such complexity?

00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac, but this podcast isn’t about Muse the product. It’s about Muse the company and the small team behind it. I’m here with Mark McGranaghan. Hey, Adam, and our guest today, David Hong of Webflow.

00:00:38 - Speaker 1: Hey, thanks so much for having me.

00:00:41 - Speaker 2: Now something that we talk about quite a bit in the Muse world, maybe we take inspiration from physical workspaces, physical studios, but I understand you are creating your own physical studio screen free these days.

00:00:54 - Speaker 1: Yeah, it’s one of the pandemic projects, if you will.

We’ve been working in our garage and trying to create a more creative space that just really fosters movement and I think the inspiration just came from Back pain, you know, and just sitting in front of your desk all the time and just being on Zoom, which is a lot of my day these days. And I was watching Brett Victor seeing faces again and just really got a lot of inspiration of like How do you leverage like physical spaces to create stuff? So my girlfriend’s an interior designer and I used to do a lot of art. I went to school for art, which ties a lot into a lot of the work I’m interested in these days and really just wanted to create a space for us to be like, let’s just work all analog and really Just to feel something, right? Just create something really physical, just to really deviate away from what feels like a 100% digital world right now.

00:01:57 - Speaker 2: Yeah, doing things with your hands, the texture of paper or certainly craft materials. I like to go to just art stores, craft stores, and yeah, I like highlighters and I like chunky markers and I like butcher paper, and I like all that sort of thing, and I have less as the digital tools get better and better and in fact. Superior, particularly in their shareability, which is really important on your kind of distributed teams, those things become more of a curiosity maybe or something I keep around, but every once in a while I get them out for a similar reason to that. But yeah, maybe that means I should really just take up like wood block carving or something like that.

00:02:34 - Speaker 1: Yeah. The thing that’s interesting about that too is I think in many ways, our tools are processing way faster than we can think about our ideas.

And the thing I love about working on paper and those chunky markers like you said, is it gives you time to really kind of flush through the idea and work on it because the problem today is not the level of computation you have access to, maybe 10 or 20 years ago.

It’s like you can process and build anything, but it’s just like how do you Hash out the ideas and I’ve really kind of found this return to working on paper recently and that’s whether it’s drawing up a user flow or creating low fidelity wireframes. It’s been really helpful to work in that material that almost intentionally slows down and gives you time to think a little bit deeper.

00:03:24 - Speaker 2: And I’d love to hear a bit about your backstory, days before web flow, and then what you’ve been doing now that you’re there.

00:03:30 - Speaker 1: Yeah, so, right before I joined Webflow, I was the head of product design at a health tech startup called One Medical and was there for about 4 years. I led design and research there.

00:03:41 - Speaker 2: Quick personal note, I was a customer there while I lived in San Francisco. This was kind of A doctor’s office, but reimagined a bit in terms of being more user experience centric. Is that a right way to describe it?

00:03:54 - Speaker 1: Yeah, that’s accurate. I hope you had a good experience with it too.

00:03:57 - Speaker 2: I did. I’m missing that there is no such thing in Berlin as far as I know. User experience is not a key feature of doctors I visited here, sad to say.

00:04:08 - Speaker 1: Healthcare experience is something where I think we need more designers and more technology, like thinking about that end user experience. Yeah.

So when I was at one medical, one of the first features I started working on was our video visits platform. So it was being able to do a one on one virtual call which You and your doctor, and I built that prototype using Quartz composer and kind of started that from the initial prototype of like how we could even wire the AV and really test these cases. So a lot of what I’ve been interested in is design prototyping in a lot of ways.

And prior to one medical, I was director of mobile design at a company called Black Pixel that was really focused on Like iOS and Mac apps doing our own products, but then also doing a lot of client services as well. And what brought me to web flow was after I left one Medical, I think. It’s really great when you leave a place that you feel like you could be there for another 4 years, and that’s kind of how I felt at one medical and was just looking for something a little bit different.

So I took a mini sabbatical, probably about 2 months off trying to figure out what’s next.

And my original idea was considering to do a startup around like prototyping on the iPad, because I think that was the year when Swift UI came out and I thought to myself, it’d be really cool to Build tools for people to build, and really build layout, and whether it was like a full-on developer tool or prototyping tool. That’s what I was exploring, but I think for me, I know how hard startups are and the life expectancy of those. So, you know, it’s something that I was continuing to explore lately, but then got connected with web flow. And for those who don’t know, web flows a visual development platform and it’s really focused on websites, blogs, and more dynamic web experiences. And I think the thing that got me really interested in that is this bridge between design and engineering. And it wasn’t just prototyping, but the stuff you build goes straight into production right away.

So you can build your site, publish it, and you know, wire up a domain and you’re done.

And I was just like, wow, you know, I think this is a really interesting space to be able to take the things that I was really excited about, which is like visual programming. And that is naturally just a part of it too. And I was like, OK, this is a company I have to join. Like I think at that time, they were growing and still growing, and I figured, you know what, instead of doing my own thing, I’d love to join forces with a company that’s already doing a good thing.

00:07:02 - Speaker 2: And thinking about the product positioning there. Is the target user or I’m sure you have a lot of diversity of customers now, but when you’re doing this design work, do you think of it as someone who’s coming from maybe a simpler tool, I don’t know, Squarespace comes to mind, and they want to upgrade and do something that’s more powerful and gives them more control over the CSS more capabilities, or is it actually the other way around, which is someone who’s been hand coding their HTML and they go, you know, this is a little bit tedious, and I’d like a visual tool that augments my ability to do that.

00:07:35 - Speaker 1: Yeah, oh man, that’s such a good question, and I think it’s something we’re talking about a lot.

And the thing that I know for sure is, you know, our end user and who we’re targeting are designers, and not to get into this existential crisis, but it’s like, what is a designer, right? There’s so many different flavors of what a designer can do. I would say this predates my time at web flow, but I would say like when the early product was being developed. I think it was really focused on the web designer and the web designer that really knew, really familiar with HTML and CSS, you know, that material of code to create and build these sites, but I think as Our customer base has grown, you are kind of seeing people who maybe their mental models are more from the Squarespace or using a tool like FigMA or Adobe XD to really understand design, so they’re kind of bringing those mental models in. So I think the thing that I think about a lot is What are the different types of personas of designers that we’re looking to serve, and that could be many different levels, you know, could be designers who know code really well or they want to use no code tools so they don’t have to know code.

00:08:52 - Speaker 2: If I can make a comparison to Hiokku, this was a similar, I think dilemma we had, you might say in our user base, and of course a good product can be used by different types of people and it works to try to understand the different segments you’re trying to support.

Yeah, Hiroku both had developers who were people that maybe would have struggled a bit to get like a production deployment of. on rails and a SQL database and so on, and we made that much more possible for them to do, but it also had the other way around, which was professional developers that completely knew how to buy a server, install Linux on it, put it in a co-location facility or set up a VPS or whatever, do all that server and operation stuff.

They said, I don’t want to bother with that. I would rather outsource. To you, it’s undifferentiated work. I just want to build my app, but we have people that are sort of coming from two very different skill directions that land on kind of needing the same solution, but as you said, like their mental models of how everything works is going to be wildly different in that, hence the huge design challenge to make a single product that works for both of them.

00:09:57 - Speaker 1: Yeah, it’s such a tough challenge because what I ask myself is, who do you serve in that instance? And for me, the answer should be both approachable software for these sort of tools. is you want to be able to abstract away the complexity, but you also want to be able to pop the hood open, if you will, right? So if someone wants to use code and make things more extensible, there’s a lot of challenges if we cap that from people and they don’t have access to it and to what you mentioned with Hiroku it’s like. Do people go with a different solution, or do you find ways where it can be a little bit more flexible for what people’s needs are? And I think that’s the sweet spot you want to hit and it’s really hard to find, which kind of makes me really excited about this space because it’s not only like a diverse persona, but it’s also the different use cases and how people learn too. So really trying to figure out how you find that place where it meets both of those ends of the spectrum is really challenging.

00:10:57 - Speaker 2: Maybe that’s a good moment to introduce our topic which is designing for creative tools. Now creative tools can include a pretty big gamut from word processors and video editing.

Here we’re talking about maybe the fairly far end of the spectrum on complexity, which is dynamic modeling tools, web design, development, but if you think of that spectrum as being on one far end as the pure consumer, very everyday apps, something like a kitchen timer.

Whether maybe things that are in the middle but still closer to that consumer side might be social media, for example, not to say there isn’t a ton of complexity in that, but compared to what you can do with creative tools or what the user can do with creative tools, there’s the variety of possible states essentially that a user can put their document into with anything on this end of the spectrum is vastly greater than some of those everyday apps.

And that creates some pretty big challenges, but also for the right kind of person, and I would count, I think the three of us in that category, those challenges can be very fun and interesting.

00:12:02 - Speaker 1: Yeah, it keeps you on your feet, for sure, and I think the word I keep attributing to this is just dynamic, right? It’s that it’s always changing, it’s always evolving.

And I think what’s most interesting for me in this space is you build a set of capabilities for people and you see what they do with it, right? And that’s different for what you alluded to is that, you know, a lot of my background before was consumer apps or networks and e-commerce and they’re more rigid in the user experience, so it’s more predictable with what people will do.

Like, of course, there’s flows you want to Optimized for, but I think there have been times where I imagine a lot of spaces of people working in creator tools see this a lot, where end users just subvert and find new ways to use your tool and you’re always so surprised by it and I think Rather being worried about what happened to you, embrace that and see where it goes, and I think that’s really interesting.

It’s just kind of like, uh, you know, this whole notion of like, I think Microsoft uses the term citizen developer or you know, end users creating stuff. Now it creates such a unknown journey map for a lot of these users, which I think is personally really cool.

00:13:22 - Speaker 2: Yeah, that rigid design you mentioned in, for example, e-commerce, that’s actually by design, you want a checkout form, for example, the number of forks in that path should be pretty minimal, right? The data is different, where I’m shipping to is different, maybe there’s a few options in there, but you don’t want to choose your own adventure on a checkout form and perhaps the work you did in the medical space was similar that you want something pretty structured, pretty rigid.

Everyone kind of does it more or less the same way with some essentially minor variation is really the complete opposite of a great creative tool.

I think almost by definition is one that your users will use it to make things that you never expected. They like you said, that subversive element.

00:14:08 - Speaker 1: Yeah, and I think that’s why at Webflow, we tend to call things capabilities versus features, and we want to focus on that lens where it’s like, what are we equipping end users being able to do versus like, here’s this feature that will do X or do Y but it’s more like, here’s this capability, here’s this offering. Let’s see what you do with it.

00:14:32 - Speaker 2: I’d be curious to hear if there’s any cases you’ve seen so far of web flows, users and customers doing something interesting, unexpected, even even subversive.

00:14:43 - Speaker 1: Oh man.

00:14:43 - Speaker 3: Have you had any bitcoin miners like we did on Hookku?

00:14:46 - Speaker 1: Not yet, not yet. We’ll see, there’s still time for that.

I’d love to hear the Hiroka use case. There’s two that come to mind for me, and one is a weblow community member created, I think it’s called The Big Bed, and it’s a children’s story that he illustrated. I can’t remember if it was directly about his daughter, but it was this narrative that they created.

So he created an interactive site with web flow that had audio and just this really great immersive experience.

And then there’s another use case where someone in the blood flow community created a game that I used to love playing is he actually recreated some of the intro and functionality of the game Civilization in web flow, and I’m just like, oh my goodness, there’s so many events, so many interactions built this, and you could tell like the people who built this is just, it’s pure passion for learning and just love of creating stuff and like.

When I saw those two things, especially, I’m just like, oh my goodness, like this isn’t just for building like the websites built on Twitter bootstrap where they all kind of look the same. It’s kind of returning this sort of expressive form of the web, which got me really excited because I think in my iOS days, I think at that time the web was becoming a little bit stagnant and less expressive, but kind of seeing these sort of tools come back for people to be expressive on the web, I think it’s really awesome.

00:16:18 - Speaker 2: I think we talked with Wei Weixu a bit about kind of personalization in our online spaces, and I think I expressed my love of personal websites and the web and HTML remains and has only gotten better with years, even if there’s fewer sort of GeoCity style places for people that easily have their own spaces, what you can express through a personal site is greater than ever before, but that’s balanced out or maybe just drowned out would be the way to put it by.

Yeah, maybe social media profiles or even just sites that are designed to be a profile for you, and it’s nice cause you upload a picture and you type in a bio and you click on three things you like and it gives you a nice looking page, but yeah, it lacks that personality, that expressiveness, and certainly that handmade element, but that’s still live on the web in terms of what you can do with HTML.

You have to get away a little bit from the template driven world of say a Squarespace and a little bit closer to the metal if we want to call it that, and I think you know hand coded HTML is a great way to go, but not to drop in too many metause references here, but we also talked with Maggie Appleton about visual programming, which I think David discussing that episode is part of how you and I got talking and Talks about, well, look, we don’t want to replace code, but maybe we want to layer new kinds of visualization tools on top of it.

I think the web is really, really perfect potentially for that, and you see a small version of that and say the developer tools, the Chrome slash fire bug derived developer tools, but there’s so much more we could do with that, I think.

00:17:53 - Speaker 1: Yeah, for me, the word I keep coming back to is expression, right? And the expression of how you create, and I think.

I don’t like using like web 12 and 3 just because I think it’s just like a continuous evolution, but for the sake, let’s say web 2’s a lot of social media, a lot of feeds, and that’s where conversation happened, right? And I think for me, I grew up in the earlier days of the internet having a Geo City site using Dreamweaver to build my personal websites.

I use this analogy of like visiting people’s homes and you would go to people’s home pages to be able to see that expression and now things are in social graphs, right? And there’s still a lot of where web 3 might move and I still think it’s.

Really early, but through all this, I think there’s a lot of this interest to kind of bring personal expression back and bring back personal websites, blogs.

RSS is a technology that I continue to use and love today, and I think there’s like a resurgence to this because people want expression in the content, you know, whether it’s personal expression or that of the people they interact with.

00:19:02 - Speaker 3: Yeah, definitely hitting on some recurrent themes from the podcast here, just kind of give another angle on it.

This idea of a personalized space is so important for professionals because almost by definition, you’re spending all of your waking, working time in it.

And if you have no agency over how it works and how it looks and how it feels, that’s very demoralizing and discouraging. So for that reason alone, it’s very important.

There’s other angle of like being able to do things that the creator of the tool didn’t specifically envision. In some ways, that’s the very definition of a creative professional, as someone who’s doing something novel, who’s doing these.

Combinations because if there was no novelty for it, it’d be more like turning a crank and why pay really high professional labor rates for doing that, right? And so the tool has to facilitate it.

You have to make this leap of, we’re going to provide these primitives and building blocks and people are going to reassemble them into games or whatever, you know, civilization, who knows, right? You have to be able to support that.

00:19:56 - Speaker 2: So going a layer deeper on what it means to design creative tools and design for creators, including designers and developers. One of the big topics in design is always mental models, and I’d be really curious to hear about the mental models you’re using for web flow, David, maybe Mark, you could talk to Muse a little bit or maybe we have some other examples from our collective experience, but maybe to start, Mark, could you define mental model just to make sure we’re all on the same page?

00:20:26 - Speaker 3: Yeah, so a mental model is sort of the platonic forms you’re dealing with in the domain. It’s the nouns and the verbs and how they interact, you know, what is the way that you think about the space? What are the primitives, how do you build on top of them? How do you combine them? So, for example, with a desktop OS you have things like files, folders, windows, things like that, mouse, and so forth.

00:20:51 - Speaker 2: One trick I’ve always liked for coming to grips with the mental model of some system that I’m designing is to write a glossary, essentially a list of all your vocabulary, and these are things that you’re surfacing to your user.

So for example, I think I might have first tried this for the Hiroku add-on system.

And in writing that glossary, I realized first of all we had way too many things. There was like 20 different things in there we were expecting people to keep track of, many of which were like kind of a relatively new concepts and certainly pretty abstract ones. So we’re looking for ways to kind of reduce those.

Second, I found that sometimes we would use two words to mean basically the same thing, and that’s confusing. But then third, it kind of forces me at least to ask, does each one of these serve a really good purpose? Is a person going to have a clear understanding of what this item is? They know this term refers to that, and they can either connect it to something else they already knew before they started kind of using the product or reading your documentation or whatever, or for the very few you want to offer as new, is it worth your while to introduce this new term, this new concept.

And of course one of the tricks, I think you Kind of illustrated pretty well there, Mark, is to take physical world metaphors. So your desktop is on your computer as a literal metaphor to your top of your desk. Files and folders are also metaphors, although even there you see where it’s an imperfect. fit.

My mom actually has commented on this a number of times, which is she’s worked with paper files and folders for a long time and from her perspective, a file folder is one kind of thing and it’s one of those folding manila envelopes that you can put pieces of paper and documents into. So she thinks that you should call files documents and you should call folders files, and now of course, we’re set now, but it’s a good example of where users have preexisting expectations, you’re trying to borrow these metaphors, but they don’t necessarily map perfectly, but you get some leverage there because you’re not asking someone to learn a whole bunch of new words that don’t map to anything they know from any other domain.

00:22:57 - Speaker 3: Yeah, and my experience has been that the product architecture, which is the phrase we sometimes give to coming up with and naming these mental models, is incredibly important. If you get this even a little bit wrong, it’s gonna make everything much harder down the road, and in particular for some people to be able to span the full range of use cases from very simple to very complex, and to be able to do unanticipated recombinations, they have to be really solid.

00:23:24 - Speaker 2: So what kind of mental models do you make use of in web flow, David?

00:23:30 - Speaker 1: Yeah, I think a challenge in a lot of creator tools is to decide how opinionated you should be. And what I mean by that is when you become opinionated, there’s kind of a trade-off with that, right? You can kind of really help guide people in how they build certain concepts, or do you be more open ended and you give people the flexibility to explore that. And I think the thing that’s tricky with that is The question I ask myself is what mental models do people come in with using web flow, so someone who is a front end developer, the way they approach using web flow is going to be dramatically different than someone who may use FIMA. And I think the thing that’s hard is In design, there’s a lot of these things that are very similar, but not necessarily identical, right? So, for example, in Xcode, the auto layout engine is a lot different than auto layout in Figma, but yet, these are things that people associate with how to approach using it.

So I think When we’re thinking about the mental models of web flow, I think a lot of things that we’re asking ourselves is like, what do people come in expecting, right? So, someone who’s coming in and using layout may not think of things as divs, right? And also think about things like nesting and parent-child relationships. They may be thinking of it as an infinite canvas that they drag and move freeform. And unless you kind of set position to absolute, there’s really no way of doing that in a way that produces good code and That can be frustrating for users if you’re coming in not knowing box model and some of these web design practices. So I think a lot of things we’re thinking about like, how do we become more opinionated in our own product without like biasing them on what to build, right? So for example, a lot of this can come from onboarding new users and teaching them like, hey, these are the core aspects of web design that’s going to be really important for you. To know, you already know this, great, you can skip it, right? But if you don’t know, it’s going to be really helpful for people to really understand those mental models, because I think for me, really being true to the material and the material in this case being like HTML and CSS I think. I personally wouldn’t want to abstract it so far away where you’re creating some like proprietary markup or something, right? You really want to make sure that you can get as close to the native output as much as possible, but abstracting how people build with. That I think is key.

00:26:08 - Speaker 2: It also occurs to me that some of the mental models are things about what do my users come in expecting a front end developer versus a designer, for example, but also, as you said, the material, you just inherit a bunch of things that are just true whether or not you want them to be, and certainly the web and HTML and CSS are full of plenty of quirks and history and that sort of thing, and so something about how the grid system works or something about how Flexbox works or what have you, you’re just gonna inherit that. Some of that may be good because there’s good mental models, some of it may be more like baggage or gets in your way, and so presumably, maybe I’m realizing now I’m just kind of resting what she said, but just for my own understanding, you’re trying to figure out which things are abstractions you really want to surface to your users because they’re useful, they’re powerful, they’re compre. Sensible, they fit well with the visual tool you’re creating and which are weird quirks of the web that don’t really help you to know and I don’t need to know about, I don’t know what JavaScript mification, it’s just we do that quietly behind the scenes and kind of tuck it away and you don’t need to really like have a concept for that in your mind to get value from the tool.

00:27:18 - Speaker 1: Yeah, and I think this is why I like the jobs to be done framework where you’re kind of focusing on that outcome that a customer wants, right? And I think for us, when we think about it. There’s like multiple ways to build a layout, right? But if we’re kind of looking at some of the best practices of like, here are the things that people typically try to build and it solves like 80% of those use cases, like how do we surface more of that because the likelihood of what people want to build with that is higher, right? And there’s always going to be this option B, C, D, and E that people can explore. But when you give them A through E all at once. It’s this paradox of choice, right? So if I drop a div and then you’re asking like, OK, you can use display, flex box or grid, someone who doesn’t know what the difference is three are, they probably just pick one, right? And then really just trial by error with that.

But if we can be more opinionated about some of these things, I think it helps reduce the cognitive load of decisions that people have to make. So can we streamline people to what we think is the best decision while giving them that option to subvert it or explore other paths to, as opposed to give them all the divergent paths at once.

00:28:38 - Speaker 2: Now here we’ve spoken a little bit about sort of things within the page ad, a flex box, and that sort of thing, but actually the web has a huge number of abstractions or that mental model glossary for the web would include pages, include URLs, would include links. I think all of those are pretty well understood even by non-creators, which is actually pretty great and so you can just rely on using those things, I assume, even something like a website, what actually is a website. Where are the edges of it that may or may not be fully understood by the average person, they may not fully grasp when they sort of leave Facebook and go to another site, but certainly I think for your target audience, those things are probably really well understood and you can totally lean on that, is that right to guess.

00:29:24 - Speaker 1: Yeah, absolutely. And I think that’s the beauty of building for the web is there’s such a rich taxonomy and a lot of like standards already set on that, that even if people aren’t familiar with it, it’s not like they’re learning just web flows mental model, right? They’re learning the mental models of like building a website and links, buttons, and even in layout, you know, thinking about sections and Some other elements that are offered to people. So I think that’s the thing that’s been helpful for us is that it’s like, as you’re learning web flow, you’re learning the web mental model as well.

00:30:01 - Speaker 2: Can you give us an example of something, you know, we’ve talked about this kind of visualization element, which in many cases I think a visualization tool is something that doesn’t really add a new mental model, it just helps you better, well, literally see what it is that, yeah, understand, for example, margins and padding. It sort of shows you how those layout. Is there some major new abstraction that web flow gives you that’s sort of a new capability that’s added to your user’s tool kit, but it is not something that comes from the web, but is something you created as part of your universe of mental models.

00:30:36 - Speaker 1: Yeah, it’s not something we originally created, but maybe I’ll throw this example out here because we just had our no code conference. We announced a capability that we call logic.

And now when you have the UI side of things, and you have logic, and you have data with our CMS offering, it’s essentially a 1 to 1 connection to model view controller, right? And I think as we start exploring this is like, The question I’m asking is, do we teach everyone the fundamentals of model view controller and ask them to build it the exact same way? Are there ways to leverage those ways of doing things in new ways? And I think for us, there’s a lot to be able to explore there, even with our CMS, right? It’s like we’re letting people buying data to layout and building collections with them not necessarily knowing. What a collection is and how you would build that in code, right? So I think it’s not necessarily like inventing new definitions of things, but maybe new ways of manipulating and using it. And I think for us now that we have data, UI and logic, being able to manipulate, layout or data based on events, there’s a lot for us to really explore on how end users interact with that.

00:32:00 - Speaker 3: This brings us to another interesting aspect of designing for creative tools, which is the social aspect.

So increasingly designing tools and then using the design tools takes place across many people, and there’s interesting social dynamics there.

So especially if you look at a domain like the web, which is very multidimensional, like you can use absolute positioning or box model or grid or whatever, you have to come to some common language and understanding as a team, and sometimes you just gotta kind of pick one or be on the same page or at least call things the same thing. So an important job of design tools I think is helping teams reach that agreement. I can give you two examples. One is Hiroku, where there’s basically a lot of ways you can design and deploy an app, and Hirokoku picked one, and there were good reasons why Hiokku picked that way, and we said basically you should do this, like you should use Git and you should not write to the local file system and so on and so forth, you should use environment variables and Yes, those were good choices to make in of themselves, but they also basically forced everyone onto the same path, which was itself another example that’s maybe more analogous to web flow is Ruby on Rails, where basically it need people to pick a way to do NBC like, put this here, put this here, call this that, use this convention for converting between lower case and uppercase, and just do it, it’ll be fine. And there’s actually a huge service and just picking these defaults and having these guard rails in place.

00:33:21 - Speaker 1: Yeah, it’s really interesting you bring that up, Mark, because I think one of the things we’re really thinking about and that’s really top of my mind is how does collaboration work in web design and in a tool like web flow, and I can give some examples of that is one, let’s say you have an end user creating their site, but perhaps they find inspiration from our showcase and they pick a template to use, right? But that template is built Flexbox only. And let’s say they use CSS grid or something else for their site, they drop it in and just boom, the whole layout just collapses, right? So I think for us, that’s something to really think about.

It’s just like, again, just how do users understand like how the material’s created, right? And I don’t know if it’s something where we’re like, want everyone to use flash. Xbox only and get rid of the other stuff because there’s implications with that.

But how do we kind of nullify and make sure that when people are using other resources that people build, like in a community aspect, that there’s clarity, there’s good documentation, and there’s some good best practices around that.

And I think the other thing.

That you touched on, Mark, that I think is really interesting is, how do you think about like design architecture as a team, right? And if you have multiple designers working in web flow on a larger team, it’s like, how do you make these agreements and how do you declare these things that’s like, hey, as we’re working, this is our approach to Naming our CSS architecture or this is kind of how we want to approach building pages and having that.

I think a lot of that lives off platform right now today. Some of the things that we’re thinking about is just like how do we enable teams to work better in web flow, and I think we’re still doing a lot of research on it and trying to figure out like what that best case is.

00:35:13 - Speaker 3: Yeah, it seems inevitable that all design tools are going to become collaborative and social, at least have the capability to do things as a group, and it’s interesting that we’re sort of working our way up. So the first thing was like Google Docs, which is text, and then you add the whole office suite, and now we’re working on complex tools like Figma and web flow, and I think eventually we’ll get to video that’s probably the hardest one to do collaboratively because of bandwidth, but we’re gonna get there. It’ll be interesting to see how that all plays out.

00:35:40 - Speaker 1: Yeah, I’m starting to see a lot of startups working on collaborative video too, so I think definitely a really gnarly problem, but I think it’s a sign, like you said, it’s inevitable that everyone’s shifting to collaboration in as real time as possible too.

00:35:55 - Speaker 2: A bit of a tangent, but it’s certainly a reminder of something I feel like comes up on Twitter from time to time, which is, it does seem odd that you basically have all of these startups that are reimplementing collaboration, typically inspired by Google Docs or some combination of Google Docs and GitHub. And in fact, given that we want every single tool to be collaborative, couldn’t you imagine that as an element of the operating system or the file system? And instead, every single startup that does this has their own big engineering team and like needs to build it all, but one can’t help but to envision that future operating system where by default that is part of anything you build.

00:36:36 - Speaker 1: I think about that a lot about annotations too. Couldn’t annotations and commenting be more native across the operating system based on the objects that you’re working with, but like you said, a lot of these tools, it’s part of this walled garden, right? And everyone’s building their own version of it and there’s got to be a way where How do you take that a layer deeper, like either in the operating system or being more open source about it, but it is interesting, like everyone’s kind of building these same like set of features, and I always think about annotations and commenting as ones that I would love something like that on the OS level.

00:37:15 - Speaker 3: Yeah, I actually had the aspiration for such a thing existing.

I think it could be an OS service or a web service sort of like S3, and I repeatedly hear people ask for this, and I think there are two big hurdles.

One is there’s an expertise hurdle, which I think is not obvious until you try to do it, but it’s very, very hard to build such a system, and I think it’s basically impossible to do without having a motivating example product.

So I think it’s most likely this gets extracted out from either a company or someone who has experience with the domain of trying to build such a system.

And I think there’s an important path dependence thing where yes, everyone wants the operating system to support this, but, you know, it’d be very convenient if the operating system was the one that already ran, you know, my program, right? I don’t want to have to rewrite all my stuff or change my business or lose my business for such an operating system. So there’s a first mover problem. So, basically, I’m looking for the bookstore that wants to get into the business of web services in this space, and I think they’re out there somewhere. If you are, remember, we’re looking for such people, so contact us please.

00:38:16 - Speaker 2: David, what you mentioned earlier about the dropping a Flexbox component into a grid layout also makes me think of another thread here, which is the kind of componentization elements of things.

Yeah, I think a product with a good mental model, a good set of abstractions, the elements of it can be combined together in a lot of different ways, again, ways the creator didn’t originally expect, but you take that even a step further, which is not just that I, the person using the tool within my document, can Do interesting and different things, but then you can go from there to, as you said, the collaboration, we’re on a team and we’re working together on something like a website or a document, but then the furthest step is to go from there to, you have these components that you can plug together where maybe the I don’t even know the person that made this calendar widget that I’m plugging in.

But I feel like this has been a dream for a long time, and maybe one that there’s been many attempts, I think OpenDoc is kind of a famous one there, maybe ActiveX kind of Microsoft had a couple of different iterations of object embedding and yeah, I’m curious if you have a take on that path of computing history attempts.

00:39:28 - Speaker 1: Yeah, I can speak about the promise of OpenDoc cause candidly speaking, I never really had a chance to play around with it and. Implemented, but I think this idea of component software that is reusable and adds value for people immediately, I think it’s still a lot of ways the dream, right? And when we think about community plug in the ecosystems, it’s an aspiration I want to continue to pushing now, there’s a lot of trade-offs in practice because I think for me. Someone who used like cocoa pods a lot, right? There was something around like how open are these plug-in ecosystems, and I think that’s a tough tradeoff for any platform that’s being built, but I think for me with OpenDoc, I kind of felt like web objects was a lot of this too, in this world where you now have people who can build components. That serve other people and really being able to open up like how work is done, right, whether within your company or externally, but I think OpenDoc is just one of those still kind of waiting for that promise to be fulfilled and then I think that vision is so inspiring.

00:40:40 - Speaker 3: I think this is a super interesting frontier as well, and I think it’s like understudied and under theorized. I think people don’t appreciate how complex it is, especially when these plug-ins are turned complete and they have access to compute and data, you know, that is your compute and your data, they can do wild stuff and there’s sort of a this problem in the engineering world of libraries.

And I think we’re still in the very early days of how we think about libraries, which is basically we download a bunch of random code from the internet and run at our computers and who knows, you know, a lot of it’s probably like mining Bitcoin or, you know, stealing my keys.

It’s a complete mess. And I think it requires a very serious design and engineering effort. As well as again this respect of the path dependence problem where you need a way to bootstrap the ecosystem and to incentivize the ecosystem. So I’m so optimistic. I just think it’s a very hard problem.

00:41:27 - Speaker 1: Yeah, I think in a lot of ways, you’re right, it’s still so early in the way that we’re doing it.

And I think one of the things, like let’s take no code, for example, and use this open doc analogies. I’ve always described as no code being like the 3D printer for building on the web. So what it does is really creates repetition and reusability in a great way, right? Now, no code tools, there’s always going to be this threshold where if you’re doing something sophisticated, you might need to code it, right? So it’s never this like one or the other, but I think it kind of evolves into that and I see that with component software too, in the sense that it’s like, I think about this all the time. If I’m building an app, I’m like, why do I always have to build the same authentication flows, right? Or kind of build these things that people predict. It’s a very rigid solution intentionally, like, you know, e-commerce and check out some of these things like why do these things have to be constantly unique, right? There’s clear interactions of what people expect in those. And how do you do those things at scale. So then the things that need to be unique for your business or your product, you can really focus on that. And I think that’s where, again, I think this whole concept of like component software, I still very much believe in it. It’s a very ambitious vision and I think in a lot of ways still pretty early.

00:42:54 - Speaker 2: By the way, it probably is worth defining no code briefly for the audience. Again, we suspect a lot of folks may have at a minimum part of it, but given that you put on a conference with that name, it seems like you might be an authority to speak to what you think that word means, you know, what the category is, what the movement is, etc.

00:43:10 - Speaker 1: Yeah, absolutely. With like what it’s not, right, which is not the absence of code or any existence of that. And it’s really more of like the primitive that you build with.

So instead of building, using code in a command line interface or a text editor, it’s through like visual abstractions.

So there’s no code and low code.

But yeah, it is something funny where It’s not even in my opinion, combating with code, right? It’s just kind of the existence of these two approaches in a lot of ways. And I think the companies that are going to excel at this is they’re probably going to use a combination of both, right, depending on some of the different use cases, but yeah, no code is kind of starting with not needing to learn how to code and you’re kind of focused on like the visual abstractions of creating with code.

00:44:05 - Speaker 2: My sense is that it’s often non-programmers doing automation and particularly connecting services together, so I think of the if this, then that and Zapier as being kind of a starting place, very simple, just, I don’t know, we use a Zapier integration for someone tweets about X, then put it in the Slack channel, for example, or you get an email with a PDF, stick it in this Dropbox. Those kinds of basic automations and that certainly I’m sure professional software engineers sometimes use such service just because it’s easier, less work to maintain or whatever than using their full on development stack, but I think very often it’s a business person or a designer or some other person that the writing a, I don’t know what a shell script to do the same thing would probably be out of reach for them.

00:44:53 - Speaker 1: Yeah, it makes me think about and name any use case, right, where before you’d have to like ask an engineer to run a rake task to be able to get all these things done.

Now you’re empowering people, like you said, maybe they’re on the business side of things or not on the engineering and product side to be able to create their own automations in that way. And the question I always ask myself is like, this is the stuff you want to democratize even within your own company, right? It may not be the stuff like an engineer even wants to work on. So it’s like, again, it’s not contrary to how you do it, it’s just kind of really thinking about some of these use cases. I don’t know, do you all remember Yahoo pipes? That was another one that I think about with the automations too.

00:45:41 - Speaker 2: Yeah, I had to do some serious digging around in the web archives to find a screenshot of that because I wanted to reference it for the inco switch end user programming article that we did.

But yeah, I think of that as one of the original put together flow-based programming with, I guess the emerging idea of web services or the fact that URL over here as a web report and another API over here is where I can feed in my travel plans and maybe I can connect all those together with well pipes. And maybe it was before its time, I’m not sure, but the concept there was so simple and maybe coming back to our mental models point, you know, you even look at a screenshot, you instantly understand what this is doing and what it might be capable of.

Now another thing that I think about when thinking of a tool like what you’re making with web flow, I think Kokku had some of this as well, and I think any kind of creative tool always has this, you know, you talk about your ideal is the low floor, high ceiling, that’s the idea, it’s relatively easy to get started with, but you don’t get constrained later on.

There’s also these powerful cases, but I do think there are cases where you do want to say, OK, you’re asking for something that actually is more kind of off the edge of what we actually want to offer with the tool.

Certainly when we ran this Hiroku, someone would come in. I want to tune all these kernel parameters, whatever, we’d say, well, look, this actually isn’t the right platform for you because that level of control and customization is exactly what we’re trying to save you from. We’ve just made good choices there that will work pretty well for most people, and you can just remove thinking about all that kind of stuff from your head.

And an example, you know, that I like to cite a lot for end user programming is Flash, which I think did a really great job of bringing animators and maybe what we would now call motion designers into something that was essentially kind of a programming environment, but it’s been speculated on some of these uh flash dyed postmortems that came along a couple of years ago that one of the Issues that it faced was in those early days, it was so accessible to animators, then people started making games, those games would get pretty complicated, they would need all these things that just professional software engineers need, want, expect in terms of data layer, caching. Complexity of the language, all that kind of stuff, ability to add libraries and dependencies, and eventually it became such a powerful programming tool that it actually lost that ease and that accessibility. Essentially the floor kind of crept up as they pushed up the ceiling. So I also think in designing a particular tool, it’s very reasonable to decide our spectrum of use. cases, you know, there’s some that’s going to be too trivial or too, you know, we don’t want to make things so easy, you know, we push you out to some more beginner tool, but there’s also a ceiling somewhere where we say, look, you actually reached the limit of what this tool is for. We’re not designing it for you. You should go use this over here that’s more powerful but also has, you know, other trade-offs.

00:48:38 - Speaker 3: Furthermore, I think there are different ways to do this. So I think the ideal way, again, if you have the right mental model and product architecture is to have basically a nested mental model, a nested architecture where you can peel back layers and get at the granular abstractions within.

There’s all kinds of examples on Hooku. I think we did do a pretty good job with this. If you get push an app to compile and deploy it, it just basically picks how I think it should compile based on what the app looks like.

But if you want, you can swap in your own compilation step and say, here’s the script that I want to compile this app, but critically, both the Hiokku default and that. use the same interface. They’re totally interchangeable.

It’s like basically peeling off that one layer and saying I want to insert something different into this interface. It’s not saying, oh well, you know, Her only deploys Ruby. I gotta go do my whole own thing on AWS from scratch, right? You get to granually pick apart pieces and there are all kinds of examples of that.

In contrast, sometimes I see these programming tools that are like code generators where there’s a super complicated problem and you invoke the code generator and it spits out 100 files. And as long as you don’t need to do anything different, you’re fine, but as soon as you need to do something different, you’re completely out of luck. It’s like you’re often hand editing these 100 different files. So I think the extent that you can create a system where you can peel back these individual abstractions while still enjoying the stack overall, that’s great.

00:49:54 - Speaker 1: Yeah, and it makes me think about, I’ll give a small example.

So there’s this note taking tool I love called Obsidian, and the thing I love about Obsidian is you use your local markdown files, right? So. If Obsidian ever gets to a point where it’s not scaling for me, which I think it serves my use case, well, you still kind of have the native markdown files and you’re not kind of stuck in that application layer, right? And I think great applications will figure out ways to be more of a facilitator than controller on that, you know, and I think for some like web flow, we think about, OK, we no longer are meeting the threshold of what like a certain customer wants, they can still export their code. But are there other things we can kind of build to make that interoperability a little bit easier too. So I think that’s the trick is like being in an application that can be great at facilitating some of these things. So if such things do evolve too, that you’re not kind of locked into that, but I think what you said, Mark is spot on.

00:50:57 - Speaker 2: Yes, I guess in the ideal world you design your tools so that.

You start with a basic set of primitives, abstractions, mental model glossary that hopefully someone can understand and do something useful with when they need a little more power in some particular areas, that’s where they, as you said, mark, peel it back or I think David you put it as kind of popping the hood, and you can go down one layer at least for that spot, but you’re not completely off in some new world, you’re still within the kind of universe of abstractions that all fits together.

And then there’s a final step, which might be what you referenced there David, which is where you actually do get to the end of what the tool can do for you, but hopefully now it’s not, now I’m really screwed and I have to just kind of recreate everything from scratch in some new environment, but rather you can, I think it’s React Native uses this term. Eject, where you essentially can say I want to take my project out of the React Native world to just make it a standard X code or Android Studio project, and there’s no going back once you eject or no easy going back, but that’s your out, right?

00:52:05 - Speaker 1: Interesting choice of words for React Native.

00:52:10 - Speaker 3: Yeah, that’s actually the kind of project that I was thinking of in my previous example where if you have to eject in that case, I think it’s pretty bad. I mean, you can still run.

Another example of ejection would actually be with deploying apps with Hiokku. If you have a standard app, you can deploy to Hiroku, but you can also take that standard, like Ruby on Rails app, for example, and deploy it somewhere else, sort of an injection in a sense.

Hm. This is a very important concept, by the way. Another way I think about this would be as an efficient frontier where the axes are difficulty slash complexity and the other axis is power, and what you want is you want a smooth trade off on those where you can always add a little bit more complexity to get a little bit more power. If you need it. And so if you need a little bit more power, you never have to undergo a huge complexity jump, like migrating your app to a whole different platform. For example, there’s little changes you can make along the way. And furthermore, you want that frontier pushed out as far as possible, so that the minimal amount of complexity is needed for the given amount of power.

00:53:01 - Speaker 1: I think complexity gets a bad rap too, because I think a lot of times people think complexity is the opposite of simple and everyone loves simple because simple is elegant, so then complexity becomes a sort of like villainous thing, right? And I think there are times where we do need to embrace complexity, but how do you make it approachable, right? And I think that is the thing to solve, right, is to figure out like when there is a time where complexity is called for, how do you have your creative tools give people the knowledge of how, like again, to peel that layer back or pop the hood open to be able to address such complexity as opposed to avoiding it entirely.

00:53:45 - Speaker 3: And again, I keep coming back to this idea of mental models, often with complexity, you’re dealing with a fundamental reality of the underlying world, and if you ignore it or try to cover it up for long enough, you just make it worse, you have to address it. But on the other hand, you don’t want to make that problem any worse than it is by, for example, combining two problems and giving yourself three problems.

00:54:06 - Speaker 2: I’m reminded of the Einstein quote, Everything should be made as simple as possible but no simpler, which is, yeah, the world is complex, it can be messy.

You’re creating a tool for someone to model something about the world or create their own little mini made up world, and they are just going to need to deal with that complexity.

In the web world, that’s something like all the different browsers and all the different devices that someone might browse from and different screen sizes and the difference between interaction on touch versus mouse versus trackpad versus stylus.

Those things all exist and you need to deal with them when you’re creating something and attempt to totally abstract all that away because it sounds too complicated. It may impair the ability of the creator to make something that’s really good.

00:54:52 - Speaker 1: Yeah, because abstractions still derived from the original thing, right? And I love the idea of really focusing on where you address complexity as opposed to neglecting it or putting it everywhere, right? So when you have these complex things to solve, what’s the optimal place to solve it?

00:55:10 - Speaker 2: Yeah, absolutely. Well, I do think we’re in kind of a golden age or the beginning of a golden age for creative tools that includes being more interesting, maybe place for designers to go work on tools for thought and things like that, that the the stodgy old kind of vanilla styles of the office suites of the past and so forth are giving way to more stylish and interesting and opinionated tools for thought and developer tools and designer tools. I’d be curious to hear from both of you looking forward to kind of the future, you know, if we could fast forward that trend 3 or 5 years, how does creative tools look different in the near future?

00:55:50 - Speaker 1: I think you’re gonna see a lot more participation in it, and it’s almost like.

The consumerization of creator tools, which I think is exciting.

And the reason I’m excited about it is I believe some of the people with the best ideas and things that can be life changing and can really change the world, probably don’t know how to code. They might not know how to design. So being able to give a platform for people to explore and express, kind of gives the continuation of such idea to manifest in other ways. Now, it may not be that person who ends up creating it, but maybe it sparks an idea somewhere else. So I’m always like a big fan of participation in anything because I think for me, honestly, if it wasn’t for visual programming tools like Hypercard and Quartz Composer, I may not have gotten into an interest in Building software and if I went the conventional route, I probably would have failed. So I think for me, that’s what I’m excited about is that like, this whole notion of like end user programming and it being more accessible, just for people to play and explore is pretty exciting for me.

00:57:03 - Speaker 2: It’s funny, I’m obviously a huge proponent of end user programming and more people learning how to grasp the power of the dynamic medium that is computers, not just as users, but as creators of software.

But when you use the word consumerization, Then that actually almost gives me a little bit of an opposite reaction and intellectually, I think I agree with you that more participation, more accessibility is better, but I guess as a crafts person and I love my niche and sometimes kind of complicated powerful tools, then what consumerization brings to mind for me, I don’t know, Instagram stories, or for example, you’ve seen this in some of Apple’s creator products like they have for audio editing, you’ve got. Logic Audio, but then you’ve also got GarageBand, which is installed in a reac. It’s pretty simple and easy to use, which is nice, but then in some ways they brought some of that design aesthetic to logic, maybe taken away some of the things that the longtime pro users of that could be described as like a dumbing down. So it’s interesting to reflect on that reaction of myself. I don’t think that’s a good thing. I don’t think I’m proud of it, but I just had that twinge when you said that word.

00:58:12 - Speaker 3: Oh Adam, I got a different phrase for you. What if we called it end user creating as a sort of generalization of end user programming, and this is a road we’re already part of the way down.

So it used to be that even end users couldn’t do something like word processing that was kind of a professional activity you had a typist or whatever. And we’ve since brought the Office suite to end users, and now I think we’re in the process of doing that for richer media, so audio, video, web pages.

Of course, those are things that are kind of on the cusp right now of even a few years ago, it was quite hard for someone to casually do audio editing or video editing, but now you go look on YouTube and there’s these like super, super niche, random people doing super random stuff, but the video quality is like insane because everyone can do video editing now. And I think that kind of progress is going to continue.

00:58:56 - Speaker 1: Yeah, it’s interesting.

I think Adam, even when I said that word, I had a similar reaction too and it just makes me wonder, like, has the term consumer transformed in a way that, you know, needs to evolve a little bit, but I’ll give you an example.

There’s an awesome. iOS app called Universe, which lets you build websites like on your phone. And I think for that, that to me is like the consumerization of a creator tool, right? You’re kind of taking the mental models of what people are used to on their. Smartphone dragging and dropping these swipe gestures, but instead of consuming content, maybe it’s more the consumers are becoming creators, right? So it’s kind of normalizing creators in that way and I think the universe is a great example of that. But just wanted to say when I said that word too, I had a certain mental model that came to mind and I think it’s, yeah, kind of like, maybe it’s more turning consumers and the creators rather with the mental models that they know.

00:59:56 - Speaker 2: Yeah, I love that, and certainly I have my own career to thank for that in a way.

As a kid, I loved video games, I was a consumer of video games, and that led me to think I want to be able to create these for myself, how can I do that? Back in those days that was breaking out your basic prompt and you know, doing some turtle graphics and that sort of thing.

Nowadays, we have quite different tools at our disposal, but having that smooth on ramp and folks have talked about how we in some ways have lost that as computing has gotten more sophisticated, it means, yeah, that same eight year old with an iPad, they’re playing the games and they’re thinking, how can I create these games and they kind of can’t because, you know, basically the whole stack of software creation and design.

Tools lives on a totally different platform and you know, requires professional buy in and is incredibly complicated, but anything that brings us back the other way and puts that creator power into the hands of interested people who, you know, they may just dabble in it and that’s fun and satisfying and they never go further and others may actually find their spark there and their inspiration and they go from there to something more sophisticated.

And both are great. Having that smooth ramp rather than gaps or a wall or a gap, whatever metaphor you want to use on the other side are the quote unquote serious professionals, and you have to do some kind of ritual to prove your worth to be part of them, but in fact, that if you have that spark, that bug to create and you pursue it, the opportunities are in front of you to take it as far as you wish to take it.

01:01:35 - Speaker 1: It’s interesting you mention that, Adam, because I think what it dawned on me is the same way I got into computers from playing video games and understanding how sprites are created that kind of sparked this curiosity for me to create.

I don’t know if that’s happened for mobile and tablets yet, right, because even though the inspiration is on device to be able to create, it’s off device and maybe this is where Xcode is going to bring a lot more things to.

The iPad and be more mobile centric, but maybe perhaps that’s the reason we’ve seen so much like hyper consumerism on these smartphones is that the tools on device, we may not have had that evolution yet, right, the same way as on my Apple II or name any old computer, it was like on device and you’re creating on the same platform. I don’t know if that’s really happened with mobile, a lot of that still kind of locked in, so it’d be interesting to see how that evolves over the years.

01:02:36 - Speaker 2: Yeah, I think the web has its own version of that. I think in many ways the web is better in the sense that maybe it’s a little more hidden in the menus now, but you can still view source on any web page. You’ve got to have tools inspector and certainly anyone that wants to grab a glitch account or a web flow account can start making simple web apps without a huge amount of ceremony.

Nevertheless, there is still a bit of a gap you jump over and certainly in compared to the original vision for the web, which was something much more read-write, something much more where you kind of right click a page and say edit, and it takes you in, or maybe something like Beaker browser has an interesting vision there or essentially any web page you’re on, you can click a fork button, you get a local copy and you can start editing it.

I like to see things like that because I feel like it helps. Reverse or provides a counterbalance to the tendency that as systems get more complicated, of course they get less accessible, and the tools for creation get further and further away from the regular tools for using.

So hopefully we can say web flow is part of that story as well. Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at MuseAppHQ or via email, hello at museApp.com. You can help us out by leaving a review on Apple Podcasts. David, thanks so much for help making creation on the web, something that’s more accessible.

01:03:59 - Speaker 1: Oh, it’s such a joy. I feel like it’s a life purpose in many ways and yeah, thank you so much for having me on the podcast.