Why services should offer marginal features (with apologies to 37signals) | Hacker News Reader

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

zencoder.com

86 pointsjon_dahl35 comments

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.

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.

Thanks for using Highrise. Sorry you're having a bad experience with deals.

We agree that the deals page needs pagination, but most people don't have 5000 deals. So while you're scenario is very real to you, it's not a common case. That's not to take anything away from your experience - we agree it's bad and we want to make it better - it's all just a matter of priority. We're currently working on optimizing for the common cases so we can improve the product(s) in areas everyone can enjoy.

Our development log is public, if your curious about the improvements we're making every day: http://highrisehq.com/changes

Thanks, Jason. Appreciate the response and understanding of our frustration.

We have heavily integrated our business app with Highrise, including our Quote to Invoice app with the REST API. We've built reports around the Highrise data. And we love Highrise, for the most part, since it simplifies the sales process. And it's great to track where our sales are at.

But what made us love Highrise was that it was fast. And when we lose that speed, we are reminded of our experience with Salesforce.

The loss in productivity with Salesforce was why we came to 37s in the first place, because you offered us real value in simplifying our sales flow. But right now, we are fiddling with speed, and we understand while you have different priorities, going through our deals nimbly is important to us.

Yeah, I mean pagination is so basic and should have been there in the beginning. It makes everyone feel nice to be glad-handed but ... come-on, pagination?

It was basic frustrations like this that caused us to switch as well. In particular, it with the issue with tasks lists - we used Basecamp and Highrise, and even though the feature request has been made regularly for the last 4 years, there is STILL no way to get a common task list across Highrise and Basecamp.

So we went over to Zoho. In the time it has taken 37Signals to hem and haw over task lists, Zoho has created an entire ecosystem of apps, integrated it with Google App Engine, associated tasks across their apps, etc.

Sure, the apps aren't pretty, but they work. Jason would probably argue that our needs aren't the norm, that we've outgrown Highrise, but a counterexample is FreshBooks: we've been using FreshBooks since day one in our business, and we continue to us it because it's a great app that is growing with us. It focuses on simplifying things that are ordinarily complex rather than simplicity as an end goal.

Highrise has been less and less valuable to me (though I'll note that just by calling it a "CRM", you're already suggesting that you're asking it to do tricks; it's not a full-featured CRM). But Basecamp has gotten more useful to me over the past year or so.

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.

> 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.

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.

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

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.

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.

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).

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.

It is the same problem, but you just don't deal with it at the same point. With UI you are forced to make it simple or users won't be able to figure it out. With an API, you can make it complex, but you will end up having to support that and a 1000 features within an API, no matter how simple, will always be harder to manage than 10.

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.

>> I always wonder if I'm ever using the right parts just because there's so much there.

Good point, but I'd say that (1) any well-documented API call should discuss its alternatives, and (2) any well-designed API in general should try to minimize unnecessary overlap between functions.

This seems to be a point that you are alluding to: In some ways, the UI for an API is actually its documentation.

OP here. I probably shouldn't have made my argument sound quite so mathematically rigorous. :)

You're right that a well-designed UI can decrease the complexity of additional features. That said, I think it's usually true that additional features have a larger impact on the complexity of a UI than the complexity of an API. Not as a universal rule, but as a general guideline.

It might be useful to view APIs as a UI; it is not a G UI, but it is is a user interface where the users are developers.

The developer can be as confused as a GUI user when faced with a myriad of choices.

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.

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.

> 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.

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?

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.

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).

I'd say that PHP is easier to learn and harder to master, whereas the opposite holds true for Ruby/Python. The difference being primarily the fact that the Ruby/Python communities generally are more invested in code quality and improving the state of the art of software engineering, and therefore it's easier to find better code to accelerate your learning.

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)

The person I was responding to talked about PHP being the best at getting set up quickly. I wasn't comparing PHP to Rails or Django, I was measly saying that for getting up to speed fast, I found PHP not as fast to get up to speed quickly. For political correctness though, I'll say this: I find most PHP frame works (CI I found lacking, Symphony I found easy but something just didn't click, Cake was ok amazingly, the others I haven't used) are not as good as Rails or Django for quickly bringing a project up to speed.

Your statement compares PHP to Rails and Django. It's not about 'political correctness', it's about comparing a language to a framework. Of course a framework gets things done faster than no framework.

No I didn't. When I originally said what I said, I wasn't really comparing PHP against Rails or Django, I was merely stating that there are better ways to get up to speed faster. I then proceeded to give my opinion on the frameworks I've tried in PHP, mostly to be a good sport to you. In any case, PHP with or without framework, feels (to me) like a messy solution with less structure than the usual suspects.

How is that any different than Python, Ruby, Perl, etc...?

It's the same of course, just that people complain a lot about PHP's ... erm ... richness of built-in functions.

I think the main complaint is that they're not neatly divided into namespaces or modules, as they are in Python.

Reply on news.ycombinator.com