Ep. #10, Environment Protection

Steve Boak: We're calling this episode of Don't Make Me Code "Environment Protection," and we're here with Sean Li, Lead Product Designer at Docker and one of the founders of Kitematic.

Sean Li: Thank you.

Steve: Thanks for being here with us. This is a really exciting conversation for me because we get to talk to a product designer for a company like Docker.

Sean: It's good to be here.

Steve: Kitematic is a real interesting project for a bunch of reasons. I mean, it caught the interest of Docker. It's also proven to be a really novel bit of development environment technology. And so we're curious how it all got started.

Sean: It got started in a university dorm room. I was a student from University of Waterloo in Canada, and the school actually offers a pitch competition. So we had this idea around making development environments easier, and so we pitched the idea and won. That's how we got enough money to get started.

Steve: Wow, and was it at all tied to Docker at that point?

Sean: Docker was actually what we used for the back end. At the time, Docker was version 0.3. And then we're on Hacker News, and we're like, "Oh, this is interesting. It could be super useful technology to do what it wanted to do."

Our idea was essentially like Dropbox for your code.

You get a Dropbox-like icon on your task menu, and then you can put code in it. For example, Jango, it would just run it for you. And you can see it on the browser.

Steve: Oh, nice. And so you have your production environment there, compiling for you and ready to go.

Sean: Yeah. Then, when you added the code, it will sync to the cloud environment and then update right away.

Steve: Nice. That's awesome. It's like a step beyond GitHub. It's not just committing the code; all the CI and everything is built into this one workflow.

Sean: That's like the future plan right at the time, but at first, our MVP was super simple. Just syncing code to a remote server and then seeing the changes.

Steve: From the beginning it was implemented as a desktop application, you said like a Dropbox tray application.

Sean: Yeah, because Dropbox was obviously the inspiration.

Steve: And so why a desktop application?

Sean: At the time, we actually didn't realize the power of desktop application yet. At one point we used to pivot a lot, as startups usually do. And then we're talking to customers, and they start realizing what we're using underneath.

We talk to Canadian Tire, the biggest retailer in Canada. They were looking for something like this, and they're like, "Are you using Docker underneath? We want to use that."

At the time, the product we have is in the cloud, like an off-ramp web browser setup. And then we started thinking of, instead of abstracting away Docker, why don't we embrace it and then make it easier for the customers? Then we start brainstorming ideas, and it came across that having a desktop application is actually super beneficial.

It's like the best platform for developers, because they can import their code super easily. They can open a directory instead of having to upload files in a browser. You can also get a lot of access to their desktop, so once your tool gets more powerful, there's more things that you can do.

It's also super cool because we use Chrome in an electron shell. And we wrote the UI in React, so that means we only have to worry about how the UI runs in that one browser, instead of having to worry about browser compatibilities across the board.

Steve: So it's not something like React-needed, it's just running in a web view in the electron browser.

Sean: And we make it feel as native as possible.

Steve: All right, nice. So it's a true desktop app in many ways, but specifically the UI, it's a web UI.

Sean: A lot of inspiration comes from the Atom Editor by GitHub. They're using the same technology.

Steve: And so this whole bit was open sourced from the beginning?

Sean: We were working on it, and then we open sourced it.

David Dollar: I'm curious what made you decide as you're releasing this tool. Was open source service a strategic decision, or you figured you could get more users by doing that? Or is it just wanting contributions from the community? Could you talk through a little bit of your inspiration behind that?

Sean: I think the biggest part is

if it's something that touches their code, it's really important that the developer trust it by seeing what the code is like.

We're really open about what we do, and also the part on gathering the feedback from the community is super, super helpful. I feel like, in general, open source projects get more feedback from the community.

Steve: With developer tools it seems like a great way to encourage participation. If you've got an open source project, you're inviting people to contribute. Obviously, ur OPCR product for example, it's closed, a SaaS application. So we don't have the le,vel of community support from developers that we would really like in some ways.

Sean: We hired an engineer from Docker because he was a maintainer and he was super passionate about the project. It really helps on that front as well.

Steve: Following from that, you launched this to an open source community, did you have an idea of the kinds of users you were targeting at that point?

Sean: We sort of did from the original product that we had, the Dropbox-for-code product. We had a sign-up list. A lot of these users are more leaning towards willing to use UIs and prefer something simpler. The super active ones are actually consultants that work on multiple projects.

