Re: [manifest] orientation member

On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>
> On Wednesday, December 4, 2013 at 5:26 AM, Jonas Sicking wrote:
>
>> 3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri <mounir@lamouri.fr (mailto:mounir@lamouri.fr)> wrote:
>> > On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
>> > > My impression has been that the vast majority of apps only need a
>> > > single orientation that is independent of media-query results. If
>> > > that's the case, then I think the above is too complicated. I.e. if
>> > > that is the common case, then we should support:
>> > >
>> > > "orientation": ["landscape"],
>> > >
>> > > or maybe even
>> > >
>> > > "orientation": "landscape",
>> >
>> > I definitely agree with that. Though, we should allow both syntaxes
>> > (array and string).
>> > If we want a more complex system later, we could move to that. For the
>> > moment, I think we should keep it simple. Also, when comparing how
>> > applications handle landscape/portrait, it is worth considering how
>> > common/easy it is to write responsive UI on the platform. iOS has a very
>> > limited number of device sizes so I am not really surprised that iOS
>> > applications try to optimize for some sizes (thus arbitrary ignore some
>> > others). Is that common on Android? Would that be common using Web
>> > applications?
>>
>>
>>
>> I too am curious what the use cases are for switching orientation
>> based on screen size is. If your app runs fine in both orientations,
>> then why lock the orientation at all?
>
> Yes, of course when one presents it like that ("if it works on both, why lock it?") it seems to makes sense: but it’s overly simplistic: It’s only in the opposite case (on smaller devices/phones, single locked orientation makes more sense)… i.e., this is a “mobile first” design issue - where even though it “works” in landscape, the experience is so sub-optimal for some application types that it’s not worth optimizing/designing for. However, the Web case may be unique, in that installed applications are bookmarked from browsers, which generally support portrait and landscape on phones and anything bigger.
>
> You can see that the landscape experience is sub-optimal if you just play around with apps on your mobile phone that are not games. With the exceptions of a few apps (e.g., calculator on iPhone, which turns into a scientific calculator when rotated; and the Stocks app - which shows a graph view when rotated to landscape), I’m confident that you will see that even the ones that support rotation are not particularly useful in landscape mode (i.e., are more natural to use in portrait - particularly web applications). Games are always the exception, as they really do require landscape to support for continuos interaction (i.e., because the user’s fingers are on the screen so would block too much of the viewport). Also, on phones, starting applications is generally done in portrait mode (at least on iPhone, Android, and FxOS) - so most apps are expecting to be launched and primarily used in portrait.
>
> But that’s not the case on tablets (particularly for applications that are both created for both phones and tablets) - where it’s natural to hold the device in any orientation. This leads to the problem:
>
> 1. an application may work best as portrait on a phone, but has to work on any orientation on tablet. Forcing a single orientation would only be useful for games - all other application types would need to support any (forcing developers to have to design for landscape on small devices when they don’t have to in their native counterparts - or worst, they have to display a “rotate your phone portrait” message to users, as some apps already do - e.g., forecast.io displays advertising for a future product when rotated to landscape).
>
> 2. Forcing an application on a table into portrait leads to a bad user experience (because a percentage of users will be unnecessarily forced to rotate their device to portrait). So I don’t imagine anyone will use this, unless they are using UA/device sniffing, which would show that the solution is broken.

Ok, makes sense.

So my counter questions are:

1. Could we get away without using generic media queries and instead
only allow switching on screen size height and/or width?
2. Could we get away with just using static orientations in v1? I.e.
punt using different orientations for mobile/tablet until v2 of the
manifest?

/ Jonas

Received on Monday, 27 January 2014 21:48:54 UTC