Proposal: unify category tag with corresponding new tag


(lid) #1

#Option 1
Unifying the new tag and the category tag can better communicate which category has new posts
In the current implementation you can see random “new *” tags in the list

The only down side that I can see with my proposal is the if the user click on the nested new tag
he will be taken to the forum with the filter of new. it is good if the user intend to only see new posts but less if he used the link to quickly jump to the category

Vs

#Option 2

I think the proposal above has a good potential to improve the UI, but if this might not be a viable solution then I am thinking of the following concept, where new tags are correlated with the parent category
this way the user can quickly identify that the new tag is most likely related to the color matching category
the only difference is that for the user to identify quickly categories with new is instead of relying on color to train the brain to look for the shape


Unread/new badge style?
(Kris) #2

Totally agree with option 1, have been meaning to do something like that for a while now.


(Sam Saffron) #3

We have to be careful with colors here, it may become unreadable with certain combos.


(Jeff Atwood) #4

I was thinking the interior bit could be the same color as the text, and then inverted. This would work on all category badges, but, we lose the blue = new association.


(lid) #5

We can possibly keep the blue is new association
just ignore the awkward spaces between tags in the examples below

I some what like this option too
it gives the feel of a bubble that call us to pop it by reading the category :smile:


(Jeff Atwood) #6

We can probably get away with suppressing the word “new” in this particular drop down @awesomerobot. That would help as well.


(Kris) #7

If we suppress the word new there’s no way to distinguish between unread and new

One could be grey and one could be blue, but grey already means something different on topic pages (unread old)

Is unread old even useful at all? maybe blue new and grey unread is just how everything works?


(Jeff Atwood) #8

Unread old is indeed useful. I wonder if we could just combine new and unread into one number for the purposes of this dropdown? Regardless of old unread vs. new unread, we have a fundamental too many numbers problem.


(Dave McClure) #9

Yes please!!

I feel like that distinction could be done away with completely…

It’s especially odd on the topic list with both bubbles appear side by side. Especially in that case it seems like it’d be better to just have one bubble with the total number of unread posts. If you feel the new vs old distinction is still important, I’d recommend to color the bubble grey if there are no new posts and blue if there are any new posts, but keep it one bubble.


(lid) #10

//discourse-meta.s3-us-west-1.amazonaws.com/original/3X/a/2/a25230710255e8f24a20da46004d257924d006ab.png

Personally I find having two different buttons to indicate that a category has new content some what confusing.

As a user when I see “7 new” I instantly know that there is 7 new updates or items
but then seeing it right next to another button with only a number “5” and no indication of what the number is for is confusing.

It gets even more confusing when on different scenarios I might see “7 new” but not the other button next to it. and sometimes I will just see a number.

My dilemma is that I think that the information provided in that box is actually useful as it is the only place I know where the user can quickly check categories with updates as well quantitative information.

I prefer having only a single “new status button”, and of course going with my first recommendation of unification.
a tooltip(title) can be used to provide some extra information as to how many topics and how many are unread posts.
“7 new topics, and 3 unread posts”

some questions:
With only 1 button to indicate new content of category, what should the number represent::
A.total number of new topics,
B. total of new topics + unread posts

In my opinion option B can be more confusing for the user if he expect the number to represent new topics.
he might see 8 as a number and when going to the category only see let say 1 new topic.

experimental concept
I have created a ruff experiment with the concept of having a single numeric button that expand on hover to show more details.
you can check the concept here
http://jsfiddle.net/lid0/8dPWX/embedded/result/

screenshot mouse over

or


(Trevor Williams) #11

I like that experimental concept you’ve done, but this only works well on desktop. I really don’t like the hover animation - it doesn’t feel smooth or natural and if you keep hovering over it back and forth it keeps moving however many times you’ve hovered with a lagged delay. With this effect, I don’t think its wise to use .animate in the JS, but instead use CSS transitions to animate for better speed and easier control.

