2166: Search UI still needs more work

Report bugs & feature requests for MediaMonkey 5 and learn about the newest builds.

Moderator: Gurus

Barry4679
Posts: 835
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

2166: Search UI still needs more work

Post by Barry4679 » Sun Mar 17, 2019 11:47 pm

The differences between search mode "filter matches" vs "scroll to matches" is not initiative, and it is poorly indicated by the UI.

Differences:
  • "filter matches" ... searches all properties
  • "scroll to matches" ... searches just primary sort column
I suggest that you change wording to "keyboard scroll; matches in the primary sort column" vs "keyboard filter: matches in any column"
or at the vey least you need to provide a tool tip for this complex & non-intuitive control.

Also suggest that you have an explanatory message if the user presses ctrl|updown without a search string ... ie. replace the following with some explanation of the feature https://www.dropbox.com/s/m81wx8d0bcj39 ... d.png?dl=0

The following was a very good idea for "scroll to matches" ... still under consideration? ... I think that it should adopted for both the temp message boxes ... ie. in "Use ctrl+down dor next occurrence", and also in "No occurrence for" messages ... I think that it would be a big improvement, as it does a good job of describing an non-intuitive feature
https://www.dropbox.com/s/9u6jljhhd9vb2 ... a.png?dl=0


You display the following message when I am already in "scroll to matches" mode ... unnecessary
https://www.dropbox.com/s/40t3d0s0439tk ... y.png?dl=0

in "scroll to matches mode, a search for albert finds albert hall, but a search for albert hall finds nothing ... that is unhelpful behaviour

The global search icon at the top right of the tool bar

This kind of search is very different to keyboard search when focus is in a grid:
  • global scope
  • navigates the user away from their current node
  • has a search syntax
The UI gives no indication that this control is not connected to the keyboard search|scroll|filter facility somehow.
There is no tool tip when the control is closed. ... so this type of search is given no name ... which will cause support query confusion
The tool tip should contain some brief description of its function: eg. "Whole database search: not confined to just your current view ... for search within your current view just use the keyboard"

Ludek
Posts: 3083
Joined: Fri Mar 09, 2007 9:00 am

Re: 2166: Search UI still needs more work

Post by Ludek » Mon Mar 18, 2019 4:30 am

Hi, the contextual search improvements are still being worked on,
see the last suggestions/details from friday: https://www.ventismedia.com/mantis/view ... 077#c52972
I am going to implement the basics for the suggested approaches ( FI & FII ) today and we will decide whether we will go with FI) or rather FII)

Re: https://www.dropbox.com/s/9u6jljhhd9vb2 ... a.png?dl=0
yes, I think we will need to clarify this.

Barry4679
Posts: 835
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2166: Search UI still needs more work

Post by Barry4679 » Mon Mar 18, 2019 5:30 am

OK, I will hold back any further search feedback until this settles down.

A few other comments re search facilities.

1. The "scroll to matches" facility still has a problem with repeated adjacent letters, ie it ignores the duplicates
eg. it is impossible to scroll to the artist named eels ... the second e gets consumed, and the search string is just els

2. context for "scroll to matches" in Art View is confusing. Steps:
  • click on EntireLibrary>Album node ... a grid is displayed ... type help (ie. looking for Beatles album with title of Help!) ... a message appears at the bottom of the grid saying "no occurrence for help" .... it can look like I don't have an album with "help" in title ... but no, the current search context is still within the media tree
  • so click in some free space within the grid ... surprise there is no free space, so an album opens up ... it now looks like the search context will only be within that album ... but no, search context is within the whole albums node ... type help and the auto-closes, and the grid is scrolled to the album Beatles album
  • if I click within the box that has opened for the album, the UI is not altered ... it looks like nothing has changed, but now the search context is just within that album ... shouldn't the UI show this?
Wouldn't it be better if when I click on the node EntireLibrary|Albums, the search context was within the grid that you have opened.

And if I click on an album, and you open it up, then the search context would be within that album ... if I want to search the whole node, I am required to close the album first, ie press esc key

That way the UI would better describe the search context wouldn't it?

Ludek
Posts: 3083
Joined: Fri Mar 09, 2007 9:00 am

Re: 2166: Search UI still needs more work

Post by Ludek » Mon Mar 18, 2019 7:31 am

re 1) yes, this will be fixed in 2167

