Look and feel Re: Kick starting the Web App UX debate

This is a big topic. I think we can break it down, but I'll start with the  
grab bag.

On Sat, 04 May 2013 19:01:39 +0200, Jo Rabin <jo@linguafranca.org> wrote:
> 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 :

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

I am ignoring most of the "behaviour" stuff (things that I don't think  
would qualify as "View" in a Model-View-Controller perspective on the  
universe), but fullscreen is about look and feel, that happens to have  
behaviour implications.

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

I think this is important. Some developers strive to make their  
applications feel the same across multiple platforms. Others strive to  
make their application feel native to each platform it is running on.  
Operating systems are generally owned by someone with a marketing  
department and a design group, who provide a "default" look and feel. The  
Web is exceptional, and I hope it stays that way. People obviously copy  
what they think is good, so there is a lot of convergence, but it is also  
easy to diverge.

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

Yes. It seems pretty clear that people will continue to want to adapt  
their look and feel to different "paradigms" (I love that word). So one of  
the things the Web needs to maintain is the ability to "skin" things, or  
give them different themes. At the same time, the CSS UI module (currently  
ignored and rotting as far as I know) or something like it would probably  
be helpful for this.

>>>        4. Web apps need to exist outside of the browser user
>>>        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.",

I assume so.

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

There are implementations that explore this in various ways - the  
different "full screens" over the years, Opera Widgets, Chrome and  
FirefoxOS "apps", the way people have done this in areas like TV and  
digital signage based on Web technology, and so on.

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

Yes, I think it would be very useful. And while we're there, to look from  
the other end. Web Apps only work to the extent that "browsers" provide a  
platform, and browsers have a pretty broad set of needs to meet, so they  
are likely to make judgement calls on conflicting requirements, consigning  
one or more development paradigms (yay, again ;) ) to the scrapheap of "if  
only browsers would help me instead of the other guy…"

In my arbitrary division of themes, the part that has most impact on  
presentation is security. Browsers make efforts to protect against  
phishing and the like that most app platforms simply don't make, instead  
relying (often with a great deal of optimism and hope) on the user knowing  
what they have installed. For this reason, they impose restrictions that  
would probably make other platforms more secure too, but those platforms  
sometimes choose to trade user security for convenience.

There's more of this stuff in behaviour, but I'll try to split that into a  
different subthread.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Saturday, 4 May 2013 19:53:15 UTC