Another thing I’ve noticed is that you won’t be able to use transparency with this method as the new and unread is overlapped with the 8 or * and not hidden using opacity so only solid colors work in this case.

The best way to do it is using data attributes instead of relying on the JS.


(lid) #12

Having 2-3 possible type of new status indicators
makes thing even more complicated.

  1. new topics
  2. new posts
  3. old unread (which by definition is not even new)

The question that need to be ask is:

does this UI need multiple new status buttons per category or a single new button indicator is enough?


@trevor you are making some good and correct points.
The code is a quick prototype and it is far from being optimized. And yes it is only benefit users with a mouse
as hover is not popular with touch devices.

I probably should have not set the html() of the elements on the animation. probably what causes the animation choppiness.

events should be handled better to avoid event queue when user hover multiple times quickly.

As much as a like this animation concept it might be an overkill and bug prone ,the same functionality could be achieved with a simple title attribute on the button element or just using custom tool tip with simple fade effect.

Some other issue with that implementation

  1. bubbles are on the same z-index as category. Expanded bubbles might get rendered behind other elements in the stack
  2. bubbles expand to the right of the category button in some cases it might get out of the window.
    And probably other issues :smile:

This version uses fade in/out effect and does not uses the html() method and also kinda fixed multiple hover issue
http://jsfiddle.net/lid0/8dPWX/6/embedded/result/



(lid) #13

#New suggestions
regardless of what is decided regarding how the new button should be, I have some more improvements suggestions

1.using icons, no words
2. Category with new get it’s own line
3. prioritize categories with new to top of the list.

#Why?
1st having the categories with new on the top of the list make sense, it allows the user to focus on categories with new content. in a predictable manner.

Having the categories with new on their own line, in my opinion allow a better eye scan and much less information to digest at a time top to bottom and not in a Z pattern of the categories, categories first then info on the side.

On the downside:
if there are many categories and they are all very active and each category get a line. It consequently will increase the overall length of the categories list. more chances of the user need to scroll down to see full list of categories.

@awesomerobot what are your thoughts


(Erlend Sogge Heggen) #14

I don’t understand why there needs to be NEW-notifications in this particular menu at all. It’s not a menu that accommodates a lot of data. I only ever saw it as a quick-jump menu. Personally I never use it, so I would love to see some stats for it.

You’re also promoting unproductive behaviour as the “check for NEW” can be done without moving away from the current thread; why do you need to know there are new posts in some category before you’ve finished with the one you were currently engaged in.


(Sam Saffron) #15

I don’t mind just merging the 2 numbers (by say adding them) and linking to the category latest page instead of unread/new. You can display the breakdown on hover for desktop.


(Erlend Sogge Heggen) #16

Frankly I don’t see why there needs to be any numbers at all in this menu. If you merge these two numbers I think that would just confuse users further with yet another number that they have to mouse over to decrypt.

Why does this menu need numbers?


(cpradio) #17

I’m in agreement here. I rarely use that menu to go to a category. I usually tackle the New/Unread from the global page (not category specific). I don’t really need the breakdown by category.


(lid) #18

If the argument is why we even need the numbers? Then the answer is simple.

Because the numbers are useful for the user. Take for example a mobile user. As that user try to find out what categories have new content. Are you going to go through every category to find how if it has new topics or posts?

When you can use a single finger tap and all the information is right there on a silver platter.plus this menu is accessible on every page.

The question that should be asked is not whether we need that information. We need to ask our self is there a better way without taking a feature away.


(Erlend Sogge Heggen) #19

If you want to get a good idea of which categories have new content, you should go to the /Categories page, which is only one extra click away through that menu, and it’s explicitly designed to convey all the information you need to choose which category to dig further down into.


(lid) #20

Thanks for the suggestion.it does sound like a good idea loading a full fledged page on a slow network connection on a small mobile device. and make lots of scrolling.

Compare to a sanppy solution in drop down menu with a single click

When you designing user experience / interaction you have to think as a user contrary to “I am the user”.