ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #15311
Re: Future of Scopes
On 08/31/2015 12:24 PM, Alejandro J. Cura wrote:
> On Mon, Aug 31, 2015 at 12:09 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
...
>> The one thing I'd like to see is better use of caching. For example, I think the
>> Today aggregator scope is great but it sometimes goes blank to refresh
>> everything and then the aggregated scopes' content trickles in one at a time,
>> which can be jarring to the user. I think it would be better to show the
>> previously displayed content with a very small and tasteful indication that each
>> aggregated scope in the process of reloading and when the updated content is
>> available for the aggregated scope, reload it in place. I imagine this is
>> probably also useful for leaf scopes-- show the last content and then replace
>> the bits that are updated.
>>
>> (I've been wanting to bring this up for a little while but wasn't sure if this
>> was a bug, intended behavior, on a todo, an implementation limitation, etc. I
>> figured I'd glom onto a thread that said 'Future of Scopes' for this :)
>
> Replacing only the content that has changed in a scope is a feature
> we'd like to see, but one that's tricky to get right.
> Items disappearing or moving when the user is trying to tap them is
> the most serious issue, but there are some others pointed out in the
> comments to this bug:
> https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1238979
>
> The major issue is matching the scopes data model (a set of categories
> with results) to what the QML model in the dash expects (additions and
> deletions of items).
> We are working on that, and our current plan is to add new items at
> the end of the model and wait until all results have arrived to delete
> the items that are no longer present.
> Still it's not without flaws, because finding a reliable way to
> uniquely identify existing results is something that we'll need to add
> to every existing scope.
>
In the case of an aggregating scope, I would think this might be as simple as:
Aggregator scope at first view
[\] foo scope
[|] bar scope
[/] baz scope
Aggregator scope when bar updated
[-] foo scope
bar scope
[|] baz scope
Aggregator scope when foo and baz updated later
foo scope
bar scope
baz scope
I'm not sure if what you described is like that ^, but the idea is that the
aggregator seems to know the order it wants to put things, and it knows what is
up to date and out of date. Keep the order and replace out of date with up to
date in place when ready.
--
Jamie Strandboge http://www.ubuntu.com/
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References