Actions and markup: Icons vs Tags

Continuing the discussion from A roadmap for Tags?:

The more I use Discourse, the more I’m confused by the multitude of icons marking topics and posts, placed in different corners, with some being just indicators, and others being actions.

  • Upper right corner of a post
    History icon - action on click
    Whispers icon - just an indicator

  • Lower right corner of a post
    a row of icons - action on click, includes a wrench menu

  • Upper right corner of a topic
    Wrench menu - action on click

  • Lower left corner of a topic
    Wrench icon - no action, just changes color on hover
    [Edit: this didn’t work just temporarily]

  • Below a topic
    Watching button - both an indicator and action

  • Right side of a topic
    Watching icon - both an indicator and action

  • After topic title
    Pencil icon - action on click

  • Before topic title
    Bookmark, Lock, Pinned, Solved icon - indicators

…and then there are tags.

Tags and icons compete with each other on the topic level. They are both markup systems, similar in what they do and one could easily be replaced by the other.
IMO, it would be cleaner if icons were restricted to marking individual posts, while tags, anything related to topics. It would provide a clearer functional distinction.

I think listing icons outside of their context is a bit too abstract. For example, there’s a wrench icon at the topic level and a wrench icon within a topic because they both configure admin actions on those respective levels.

Are there more specific issues you could address? For example which options have confused you in particular? Do you think some of the buttons at the bottom of a topic are too redundant? (I’m not sure the topic-level wrench there is necessary, for example)

Tags and icons are two very different things here.

Icons are the status of a topic (closed, hidden, solved, pinned, assigned).

Tags are meant to classify contents.

6 Likes

I understand which icon does what. I just think the use of icons in Discourse is very inconsistent. There’s no clear distinction between icons with actions and indicators.

The very point of the list in my first post is to show them without context, because this shows general UX principles or the absence of them.

I would argue that status is a subset of classification, so auto-tags could be used effectively for status as well.
OTOH, icons in Discourse are “confused” between being indicators or actions.

Ask yourself this question: when I see an icon, how do I know if it is just an indicator or should I click on it?

I guess I’m a bit confused here. Are you strictly talking about visual inconsistency or are there usability issues?

We use icons in different ways because they provide different levels of meaning in different contexts.

We’re intentionally creating two mental models here. “Closed” or “Pinned” isn’t descriptive of what the topic is about, so it’s a status and not a tag. Are there benefits to statuses as tags outside of the desire to not use icons for statuses?

You tell me. Did you click on an icon and become confused about its action or lack of action? E.G., Did you click on a lock in a topic title expecting it to do something? (not trying to be obtuse here, I’m really just not understanding what problem is in need of solving).

5 Likes

You’ll need to provide specific and concrete examples @BlackKnob. As in “I was browsing this topic, and then I tried to…”

Otherwise this is impossible to respond to in any sensible way.

4 Likes

Are you sure about this? If you are not seeing a menu open up on click you may have a bug somewhere.

Also, I think that if you really want this autotag everything feature in your forum, just post it to #marketplace. It’s a relatively easy plugin to create:

DiscourseEvent.on(:post_created) do |post|
  topic = post.topic
  if topic.closed?
    topic.add_tag closed_tag
  elsif post.wiki?
    topic.add_tag wiki_tag
  # and so on
end
8 Likes

Here are some examples of where I think Discourse has problems with icons.

disclaimer

I genuinely love Discourse as a platform and I know I can hide icons with CSS.
When I say something is confusing, I mean the UX feels ambiguous.

:lock: Padlock

this icon marks both a category with restricted permissions and a closed topic.

  • Having the same symbol for two different applications is already confusing. It suggests that a closed topic has restricted permissions. But if an TL3 user has no restrictions in the Lounge Category, why does he see a :lock:?
  • A user already know s/he can see a restricted category by… seeing it. Sometimes the best UX is none.
  • An icon preceding a title is a very strong signal to the user. So why is it so important that we are so explicitly warned that a topic is closed? Is it an indication, that it contains something offensive or improper? or has no useful information? Is the icon supposed to discourage us from reading it?

:bookmark: :white_check_mark: Bookmark and Solution

  • This is again a very strong signal to precede a title. Why is it so important? Why do we show a bookmark indicator, but don’t show another icon for topics to which we replied? This information seems secondary at best, and could be pushed to another column after the topic.

:pushpin: Pinned

  • this is the only icon I find appropriate to come before a title. It suggests “Featured” or “Important”. I can click on it to unpin it or pin it back. It’s a very natural action.

:crayon: Pencil

  • using it for version history on the top right of a post is strange. It’s not exactly editing of the post and the placement makes it really pronounced, as something as essential as date. A more logical place for version history would inside the :wrench: menu below the post.

