11 ms·

Why services should offer marginal features (with apologies to 37signals)

86 points by jon_dahl 16y ago

Jd 16y ago
No need to apologize to 37signals. They wouldn't to you!
- access_denied 16y ago
  But he did apoogize and that's a difference that got noticed.
- access_denied 16y ago
  But he did apologize and that's a difference that got noticed.
stevedewald 16y ago
I'm not sure I agree that an API is that different from a UI. Try working with the Windows API in C#. Lack of default parameters means that for every API call I have to explicitly set about 30 options (29 of which I'm usually not using). It sounds like the point you're making is that, if well-organized, marginal features can add value without encumbering users that aren't interfacing with them. That makes a lot of sense, and I agree with your approach over the 37signals approach. Marginal features can be core features to some users. It's just important that we keep the interface/API organized in a thoughtful manner, so that unused features don't distract people.
- chipsy 16y ago
  I would agree that APIs are more of a kind of UI than a "something else" where the rules are different. They can afford to scale up their complexity more than graphical designs because textual reference lets you bury stuff very deeply, but the user still has to deal with the "conceptual load," which in a big API can be pretty intensive.
- RickHull 16y ago
  > Try working with the Windows API in C#. Lack of default parameters means that for every API call I have to explicitly set about 30 options (29 of which I'm usually not using). Both APIs and UIs can be poorly designed. I think the point is that UIs have an additional constraint -- that of being interactive. At least filling out the poorly designed Windows API signatures only has to be done once, at design time. After that, the application does it for you and never gets tired of it. Also, the audience for APIs is developers, who are far more tolerant of necessary complexity, especially when considering an infrastructure to build off of. I mean, intuitive APIs are nice, but I appreciate a proper design (respects orthogonality, minimize leaky abstractions, etc.) even if intuition is sacrificed. Users have neither the luxury of automation (i.e. no application layer on their side that can "pave over" any warts or tedium) nor the tolerance for violated intuition.
colinprince 16y ago
This is why PHP works well for getting going fast, you don't have to learn all the built-in functions, just the ones you need. In this case the name-space is the API.
- code_duck 16y ago
  How is that any different than Python, Ruby, Perl, etc...?
  - colinprince 16y ago
    It's the same of course, just that people complain a lot about PHP's ... erm ... richness of built-in functions.
    - code_duck 16y ago
      I think the main complaint is that they're not neatly divided into namespaces or modules, as they are in Python.
- sp4rki 16y ago
  You can say the same of any programming language. Why should I try to use features I don't really need to use? To put things in perspective, it's equally easy to make a convoluted API that sucks in PHP than in any language or framework. PHP is not exempt of following decent UI/IX guidelines, regardless of how fast you can get up to speed with it (which in my experience I still find it slower than Django or Rails).
  - code_duck 16y ago
    You can't logically compare Django and Rails to PHP, though. How about comparing those two to CI, Yii, Kohana, Cake or Symfony? (I know which I'd prefer - Django - just pointing that out)
    - sp4rki 16y ago
avk 16y ago
Takeaways: 1) "what’s marginal to one user might be core to another" 2) APIs can afford to have more marginal features than UIs because the complexity is largely hidden. Done right, there's more API documentation but the main interactions aren't affected or made more complex.
avk 16y ago
I'm not sure that API complexity is that different from UI complexity. From the article: "But APIs are different. An API with 60 options makes for longer documentation, certainly. But if the options are well-chosen and well-documented, an API with 60 options is barely more complex than an API with 20 options. You should be able to safely forget about features you aren’t using, and just use the features that matter to you. Done well, incremental features in an API only increase complexity by O(log-n) or even O(1) – virtually no complexity increase at all." This is true, but how is this different from a UI that's done well? With a great UI you should also "be able to safely forget about features you aren’t using, and just use the features that matter to you." Isn't that just good information architecture combined with a design that prioritizes and encourages accomplishing the most common tasks? A poorly designed API adds just as much complexity and frustration as a poorly designed UI. But I doubt that a UI "done right" still increases complexity by O(n) or O(n-squared).
- csallen 16y ago
  I think the author makes a good point. In UI design, you're working with platforms that have limited display space, and you're working with users who have limited attention spans. To be great, you have to know what to leave out. Sure your inherent abilities in design are important, but as the number of features approaches infinity, so do your chances of designing a shitty UI. APIs are a different story. Whether you have 10 features, 100, or 1000 is almost totally irrelevant. It doesn't affect the user experience.
  - avk 16y ago
    The original post makes no mention of how a UI "done well" is different from an API "done well." I'm really interested in the omission and think that might be the only flaw in the argument. I've never developed an API but the difference between 10 and 1,000 features is huge for the consumer of an API. With big enough APIs, even if the individual calls are beautifully simple and well-documented, I always wonder if I'm ever using the right parts just because there's so much there.
    - 16y ago
