Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Usability] Lyrics support is unintuitive to use #111

Open
Olf0 opened this issue Dec 1, 2024 · 4 comments
Open

[Usability] Lyrics support is unintuitive to use #111

Olf0 opened this issue Dec 1, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@Olf0
Copy link
Contributor

Olf0 commented Dec 1, 2024

From #106 (comment) by @tuplasuhveli:

  1. First of all, you have to have a song playing.
  2. Then tap on the small album cover on the low left corner.
  3. After that you need to swipe left to see the lyrics.

flowplayer

@Olf0 Olf0 added the enhancement New feature or request label Dec 1, 2024
@Olf0 Olf0 changed the title [Usability] Lyrics support is unintuitive to support [Usability] Lyrics support is unintuitive to use Dec 1, 2024
@Olf0 Olf0 mentioned this issue Dec 1, 2024
@tuplasuhveli
Copy link
Contributor

tuplasuhveli commented Dec 15, 2024

This is the view inside an album after a song has been picked:

soittonäkymä1

How about we add option "Show lyrics" to the top pulley menu?

ylävalikko1

Another option would be placing a lyrics icon to the bottom pulley menu, but I find this less intuitive: alavalikko1.jpg

@Olf0
Copy link
Contributor Author

Olf0 commented Dec 16, 2024

  • Do not suggest options you basically dismissed in the first place. 😉
    You can always come up with such a suggestion, when your original, preferred suggestion comes under scrutiny. The line of arguments is then: "But look, though another option would be to do it that way, but this is far worse than my original suggestion, isn't it?"

    Thus I dashed out this variant (for now).

  • How about we add option "Show lyrics" to the top pulley menu?

    Well, who is "we"? Feel free to submit a PR.
    Sorry to state this so bluntly, but using "we" is mostly a rhetoric trick in most contexts, as someone specific has to do the work. By using "we" it is concealed who is addressed, either deliberately (usually to fool the recipient(s)) or unconsciously.

    If you just intended to discuss, »How about adding an option "Show lyrics" to the top pulley menu?«: Yes, that seems to be the obvious place for it.

  • Usability / Look&Feel

    Would it be sufficient to jump to FlowPlayer's "Lyrics" page from such a new pulley entry?
    Does swiping left to leave the "Lyrics" page bring you back to the "Album view" page currently, as one would expect then? I.e. is there anything else to implement than a pulley-entry which opens the extant "Lyrics" page?

    If the answers are "Yes", "Yes" and "No", then this should be quite easy to implement.

@tuplasuhveli
Copy link
Contributor

  • Do not suggest options you basically dismissed in the first place. 😉

Heh, I see what I did there now that I read my message again. I wanted this to be a discussion, but I should have made the arguments more balanced.

I could have mentioned, that adding the "Show lyrics" entry into top pulley menu means it has 4 items on it - that's the maximum, if the app is wanted to be used in landscape mode.

  • Well, who is "we"? Feel free to submit a PR.

I wanted to hear opinions from other users and people who follow the discussion in this repo. As this is a community, I tend to think it as "we". I didn't want to make any demands or promises.

  • Yes, that seems to be the obvious place for it.

Good to hear that! And then to the questions...

Yes, that would be ideal.

  • Does swiping left to leave the "Lyrics" page bring you back to the "Album view" page currently, as one would expect then?

Swiping from left (or to right) goes back to the song page that was opened by clicking the album cover. It sure would make more sense to go back to Album view page, if the "Show lyrics" top pulley menu item is used.

  • I.e. is there anything else to implement than a pulley-entry which opens the extant "Lyrics" page?

The logic needs to be changed to back to the previous page, which is either Album view page or Song view page. The Song view page has already 4 top pulley menu items, so I guess it could be kept as it is.

@Olf0
Copy link
Contributor Author

Olf0 commented Dec 18, 2024

  • Do not suggest options you basically dismissed in the first place. 😉

Heh, I see what I did there now that I read my message again. I wanted this to be a discussion, but I should have made the arguments more balanced.

To continue my bitching: Well, then discuss with yourself, until you know what you want to suggest. 😉

