Hello,
in my community, the usernames might differ a lot from the given name. The results to a search also consider the given name, even though it is not displayed. If someone looks for the given name Robert and finds only @asdf2016, it is not be evident that this is actually Robert.
Hence, I suggest to add (if different from username) next to the username on the same line the given name in smaller letters. 
After 1 year, I eventually got the discourse dev environment with Vagrant running on my opensuse maschine. 
To realise the proposal one has to:
Settings.enable_names is activeI have no idea how these serializers work. The search result uses this one:
https://github.com/discourse/discourse/blob/master/app/serializers/basic_user_serializer.rb
include_name? is already there, but I don’t know how this is used.
To display the name, one probably has to change some lines in here:
It’s a magic trick to determine whether name should be included by the serializer. If it’s true, you can find that field in the JSON.
After that, Ember model and widget kicks in. Try console.log(u) in that function so that you can see what’s in the u. You could access name by u.name there. And you’ll need some class for colors probably.
There is a site setting for displaying order of username and name. You could check that site setting and putting the name there.
You might find this useful:
Thanks for your suggestions.
I tried so, but it doesn’t work:
There is no u.name. 
I made sure to have enabled names. In the rails console, SiteSetting.enable_names? gives true.
Er, you can amend , name right after the end of attributes :id, :username, :avatar_template. Not sure why it’s not there though.
Now it is working! The name is not included if BasicUserserialiszer#include_name? evaluates to false.
No, it’s not. But you should also check whether enable_names? is enabled on the client side
enable_names is two-sided? I thought it’s a global server-side setting.
Yes, you can find this setting in client side. See widgets/hamburger-menu for how to access site settings.
I got the option enable_names on the client-side working.
Unfortunately, the attribute :name in the serializer seems to cause issues that I couldn’t track down yet.
I could imagine that a database query has to be modified to select as well the name field.
hi! I just worked on this issue and submit a PR for it.
@rriemann thank you for all your re-search, it saved me lot of time 
Thanks! Could you please include a screenshot in your post of how the search looks with you PR added?
Right! I did the screenshot and forgot to include it
Here it is:
I found it nice and clean to just wrap the name in parenthesis but if we think is not so important information, we could also do it smaller.
If user didn’t give his/her name, nothing will be display.
I would suggest to change the design to:
or:
maybe without the title.
in any case, I like the differentiation by font-weight/color.
Absolutely, we should try to keep the display as consistent as possible with the site setting.
So as far as @designbygio’s PR is concerned, we’re saying go with the first example in @rriemann’s mockup, which does:
username Full Name
**username** Full Name
Still linking to username of course, but dropping the link styling, since the interactivity is obvious enough in the context of a search drop-down.
The second example in @rriemann’s mockup is a separate discussion and PR altogether. I think this is what we’re proposing:
enable names and display name on posts are enabled, and prioritize username in ux is disabledthanks for the feedbacks!
About style:
currently the username is not in bold.
@erlend_sh what you said is:
username in bold and blue color, name normal font-weight and grey color.
Is that correct?
Honestly, I’m not sure about blue + grey.
I try that solution but i personally didn’t like.
Is there any other place in the app where these style is already used?
As Sam said, i want to keep consistent with other style but i didn’t find any place where these style is used.
I would simply go for this style, no need for blue:
It is consistent and be very familiar.
