Analysis style changes

[dav1312]

TLDR

I'm going to talk about a lot of possible style changes so here is a picture of all/most of them combined as a TLDR.

I'm also going to provide multiple css snippets with each idea so they can be tested if needed.

---

Inaccuracies

Problem

Right now, mistakes can have 3 categories: inaccuracies, mistakes and blunders, from better to worse.
The color scheme used doesn't really make much sense for inaccuracies. Blue is not a color that one would immediately associate with something bad happening, quite the opposite actually since it is usually used when something better than good (green) happens.

Posible solution

Use the standard color scheme for "bad" things. Yellow (inaccuracies), orange (mistakes) and red (blunders).
To make it easier to differenciate from a mistake, the color of mistakes should probably a darker orange.

css example

:root {
	--inaccuracy: 250, 168, 26;
	--mistake: 245, 117, 49;
    --blunder: 223, 83, 83;
}

.tview2 move.inaccuracy {
    color: rgb(var(--inaccuracy));
}
.tview2 move.mistake {
    color: rgb(var(--mistake));
}

#main-wrap .cg-custom-svgs circle[style="fill:#56b4e9;filter:url(#shadow)"] {
	fill: rgb(var(--inaccuracy)) !important;
}
#main-wrap .cg-custom-svgs circle[style="fill:#e69f00;filter:url(#shadow)"] {
	fill: rgb(var(--mistake)) !important;
}

.tview2-column > interrupt > comment.inaccuracy {
    color: rgb(var(--inaccuracy))
}
.tview2-column > interrupt > comment.mistake {
    color: rgb(var(--mistake))
}

.tview2-column comment.inaccuracy {
    border-color: rgb(var(--inaccuracy))
}
.tview2-column comment.mistake {
    border-color: rgb(var(--mistake))
}

#main-wrap .symbol.inaccuracy {
	color: rgb(var(--inaccuracy));
}
#main-wrap .symbol.mistake {
	color: rgb(var(--mistake));
}
#main-wrap .symbol.blunder {
	color: rgb(var(--blunder));
}

#main-wrap .symbol.inaccuracy:hover {
	color: rgba(var(--inaccuracy), .859);
}
#main-wrap .symbol.mistake:hover {
	color: rgba(var(--mistake), .859);
}
#main-wrap .symbol.blunder:hover {
	color: rgba(var(--blunder), .859);
}

---

Advice summary

The players are too close

Problem

The players are too close to each other, this makes it a little bit hard to look at.

Posible solution

Separate the players by a margin, a divider or both

.advice-summary__side {
	padding-bottom: 8px;
	margin-bottom: 8px;
}

Make the players easier to see

Problem

The players have the same style as other parts of the summary.

Possible solution

Make the player names bold and separate them a little bit from the summary.

.advice-summary .advice-summary__player > span,
.advice-summary .advice-summary__player > .user-link {
    font-weight: bold;
}

.advice-summary .color-icon::before {
    vertical-align: baseline
}

Inconsistent capitalization

Problem

The user, acpl and accuracy are all capitalized but the mistakes are not.

Possible solution

Capitalize them.

.advice-summary .advice-summary__error {
	text-transform: capitalize;
}

Order of elements

Problem?

This is maybe more of a personal preference, but I consider accuracy and acpl to be more general representations of the game, so I would put them at the top

Possible solution

Reorder to: Accuracy > ACPL > Mistakes

.advice-summary__side {
	display: flex;
    flex-direction: column;
}
.advice-summary__player,
.advice-summary__accuracy {
	order: -2
}
.advice-summary__acpl {
	order: -1
}

Duplicated elements

Problem

All of the elements in the summary appear once for each player.

Possible solution

There is a common way of dealing with this, that is, putting the text (accuracy, acpl, etc.) in the center and the values for each player on either side of the text.

---

Other changes

Move color on hover

Problem

For a regular move, the background color changes to blue and the text color changes to white, however, this does not happen with other types of moves.

Solution

:root {
    --regular: 155, 199, 0;
	--brilliant: 33, 196, 58; 
    --good: 93, 223, 115;
    --interesting: 240, 117, 225;
	--inaccuracy: 250, 168, 26;
	--mistake: 245, 117, 49;
    --blunder: 223, 83, 83;
}