Steve: That's an interesting segment. People there, maintaining a lot of projects, and they're looking for an easy way to keep track of all that stuff. And Kitematic fit that mold.

Sean: Yeah, and Docker being isolated also provides that value.

Steve: That too. Now, if I'm maintaining multiple projects, I can have a Docker environment for each one. The app makes it very easy to move between those. And so specifically the React UI and the GUI, what was it like having that be part of the open source project? Did you get contributions for that as well, or was that entirely internal?

Sean: The React UI helped us in a way, because React is, according to a Google trend, almost on the same trajectory as Docker. So there are a lot of people willing to work on something that's built in React. It was in a way accidental, because when we started, it was a really good technology to use.

Steve: Did you have any designers contributing to the project?

Sean: We do have design-minded people but not professional designers.

Steve: For example, you're a lead product designer at Docker and you, I assume, identify mostly as an engineer, or your background in coding. But there's definitely this hybrid world in the developer tool space.

Sean: Definitely. In the beginning we had hackthons. A lot of participants were trying to add features to Kitematic, then make a huge effort on figuring out the right UI right experience to build there.

By default, I think what I wanted is sort of like designing an OS.

A UI is very extensible, and you want to figure out the right points where you can extend on it. You actually focus on per component and really set an example of how you extend the current UI. When people contribute, it can follow that pattern. And you only had to make slight adjustments to it.

Steve: That seems true of open source projects, generally, too. You want build a broad base that people can build on top of and customize.

Sean: Yeah, but the initial effort has to be really strong. Because otherwise you will get swayed by different opinions. And design by committee isn't always a nice thing.

David: That's pretty interesting because you often times see open source projects that are sort of notorious, especially visually, for bad design or design by committee that ends up being a little too weird. I can think of some Linux desktop managers that I won't name, but Kitematic is actually a beautiful application.

Sean: Thank you.

David: I'm curious how you managed to maintain that, even when you're doing community-driven design.

Sean: I think a big part of it is keeping focus and actually be willing to cut things. In the beginning, Kitematic actually had build, you can actually build an image and then push it. But to keep focus and make things simple before we figure out the next steps is actually making it run content only.

Essentially the focus of Kitematic was helping user install Docker on their computer. You know, in a visual way, it feels very reliable. We solve a lot of underlying issues with VirtualBox in the beginning. And then after that choose a beautiful catalog where you can click one button and run a container. And then that's the experience we were aiming for and focused on. So it's super obvious what to do.

Steve: Did you ever get push-back on those decisions from the community where you had to assert your position strongly there?

Sean: No, I think the community is mainly supportive. What I had to manage was people trying to add too many things that are not focusing on that roadmap currently.

Steve: I think I remember you saying, on the Software Engineering Daily podcast, that you did end up cutting quite a few things from the product after a bit of time. Can you talk more about that? You were trying to clean it up?

Sean: The one thing that was cut was building images from it. Even though it's a super important thing, we decided to delay it because we want to do it right.

Instead of releasing something super early, and then get sidetracked into different things, we want to keep focus until we figure out this is it.

And then release that as a whole. Talking about cutting more, the next version of Kitematic is sort of Docker for Mac. It really solved the core issues that Kitematic was trying to solve in the beginning, to install Docker reliably on people's desktops in a way that it almost feels like it's seamless.

You don't feel like it is running inside VM at all, and that's the goal in the beginning. You install Docker for Mac. When you open the terminal you can type "Docker run" and it just works.

Steve: Had the Docker for Mac project begun before the Kitematic acquisition?

Sean: It was after the acquisition.

Steve: So you were involved with that from the beginning.

Sean: Yeah, I was the founding member of Docker for Mac.

David: So it's interesting to think about this this sort of internal debate. I guess with most design questions it's customizability and configuration, versus limited options, and this carried a beautiful experience. I feel like that happens even more with developer tools.

It seems like Kitematic and Docker for Mac, some of these tools, are definitely trending towards the latter there, where you're removing some of the optionality of Docker to make a better user experience. I think that's really interesting.

Sean: I think the two tools are, in a way, more complimentary. People usually use Kitematic by having the Kitematic UI side-by-side with the terminal. So they like the transparency that they're getting from the Kitematick side, and the sense of it feeling reliable.

