Re: [manifest] orientation member

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.  

> I thought that the main use case was for something like a video player
> or a game that wanted to always be in landscape mode was the main use
> case?
>  

No - specially the video use case is not really valid because videos will usually just enter full screen mode and allow any orientation once they start playing (think of them as an application within an application). Again, the 300+ odd apps we looked at paints a different picture: small device, then single orientation (generally portrait primary) - unless it’s a game. Tablet device, free to rotate to any orientation - tablet applications that lock to an orientation are annoying in that they are unnatural to use (unless it’s a game, of course).

We could assume that any orientation be supported on any device, but this means we (browsers) are putting developers in a bad situation again of not having the freedom to control how their applications are displayed on different device types. This can lead to a degraded user experience, particularly on small devices.  

Having said that, we could incrementally build this up over time: start with simple locking to at least better support games, and then add better control through viewport later. I would be ok with, but and hopefully it won’t lead to a ton of UA and device sniffing.

Received on Monday, 13 January 2014 09:44:44 UTC