.tview2 move.brilliant {
    color: rgb(var(--brilliant));
}
.tview2 move.good {
    color: rgb(var(--good));
}
.tview2 move.interesting {
    color: rgb(var(--interesting));
}
.tview2 move.inaccuracy {
    color: rgb(var(--inaccuracy));
}
.tview2 move.mistake {
    color: rgb(var(--mistake));
}
.tview2 move.blunder {
    color: rgb(var(--blunder));
}

#main-wrap move.brilliant.active {
    background-color: rgba(var(--brilliant), .169);
}
#main-wrap move.good.active {
    background-color: rgba(var(--good), .169);
}
#main-wrap move.interesting.active {
    background-color: rgba(var(--interesting), .169);
}
#main-wrap move.inaccuracy.active {
    background-color: rgba(var(--inaccuracy), .169);
}
#main-wrap move.mistake.active {
    background-color: rgba(var(--mistake), .169);
}
#main-wrap move.blunder.active {
    background-color: rgba(var(--blunder), .169);
}

#main-wrap move.brilliant:hover,
#main-wrap move.brilliant:hover index,
#main-wrap move.brilliant:hover eval {
    background-color: rgba(var(--brilliant));
    color: #fff;
}
#main-wrap move.good:hover,
#main-wrap move.good:hover index,
#main-wrap move.good:hover eval {
    background-color: rgba(var(--good));
    color: #fff;
}
#main-wrap move.interesting:hover,
#main-wrap move.interesting:hover index,
#main-wrap move.interesting:hover eval {
    background-color: rgba(var(--interesting));
    color: #fff;
}
#main-wrap move.inaccuracy:hover,
#main-wrap move.inaccuracy:hover index,
#main-wrap move.inaccuracy:hover eval {
    background-color: rgba(var(--inaccuracy));
    color: #fff;
}
#main-wrap move.mistake:hover,
#main-wrap move.mistake:hover index,
#main-wrap move.mistake:hover eval {
    background-color: rgba(var(--mistake));
    color: #fff;
}
#main-wrap move.blunder:hover,
#main-wrap move.blunder:hover index,
#main-wrap move.blunder:hover eval {
    background-color: rgba(var(--blunder));
    color: #fff;
}

Simulated hover over all moves at the same time using devtools

Add color to last move indicator

When a special move happens like a "brilliant" or "blunder", change the color of the last move. I think this is a nice touch that makes move stand out more.

#main-wrap:has(circle[style="fill:#168226;filter:url(#shadow)"]) .last-move {
    background-color: rgb(var(--brilliant));
}
#main-wrap:has(circle[style="fill:#22ac38;filter:url(#shadow)"]) .last-move {
    background-color: rgb(var(--good));
}
#main-wrap:has(circle[style="fill:#ea45d8;filter:url(#shadow)"]) .last-move {
    background-color: rgb(var(--interesting));
}
#main-wrap:has(circle[style="fill:#56b4e9;filter:url(#shadow)"]) .last-move {
    background-color: rgb(var(--inaccuracy));
}
#main-wrap:has(circle[style="fill:#e69f00;filter:url(#shadow)"]) .last-move {
    background-color: rgb(var(--mistake));
}
#main-wrap:has(circle[style="fill:#df5353;filter:url(#shadow)"]) .last-move {
    background-color: rgb(var(--blunder));
}

[schlawg]

When I want to distinguish between three different colors, I prefer that none be a combination of the other two. I understand that move classification is a spectrum but that doesn't mean the cutoffs have to map directly into a narrow band of the visible light spectrum. Sometimes it's hard to tell whether something is red or orange against various backgrounds. Perhaps more importantly, users are already used to inaccuracies being blue.

More colors on hover, last move, etc. It's too many colors. Hilite on hover is just meant to convey you can click something. Different hilite colors would make some sense if clicks on each color corresponded to different behaviors, but in all cases clicking just sets the board position.

