Option to display username instead of full name for registered users

[Giuse69]

Is your feature request related to a problem? Please describe. Users may want to keep private their full name and show publicly only the username/login name.

Describe the solution you'd like A configuration option to display username instead of full name.

Describe alternatives you've considered Template override but it may be better to have it OOTB.

Why do you think this is relevant to people other than you See first point for "privacy".

[nikosdion]

As I’ve said in the past, I’m against a metric ton of options controlling the output. It makes it really hard to maintain the software and they become a constant source of bugs, as I’ve found out the hard way with Akeeba Subscriptions in 2011-2013. If you want to change the output, Joomla gives a fantastic built in feature, template overrides.

Further to that, the assumption that usernames are private but full names are not is nonsense.

The user chooses both. If I expect privacy I don’t register an account as nikosdion with my real name, what kind of morons does that?! I would use something like white_rabbit_99 and full name Morpheus. BTW, that’s how privacy in public discourse is handled in Reddit for over a decade.

Moreover, on most Joomla! sites, the user can change the full name, not the username. So what you propose is even WORSE for privacy. Remember, a username (or, generally speaking, an alias) can be even more identifiable than someone’s real name.

[Giuse69]

You are the developer so you decide but let me say that your tone of reply is not kind, these are your opinions, others may have other opinions. There are people who register with their full name, pick a nickname (maybe different in every site) as username and do not want to appear publicly on forum with full name (known just by the administrator of the forum) but with the username/nickname and I don't dare to consider them all 'nonsense' or 'morons'. The option to show username or full name is also available in the other comments component. I already made the template override to show the username, but I thought it might be a proposal for improvement of your component since it is a very common use, I was wrong.

[nikosdion]

My tone was factual. Your tone, however, is confrontational, and you seem to make a number of false assumptions about how much thought I have put into it and why I rejected your proposal.

The fact that the username and name you volunteer to be used on a site with the explicit purpose of being used in conjunction with the content (comment) you volunteer to be publicly visible on said site means that the former cannot be considered private. This is tautological. It's not a matter of personal opinion or the subject of debate.

I also told you, the username on Joomla sites is immutable by default. In fact, there was no way for the user to change it themselves until Joomla 4.0 was released in August 2021. This is an objective fact, not a matter of personal opinion or the subject of debate.

Even with Joomla 4.0, the site owner has to explicitly set an option which would allow a user to change their username, something most site owners don't want to do for reasons that are not but tangentially relevant to this discussion. The objective fact you need to keep in mind is that users are unlikely to be able to change their username, BUT they can change their full name.

I had these OBJECTIVE FACTS on mind when I wrote Engage. Just like you, I initially assumed that showing the username would be the more privacy-preserving (not “private”) option. However, I then thought about the following.

