I’d like to suggest some simple UX changes to increase the discoverability of badge titles.
Badges used to be a big deal on my old forum. Users would be proud of their newly earned “Contributor” badge, and would sometimes congratulate one another at the sight of it. After migrating to Discourse I re-granted the “Contributor” title to all of our existing contributors. However, hardly any of them seem to have picked up on the fact that they can use it as a title for an extra piece of flair.
I’d like to suggest two simple UX tweaks that I believe could result in a significant uptake in the use of badge titles.
First, I’d like to add an extra snippet of text underneath badges that have this special property. The titlehyperlink at the end would be the same as the main link; it’s just there to draw the eye to something a little out of the ordinary.
[quote=“erlend_sh, post:2, topic:27372, full:true”]
As an added measure, being able to assign a default title would go a long way. @sam
I’d like to force-assign the Contributor title to every user who receives the Contributor badge and does not already have a title selected.
[/quote]This is possible now, yay!
Meanwhile, the main topic stills stands. My users can still not fully appreciate what comes with a badge. Not only are Title-granting badges frequently overlooked, but users who attain Regular status don’t notice!
Can you take a screenshot of the title you’re talking about? I thought you were talking about something like your “Contributor” title:
… but that title is not clickable.
I don’t agree. Start a new topic for this if you’d like to push this further.
In short: While an on-hover display might be slightly beneficial to badge discovery, many users would surely find this annoying. There are extremely few (good) examples of modal boxes displayed on-hover in mainstream application, and for good reason: On-hover is not a guarantee of intent, and so the usefulness of the on-hover action relies entirely on how likely the user is to hover their mouse over that avatar when they do in fact mean to view the avatar. Every time that is not the user’s intent, it’s an annoyance, and a pretty disruptive one at that.
yes i’m talking about that title. The thing is that i “test” it on title like: Team or “co-founder” which are links but i didn’t notice that other title like “Contributor” or “Customer” aren’t link.
Any particular reason for that?
About your disagreemnt on hover display, i disagree
What i mean is that I understand and agree with your theorical explanation of on-hover state but it always dipend by different case and different site/ui.
I believe in this case it wouldn’t be that annoying for user since the avatar icon is quite out of the way of normal user’s mouse path. It will not popup wile writing or replaying to a post.
And it will be actually very beneficial for badges, user page, title, … in general to discover other user and create more connections between users.
Anyway, i will create a quick test-branch and open a new topic for this, so we can see directly if is more annoying or useful
well this is not trying to deciding, this is studying the habits of usual user’s behaviours and design an application and functionality based on those data.
Of course there would be some users that are out of the “common” behaviours nevertheless we need to make the title feature more intuitive for the majority of the users. At least at the beginning.
There is always time for corner case.
Sure a count near to the title dropbox can be helpful but:
select box already imply there are more options to select
Our main problem is that most of the people don’t even get to the setting page to change the title because they don’t know what is it. Or rather they know about title feature but they update with new badges much later because they were not aware they can use also that title.
So we need to figured out a solution before the user get to the settings page.
Start to work on this feature.
But I would need some Rails guideline here.
I figured out that the notifications are created from this file
which display badge name and link. The attributes that this file got are
In order to add the “this badge can be used as title” just to the badge that can be used to has title, i wanted to send another attr: allow-title
I believe the file that handle the attrs to send is
I added badge: @badge to the grant method to see what’s inside of badge but it doesn’t display nothing, not even an error.
I’m also having hard time to debug this part, i’m not rails devs so i really don’t know how to do it properly but i try with debugger, pry and byebug.
The console never stop.
I’m i looking at the right file? How can i properly debug this part?
I posted the wrong file link, now i correct it. Is actually badge_grant.rb not the spec file.
What i try want to do is to “update” the attributes that the badge has in notification-item.js
That badge now has: id, name, slug and username.
I want to pass to that badge var also allow_title attribute. Which i now it exist in the ruby part.
Once i have a boolean value for each badge that tell me if allow_title or not, is easy to add title link.
I’m not sure i understand your idea with the different css classes (do you want to give to each <span> the name of the badge as class name?) but with your or mine approach, i still need to know at one point, if the badge can be use as title or not.
And that’s something that has to come from the backend, as attributes, as far as i know.
I must respectfully disagree. Gamification or the feeling of having achieved something and being able to show that plays a big role for a lot of users. Badge/User titles are a very important thing for this group. It may sound strange, but it is a fact. Especially for the younger generation.
I definitely agree with @Lutz and that was all the idea about “improving badge title feature”
I agree also with @codinghorror, is not the best UX/UI solution.
But at the beginning of this post we thought it could be a good intermediate steps to move in the direction of make all badges more discoverable.
Since is difficult to make big changes in discourse, this would be a middle step.