ubuntu-phone team mailing list archive

[Mitchell Reese <dev@xxxxxxxxxxxxxxxxxxxxx>]

H Thomas, thanks for your reply - my responses below:

On 29/05/15 22:49, Thomas Strehl wrote:
> Hi,
>
> On Thu, May 28, 2015 at 12:25 PM, Mitchell Reese 
> <dev@xxxxxxxxxxxxxxxxxxxxx <mailto: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?
Normally I use favorited scopes - the issue is when I'm looking for 
something NOT in my favorites - currently I'm presented with a cluttered 
interface. Grouping them by category might help.
>     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.
That makes sense. I'm not sure then how to provide a better experience - 
right now it feels cluttered and not well presented. I think your idea 
of categories could work, and perhaps aggregators having larger icons 
than the others - or even having a seperate section for aggregators. I 
think this could include all aggregator scopes - even aggregators of 
aggregators, etc.
>     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.
Yep, love this idea. Trying to get a handle on scope keywords myself - 
looking forward to seeing where this is going.

M
> Thomas