Menu

Can software ever be done?

My latest column for A List Apart was published today. From The Analog Revolution:

So I wonder. I wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the product we make might not only be done at some point, but might be something that lasts for a while? Would we make it fit into the web environment better, give it a timeless aesthetic, add fewer unnecessary features, and spend more time considering the consequences of our design decisions?

It’s not the best thing I’ve ever written, but I have to say, it’s one of my favorites. This is something I’ve been thinking about for a very long time, and to condense those thoughts into just over 1,000 words that include subtle references to The Hobbit and Zoolander feels pretty good.

How to display threaded discussions on the web

I’ve been doing some work on threaded discussions and comment threads in our web and mobile apps, and I thought it might be useful to summarize some of my findings here. The particular issue we’re trying to address is how to deal with infinitely threaded discussions, like the kind you find on Hacker News and Reddit1:

Infinitely threaded comments on Reddit

The first thing I did was some research on the different approaches currently used on the web and mobile for discussions and comments. There are some weird outliers, but in general there are five major ways threads are handled:

Threaded discussions on the web

I did some further digging and came up with the following list of pros and cons for each approach.

Completely flat

  • Example: New York Times
  • Pros:
    • Easy to navigate—just scroll down
    • Content not pushed off screen
  • Cons:
    • No context available
    • Difficult to follow conversation or see what a comment/reply refers to

Infinitely threaded

  • Example: Reddit
  • Pros:
    • Context always visible
    • Can have deep side conversations
  • Cons:
    • Difficult to navigate
    • Hard to find new replies on a thread
    • Pushes content off screen (as threading continues to reduce column width)
    • Doesn’t let you decide which tangents (reply threads) you want to dig into2

Capped threaded

  • Example: Stack Exchange
  • Pros:
    • Sets expectations that replies can’t go on forever
    • Keeps context visible (up to a point)
    • Content not being pushed off the screen
  • Cons:
    • Deeper levels of replies not possible

Infinitely threaded (collapsed)

  • Example: Quora
  • Pros:
    • Context available on demand
    • Easy to scroll and decide which tangents to go off on
    • Less cognitive load to scroll through
  • Cons:
    • An extra action needed to view context

Teased capped threaded3

  • Example: Facebook
  • Pros:
    • Context available on demand
    • Easy to scroll and decide which tangents to go off on
    • Less cognitive load to scroll through
    • Can highlight relevant content as teasers
  • Cons:
    • New comments in thread can be confusing without their context

Our approach

All design in a business is compromise. In our case, we need to figure out what we’re willing to gain, and what we’re willing to give up for it. In our case, our existing product uses infinitely threaded comments. So any change from that will obviously be… complicated. But considering that we want a single approach on mobile and web, it currently looks like we’re going to go with the Teased capped threaded approach:

Teased capped threaded

This seems to strike the best compromise between easy scanning and the ability to drill into specific conversations. The “teaser reply” is particularly interesting, because it opens up some neat ways to provide relevant content to users. Perhaps you show the first unread reply, or the latest reply by someone you follow, or the most-liked reply. We’re still trying to figure out what would be most useful.

Another outstanding issue is if/how to deal with this approach differently on desktop and mobile. Some apps (like Quora and Facebook) split the view into two pages. The first page has the content and the first level of comments, and the second page has only the reply threads. In digging into it a bit more, it looks like this is mostly to make the app more performant. Here’s how Facebook does it:

Facebook comments

And here’s Quora:

Quora comments

Youtube, on the other hand, does it all on one page:

Youtube comments

We’ll need to dig into the performance issue, but my preference would be for a single page with truncated replies, like YouTube does it. Our current working hypothesis for a good solution is this:

  • Show entire comment thread on the same screen (replies not on a separate screen) to make the flow better (easier to scan and dig into individual threads)
  • Cap each individual comment at 5 lines (with a way to expand) (Mobile only)
  • Show first reply to a comment, with “View more replies” to load 5 more (“View more” on mobile only)
  • Show first 10 comments on a post, with “View more comments” to load the next 10 (“View more” on mobile only)

