I read a post recently of Dave Rupert lamenting that he can describe any digital interfaces as lists, details, or flows. This is, of course, an abstraction. Abstractions can be useful for reducing complexity and making things understandable. In code, they also can be used to reduce duplication and provide reason for limited responsibility, improving maintainability. But if everything is fit into a small number of buckets, it can certainly make it seem like there is a lack of diversity, a sameness to everything.
With any good abstraction, everything can fit into it with a certain level of mental effort. Some might be more willing to go further than others to make a given classification work. In code, too heavy abstraction can lead to a given abstraction trying to do too much, or conversely, functionality being limited to fit a simple concept of the abstraction.
Taken in this context, it would not be hard to find these abstractions in the other places Dave went looking for different types of interfaces. In video games, for instance, it’s easy to see a flow. Things such as characters, ships, and items that characters can be acquired can be presented as details (individually) or as lists (grouped together). Individual book covers might be harder to directly tie to one or more of those three words, but they are not dissimilar from simple web home pages, and certainly bringing in the other related words, particularly parts of speech, could be used to describe them. Graph databases are like items in lists with more complicated groupings.
I guess my point is that looking at things only as a given abstraction can give a simplistic view of reality. This can be both useful and problematic. This is mostly just some thoughts I had when reading Dave’s articles, but they hit on something I’ve been feeling encountering many people trying to abstract everything into small sets of options.