Open cr7pt0gr4ph7 opened 3 weeks ago
cr7pt0gr4ph7
commented
3 weeks ago Huh, seems like I found a slight bug with the code formatting rules when confronted with changes in files that contain old, wrongly indented code. Fixing the indent of the old code makes the issues with the new code disappear... so that's what I will be doing. Don't know enough about clang-format to know if there's a config option that would fix this.
ronso0
commented
3 weeks ago Just a hint: IIRC from a related discussion, one of the reasons to keep the search disabled in Auto DJ was that it is not obvious that the view is filtered. A possible solution, also relevant here IMHO, would be inserting narrow, empty dummy lines where the invisible tracks would be. Not sure how that could work though.
cr7pt0gr4ph7
commented
3 weeks ago Just a hint: IIRC from a related discussion, one of the reasons to keep the search disabled in Auto DJ was that it is not obvious that the view is filtered. A possible solution, also relevant here IMHO, would be inserting narrow, empty dummy lines where the invisible tracks would be. Not sure how that could work though.
Okay, I understand the concerns. I tried to look up the discussion you where mentioning, but couldn't find it. After thinking a bit about it, let me explain my reasoning why I think this is should not be a problem in practice.
cr7pt0gr4ph7
commented
3 weeks ago Update / TLDR: See my comment below for an overview, and then possibly come back for the detailed reasoning here.
As I see it, there are three problems to be avoided here:
How do we avoid users from being confused by not being able to see all tracks in the Auto DJ playlist?
Consistency: I'd argue that because the same can be said about filtering the main library, playlists and crates, users should learn about this behavior pretty quickly simply by us being consistent throughout the application. If we worry about that, we should worry about the other places in the application, too.
Teachability: As soon as a user starts to type in the search field, they see the immediate effect of the list being filtered. If they reverse their recent action (entering the text/one more character), the original list is being shown again. I'd argue that this is a pretty effective way of teaching user's how filtering works. And if you never use the search field, you are never confronted by this anyway.
Visual Indicators: The entered search is stored separately per library view. There is the chance of forgetting that you entered a search term in this view before, but I'd argue that by combining the visual indicator of the search field's text changing with the fact that this can happen everywhere else, too, users will quickly (and also have to) learn to check the search field in those cases anyway.
How do we avoid users from being surprised that a track they couldn't currently see was picked as the next track by the Auto DJ?
This one's a bit trickier, but I think it again boils down to:
If we look to e.g. Spotify, they have a similar feature for filtering playlists, with the same behavior as implemented here (filtering hides tracks temporarily but still plays them). I'd guess they've done a lot of usability testing and A/B testing,
How do we avoid users from being confused because they can't see any tracks (due to their search terms filtering out all available tracks)?
This may be an actual problem in practice (at least when going from my own, personal experience/confusion), but isn't limited to the Auto DJ view. The confusion mainly stems from the fact that my perception that I have successfully switched to a different library view is based on the list of tracks in the track table changing.
My suggestion would be to insert a visual indicator when some (or all) tracks have been filtered out due to the current search and/or when the current playlist/crate/view didn't contain any tracks whatsoever even before filtering. There are two alternatives I can think of (centered text in the background, or an unselectable "phantom row" at the end of the tables), I'll try to craft a proof-of-concept pull request.
cr7pt0gr4ph7
commented
3 weeks ago These are just my two cents, though. I appreciate feedback whether I missed something!
As an aside, here are possibly related issues from the past that I could find:
If if I infer everything correctly, the limitations for searching & sorting the Auto DJ queue were primarily motivated by technical restrictions, and not by user expectations. As explained by @daschuer in this comment on #6335, most users probably expect the Auto DJ queue to behave like a playlist.
cr7pt0gr4ph7
commented
3 weeks ago My personal, real-world use case that motivated this PR is this:
I have prepared a 3 hour/100 track playlist in the Auto DJ queue for a dance party, and want to remove a specific track from the queue because I have added another copy of it near the top of the queue during the course of the party.
Without neither search nor sorting, this is an arduous task - that's why we have search. Inserting narrow placeholder rows or greying out filtered out tracks instead of fully hiding them would be slightly better, but would still force me to scroll through a large list of tracks.
It seems to me that there are three camps of users:
Those that want to interact with the Auto DJ just like with a playlist, including sorting & filtering, and whose mental model is that Mixxx will play the underlying playlist, and not their filtered view of it. (This is the solution proposed here, and the one employed by other music players like Spotify)
Those that expect the visible list in the Auto DJ view to be what will be played, including sorting (and probably filtering, for the sake of consistency). There are some consistency problems with implementing this IMO, but it would be possible. (This is the solution proposed in #6335 AFAIU)
Those that fall in the middle of not particularly needing to filter a large Auto DJ queue, and either do not expect the filters/sorting to affect the play order, or do not care because they don't use (or know about) it anyway. The main concern is to prevent those users from accidentally shooting themselves in the foot through unintended filtering. (This correlates with the compromise of greying out tracks instead of hiding them, as proposed before).
And the fourth solution: Disabling search to postpone a decision on the behavior.
I think that the second solution conflicts with how playlists (that is, the specific objects called "playlists" in the UI, not the general concept which also includes in the Auto DJ queue) behave currently in Mixxx, and thus is undesirable in my opinion, but could be solved using a config option or separate feature. The third and fourth solutions are compromises that give noone what they want, except for the people that do not need or use the feature anyway.
ronso0
commented
3 weeks ago Thanks for elaborating!
Visual Indicators: How do we indicate that the playlist is currently being filtered?
- The same way as in all other library views: By there being text in the search field (and maybe an additional visual indicator, see below).
tracked by #7922
ronso0
commented
3 weeks ago How do we avoid users from being confused because they can't see any tracks (due to their search terms filtering out all available tracks)?
I think a status bar / info bar could also solve this. (stale PR #3406).
an unselectable "phantom row" at the end of the tables
That help much IMO. If the filtered tracks fill the view such a bottom row would be visible.
cr7pt0gr4ph7
commented
2 weeks ago I can confirm your use case.
However, I am strictly against filtering and sorting in the Auto-DJ playlist. The reliable view what will happen next is, IMHO much more important than any desire for sorting and filtering.
After giving it some more thought, I can't really come up with a valid use case for sorting an already running Auto DJ playlist, either, so we can restrict the discussion to filtering only, and see whether we can find a good solution for that.
I often search for a successor and forget to go to the Track view first. If that happens with Auto DJ late at night, even a warning bar would be not enough, considering other visual clutter we have already.
Yeah, I'd be kind of opposed to a warning bar / status bar at the bottom of the screen, too, due to its distraction potential. The search bar is basically the main entry point for starting to interact with tracks/playlists (see #13200), so any visual indicators or such, if any, should be in close visual proximity to it or the track list, because that are the places users will look at.
I think that your use case is very valid. Just to understand correctly, what are your main concerns/issues you want to avoid?
Also, for clarification, are you using an external DJ controller or a Mixxx-only setup? (For context, I'm running Mixxx on a laptop and do not have any experience whatsoever with external controllers).
I like however @ronso0 idea to highlight and probably select and auto scroll to the filter matches. That is IMHO quiicker as a normal filtering for your tracks. You just need to press del and the tracks are gone. What do you think?
I don't know about introducing a whole different behavior of the search control just for one library view, though. That has a great potential for confusion, and feels a bit like overkill. I like the idea of scrolling, but that only works well for a single selected track. As soon as multiple tracks are selected, you have to find a way for the user to see that there are offscreen track which are selected, and for the user to cycle through those tracks, ... it removes one potential issue but creates others.
cr7pt0gr4ph7
commented
2 weeks ago The best solutions I think of so far (based on the suggestions here and elsewhere) are:
| # | Title | Artist | Album |
|---|---|---|---|
| 1 | ... Filtered out ... | ||
| 2 | Some track | A | B |
| 3 | Some other track | A | B |
| 4 - 8 | ... Filtered out ... | ||
| 9 | Another track | C | D |
| 10 - 50 | ... Filtered out ... |
ronso0
commented
2 weeks ago I like however @ronso0 idea to highlight and probably select and auto scroll to the filter matches. That is IMHO quiicker as a normal filtering for your tracks.
For the record, I didn't propose that (here ; ) Maybe in some ancient combo. I agree it's bad UX)
Let's take a step back and ignore the imlipcit constraints we set when thinking of the AutoDJ as a regular (playlist) view, e.g. when sorting all rows are sorted, when filtering the filter is strict, no exceptions.
There are basically two situations where filtering and/or sorting can be applied, AutoDJ ON or OFF, but IMO there are different constraints / requirements / expectations:
In both situations filtering / sorting may be desired, mostly like in playlists:
So if we now have a somewhat independent table model (at least we can tweak the filtered view to our liking) could it be possible to present the filtered view differently?
What do you think?
daschuer
commented
2 weeks ago I agree the next 1, 2, 3 queued tracks should always be visible
I can confirm. They can be grayed out or such. That's still ok for me.
For the rest, the view proposed in https://github.com/mixxxdj/mixxx/pull/13337#issuecomment-2156151728 works for me. However I would prefer to see all of them grayed out. This should be more easy to implement. From there we can than interate after some brief testing.
cr7pt0gr4ph7
commented
2 weeks ago Let's take a step back and ignore the imlipcit constraints we set when thinking of the AutoDJ as a regular (playlist) view, e.g. when sorting all rows are sorted, when filtering the filter is strict, no exceptions. [...]
I agree with your analysis.
I agree the next 1, 2, 3 queued tracks should always be visible
Yeah, that would work for me, too. We could maybe implement these "next tracks" kind of like pinned table rows that are always visible. That would also make the (probably pretty common) use case of dragging something from later in the queue to e.g. the third place pretty easy.
Update: Maybe like this? (Not implemented yet, just a quick mockup using GIMP)
Enforce the # column, always left most column, paint it in a special way if the queue is not sorted by #. Maybe turn it into a vertical header so it's always visible?
Pinning the '#' column so it is always visible (even when scrolling to the right) sounds good. That would also reinforce its special meaning.
If we decide to allow sorting, highlighting the '#' sounds like an idea we can try, although I'm a bit cautious to not add too much visual noise. But if we decide to do that, we could combine it with a tooltip when hovering over the highlighted '#' column that explains "Sorting only affects the visual display. Play order is indicated by the numbers in the '#' column.".
As an additional idea, we could also put an orange border around the Auto DJ view to indicate active filtering/sorting.
However I would prefer to see all of them grayed out. This should be more easy to implement. From there we can than interate after some brief testing.
I need the filter to reduce the number of visible tracks, so that all (or most) tracks found by the filter are visible on the same screen, so hiding/collapsing at least some of the tracks would be required for me. I'll have a look at implementing a proof-of-concept.
When filtering, indicate that tracks (spans) are hidden by replacing the hidden tracks with some sort of placeholder? an empty row that is only half the height of a normal row, perhaps with filled with a gradient or other type of infill that distinguishes it from a regular track row?
Yeah, some visual indicator would be good. Just graying out tracks conflicts with the "already played" indication of tracks, so we have to be at least somewhat different to that. Although maybe a different, darker grey is enough. I'm not a huge fan of half-height rows because they disrupt the vertical visual rhythmn, but maybe I'm just prejudiced.
daschuer
commented
2 weeks ago Let's not allow sorting.
What is the reason you need to see all filter matches on a single page?
If we pin the first four, and than replace the hidden rows with a single line as you demonstrate above that could work. Maybe with a + icon to uncollapse these rows and remove the filter.
The search feature for the Auto DJ view was originally disabled by 54f71ea7b8e5d6e87ad9132bcf7fdfe2a7c8372a over 12 years ago.
We now have some new tools available, which means we can implement a workaround instead of disabling search altogether. Searching within normal playlists is already possible and works correctly, and the Auto DJ queue is basically just another playlist, so being able to search there matches user expectations.
The implementation here reuses the
ProxyTrackModelcode already used by the file browser view for the actual filtering behavior (4970e30b0fd67ff3d2094bb080ec2ff749ef3701). Most of the changes here are for makingBaseSqlTableModelplay nicely withProxyTrackModel(75ce4d0a48d672249100bbaa9da7c00959575f09), for making cut, copy & paste work (62c3a0f0435121e0ebbdc800ca1f6c657fa72a39) and behave correctly w.r.t. keyboard focus (35569a49f71955256cb8f514be2ef25f9de94b4f).