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
