Let's stop using bold / italics / underline to indicate tag counts

@BrokenEagle98: > Shinjidude said: > > Even if we could do...

2019-03-17T18:02:07-04:00

Shinjidude said:

Even if we could do this (it's certainly possible, but I'm not sure what performance impact it might have, or how much alteration would need made to the codebase), I think having 1-7 digits next to each tag in a list would be very visually cluttered, and not so helpful. It might be harder to read than the current situation.

Yeah, that's what I was thinking. I like the idea of having a general idea of where the tag counts are at on the meta-wiki pages, but the actual tag counts are unnecessary and cluttering like you said. Those interested can query the /tags endpoint, or better yet, a link can be provided somewhere on the page which will open up the /tags endpoint with the tags in the same order as on the wiki page.

I currently added such a link to the bottom of the List of animals wiki. There might be a better way to position or present such a link, but I went with that for now.

It looks like the following.

Current postcounts

Click here

@Shinjidude: > Danielx21 said: > > Here's another idea: is...

2019-03-17T17:03:50-04:00

Danielx21 said:

Here's another idea: is it possible to tweak Danbooru's system and have a way to get the tag count automatically?

For example, typing this:
[count:blue_bikini]
...resulting in this, the tag count of blue bikini automatically up to date:

9986

I'm just asking because tag counts automatically appears everywhere, so there must be some function in place to do this already.

Even if we could do this (it's certainly possible, but I'm not sure what performance impact it might have, or how much alteration would need made to the codebase), I think having 1-7 digits next to each tag in a list would be very visually cluttered, and not so helpful. It might be harder to read than the current situation.

@Danielx21: Here's another idea: is it possible to tweak...

2019-03-17T14:54:39-04:00

Here's another idea: is it possible to tweak Danbooru's system and have a way to get the tag count automatically?

For example, typing this:

[count:blue_bikini]

...resulting in this, the tag count of blue bikini automatically up to date:

9986

I'm just asking because tag counts automatically appears everywhere, so there must be some function in place to do this already.

@BrokenEagle98: > Shinjidude said: > > Personally, I actually...

2019-03-16T15:30:31-04:00

Shinjidude said:

Personally, I actually like the de-emphasized style better, as the "regular style" ones draw my eye automatically which makes it hard to read the text. It takes longer to read the de-emphasized ones, but to me the content of the text is more important than the magnitude of the tag being linked to.

After thinking about it for a bit, it probably would be better to put the de-emphasized version there by default, since that throws in HTML elements that allow the user to adjust those elements as desired with Custom CSS.

For instance, the following restores the size of the symbols but leaves the grey color, while also shrinking the size of the follow-on markers if they exist.

/*Adjust this to modify the symbols*/
#wiki-page-body li > .tn:first-of-type {
    font-size: 1em;
}
/*Adjust this to modify the follow-on text*/
#wiki-page-body li > .tn:nth-of-type(2) {
    font-size: 0.7em;
}

Both the symbols and the follow-on text can be removed entirely by setting the font-size to 0, or the color can be set to white so that it only shows up when the text is selected.

It'd be nice if somehow we could suppress the bullets in the lists and replace them with the symbols.

That would also be possible with ID'd headers, for instance "[nodtext]h4#stylized-other-text.[/nodtext]". All applicable header IDs need to start with the same ID text, such as "stylized", which translates to "dtext-stylized" when rendered by Danbooru.

/*Adjust the margin-left to move the position*/
#wiki-page-body [id^="dtext-stylized-"] + ul li {
    list-style-type: none;
    margin-left: -0.5em;
}

I did up the Tag Group:Technology wiki that way for anybody that wants to test. The "See also" section at the end shows the regular bullets, which demonstrates that it can be limited by section.

One limitation though is that no elements can lie between the header and the bullet list. I had to move a couple of "See also" text lines to the end of the bullet group, but they should probably have been there anyways.

I'd also suggest adding commas to the numbers in the legend just for ease of reading there too.

I'm guessing something like the following?

Legend:
◎ - 0 ... 100 posts
◔ - 101 ... 1,000 posts
◑ - 1,001 ... 10,000 posts
◕ - 10,001 ... 100,000 posts
◉ - 100,001 and beyond

Edit:

After thinking about it a bit more, I thought maybe putting the vertical bars and spaces inside the deemphasized sections would be better. That way users could remove all styling in its entirety if they wanted to with the following.

#wiki-page-body li > .tn {
    font-size: 0;
    line-height: 1em;
}

