ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Mon, 2015-03-16 at 10:11 -0300, Alejandro J. Cura wrote:
> On Sat, Mar 14, 2015 at 11:54 PM, Rodney Dawes
> <rodney.dawes@xxxxxxxxxxxxx> wrote:
> > On Fri, 2015-03-13 at 11:01 -0300, Alejandro J. Cura wrote:
> >> I agree with this point: when a click package has both a scope and an
> >> app, either the scope should take precedence or the devel should be
> >> able to choose how it's displayed in the store results (as an app or
> >> as a scope).
> >
> > It should display as both an app and a scope. The way it is now is due
> > to a limitation in the way packages with more than one app are handled.
> > Even if your package has multiple apps (which is possible), only the
> > first will appear in the store, and we only really handle a single app
> > in the package reasonably well in general. This needs some thought in
> > terms of implementation details, but I don't think it needs a bug with a
> > lot of discussion.
> 
> I've seen this first with the "Untappd scope", so: No, it should not
> be shown automatically as both an app and a scope in the store. As
> pointed in this thread, developers consider the main focus of their
> package to be either an app or a scope.

But users may not consider that to be the main focus. If as a user, I do
not want to use scopes, and am looking for apps, I shouldn't have the
app hidden from me, because I'm choosing to only view the apps in the
store. The store interface isn't about what developers want, it's about
what users want.

> My proposal is to find some simple way to give the developer of a
> package some control over this option: whether to show the package in
> question in the store as a scope or as an app.

The developer has control over this already. If they don't want their
package to  be viewed in the app results, then don't include an app.
Likewise, if we were to implement store functionality within
online-accounts to allow users to easily find additional accounts
providers (and thus the apps/scopes that provide them), we should show
anything that provides an account plug-in there, and not only things
which the developer thinks the primary interface to using, is the
account provider. Those packages should also appear under the apps or
scopes results as appropriate as well.

> For example, we could add a new optional field to the click manifest
> that points at the main click hook (eg: "main-hook: untappd"), and
> with a seemingly small change in the client and the server we could
> provide devels with control over this.
> This is the kind of small fix I think we should be discussing in a bug.

I think we should support a package which has both an app or a scope (or
multiples thereof), as both an app and a scope, and searching for any of
the contents in either apps or scopes will provide that package in the
results. Anything else is not robust, seeks to fix specific corner cases
rather than providing for user needs, and makes for more complex code to
deal with specific cases.

> > It's also possible for a package to only provide an online accounts
> > provider as well. But those will not show up in the store scope at all,
> > and there will be no way to get a preview to uninstall it. This is a
> > general problem beyond just scopes and apps, which affects any general
> > content provided in a package. We're going to need to fix the store to
> > be able to deal with all of these situations.
> 
> At this point the store has zero support to show clicks with only
> online accounts in them, or with any content other than scopes and
> apps.

The scope does, yes, but the store server can have packages which
provide neither an app or scope (though we only use it for very special
cases at the moment).

> They should all be caught by the app review tools, and not allowed
> into the store. If not, it's a bug in the review tools.

The click tool should only complain about things that are not valid
click packages. A package which has neither an app nor a scope, is still
a valid click package. The tool only complains about hook types which it
does not know about. Where things that do not provide either an app or a
scope will get blocked is in possible manual review (as account-provider
hooks require manual review currently).

> Any change in other direction needs plenty of design work before we
> tackle it, so I propose the smaller change above to give devels what
> they are currently requesting.

Aside from implementing filters in the dash and click scope on the
client side, I don't think there is any design that needs to happen, to
allow packages which contain both apps and scopes, to be visible in the
store as both an app and a scope. The main thing we'd need to do in the
click scope itself for that, is to avoid duplicates in search results,
when not showing the surfacing/highlights results.

Attachment: signature.asc
Description: This is a digitally signed message part