@Mooeypoo I just noticed something else, which prompts a question: it seems the settings can be saved only for the tools that are in the new UI. I.e., I don't seem to be able to save number of results, time period, namespace or tags. Is that because it's hard or we just forgot?

If it's hard—and if the work going forward to integrate these tools will solve the problem naturally—then I'm not sure it's worth it to do a lot of work for an interim fix. But if it's not hard, then incorporating them in the saved settings might be a good idea.

Answering some:

Down-facing arrow

Pau's design on the prototype shows a down-facing arrow on the Quick links menu. That makes sense to me.

Default message in the menu

When the user has not yet saved settings, the prototype shows a little message encouraging the user to try the feature. I like this idea. Please use this text: Save your favorite tool settings to re-use them later. See prototype for design.

Disappearing bookmark

When the user can't save new settings (for whatever reason), currently the bookmark icon disappears. This is less than ideal, I think, since users may want to make a setting but not realize how to get back the bookmark. They'll just think it's broken or that they imagined it. Better would be if the bookmark would be grayed out when not available.

We need to add those in.

Too much space between menu items

In the Quick Links menu, items are separated by about 40 vertical px. In Pau's mockup, it looks more like about 30 px.

I can fix that, but this is an OOUI styling for all buttons and menu items. I discourage changing this from the standard design unless we really insist on it.

"Unset as default"

There is no such word as "unset." (I find it unsettling!) How about "Remove as default" or "Remove default".

Ha, I thought I saw that in the design, but wasn't sure. This is a trivial change of the message.

Rollover for long names?

The menu is making room for names of about 29 characters before they're truncated. Which seems sufficient (English could do it in less, but it's good to leave room for German et al.). Still, didn't we want to show the full name as a rollover?

I'll verify, it should be there, but may have been an oversight.

In T164861#3249208, @jmatazzoni wrote:

@Mooeypoo I just noticed something else, which prompts a question: it seems the settings can be saved only for the tools that are in the new UI. I.e., I don't seem to be able to save number of results, time period, namespace or tags. Is that because it's hard or we just forgot?

If it's hard—and if the work going forward to integrate these tools will solve the problem naturally—then I'm not sure it's worth it to do a lot of work for an interim fix. But if it's not hard, then incorporating them in the saved settings might be a good idea.

In T164861#3249208, @jmatazzoni wrote:

@Mooeypoo I just noticed something else, which prompts a question: it seems the settings can be saved only for the tools that are in the new UI. I.e., I don't seem to be able to save number of results, time period, namespace or tags. Is that because it's hard or we just forgot?

If it's hard—and if the work going forward to integrate these tools will solve the problem naturally—then I'm not sure it's worth it to do a lot of work for an interim fix. But if it's not hard, then incorporating them in the saved settings might be a good idea.

That's correct; the saved filters are only for the filter area + highlights. It wasn't implemented with the other filters at all, mostly because it will complicate things very much.
If we want to implement this, we should start it as a new task - it would require some thinking on how to preserve the values outside the filter list while allowing for normalization... The fieldset can (and does) include things that can be relatively arbitrary between wikis, so we need to find a way to store its results in a consistent non-rigid manner that still allows us to compare the current query to the one stored.

Not impossible, but not straight forward at all, either.

@Mooeypoo , I added a new item to the "Tweaks" above: No disappearing menu It's pretty much a corollary of "Default message in the menu," but I wanted to make that explicit. (BTW, I went over these changes with Volker, who agrees.)

Thanks for compiling those @jmatazzoni, I did a similar list also to identify design specs that may help, and I plan to add next to the tickets.

From your comments I agree with all except one:

Disappearing bookmark
When the user can't save new settings (for whatever reason), currently the bookmark icon disappears. This is less than ideal, I think, since users may want to make a setting but not realize how to get back the bookmark. They'll just think it's broken or that they imagined it. Better would be if the bookmark would be grayed out when not available.

