Re: Kick starting the Web App UX debate

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"

>         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

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

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.

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

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

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

Thanks for getting us started on this!

Dom

Received on Friday, 3 May 2013 13:15:35 UTC