← Back to team overview

ubuntu-phone team mailing list archive

Re: Future of Scopes

 

On Mon, Aug 31, 2015 at 12:09 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
> On 08/30/2015 10:01 AM, Michi Henning wrote:
>> Scopes, by design, are information providers, and interaction with them is
>> deliberately kept to a minimum. In return, we get scopes that are stateless,
>> take up minimal resources, don't need access to a display surface, and start up
>> in a fraction of a second.
>>
>> The way to make scopes interactive to bundle them with an app. The scope
>> surfaces content and, when more sophisticated interactions are required, the
>> scope can notify the app, which then takes over for the fancy stuff.
>>
> I've actually found that a well-written and designed scope can be quite useful.
> Those that aren't tend to not surface enough information or feel like little
> more than a google search with 'site:example.com'.
>
> 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.

cheers,
-- 
alecu


Follow ups

References