Re: New possible SC: All functionality available in portrait / landscape, OR not?

> Allow it to look perfect in one orientation, and ensure it's functional
in another....NOW, designing a "Portrait and Landscape Experience" unique
to those layouts, that could be a challenge. But that's not what we're
asking."

I agree we have the right balance now, which is the current wording,
although its still an earthquake.

The response I've been getting to that, is "This is an application for a
major vendor. We simply don't let stuff go out the door that looks and
behaves badly. We want to steer the user to the experience that we crafted
and the experience that is professionally designed, not a one sprint hack"

For this crowd, they are not keen on releasing a product that could be ugly
just by opening the app while the device is sideways in the users hand.
They'd rather lock orientation. No one on that level, in retail, banking
etc... wants their app to look ugly and unprofessional. It makes them look
incompetent and loses customer trust. It's going to take a while for our SC
to ripple through the design world. It's going to increase design costs by
about 20% I'd say to get this right.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>


On Wed, May 1, 2019 at 9:01 AM Chris McMeeking <chris.mcmeeking@deque.com>
wrote:

> Developing mobile apps to render well in multiple configurations is not
> difficult. My response to such teams would be:
>
> "Allow it to look perfect in one orientation, and ensure it's functional
> in another."
>
> Any Native Mobile app that cannot, relatively trivially, be allowed to
> work in both orientations has been programmed lazily. This is a one sprint
> endeavor for any application that I have worked on.
>
> NOW, designing a "Portrait and Landscape Experience" unique to those
> layouts, that could be a challenge. But that's not what we're asking. Teams
> that care about this should have considered Accessibility Earlier in their
> development process.
>
> Every SC has ripple effects when you care about the design implications of
> those effects that can immensely complicate things for those who care about
> those implications. Color Contrast is an excellent example of this. Teams
> that care about this implications should consider Accessibility in earlier
> phases of development. But, unlocking the configuration, attaching a
> ScrollView to your main content, and just letting your view readjust to the
> viewport change is trivial for any non-stupidly programmed application.
>
> Chris
>
> On Wed, May 1, 2019 at 6:30 AM David MacDonald <david100@sympatico.ca>
> wrote:
>
>> I think the language of this SC is intentionally quite narrow. But even
>> with the narrow scope it still causes a lot of trouble.
>> "Content does not restrict its view and operation to a single display
>> orientation, ..."
>>
>> In the understanding we distinguish "operation" from "changes in
>> functionality". We mean "operation" in a very broad sense. So a test for
>> this SC is simply to turn the device and click a few things to make sure
>> operation is not "restricted", rather than make sure all content is
>> functional and working well.
>>
>> I've worked on two popular and top tier mobile apps lately where I came
>> in after the app was built to improve accessibility, and both companies,
>> independently had spent endless hours perfecting every detail of each
>> screen... in portrait mode. In both cases when I said "If we want to follow
>> the guidance of WCAG 2.1 it would be a good idea to unlock the orientation
>> and let it be used in landscape" . Both said "oh my, that is a long term
>> complete redesign consideration, it will cause us to completely rethink our
>> whole UI."
>>
>> Naturally, the next hing to say is "well that would have been a good
>> thing to think about when the cement was wet in the design phase."
>>
>> Perhaps I'm just unlucky in getting two of these in a row, but I'm
>> guessing this SC is going to send huge shock waves through the native
>> mobile app world. Which wouldn't be a bad thing... but it will be
>> consequential.
>>
>> Even the latest "Tasks" app from Google is locked orientation (in that
>> case it seems that unlocking the orientation wouldn't have much effect.)
>>
>> Anyway, I'm  in favour of a separate SC proposal if we're considering all
>> functionality must work, understanding that making functionality work well
>> in both orientation will be a HUGE endeavour in the native mobile space,
>> more than I imagined. I'd keep this SC narrow to simply not locking
>> orientation rather than ensuring everything works well and build out
>> another one. Maybe Silver could combine them, and in a few years this will
>> be more part of the design process.
>>
>> Cheers,
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>>
>> Tel:  613-806-9005
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>
>>
>>
>> *  Adapting the web to all users*
>> *            Including those with disabilities*
>>
>> If you are not the intended recipient, please review our privacy policy
>> <http://www.davidmacd.com/disclaimer.html>
>>
>>
>> On Wed, May 1, 2019 at 3:07 AM Patrick H. Lauke <redux@splintered.co.uk>
>> wrote:
>>
>>> On 01/05/2019 03:11, Michael Gower wrote:
>>> > There is no requirement in Orientation regarding the content
>>> > presentation beyond the simple requirement that the author not lock it
>>> > to an orientation. It's crucial to differentiate this requirement from
>>> > anything to do with how content may be altered when the reorientation
>>> > happens; that is not in scope.
>>>
>>> Yes, I believe the discussion here (which I jumped into with my reply)
>>> was about retrospectively expanding the scope of the SC, rather than
>>> creating a new SC. (which I believe is not really possible in general)
>>>
>>> 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
>>>
>>>