"I see things are running. I can check the logs super easy." On the other end, the terminal is how they're used to working before, and that was sort of expected in the beginning. And then you go from there.

You never want to displace a tool that they're already using, one they're so familiar with.

So instead we embraced that but made Kitematic more of a complimentary to the Docker CLI.

Steve: That's really interesting. I've seen similar comparisons made with GitHub and some of their tooling. GitHub has their Mac app and their web UI and stuff like that. And I found myself going to them for things like diffs and comparison, merge states, something where I want to get a lot of text or get some status update.

But for actions, if I want to do merges, everything I'm actually doing with it I'm still doing through the command line. But that's a really interesting comparison, because it sounds like you've made the same distinction. To view things, maybe you go to the UI.But to actually take action?

Sean: GitHub desktop is like a huge inspiration for all these decisions as well.

Steve: I never really heard that distinction made this clearly, that there are certain things that developers are going to continue to want to do through the command line and through terminal. But that we can make the experience better in some ways, like just figuring out whether a container is running or not. That's really nice to have a UI to see that all the time.

That segues into development environments more generally, and what the qualities of a good one are. We've touched on some of those things already, like easy ways to see what the state of things are. What else do you think makes a really good environment?

Sean: I think, like you mentioned, one of the biggest things is transparency into what is actually going on. And I don't think that there are that many prominent developer environments out there.

Before Docker things were very commonly adopted, it still is, but it really depends on if you can set up a really good Vagrant file. So you can do that every time, reliably. I think, with Docker, now it almost works out of the box. Because you can run your images, run your services, and link them together and reproduce them every time the same way. I think having that consistency is super important to a development environment.

Steve: That is a really interesting point because I think something about it makes the timing of this feel very right. That you're able to do things with Docker that maybe you couldn't do in other places like Vagrant.

Sean: I think it came in under the right time, with infrastructure as code, and people are starting to put their configurations in GitHub and iterate on them. Docker and Dockerfile came along and made that super easy. So it's just yeah incredible timing.

David: I would say, personally, that one of the most important things about a development environment is being as close to production as possible, being able to recreate that environment, be really confident that what you do in development is going to work in production.

Definitely Docker hits a lot of those all of those pain points for people. I mean, I used Vagrant before that, and you can definitely build a development environment in that. But as soon as you want to go to production, now you're looking at maybe recreating that whole setup in another tool.

Sean: Totally. The consistency is between production environment and your development environment.

Steve: The timing also feels right because of everything else that made that possible consistent environments. Developers are being able to manage their own infrastructure and spin up cloud hosting for themselves. Now a developer can very easily set up the containerized environments and run them exactly the same way everywhere. It's another reason that the timing of all this feels really good.

Sean: Definitely.

Steve: I am curious to what other distinctions you draw, specifically with Vagrant or other development environments. Are there any counter examples, things you were trying specifically to not do?

Sean: One thing I personally decided to avoid, in the beginning, is IDEs. Because there are a lot of tools out there that developers already use, and IDEs tend to have a harder learning curve in the beginning. It will make new tools much harder to adopt.

I think instead of displacing current tools, it's better to make a tool that is like a companion to what you're already using in the beginning.

Then, eventually, you'll grow that tool and make it more and more powerful. Because you can't displace things all at once. It's like a slower and more smoother process.

Steve: Like you said, there aew already a lot of development environments out there so adding another one to the mix, this feels fresh. It's a different approach, where with another IDE you might not have been able to do a lot of things that you've done.

David: It's really interesting, a real important point. Letting developers continue to use the tools that they already use is so important. We basically ask developers to sit here and customize our tools and go through this never-ending process of improvement, and personalization on all these tools to make ourselves more productive, or whatever. And if now you can't use vi? That throws away so much work that I've done on my own.

Sean: For things like Atom Editor, people have their plugins and everything set up. You obviously don't want to lose it.

Steve: At best, in some ways, you've achieved some of the best possible UX schemes that you can have, because it's this invisible layer. It's just running all the time, and you can very easily pull up a status about your containers, and you don't have to really do anything to achieve that. It's just this helper that sits there and it's there for you if you need it. If you don't need it, you don't even have to know it's there.

Sean: In the toolbox situation, you don't even have to have it open. You can use the command line if you want, and then you can open the Kitematic UI to see what's going on, if you want. You can use other things, for example, our commercial products, to see what's going on. It's all up to what the developer wants to do.

