The biggest advantage of having a separate media query for tablet landscapes is if I want the the look and functionality of the tablet version to differ from the desktop version. As I’m sure you’re aware, there are 3 aspects involved with screen size: Physical dimension, pixel density and aspect ratio. Pixel density will continue to increase, but physical dimension will not change. Aspect ratio is variable, and is based on both of the other criteria. Because of this, a tablet that measures 3 inches by 5 inches may have a pixel density that far exceeds a standard desktop monitor, which might then present layout problems, because the physical size of the tablet, even in landscape orientation, would not be conducive to the layout of the desktop version of the site.
So my main concern is having the ability to change the layout/size/functionality of the site on tablets in landscape mode, if i so desire to do so, to prevent any usability issues on tablets with increasingly small physical dimensions. I profess extreme ignorance as to the workload and implementation of such a feature request, but from the perspective of the end user, this makes much sense to me.
Here is an interesting op/ed about the issue of screen size in the modern web landscape that i found enlightening:
Again, I profess much ignorance on this issue, but do see a benefit of being able to control layout on a tablet in landscape mode. I now leave this up to the discretion of your very capable team on this matter.
You just need to know that your site looks good at approximate sizes, i.e. small, medium, big, biggest. The pertains mostly to changing columns to stack, and altering font sizes, padding and margins as you crunch down the amount of available space.
The trick is then to ensure that your layout is flexible in between each of your media queries. You can do this by having your containers always set to 100% width, but with a max-width of the media query you’re working within, e.g. 100% width with a maximum of 767px or 479px.
Then anywhere between your queries, your layout will still adjust flexibly, as long as you ensure you code everything to be flexible rather than using rigid bg images and so on.
Then you don’t have to worry about device orientation, because you’ve covered all possible dimensions that can exist between each of your media queries.
This also future proofs your designs, as you are covered for all the devices and dimensions you don’t know about yet. For example, we all originally designed for iPad and iPhone resolutions. Then 7" tablets came along and messed it all up.
Being fully flexible and thinking not of devices, but of readability on a sliding scale, I’ve found to be the best approach.
thanks for sharing @kezzb I had not heard of this before. The only issue that initially comes to mind is the lack of attention to aspect ratio, which includes the whole portrait/landscape thing. For a site that is supposed conform to the size of the screen, AND it’s orientation, this may not work too well.
As an example, if I’m designing a site that is modeled after a magazine or book, that flips from one page to the next and does not scroll, i would want the site to recognize the aspect ratio of the devices position (thus determining if it’s being used in portrait or landscape mode) and then adjust the content accordingly, while still conforming the content to only the size of the devices screen. Goldilocks looks great for sites that scroll, but for sites that do not scroll, it might be too simple a strategy to effectively solve the problem at hand.
I would have to spend some more time with it to get a better sense of how it works, though. It might be in there, but i just have not seen it yet.
Again, thank you for sharing. It has definitely piqued my interest
Just 2 cents as a user on the tablet media query (though as a UX consultant, I’d love to conduct some research to discover whether this attitude was shared by a significant percentage of other users):
The most common landscape tablet query design I’ve encountered to date, shared by a number of large sites, is an ongoing annoyance. One of the blessings of a 9.7" tablet is that I can browse the desktop version of a site, which has usually had years to evolve and is generally pretty well-considered. That’s the experience I got the tablet for, as a mobile improvement over small screen devices.
If you create a tablet landscape design that differs from the desktop media query, I think it’s incumbent on you to be sure that it adds significant value to overcome the loss of benefits of the desktop site. In too many that I’ve run into, it feels like the designer has just been too clever by half, creating a tablet-specific version that is clearly not tablet-optimized, and deprives the user of the advantages of the desktop version.
My personal feeling at this time is that creating such a design is a fairly high bar, and would take more consideration and time than most projects can afford in their resource priorities. (Hence the really substandard versions I’ve seen.) And even if done perfectly, it’s dubious whether it will add anything but the most marginal value to users, making the large design time investment a poor use of time.
Thank you for your input @ramatsu I agree with you on all your points. My desire for Webflow to adopt a tablet landscape has to do with my philosophy of the function of a tool. The ideal tool, in my mind, allows the artist the ability to create anything they want and not incumber their creative possibilities due to an editorial omission made by the tools designer. I personally do not like browsing a desktop interface on a 7 to 10 inch tablet: Links are hard to touch, and the interface is usually not conducive to easy hand navigation. These are, of course, my own anecdotal opinion
Your opinion that most designers do not implement good tablet designs I agree with completely. However, Webflow should not impede good designers from doing their job right by limiting their tool set, in my opinion.
I’m with you on all that as well @rchrdnsh. The great thing about webflow is the pixel granularity it offers for the things it allows you to control, and the kind of control over media queries you’re looking for is consistent with that philosophy.
In considering feature robustitude vs. simplicity of UX, and some wild guess at what most webflow users will find valuable, that granularity vs. some approach like goldilocks (only took a second to look at it and get the gist, so I can’t speak to it specifically) are questions that plague product managers at night. Either approach will be a tradeoff; lose some users because of complexity vs. lose others because of lack of granularity.
But the webflow UX team has done a pretty great job so far of putting a lot of power in a relatively simple UI, so I suspect they could find a way to accommodate both, maybe with expert mode panels similar to the current Advance Positioning one.
I would say that for my part, I’d put more sophisticated media queries on my wish list, but below a number of other things for which I have an immediate need, like <span> capabilities, lists, and in the complex end, a mobile media query nav framework (which is apparently on its way asap, yay!).
Of course, those are just my priorities; I won’t venture to guess what most webflow customers would prioritize, those advanced media query capabilities might be high on a lot of people’s lists.
Speaking of which, there are some nice web support tools out there for crowdsourcing ideas and priorities from a user base that would be really nice for webflow to consider adding to the support page at some point!
I guess this has kind of been done to death here above, however the only reason i am looking to be able to separate an ipad landscape media query from desktop is because I am building a site with a video background (following @danro 's instructions over at how to add a background video), and this doesnt work on ipad obviously. so i can set it use the video on desktop, and replace it with a static photo on ipad portrait, however means that anyone viewing the site on ipad landscape will get something that doesnt work unfortunately. Not sure how best to avoid this problem without abandoning the video idea altogether.
Assuming theres no plans to add this query as @thesergie suggested, any suggestions welcome.