View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010912 | MMA | Synchronization | public | 2013-05-24 22:20 | 2022-12-01 21:41 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0.4 | ||||
| Target Version | 2.0.0 | Fixed in Version | 2.0.0 | ||
| Summary | 0010912: Delete tracks confirmation dialog is difficult to navigate for large sync lists | ||||
| Description | If the user has a large number of tracks being deleted, the confirmation dialog isn't that useful because all tracks are listed in a single list by track. A couple of possible solutions would be: a) retain a list, but allow users to choose the sort order (e.g. By Track, By Artist, or By Album) b) allow the user to view by Track, or by Artist > Album > Track (i.e. a tree) Some form of b) probably makes more sense, since it should be possible to easily see what's being deleted by content type (e.g. videos vs audio files). | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=70171 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1005 | ||||
|
|
I think that there is quite no advantage to have the confirmation as dialog. We plan to change UI to use side pane. So we can maybe to use this pattern here too. So confirmation dialog can be actually something like confirmation activity with its own navigation so we will be able to show it more hierarchic. It can be implemented after new tablet layout will be implemented. I can create some layout. I think that there should be some simplified options (scenarios) too so the user doesn't have to check or uncheck all checkboxes like: 1) I want exactly what is on server - this will download everything from server and delete everything else on MMA 2) I want preserve all tracks and playlists - this will upload from MMA to MMW and syncs 3) ... some other commonly used scenarios This will automatically do some actions with tracks and playlists. Because I think that users usually don't want to operate with particular tracks but they want to do some "scenario". Certainly the possibility to check or uncheck particular tracks will remain. |
|
|
I have created new design for confirmation dialog. As I described above, there should be two dialogs (btw. I use full-screen dialog design pattern): 1. The simplified with scenarios 2. The advanced - where user can select particular tracks, playlists, .. The screenshot shows the 2. type. It is expandable listview that with categories (playlists, music, audiobooks, podcasts, ...) and its items. Each category can be expanded and collapsed. I have created new UI component that is a toggle button with 4 states: a) no action b) delete c) download / update from MMW to MMA d) upload / update from MMA to MMW These states are in cycle and changes on user click. Large screen layouts (tablets) can have three separate buttons so user can select one option directly. All options are not always enabled (as download option in Favourite playlist item). User can select one option for whole category by clicking on this button in category item. All items in this category will change to this option (e.g delete). Items that do not have this option enabled is set as "no action". In the screenshot, I used three types of GUI for items...one should be selected: i) Selection is white (used in Movies item) - selected item is white (upload), other possible option is darker (delete) and disabled option is extra dark (download) ii) Selection is primary color (used in Dance playlist item)- selected item is primary colour (delete), other possible option is white (upload) and disabled option is dark (download) iii) Selection is secondary color (used in Music item) - selected item is secondary color (upload), other possible option is white (delete) and disabled option is dark (download) Btw. I still don't know whether we want use the secondary palette (accent color) in our app. Details here: http://www.google.com/design/spec/style/color.html#color-ui-color-application The layout should also contain button to switch to simplified dialog with scenarios and some (i) button that will show some help to user. I think that all sync possibilities are covered by this design. Upload and update from MMA to MMW are in one state because they cannot occur simultaneously and they have the same meaning for user. Same situation is with download and update from MMW to MMA. One action is not covered: Upload to MMW and delete. I think that this action should not be part of sync. Because it is not sync. After doing this, the state of items is not synced. I also think that it is something that is not expected here by user. It is not common scenario and user always can upload, i.e. do the sync, and delete items after that... Without this scenario, the dialog can be very simple and intuitive. This scenario is also not available over USB sync. |
|
|
So it looks good. The only items I'm unclear on are: a) Will users understand how this relates to the sync config? This is minor, but it might be worthwhile to have the list appear in the same order that it does in the 'Auto-sync server content' config list, and for that list to expand/contract similarly to how this one does. b) Re. the configuration of Top-level items (e.g. Playlists or Music), does it make sense for such items to appear if the items contained within them have different actions based on the sync rules? e.g. If some Music tracks are being deleted, and others are being updated, then: i) placing Music with configurable Delete/Update buttons seems to be asking for either trouble or confusion since the user really probably wants to confirm deletion of a subset of Music tracks and update of another subset of music tracks. ii) given i) are you thinking of showing Music with disabled buttons and pre-expanded up to the level of the child attributes that were selected by the user (with active buttons only appearing on the pre-expanded attribute)? |
|
|
I have added three screenshots to describe how grouping can work. This way user can confirm one Album, Artist, ... by one click. 1. confirmation1.png The view shows tracks, user can click on three dots icon on Music item to show more options 2. confirmation2.png Options is shown as offers to view the Music as Tracks, Albums or Artists. User clicks e.g. on Artists 3. confirmation3.png Music is shown as Artists. User can confirm one artist by one click. |
|
|
Looks good. Can you confirm though: c) Is there a way to easily confirm/reject groups of tracks at once i.e. the MMA 1.2 dialog allows the user to accept/reject all deletions at once rather than by individual items. Is there a way to accomplish this with the new dialog? Note: I assume that the confirmation dialog will have all of the default actions preconfigured so the user just has to click 'confirm' in most cases. The above question is mostly about cases in which the user wants to reject certain an action on many tracks at once. |
|
|
c) yes, each group (Music, Playlists, ...) has the same icons as particular items and user can select the action for whole group at once. The example screenshots shows the situation where deletion is checked for all playlists that need confirmation for deletion - 1 playlist called "Some new playlist" Re.Note : yes, it will remain the same as it is currently in 1.2 |
|
|
b/c) I meant, supposing there were: i) 20 tracks slated for deletion ii) 20 tracks to be downloaded/updated iii) 20 tracks to be uploaded/updated With the current UI, the tracks in _any_one_ of_the_above_sets_ can be selected/deselected as a group without affective the other groups. If I understand correctly, that can no longer be done. i.e. with the new UI I can only set an action for all 60 tracks OR change the settings for tracks individually--there's no way e.g. to just deselect the 20 tracks slated for deletion. Is that correct? e) Just a question: what does 'White' selection mean vs 'Yellow' selection? I saw what you wrote at 0010912:0042153, but I still don't understand e.g. the difference between: i) White Garbage can and Yellow Garbage can ii) White Upload and Yellow Upload |
|
|
The biggest problem of dialog in 1.2.0 is that some track can exist (and it is common) in two tabs without any visible connection. I.e. to switch state of some track, user has to look for the track in different tabs. Now it is not necessary, we can set the state per track, or it can be grouped so we can set the state per Artist/Album too. This is much more user friendly design and I think that it is much more intuitive. Your scenario is not correct and it is not possible: First of all, we do not confirm download of tracks or playlists - I know that it was on some screenshots and it is mentioned in previous note but it was my fault. Please have a look at current screenshot. We confirm only uploading and deletion. Following states are possible for tracks and playlists: a) track was removed from synclist - user can only select whether delete this track - upload icon is grey (inactive), delete icon has two states: delete (yellow), do not delete (white) b) track is new and is not on synclist - user can delete or upload this track - both icons have two states: white (do not delete/upload) or yellow (delete/upload) - when user clicks on e.g. upload when delete is activated - upload is activated and delete deactivated - i.e. the state of track is clear for the user with visible interaction ------------------------------------------ c) PLAYLISTS !! have an extra state when playlist is on synclist and was updated in MMA - user can only select whether upload this playlist - delete icon is grey (inactive), upload icon has two states: upload (yellow), do not upload (white) So I would like to correct your use-case in current implementation: i) 20 tracks were slated for upload ii) 40 tracks were slated for deletion (but it includes 20 tracks for upload) Same amount of tracks will be selected/deselected in both implementations. So the possibilities are not shrinked at all. It is only improved. re. e) I tried to describe the difference in text above... but I think that there might be some visual improvement for both icons. There are following states for both icons: - state is not possible - currently it is displayed grey and disabled, we can make the icon invisible - state is possible, not activated - currently it is displayed white, we can display it as grey - state is possible and activated - currently it is displayed yellow, we can display it as white I have attached a screenshot Confirmation4 that displayes exactly the same state as Confirmation1 - but with these icon color changes... Btw. I still think that there should be some simplified confirmation dialog view too, as described in 0010912:0040581 : 1) I want exactly what is on server - this will download everything from server and delete everything else on MMA 2) I want preserve all tracks and playlists - this will upload from MMA to MMW and syncs 3) ... some other commonly used scenarios Both views can work paralelly and selecting one of these scenario in simplified view will autoselect the checkboxes accordingly in detailed view. |
|
|
Re. my question about b/c), in a case of i) 200 tracks slated for deletion ii) 200 tracks to be uploaded/updated I understand that the new UI gives greater flexibility, but i just want to make sure that I understand. If the user: 1 Clicks Music [Garbage can]--> all tracks slated for deletion are deselected. 2 Click Music [Garbage can] --> all tracks slated for both Upload and Deletion are selected for Deletion i.e. once the user overrides the initial confirmation settings (thereby obfuscating the distinction between which tracks are slated for deletion vs slated for upload), the only way to revert them is by pressing 'Cancel' and then re-initiating the sync operation. Correct? Re. e) icon states (in a/b/c): My confusion re. yellow and white states for 'Delete' stems from the fact that I normally expect: 'White checkbox': active but deselected 'White checkbox-checked': active and selected 'Grey checkbox': disabled/can't be checked So if users see a white filled in Garbage can, it intuitively means that it's slated for deletion (or in the best case scenario, users wouldn't intuitively know the difference between White and Yellow garbage cans). The alternative approach that you proposed would solve this (but on the downside it doesn't distinguish between 'state not ever possible' and 'state is possible though currently disabled'), OR it could also make for sense for the states to be: Absent: state not ever possible Grey outline: state is possible but currently disabled White outline: state is possible, but not active/selected Filled (white): state is possible and active/selected - How does hierarchy work? e.g. in confirmation3.png, the Playlists garbage can is selected (orange), but the Dance playlist isn't selected Orange. Shouldn't the child be selected if the parent is (or conversely, shouldn't the parent be delected if the user overrides it by de-selecting one of the children)? |
|
|
Yes, you are correct. But it works exactly the same way in current implementation too. Delete tab contains both tracks for upload and deletion. Btw. "cancel" button is not the only option - the simplified dialog scenario (as described above) can do it too. Outline icons are not used in material design. Primary (orange) colour or secondary (not set for our theme yet) is used for activated/checked icons. It is the same approach as for repeat and shuffle controls. We should really choose the UI from confirmation1.png ... It uses commonly used design so I don't think that users will be confused. (More info here: https://material.io/guidelines/components/buttons.html#buttons-toggle-buttons) There are not 4 states, only 3 states as I described above. I think that the hierarchy is correct. All the playlists that can be deleted are selected so parent is selected too. Dance playlist is on synclist and changed on MMA side and can be only uploaded to MMW. That is why I wanted to hide the icon if the state is not possible. |
|
|
OK, so let's go ahead as you proposed using the icon styles as in confirmation4.png. |
|
|
Fixed in build 2.0.0.1005 |
|
|
Verified 1032 |