Steve: We've touched on a few points here already, but after the acquisition by Docker, now Kitematic, is it fair to say it's getting rolled into various parts of the Docker ecosystem so all roadmap from here forward is Docker apps?

Sean: Yeah, still some things TBD, where it should fit. If it should fit in Doc for Mac or other products, it's still to be determined.

Steve: And how big is the team that you're on now?

Sean: I was on the Doc for Mac team, now I'm on the Enterprise team. Looping back to what I mentioned about a desktop app being super powerful, we're running into some challenges in how, for example, we have the Universal Control Plane that you set up on a server to manage your cluster.

But how do you point a Docker client to that? The process right now is not as ideal as it should be, but if there is a desktop client, it would be much easier because you can manage certificates and keys.

Steve: I was just thinking that you might run into roadblocks in enterprise environments installing a desktop app on managed systems. Have you seen any challenges with that?

Sean: We're still in the process of exploring this alternative.

David: I've definitely seen that in the past, for myself. It's just like web apps are actually a little bit easier for enterprise customers, just because it's sometimes getting a piece of software installed on the desktop of a Fortune 500 engineer can be pretty challenging.

Steve: I'm just thinking about that now, that I remember at one of my first jobs I had this laptop computer that they gave me. I added some MP3 files to my music folder, and the IT guys sent me a message like "Hey, delete those."

Sean: I think back in Kitematic days, the analogy I wanted to be was, Kitematic is like, more VMWare Fusion on our desktop." And the web management dashboard is kind of like vSphere. People were okay with that, so that's why we went on to explore this route.

Steve: That's a good point. Developers working in environments like that, this is a tool for them, so they should get the access they need to run. The question of what you're planning next feels a little dangerous now that it's part of the Docker Enterprise roadmap. But what have been the most exciting things so far to customers, and what are the areas that you really want to pursue the most?

Sean: What's important for customers right now is integration Docker, the new Docker orchestration. There's a lot of exciting things to do there. Things like node management, you can request the node joining, and people can accept it. How do you deploy and scale an application? All that the flow is figured out on the command line. But in terms of UI and how it maps to help people already work, it's very exciting.

Steve: I really like the analogies that you made of this being a cross between Dropbox and GitHub apps. Also integrating a lot of things people are used to in the command line and figuring out ways to add value through a visual client in the desktop app.

Sean: It requires, part of UX is, researching users and figuring out how they're actually using their command line tools. Adapt to that, and create a product that complements what they are already doing.

David: That's interesting and it touches something we've talked about on a prior episode of this show, where there is more than one kind of developer. Not everybody's the same. Especially as Docker is starting to approach big enterprise and some of these larger clients with the tools you're working on now, you're going to start to see a lot more of raw developers and we have very specialized ops people involved all these different targeted audiences now for this stuff you're doing.

I'm curious, how do you approach that? Do you actually try and identify the sub types of developers and target them differently with different kinds of interfaces, or is it all really just one set of tools that everybody uses?

Sean: It's a tremendous amount of effort to research into those users and, in fact, the design team is growing and user research is becoming a criteria. And we really want to do things right instead of when Docker 1.12 is out, and that's just "Add UI in it. We have the technology, so slap on the UI.

It's more about having the whole product and user process since the beginning. We're trying to take our time and do it right.

Steve: As you already said, rather than just taking the feature set that you're planning to offer and slapping UI on it, back that up with research. Figure out why you need to do this and what people are going to get most out of.

Sean: Building personas for different developers. One thing to really watch out for is the Valley is a small place compared to the rest of the world. If you want to go big and target developers around the world, you don't have to necessarily cater around the developers in the Valley.

Steve: Did you find that a lot of your early traction with Kitematic was Valley people?

Sean: It's actually pretty widespread, and so I look at the metrics. It was dense in California, also pretty well spread around the U.S. and Canada, Europe as well. At one point we actually picked up a Chinese and Japanese community. So just everyone loves simple tools.

Steve: That's another really strong benefit. I've seen even tools that I've worked on, I'm sad to say, we've hit a plateau where, because we were talking to our friends about it and our friends are local, we get this Valley-centric picture of what people want, and that doesn't scale to the level I'm sure you're looking at now.