I like this hypothesis because it keeps the approach the same across devices, but still allows for differences in screen real estate available on mobile and desktop. We’re still in the middle of the debate, so if anyone has any recommendations or anything to add, please let me know!


  1. Yes, Reddit starts capping threaded replies at some point, but they’re the best example out there of threads that go on forever. 

  2. Jeff Atwood did a good deep-dive on these issues in his post Web Discussions: Flat by Design 

  3. Yeah, I know I’m not good at naming things… 

Mobile first: not the right answer, just an efficient one.

Here’s some solid pragmatism from James Archer in Why is it so Easy to Get “Mobile First” Wrong?:

Mobile-first design isn’t, in itself, the right answer. It’s just an efficient answer. If you can design for one device and then tweak it to more or less function on other devices, you shave a lot of time off the design process. With the cornucopia of possible devices you’d otherwise have to design for, that’s definitely a good thing.

Developers: our best source of true innovation

I find the common meme of “Oh, that’s ugly—a developer must have designed that” pretty misguided (and I’m not even a developer). The reason is that most developers I know have exceptional ideas (and taste). So these words from Marty Cagan really resonated with me:

I consider this mindset of the product owner (or more generally, the CEO or stakeholders) as the only one that can determine what to build, as toxic to teams, and a major reason for the lack of innovation. I’ve tried to explain many times that often the best single source of true innovation are our engineers. That doesn’t mean every engineer is going to be like this, but the mindset where no engineers can do this is a very serious problem. The engineers are working with the technology every day and are in the best position to see what’s just now possible. They are also disproportionately very bright people. When you combine this deep knowledge of technology, with a first-hand experience of the customer problems, great products can result.

“The best single source of true innovation are our engineers.” True that.

What they say vs. what they do

If you invest in growth before you have retention, you’re renting users, not acquiring them.

— Gillian Morris in a great post about what users say vs. what they do.

Product vision + OKRs = Sustainable roadmap

I really love the product strategy direction Marty Cagan proposes in The Alternative to Roadmaps:

Ensure your product organization has a compelling product vision.  Ensure that each product team has a clearly defined, prioritized set of business objectives.  Make sure any commitments that must be made are high-integrity commitments.

This means that instead of prioritizing features (and the timing of those features), the leadership team prioritizes business objectives and problems to solve. There are two components to this:

First, the product vision is about setting OKRs—Objectives and Key Results (again—not features or solutions). From The Art of the OKR:

The objective sets a goal for a set period of time, usually a quarter. The key results tell you if the objective has been met by the end of the time.

Second, high-integrity commitments mean we give teams the time they need to figure out how long something will take. From Managing Commitments in an Agile Team:

So the way we manage commitments is with a little bit of give and take. We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution, and validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business (they can support this solution).

Once we have come up with a solution that works for our business, we now can make an informed and high-confidence statement about when we could deliver this and what type of business results we can expect. We can also decide if it’s even worth doing.

One day when I grow up, this is how I will run my product team.

How to continue to make good products as organizations grow

In my latest column for A List Apart, called The Distance to Here1, I discuss a theory I’ve had for a while now:

The larger the distance between people who build a product and people who make decisions about the product, the harder it is to make a good product.

The post goes into detail on how I think companies can continue to make good products as they grow.


  1. Anyone else old enough to get the reference? 

Empathy in enterprise software

In Design Thinking Comes of Age Jon Kolko describes one of the biggest (and most important) shifts we’re starting to see in enterprise software:

To build empathy with users, a design-centric organization empowers employees to observe behavior and draw conclusions about what people want and need. Those conclusions are tremendously hard to express in quantitative language. Instead, organizations that “get” design use emotional language (words that concern desires, aspirations, engagement, and experience) to describe products and users. Team members discuss the emotional resonance of a value proposition as much as they discuss utility and product requirements.

More

  1. 1
  2. ...
  3. 72
  4. 73
  5. 74
  6. 75
  7. 76
  8. ...
  9. 201