tow21 16y ago
API complexity - just as much as UI complexity - represents a host of different code paths in your software that you need to manage. You need to make sure all these code paths work; and you need to make sure they don't interact in unexpected ways. You need to test not only the well-used paths (which your users will test for you - you'll find out quickly enough if commonly-used functions fail!) but also all of your less-commonly used paths, which will bit-rot if you're not on top of them all the time. The art of good API design is entirely different, but just as hard, as good UI design. Bolting on a bunch of new features does not a good API make - you need to ensure that you add features sensibly, orthogonally, and matching your user's expectations. Expanding your API also means you need to make sure you have a good understanding of the load profile of all your API calls, both individually and in combination. In short, I think the OP is underestimating the complexity involved in designing and managing an API - just because the problems arising aren't the same as those in UI design doesn't mean they're not there.
dasil003 16y ago
I agree with the conclusion, but I don't think the argument is presented all that well: This advice might be good for user-facing web applications. But if you’re building XaaS, marginal features are awesome. That’s because when you’re a service, what’s marginal to one user might be core to another. I don't think this is any less true in user-facing applications than it is in APIs. It seems to me that the main difference is that user-facing apps tend to be solving higher-level problems (eg. project management vs encoding video). Our job is to provide powerful tools and let our users decide what options matter. 37signals also listens to users, but the total number of users per revenue dollar is higher, the scope of the usage is wider, and the cost profile (development, maintenance and cognitive overhead) tends to be different. In either case any new feature requires a cost-benefit analysis. But APIs are different. An API with 60 options makes for longer documentation, certainly. But if the options are well-chosen and well-documented, an API with 60 options is barely more complex than an API with 20 options. This is certainly true for options that are simply wrapping command-line options of open source components. However if you're implementing code on the back-end, these options can easily add complexity to the whole system. It's true that a checkbox in a GUI is a much higher burden on the user than an option in service API documentation, but then again a service already starts with an order of magnitude higher usability burden than a GUI. This is of course because APIs are designed to be coded against, so the amount of user effort expended is amortized over hundreds or thousands of compute hours. I'm sure the author understands all this, but it just didn't quite come out of the article.
- jasonjei 16y ago
  I think the author has a valid point. 37signals's Highrise is a CRM that we are using--and after using it for several years, we still don't have pagination. We wait for 5000+ deals to load, including lost and won deals, yet something as simple as pagination (or even an archiving feature), which have sent feature requests, still won't be implemented. So instead, we continue to wait 5-6 seconds for our deals page to load. If anything, Highrise hasn't grown in years. It's now feeling the plateau effect, and we are looking for alternatives to Highrise because it hasn't grown with us. I agree that "Less is More," but when something as simple as paginating the deals can't be implemented, it makes me wonder why we pay 37signals every month. If it's not going to improving the software and improving workflow, customers will leave to a business that understands its customers. Even Apple, while they don't exactly ask for their customers' input, know what problems their customers face every day. 37signals looks as if they are becoming out of touch with their users.
tptacek 16y ago
I think 37signals acknowledges that "what's marginal to one user could be core to another". Their point is, "who cares?" They're optimizing for minimal feature set, maximal user base, so they can refine the hell out of the features they do offer. There are indeed other product strategies, but they're all fraught; as Apple's competitors discovered, you can even lose users who use your "marginal" features if the real core features in competitors offerings are better executed.
8ren 16y ago
Aside: with application development becoming so much easier and faster, will it also become much more competitive (which is bad for developers), in comparison with systems/infrastructure development?
bluesnowmonkey 16y ago
APIs introduce a more long-term maintenance burden than GUIs. If you take away a checkbox that hardly anyone used, no big deal, a few people are momentarily confused. But if you take away an API call parameter that hardly anyone used, a few people still depended on it, and maybe the change broke their systems and caused them to lose business until they patched it. Then they complain online, cancel their agreements with you, scare away your potential customers... it can be a disaster. Everything you put in your API documentation is a promise. Facebook gets away with frequent, breaking API changes because they have a monopoly. Until you can say the same, it might be a good idea to keep your API stable.
astrange 16y ago
> This week, we’re releasing a bunch of advanced audio processing features. These features let you normalize audio levels, fade in/out, control gain, apply a highpass/lowpass filter, apply a expand/compress effect, and apply basic equalization. We’re even adding a karaoke effect option. Those are just the default audio filters in mplayer. At least it can't have cost much to implement.

