3 ms·

The article, which I liked, is very end user-oriented, but I think that the ability of other programmers to interact with your conceptual models is just as impo

The article, which I liked, is very end user-oriented, but I think that the ability of other programmers to interact with your conceptual models is just as important. Other people have to work with your code, and their ability to develop new features will very much depend on how easily they can work with your conceptual models. Onboarding programming hires into a poorly organized conceptual model will be a mess, and disheartening to the new person. Good conceptual models can be extended, interacted with, and built upon, and that which an end user may regard as a "feature," including features not yet thought of, flow naturally from the best models. So there are some knock-on benefits to the end user from good conceptual models under the hood, even if the end user doesn't see them or have an opinion about how intuitive they are.

HillaryBriss 11y ago
When I first read the article's title, I thought basically the same thing: this is about the concepts the programmers embrace. But it turns out to be about the concepts the end users must embrace. It's unclear to me how those two things are related. They _can_ be related, but it doesn't seem like they have to be. Not sure.
- andy_wrote 11y ago
  I think they don't have to be related. The article's example of tags and folders is a good illustration. "Tag" and "folder" models might have a clear enough implementation in the code; a programmer might wonder why they're both implemented but may have no trouble supporting both in principle. But the existence of both may be very confusing to the user. The cost inflicted on the coders is not coders' conceptual debt, but users's conceptual debt - certainly costly to coders as they have to support multiple patterns, but I think there is a difference. I guess when I think of coders' conceptual debt, I'd think of something that may be abstracted away at the UX level such that the user doesn't see it, but inflicts pain on implementors due to counter-intuitive patterns.

HillaryBriss 11y ago

When I first read the article's title, I thought basically the same thing: this is about the concepts the programmers embrace. But it turns out to be about the concepts the end users must embrace. It's unclear to me how those two things are related. They _can_ be related, but it doesn't seem like they have to be. Not sure.

andy_wrote 11y ago
I think they don't have to be related. The article's example of tags and folders is a good illustration. "Tag" and "folder" models might have a clear enough implementation in the code; a programmer might wonder why they're both implemented but may have no trouble supporting both in principle. But the existence of both may be very confusing to the user. The cost inflicted on the coders is not coders' conceptual debt, but users's conceptual debt - certainly costly to coders as they have to support multiple patterns, but I think there is a difference. I guess when I think of coders' conceptual debt, I'd think of something that may be abstracted away at the UX level such that the user doesn't see it, but inflicts pain on implementors due to counter-intuitive patterns.