I did up the List of Animals wiki in that adjusted style. That style still works for me, so I'd be fine with doing that.

@Shinjidude: Personally, I actually like the de-emphasized...

2019-03-16T11:15:45-04:00

Personally, I actually like the de-emphasized style better, as the "regular style" ones draw my eye automatically which makes it hard to read the text. It takes longer to read the de-emphasized ones, but to me the content of the text is more important than the magnitude of the tag being linked to. It'd be nice if somehow we could suppress the bullets in the lists and replace them with the symbols. I'd also suggest adding commas to the numbers in the legend just for ease of reading there too.

@BrokenEagle98: I did up about a dozen wikis, using a...

2019-03-16T02:49:51-04:00

I did up about a dozen wikis, using a deemphasized and a regular style. I added the regular style since my poor poor coder's eyes were having to squint a lot to see some of those small symbols clearly. It's fine to deemphasize them when they are numbers since those are distinct and the human eye is trained to see them in most cultures, but those circular symbols are harder to discern.

Deemphasized style

Regular style

My own preference would be the regular style since they're easier to see, and because they aren't numbers, they don't conflict with the alphanumeric tags making them easy to ignore/filter out if desired.

@BrokenEagle98: > GabrielWB said: > > ...Yeah, I like it....

2019-03-15T23:43:47-04:00

GabrielWB said:

...

Yeah, I like it. Those symbols are intuitive, and I agree that several of the number categories are probably unneeded. I also like the bounding "|" on both sides when it occurs, as it still draws the eye to the tag without too much distraction.

You gave a good argument for small tags, but I also have one for larger tags. The larger a tag is, the less acceptable it is to have no wiki. Highlighting this helps draw attention to this fact where it is most needed. Granted one could just use the tags endpoint for that, however that entails a large never-ending quest which would put off the most dedicated users. However, taking care of a few entries in one of the List_of/Tag_group wikis is a lot more doable, especially in the spur of the moment, and gives a sense of accomplishment once finished.

I'd like to do up several wikis in that style, so that people can get a good idea of how it works for them. Sometimes it just takes getting used to something before the value of using it is discovered.

@GabrielWB: > BrokenEagle98 said: > > I like the way...

2019-03-15T23:09:16-04:00

BrokenEagle98 said:

I like the way you're thinking, however:

1. All emoji don't have universal support in all browsers.
2. No matter how much I stare at the legend, the symbols still mean nothing to me.
3. Consideration must be taken for users which may be partially or wholly color blind.
4. Those yellows are murder on my eyes... and that red-almost-black triangle is irksome...pick a color!

While I'm of the personal opinion that people who use devices/operating systems/browsers that don't support Unicode 6.0 from 2010 should really consider upgrading, I do agree with those other points. I didn't consider readability of colours for some people.

Using a number scale for scalability is pretty ingenious, but I do have to ask if it's needed to differentiate between the larger numbers (say beyond 100000 posts)
1girl is the largest tag on Danbooru with 2392256 posts. It will break ten million eventually, and it would certainly be a major milestone, but I don't think that it would be valueable to create a new category just for that when it comes to tag counts.

The great value of pages like list of blue tags is that it shows tags that are underused and I think that the focus should be put there. In other words:

evazion said:

I don't think tag size is that important to begin with. Big tags don't necessarily deserve more emphasis than small tags.

I would argue that tag size is important, but for the inverse reason, namely that small tags need more attention than larger tags to make them more used.

I still think that using symbols is far more readable than numbers, so I would like to propose this version by ~~stealing~~ taking inspiration from an idea posted by @Shinjidude back in 2012 in topic #8229

Shinjidude said:
A symbol to the right or left? Maybe one similar to those used for ranking by Consumer Reports? (○◒◓●) or (○◔◑◕●) A numeric value of some sort?

No more colours, and original symbols from Unicode revision 1.1 that should be supported everywhere.
It's pretty much a small pie-chart that fills up as a tag grows.

◎ - 0 ... 100 posts
◔ - 101 ... 1000 posts
◑ - 1001 ... 10000 posts
◕ - 10001 ... 100000 posts
◉ - 100001 and beyond

Which results in:

◕ | Blue background

◔ | Light Blue Background
◔ | Kinda Blue Background
◑ | Not Really Blue Background | No tags
◑ | Dark Blue Background | No wiki
◉ | Could be more Blue Background | No wiki

◑ | Blue bikini
◔ | Blue border

And the de-emphasized version:

◕ | Blue background

