Part 2 of an Interview with Mike & Jesse: WorkFlowy Features Present and Future

FRANK: Is there anything you can tell us about your inspiration for or any epiphany concerning WorkFlowy’s zoom? Would it be an overstatement to say that the ability to zoom into lists is WorkFlowy’s superpower?

JESSE: Zooming is definitely Workflowy’s superpower.

I tried a bunch of outliners before starting to work on it, and they all had the same problem: If you start a huge project in it, that has many big sub projects, which have many significant sub sub projects of their own, you quickly get to a point where the page feels overwhelming. In most, you can’t zoom, so you can’t infinitely keep drilling down as something gets more complex, or as some small part of a bigger project explodes into a big project of its own. Those where you can zoom, it is usually clunky and unintuitive, so you don’t do much and it is a hassle.

And that is what I was after. I am a bit scatterbrained, so I like to write down every little step of what I’m doing. So my documents tend to get super big and unwieldy really quickly, and I just knew that I needed to be able to zoom in and treat any part of my bigger document like its own little document.

MIKE: I do think the particular way WorkFlowy handles zooming is a big part of why the product clicks for people. A number of the outliners of yesteryear support a feature called “hoisting”, but it doesn’t feel like a primary way of using them, and the way of interacting with it is clunky.

I was familiar with outliners before WorkFlowy, but I never used them. I think that in a way was an advantage in my work with WorkFlowy, because normal outliners (at least the ones in use circa 2010) were not compelling to me – I wanted to make a hierarchical list-making app that was a joy to use.

 

FRANK: Could you give us some insight into how difficult it actually is to roll out any new feature? Take, for instance, one of the relatively recent additions… the ability to select multiple, arbitrary lists (Alt+Click).

JESSE: Doing things in a really smooth and nice way is hard, and takes a lot of time. Multi-select is a great example. Mike did an amazing job with it and it feels simple and clean.

I just looked at the timestamps on that project and it looks like it took from mid/late May of 2014 until mid July. So, a month and a half at least for that feature that looks/feels simple, but has so many different things going on, so many different browser quirks to work around, etc., that getting it out the door was really time intensive.

MIKE: We (well, particularly I) are perfectionists about the product, and this makes new features take longer, but I think it has been worth it. When we add something new, we think how it can integrate with everything else in the product and how to do things in the most elegant way possible. I am quite averse to new features that feel like they are “tacked on” to the rest of the product. Everything should integrate seamlessly and in a way that makes sense.

FRANK: One gets the feeling that if you were to implement all reasonable requests on people’s wish lists, WorkFlowy might get a tad bloated. Any thoughts on that? Do you have any WorkFlowy philosophy that guides your decision making that’s not documented anywhere?

JESSE: I don’t think that most of the requests we get would bloat the software. Once in a while someone says something that seems incredibly specific or misaligned with our philosophy, but most of the time it makes sense.

Our philosophy so far has been that basically it is text lists with superpowers. So doing anything in WorkFlowy should just feel like typing, and the more familiar you get with it, the faster and more intuitive it gets.

As I said, I don’t think it’s the features that would bloat the software, but rather the way we implemented them and exposed them to the user. We aren’t geniuses, though, so we could definitely mess it up.

MIKE: Disagree that we aren’t geniuses. J/K.

This goes back to the general point that a big part of a product feeling bloated is not how much you can do with it but rather how well-integrated everything is. So, for example, Microsoft Word feels bloated because it shows you endless menus and rows of icons. If new functionality can be added in a way that feels natural (like allowing importing content simply by pasting it into an empty item, for example), then the product simply feels powerful and intuitive rather than bloated.

I think that most new features can be added in a way that increases power but not bloat or complexity. There are some features I struggle with, but it’s a fun challenge to try to do everything in the best way possible.

FRANK: The overwhelming majority of WorkFlowydom loves WorkFlowy’s minimalist feel and dynamic. Given that… and provided you had the development capabilities in place, how far does your vision stretch in terms of additional features? What features would you, yourselves, kill for?

