Library layout redesign

[jmigual]

Hello,
during this summer I've been redesigning the Library GUI.

This is a GSoC project and the complete info about the project can be found here:
http://www.mixxx.org/wiki/doku.php/library_layout_redesign

This PR is a continuation of #975

A small list of the changes is:

• Now there can be one, two or more track table panes where the features can show their tracks, info...
• In the MixxxLibraryFeature there's a new tree allowing the users to use all the power from the SearchBar queries, it acts like a query helper.
• A new feature is added FoldersFeature, this feature shows the tracks added into the Mixxx Library sorted by their folder.
• The maintenance tab from MixxxLibraryFeature has been moved to it's own feature MaintenanceFeature.
• The sidebar is separated in a buttons sidebar (sidebar buttons) + tree sidebar (sidebar expanded)
• The sidebar buttons can hide or show the text allowing more space
• Now the scroll bars have a scroll helper which shows in which position the first letter of the current sorting is. When you change the sorting the scrollbar helper changes too to the new sorting.
• Added a breadcrumb to allow visual feedback and not confuse the user
• Added this new library behavior to all officially skins (Shade, LateNight and Deere).
• Added sticky views, now a search query can be saved and restored later.

Here are some images of the new layout in the skins:

Sticky views, can be saved or restored, the buttons from left to right:

• Clear search
• Save search
• Restore search (opens a drop down menu with the saved searches)

Example in sidebar buttons with text hidden / shown:

The new Library tree, the sorting can be changed in one of this:

• Artist > Album (shown in the screenshot)
• Album
• Genre > Artist > Album
• Genre > Album

The folders feature supports multiple source folders location

Example in scroll bar helper, in this example tracks are sorted by title:

[daschuer]

The keyboard control is working. Apart from the general design question, there is "only" the midi interface missing and of cause some bugs.

Does the current way of keyboard control work for you? I would be happy to read your suggestions here? Maybe you cold also help to implement the midi mapping interface?

[timrae]

the general design question

Could you please summarize the unresolved points about the design?

there is "only" the midi interface missing and of (course) some bugs.

Are there some steps to reproduce these bugs, or just a general feeling of "bugginess"?

Maybe you could also help to implement the midi mapping interface?

Other than what was discussed in #953, what is required?

[daschuer]

the general design question

Could you please summarize the unresolved points about the design?

We had the original Idea:
A "Total Commander" or "Nemo" like view. Since, unlike a file manager, we have different types of views for the features, it turns out in live tests that a feature swapping its pane is confusing.

As solution, we have now a feature pane association and a preselect button to explicit swap the panes.

Since this now does not behave like "Total Commander" or "Nemo", it is confusing for other users.

There are to alternatives discussed:

• Independent left and right parts: Library layout redesign #991 (comment)
• replace the right part with tabs.

there is "only" the midi interface missing and of (course) some bugs.

Are there some steps to reproduce these bugs, or just a general feeling of "bugginess"?

The most notable one its that the model allows to show the library twice, but the back-end does not yet support that well. @jmigual has offered to add a Null Feature, which can replace the previous pane in case of a swap.

Maybe you could also help to implement the midi mapping interface?

Other than what was discussed in #953, what is required?

In general, your model will fit to the current solution.

We need to define/verify a clean CO interface, that works well for a
left / right / up / down / load controller and for a
Knob + Enter + Back controller.

Old mappings should continue to work somehow.

Here is the original design page:
http://www.mixxx.org/wiki/doku.php/library_layout_redesign

Do you have fun to work on this? You may prepare a PR against @jmigual s sjmigual:libraryLayoutRedesign

I will hunt the bugs, once I find time.

[Be-ing]

There are to alternatives discussed:
Independent left and right parts: #991 (comment)
replace the right part with tabs.

I have not seen the "replace the right part with tabs" idea described anywhere. Could you elaborate? I have an idea of what you mean and I'm guessing it wouldn't be as flexible as independent left and right parts.

[daschuer]

I think the original tabs Idea was proposed by @ferranpujolcamins Ferran, but I cannot find it yet.

[Be-ing]

I think the original tabs Idea was proposed by @ferranpujolcamins Ferran, but I cannot find it yet.

Is this mailing list post what you are referring to? I think that is overcomplicated and would pretty easily get cluttered with tabs unlike the mocked-up design above.

[naught101]

Hey all, this looks totally awesome. I'm really keen to try it. Especially looking forward to

• Now there can be one, two or more track table panes where the features can show their tracks, info...

