thebigg73 / OpenSongTablet

Android port of OpenSong. Use your mobile device as a portable song book. Gareth Evans
GNU General Public License v3.0
32 stars 23 forks source link

Enh: Rework of #235 after user feedback. #238

Closed iv-gha closed 1 year ago

iv-gha commented 1 year ago

Also added tweaks to (hopefully) get top menu icons aligned and a few top padding fixes. Hopefully good for all devices!

iv-gha commented 1 year ago

It is a tension yes. It acts that in normal use click of a song, receive of a song, click of a song in set, swipe... will move to the song and change the song list to that songs folder and scroll the song to the top. For v6 reset of filters is needed.

However...

As per your note... this is in tension with use of the song list to swipe through as a filtered list. It may resolve the tension if the 'reset' test considers if the new song choice is in the current (possibly filtered) song list - only resetting if not. Scroll to top will then happen. Maybe?

iv-gha commented 1 year ago

Here I reveal a few v5 and v6 thoughts - my feeling is to think further always seeking best usability.

Thoughts...

It keeps logic simple (v5 in effect does this) to not persist search results and on song move to move to that song. The use of song menu after this finds the song at the top with ability to long press/use + options on the song. v5 does this on song move, renames, copies etc. - search does not affect the song list.

v6(20) filters the song list to give a persisted search result.

Persisted search result positively affects swipe behaviour if the search intent was to end up with a list of songs (TAG).

Persisted results negatively affects if wanting to find a song in a folder and to swipe through songs in that folder. This will return few songs. User would have to return to the song menu, clear all filters but folder, find and select the song manually. They can now swipe through songs in the folder.

Persisted results may negatively impact for received songs. These may or may not be in the persisted results or current set. Needs considering.

These thoughts are highly likely to change as further sources of song change are considered.

Part of me loves persisted search results and if OpenSongApp was a simpler songbook then the following might resolve...

Some of the potential pain could be removed by having the ability to clear search filters to the current songs folder with the song at the top. Another button!

Thinking...

thebigg73 commented 1 year ago

I definitely feel the filters (not necessarily used as song searches) should be persistent until the user clears/hides them. E.g. putting a tag filter of 'Pentecost' to filter all songs with this tag, I like (and want) the option to be able to swipe through the filtered list - that's why I filtered it! I know a few users who requested this feature to be able to act like a set filter for different purposes, etc and specifically requested persistence and the song navigation to reflect available filtered songs.

Filters can be removed by either clicking on the x button in the text filter, or by simply hiding that filter by clicking the button again - no need for a new button.

Received songs will be received and displayed without issue. If the receiver/client swipes, they wouldn't be navigating the host songs anyway.

Not persisting filtering is more of an issue if you use it to filter intentionally to restrict songs shown (from different folders, etc). Having to retype this each time would definitely be a downgrade and non-expected, irritating behaviour. For example, I often have a theme tag for 'acoustic' to quickly list songs from various folders that I can easily choose from for solo acoustic gigs when taking requests, rather than ones I tend to only play in a full band setting. I can scroll through these songs (swipe/pedal) and opening the song menu keeps these songs listed alphabetically as the filter persisits. allowing me to easily scroll through them. Having to open the tag filter each time and retyping would be a major inconvenience. Usability suggests to me if a user adds a filter, they have the open to add and remove it as required.

v5 was simply a 'search' and that did make sense to reset, since once you find a song, you are unlikely to open the song menu to find the same song again. v6 uses combined filtering allowing far more focused, or looser filtering as they see fit.