86 points by jon_dahl 16y ago

Jd 16y ago

No need to apologize to 37signals. They wouldn't to you!

access_denied 16y ago
But he did apoogize and that's a difference that got noticed.
access_denied 16y ago
But he did apologize and that's a difference that got noticed.

stevedewald 16y ago

I'm not sure I agree that an API is that different from a UI. Try working with the Windows API in C#. Lack of default parameters means that for every API call I have to explicitly set about 30 options (29 of which I'm usually not using). It sounds like the point you're making is that, if well-organized, marginal features can add value without encumbering users that aren't interfacing with them. That makes a lot of sense, and I agree with your approach over the 37signals approach. Marginal features can be core features to some users. It's just important that we keep the interface/API organized in a thoughtful manner, so that unused features don't distract people.

chipsy 16y ago
I would agree that APIs are more of a kind of UI than a "something else" where the rules are different. They can afford to scale up their complexity more than graphical designs because textual reference lets you bury stuff very deeply, but the user still has to deal with the "conceptual load," which in a big API can be pretty intensive.
RickHull 16y ago
> Try working with the Windows API in C#. Lack of default parameters means that for every API call I have to explicitly set about 30 options (29 of which I'm usually not using). Both APIs and UIs can be poorly designed. I think the point is that UIs have an additional constraint -- that of being interactive. At least filling out the poorly designed Windows API signatures only has to be done once, at design time. After that, the application does it for you and never gets tired of it. Also, the audience for APIs is developers, who are far more tolerant of necessary complexity, especially when considering an infrastructure to build off of. I mean, intuitive APIs are nice, but I appreciate a proper design (respects orthogonality, minimize leaky abstractions, etc.) even if intuition is sacrificed. Users have neither the luxury of automation (i.e. no application layer on their side that can "pave over" any warts or tedium) nor the tolerance for violated intuition.

colinprince 16y ago

This is why PHP works well for getting going fast, you don't have to learn all the built-in functions, just the ones you need. In this case the name-space is the API.

code_duck 16y ago
How is that any different than Python, Ruby, Perl, etc...?
- colinprince 16y ago
  It's the same of course, just that people complain a lot about PHP's ... erm ... richness of built-in functions.
  - code_duck 16y ago
    I think the main complaint is that they're not neatly divided into namespaces or modules, as they are in Python.
sp4rki 16y ago
You can say the same of any programming language. Why should I try to use features I don't really need to use? To put things in perspective, it's equally easy to make a convoluted API that sucks in PHP than in any language or framework. PHP is not exempt of following decent UI/IX guidelines, regardless of how fast you can get up to speed with it (which in my experience I still find it slower than Django or Rails).
- code_duck 16y ago
  You can't logically compare Django and Rails to PHP, though. How about comparing those two to CI, Yii, Kohana, Cake or Symfony? (I know which I'd prefer - Django - just pointing that out)
  - sp4rki 16y ago

avk 16y ago

Takeaways: 1) "what’s marginal to one user might be core to another" 2) APIs can afford to have more marginal features than UIs because the complexity is largely hidden. Done right, there's more API documentation but the main interactions aren't affected or made more complex.

avk 16y ago

I'm not sure that API complexity is that different from UI complexity. From the article: "But APIs are different. An API with 60 options makes for longer documentation, certainly. But if the options are well-chosen and well-documented, an API with 60 options is barely more complex than an API with 20 options. You should be able to safely forget about features you aren’t using, and just use the features that matter to you. Done well, incremental features in an API only increase complexity by O(log-n) or even O(1) – virtually no complexity increase at all." This is true, but how is this different from a UI that's done well? With a great UI you should also "be able to safely forget about features you aren’t using, and just use the features that matter to you." Isn't that just good information architecture combined with a design that prioritizes and encourages accomplishing the most common tasks? A poorly designed API adds just as much complexity and frustration as a poorly designed UI. But I doubt that a UI "done right" still increases complexity by O(n) or O(n-squared).

csallen 16y ago
I think the author makes a good point. In UI design, you're working with platforms that have limited display space, and you're working with users who have limited attention spans. To be great, you have to know what to leave out. Sure your inherent abilities in design are important, but as the number of features approaches infinity, so do your chances of designing a shitty UI. APIs are a different story. Whether you have 10 features, 100, or 1000 is almost totally irrelevant. It doesn't affect the user experience.
- avk 16y ago
  The original post makes no mention of how a UI "done well" is different from an API "done well." I'm really interested in the omission and think that might be the only flaw in the argument. I've never developed an API but the difference between 10 and 1,000 features is huge for the consumer of an API. With big enough APIs, even if the individual calls are beautifully simple and well-documented, I always wonder if I'm ever using the right parts just because there's so much there.
  - 16y ago