re 2)
Wouldn't it be better if when I click on the node EntireLibrary|Albums, the search context was within the grid that you have opened.
No, because if you click a node in media tree then the 'scrool to matches' is meant to be performed within the media tree.
i.e. if you expand a node with many subitems (like EntireLibrary|Albums with the 'showAllNodes' extension) or 'Playlists' node then it is expected to scroll the media tree items (subnodes).

Workaround is to not use navigation via media tree, but via further UI elements (e.g. navigation bar, main view)

i.e. The logic is that "scroll to match" is performed within the list for which the item was selected. When you selected an album then it is performed on album list, when you selected a node in tree then it is performed on tree node list and when you selected a track of an album then it is performed on album tracklist.

I think this is the right logic, don't you think?

Barry4679
Posts: 835
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2166: Search UI still needs more work

Post by Barry4679 » Mon Mar 18, 2019 8:41 pm

Ludek wrote:
Mon Mar 18, 2019 7:31 am
No, because if you click a node in media tree then the 'scrool to matches' is meant to be performed within the media tree.
i.e. if you expand a node with many subitems (like EntireLibrary|Albums with the 'showAllNodes' extension) or 'Playlists' node then it is expected to scroll the media tree items (subnodes).
[snip]
I think this is the right logic, don't you think?
I think that it is not a black or white issue. ... MM5 tries to have things both ways.

Example ... I select EntireLibrary>Albums node ... I press ctrl+A; all albums in the grid are selected ... I press F5; the contents of the grid are refreshed.

Or I have search set to "filter matches", and I type 'help", and you filter the grid.

So in those cases it looks like the grid has focus.

But if I have search set to "scroll to matches", and now you want to say that it is to be expected that focus has remained in the Media Tree.

And if you worked through the steps in my previous post you should see that the UI is somewhat misleading. ... in step 1, the "no occurrence for "help"" message was at the bottom of the grid, so it looks as if the message applies to the grid .... and at steps two and three, the UI is truly confusing IMO

The one thing is favour of your current implementation is that the user may have installed the 'showAllNodes' extension. ... idea: maybe that extension could override native behaviour to retain focus in the Media Tree?

If I click the EntireLibrary>Albums node, and then press the down arrow, I want focus to have remained in the Media Tree ... which is why I say that MM5 tries to have it both ways ... there is no black or while logic to the behaviour ... MM5 has convenience exceptions, such as those listed above ... which are good things IMO

Either way it is no big deal. ... I will not install the extension, and nor I will use "scroll to matches" mode either ... but I do think that the implementation is confusing, and is missing a convenience function. ... it is like those annoying dboxes, where the Developer hasn't thought to set focus to the control where you are now required to type something.
Ludek wrote:
Mon Mar 18, 2019 7:31 am
Workaround is to not use navigation via media tree, but via further UI elements (e.g. navigation bar, main view)
This is humour ... right?

Ludek
Posts: 3083
Joined: Fri Mar 09, 2007 9:00 am

Re: 2166: Search UI still needs more work

Post by Ludek » Tue Mar 19, 2019 5:59 am

The one thing is favour of your current implementation is that the user may have installed the 'showAllNodes' extension. ... idea: maybe that extension could override native behaviour to retain focus in the Media Tree?
Yes, I also thought about this yesterday. Probably makes most sense -- as without this extension the media tree has a limited count of nodes and the 'scroll to matches' feature within the media tree isn't much needed. And even with the extension installed the same item can be scrolled within the main view.
Another possible "rule" could be the expand state of the currently selected media tree node. If it is expanded then scroll tree item, if it is collapsed then scroll the 'main view' item. As you are saying it is not black or white logic ;-)

Barry4679
Posts: 835
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2166: Search UI still needs more work

Post by Barry4679 » Tue Mar 19, 2019 8:05 pm

Ludek wrote:
Tue Mar 19, 2019 5:59 am
Another possible "rule" could be the expand state of the currently selected media tree node. If it is expanded then scroll tree item, if it is collapsed then scroll the 'main view' item. As you are saying it is not black or white logic ;-)
Sounds OK.
Also any node, or sub-node, which has <2 subnodes of its own should have the convenience function IMO
ie. without the extension EntireLibrary>Albums has zero subnodes. ... and EntireLibrary>Years>1930s has 1 subnode

Post Reply