On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres <[email protected]> wrote: > > > 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.
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
