ubuntu-phone team mailing list archive

[Thomas Strehl <thomas.strehl@xxxxxxxxxxxxx>]

Hi,

On Thu, May 28, 2015 at 12:25 PM, Mitchell Reese <dev@xxxxxxxxxxxxxxxxxxxxx>
wrote:

> Firstly, thanks to all the devs working on the scopes - they've come a
> long way and are getting really usable. Secondly, the search and display of
> local scopes on a device needs work.
>
> Currently I can swipe up from my phone to view all my scopes. The
> favourites have their own area, and the rest of the scopes have theirs. So
> far so good.
>
> The issue comes with having lots of scopes installed - at the moment in my
> favourites I have 15 scopes - all of which get used to varying degrees.
> Aside from those, I have 42 other scopes installed. Searching through these
> to find something NOT in my favourites is tedious.
>

Is this a regular use case for you to frequently use unfavorited scopes?


>
> There is nothing to differentiate between scope aggregators (parent
> scopes) and scope sources (child scopes). This leads to a cluttered view,
> with no information as to how I can find scopes that use other scopes. I.e:
> with the default BQ images, there is the Today scope, with the calls,
> messages, etc., all of which have their own scopes. At the moment there's
> nothing to inform a user that the Calls and Messages scopes get used by the
> Today scope, etc. This also happens with the Food Aggregator Scope, default
> News Aggregator Scope, etc.
>
>
That's by design. On a certain level we don't differentiate between
aggregators and what you call child scopes - for the scopes machinery it's
all just scopes. This also means there is no two level hierarchy, but
aggregator scopes can also aggregate other aggregators and so forth. Only
the aggregator knows (or have a rough idea when using scope
tagging/keyword) which scopes it queries, but the "child scope" usually do
not know and shouldn't know who aggregates them. This keeps everything
highly flexible and would allow us to eventually also enable consumers to
define their own aggregators which would be quite powerful. With that, any
scope may or may not be aggregated by any other scope, so a Call or
Messages scope cannot know their aggregators up front.



> I know this area is under heavy development, and I look forward to seeing
> the next iteration of work. I think a better workflow would be to have 3
> seperate areas, with different size icons to differentiate them - i.e., the
> Favourites (up the top, or on a separate page), the Aggregator Scopes
> (Large icons in the middle), and the Child/information Scopes (smaller
> icons at the bottom).
>
>
That might be one option, another one would be to categorize scopes by
contextual areas, e.g. by reusing scope keywords like "news", "music" etc.



Thomas