Pre-filter the 'Available' plugin manager tab, allow multiple terms #4580

daniel-beck · 2020-03-14T23:16:06Z

There are three similar looking tabs in the plugin manager:

Updates shows updates for installed plugins.
Available shows available plugins (plugins not currently installed).
Installed shows currently installed plugins.

The first and third have a fairly limited number of list entries (typically at most dozens and very low hundreds, respectively), all of which are relevant to administrators in different ways (updates and installed), while the second has a very large number of list entries (almost more than 1000) with a very low average/median relevance to users.

This PR implements a change that hides all elements on the "Available" tab by default, and users are reminded to use the "Search" field to make plugins appear. Search expressions need to be two characters minimum (to support searching for "JS" – sorry R!).

Implementation is fairly hacky, since we're doing all the searching/filtering client-side, we just now hide all rows in the form by default (they're still loaded, but at least not rendered!). Didn't want to bother with a full rewrite here, I lack the mad design skillz to pull off an actually good plugin manager anyway!

Screenshots

Updates tab - unfiltered (largely unchanged)

Updates tab - slightly filtered, still supports 1 char filters (largely unchanged)

Available tab - unfiltered and empty except for a reminder to use the search field

Available tab - unfiltered with 1 character in search field

Available tab - filtered with 2 characters in search field

Available tab - we now support multiple individual search terms

Search vs. Filter

I left the "Filter" term on the UI for Updates and Installed, because there's a list that we filter.

"Search" is the new term for "Available" only, since we're starting out with nothing.

Proposed changelog entries

Minor RFE: Don't show all available plugins by default; use search field to find plugins
Minor RFE: Allow use of multiple space-separated filter terms in plugin manager

Proposed upgrade guidelines

N/A

Submitter checklist

JIRA issue is well described
Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
- Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
Appropriate autotests or explanation to why this change has no tests
[n/a] For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

There are at least 2 approvals for the pull request and no outstanding requests for change
Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
Changelog entries in the PR title and/or Proposed changelog entries are correct
Proper changelog labels are set so that the changelog can be generated automatically
If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
If it would make sense to backport the change to LTS, a JIRA issue should exist and be labeled as lts-candidate

daniel-beck · 2020-03-14T23:17:07Z

core/src/main/resources/hudson/PluginManager/_table.js

