Re: Testability of Animation from interactions Issue 18

On 13/01/2017 02:01, Gregg C Vanderheiden wrote:
> In the Epilepsy FLASH - the size of the flashing object (in visual
> angle) is critical since its size relates to the area of the brain that
> is stimulated —and the larger the visual angle the greater chance it
> will cause a seizure.
> but it is the absolute size of the stimulus and it has nothing to do
> with the size stimulus in relation to the size of the screen.

But as pointed out, the actual size of the stimulus on the user's retina 
can only be calculated correctly if you know the resolution of the 
screen in (CSS) pixels, the actual physical size of the screen, and the 
actual viewing distance. And as the last two can simply not be 
determined programmatically, and since they can and are very variable 
(even just for desktop, where people sit the same distance from screens 
that are actually quite different in physical size - something that gets 
even more complex once you take other devices like mobiles, tablets, 
phablets etc into account), it is not possible (even with a "tool", if 
that tool doesn't actually ask for physical dimensions/distances) to 
make an absolute determination for pass/fail. Any pass/fail is heavily 
reliant on the assumed/fixed value assigned to the physical screen size 
and viewing distance. So for instance, a pass (as determined using a 
"tool" or by manually calculating this) can still be a fail if the user, 
for instance, has a desktop monitor that is larger than the assumed 
average, still runs at the same CSS pixel resolution, while still 
sitting at the same distance...since that would result in the stimulus 
area being larger in real terms.

[...]

>> What if it's a 24 inch screen at same resolution and viewing distance?
>> (not uncommon nowadays for people to have much larger screens, but to
>> still sit at the same desk/distance from the screen)
> There are no 24 inch screens that are 1024 x 768.

As a user, I can set my OS to drive the monitor at whatever resolution I 
want. Don't confuse physical pixels (individual hardware dots) with 
(CSS) pixels of what is displayed on your screen.

> All of the larger screens have higher pixel density — so the material
> would be safer.

They have higher pixel density, but then the OS will use more physical 
pixels to display a single (CSS) pixel. In layman's terms, this is why 
on an iPhone with retina display things aren't half as big as on an old 
non-retina iPhone.

>> It would result in a rectangle that has the same pixel dimensions, but
>> actually in physical terms it's rendered larger, so occupies a larger
>> field area in the user's absolute field of view.
>>
> If you look at that same page on one of those screens you will find that
> the content is smaller

No you won't. If the OS is still driving that physically larger display 
at 1024x768, it will be larger.

>> So there is already variability here in real terms, and it's the same
>> sort of variability that we're discussing here, no?
>
> Variability - yes.    But not less safe.

See above.

>>
>>> the only thing not covered is if a person uses a magnifier on the
>>> flashing element.    But that will fail no matter what you do and the
>>> author can’t predict or address that anyway.
>>
>> The author also can't predict the actual physical size of the screen,
>> nor the actual viewer's distance.
>
> Correct
>
>> So there are assumptions being made (about the "standard screen size
>> and viewing distance"), and with those fixed, the only other remaining
>> variable is screen resolution (in the example in the spec, 1024x768).
>
> Close
>
>> So, boiling this down, it seems reasonable to say that really the
>> highly obscure definition of ".006 steradians within any 10 degree
>> visual field on the screen (25% of any 10 degree visual field on the
>> screen)”
>
> that is the rule and it is not obscure in any sense of the word.  It is
> very specific.   It may be technical but not obscure.   And the notes
> make it concrete and easy to understand in people’s minds

I think we'll have to disagree on this. Find me a random sample of web 
developers in the wild who would even begin to understand this measure, 
compared to saying "1/3 of the width by 1/3 of the height of the 
viewport/screen"

>> essentially comes down to (since 2 variables have been assumed as
>> ideal/fixed) "1/3 of the width by 1/3 of the height of the
>> viewport/screen". Or am I missing something?
>
> This is confusing.    It is 1/3 of 1/3 of one particular size screen and
> resolution combination.    It is not 1/3 by 1/3 of anything else.
> So I’m not sure what you are getting at.   Can you help me?

What I'm getting at is: since even the "tool" calculations make 
assumptions and essentially use constants for physical size of the 
screen and viewer distance to make their pass/fail determination (since 
the tool doesn't, from what you're saying, ask for these parameters), 
and since the only remaining variables that the tool can then work with 
is essentially a) the size of the area that's flashing and b) the 
overall size of the screen, why not simply define the measurement as a 
simple ratio of "if the flashing area is larger than 1/3 of the width by 
1/3 of the height of the viewport/screen, it's a fail". This has the 
same uncertainty in terms of calculation that the current 
"steraradians..." measurement has, but is immediately more 
understandable. And this is also resolution-independent, as it's a 
percentage/ratio.

>
>>
>>>> Does the tool require you to enter the variables like physical
>>>> screen size, viewing distance, etc? Or does it simply base its
>>>> calculation on the screen/window size? If the latter, then it's
>>>> doing nothing different from what I'm proposing, i.e. anchoring any
>>>> measurement on viewport/screen size and writing out clearly what
>>>> that ratio is.’
>>>
>>> No,  If you read the whole email I think you will see that this is
>>> covered.
>>
>> As above, the tool in that case assumes ideal/fixed conditions of
>> physical screen size and viewing distance, I take it?
>
> No.  Assumes that pixel density or a smaller pixel density.
>
>> So in essence simply calculates the ratio of the flashing area in
>> relation to the whole screen size?
>
> no - not true at all.    it is based on the visual angle.

So somewhere along the line this tool needs to be anchored on an 
assumption (since different displays, even of same physical size and at 
same viewing distance, can actually run at different resolutions). Is is 
basing its calculations on the reference pixel definition in CSS, 
perhaps? https://www.w3.org/TR/css3-values/#absolute-lengths

[...]

>> I have read it more carefully, but have come to the same effective
>> conclusion...since physical screen size and viewer distance are
>> assumed to be “ideal”
> no not ‘ideal’.    that is just one data point.    Actually anything
> with higher pixel density is more ideal (safer)

Again, there's a difference between pixel density in terms of hardware 
pixels of a display, and what (CSS) pixels are actually displayed.

>> (along the same effective ratio as having a 15-17 inch screen at 22-26
>> inches distance), it stands to reason that the ratio IS only
>> calculated based on the area of what's flashing versus the overall
>> screen area, no?
>
> No.   it is based only on the size of the area that is flashing.   Size
> of the overall screen has no effect at all.

But as you can't determine the actual size in real terms, because it 
depends on the physical screen size, the viewer distance, the resolution 
of the screen, something in that calculation must be anchored.

[...]

>> If I hold my mobile phone at 3-4 inches from my eyes (which for
>> certain activities, like watching a movie, I just might), it occupies
>> roughly the same area of my field of view as my 24" monitor on my desk
>> at the average viewing distance...so I would not say that's always a
>> safe bet.
>
> Yes you are correct - it would.  But it has many more pixels than the
> 1024/768 screen at 15 inches does.   so the pixels definition and the
> angle definition would both yield a save view for you.
>   Do the calculations and you will see what I mean. .

And once again, don't confuse physical pixels with logical/CSS pixels. 
My phone may be high resolution, but it's displaying standard web 
content at 320 pixels x 800ish pixels.

[...]

>> Both animation and photosensitive epilepsy are concerned with how much
>> of the field of view the animation/flashing are taking up. So if, as
>> discussed above, even for flash/red flash the measurement effectively
>> boils down to a relationship of what's flashing in relation to the
>> overall size of the screen
>
> You keep saying that it is the flashing area in relation to overall
> screen size.  But no where did I say that — and it is absolutely not true.

I'm pointing out that because all other variables are 
unknown/unknowable, they are being assumed/fixed, and that's why these 
are the only remaining variables that are and can be used for the 
calculation. YOU aren't saying that.

[...]

> Now that we are back to animation — I don’t think the size of the
> animation has much to do with anything.

The proposed SC talks about "1/3 of the webpage view", so I thought it 
*was* relevant (before we took a detour into steraradians which led us 
down the conversation here). Surely a tiny animation that, in the 
extreme, only occupies one CSS pixel on the screen is less problematic 
than something that animates more than 1/3 of the visible 
viewport/screen, no?

> See the note at the top of the page.

Which page, which note?

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 13 January 2017 02:49:13 UTC