4 ms·
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 docum
by 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 agoI 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 agoThe 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 16y ago>> 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 16y agoThis seems to be a point that you are alluding to: In some ways, the UI for an API is actually its documentation.
- duck 16y agoIt 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.
- jon_dahl 16y agoOP 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.
- brunoc 16y agoIt 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.