◔ | Light Blue Background
◔ | Kinda Blue Background
◑ | Not Really Blue Background | No tags
◑ | Dark Blue Background | No wiki
◉ | Could be more Blue Background | No wiki

◑ | Blue bikini
◔ | Blue border

@evazion: I really don't think there needs to be any kind...

2019-03-15T21:32:49-04:00

I really don't think there needs to be any kind of special formatting. I agree with everything said in the OP. It's just plain hard to read.

I don't think tag size is that important to begin with. Big tags don't necessarily deserve more emphasis than small tags.

I recently wanted to update tag group:attire, but the wiki was so hard to read, let alone edit, that I ended up removing all the formatting just so I could make my change. Other kinds of formatting would be even harder to edit. Their readability is a bit better, but still not great compared to plain text.

Danielx21 said:

If it's not too hard to find, I'd be interested in seeing any old discussions about that. I tried to search the forum for "dynamic rendering" or just "dynamic" but couldn't find it.

There was some discussion in issue #2755. In the extreme case you can have 1000+ tags on a single page (see list of original characters or topic #13868). Handling these worst case scenarios efficiently proved to be challenging.

That said, my Danbooru EX userscript does have a feature that marks broken links. The way it does it though (using Javascript to add the formatting after the page loads) is kind of hacky and wouldn't be the best way for Danbooru itself to do it.

@Shinjidude: > BrokenEagle98 said: > > That was the idea. I...

2019-03-15T20:28:58-04:00

BrokenEagle98 said:

That was the idea. I already have something that can process and stylize the links as they currently are.

Not sure about smaller numbers... but the following is how such would look, using the same Log 10 scale...

I haven't really been following this thread closely, but I will say this last styling looks so much better than anything else in the thread so far.

@BrokenEagle98: > 7HS said: > > Wouldn't this be an ideal use...

2019-03-15T20:25:48-04:00

7HS said:

