The end of Clown Vomit, or, simplified category styles

(Jerry) #101

I don’t remember the colors of all the categories, but whenever I load the homepage here on Meta, I scan the page for the first UX post, note the color (I know by experience that it’s black) and then scan the rest of the page for the same color. I use the colors cues all the time.

They make even more sense on our forums, where the four categories we use have very specific colors our members have been seeing for 10 years now.

1 Like

(Jeff Atwood) #102

Only if they are completely incapable of using CSS in any form? I guess I’d say this is just plain not true.

Or maybe I am misunderstanding the point you are trying to make?

(I’d also point out that a lot of forums do in fact “look like” phpBB, most of the ones I see on the Internet do. Which is why the default design needs to be good, and clear, and prevent people from hurting themselves and their audiences with magentas and greens and so forth…)

0 Likes

(Jerry) #103

Burned indeed. Doesn’t change what I was saying though, that’s how I do it.

(Plus, for my defence, I have keratoconus and hadn’t my contact lenses when I wrote that, and the bar doesn’t help at all to make the distinction. On my non-Retina screen, the bar is much much smaller and that purple looks like black to me.

1 Like

(TechnoBear) #104

The point I was making is that I can distinguish colours at a glance, which is quick, but words I can only distinguish by reading them, which is a slower process. I also said I was speaking personally; this is my experience, if nobody else’s. However, I suspect anyone with mild visual problems or perhaps dyslexia would also find the colour cues valuable.

And yes - this page is full of words, which I can read. That does not mean I can read them as easily as the next person. As you’re not in a position to judge the level of difficulty which I experience, I’m afraid I’ll have to ask you to take on trust the fact that distinguishing categories by reading names is a slower and more troublesome process for me than distinguishing them by colour.

6 Likes

#105

I can’t do that for here. But I know the colors at my “home” discourse installation.

4 Likes

(Lowell Heddings) #106

You can definitely use CSS to customize things. My point is that the markup is changing in ways that make putting the style back difficult, some people want columns that have been removed, and others don’t want some of the columns that are there. I just keep reading topics where people want this or don’t want that, and it seems like nobody really agrees.

The selector for the top menu works really well, you can choose what you want there, and in the order you want. It gives people freedom to customize. Perhaps that type of selector could be enabled for the columns – that way if somebody doesn’t like the avatars, they just remove them from the list and they disappear from the topic list. (I’m not sure how difficult this is)

The other thing that could probably happen more easily is to have an easier way to override the templates for the important things without having to use a plugin. So you go into the Customize editor and the current template shows up, you click on topic list item (or whatever element you wanted to modify), and you can make little changes to the markup.

By template I mean this stuff… like this is the one for a topic list item.

<script type='text/x-handlebars' data-template-name='list/topic_list_item.raw'>

<td class='main-link clearfix' colspan="{{titleColSpan}}">
  {{raw "topic-status" topic=topic}}
  {{topic-link topic}}
  {{#if controller.showTopicPostBadges}}
    {{raw "topic-post-badges" unread=topic.unread newPosts=topic.displayNewPosts unseen=topic.unseen url=topic.lastUnreadUrl}}
  {{/if}}
  --- snip ---

The only thing with this is that you’d need a way to easily load the original templates in case something breaks (which is likely). Maybe a URL like http://forum/?disablecustomtempates=1

This would obviously not be useful for everybody, and the average person shouldn’t be mucking around in there. But then again, the average person shouldn’t be mucking around in a WordPress theme file either, so it’s not really different.

This would allow much more powerful theme support.

I’m not saying that discussion is bad, or that you don’t need a good default theme. You do. It’s good. I just think Discourse has been adopted widely enough at this point that you can’t make everybody happy with a default theme and a few CSS changes. Maybe it’s time for some more advanced and supported customization options.

I can’t disagree with the fact that almost all forums look like their default…

But that’s because modifying a phpBB forum is (or at least was) a nightmare. I actually made a custom theme for one a lot of years ago. Just awful, and then you need to do a security update and everything dies.

WordPress, which does provide a (relatively) easy and supported way for people to change the themes and customize everything, is another story.

How often do you see a site that people actually visit that is using the default theme? Almost never.

[edit] This probably belongs over on this topic instead.

4 Likes

A more robust ecosystem for creating, sharing and modifying themes
#107

LOL, good example. It’s really tough to assign an idea to a color. And imagine if you are a forum user in the future that visits several Discourse forums (since the platform exploded in popularity), and they all uses different colors for the same/similar categories. Still don’t really get the point of the colors. Will it be possible to assign an icon if you want instead?

0 Likes

(Jeff Atwood) #108

I suspect it would be easier still for you to distinguish them by glyphs or icons.

Using color as a primary method of distinguishing “different” is super problematic once you get past about 10 things that you need to tell apart; I’d say color starts to be a problem at around 5 things to tell apart. Which is why I think it’s a mistake for the default design to rely so heavily on color, and one of the (many) reasons why we are de-emphasizing it.

Some other relevant images:

versus

And

That’s just from stuff I happened to encounter today. None of this was cherry picked.

2 Likes

(cpradio) #109

Why is the header no longer sticking to the top of the page when scrolling through a topic?

I guess the only way to add glyphs to categories is using the [href=/c/ux] syntax?

0 Likes

Header sometimes not sticking to the top of the page
(TechnoBear) #110

I’d be happy to test that idea, but I very much doubt it’s the case. Over twenty years of living with this condition has given me a pretty good understanding of what works for me and what doesn’t. Please don’t presume to know better.

Colour information is simple to process; it’s either present or not. Glyphs and icons, like words, require more processing. A familiar icon which has an association with the thing it represents - such as a magnifying glass for search - is OK. I’m not sure what kind of glyphs could be used to readily distinguish PHP, Ruby, General Web Dev, Marketing, etc.

Again, it’s my experience, but doubt I’m alone.

5 Likes

(Jeff Atwood) #111

I have some ideas:

But you are right, you are the expert on you.

0 Likes

(cpradio) #112

Ugh. Those are logos not “glyphs” (well except the last one — just an image?). :smile:

Plus if you thought the background color was noisy, can you image those next to each category? I can’t. I’d much rather have the solid background color (of which I know is possible via CSS customization – so we’re good there).

2 Likes

(Jeff Atwood) #113

Seems to work OK on Stack Overflow:

1 Like

Cleaning up category badge language in the category drop down
(cpradio) #114

That is a significantly different layout though… There is a lot breaking it up. List it in a column and have 30-50 (typical number of topics in a given view) of them and let’s see what you think about it :wink:

2 Likes

(Jacob Chapel) #115

They also have blocks around them to coordinate the image with the text. Which seems to be everyones major complaint about the bar.

3 Likes

(Dean Taylor) #116

I actually really like the images idea a lot for categories…

However keep in mind that the vast majority most popular tags on StackOverflow don’t have images influencing the UX:

2 Likes

#117

I like it. Makes sense with forums with a lot of colors and categories. But we only had a few categories and we used it to our advantage and mostly used variations of the same color.

A setting to switch between the old category styling and new would be a nice feature.

1 Like

(Sam Saffron) #118

I think we can all stop arguing now.

I tightened up the “bar” style, cleaned up a bunch of styling and made the base styles very flexible.

How flexible you ask?

This flexible:

Or you can have.

The markup is much cleaned up as are the 2 biggest pain areas that the bar design had:

with this bonus

So time to move along, nothing to see here…

@awesomerobot it is super trivial to add a “square” style, would love if you wired that option in, I think it is my fav of all styles :slight_smile:

Clown hugs everyone ?

23 Likes

(Jacob Chapel) #119

The squeaky wheel gets the grease.

How hard was it to wire up the config like this? Would be nice to abstract this a bit so we could add our own styles (through a plugin perhaps) that people could install without explicitly having to use CSS directly or the customize panel. Thinking also beyond category badges, could be useful for other areas where an element could have different major styles to it.

1 Like

(Daniel) #120

The badge with the bar styling is a bit messed up in the category list on mobile. There is a float: left that needs removing on the .badge-category text. It’s making the text wrap after the badge background element. Also, I’m not sure what the extra margin was for, so removed it.

.category-list-item th .badge-category {
	float: none;
	margin: 0;
}

I’m not familiar with extending Discourse so can’t help with the additional built in style but I’ve quickly created the CSS customisation for square category badges using the bar style as a base.

.badge-category-parent-bg, .badge-category-bg {
	padding: 0;
	margin-top: 6px;
	height: 12px;
}

.badge-category-bg {
	width: 12px;
}

.badge-category-parent-bg {
	width: 6px;
}

.badge-category-parent-bg + .badge-category-bg {
	width: 6px;
}

.list-controls .badge-category-parent-bg, .list-controls .badge-category-bg {
	margin-top: 10px;
}

.list-controls .category-dropdown-menu .home {
	margin-left: 12px;
}

.list-controls .category-dropdown-menu .cat {
	margin-left: 4px;
}

.list-controls .badge-category, .list-controls a.badge-category {
	padding-left: 6px;
	padding-right: 6px;
}

header .title-wrapper .badge-category-bg {
	margin-top: 0;
}

A couple of additional rules for mobile (with the first one to fix the category name wrapping to the next line):

.category-list-item th .badge-category {
	float: none;
	margin: 0;
}

.category-list-item th .badge-category-bg {
	margin-top: 9px;
}

In each appearance, the margin-top of the badge background element has to be (h - 12px)/2 where h is the height of the badge text element (including padding and margin) and 12px is the size of the badge squares.

The sibling selector is used to split the subcategory badge in half.

Screenshot for the curious:

4 Likes