It will be great to be able to minimise swapping between panes via the library side-bar.

One change that I would add if I had a magic wand would be something like this:

This layout would be pretty close to perfect for me - it's often useful to be able to quickly access the most recent few history items, to update tags or whatever, without constantly switching views. Basically, the three things I want to be able to do are: 1. keep track of what's coming up, 2. on-the-fly re-crating/rating played tracks, and 3. searching for new stuff. A three-part interface would be ideal, but if it were three panes side-by-side, then it would be difficult to fit everything important in (track name, artist, BPM, key, duration, rating, [album, genre, year]).

Of course, that suggestion probably complicates things massively, and I wouldn't expect it to be implemented in this pull request (or maybe ever), but I figured I'd throw the idea out there anyway.

Is this PR stable enough for user testing? I mean, I don't mind buggy interfaces, as long as it's not going to screw up my library data. If so, I will try to give it a go soon.

[timrae]

I had a play with this branch today... My initial thought is that I don't like the double "right pane" arrangement. I think the concept has potential but it's not mature / intuitive enough yet to merge, so I recommend pulling it out for phase 1.

After removing the second right pane from the xml layout, everything feels pretty familiar; it's basically equivalent to the existing (i.e. master branch) design but with the main difference being that we now have the left button bar for switching between which features are shown in the left (tree) pane, and the right (list) pane. I think this both looks and works well, and it could be merged with a few tweaks and bug fixes.

A few important points to note:

• The "playlists" feature is currently broken. That needs to be fixed before merging.
• The "folders" feature is not really intuitive. I think the concept needs more work and recommend pulling it out for phase 1.

I feel that this PR has some good work in it, and that if we can build a consensus on a subset of the features then I'm happy to help @daschuer in helping to do whatever needs to be done to get it included in 2.1 (assuming that's even feasible).

@daschuer

We had the original Idea:
A "Total Commander" or "Nemo" like view. Since, unlike a file manager, we have different types of views for the features, it turns out in live tests that a feature swapping its pane is confusing.

As solution, we have now a feature pane association and a preselect button to explicit swap the panes.

Honestly I don't really get it... I haven't used either Total Commander or Nemo sorry. However, what do yo think about just starting with a single feature pane (aka "right pane")? Doesn't this remove most of the complexity?

We need to define/verify a clean CO interface, that works well for a
left / right / up / down / load controller and for a
Knob + Enter + Back controller.

Do you have fun to work on this? You may prepare a PR against @jmigual's libraryLayoutRedesign branch.

I have implemented all the controls in #953. The controls are not really related to this PR in general, so I have updated my existing PR against the master branch. After merging that we can look at merging this PR with masters and resolving all of the merge conflicts, then doing some simplifying, and bug fixing.

How does that sound? If we can build the consensus and prepare a list of things that need to be done for the library layout redesign then I'm happy to help out... Realistically I could probably afford to spend around 5 days of full-time work on it over the next month.

[daschuer]

@naught101:

Thank you for you nice Mockup and your comments.
I think you design should be already possible, since we support N panes. (Your N is 3).
It is only a matter of the skin.

This branch still suffers from some bugs. But the library data itself is not effected. I have actually used it on a friends birthday party, and it works somehow good. But there is no guarantee, so you should backup your .mixxx folder anyway.

[daschuer]

@timrae:

I had a play with this branch today... My initial thought is that I don't like the double "right pane" arrangement. I think the concept has potential but it's not mature / intuitive enough yet to merge, so I recommend pulling it out for phase 1.

Yes that is the remaining strong issue. I would be very happy if we get a single pane version merged into master, since it already includes some nice features.

• The "playlists" feature is currently broken. That needs to be fixed before merging.

• The "folders" feature is not really intuitive. I think the concept needs more work and recommend pulling it out for phase 1.

Yes there are some pending issues, could you describe your particular once?

I feel that this PR has some good work in it, and that if we can build a consensus on a subset of the features then I'm happy to help @daschuer in helping to do whatever needs to be done to get it included in 2.1 (assuming that's even feasible).

We could work for 2.1, but we shouldn't rush for it. Since it was original planned to publish 2.1 tree month after 2.0 we may pick any suitable commit form master between 2.0 and now and declare it to 2.1.

Honestly I don't really get it... I haven't used either Total Commander or Nemo sorry.

If a user like set Mixxx to its desired layout (let's say as shown in @naught101 's mockup) He will hate if this changes during the Mixxx accidentally. This happens to me in a very first version where the QT input focus was coupled with the preselection button.