JESSE: My imagination stretches very far, and there are a million features/improvements I’d like to make.

I think that minimalism and lots of features are not opposed to one another. It is instead the way of implementing new features that allows a product to stay minimal. We have added a ton of new features over the years, yet kept the product minimal.

If every feature is pushed into people’s faces through the interface, then you get what feels like feature bloat. If, instead, you are using a product and you think, “I wish it did X,” and then thirty seconds later you realize, “Oh, it does do X”, then you’ve got a minimalist product.

The features I personally want most? I’d like a better native mobile app, I’d like a left bar so it was easier to navigate to dramatically different parts, I’d like image support, I’d like a ton of stuff related to collaboration and communication so that I could draw people’s attention to things, see updates when people change things, just have that whole flow be easy for communicating with people inside of it. I’d like some concept of dates, but for me I’d probably be more interested in recurring stuff, so I could use it more effectively to build a regular schedule for myself. I’d like to have something around tags and templates, so I could quickly type something in and pop in a structure that I’ll then fill in. I’d really like to have a way for people to share such templates with one another, and I’d also like to have a way for people to easily create interactive how-to’s and tutorials for workflowy, that provide a person with a WorkFlowy structure for a given person and then guide them through using that structure, so that we could have a community of best practice that evolves over time to discover and share different ways of using the tool. I’d like to make it easy to link from one place in WorkFlowy to another, so that you could represent graphs easily instead of just trees. I’d like to have an API that let you both control the interface and build new interfaces for WorkFlowy (as well as more normal stuff). I’d like to make a nice way to publish WorkFlowies, including more presentation type display (which really just means making everything bigger). I’d like to let you sort your sub lists in different ways. I’d like to let you view multiple sublists at once, side by side or maybe in a grid of sorts. I’d like to have much faster collaboration, so there’s no lag when editing. There is an endless list, honestly. Most of the stuff people want, I’d really like to do.

FRANK: Does the current set of features we have stem predominantly from your very own use of WorkFlowy or do you also anticipate features you think others might need even though you don’t?

JESSE: It comes primarily from our own use cases, plus that avalanche of feedback we get from our users. This actually frustrates me a bit, because our jobs aren’t that typical and I really would like to have a design process that focuses more on our users than on ourselves. It is super important for us to use the product, but I’d really like to design with more empathy, and actually do things like date support, which a lot of people with real jobs that involve meetings and deadlines need.

MIKE: I do have a very empathetic relationship with myself, but I agree with Jesse that we have some blind spots that are due to our own use cases for the product. We tend to weigh things that we will use a lot more heavily, which is human nature, but also can lead to important things being pushed off into the future.

FRANK: Do you have any secret WorkFlowy features that you reserve for yourselves (and which you would never ever admit)?

JESSE: Not really. We have a few administrative things we can do, but those aren’t really features, just things that help us with customer support.

MIKE: The closest thing to this is probably the “hidden search operators,” but we have blogged about them which makes them not-so-hidden 🙂

We of course have been planning to make these less hidden, particularly in terms of viewing what has changed recently.

In general, we try not to use anything that isn’t clearly documented and intuitive for other people, because that creates blind spots where we don’t realize that important functionality is missing for others.

FRANK: Any thoughts about an open API (to let others go wild)?

JESSE: Would love to do it. We haven’t yet because it feels like a big project that we have no idea how to really approach.

FRANK: Over the last couple of years, has your job of convincing people to onboard gotten any easier? Why do you think it is that so many people don’t click at first… and in many cases only get their Eureka moment months or years later?

JESSE: You know, this is what kills me. We still stink at onboarding I think, and it is one of the things that if we nailed it, we would be growing a lot more quickly and just be in a totally different place as a product and a company.

I am thinking about this all the time, but here are a few thoughts.

