On Wednesday, December 4, 2013 at 5:26 AM, Jonas Sicking wrote:

> 3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri <[email protected] 
> (mailto:[email protected])> 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.  




Reply via email to