Is changing board square colors worth the effort to ensure they can be distinguished (and don't look worse) on every board type? Do they add any information to the glyph?

Separation, capitalization, and reordering of the summary lines are good ideas, and would make a good first issue as well.

[dav1312]

Sometimes it's hard to tell whether something is red or orange against various backgrounds.

I don't know, I personally never had that issue. You can "separate" all 3 colors enough so they are easy to distinguish.

users are already used to inaccuracies being blue.

Beta/UAT?

More colors on hover, last move, etc. It's too many colors. Hilite on hover is just meant to convey you can click something. Different hilite colors would make some sense if clicks on each color corresponded to different behaviors, but in all cases clicking just sets the board position.

There is already a change in color on hover, my suggestion was just to make it consistent across all types of moves. aka, background color without transparency and white text.

Is changing board square colors worth the effort to ensure they can be distinguished (and don't look worse) on every board type?

This was already done for the current color. Some boards change the color to blue instead of green so they are easier to see.
It doesn't really look that hard to check if they look fine since you can easy change the board theme on lichess.

body.green square.last-move,
body.green-plastic square.last-move,
body.marble square.last-move {
    background-color: rgba(0,155,199,.41);
}

Do they add any information to the glyph?

No? I'm not sure I understand that question

[Vavo77]

please take consideration about interesting moves which are pink in color & dubious moves which are blue in colour. [in study annotation]
interesting moves are closer to good moves which are green & the blue colour is closer to the green, meaning that interesting moves should be blue..
& the dubious moves are closer to mistakes which are red or yellow + the pink colour is closer to red so dubious moves should be pink in colour.
Thanks

[dav1312]

I like pink for interesting moves, it is an interesting color, but sure, blue should be fine too
But I'm not sure about pink for dubious moves tho pink doesn't have a "bad" meaning.

[Vavo77]

?! (Dubious move)
Edit
This symbol is similar to the "!?" (below) but usually indicates that the annotator believes the move to be dubious[2] or questionable but to possibly have merits. The "?!" may also indicate that the annotator believes the move is deserving of criticism but not bad enough to warrant a "?". A sacrifice leading to a dangerous attack that the opponent should be able to defend against if they play well may receive a "?!". Alternatively, this may denote a move that is objectively bad but sets up an attractive trap.

!? (Interesting move)
Edit
The "!?" is one of the more controversial symbols. Different books have slightly varying definitions. Among the definitions are "interesting, but perhaps not the best move", "move deserving attention",[2] "enterprising move" and "risky move". Usually it indicates that the move leads to exciting or wild play but that the objective evaluation of the move is unclear. It is also often used when a player sets a cunning trap in a lost position. Typical moves receiving a "!?" are those involving speculative sacrifices or dangerous attacks that might turn out to be strategically deficient.

Andrew Soltis jokingly called "!?" the symbol of the lazy annotator who finds a move interesting but cannot be bothered to work out whether it is good or bad.
found this on Wikipedia
https://en.m.wikipedia.org/wiki/Chess_annotation_symbols

[dav1312]

Not sure what that is for but... ok?
In Lichess, inaccuracies (?!), mistakes (?), and blunders (??) have pretty clear definitions and they are very linear
An inaccuracy means you lost at least 10% of your winning chances, a mistake 20% and a blunder 30%

[TBestLittleHelper]

Well, the definition is clear on the surface. But here is a simple question to prove it wrong : is black's next move - d6 - an inaccuracy?

Computer eval changes from 0.0 to +0.8
In practice, in the master db: black wins 28% with d6 and "only" 21% with Nc6 (stockfish move)
d6 is also played much more frequently in the master DB.

The "proper" symbol here would probably "book move" or simply no symbols. I think it's hard to call this an inaccuracies, and I defently would not color the move red. You can find countless examples of inaccuracy, that are - quite frankly- not an inaccurate move. I am also sure you can find many examples of inaccuracy, that a human would call "mistake" or "blunder". A more accurate name for inaccuracies, is probably "might be a mistake, might be fine". So it's probably best to reserve the color red for more severe and clear errors. Such as blunders. And keep mistakes in their current orange form. That doesn't mean that blue is the perfect color either - but I think it's hard to argue that it's worth changing at this point. Better to focus on the other proposals you have (for example making them all capital letter's seems like a small good independent change)
{ At least focus on them first. And perhaps revisit the colors after the small stuff is cleared out of the way. No need to have a color debate block all your suggestions }

[schlawg]

One problem we face is that we're not designing this thing from scratch. You've got a hundred thousand users out there right now who think blue means inaccurate. Every time we change something like that it throws a lot of them for a loop. Brightening hilite colors on mouseover beyond the current extent is doable with a minimum of fuss, but it offers no real benefit that I can see and the implementor would need to make sure it whatever darkening/lightening function used looks good in all three themes varieties.

If we were going to futz with this now - we should get buy in from thibault, nojoke, 1vader, TBest, and others. More than one of them might feel this is a waste of time.

I personally could be convinced to at least try:

• Red as blunder - these values likely different based on theme
• Orange as mistake - these values likely different based on theme
• Yellow as inaccuracy - these values likely different based on theme
• pink as interesting - same as now
• greens are good - same as now
• we remove blue and use mute blue background for current move in the move list and brighter blue as a hover highlight color (for all move categories). Annotated moves in the move list that are highlighted blue will still show the glyph and the font color of their move classification.
• No changes to last move board squares.
• All changes to acpl summary are good. Player separation, heading bolding, reordering, capitalization - all uncontroversial.

That is what I would be willing to try, assuming someone like @Tbest, @nojoking, @brollin, who knows better signs off on messing with the move color spectrum. I'll welcome and tolerate a medium sized shit-show of complaints about inaccuracies changing color, but will keep a close eye on the volume of legit issues with difficulty distinguishing yellow/orange/red in all situations. The git rollback trigger finger will be itchy here.

[schlawg]

Keep in mind, the implementation above means I would actually remove the special highlight color for each move classification as it exists now in the movelist. The yellor/orange/red/pink/green background would still be there unless you hover (then it's always bright blue) or it's the current move (then it's always muted blue).

To further reinforce usage of blue as a temporal marker and navigation hint - the vertical line marker in the graph should probably be blue as well.

[TBestLittleHelper]

With great anticipation, I look forward to someone convincing the maintainer that we need a new settings panel, allowing all players to customize all colors! ( Alternatively, we should just be happy with the current status and allow extensions like prettier lichess worry about letting users tweak colors to their preference )

[dav1312]

You've got a hundred thousand users out there right now who think blue means inaccurate.

That is why I suggested the use of a beta program or user acceptance testing but I'm not sure if Lichess currently has those.
But even if they currently associate blue with inaccurate, the use of yellow/orange/red is so common that it shouldn't be hard at all for them to adapt.

will keep a close eye on the volume of legit issues with difficulty distinguishing yellow/orange/red in all situations.

I made some tests with some colors and they can be separated enough so they can be distinguished.
e.g #FFBA08, #E86717 and #E8172F

the vertical line marker in the graph should probably be blue as well.

The problem with using blue in the graph is that other elements use a (weird) orange (which IMO looks pretty bad) and using blue there would make it look even worse.

Alternatively, we should just be happy with the current status and allow extensions like prettier lichess worry about letting users tweak colors to their preference

I use Prettier Lichess but I don't like having to rely on 3rd party extensions just because the official website doesn't have the courage to push for mayor redesign changes.
Reddit still allows users to use the old style of their website with the old. subdomain for "legacy users". I bet the amount of new users that want to switch to the old design is minuscule.

[schlawg]

just because the official website doesn't have the courage to push for mayor redesign changes

I wouldn't say it's a lack of courage. It boils down to reluctance to shake things up that users have grown accustomed to without a good enough reason. Just think of analysis as gender reveals and inaccuracies as beautiful baby boys. I am told this helps.

[schlawg]

@dav1312

You know the CSS required. Why not make a pull request and see what happens? Some of your proposals seem uncontroversial, and I would like to hear if others have arguments for using primary (light blue) color for inaccuracies after mine fell flat.

[dav1312]

Most of the work presented here has been merged. The only parts missing are the controversial changes about last-move background colors and annotation color changes.