

Why services should offer marginal features (with apologies to 37signals) - jon_dahl
http://zencoder.com/encoder-blog/2010/10/21/marginal-features/

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

~~~
jasonfried
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>

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

~~~
dinkumthinkum
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?

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

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

~~~
RickHull
> _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.

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

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

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

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

~~~
csallen
>> _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.

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

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

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

------
8ren
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?

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

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

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

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