Saving makes sense after customising the filters, and not much after loading a set of filters or saving a new one. Making the action appear as the user modifies the filters helps to communicate they can do something new, and hiding it when it is not relevant keeps to focus on the relevant information. This is the same we do with the trash can icon: when you clear the filters, the trash can icon disappears because it does not make sense to clear the filters where there are none. Similarly, the "restore defaults" action is shown only when the active filter area is empty.

I'd recommend to identify if the proposed approach is problematic (e.g., we still get requests to save filters after providing the option, we observe issues during user research, etc.) before raising the prominence of the save action.

Change 353204 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] RCFilters UI: Add down indicator to SavedLnksListWidget button

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

Change 353205 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] RCFilters UI: Add tooltip to saved links items

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

Change 353206 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] RCFilters UI: Add a placeholder to SavedLinksListWidget when it's empty

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

Change 353204 merged by jenkins-bot:
[mediawiki/core@master] RCFilters UI: Add down indicator to SavedLinksListWidget button

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

Change 353205 merged by Sbisson:
[mediawiki/core@master] RCFilters UI: Add tooltip to saved links items

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

Change 353206 merged by jenkins-bot:
[mediawiki/core@master] RCFilters UI: Add a placeholder to SavedLinksListWidget when it's empty

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

Checked in betalabs - below is a summary of the implemented adjustments:

Feature	Prototype	Implemented	Comment
Down-facing arrow			The arrow icon in prototype is a black down-pointing triangle (though there is a prototype variant with a checkmark)
Default message in the menu			The suggested text No links saved yet. To save your filter settings and reuse them later, click the bookmark icon in the Active Filter area, below.
No disappearing menu	'Quick links' will be always present; when there are no filters saved, the text is: "Save your favorite tool settings to re-use them later." - see the screenshot above.
Disappearing bookmark	works as described per Pau - the bookmark icon appears when there is selection/modification of filters that has not been saved. There might be some use cases when users when such behavior looks confusing - see my separate comment.
Too much space between menu items
"Unset as default"
Rollover for long names?			Rollover (tooltip) is present

@Pginer-WMF, @jmatazzoni re "Disappearing bookmark"
The current behavior is strictly logical, per @Pginer-WMF previous comment:

Making the action appear as the user modifies the filters helps to communicate they can do something new, and hiding it when it is not relevant keeps to focus on the relevant information.

However, there are, at least, two cases when users will need some additional feedback why the bookmark icon is not display:

1. Users may not remember which filters have been saved and would be surprised not seeing the bookmark icon when they select a set of filters/highlights that's already was saved.
2. When users will modify a saved filter and unintentionally come to the combination is already saved as a different filter, they won't see the bookmark icon which may be confusing.

Use his for the default message

Default message in the Quicklins menu

No links saved yet
To save your filter settings and reuse them later, click the bookmark icon in the Active Filter area, below.

Don't worry about the state pictured below. That gray "Mark your favorite tools..." message is only for use when we have the community links, which can be Favorited.

Change 353696 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Style the Saved Links placeholder and add a title

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

Change 353697 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Rephrase 'unset' to 'remove' in default option menu

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

Change 353698 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Style saved links option menu

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

New fixes require re-review.

Change 353697 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Rephrase 'unset' to 'remove' in default option menu

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

I've +2ed Moriel's patches, but the new placement of the default icon looks odd and out of balance to me:

Change 353696 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Style the Saved Links placeholder and add a title

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

Change 353698 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Style saved links option menu

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

In T164861#3295537, @Catrope wrote:

I've +2ed Moriel's patches, but the new placement of the default icon looks odd and out of balance to me:

In T164128 there are some layout guidelines that can help with this:

Mass-moving all items tagged for MediaWiki 1.30.0-wmf.3, as that was never released; instead, we're using -wmf.4.

Re-checked in betalabs - added updated screenshots o my comment above.

What's left:
(1) @Catrope, @jmatazzoni - please confirm that the current behavior is ok.

Disappearing bookmark
When the user can't save new settings (for whatever reason), currently the bookmark icon disappears. This is less than ideal, I think, since >users may want to make a setting but not realize how to get back the bookmark. They'll just think it's broken or that they imagined it. >Better would be if the bookmark would be grayed out when not available.

