Re: What is an app Re: Kick starting the Web App UX debate

Wow, very well argued, thank you very much for that!

I wonder if there is a continuum here, where on one end we have the classic
"web as document" flowed text which has all of the user-as-reader
attributes you discussed.  On the other end is Angry Birds with all
benefits as well as the downsides you discussed.

I will argue something that might appear a bit cavalier but one of the
reasons that apps are eating the web's lunch right now is the control and
flexibility they have. Native apps are a lot like Spiderman, "With great
power comes great responsibility."  I don't want to look like I'm against
your point, I'm just saying that we need a more subtle way of discussing
this. I frankly don't see any practical way where you can have two authors
(web designer and reader) each have control over a complex layout.
SOMETHING has to give. Of course, you *can* have this two author model for
flowed text, the web has proven that.

I guess I'm willing to kill a sacred cow and say that this author/reader
dual control of display really only goes so far, and is frankly, impossible
to pull off for complex layouts. Are we willing to let some of that go?

Excellent discussion, thank you,

Scott


On Mon, May 6, 2013 at 6:05 PM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Mon, 06 May 2013 23:16:42 +0200, Scott Jenson <scott@jenson.org> wrote:
>
>  On Sat, May 4, 2013 at 12:52 PM, Charles McCathie Nevile <
>> chaals@yandex-team.ru> wrote:
>>
>>  +1 ; I think at our level what matters is:
>>>
>>>> * how the content/service provider wants her Web-based experience to be
>>>>> perceived like
>>>>>
>>>>>  I think the issue is more complex. One of the traditional strengths
>>> of the Web is that the user gets a say. Authors tend not to like that, so
>>> the successful way to make it work tends to allow the author a lot of
>>> control over the default presentation, in ways that still let the user
>>> adapt it easily to their particular situation if necessary.
>>>
>>
>> I'd like to understand this more. Other than resizing a browser window
>> and zooming the text what *else* do users do?
>>
>
> Well, zooming the entire content. Normal browser tools work up to
> somewhere between 200% and 1000%, beyond that people use specialised tools
> up to about 2 characters / screen.
>
> Using a screenreader to provide voice feedback, instead fo looking at the
> content at all. This isn't such a big deal for the way things look IFF the
> developer has built stuff with common controls, but messing with
> "behaviour" - the email I didn't write yet - plays merry hell with all this.
>
> Changing the colour scheme to high or very high contrast. (Microsoft has
> put this into CSS - presumably because it is a pain point with real
> customers. If I were speculating I would guess the major real customers are
> banks, educational institutions and the US government, but that's just wild
> guesswork).
>
> About 10% of the "western" male population is colour-blind (the rate is
> much lower in other segments of the world population). While good authoring
> should handle this anyway, it is often the case that graphic designers
> don't. (There are some exceptions, and world-famous designers in the Web
> world whoare themselves colour-blind). High-contrast mode is a sub-optimal
> solution in many cases, but where it is an improvement on "the default
> presentation" people will of course use it anyway.
>
> Not using a mouse, or using an IME to generate characters considered
> "normal" (e.g. typing numbers on a standard french keyboard requires using
> the shift key). Again, this is more in "behaviour", but where the design of
> an app relies on people e.g. hovering something ("If doors were made by web
> developers, you wouldn't see the handle until you were reaching for it") it
> causes problems.
>
> Using captioning, subtitling, etc, for multimedia content.
>
>
>  I'll also go back to my previous email and call the distinction between
>> a web document and 'something-higher-level-that'**s-not-a-doc'. If you're
>> viewing a full screen canvas animation, what can the user do to
>> 'adapt it'?
>>
>
> In the general case not a lot. This is a serious problem for real users,
> and for real content producers who have to serve those users - governments,
> banks, schools, the sort of behemoths who, we complain, don't move with the
> times. Sometimes because the new technology doesn't *actually* do what they
> need, among other reasons.
>
>
>  My claim is that that vast majority of 'adaption' that we see on the web
>> is applied to flowed text. I agree with this and agree this is an awesome
>> part of the web.
>>
>
> Sure. In part because CSS has been extremely successful in making it
> relatively easy for developers to get their preferred layout unless the
> user insists on changing something, while allowing users the flexibility
> they might need.
>
>
>  However, what does it mean to carry this ability into non-documents?
>>
>
> Well, that depends on the user and their needs. Things like ensuring that
> a user can effectively interact with an app.
>
> In principle SVG allows the same adaptability via CSS that is available
> with flowed text, but for a far richer set of graphical representations.
> This is generally possible in real implementations. But in practice, there
> has been relatively little work on making graphic representations adapt
> well.
>
> Despite having woefully less capable technology to work with, the
> Television industry is generally well ahead of the Web in practical
> experience here. TV in a normal US bar is pretty awful, but it generally
> has captions being displayed. Japanese television manages more powerful
> adaptations - high audio contrast, and in extreme cases messing with the
> timing to allow adapted presentation of content.
>
>  My concern is that we are using yesterdays tasks to define tomorrow's
>> features.
>>
>
> Yes, we should be careful about that. But it is also important to remember
> that a lot of yesterday's users are still here today. As I mentioned, for
> some classes of app, ignoring those people is apparently a sign of how cool
> the developers are, but for some classes of app it is simply a dealbreaker
> that means the development is not worth doing.
>
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>       chaals@yandex-team.ru         Find more at http://yandex.com
>