A comes to submit a comment without thinking that by doing so using their user account their username and/or full name will be publicly visible — despite what four decades of BBSes, Internet forums, and Social Media has taught users (in this context, wouldn't that make someone a moron for thinking that this information is “private”?). Now that they see what is going on they want to walk it back. What are their options?

They cannot edit or delete their comment. Allowing unprivileged users to edit or delete their comments provides a conduit for toxic interactions. It's easy to bait someone to reply to something you wrote and then remove or change it after the fact to cast them in a negative way. So, that's not a good solution.

They cannot edit their username on most sites. At the same time, usernames are even more recognisable than full names. For example, everyone knows Mudge —that's even the name he used in the Senate hearing— but very few would recognise his legal name Peiter C. Zatko. So, using the username sounds like a bad idea because a. it is immutable on most sites and b. it is very likely recognisable.

They can edit their Full Name on all sites — even if the site owner has not provided a link to the profile edit page, you can still access it with a predefined URL thanks to how Joomla works. So, really, the only thing we can display that the user can also easily change to avoid public identification is the full name.

This is the first reason why I chose to display the full name instead of the username (and why the username is ONLY displayed to comment managers!).

The second reason is that one of the design goals in Engage was to allow Guest Comments. If we display a user-provided string as the guest commenter's “username” we create a problem: impersonation. A malicious person could post a comment on my site as username “nicholas” saying bad things to get me in trouble. Sure we can mark it as a guest comment but remember that people think of usernames as immutable because they are immutable on most sites. This is a strong cognitive bias and it will lead to toxic interactions. We cannot filter out known usernames because a. this is information disclosure which has both privacy AND security implications for the site and the user and b. a user by that username may be registered in the future with the consequences that i. the original guest commenter can no longer comment under their previous identity and ii. the new concrete user (which can be an entirely different person) can now continue posting in the threads of the previous guest commenter impersonating them. Again, this creates a problem of toxic interactions.

Having guest commenters provide a “full name” (which has less cognitive bias as a unique identifier in the minds of people — there are plenty of Thomas Müllers in Germany or Giorgos Papadopoulos in Greece, i.e. we're conditioned from a young age to NOT treat the name as a unique identifier for a person) and displaying it in a different way than that of concrete users solves this problem.

So, that was reason number two.

Which brings us to whether we want an option to change that because, sure, someone somewhere has a unique use case where usernames are actually mutable and less identifiable than full names. I do NOT dispute the point that these use cases exist. I dispute that the solution to that problem is adding an option.

As I explained, adding options adds unnecessary complexity. Moreover, if I start doing that with one visual element I have to do it with everything.

This would create three problems.

For starters, any necessary change in the layout becomes exponentially harder when you add options. Case in point, migrating this component from Joomla 3 to Joomla 4 was fairly “easy” as I “only” had to create the entire layout from scratch in Bootstrap 4 and then Bootstrap 5 (when Joomla 4.0 beta 2 decided to switch to BS5 literally overnight). And then I had to do the same with pure CSS so the interface would work with non-Bootstrap templates. This took a week. If I had a ton of options it would take 3 or more weeks as I would have to test all possible combinations of options.

Second, this is how you get the long-standing Joomla problem of having countless options in a daunting configuration page. This dissuades new users from using the software because it appears complex. It makes it near impossible for a site integrator to understand what is going on in the view template — and even when they do figure it out, their clients start wondering why the plethora of options no longer does anything. Also keep in mind that these options would have to cascade from component level to category level to article level making them completely inscrutable to all but the most experienced users (the same users who can much more easily create a template override!).

Third, your option in particular is incompatible with Guest Comments. This creates a conundrum. If we let people show usernames instead of full names and still have guest comments then the guest comments would all appear anonymous, attributed to “Guest”. If we treated guest comments differently than other comments —displaying full names instead of usernames— we create a jarring display with all sorts of display and usability issues. If we prevent this option to be selected unless guest comments are disabled we introduce a “magic action at a distance”, i.e. your settings in the component's, category's, and article's Permissions control whether a display option appears in the configuration interface. This is bad UX design. The final option is to treat this display option ALSO as a switch for guest comments which is not only bad UX design, but also an abysmal architecture in the backend as well.

As you can see, far from being an arbitrary decision, the current display of Engage is the product of rational thought and taking into account how the component will be used in the real world. Moreover, when dismissing your suggestion as “nonsense” I took into account both the fact that you falsely alleged that usernames are magically more private than full names (both can contain whatever the user wants; the latter can be more easily changed, therefore your premise is wrong) AND how your suggestion would interact with the guest comments feature.

So, again, my suggestion to use template overrides stands. The conundrums you introduce with your choice to display usernames instead of full names cannot be resolved in the generic, mass-distributed software case I have to support in the code I distribute but CAN be resolved for a VERY SPECIFIC use case you implement your site against — which requires template overrides.

If you disagree you can always put your code where your mouth is. The software is FOSS, distributed under the GPLv3. You can fork it, add all the options and changes you want, and distribute it yourself. You also get to maintain it. Eventually you will see all of the problems I described and you'll understand why Less Is More.