ubuntu-phone team mailing list archive

[Martin Albisetti <argentina@xxxxxxxxx>]

After seeing the conversation play out, I agree that the developer is the
right person to decide how their app should be perceived, whether a scope
or an app. I can make that change in the store without requiring any client
changes.

Supporting an app showing up as both an app and a scope at the same time is
more invasive and not easily backwards compatible. If the former feels like
enough to everyone, I'll add that to our list, give control to the
developer on how to present the package type.
On Mar 16, 2015 7:22 PM, "Mitchell Reese" <dev@xxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Rodney, I disagree with your points about user experience. One of the
> BEST points about Ubuntu Touch for me is the sheer ease of switching
> between apps - a simple swipe and I've gone from app to scope, and back
> again. It's like having multiple screens on the desktop - one of the main
> reasons I switched to Linux, and revolutionary for my workflow at the time.
>
> With such a brilliant UI, it means that switching between two apps (or app
> and scope) becomes a joy to use. This means the OMG Ubuntu scope becomes
> the main point of navigation, with the webapp the content holder. If I was
> just concerned with users being irritated between switching apps, I
> wouldn't consider this, and would leave the navigation bar in the app.
> Compared to anything else on the market, this is a much cleaner, simpler,
> more user friendly UI.
>
> As a developer, the alternative is not bundling an app and scope together,
> and simply referencing each in the store - not as optimal by any means.
>
> I think devs should at the least be able to choose of what they create is
> viewed as an app or a scope.
>
> Mitchell
>
> On Tuesday, 17 March 2015 8:00:34 AM AEDT, Rodney Dawes wrote:
>
>> 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.
>>
>>
>>
> --
> Sent using Dekko from my Ubuntu device
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>