However, what do yo think about just starting with a single feature pane (aka "right pane")? Doesn't this remove most of the complexity?

Yes, lets go for it!

How does that sound? If we can build the consensus and prepare a list of things that need to be done for the library layout redesign then I'm happy to help out... Realistically I could probably afford to spend around 5 days of full-time work on it over the next month.

Wow! Thank you a lot :-D

[Be-ing]

Getting a single track table version of this in for 2.1 would be nice.

[timrae]

Yes there are some pending issues, could you describe your particular once?

There are supposed to be several playlists listed in the "left pane", however there are none.

Also, I feel "Folders" doesn't offer much benefit in addition to "Library" and "Browse". I feel that users will find it confusing / frustrating, and the implementation doesn't feel complete. I suggest handling it in a separate PR and focusing on features that we can all agree are ready for merging.

[rryan]

I think this would delay the 2.1 release since there are likely to be new bugs we haven't found yet that a beta would reveal. As soon as https://bugs.launchpad.net/mixxx/+bug/1653368 is fixed, we should be able to do a 2.1 beta. I think master is pretty stable at this point, so the beta period wouldn't need to be long.

Once we have stable builds for Windows again, we can start releasing more often (every 4 months would be nice) so hopefully that can alleviate our desire to feature creep. Right now if you don't get into the yearly release you have to wait a year, and that's no fun :(.

[timrae]

Right now if you don't get into the yearly release you have to wait a year, and that's no fun :(

Sorry I don't understand what you mean by that...?

[rryan]

Right now if you don't get into the yearly release you have to wait a year, and that's no fun :(
Sorry I don't understand what you mean by that...?

Our historical rate of releases averages out to about one big release per 1 or 2 years. So culturally on our team and especially around feature freeezes there is a high pressure to feature creep since it's more fun to have your work in the hands of users faster. We've wanted to change to faster releases for a while.

[timrae]

Ah right yeah I get you. Anyway, let's discuss which release this goes into once we have something to talk about. IMHO there's no reason to prematurely shut down the possibility that it could be included in 2.1 until you see the code that we come up with out of this PR.

[timrae]

@daschuer
How can we work together on this? What's the strategy?

[daschuer]

We need to fork this branch an tweak it for master.
This one should be keep as a preview to a future N-Pane layout.

For the new branch we can do immediately a work in progress PR with a Todo list on top:
Like this:

• for an empty checkbox
• for a checked checkbox

Than we can decide about the important points that are required for a merge.

Anyone who has fun and time can pick a TODO and issue a PR to the branch of the work in progress PR branch.

@timrae do you have already an idea what you what to do next?

@jmigual what do you think?

[jmigual]

@jmigual what do you think?

I think I understand the concept. So, we will do a single pane PR with a TODO and some things to fix?

Actually the code supports showing only a single pane. So, removing the multipane code in the skin.xml and then removing the preselection icon should be enough to disable the multiple panes.

Now only remains the TODO list, what should be essential to be in this PR? Of course fixing the playlist bug its a must.

---

Also, I feel "Folders" doesn't offer much benefit in addition to "Library" and "Browse". I feel that users will find it confusing / frustrating, and the implementation doesn't feel complete. I suggest handling it in a separate PR and focusing on features that we can all agree are ready for merging.

@timrae This was added because some users where complaining that they add their library folder but then their hierarchy is not preserved in the Library Feature. And you're right in this PR there are many features added at once. Maybe splitting it in multiple PR will make it easy to review, find bugs...

[timrae]

We need to fork this branch and tweak it for master.

Yes, before we can even start discussing / working on this, someone needs to fork this branch, resolve the merge conflicts, and create a new "Library Redesign Lite" PR. I don't feel comfortable to do this obviously, so I think it should either be @jmigual or @daschuer.

Once the above is completed, we include a checklist at the top of the PR starting with the following:

• Update the skin to use a single pane
• Remove the "Library" feature
• Fix the playlists feature

From there we can start the real testing, adding items to the list as we find bugs or points of contention, and either fix or remove (for another PR) the features in question.

@jmigual & @daschuer:
Realistically how much time do you think you will have to work on these things over the next couple of weeks?

[jmigual]

• Remove the "Library" feature

Do you mean the "Folder" feature?

Realistically how much time do you think you will have to work on these things over the next couple of weeks?

Until February I won't have time because now I'm on final exams. Also what you are requiring should take a morning to complete.