On Mon, Jun 6, 2016 at 1:50 PM, Joan Marcè i Igual <j.marce.ig...@gmail.com>
wrote:
> Hi RJ,
> thank you for your thoughts
>
>
>> I see -- thanks for the explanation. Sorry to nit-pick but could I push
>> for more salient names for these? I think it's already causing confusion
>> :). Skin designers will probably also be confused.
>> We already have <LibrarySideBar> and <Library> XML nodes.
>> What about <LibrarySidebar> for the button bar, <LibrarySideBarExpanded>
>> for the expanded sidebar view, and <Library> for the track tables?
>> Instead of Left and Right? Since from what I understand, LibraryLeftPane
>> is the expanded sidebar view for the feature?
>>
> Yes it is, I like your names so I will be using them since now for the
> skin.xml (I'll update it in the wiki as soon as possible)
>
> I think I'm getting what you mean -- let me restate it to make sure:
>>
>> Each library feature will have two "loadable views" associated with it --
>> the expanded sidebar view and the track table view. (e.g. in the case of
>> Playlists, the tree view of current playlist names and the track table view
>> for the currently selected playlist).
>>
> Yes it's exactly like this
>
>
>> Request: In future emails can you pick more descriptive words than
>> right/left? Instead use a word that describes its purpose so we can be sure
>> we're talking about the same thing.
>>
> Totally agree, it can lead to a lot of confusion what about:
> Button Bar becomes Library Side Bar (as you suggested with the skin XML)
> Left Pane becomes Library Side Bar Expanded (as you suggested too)
> Right Panes become Library Track tables
>
>
>> I think instead of coupling the track table view and the sidebar expanded
>> view together into a "LibraryPaneManager", the expanded sidebar view should
>> instead be associated with the selected feature in the library
>> side-button-bar. I don't see a strong reason for coupling the current
>> selected track table view with the current selected expanded sidebar view.
>> It seems it will limit use cases we're discussing where you switch around
>> to different parts of the library while keeping a previously selected
>> playlist/crate open to drag/drop tracks. Additionally, since there can be 1
>> to many "Right" (library track table view) widgets -- it seems we are
>> already going break the coupling logically.
>>
> This is because in the LibrarySideBarExpanded when the user opens the same
> feature multiple times int different library track table view widgets and
> focuses one of the track widgets the expanded sidebar should change too (in
> the Nemo file manager this is shown) to reflect the current state of the
> focused pane. This allows the user to have different sidebar expanded
> states for different track tables.
>
> For example if I have about 100 crates and in one track table I open the
> "crate 1" and in the other track table I open the "crate 100" when I click
> the "crate 100" track table I want the Sidebar Expanded to show the tree
> with the "crate 100" selected and if I click a track in the "crate 1" track
> table I want the Sidebar Expanded to show the tree with the "crate 1"
> selected.
>
>
Interesting -- do Library Track Tables need a title now? In Mixxx 2.0 we
know what playlist is selected based on the highlight in the sidebar tree,
but this may be harder to tell in particular because the focus highlight is
somewhat subtle. Maybe we could clear up the need for keeping this
highlight in sync by adding a title to the track tables. For example, when
you have AutoDJ and Playlist: Foobaz showing, if the sidebar expanded is
showing the list of playlists with "Foobaz" highlighted then you have no
way of know what the AutoDJ track table is (other than seeing the ADJ
buttons).
Or, for the specific case of two playlists showing at the same time -- each
library track table could be styled with a particular color (e.g. a rim
around it or a background color / alternate row color), and the expanded
sidebar can put a colored dot next to each playlist to signify which
library track table they are loaded.
>From a UX perspective, I think I may find it jarring if changing the
focused library track table caused the library sidebar expanded to change.
It may even be frustrating if I was trying to do something with the sidebar
in the state that it was in and then changing the focus made it change even
though I didn't touch the sidebar at all.
(and now some ramblings:)
IMO, apps that have "action at a distance" can be frustrating because you
have to fiddle with it to get it into the state you want -- if every action
only has local consequences then that can lead to simpler mental models and
less fiddling needed by the user. Sometimes this comes with a cost of extra
user actions needed but that's a trade-off.
Examples of what I mean by "local consequences":
- Click "Playlists" button bar item -> loads playlist list into the
expanded sidebar.
- Drag "My Playlist" from playlist expanded sidebar view to one of the
track tables -> loads that playlist into that track table.
- Hit "X" button on track table view to dismiss/close it -> closes just
that track table view with no other side effects)
> I will be waiting for your answer,
> Joan
>
>>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
