← Back to team overview

ubuntu-phone team mailing list archive

Re: Scopes default store behaviour

 

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


Follow ups

References