Wouldn't this be an ideal use case for a bot? Wiki pages don't need to list tag counts that are up-to-date to the minute (especially if we go with some symbolic representation of popularity that doesn't include exact numbers,) they could be gone through and updated as infrequently as every week, and the updates could even be staggered - this page on Mondays, this page on Tuesdays, etc. - to reduce server impact.

That was the idea. I already have something that can process and stylize the links as they currently are.

I sort of wonder if people would expect smaller numbers to represent more popular tags, though, as if ranking votes in a contest/election. Perhaps all tags in each subsection of a tag list should just be ranked from highest (#1) to lowest (#2, #3, etc...) post counts, so there's less ambiguity about what the numbers represent.

Not sure about smaller numbers... but the following is how such would look, using the same Log 10 scale.

５| Blue background

７| Light Blue Background
７| Kinda Blue Background
６| Not Really Blue Background | No tags
６| Dark Blue Background | No wiki
４| Could be more Blue Background | No wiki

６| Blue bikini
７| Blue border

If you're talking about using numbers to order them by tag count, then there would be no need for numbers at all. However, such a scheme would drastically impinge the human lookup time for tags, as there's a reason that dictionaries are in alphabetical order. Also, how would one handle subtags?

@7HS: Wouldn't this be an ideal use case for a bot?...

2019-03-15T17:12:29-04:00

Wouldn't this be an ideal use case for a bot? Wiki pages don't need to list tag counts that are up-to-date to the minute (especially if we go with some symbolic representation of popularity that doesn't include exact numbers,) they could be gone through and updated as infrequently as every week, and the updates could even be staggered - this page on Mondays, this page on Tuesdays, etc. - to reduce server impact.

Also, I think BrokenEagle98's suggestions (in the form shown in the edit) look quite sound and unobtrusive.

I sort of wonder if people would expect smaller numbers to represent more popular tags, though, as if ranking votes in a contest/election. Perhaps all tags in each subsection of a tag list should just be ranked from highest (#1) to lowest (#2, #3, etc...) post counts, so there's less ambiguity about what the numbers represent.

@BrokenEagle98: > Danielx21 said: > > If it's not too hard to...

2019-03-15T13:33:09-04:00

Danielx21 said:

If it's not too hard to find, I'd be interested in seeing any old discussions about that. I tried to search the forum for "dynamic rendering" or just "dynamic" but couldn't find it.

@evazion did something similar, trying to colorize the links based upon the tag category. It was discussed on either Discord/GitHub.

Wikipedia and Danbooru could potentially have different circumstances (budget, server issues, how the software works or whatever), but somehow Wikipedia makes the red / blue links work.

They have the budget AND the manpower AND the servers. Danbooru pretty much is maintained by one guy and the budget only pays for a scant amount of servers.

Maybe this was discussed before, but I guess the red / blue links could be cached (instead of checking for blue / red links every time someone sees a page). When someone edits or creates a wiki page such as list of blue tags, the software checks for red or blue links upon saving, and keeps the style saved until the page is edited again. It could potentially be out of date sometimes, but that seems easily fixed by editing the page or just clicking "Submit" without doing any changes. The idea of having blue / red links has the added benefit of being easy to ignore in case people are not interested on whether a wiki exists or not.

Gauging by the lack of activity on GitHub overall and especially recently, it's very likely that any kind of "feature requests" will end up by the wayside.

In my opinion, there's this problem with bold / italics / underline, which is the same problem with emoji and numbers suggested above. I think they draw too much attention. Some people may care about the info presented but others may not, in which case the bold / italics / underline / emoji / numbers may be considered a nuisance rather than something helpful.

That's your opinion, so that's apparently your vote. I'm guessing that most people don't care, given the lack of protest in the several years such a system has been in effect.

@Danielx21: > BrokenEagle98 said: > > Dynamic rendering...

2019-03-15T10:13:58-04:00

BrokenEagle98 said:

Dynamic rendering has been attempted in the past, but the overhead is so intense that it makes some pages take forever to rend, and it would cause the server to slow down to mush for everybody else.

If it's not too hard to find, I'd be interested in seeing any old discussions about that. I tried to search the forum for "dynamic rendering" or just "dynamic" but couldn't find it.

Wikipedia and Danbooru could potentially have different circumstances (budget, server issues, how the software works or whatever), but somehow Wikipedia makes the red / blue links work.

Maybe this was discussed before, but I guess the red / blue links could be cached (instead of checking for blue / red links every time someone sees a page). When someone edits or creates a wiki page such as list of blue tags, the software checks for red or blue links upon saving, and keeps the style saved until the page is edited again. It could potentially be out of date sometimes, but that seems easily fixed by editing the page or just clicking "Submit" without doing any changes. The idea of having blue / red links has the added benefit of being easy to ignore in case people are not interested on whether a wiki exists or not.

In my opinion, there's this problem with bold / italics / underline, which is the same problem with emoji and numbers suggested above. I think they draw too much attention. Some people may care about the info presented but others may not, in which case the bold / italics / underline / emoji / numbers may be considered a nuisance rather than something helpful.

@BrokenEagle98: > GabrielWB said: > > ...I like the way you're...

2019-03-15T02:42:32-04:00

GabrielWB said:

...

I like the way you're thinking, however:

1. All emoji don't have universal support in all browsers.
2. No matter how much I stare at the legend, the symbols still mean nothing to me.
3. Consideration must be taken for users which may be partially or wholly color blind.
4. Those yellows are murder on my eyes... and that red-almost-black triangle is irksome...pick a color!

That's the problem with those geometric symbols... they don't carry a lot of meaning.

As an alternative, I propose using numbers based off a 10-based logarithmic scale (starting at 1).

５|Blue background - 23748

３|Light Blue Background - 404
３|Kinda Blue Background - 403
４|Not Really Blue Background - 9001
４|Dark Blue Background - 4250
６|Could be more Blue Background - 999999

４|Blue bikini - 9970
３|Blue border - 294

Those symbols are instantly recognizable, and it won't take long to get used to how much weight each number has. Also, for those worrying about running out of numbers, well that won't happen until Danbooru gets over 1000000000 posts, which is a little over 290 times more posts than Danbooru currently has. Hopefully in 1000 years from now, they'll have fast enough machines to facilitate a better scheme.

Edit:

A deemphasis on the rating numbers, removing the tag counts, plus "No wiki"/"No tags" markers.

５| Blue background

３| Light Blue Background
３| Kinda Blue Background
４| Not Really Blue Background No tags
４| Dark Blue Background No wiki
６| Could be more Blue Background No wiki

４| Blue bikini
３| Blue border

...or...

５| Blue background

３| Light Blue Background
３| Kinda Blue Background
４| Not Really Blue Background | No tags
４| Dark Blue Background | No wiki
６| Could be more Blue Background | No wiki

４| Blue bikini
３| Blue border

Optionally, "No tags"/"No wiki" could be shortened somehow, like "NT"/"NW", "†"/"‡", etc.

@GabrielWB: Another way would be to use emoji. If you dig...

2019-03-15T01:52:11-04:00

Another way would be to use emoji. If you dig beyond the usual Laughing Face and Poop emojis, there are a number of colourful shapes that could be used to indicate the category a tag belongs to.

For example:
❇️ = 0-500 posts
🔺 = 501-5000 posts
🔶 = 5001-50000 posts
🔷 = 50001-... posts

The first entries of the list_of_blue_tags page would then look like this:

🔶|Blue background
🔶|Blue bikini
❇️|Blue border
🔶|Blue bow
❇️|Blue card
🔶|Blue dress
🔷|Blue eyes
🔺|Blue fire
...

And hierarchies are still possible.

🔶|Blue background - 23748

❇️|Light Blue Background - 404
❇️|Kinda Blue Background - 403
🔶|Not Really Blue Background - 9001
🔺|Dark Blue Background - 4250
🔷|Could be more Blue Background - 999999

🔶|Blue bikini - 9970
❇️|Blue border - 294
...

And the great thing is that if we ever get dynamically updated post numbers, these symbols could be moved to that system so they would change dynamically.

Blue background - 🔶23748
Blue bikini - 🔶9970
Blue border - ❇️294
Blue bow - 🔶15354
Blue card - ❇️46
Blue dress - 🔶27648
Blue eyes - 🔷687920
Blue fire - 🔺1680
...

@BrokenEagle98: > Danielx21 said: > > Maybe Danbooru could do...

2019-03-14T18:05:34-04:00

Danielx21 said:

Maybe Danbooru could do what Wikipedia does:

If a wiki does not exist, links to that wiki could be red instead of blue.

I mean the software itself would automatically present links like this as needed.

Dynamic rendering has been attempted in the past, but the overhead is so intense that it makes some pages take forever to rend, and it would cause the server to slow down to mush for everybody else.

fossilnix said:

I'd be in favor of getting rid of the formatting because it's hard to understand and quickly out of date. If we keep it, it should be mechanically updated (it's far too much work for users to do by hand). and maybe instead of text styling, it'd be easier to read plain old numbers

Extra text for numbers would be far more distracting than text styling.

sometag - 1000
someothertag - 2000

Tables could be used...

sometag	1000
someothertag	2000

...however with tables you lose the easy ability to do hierarchies...

sometag		1000
	subtag	1000
someothertag		2000

...plus it looks terrible.

@Danielx21: > BrokenEagle98 said: > > The curly brace...

2019-03-14T17:40:37-04:00

BrokenEagle98 said:

The curly brace thing isn't that big a deal to me, but I can see how it might be to others. To be honest, I originally tried adding a No wiki to the right of the tags to indicate such, but at the time the use of the [tn] forced a newline and looked awful. However, that is no longer the case, so I could go back to using No wiki and No posts instead of the surrounding characters.

Maybe Danbooru could do what Wikipedia does:

If a wiki does not exist, links to that wiki could be red instead of blue.

I mean the software itself would automatically present links like this as needed.

@fossilnix: I'd be in favor of getting rid of the...

2019-03-14T00:24:01-04:00

I'd be in favor of getting rid of the formatting because it's hard to understand and quickly out of date. If we keep it, it should be mechanically updated (it's far too much work for users to do by hand). and maybe instead of text styling, it'd be easier to read plain old numbers

@BrokenEagle98: I think I've probably done most of the recent...

2019-03-13T21:44:29-04:00

I think I've probably done most of the recent such formatting, though I have tried to restrict its use to meta-wikis only.

As for myself, I kind of like the extra formatting for the tag size, as it gives a certain weight to the tags. Otherwise, all of the tags look the same, without any way to know which ones are more heavily used. Also, for the majority of such lists/groups, it is not as simple as as a search blue_* on the tags page.

Beyond the formatting used for tag size, which is admittedly more optional, the primary use was to identify fixup items, such as tags which didn't have wikis, had wikis but no posts, or had neither a wiki or posts.

The curly brace thing isn't that big a deal to me, but I can see how it might be to others. To be honest, I originally tried adding a No wiki to the right of the tags to indicate such, but at the time the use of the [tn] forced a newline and looked awful. However, that is no longer the case, so I could go back to using No wiki and No posts instead of the surrounding characters.

Example at: List of Blue Tags

Also, as far as the maintenance of those meta-wikis, I hadn't set up any recurring tasks for such, though it shouldn't be too hard to do so. I'm guessing that monthly should be often enough to keep them current?