Page MenuHomePhabricator

Improve highlighting display so it's compatible with 'Group results by page" preference
Closed, ResolvedPublic

Description

The 'Group results by page" feature doesn't work well with Recent Changes highlighting With this preference, when multiple changes for a page exist, only a summary line is shown, while the relevant changes are collapsed (users click a right-pointing arrow to expand the collapsed changes). Highlighting the summary line isn't logical, since different colors might apply to different changes hidden in the collapsed group. So summary lines are currently left unshaded, which means users with this option don't get the full benefit of highlighting.

Now that 'Group results by page' is becoming an option right on the RC page (T168513), it's even more important to fix the highlighting issue.

Solution

When in 'Group results by page' mode, the display will work as follows (for collapsed groups):

  • No highlight: When the collapsed group contains no highlighted results, the summary line is white.
  • Uniform highlighting: When the collapsed group's members are uniformly highlighted with a consistent color or color blend (e.g., all are yellow+blue), 1) the summary line also gets that color or color blend, and 2) one or more colored dots as appropriate appear in the left margin.
  • Mixed highlighting: When the collapsed group contains members that are inconsistent because they're either a mixture of highlighted and unhighlighted members or highlighted members of different colors, 1) the summary line is gray and 2) one colored dot for each distinct highlight color represented in the group appears in the left margin (to the maximum of 5 dots, one for each color represented). To be crystal clear, the maximum dot display is 1 each of blue, green, yellow, orange, red.
    • The gray highlight will use #DEE0E3 as background color (which is equivalent of using Base70 at 60% opacity over the white background).

When a group is expanded:

  • Each group member gets the appropriate highlighting and dots, as now.
  • The summary line retains the coloring and dots, as above (which will help users understand how the feature works).
InitialHighlightedHighlighted & expanded

The example illustrates three states for a list of recent changes with three groups representing (in order) the cases of "no highlights", "uniform highlights" and "mixed highlighting". Note that when highlighting is applied, the expand/collapse triangles are placed in a separate column to avoid conflicting visually with the dots.

Mixed vs. uniform highlight combinations. The "uniform highlight" group has been modified in the example below to illustrate how multiple highlight colors are represented differently for the summary line depending on whether they apply to all elements in the group (the summary is highlighted with their blend) or not (summary is highlighted with a neutral grey color).

Details

Related Gerrit Patches:

Event Timeline

jmatazzoni assigned this task to Pginer-WMF.EditedJul 17 2017, 7:37 PM

@Pginer-WMF, can you please add an illustration in here that shows all three of these results, along with layout specifications, etc.?

[Note that the "Mixed highlighting" above could have gone a different way: we could have made had a fourth category for groups that have a mix of no highlighting with one consistent color or color blend. And make that summary get the color of the consistent color/blend. But James liked this way better. I could probably be argued to the other position...]

Pginer-WMF updated the task description. (Show Details)Jul 18 2017, 10:38 AM

@Pginer-WMF, can you please add an illustration in here that shows all three of these results, along with layout specifications, etc.?

I added a sequence of mockups to illustrate the different states for Recent changes when grouped by page, including the three kinds of groups mentioned.
If those look good, I'll add some more details to the specification next.

@Pginer-WMF, thanks for adding the mockups. They look great. But I have a suggestion. Oddly, this suggestion will both clarify the proposal and point out the ambiguity that is built into it. :-)

Can you please make the group that is now just "consistent" yellow instead to be consistent yellow+blue (i.e., a green blend)? The ambiguous part is, the dots for both the consistent and the inconsistent summary rows will be the same: 1 yellow and 1 blue. But one summary row will be green and one row will be gray. Interesting, but not bad, I think.

One observation: on my monitor, which is just a generic LED and probably much less sophisticated than yours, the gray row looks a lot like the blue row. Is there anything you can do to distinguish these more?

Pginer-WMF updated the task description. (Show Details)Jul 19 2017, 10:09 AM

@Pginer-WMF, thanks for adding the mockups. They look great. But I have a suggestion. Oddly, this suggestion will both clarify the proposal and point out the ambiguity that is built into it. :-)
Can you please make the group that is now just "consistent" yellow instead to be consistent yellow+blue (i.e., a green blend)? The ambiguous part is, the dots for both the consistent and the inconsistent summary rows will be the same: 1 yellow and 1 blue. But one summary row will be green and one row will be gray. Interesting, but not bad, I think.

I added these as a separate example in the description. I think it could work well as a clarification. If you think it is too redundant, feel free to replace the former images.

One observation: on my monitor, which is just a generic LED and probably much less sophisticated than yours, the gray row looks a lot like the blue row. Is there anything you can do to distinguish these more?

In the standard color palette (M82), our greys have a component of blue. This was intentional to make them feel harmonious with our main accent color (blue) which makes sense on general UI uses but may bring grey a bit too close to the blue in our context (where colors are applied with a transparency factor for highlight). We can either (a) pick a darker grey from the palette (o a variant of it with some transparency) or (b) consider this case as an exception and go with a custom more neutral grey instead to avoid confusions. A comparison below:

