4 ms·

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 limi

by 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.
- 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 ago
    This seems to be a point that you are alluding to: In some ways, the UI for an API is actually its documentation.
duck 16y ago
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.

4 ms·

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 limi

by csallen 16y ago

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.
- 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 ago
    This seems to be a point that you are alluding to: In some ways, the UI for an API is actually its documentation.
duck 16y ago
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.