The point is that conflating these cheapens both disciplines. A good API may last decades, a good UI can float across multiple APIs.
The point is that conflating these cheapens both disciplines. A good API may last decades, a good UI can float across multiple APIs.
That's the point. Programmers are the users of APIs. So build them for users, to support them in their work; don't build them programmers who need to hack around the API to get things done.
> while users don't have to know about it.
There is no difference between programmers and users. Everyone is a user, it's just a matter of perspective. If you creat an API you are the programmer, if you use an API you are the user. In both cases you have different knowledge, understanding and goals.
It's not a good analogy because programming APIs are only used by the programmer. If this is an internal API then it's akin to the farming equipment that a tomato farmer might use to supply the chef with high quality tomatoes.
A farmer using high quality, efficient equipment will have an easier and more productive time farming tomatoes and therefore will have an easier time fulfilling the needs of chefs who want the tomatoes.
It's still very much a user interface. The users are your developers. I think people are confusing graphical user interfaces with user interfaces. A keyboard/mouse is a user interface into a PC.
If it's a public API then the API is your product. And it's very much a UI because that is the user interface, the users use your product in that way. That's why companies like Stripe are so loved by developers, they have a good API.
>>> it's akin to the farming equipment that a tomato farmer might use
>> A farmer is not the one designing the farm equipment
Great example of the problem of using analogies.
> someone else's spaghetti code
I'll not open this, erm, can of worms
What should be taken seriously is proper domain and service modeling. The rest follows.
A good UI follows a good model. Visuals and trends are just a tiny bit.
I honestly have no idea what "proper domain and service modeling" means but a good UI is NOT a natural consequence of good engineering. That's why human interface design is a real discipline.
Code/APIs are a different type of User Interface. Maybe we can call it PUI for Programmer User Interface.
The term "user interface" is perhaps a bit unfortunate, and "human interface" would be better. In my usage of "user" here it's a synonym for "human".