ubuntu-phone team mailing list archive

[nick luigi eusebio <kugi_igi@xxxxxxxxx>]

I think best thing to do is to integrate a Readability-like functionality into the scopes so that you won't have to open articles/blogs into separate webapps.Maybe same is applicable for other types of contents.
      From: Mitchell Reese <dev@xxxxxxxxxxxxxxxxxxxxx>
 To: Ubuntu Touch <ubuntu-phone@xxxxxxxxxxxxxxxxxxx> 
 Sent: Tuesday, March 17, 2015 9:57 AM
 Subject: Re: [Ubuntu-phone] Scopes default store behaviour
   
That's a great outcome! How long until this goes into play? Better get 
cracking on some more scopes...

M

On 17/03/15 09:31, Martin Albisetti wrote:
>
> 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 
> <mailto: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
>            <mailto: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
>    <https://launchpad.net/%7Eubuntu-phone>
>    Post to    : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>    <mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
>    Unsubscribe : https://launchpad.net/~ubuntu-phone
>    <https://launchpad.net/%7Eubuntu-phone>
>    More help  : https://help.launchpad.net/ListHelp
>


-- 
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