Hi Albert
> 1a. 'Apps' should be reposition-able and unfavorite-able when in edit mode > > (as with other scopes). > The "Dash & Feeds - RTM Usability Fix" document says "The Apps feed cannot > be > deleted/unsubscribed or moved from its position at the top of the list." > I hope this is correct since both Pawel and me had to do extra code to make > that happen. Apologies for this oversight due to some miscommunication. It became apparent at the end of last week that the way we had planned for this to work needed to change; given the plans for both default scopes (which now include a dashboard scope, a nearby scope, etc) as well as the latest plans for how the ubuntu button on the launcher would function. I'm sorry for any effort you expended before it became clear that this needed to change from what was described in the design doc (which I will update at the first opportunity). > 1b. The 'home key' in the launcher should move the user to the first > > position in the dash (not to the 'Apps' scope specifically) > > > > 2. When in edit mode, check-boxes for multi-select and, select-all icon > and > > trash-icon for multi-delete should be present. > As far as i understand the checkboxes and the select-all are there useful > for > the "unsubscribe" feature and that has not been agreed of being part of > OTA 1, > so there's no use at all for the checkboxes and that's why they are not > there. The only use for those checkboxes currently is for deleting (unsubscribing) multiple scopes. There may be further uses for them at a later date (e.g. if we add the ability for the user to generate their own aggregator scopes at a later date), but for now will we at least have the 'delete a single item from the list with a swipe' functionality? > 6.The way items appear semi-transparent when being dragged could pose > > problems with legibility, this is further complicated by the item being > > dragged appearing as a 'copy' of an item still in the list (although I > like > > the way the list resorts to accommodate the newly dragged item) > > > > The only other example we currently have for drag and drop in the U.I > > should probably be our guide here - Repositioning app icons in the > launcher: > > > > 'Manage' scopes (currently): > > - Semi-transparent copy of item being long pressed/dragged is created, > > floats before the list and attaches to users finger. > > - Line is used to preview new position for dragged item. > > > > Launcher: > > - App icon is removed from the list and attaches to users finger. > > - Remaining App icons 'fall' to fill gap left by dragged item > > - Line is used to preview new position for dragged item. > > - Other App icons are nudged slightly as the user drags the item up and > > down item prior to releasing - (which icon is nudged and the direction it > > nudges in are determined by the current position of the preview line and > > the direction of the user drag. > > > > I hope that's clear? Difficult to describe in bullet points, so I'd > > recommend taking a look at the launcher and playing with it's drag and > drop > > functionality. > So do you want me to copy what the Launcher does? > Because the launcher does allow horizontal movement and you said you don't > want horizontal movement. Can you clarify it? We want to be as close top the launchers behaviour as is reasonable (so that, even if the users interactions aren't identical, they are close as we can reasonably make them). One of the distinctions would be the lack of horizontal movement with list manipulation - horizontal movement is helpful when moving small icons within the narrow launcher, bur not as useful for full-screen width lists. > 3. When in edit mode the user shouldn't need to long press an item to > begin > > dragging items - tapping and dragging (on the 'grip') should begin the > drag > > and drop. > Another question about this, the tap+drag should be reduced to the grip > area > or be available on the whole item like now? This only really becomes a problem if we have checkboxes (as that part of the list item would need to be 'tappable' rather than 'grippable'). In the current version having the entire list item be draggable when in the edit-mode is not harmful. Thanks again Albert and Pawel for all your hard work on this James On Fri, Oct 10, 2014 at 4:58 PM, Albert Astals Cid < [email protected]> wrote: > On Friday 10 October 2014 16:10:22 James Mulholland wrote: > > Thanks for this, looks great so far! > > > > Some initial feedback (some of which I am sure you are already aware of): > > > > 1a. 'Apps' should be reposition-able and unfavorite-able when in edit > mode > > (as with other scopes). > > The "Dash & Feeds - RTM Usability Fix" document says "The Apps feed cannot > be > deleted/unsubscribed or moved from its position at the top of the list." > > I hope this is correct since both Pawel and me had to do extra code to make > that happen. > > > 1b. The 'home key' in the launcher should move the user to the first > > position in the dash (not to the 'Apps' scope specifically) > > > > 2. When in edit mode, check-boxes for multi-select and, select-all icon > and > > trash-icon for multi-delete should be present. > > As far as i understand the checkboxes and the select-all are there useful > for > the "unsubscribe" feature and that has not been agreed of being part of > OTA 1, > so there's no use at all for the checkboxes and that's why they are not > there. > > > 3. When in edit mode the user shouldn't need to long press an item to > begin > > dragging items - tapping and dragging (on the 'grip') should begin the > drag > > and drop. > > Ok > > > 4. When dragging/repositioning items in the list, horizontal movement > > should be disabled (i.e. the user can only drag up/down along the > vertical > > axis. > > Ok > > > 5. Our placeholder 'drag handle' assets should probably be looked at by > > visual design (although the grip made of 9 small squares is OK as a > > placeholder for now). > > I'll use whatever you guys give me :) > > > 6.The way items appear semi-transparent when being dragged could pose > > problems with legibility, this is further complicated by the item being > > dragged appearing as a 'copy' of an item still in the list (although I > like > > the way the list resorts to accommodate the newly dragged item) > > > > The only other example we currently have for drag and drop in the U.I > > should probably be our guide here - Repositioning app icons in the > launcher: > > > > 'Manage' scopes (currently): > > - Semi-transparent copy of item being long pressed/dragged is created, > > floats before the list and attaches to users finger. > > - Line is used to preview new position for dragged item. > > > > Launcher: > > - App icon is removed from the list and attaches to users finger. > > - Remaining App icons 'fall' to fill gap left by dragged item > > - Line is used to preview new position for dragged item. > > - Other App icons are nudged slightly as the user drags the item up and > > down item prior to releasing - (which icon is nudged and the direction it > > nudges in are determined by the current position of the preview line and > > the direction of the user drag. > > > > I hope that's clear? Difficult to describe in bullet points, so I'd > > recommend taking a look at the launcher and playing with it's drag and > drop > > functionality. > > So do you want me to copy what the Launcher does? > > Because the launcher does allow horizontal movement and you said you don't > want horizontal movement. Can you clarify it? > > Cheers, > Albert > > > > > Very encouraging early build though, thanks again! > > -- Best Regards James Mulholland -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1281602 Title: When searching videoaggregator scope, local videos are shown at the bottom To manage notifications about this bug go to: https://bugs.launchpad.net/unity-scope-mediascanner/+bug/1281602/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
