ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Mon, 2015-03-16 at 16:11 -0400, Robert Schroll wrote:
> On Mon, Mar 16, 2015 at 9:34 AM, Rodney Dawes 
> <rodney.dawes@xxxxxxxxxxxxx> wrote:
> > 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.
> 
> Response the first:
> 
> We are told, as developers, to "create unique and valuable user 
> experiences" [1].  Part of creating a user experience is to design and 
> guide the user on a particular path through the application.  Perhaps 
> that starts with a scope and flows seamlessly into an app, to display 
> richer results.  Perhaps is starts in an app and flows into a scope to 
> allow querying of remote resources.  Perhaps it does something more 
> complicated.  To do this, developers need to be able to specify the 
> (default) entry point to their application.  Forcing them to accept 
> entry from any point is antithetical to providing a designed experience.

Apps and scopes are independent things. A scope may provide results that
can be opened in an app, but the app is an independent thing. It does
not provide the implementation that runs the scopes, nor the
implementation of the scope itself. In terms of the way the system
works, an app has a .desktop file and will show up in the list of apps.
Nobody is forcing developers to accept entry from any point. There are
specific and well-documented entry points to specific things, however.

> Response the second:
> 
> Why should users need to know about the technological details behind an 
> application?  If a "scopey" application uses a simple QML app to 
> provide a feature not available in the scope, the user doesn't need to 
> know.  Nor should they care if an "appy" application turns operation 
> over to a scope for small feature.  The fact that different processes 
> are responsible for putting pixels on the screen should not stop the 
> user from thinking of the first as a scope and the second as an app.

People don't need to know about the technical details behind an app. An
app is an app. If a person wants to use the app, they should be able to
use the app. Forcing them to go to a scope, search for something, find
that thing in the list of results, then tap on it, to open an app is
antithetical to "creating a unique and valuable user experience."
However, if your app and scope are jumping back and forth between each
other, the person will get frustrated.

As an example: recently, the Coca-Cola Freestyle machines got a firmware
update which changed the UI for the menu system. Previously, to get a
standard flavor (without cherry, lime, etc… mixes) soda out of the
machine, all one had to do was select the brand logo on the main screen,
and then push the button with the cup under the spout. Now, one has to
select a genre, then the soda brand, and then the unflavored soda again,
before being able to fill their cup. It now takes at least 3x as long to
get the same soda, as it did previously.

Forcing a person into that experience is not helpful or valuable to the
user.

> In short, if a developer decides that their app+scope is a scope, we 
> should believe them.  In fact, I would argue that there should be a way 
> for the developer to keep the app icon from showing up in the app grid, 
> so that the only entry point is through the scope.

Don't provide an app then. In many cases, the app is just going to be a
webapp anyway. Forcing a person to go to the scope first, and then to
the app, and back and forth, isn't going to be helpful to the user.

> As a for-instance: My Gmail scope offers a pretty awful reply 
> functionality [2], limited by the capabilities of scopes.  I'm toying 
> around with a little QML app that would allow more full-featured 
> replies.  But I wouldn't want this combined package to be listed as an 
> app, since the QML part is designed only to be entered from the scope.

What you want, isn't an app. It's a trusted prompt session. You want the
UI to pop up on top of the dash, not in a separate app, in the same way
we have the payments UI working for app purchases in the click scope.
There is however, not a general solution for scopes to do this at the
moment.

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