:eye: Crossed Eye

  • the same icon is used for both “whispers” and “unlisting”. It’s confusing.
  • for whispers, the placement in the top right corner of a post seems arbitrary, especially that it’s just an indicator. This is an example, where I really expected to be able to click the icon. It would be more at home below the post, with other clickable icons, or inside the post actions menu (:wrench:).

:wrench: Wrench

  • easily confused with :crayon:. Configuration and editing are often interchangeable.
  • It’s a menu, even though the icon doesn’t indicate this. We already use :hamburger: in other places. In fact, the menu button on the top right of the Category View already uses the :hamburger: icon, while a similarly placed config menu in the Topic View is a :wrench:.
2 Likes

this:

should look like this:

or even better:

3 Likes

If they’re all topic status indicators (solved, bookmarked, pinned, closed) why separate them in the topics view?

:pushpin: is a functional icon. You can click on it to pin or unpin a topic.
The others are just indicators overwhelming a title. See my post above for further explanation.

Sure, it’s a state indicator which can be interacted with, whereas the others are only state indicators. There might be value in denoting visually that can be interacted with but the idea that it has to be split out past the topic title is pretty horrible.

It could also be outdented to the left of the current column so that it’s not in the mix with the others, that would reduce clutter whilst keeping all the state indicators together.

I saw the second example you edited in after my initial response, that space is currently occupied with tags, are you suggesting that tags and status indicators are now adjacent instead? That’s arguably more confusing than having one clickable status icon next to the rest.

While we’re bike-shedding I’ll ante up my two pence. IMHO if I were to change the look at all it would be to remove the float: left
status-icons

I’ll support anything that doesn’t make a topic title look like occupied by an army of emojis and prevents iconageddon.

does everybody disagrees with what I wrote, or do you think it just doesn’t matter?

We tend to make changes based on a consensus that there is change required and that doesn’t seem to be the case here.

I see what you’re getting at but I don’t it causes a fundamental usability issue, or even much ambiguity TBH.

3 Likes

I’ve experienced the UI for a long time so I’m not the best to evaluate how it might be for an uninitiated visitor. I have seen posts like “how do I find this?” and “I didn’t know that did that” but I can’t recall ever seeing a post about UX problems involving the Icons / Tags in the topic title lists. Not that anyone who has would make the problem known, but do you know of even a single user that has reported an issue?

That is not to say that a “I would design this differently” shouldn’t be able to be changed. Have you tried using CSS to style them more to your liking but run into problems that something like having a class value would solve?

2 Likes

Fair enough @HAWK.

All of my comments were made from a user’s perspective, where a friendliness of UI may be more important than the sheer functionality under the hood. A functional-but-not-friendly may not necessarily appear as an essential problem from a programmer’s point of view. Just because something works on the technical level and users don’t complain, doesn’t necessarily mean that it’s friendly.

I don’t see UI friendliness being discussed much on Meta. Everybody gets excited about the backbone changes, which is important, but so is a user’s perspective.
Discourse UI is excellent in many areas, but it needs (IMO) discussion on how to make it more consistent and friendly.

@Mittineague, I gave examples of icons being functionally confusing to me personally. I am a user, so in the future you won’t be able to say that no one has ever complained :wink:

2 Likes

Thanks for taking the time to go into more detail here and providing mockups

The problem with this is that topic statuses are somewhat infrequent relative to the total number of topics on a page. A new column takes space away from all topics. We could alternatively only show the icons after the title when available and not make it a dedicated column, but I’m not sure that putting the icons after the title instead of before is an improvement over what we have now.

I think dropping the iconography would almost always make these statuses harder to read. I still strongly believe that statuses need to be significantly different in appearance and placement when used with tags. Here’s a rough example with only 3 tags. We’d be simultaneously making it harder to read statuses and tags by combining them. A user would have no way of prioritizing one over the other when scanning the topic list.

To me pins and locks make sense at the beginning of topic and shouldn’t go anywhere. Solved/bookmarked could potentially be handled in better ways.

I think an alternative way forward might be to look at ways to handle individual statuses that improves upon them individually, rather than just assuming they should all be treated the same. For example, I don’t think it would be unreasonable to say that the solved checkmark on its own could be somewhat ambiguous. Maybe it should stand out more on its own as a badge…

Another example: maybe the bookmark icon just isn’t clear as literal bookmark (it’s kind of ugly too). Many browsers and email clients use stars now for bookmarking… maybe we should too (we used to have a “favorite” system that used stars in addition to a bookmarking system, but we’re divorced from that by a few years now)… would it be clearer as a bookmark in another location?

The friendliest UI in the world is worthless if it doesn’t work. You can’t pit the two against each other. It’s pointless and divisive. We have to find more ways to bridge the gap.

Please, discuss it as much as you’d like. Open-source software could certainly use more people talking about design. Things do tend to skew a bit towards engineering.

8 Likes