More seriously:

  • "I want a, b or c" is usually not a very helpful statement, regardless if a discussion is friendly or hostile: In both cases the received message is "I do not know what I want", hence you lost he argument with a hostile counterpart and do not provide concise information to a friendly reader.
  • Here specifically: As I do not use FlowPlayer (I mentioned that a couple of times), I need well thought out input, as even my checks-and-balances questions are purely academic (i.e. without any practical experience).

I could have mentioned, that adding the "Show lyrics" entry into top pulley menu means it has 4 items on it - that's the maximum, if the app is wanted to be used in landscape mode.

Well, I am aware of that more than four entries reduces usability in landscape orientation, though it is technically possible and basically still usable with five entries. But as there are currently three entries, this is a non-issue, right?

  • Well, who is "we"? Feel free to submit a PR.

I wanted to hear opinions from other users and people who follow the discussion in this repo. As this is a community, I tend to think it as "we".

No:

  • Communities comprise individuals. A "community" never thinks or acts as a whole, it is always the individuals who do. Consequently a statement as "How about we do XYZ?" is never appropriate in a true community, in contrast to "I can contribute XYZ.".
    "How about we do XYZ?" may be acceptable for a team leader who intends to provide a "team-building" "we-feeling"; still this is trying to fool people with words, as a team leader usually only organises an endeavour, but is not doing "real work" rather than delegating it.
  • There are no "other users and people who follow the discussion in this repo": It is just you an me discussing here. While there may be people participating "passively" / "silently" (i.e. just read) here, it is unlikely anybody else reads this.
  • Especially in the context of SailfishOS the term "community" has been abused right from the start: For Jolla it means "beta testing monkeys who serve us" with this term (consistently over 12 years), app developers are not in focus, contributing to SailfishOS was a completely foreign concept until very lately. They convinced me over the course of a decade, that they will never understand how Open Source Software development works together with a community to benefit all, due to the arrogance and ignorance some crucial sailors regularly exhibit. Still, it would be so easy, if they just analyse how well it worked and still works for the ancestors of SailfishOS: MeeGo and ultimately Fedora Linux, with proper processes and structures in place, such as FeSCo, the Fedora change process. But most importantly, Fedora, OpenSUSE etc. are developed in the open (i.e. fully publicly): No "internal" repositories, bug trackers, Wikis, discussion forums etc.; so it basically was for MeeGo, too (with some limitations).
  • At FSO I have very little "community feeling": Way too many clueless people, some idiots and a few assholes (as @throwaway69) make me feel rather alien there, in contrast to TJC (together.jolla.com).

I didn't want to make any demands or promises.

I did not read your statement that way, you simply fully concealed who do you think of doing XYZ (here: implementing your suggestion) by using "we".

Yes, that would be ideal.

Good, but apparently not really "ideal", because …

  • Does swiping left to leave the "Lyrics" page bring you back to the "Album view" page currently, as one would expect then?

Swiping from left (or to right) goes back to the song page that was opened by clicking the album cover. It sure would make more sense to go back to Album view page, if the "Show lyrics" top pulley menu item is used.

… this would introduce an inconsistency.

  • I.e. is there anything else to implement than a pulley-entry which opens the extant "Lyrics" page?

The logic needs to be changed to back to the previous page, which is either Album view page or Song view page.

By using such an pulley entry to open a QML-page …

MenuItem {
   text: qsTr("Add to playlist")
   onClicked: {
      maySetSomeVaraibles = "foo"
      filterSong = model.url
      pageStack.push("Lyrics.qml")
      }
   }

… one automatically returns to the previous page when swiping sideways.

But I currently do not understand the code of AlbumListView.qml, SongsPage.qml and Lyrics.qml, e.g. how is the Lyrics.qml page called from the SongsPage.qml without referencing it?

After thinking about it, I believe a single out of four pulley menu entries on the AlbumListView.qml page which is context-dependent (on which song currently plays) is good and intuitive usability, but currently lack a better idea. Maybe using an entry name as "Current song's lyrics" can alleviate this a bit.

The Song view page has already 4 top pulley menu items, so I guess it could be kept as it is.

As stated, five entries is also feasible, but three ways to reach the Lyrics.qml page is a bit much IMO. But keeping the Lyrics.qml page reachable from SongsPage.qml by swiping left is necessary for users who use it this way: I would expect them to complain if this usage is eliminated without a proper reason.


I originally thought I might be able to address this in a simple way with my little QML know-how, but after quickly looking at the code I doubt that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants