1. 14

  2. 8

    I’ve heard variants of point #2 before, and I cannot understand it at all. To some people, referring to someone as a user sounds vaguely demeaning, but to me, it’s the obvious term. One reason is that it has the appropriate generality–it lets you abstract over what’s common to the user of emacs, spotify, firefox, and lobste.rs. But also, for some pieces of software, no more specific term works. In a podcast app, you’re a listener, but what are you in emacs, or your terminal emulator? No term more specific than user applies, because the tool is open-ended and powerful.

    That said, I’d still recommend this post because point #3 is incredibly important.

    1. 6

      I have to be honest, I don’t find the ethical appeal of the first two points very compelling. I worked at a company where full time employees were, by policy, always called “team members” and I promise you this did nothing to encourage teamwork or deter anyone from screwing anyone else over. I’m not convinced that changing the name of a table, or even forcing everyone to call users some particular thing, is really going to change attitudes or policies.

      The third point I’m a bit more sympathetic to. I’ve seen a lot of different data models grapple with exotic relationships between human being, credentials, and role. But even then, I really don’t think the word “user” is to to blame here. You don’t want to, and shouldn’t, rewrite auth logic a bunch of times, so “user” usually resolves to the table that holds auth data, and that’s fine. Where it gets hairy is when you have a human who can be both buyer and seller in a marketplace kind of setup, or when you have multi-user subscriptions and some of what you can and can’t do falls out of what subscription you’re on. Or maybe you can have multiple. It can get messy. But if you step back and dream up the ideal design, I can almost promise you there’s still going to be a table that holds everyone’s login credentials somewhere and if you call that “user” or anything else it doesn’t really matter, “User” (plus other related things) is still the model that makes sense. The hard part here is the “plus other related things”.

      I’ve worked in a codebase where a single set of login credentials can have multiple “profiles”, it was implemented very badly. But the reason for it wasn’t that anyone said “hey, let’s make users exist in a hierarchy with themselves where only ‘roots’ have credentials and ‘leaves’ have preferences because the ‘User’ idea is just so good we want to double down on it” (it was bad).If you look at what functionality the product had to support at the time profiles were a feature no one would had said that.

      The issue was that initially there were no profiles. Then there was something akin to a “parent mode” and “kid mode”. Maybe when that happened someone should have seen the writing on the wall and made a correct auth/profile M2M. But either someone’s crystal ball was faulty or because it was decided there wasn’t time for that refactor, it didn’t happen, and we got a session variable that said what mode a user was in. Then “we need an arbitrary number of profiles per user” happened, it was decided that it was urgent, and a mess ensued. It’s regrettable, but that’s how iterative product development works, and I really don’t see how a. calling what was the “user” table anything else would have helped, or b. how you’re supposed to anticipate which of the many, many configurations of credentials/role/profile/group/subscription/etc is the correct one at the start of an iterative process. “A user is a set of credentials” sure seems to me like the natural starting point. Sometimes it’s all you end up needing, sometimes it’s not, but I don’t really see anything in this post that offers a better initial design that anyone could deploy without knowing what features a product team is going to produce in the future.

      1. 4

        Great post.

        The word ‘user’ invokes the idea of manipulation, of addiction. It suggests that people need this product without referencing the product’s responsibility to do right by them.

        One thing that I find hysterically funny is that the only other place the term user is widely used is in reference to illegal drugs. Meth, coke, heroin, these things all have users.

        Even if I don’t have a specific term for the people a product should serve yet, I say “constituents” instead of ‘users.’ This word choice reverses the role of dependence.

        This gets to the heart of why people feel that the term user is demeaning. It is demeaning in the same way that governments calling their citizens consumers is demeaning.

        1. 4

          A user is a person who uses your software, e.g.

          Are people on this app to listen to the radio? Then they’re listening, not “using.” Are they on here to talk to their friends? Then they’re socializing, not “using.”

          They’re using your software to listen to the radio. They’re using your software to socialize.

          The word ‘user’ invokes the idea of manipulation, of addiction. It suggests that people need this product without referencing the product’s responsibility to do right by them.

          I don’t think it does for most people. Why should it?

          The third section about the data model is about architecture and UI design; whether you call the people using your software a “user” or “constituent” doesn’t really strike me as very relevant. I do think there’s perhaps some points in there, just not related to the term “user” or thinking of people as “users”. These things are just matters of design, or features that aren’t implemented.

          1. 4

            Are people on this app to listen to the radio? Then they’re listening, not “using.”

            When reading that, my first thought was: sure, you can call them listeners, but of course you also have broadcasters/show producers, and you probably want your login system to work in a generic way so you can abstract over the difference. So I was ready to dismiss this as a pointless post, but the author’s later points are much better. Especially the data model getting messed up and the reflection on Netflix’s model with accounts and profiles as an example of how data modeling can be better.

            However, this is all mostly terminology and thinking ahead. No matter how you slice it, if you don’t know the roles your users will have (and many will have multiple, as the article points out: one can be both producer/consumer or admin/reader at different times), you are very likely to paint yourself into a corner. Bolting on a radically new role late in the process is almost always going to be painful.

          2. 2

            Perhaps this is a consequence of today’s pandemic of only thinking in terms of “use cases”. A user can/will …

            When modeling a lot of systems, one should differentiate between users of the software, and people/groups acting in roles in the problem domain. The first is concerned with access, permissions and aspects related to the use of the software, the latter with the activities of a person (or group) acting in a role (i.e. context) in the system being modeled.

            I suggest that the inability to differentiate between the two and to model both in code, is the real issue.

            1. 3

              I’m a little bit confused by your post, because your second paragraph pretty much describes how I would describe “use case”, so I don’t really follow your objection to it.

            2. 1

              I agree that naming and designing your day model is important, is easy to neglect and probably on average deserves more attention. However, I think this article assigns the blame for the observed dysfunctionality to a symptom instead of the cause. More deliberately/specifically naming and defining the data model around the users of your app isn’t going to make organisational dysfunction and architectural design mistakes go away.