Re: Kick starting the Web App UX debate

On 3 May 2013, at 14:15, Dominique Hazael-Massieux <dom@w3.org> wrote:

> Le jeudi 02 mai 2013 à 20:26 -0700, Scott Jenson a écrit :
> 
> 
>> I also like short emails. These are *meant* to provoke, but I hope
>> constructively. Which of these are too broad? Which are too narrow?
>> Reply to me directly or to the group as whole, it's up to you. Here
>> you go:
>>        1. Striving for a clear definition of what is a 'web app' is
>>        politically charged and frankly not useful. Just don't go
>>        there...
> 
> +1 ; I think at our level what matters is:
> * how the content/service provider wants her Web-based experience to be
> perceived like
> * the level of integration the user expects from her interactions with
> the "app"

I'm going to disagree on this a) because even if simple questions don't have simple answers they deserve answers of some kind, and b) because exploring the answers tells us something about the subject we clearly don't know, and that we may benefit from knowing.

> 
>>        2. However, it would be useful to approach the problem from
>>        the other end. Articulate a list of 'app-ish' behaviors that
>>        are needed (e.g. Games need to go full screen to create an
>>        immersive effect.) 
> 
> The CoreMob group has put some thoughts on this, which might be useful:
> http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#derived-requirements
> 
> I think the app-ish behaviors that are needed or desired will certainly
> vary a lot from app to app, and possibly from users to users; so to
> approach this effectively, we may need to articulate the behaviors per
> type of applications.
> 
> Based on this list previous discussions on the topic, the following
> behaviors have been mentioned:
> * integration in the list of apps directly available to the user
> * integration in the tasks-switcher
> * full screen experience
> * isolation of data from other apps
> * opening of links to external pages in a separate browser
> * "singleton" enforcement (I can only run one instance of an app)
> * can operate in the background
* cooperation with other "apps", intents and the like

> 
>>        3. Web apps don't have to look exactly like their native
>>        platform cousins. This "I need a back button in the upper
>>        right for iPhone but something else for Android" will lead to
>>        madness. It's ok to not look native. Get over it...
> 
> +1 ; in fact, I think Web apps offer a potential benefit here in that
> they free service providers from UI/UX constraints set by a third party,
> and it let them adopt a given UX framework that can be shared across
> devices.

+1 from me on this too. I find it maddening that Skpye, Spotify and Twitter - to name a couple of apps I use frequently on a cross platform basis - all have confusingly different UX and features exposed. Or maybe they don't have different features, I just can't find them. However, by contrast, when it comes to local operations I can see benefits in applications sharing native look and feel. Think this is justified in that in the first case you're interacting with a service which is the "same" service irrespective of how you access it, in the other case you're interacting with the device, irrespective of the service that invoked the interaction.
  
> That said, I think the question of how easily the Web should let service
> providers adopt the underlying platform UI components is also worth
> exploring.

I guess I just agreed with that.

> 
>>        4. Web apps need to exist outside of the browser user
>>        experience (e.g. running an app from an NFC launch event) This
>>        does not mean that the app exists outside the browser, just
>>        outside the experience (i.e. you can loose the URL bar). This,
>>        in effect, turns the browser into an underlying technology
>>        that can offer web technologies that don't feel at all like
>>        web pages.
> 
> You say "i.e. you can loose the URL bar"; I wonder if you meant "e.g.",
> in other words whether you're thinking of a mode in which all/most of
> the chrome and other browser UI features are removed, or thinking
> specifically of removing the URL bar.
> 
> I certainly can imagine the appeal of the former; I don't have a model
> of what this would mean for the said app with regard to e.g. other
> browsers tabs. That sounds worth digging further into.

I wonder it might help not to consider the browser as the unitary apotheosis of Webiness, but rather as something that 
a) uses underlying Web transport mechanisms (like many native apps), 
b) uses Web rendering mechanisms (like some other native apps) 
c) provides for reuse of a rendering surface either 
	i) under the control of its current content (or app) which can pass control to another app (by allowing for dereferencing of a URI)
	ii) or outside  the control of of that content (by use of bookmarks, back buttons, context menu, typing a url in the chrome, whatever)
d) provides various kinds of management, coordination and organisational features (discovery, installation and launching) 

> 
>>        5. Just as "<!DOCTYPE html>" declares the page as HTML5, so do
>>        we need a similar mechanism to declare to the browser that 1
>>        (or more) of these web app behaviors are in force.
> 
> I think that's at least one of the ideas behind the app manifest; in any
> case, a likely important consideration for the declaration mechanism
> would be how much control the user gets on accepting or refusing these
> special behaviors (in particular with potential concerns with security
> and privacy).

sarcastic remark on this below :-)

> 
>>        6. There needs to be a mechanism to turn off browser UX
>>        intrusions such as Android Chrome's edge dragging to next tab,
>>        and 'zoom in on ambiguous link tap' 
> 
> It would probably be useful to list the browser behaviors that are known
> to potentially intrude in the underlying Web app UX, and then analyse
> the implications of turning them off.

So take away c) ii) and d) in the above list, you can't do anything or go anywhere the current page doesn't want you to go. That means that you can't re-use the display surface for an unrelated app. It raises the question of how its
a) discovered
b) installed
c) launched

Once launched it's going to find itself inhibited because of a perception that it's like a hitch-hiker you picked up in the night, rather than someone you made ride-share arrangements with. So it's not going to be granted the same degree of permissions, purely on the basis that it's Web technology and anything that is made of Web technology has the same dubious properties.

Jo

Received on Saturday, 4 May 2013 17:02:07 UTC