Current light grey from paletteDarker grey from paletteDarker grey from palette at 70% opacityCustom neutral grey (#DDD)

It seems that "Darker grey from palette at 70% opacity" may provide a good balance: keeps alignment with the current palette while being light enough to not affect readability and the tone is distinctive enough from the light blue we are using.

@Pginer-WMF writes

It seems that "Darker grey from palette at 70% opacity" may provide a good balance: keeps alignment with the current palette while being light enough to not affect readability and the tone is distinctive enough from the light blue we are using.

Thanks Pau. Pick whichever you think works best and move this forward to RFP.

Pginer-WMF removed Pginer-WMF as the assignee of this task.Jul 20 2017, 10:52 AM
Pginer-WMF updated the task description. (Show Details)

Change 369819 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] [wip] Fix highlight display for enhanced mode

https://gerrit.wikimedia.org/r/369819

@Mattflaschen-WMF and @SBisson, next to the Watchlist stuff, this is one of our higher priority tickets. If we finish this, we will have completed all the major features required for beta graduation. (We still have to knock off all the blocker tickets, but we will have achieved the feature set we are aiming for, which is cool!)

Can one of you please review the code?

@Mattflaschen-WMF and @SBisson, next to the Watchlist stuff, this is one of our higher priority tickets. If we finish this, we will have completed all the major features required for beta graduation. (We still have to knock off all the blocker tickets, but we will have achieved the feature set we are aiming for, which is cool!)
Can one of you please review the code?

The patch is failing Jenkins. Which means it can't be merged and it's generally not the right time to review it. However, I have been reviewing it a few times already and I think it's getting close.

I have just tested it. It causes the nested lines bullets to be indented (not aligned with their parent). I don't know if that's what we want. See before and after screenshots below:

Before:

After:

It causes the nested lines bullets to be indented (not aligned with their parent).

Nevermind. I just saw that the mockups in the task are actually like that.

@Mooeypoo has a few things to fix in the patch then I'll re-review.

The indendation was the intended behavior according to the spec I understood, and reworking it is a pretty big mess because of the wya that the "enhanced" display works with big tables and "placeholder" cells.
@jmatazzoni looked at it on my computer yesteday and seemed to be happy with it.

I am fixing the ESLint error (upgrade made it grumpier than usual) and am looking again into the grey line issue.

The indentation doesn't bother me. But I did just remind Moriel re. this requirement, which hasn't been included yet:

Mixed highlighting: When the collapsed group contains members that are inconsistent because they're either a mixture of highlighted and unhighlighted members or highlighted members of different colors, 1) the summary line is gray and 2) one colored dot for each distinct highlight color represented in the group appears in the left margin (to the maximum of 5 dots, one for each color represented). To be crystal clear, the maximum dot display is 1 each of blue, green, yellow, orange, red.

There is also a small detail I wanted to mention. For groups there is a triangle that allows expanding them. The triangle should be the first element. That is, it should be on the left of the color indicators:

CurrentMockup

@Mooeypoo please note the above new requirement. I know there is some complication in the structure of this page. Will that be possible without heroic efforts?

@Mooeypoo please note the above new requirement. I know there is some complication in the structure of this page. Will that be possible without heroic efforts?

I'm not sure :\

We are getting the structure form the backend and the old way things work. I can look into changing this, but it is far from straight forward, and means manipulating the way we get it.

We are basically getting a finished table, whose structure is very awkward to work with for our purposes -- for the highlights I had to manipulate it to work, and that was a bit of an annoying mess. I'm worried that moving that cell isn't as straight forward either.

In any case, it now looks like it does without RCFilters, so I think we can treat this spec as a new requirement; I'll take a look and try to see how much work it is, but it's not straight forward. We might want to open a new task for it, and prioritize it now or later.

... one day we should rewrite the way this works originally so it's actually workable and looks like the way we want it to without so many "tricks" to get it there...

Change 369819 merged by jenkins-bot:
[mediawiki/core@master] Fix highlight display for enhanced mode

https://gerrit.wikimedia.org/r/369819

Etonkovidova updated the task description. (Show Details)Aug 31 2017, 7:59 PM
Etonkovidova updated the task description. (Show Details)
Etonkovidova updated the task description. (Show Details)Aug 31 2017, 8:57 PM
jmatazzoni closed this task as Resolved.Aug 31 2017, 9:04 PM

Checked in betalabs - the screenshots below illustrate

(1) "uniform" highlighting - all grouped records have the same highlighting

(2) mixed highlighting - the grouped changes do not have the same highlighting; the summary line has all highlighted dots that from grouped changes and is displayed in grey to indicate the mixed status.

(3) when one of the grouped changes does not have highlighting