[DigitalPoint] Profiles

[DigitalPoint] Profiles 1.0.0 beta 4

No permission to download
perhaps a sitewide admin option.....ive half come around to your logics by now but im still thinking of all the implications and not really sure yet
Ya, I suspect it’s going to simply be an option. Going to be less time coding that than it is to explain the logic about why it ended up how it is. If someone wants to have nothing differentiating usernames and display names, go for it. 😂
 
Ya, I suspect it’s going to simply be an option. Going to be less time coding that than it is to explain the logic about why it ended up how it is. If someone wants to have nothing differentiating usernames and display names, go for it. 😂
Maybe have usernames in capitals and display names in lower case or vice versa? Or use parentheses for display names? Or any other style variations/font weight/colour? I don’t know! Just a lot to think about I guess.
 
Ya, I suspect it’s going to simply be an option. Going to be less time coding that than it is to explain the logic about why it ended up how it is. If someone wants to have nothing differentiating usernames and display names, go for it. 😂
oh i mean a position toggle rather than an on/off tho...i think were saying...or in addition to the @ disable idk
 
Isn’t that how it already works? Display name is only shown if it exists. If display name isn’t set, it’s not shown. I think I’m totally not understand what you are going for… 😀
I'm inclined to defer to your reasoning since you've already been running this yourself, and the expected WT@F reaction from my site's users hasn't materialised (yet!), but this is how the logic works in my brain:

  • User has no display name set? Fine, just display their username. That's their one true name, no @ needed.
  • User has a display name set? Great, use it everywhere, it's their preferred name - but also show their @ Username with lower precedence/font size on their profile, beside their posts (the current behaviour)

edited to not summon @Username
edit 2: oops
 
Maybe you are overthinking it? It works like this:
  • All usernames are prefixed with @
  • If a user has a display name set, show that as “primary name” with username as the secondary bit of data.
Nothing more, nothing less.

I knew in the back of my head people would have issue with the @ prefix because it’s “different” and there’s no shortage of people who inherently dislike change. 😂
 
Certainly being overthought.

Usernames are taggable by @

Display names are arbitrary and not unique, so can't be tagged with an @

This is exactly how I would expect this to work everywhere else on the internet..
 
I understand how the addon works. I'm familiar with using @ as a username identifier elsewhere on the internet. I'm not sure why pointing out that it introduces literally scores of @'s per-page that weren't there before over the previous 26 years of my forum, and asking if it's possible to maybe - as an option - not have that happen is "overthinking", but OK.
 
I understand how the addon works. I'm familiar with using @ as a username identifier elsewhere on the internet. I'm not sure why pointing out that it introduces literally scores of @'s per-page that weren't there before over the previous 26 years of my forum, and asking if it's possible to maybe - as an option - not have that happen is "overthinking", but OK.
Yep, it’s super easy with a CSS entry. The @ addition is done with CSS, so could very easily override that with nothing or edit the template it’s coming from.
 
Yep, it’s super easy with a CSS entry. The @ addition is done with CSS, so could very easily override that with nothing or edit the template it’s coming from.
yeah i saw that when i went to count how many new @s are appearing on a random page (58), but where both the display name and the username are displayed, it makes sense to indicate which is the username so nuking the CSS won't help there?
 
yeah i saw that when i went to count how many new @s are appearing on a random page (58), but where both the display name and the username are displayed, it makes sense to indicate which is the username so nuking the CSS won't help there?
You could use something different to differentiate the username with edit to the same template. There’s really no limit when doing it via CSS… can have any prefix you want and/or any postfix you want. The @ is just what seemed logical to me… someone could prefix it with “Username: “ if they really wanted.
 
You could use something different to differentiate the username with edit to the same template. There’s really no limit when doing it via CSS… can have any prefix you want and/or any postfix you want. The @ is just what seemed logical to me… someone could prefix it with “Username: “ if they really wanted.
yes but i think it's only necessary to differentiate the username with a prefix at all when both the display name and the username are shown at the same time.

For example if I'm displaying recently online users in a widget then the display name they've chosen to use should be used - that's why they've set it, after all. If they have no display name set then show their username - there's no need to put an @ before it.

Which reminds me - the @ prefix doesn't seem to be getting applied to usernames in some widgets (New threads & Trending content for example)
 
yes but i think it's only necessary to differentiate the username with a prefix at all when both the display name and the username are shown at the same time.
I’m going to disagree until the day I die on that. I see huge value in consistency. So presenting the username of user A differently than user B is never going to be a good option, imo. I mean unless you want to go back to the MySpace days and the cluster**** those profiles were. 😂

I'd say pick a way to treat usernames and stick with that for all users, same for display names. If that "consistency" is simply applying nothing to both usernames and display names, that's certainly something you can do. Maybe the solution is to leave usernames "as-is" and just have a prefix for display names? That's going to be much cleaner and consistent for those that don't like change.

Personally that feels very confusing to me though. Imagining if I was a user of a site and some usernames are one way and just look like display names (nothing to show what's an actual username or not) and without being a power user and knowing to go dig through their profile, it gets confusing on how to address them in my mind (either within a message or even just sending a direct message). Like maybe I see them mostly as their display name... which now looks the same as most user's username if they don't have a display name set.

That being said, I'm certainly not the boss of your site, so if you want to present usernames differently depending on the user and/or if they have a display name set, you could do that if you really wanted to I suppose.

For example if I'm displaying recently online users in a widget then the display name they've chosen to use should be used - that's why they've set it, after all. If they have no display name set then show their username - there's no need to put an @ before it.
That’s how it works depending on how the widget was built. If something uses the <xf:username> tag with an overridden username (specifically it sets the defaultname attribute, it will respect that and keep whatever the override is). Widgets tend to do that because internally they are passing objects that aren't actually users. The "username" in those cases come from things like the thread table (latest poster). For that reason, they specifically set an override for the "username" without having the actual user entity. There's not a realistic way to automatically correct that without adding a ton of queries (every time something uses the override, then query the user table to see if there's a username that matches, etc.) it would also cause issues doing it that way.

TL;DR: basically when something uses the username override for the <xf:username> tag, that override is going to be left alone (it's an "override" already).

Which reminds me - the @ prefix doesn't seem to be getting applied to usernames in some widgets (New threads & Trending content for example)
The same basic reason as above... when something uses the username override, we don't touch it (and we also don't know if it's the actual username or not since the user entity isn't passed in.
 
Back
Top Bottom