-      function applyFilter() {
-          var filter = e.value.toLowerCase();
-          ["TR.plugin","TR.plugin-category"].each(function(clz) {
-            var encountered = {};


encountered and TR.plugin-category have been obsolete since #4534.

timja · 2020-03-15T10:34:34Z

core/src/main/resources/hudson/PluginManager/_table.css

@@ -10,7 +11,8 @@ time {

 #filter-container {
    margin: 1em;
-    text-align: right;
+    text-align: center;
+    font-size: 2em;


The search input doesn't seem to fit with the rest of the page to me, did its size need to be increased?

I did these changes to make it more noticeable. Now there's no way to use the "Available" tab without it, after all. Also larger font size for the placeholder list item.

Whether these need to apply to other tabs too is more questionable.

alternative design:
daniel-beck#2

@fqueiruga PTAL

I'd just go with Tim's design, it's more consistent with the header one. We could also extract it into a searchbox widget in the future.

timja · 2020-03-15T12:00:23Z

I don't seem to be able to search by the plugins artifact ID any more?
Some plugins can be quite hard to find, and display names vs artifact IDs don't match very well.

So I used to sometimes search by ID instead,

i.e.
workflow-cps-global-lib or git-client,

That seems broken with this change, unless I'm missing something?

daniel-beck · 2020-03-15T12:01:17Z

That seems broken with this change, unless I'm missing something?

Good point, side effect of searching textContent now. Will fix.

fqueiruga · 2020-03-16T08:43:08Z

I don't know if this is a good idea. I think it may pose a problem if just one table behaves differently than the other 2. This kind of inconsistency is confusing and may lead to user errors. Thoughts on this?

Maybe as an alternative we can have the search input with autofocus. Still does not solve the problem but at least the users are prompted to start searching

fqueiruga · 2020-03-16T08:46:42Z

One thing to keep in mind: users do not read. There's a good chance will instinctively think that there are no available plugins or have a bit of confusion.

daniel-beck · 2020-03-16T09:34:19Z

One thing to keep in mind: users do not read. There's a good chance will instinctively think that there are no available plugins or have a bit of confusion.

Hence giant fonts for everything and search field in the center rather than on the right.

fqueiruga · 2020-03-16T09:58:18Z

Still, I find it a bit confusing: empty updates tab means there is nothing to be checked. But the next tab means you need to start typing.

TBH I'd find it more useful if we could have a way to filter by categories, now that we sort of have infrastructure for it.

daniel-beck · 2020-03-16T22:35:53Z

@fqueiruga Is it the overall design using tabs flowing into the table header row that gives the impression these should all behave alike? Would be help if we did that differently, e.g. as sidepanel items?

fqueiruga · 2020-03-17T09:05:19Z

core/src/main/resources/hudson/PluginManager/_table.css

@@ -10,7 +11,8 @@ time {

 #filter-container {
    margin: 1em;
-    text-align: right;
+    text-align: center;
+    font-size: 2em;


I'd just go with Tim's design, it's more consistent with the header one. We could also extract it into a searchbox widget in the future.

fqueiruga · 2020-03-17T09:07:07Z

core/src/main/resources/hudson/PluginManager/_table.css

@@ -2,6 +2,7 @@
    background: white url('search.gif') no-repeat 2px center;
    padding-left: 20px;
    width: 15em;
+    font-size: 1em;


I think this is a case for using the font-size in rems. ems should only be used when the element size depends on where they are (such as hyperlinks or inline monospaced elements)

Recommended font sizes are located on the font.less file

fqueiruga · 2020-03-17T09:11:23Z

core/src/main/resources/hudson/PluginManager/_table.js

+    function applyFilter() {
+        var filter = e.value.toLowerCase().trim();
+        var filterParts = filter.split(/ +/).filter (word => word.length > 0);
+        var items = document.getElementsBySelector("TR.plugin");


getElementsBySelector is a prototype.js function, and should be avoided. The alternatives are using querySelectorAll (https://caniuse.com/#search=querySelectorAll). If the browser support is not good enough (especially due to Baidu-browser support, then I suggest using getElementsByClassName('plugin') and filter out the elements that are not <tr> within the function.

Unchanged from before, just threw out the other, obsolete selector ☹️

Looks like I didn't read the diff properly then 👍

fqueiruga · 2020-03-17T09:22:10Z

I think that it is part of why they feel that they should behave the same, but also because they use rather similar tables.

TBH I think they should still be tabbed, I think it would sort of hide the options if moved into the sidebar

fqueiruga · 2020-03-27T12:38:35Z

@daniel-beck what is the state of this PR? TBH I feel that showing nothing on the available tab by default is a degradation, maybe we can get some more comments on this (even raise it on a UX SIG meeting.

The multi-term search is really interesting though, and the text copy changes are on point. I believe we should move forward with these. If we can include the filter bar changes that @timja created on daniel-beck#2 it would be even better.

daniel-beck · 2020-03-27T14:34:04Z

TBH I feel that showing nothing on the available tab by default is a degradation, maybe we can get some more comments on this (even raise it on a UX SIG meeting.

I think there should be a way to work around that feeling. I tried it by making the search more noticeable and adding the placeholder with large text, but clearly that wasn't received well.

Rename "Available" to "Find New Plugins" to make it clear what the content is and how to interact with it?
Move the search field below the tab bar on that page?
Move the page from a tab into the side panel to separate it from the other two tabs that are slightly more alike?

fqueiruga · 2020-03-27T14:49:49Z

TBH I don't think there are good options here that don't merit of a full page revamp. Adding this much used tab to the sidebar can be confusing, it's sort of hiding it.

One thing I believe would improve the situation tough is to add an autofocus attribute to the search input. That way users will be propmted to start searching right away. Other thing that could help is a filter by categories, now that we have them.

fqueiruga · 2020-03-27T14:52:11Z

I think there should be a way to work around that feeling. I tried it by making the search more noticeable and adding the placeholder with large text, but clearly that wasn't received well.

TBH I think the reaction was more due to styling than anything else (the search box looked a bit out of place like if that part of the page was zoomed in). Tim's proposal of a search box is noticeable enough and looks like the one on the navbar (helps with UI consistency).

daniel-beck · 2020-03-28T01:49:51Z

@fqueiruga Could you clarify whether a pre-filtered view is possible with timja's PR, or whether neither that nor this PR currently have are good enough to make pre-filtering work?

Other thing that could help is a filter by categories, now that we have them.

#4591 remains unmerged. I wonder whether we could rely on the "label linking" feature implemented there, and do something like:

Use the search field above, or filter by the following popular labels: [pipeline], [github], [docker]

timja · 2020-03-28T10:23:24Z

That seems broken with this change, unless I'm missing something?

Good point, side effect of searching textContent now. Will fix.

From what I can tell this isn't fixed yet?

Apart from that I think the autofocus has made it more usable along with the search input being made more prominent

Possibly mentioning the filters above could help

daniel-beck · 2020-03-28T11:44:52Z

@timja

From what I can tell this isn't fixed yet?

True.

Possibly mentioning the filters above could help

Unclear, could you explain?

timja · 2020-03-28T12:12:11Z

@timja

Unclear, could you explain?

I just meant this comment,

Use the search field above, or filter by the following popular labels: [pipeline], [github], [docker]

showing that you can filter by labels would be helpful imo

daniel-beck · 2020-03-28T12:29:10Z

showing that you can filter by labels would be helpful imo

Depends on another unmerged PR to work: #4591

Would see that as followup unless we consider it essential to make this PR work.

timja · 2020-03-28T13:18:39Z

showing that you can filter by labels would be helpful imo

Depends on another unmerged PR to work: #4591

Would see that as followup unless we consider it essential to make this PR work.

👍

I'm happy with this PR except for the not being able to search by artifactId

Will cause lots of 'false positives' for some search terms, but can always be cleaned up later through more fine-grained control what can be searched (e.g. textContent + artifactId)

timja · 2020-04-01T08:43:21Z

I've updated the screenshots, any other feedback @jenkinsci/core-pr-reviewers ?

oleg-nenashev

I think it is a great first step, the list of all plugins was not really usable anyway (and it was a long rendering time contributor). It also enables future additions to the view, e.g.

Listing of categories and suggestions similarly to the Installation Wizard (reusing code is not trivial IIUC)
Listing of labels based on installed plugins and ranking
Cool UI features like Label cloud (similarly to Add a plugin tag cloud to the front page and search windows jenkins-infra/plugin-site#137 )

oleg-nenashev · 2020-04-07T07:47:10Z

I plan to merge it tomorrow if no negative feedback

timja · 2020-04-07T08:00:04Z

I think it is a great first step, the list of all plugins was not really usable anyway (and it was a long rendering time contributor). It also enables future additions to the view, e.g.

FTR its still slow as it loads all the plugins but just hides them and then does filtering client side.
Other future improvements could be:

adding a search API
searching server side rather than client side
rework the UI :D

oleg-nenashev · 2020-04-07T08:05:43Z

rework the UI :D

I read it as "embed plugins.jenkins.io frontend into Jenkins so that we have focus efforts on a single great UI/UX". Which would be a valiant goal indeed

oleg-nenashev · 2020-04-10T07:45:12Z

@daniel-beck @timja I resolved the merge conflict with #4580 . Would appreciate a second look before I merge it

timja · 2020-04-10T07:55:42Z

[ERROR] Failed to execute goal org.jenkins-ci.tools:maven-hpi-plugin:3.11:generate-taglib-interface (default) on project jenkins-core: Failed to generate taglib type interface: Failed to parse /Users/timja/projects/jenkinsci/jenkins/core/src/main/resources/hudson/PluginManager/table.jelly: Error on line 88 of document file:///Users/timja/projects/jenkinsci/jenkins/core/src/main/resources/hudson/PluginManager/table.jelly : Element type "tr" must be followed by either attribute specifications, ">" or "/>". -> [Help 1]

timja · 2020-04-10T08:44:22Z

Tested locally after the last merge fixup ^^, good to go if the build passes

amuniz · 2020-05-15T16:20:22Z

This is breaking any Acceptance Test trying to install a plugin.

jsoref · 2020-08-06T16:35:35Z

Filed https://issues.jenkins-ci.org/browse/JENKINS-63326 about the text...

fixup '%search' and '%filter' case sensitive in src/main/resources/hudson/PluginManager in table_xxx.properties and installed_xxx.properties files I found the "filter" startswith a capital letter, so I choose to the upper case. the "search" is not in any properties files, both upper and lower case are OK, in order to keep the style same I choose the upper case too. this PR is fixup for jenkinsci#4580

Pre-filter the 'Available' plugin manager tab, allow multiple terms

b9e4d4c

daniel-beck added web-ui The PR includes WebUI changes which may need special expertise rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted labels Mar 14, 2020

daniel-beck requested a review from fqueiruga March 14, 2020 23:16

daniel-beck commented Mar 14, 2020

View reviewed changes

timja reviewed Mar 15, 2020

View reviewed changes

Re-work search / filter input

42cfea9

daniel-beck added the needs-comments-resolved Comments in the PR need to be addressed before it can be considered for merging label Mar 15, 2020

daniel-beck mentioned this pull request Mar 16, 2020

Sort available plugins by popularity #4588

Merged

8 tasks

daniel-beck mentioned this pull request Mar 17, 2020

Allow linking to pre-filtered plugin manager pages, link from labels/… #4591

Merged

8 tasks

fqueiruga suggested changes Mar 17, 2020

View reviewed changes

varyvol approved these changes Mar 19, 2020

View reviewed changes

Focus the filter/search field once the page is loaded.

03d2937

Look at innerHTML as before, rather than textContent

142a786

Will cause lots of 'false positives' for some search terms, but can always be cleaned up later through more fine-grained control what can be searched (e.g. textContent + artifactId)

daniel-beck requested review from timja and fqueiruga April 1, 2020 00:11

daniel-beck removed the needs-comments-resolved Comments in the PR need to be addressed before it can be considered for merging label Apr 1, 2020

timja approved these changes Apr 1, 2020

View reviewed changes

fqueiruga approved these changes Apr 1, 2020

View reviewed changes

timja requested a review from a team April 1, 2020 08:38

oleg-nenashev approved these changes Apr 7, 2020

View reviewed changes

oleg-nenashev added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Apr 7, 2020

Merge branch 'master' into prefiltered-available

a73f86c

Update table.jelly

104e745

oleg-nenashev added the squash-merge-me Unclean or useless commit history, should be merged only with squash-merge label Apr 10, 2020

Fix quoting

dd0c8d0

timja merged commit e97fe13 into jenkinsci:master Apr 11, 2020

amuniz mentioned this pull request May 15, 2020

The check now button is a link now, not a button jenkinsci/acceptance-test-harness#574

Closed

amuniz mentioned this pull request May 18, 2020

Plugins need to be "filtered" before selecting jenkinsci/acceptance-test-harness#575

Merged

mamh2021 mentioned this pull request Oct 14, 2020

fixup search and filter case sensitive issue in PluginManager #4998

Closed

10 tasks

Pre-filter the 'Available' plugin manager tab, allow multiple terms #4580

Pre-filter the 'Available' plugin manager tab, allow multiple terms #4580

Conversation

daniel-beck commented Mar 14, 2020 • edited by timja

Screenshots

Updates tab - unfiltered (largely unchanged)

Updates tab - slightly filtered, still supports 1 char filters (largely unchanged)

Available tab - unfiltered and empty except for a reminder to use the search field

Available tab - unfiltered with 1 character in search field

Available tab - filtered with 2 characters in search field

Available tab - we now support multiple individual search terms

Search vs. Filter

Proposed changelog entries

Proposed upgrade guidelines

Submitter checklist

Desired reviewers

Maintainer checklist

Choose a reason for hiding this comment

timja Mar 15, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timja commented Mar 15, 2020

daniel-beck commented Mar 15, 2020

fqueiruga commented Mar 16, 2020

fqueiruga commented Mar 16, 2020

daniel-beck commented Mar 16, 2020

fqueiruga commented Mar 16, 2020

daniel-beck commented Mar 16, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fqueiruga commented Mar 17, 2020

fqueiruga commented Mar 27, 2020

daniel-beck commented Mar 27, 2020

fqueiruga commented Mar 27, 2020

fqueiruga commented Mar 27, 2020

daniel-beck commented Mar 28, 2020

timja commented Mar 28, 2020

daniel-beck commented Mar 28, 2020

timja commented Mar 28, 2020

daniel-beck commented Mar 28, 2020

timja commented Mar 28, 2020

timja commented Apr 1, 2020

oleg-nenashev left a comment

Choose a reason for hiding this comment

oleg-nenashev commented Apr 7, 2020

timja commented Apr 7, 2020

oleg-nenashev commented Apr 7, 2020

oleg-nenashev commented Apr 10, 2020

timja commented Apr 10, 2020

timja commented Apr 10, 2020

amuniz commented May 15, 2020

jsoref commented Aug 6, 2020

daniel-beck commented Mar 14, 2020 •

edited by timja

timja Mar 15, 2020 •

edited