3 ms·

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

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.