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>
> <mailto: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>
> <mailto: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>
> <https://launchpad.net/%7Eubuntu-phone>
> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
<mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
> <mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx
<mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>>
> Unsubscribe : https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
> <https://launchpad.net/%7Eubuntu-phone>
> More help : https://help.launchpad.net/ListHelp
>
--
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
