v6 Song tab - functional problem

[iv-gha]

Hello Gareth,

I hope the stress of the v6 release is not too great! Here are some hopefully useful observations.

Thinking about v5... The v5 Song Menu serves as a storage explorer view. The loaded song is displayed in its folder. This updates after:

• Loading from the song list
• Loading from a set
• Loading from a search
• Loading following a remote song receive
• Probably other events

For non-songs, they may not list, but are shown as being in the special folder for that file type.

The song list underlying this view is updated after song deletion, song renaming, etc.

The Song menu always provides some information relevant to the loaded song. The song is found in the Songbook.

Song swipe can move through the songs in the folder.

Thinking about v6... The v6 Song tab is a Search view with a results song list. This updates after:

• Change of search terms

V6 code still has some v5 behavior, so it may, in some cases, scroll the results list to the loaded song when in the list. Otherwise, the list can visibly jump to the top when opened.

The v6 Song tab search results list is relevant to the last search. The results can contain songs the user has no desire to load.

The Song tab does not update for song loads by other means, such as received songs or loading from a set. This means it will typically provide no useful information about the loaded song. This behavior, for me, is poor.

Using Song swipe can move through the songs in the search results. It is possible to have no search results. For most searches and after other song loads, the user will not find it useful.

At this time, the v6 Song tab is search results, meaning it is not always relevant to the loaded song. It looks like an extended v5 Song menu. However, it acts very differently.

Accepting that I have a limited view of v6 behavior, this change appears significant, and v6 may not be behaving quite as wanted.

I suggest no rush to fix. Rather, there is a need to combine Song list and Search activity in a way that supports all song loads. Perhaps taking time to work up the improved design?

Cheers, Ian

[thebigg73]

This is a tricky one as the filters can have multiple uses. For example if the user wants to play songs from a certain artist, the author/artist filter is activated and the filter text is entered, it then lists all matching songs. Loading one of these then allows swiping through the filtered songs. The same applies for the other filters ,e.g. if I set tags for some songs as 'solo' meaning they are suitable for my solo gigs, I want the app to list all songs that I've have set with this filter and want to be able to swipe through them meaning the filter needs to stay active. I get that sometimes the filtered songs may not be wanted one after the other, but in that case the user needs to cancel the filter before swiping.

With that said, if a song is loaded from another method (such as received song or from the set), it would make more sense to remove these filters with the exception of the folder filter. Would that be a sensible way forward?

[iv-gha]

Hi Gareth,

I was prompted to raise the issue by Forum posts like 'Searching questions' and 'Feature request for search filters' - I worked through the reported behaviour.

They have a reasonable desire to select songs, using any method, from a list that does not change - and for swipe to move through this list. For them it is songs in folder, but the pain is the same for songs by Artist etc.

v6 only does this if, after having got an initial song list, you do not cause it to change - so no use of other filters. If you do, it quickly generates 'doh' and 'why did it do that' moments. 'clear' does restore the song list, but not positioned at the song, and it results in confused swipe behaviour.

This is one of a number of impacts that the v6 current use of search results as the song list is having - so I raised the wider issues and I champion a redesign to resolve them all.

OpenSong and OpenSongApp use song files in folders. An explorer style song list is naturally needed to serve this. Lots of OpenSongApp behaviours need it.

My feeling it that filters used locally need to operate in two modes.

1. Persistently - to filter what is the 'base' song list in use. Perhaps grouped below a separator and above the 'base' song list which they filter.

2. Transiently - as filters of the 'base' song list. Perhaps grouped at the top of the song tab. These get cleared.

• Songs in a folder has 'Folder' persistent, others transient. (classic explorer view)
• Songs by Artist has 'Artist' persistent, others transient.
• Songs by tag, 'Tag' persistent, others transient.
• Etc.

Only thinking of local use - on load or on return to a song, transient filters would be cleared and the song list updated to the 'base' song list using persistent filters. The list would be scrolled to the song. Swipe would be initialised for the place of the song in this new list.

Offered as early thoughts - so not fully formed. I am thinking we resolve all issues with a great intuitive design!

Kind regards Ian

[iv-gha]

Hello Gareth,

I have mocked up a few thoughts...

Here is a mock up - original then proposal.

Note there is a Search icon at the top (more later) and that the terms for Search does not include Folder as it is a Filter. The Filter icon would support selecting one or more terms (Folder, Tab etc) for use as filters. In this example Folder is used for Filter so not offered for Search.

I believe it is optimal to show Search terms when Search is used. This is the simple view when the Song tab is first opened. This helps make Filter options clearer as there is no competition (yet) with Search.

Use of the Search icon would bring in the Search terms etc.

This supports a Filtered song list with a Search that finds a song located, in place, in the filtered song list. Maybe.

It is tricky to get a good UI flow here!

Kind regards Ian

[iv-gha]

I believe you are open to improvement. Just as in Windows explorer , Search is not the folder view. Just needs tweak.

[iv-gha]

?

[thebigg73]

I'm unsure of how the filtering of items and searching of items would work together other than for folder (as it isn't in the search). Searching by Tag, etc would make the filtering of the tag pointless as they would yield the same result? The search items currently work as cumulative filters/search terms where filtering by folder and lyric will yield all songs with matching folder and lyrics. I don't see how this is different to the proposed?

[iv-gha]

In the mock up, Folder is a song list filter, so it is not offerred for search.

The search buttons offers only those not used as song list filters.

Example, if the Song list is filtered by folder and tag, they would appear in the (filtered) song list and not be offerred in the search buttons.

[iv-gha]

I agree Search will feel (mostly) the same. The list updates using Search and Filter values.

The difference is code that runs after a song is selected. This code is yet to be developed.

I filter by folder, the code gives the selected song listed in songs of the folder.

I filter by tag, the code gives the selected song listed in songs with that tag.

...

Looking for a good UI design before sorting this!

[iv-gha]

?

[thebigg73]

So, if a folder is selected, then a tag is filtered, the folder should be ignored?

[iv-gha]

If you mean to select from Tag songs in a Folder then filter both. If you mean to select a song from all songs with a Tag then Filter Tag.

Yes, after select of a song, the next song menu open shows Filter(s), filtered song list with Search inactive. The user can select from the filtered list or use search.

[thebigg73]

To show all songs with a certain 'tag', then the 'tag' should be the only criteria in the search/filter items (i.e. don't have a folder selected). This filter then stays active until the user clears it or turns it off. I'm really not getting what you mean with this or what the difference is - have you worked up code for a pull request?

On Sun, 16 Jun 2024, 21:26 iv-gha, @.***> wrote:

If you mean to select from Tag songs in a Folder then filter both. If you mean to select a song from all songs with a Tag then Filter Tag.

Yes, after select of a song, the next song menu open shows Filter(s), filtered song list with Search inactive. The user can select from the filtered list or use search.

— Reply to this email directly, view it on GitHub https://github.com/thebigg73/OpenSongTablet/issues/258#issuecomment-2171867133, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3X52UD6ILMN4TK7URJHRDZHXYHNAVCNFSM6AAAAABFXSJMMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRHA3DOMJTGM . You are receiving this because you commented.Message ID: @.***>

[iv-gha]

Song list opens, users see a filtered list with Search inactive.

They scroll the list, they might look for a song title or a key or a song writer - they select a song. The song menu is closed. The app continues making use of the song in the filtered list.

Instead of scrolling, they instead use search to select the same song. The song menu is closed. The 'difference' is to give the same result - the app code to rework so the app then continues making use of the song in the (same) filtered list.

The new code would make this difference on menu close.

At the moment, still looking for a good UI design!