|
|
C would probably the choice I would implement. |
|
|
Ludek, fyi, the issue is that once the user has clicked e.g. [x] Music, they no longer realize that it's possible to select only a subset of Music because the music tree is hidden. I agree that C is probably the best solution, however, it had previously been implemented but was changed for reasons described at 0015985:0055211. Any ideas for a simple solution given the technical challenges? |
|
|
What about introducint '[x] Sync all content' checkbox on the right like this: This new checkbox would just mirror state of the '[x] Music' checkbox on the right and would be shown just when [x] Music is checked (in order to make clearer that all collection content is going to by synced) image.png (30,299 bytes) |
|
|
Alternativelly the new checkbox could be called '[x] Select all files' to be more compatible with the 'Sync random subset of selected files...' checkbox below. |
|
|
The root problem is that it's not obvious that the subnodes on the right are children of the selected node on the left (the consequence being that in earlier iterations of the UI, users didn't understand why selection of top level nodes greyed out subnodes; now they don't realize that subnodes for a selected node can be selected without selecting the parent). The real solution is to make the relationship more obvious. I would suggest: 1) The UI should display a divider between the 'collections' and subnodes so that it looks more like a file explorer. 2) For the Collections: instead of making the checkboxes selectable, just show status indicators so that the user knows whether a given 'collection' is configured to sync 3) Move the 'Collection' selector to the top of the subnodes and show it as 'All x' e.g. '[ ] All Music'. If selected, just grey out all the subnodes. If deselected, revert to the subnode selections. sync-tree-tweaks.jpg (46,907 bytes) |
|
|
Fixed in 5.0.4.2663 Note that I keep the checkbox also in the collections list (rather than the sync icon) as it is more informative, i.e. shows also the partial check state etc. i.e. the two checkboxes are now mutually in sync, checking one checks also the other and vise versa image-2.png (26,801 bytes) |
|
|
Verified in 2663. |
|
|
Apologies about re-opening, but I don't know how to add a testing note if I don't do this. There still seems to room for confusion, see attached image. ie. checking the top level 'All" node in the right hand panel, does not cause all sub-nodes to be checked. I tested with v 2663 https://www.dropbox.com/s/r5ww8hhaqsoqfa6/confusion%20from%20sub-nodes.png?dl=0 |
|
|
A couple of other issues: A) Deselecting a subnode causes the root rode's checking to go through a long animation. e.g. . 1 Select All Music > Artists . 2 Select All Music . 3 Deselect All Music . 4 Deselect Artists --> Music node repeatedly shows a 'partially selected' animation Note: I would fix this by removing the checkbox functionality from the Collection nodes (and instead just use an icon to indicate inclusion . It's confusing to have two different checkboxes that accomplish the same thing (it's not obvious which should be selected/deselcted). B) The light/dark 'Row indicators' shouldn't appear for the Collections (they should only appear for the 'details') |
|
|
Re the Barry's note 0018743:0069344 => this is intended (same as MM4) and easily allows user to toggle between all content and selected subset of the collection. I found it useful and don't think that this needs to be changed ATM. That said we can track it as separate issue, but not with 5.0.4 target. A) I would rather fix this just by disabling the animation -- in order to eliminate effort spent on this minor issue. B) Can you eleborate which light/dark 'Row indicators' do you mean? |
|
|
I'm not clear about the requests raised at 0018743. I've asked for feedback within that bug and set the target to 5.1. A) OK--though this is a real usability issue. Wouldn't it be trivial to make the collection checkboxes read-only? B) See attached. alternating-rows-in-sync-tree.jpg (60,060 bytes) |
|
|
A) OK, good idea, made the checkboxes on the left read-only B) OK, fixed |
|
|
A) This is confusing, checkbox should not be shown if it can't be selected. As it's useful to show selection state, it should be re-enabled. Now a user is left wondering why the checkbox fails to work. Alternatively a different indicator needs to be used. |
|
|
A) Agreed: my intention was for it to also _appear_ read only (e.g. greyed out) so that users don't try to click it. (ideally the indicators wouldn't even appear like checkboxes, but based on Ludek's previous feedback, changing from these controls would be too much work at this stage). |
|
|
--- Rusty: " my intention was for it to also _appear_ read only (e.g. greyed out) so that users don't try to click it. (ideally the indicators wouldn't even appear like checkboxes, but based on Ludek's previous feedback, changing from these controls would be too much work at this stage). I agree with Ludek's point that the current behaviour has benefits. I still think that it heads to confusion. https://www.dropbox.com/s/eagqu1dhjj2wcgy/which%20is%20right.png?dl=0 I think that you were on the right path by wanting to lose the checkboxes when ALL has been selected. Maybe Ludek can get the same result easily, by auto-closing all of the sub-nodes before disabling them ... ie. that way none of the checkboxes are visible, and you want anomalous situation as shown in my link above |
|
|
OK, I agree with LowLander that read only checkboxes (or disabled) looks like a bug/regression => reverted in 5.0.4.2665 And I also agree with Barry that collapsing the tree is the better way => implemented in 5.0.4.2665 Please test in 2665, I think that it works fine finally and the original confusion is eliminated (by adding the '[x] All Music' checkbox on the right). |
|
|
Verified on 2665 |
- Anonymous
