touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #26411
[Bug 1281602] Re: Manage Scopes Feedback
On Tuesday 14 October 2014 10:12:40 James Mulholland wrote:
> 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).
Ok, will talk with Pawel about this.
>
> > 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?
As agreed the unsubscribe feature is not part of OTA-1, so the 'delete a
single item from the list with a swipe' functionality won't be there either,
because that is unsubscribing.
> > 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.
Ok
>
> > 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.
Ok, i'll have them draggable in full for now since we don't have
checboxes.
Cheers,
Albert
>
>
> 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 <
>
> albert.astals@xxxxxxxxxxxxx> 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!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scope-mediascanner
in Ubuntu.
https://bugs.launchpad.net/bugs/1281602
Title:
When searching videoaggregator scope, local videos are shown at the
bottom
Status in Unity Media Scanner Scope:
Fix Released
Status in QML plugin for Scopes:
Fix Released
Status in “unity-scope-mediascanner” package in Ubuntu:
Fix Released
Bug description:
In the new-scopes unity8, searching videos works, but "My Videos" are
shown at the end, when one would generally expect local videos to be
at the top
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unity8 (not installed)
ProcVersionSignature: Ubuntu 3.13.0-8.27-generic 3.13.2
Uname: Linux 3.13.0-8-generic x86_64
ApportVersion: 2.13.2-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Feb 18 09:43:27 2014
InstallationDate: Installed on 2013-07-26 (206 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: unity8
UpgradeStatus: Upgraded to trusty on 2013-11-21 (89 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/unity-scope-mediascanner/+bug/1281602/+subscriptions
References