1. One of the benefits of WorkFlowy is the familiar document-like interface. However, because most documents don’t zoom, many people don’t get it and find the zooming jarring. They haven’t shifted their thinking, and we haven’t helped them shift their thinking, so they miss on one of the main benefits of the program.
2. We only provide one document, because zooming means every item in your document is also a document. However, a lot of people don’t quite get this, and they just start their main document as if it is a normal list, say, of contacts, or todos, or whatever. So they do not create higher level categories and miss out on the whole point of workflowy. Moreover, they get frustrated that they can’t figure out how to “create another list”. This is mostly an interface issue, and I think our plans for a left bar to make navigating easier is a good step toward giving people a sense of how to use the product.
3. We start people with a blank slate. We provide a few help videos, but I don’t think those are very helpful for really getting people started. We need to do a much better job helping people figure out how to structure their WorkFlowy, what to put in it, and how to get started in general, seeing examples of how other people use WorkFlowy. I’ve spent a lot of time on our onboarding and it feels to me like this is an area that is still incredibly weak, and that the average person doesn’t quickly get to a place of excitement and insight about how the product can help them. Enough of them do that we have a lot of users, and those who do get excited enough that they preach the WorkFlowy gospel, but we’re still doing a poor job on this.

MIKE: User onboarding is a difficult problem in general, and the open-ended nature of WF makes it all the more difficult.

As Jesse said, we are still bad in the onboarding department. We have been lucky to have spread mostly through word-of-mouth, which means that people can tell their friends what’s cool about WF and how they use it – which is basically the first stage of onboarding. That means that even if we do a bad job at onboarding, people may still “get it” because they were introduced by a trusted friend.

We know for a fact that we lose a lot of people due to confusion about how (or why) to use the product. And given how excited people are once it clicks, that is certainly a loss for us, and something we continue to try and improve.

FRANK: I’ve seen this exact same concern far and wide from organizational tool users across the board – here’s a snippet from a certain forum: “My greatest fear is that WorkFlowy disappears one day… because it would be tough to manage without it now.” Any authoritative words of assurance from the horse’s mouth?

JESSE: WorkFlowy is a strong and stable small business, so it isn’t going to die because we can’t pay the bills.

We’ve already been approached about selling a number of times, and we haven’t done it yet.

Lastly, if we did sell, we’d be very inclined to sell to a company that would actually want to invest in the product.

FRANK: I’d love to see any real-life list/ hierarchy of yours – something you can give us an inside look at – whether semi-top secret or mundane. For one, we know that you plan WorkFlowy in WorkFlowy…

JESSE: Here’s a high level view of our master list:

Well, I recently did an experiment to try to increase the number of people in shared documents who start using WorkFlowy elsewhere in their lives. It was a massive failure. Here’s the list I used to manage that project:

I did this outside of the actual WorkFlowy shared list because I’ve been experimenting with a GTD flow in my own private WorkFlowy. If Mike and I had been working on this together, however, it would have been in the WorkFlowy section, and it probably should have been in there anyway.

FRANK: Do you reckon you (the creators of WorkFlowy) might have some rather unique/ uncommon way(s) of using your document that you haven’t seen before on the web?

JESSE: You know, I’m not sure we do. I/we use it for everything, and in a lot of different way, but a lot of users do too. Don’t think this is particularly novel, but I often structure projects in the following way:

I drag stuff between the lists as I work on them. I’m not sure that’s particularly novel or interesting, but it is what came to mind.

MIKE: I also wouldn’t say we really use particular tricks that we haven’t seen other people use. I think the way a person uses WorkFlowy is very much the same as the way that person thinks and gets things done in general. WF lets you organize things however you like, so it lets people do whatever they want (which is both what makes it great, and what makes it hard to explain to people).

My style of working on a project is to first write copious notes in a “brain dump” style where I just unload everything I’m thinking about in a somewhat disorganized manner. I will then organize it a bit and move things around.

Once that is done, I’ll create an “Implementation plan” section where I specifically outline each of the steps I’m going to take to finish the project or task at hand. These steps are precisely ordered based on dependencies and also generally trying to do the simple things first and the more complicated things later.

I’ll then further break down each step in the implementation plan, often going multiple levels deeper for each one.

I’ve been using this process (in WorkFlowy) for years now, and it really works well for me.

---