(2) @Catrope - can it be addressed later?

Too much space between menu items
In the Quick Links menu, items are separated by about 40 vertical px. In Pau's mockup, it looks more like about 30 px.

It's been in production since wmf.4 - the outstanding issues are either minor ("Too much space between menu items") or of a discussion nature (Disappearing bookmark). These may be separated into separate issues if necessary.

QA Recommendation: Product should weigh in

@Pginer-WMF, please comment on these two items:

Disappearing bookmark
When the user can't save new settings (for whatever reason), currently the bookmark icon disappears. This is less than ideal, I think, since users may want to make a setting but not realize how to get back the bookmark. They'll just think it's broken or that they imagined it. Better would be if the bookmark would be grayed out when not available. Or just be available; if the user saves something that's already saved, it's not a big issue compared to not being able to find the bookmark at all.

Too much space between menu items
In the Quick Links menu, items are separated by about 40 vertical px. In Pau's mockup, it looks more like about 30 px.

In T164861#3402810, @jmatazzoni wrote:

@Pginer-WMF, please comment on these two items:

Disappearing bookmark
When the user can't save new settings (for whatever reason), currently the bookmark icon disappears. This is less than ideal, I think, since users may want to make a setting but not realize how to get back the bookmark. They'll just think it's broken or that they imagined it. Better would be if the bookmark would be grayed out when not available. Or just be available; if the user saves something that's already saved, it's not a big issue compared to not being able to find the bookmark at all.

Based on what I understood form the research, I think that the main underlying issue is that users are not aware that a saved filter is applied. I'd fix T169063 first and then consider making the disabled bookmarking action to be more visible if we still think it generates confusion.

Too much space between menu items
In the Quick Links menu, items are separated by about 40 vertical px. In Pau's mockup, it looks more like about 30 px.

The padding for each item is intended to be 8px, which makes the vertical distance between labels to be 16px. I included a diagram in the original ticket (T164128) and shared it again in a comment above (T164861#3298151). I share these below again:

Please, let me know if there is any measurement that is not clear or missing.

Fixing the icon size will be a bit of an issue, since that's the icon that is in OOUI, but I'll give it a try. The padding is also consistent through ooui menus, but we have a lot more leeway with it, providing the icons are not blocking a portion of it (ooui icons have whitespace around them, it's a known issue, but one that prevents us from using exact size measurements of the actual icon rather than the whole whitespace-plus-icon box, which is what the svg itself is using.)

As an aside - I'm a little confused about what needs immediate fixing vs what's in design (the padding+icon is immediate fix, but the disappearing bookmark is back to design consideration?)

I don't want to "hijack" this ticket back into development for partial implementation when there are open issues... should we open a small task for the icon/padding and keep this in design, or pull this entire ticket into RfP/Development but then clarify what to do and what to wait with?

Sorry for the confusion, I'm trying to make sure we implement quickly and as best we can.

OK, I got rid of the requirement to make the disappearing bookmark more stable (though I don't like it). I crossed out this item in the Description.

The padding should still be fixed. @Mooeypoo, you and @Pginer-WMF can decide whether you want to close this and make that a separate ticket or just work it here.

Moving this to RFP and unassigning Roan. Please, someone, fix the padding.

Change 365375 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Reduce saved queries items height

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

I assigned it tor @Catrope because he implemented most of the fixes that were needed; it came back due to the spacing of the items, which is actually a slight annoyance (because of the padding/margins and icon in there)

I think I solved this, though. I couldn't get them very trimmed but I tried as much as I could. They're a lot thinner now with this fix.

Change 365375 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Reduce saved queries items height

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

The last spec has been implemented:

Too much space between menu items

In the Quick Links menu, items are separated by about 40 vertical px. In Pau's > mockup, it looks more like about 30 px.

Below is the comparison between wmf.9 (without the fix) and betalabs with the fix.

betalabs	wmf.9

QA Recommendation: Resolve