Sean: I think the persona here is about having open core. You can really extend on it, but if not done right it could actually get complicated. But the rest of the world, maybe they are working, have a day job. And you go there you want to learn something complicated, they just want to pick up something oh this is super cool for what I do. I figure out who that person is is super important for building the right product.

Steve: We all have these grand ambitions. I can't think of a better way to say it than, a lot of times, I've seen teams focusing on the knowledge they've accumulated, building some very technical product, and it's almost like they want to teach people about this stuff. At the end of the day, people don't really care. If you can make their lives easier and make their jobs easier so they can go home earlier or whatever, that's going to win, and it sounds like you've got the right set of priorities there.

Sean: The other thing is, you know Valley is going big. I think one risk of building tools here is technical people may be tempted to build platforms off the bat, and that is super risky. You actually want to find a small but very important problem to solve, and then solve that first. Then slowly expand and build out the platform once you accumulate enough users and traction.

Steve: Not focus on locking people in.

David: The evolution of the Docker tool set, you end up starting off with this really useful tool. And then basically every project that gets any level of success like that comes to the point where they've got this tool, but now the thing that they really need to work on is how we get this thing on to people's computers. Whether it's like installers or other projects, usually that ends up becoming the hardest part, when you start wanting to go wide with a tool.

Sean: I think that's also another reason for being a desktop app, is that it's super easy to adopt. Basically, double click download, and it opens and just installs Docker for you.

Steve: Yeah no SSHing or packages to run.

Sean: That makes it very consumable, almost like a consumer app. I actually got my mom to try it out, and she could start a container on her Mac.

Steve: She could install it.

Sean: I think that's like the future. It's not developers, enterprise people, consumers. It's just easy enough that any user can actually do it. T

Steve: That's where I wanted to go with this. Before that, we have this idea that developers are somehow different than the rest of us, that the rest of people want something different from their tools. They're looking for some complexity.

But no, it's like, click, install. The same simplicity that wins over consumer apps, done right with a dev tool, I think you can get the same benefit.

Sean: It's all about understanding the users. A lot of products were built from technology, and then they think of the user. But if it's actually the other way around, it's more likely to catch on with the users.

Steve: Just figuring out what people's pains are, and that's why research is so important. It's listening to people and figuring out what their big problems are. It's a wonder, it all sounds so simple on the surface. So few companies actually succeed in doing this, though, that's the cool thing, I guess.

Sean: It's hard. Sometimes you need a balance. Apple is like an R&D company, but their product is actually very well catered towards users.

Steve: Getting the simplicity right. This comes with focus. It was something that is a professional tool that your customers are using to get a job done. They need power, they need control. There are some priorities that feel a bit different than a consumer app that's mostly focused on consumption, but if you simplify it in the right ways, and focus just on the functionality that they need, it's like you're giving people this very constrained power.

That's where the simplicity comes from. It's like everything I don't need is gone, but I have exactly the right amount of control that I'm looking for.

Sean: One example is GitHub for desktop, and there's this other awesome tool called Tower For Git. They're very different and also cater towards different kinds of users. My assumption is that GitHub for desktop is really focused on newer Git users who are not so comfortable with the commands, so that they can drive more people into the platform and start using GitHub and eventually learn Git and use it side-by-side with the desktop app.

A product like Git Tower is actually more catered towards professionals who are already using Git. It offers more powerful features like rebase, merging, and merge from upstream, and all that. So very different. All developers, but it's actually different use cases for different settings, so it's super interesting.

Steve: That raises an interesting point, that theoretically GitHub or Docker could have multiple apps with different target audiences. I mean, this might not be the best way to deliver it, but even within the same set of functionality, given your target user, you might want to expose different pieces of functionality and different feature sets that might be intended for, as you said, a beginner user, or an advanced user.

Sean: You have to know that right away. Otherwise, for example, if GitHub for desktop is trying to get newer users, and then they add complicated things like rebase and merge, it could be super dangerous if you didn't do it well. And they'll be super confused what's going on, and then they'll actually might not use the tool. So it's a deliberate choice on these two products.

Steve: It also speaks to how you could find success, theoretically, with either of those as long as you understand who you're designing for and why.

Sean: Yep, totally.

Steve: Thanks again to our guest Sean Li for coming by. Sean, if people want to get in touch with you, how can they do that?

Sean: You can add me on LinkedIn or follow me on twitter at lisean106.