Tooltip to display parent category


(Manthan Mallikarjun) #1

What I have noticed is that when your post in a subcategory, all you can see is the subcategory name. For example, I have a category called marketplace and a subcategory called reputation. When you post in reputation, the category badge shows up like this.

http://puu.sh/a9E9n/a9b65ae1ed.png

One thing I would like to see is a tooltip (e.x. Bootstrap Tooltips) where when you hover over the badge, a tooltip pops up saying marketplace => reputation.

This would make Discourse a little more user friendly.

Let me know what you think!

EDIT: @Lid proposed an even better idea!

Please check his video demonstrating it below!


(lid) #2

+1 on the idea this will improving the ux.

There might be a conflict with current behavior, right now hover on a category button show the native browser tooltip with a full description.

###Option 1
Make the parent category portion show the category hierarchy in the native tooltip, leaving the subcategory as is with the category description

###Option 2
this option is less snappy then option1, is not perfect but I like it as a concept


(Mittineague) #3

Is there such a thing as draggable sprites?

Seems tooltips should be minimum. More content which might pose a problem, but I can’t see that being too much effort somewhere down the line.


(Manthan Mallikarjun) #4

The tooltip would replace the native tooltip and would show up immediately on hover instead of after a few seconds.

This also seems very interesting! Is probably better than a tooltip! +1!!!


(lid) #5

@Mittineague if you are referring to the concept in the video, then since I couldn’t capture the mouse cursor it may not be evident but the expanding occur on mouse hover on the smaller bar. No dragging involved

update: actually draggable version can be good for touch enabled devices. where there is no mouse to hover with.


I am not sure I understand you completely but I will share this:

I was actually investigating today the affect of repeating string attributes on memory, cause I did notice that if for example you scroll down the topics list there will be many category buttons added to the DOM ( document )

So I was thinking does every time a category button is added do we add a full category description over and over to the memory.

I tested the hypothesis on chrome by observing memory and objects allocations ( Dev tools)
The test included setting the title attribute of over 10,000 elements in the document with a long string

$("a").attr("title", "IMAGIN_HERE_A_RANDOM_LONG_STRING_SIZE_2016_BYTES");

From my not so scientific test, I have concluded that chrome is actually smart about it and the DOM is setting the "title " attribute of all the selected DOM elements by reference to the string. which make not much difference if title is set to 5 chars or 100 chars or more, under normal use cases.

It might not always be the case (bad code) , for example if the string we set can be the same but might not have the same reference, that can happen we pull that string dynamically everytime we are asked to generate the button, which I don’t think will be the case as it is inefficient anyway.

It is appear that there are much worst memory usage on Discourse when loading topics item in the list.
@sam after V1 may be it will be worth looking on improving that. Right now I can observe about 3mb on each “load more.” on chrome 35

It might not big issue ( may be on really limited memory devices) , Because on a normal use, user is unlikely to load more then a few pages.
It is interesting to know why there is so much new object created is that a bloating the ember.js introduces?