tow21 16y ago

API complexity - just as much as UI complexity - represents a host of different code paths in your software that you need to manage. You need to make sure all these code paths work; and you need to make sure they don't interact in unexpected ways. You need to test not only the well-used paths (which your users will test for you - you'll find out quickly enough if commonly-used functions fail!) but also all of your less-commonly used paths, which will bit-rot if you're not on top of them all the time. The art of good API design is entirely different, but just as hard, as good UI design. Bolting on a bunch of new features does not a good API make - you need to ensure that you add features sensibly, orthogonally, and matching your user's expectations. Expanding your API also means you need to make sure you have a good understanding of the load profile of all your API calls, both individually and in combination. In short, I think the OP is underestimating the complexity involved in designing and managing an API - just because the problems arising aren't the same as those in UI design doesn't mean they're not there.

dasil003 16y ago

I agree with the conclusion, but I don't think the argument is presented all that well: This advice might be good for user-facing web applications. But if you’re building XaaS, marginal features are awesome. That’s because when you’re a service, what’s marginal to one user might be core to another. I don't think this is any less true in user-facing applications than it is in APIs. It seems to me that the main difference is that user-facing apps tend to be solving higher-level problems (eg. project management vs encoding video). Our job is to provide powerful tools and let our users decide what options matter. 37signals also listens to users, but the total number of users per revenue dollar is higher, the scope of the usage is wider, and the cost profile (development, maintenance and cognitive overhead) tends to be different. In either case any new feature requires a cost-benefit analysis. But APIs are different. An API with 60 options makes for longer documentation, certainly. But if the options are well-chosen and well-documented, an API with 60 options is barely more complex than an API with 20 options. This is certainly true for options that are simply wrapping command-line options of open source components. However if you're implementing code on the back-end, these options can easily add complexity to the whole system. It's true that a checkbox in a GUI is a much higher burden on the user than an option in service API documentation, but then again a service already starts with an order of magnitude higher usability burden than a GUI. This is of course because APIs are designed to be coded against, so the amount of user effort expended is amortized over hundreds or thousands of compute hours. I'm sure the author understands all this, but it just didn't quite come out of the article.

jasonjei 16y ago
I think the author has a valid point. 37signals's Highrise is a CRM that we are using--and after using it for several years, we still don't have pagination. We wait for 5000+ deals to load, including lost and won deals, yet something as simple as pagination (or even an archiving feature), which have sent feature requests, still won't be implemented. So instead, we continue to wait 5-6 seconds for our deals page to load. If anything, Highrise hasn't grown in years. It's now feeling the plateau effect, and we are looking for alternatives to Highrise because it hasn't grown with us. I agree that "Less is More," but when something as simple as paginating the deals can't be implemented, it makes me wonder why we pay 37signals every month. If it's not going to improving the software and improving workflow, customers will leave to a business that understands its customers. Even Apple, while they don't exactly ask for their customers' input, know what problems their customers face every day. 37signals looks as if they are becoming out of touch with their users.

tptacek 16y ago

I think 37signals acknowledges that "what's marginal to one user could be core to another". Their point is, "who cares?" They're optimizing for minimal feature set, maximal user base, so they can refine the hell out of the features they do offer. There are indeed other product strategies, but they're all fraught; as Apple's competitors discovered, you can even lose users who use your "marginal" features if the real core features in competitors offerings are better executed.

8ren 16y ago

Aside: with application development becoming so much easier and faster, will it also become much more competitive (which is bad for developers), in comparison with systems/infrastructure development?

bluesnowmonkey 16y ago

APIs introduce a more long-term maintenance burden than GUIs. If you take away a checkbox that hardly anyone used, no big deal, a few people are momentarily confused. But if you take away an API call parameter that hardly anyone used, a few people still depended on it, and maybe the change broke their systems and caused them to lose business until they patched it. Then they complain online, cancel their agreements with you, scare away your potential customers... it can be a disaster. Everything you put in your API documentation is a promise. Facebook gets away with frequent, breaking API changes because they have a monopoly. Until you can say the same, it might be a good idea to keep your API stable.

astrange 16y ago

> This week, we’re releasing a bunch of advanced audio processing features. These features let you normalize audio levels, fade in/out, control gain, apply a highpass/lowpass filter, apply a expand/compress effect, and apply basic equalization. We’re even adding a karaoke effect option. Those are just the default audio filters in mplayer. At least it can't have cost much to implement.