Alternative to a 100% viewport height page design in mobile landscape mode

[ajmarriott]

I was given some designs for a quasi social network that I need to build with CSS and HTML. We'll have another developer to do the JavaScript work. For simplicity's sake, let's say each user's profile consists of two views - one is the user's main landing page which is a full-screen photo, some short details about them, and a message input box. Then if you swipe to the left, you'll see the user's other view - a details page. The mocks require that each view is 100% of the device's viewport height, and the views are not scrollable i.e. the height is fixed to the viewport's height. If you want to browse other profiles, you would swipe up to go to the next profile. Also assume that the content on the profile details page will be limited to a number of characters for each section so that it will fit. The designer has already determined what that limit is and what minimum phone size they have optimized the design for. In other words, if you're on a phone that is shorter than whatever the designer designed for, the experience will look bad. (But the designer is ok with this.)

If you're viewing this on a phone and turn it to landscape mode, the phone's height will change to a much shorter height. Aside from using CSS and/or JavaScript to make the views scrollable (i.e. not fixed to the viewport height), what are some alternatives to making this design usable in landscape mode?

Or if you feel the best way to handle this is with CSS and/or JS, please feel free to discuss. One option is detecting if the viewport height is less than a certain threshold then doing stuff to make the views scrollable. But I'd like to hear other thoughts, including if this type of design is not well suited for mobile browsers and should be revisited.

Attached are sample mocks similar to what we received. Also, the designers don't want to provide responsive/tablet designs of this profile. They just want it to be designed for portrait mode.

I'll also note that this is for a website to be viewed in a mobile browser. It's not a native app. Native apps can lock its orientation. Websites can't do that without some hacky CSS or frameworks, which are not options for us. Plus it's not good practice to manipulate a device's OS behavior.

 

[chrishirst]

Plus it's not good practice to manipulate a device's OS behavior.

Says who??

However, website code is strictly limited in what it can affect with respect to OS operations.

what are some alternatives to making this design usable in landscape mode?

Use media queries to swap the image for one that will be suitable, it does not need to be a full height shot, just head and shoulders, [other anti-dandruff shampoos are available] will be enough, or you can simply turn the image off with display: none;

 

[ajmarriott]

Says who??

I believe the idea is that a programmatic workaround could break if an update in the OS ignores it or doesn't completely work with it as it used to.

Use media queries to swap the image for one that will be suitable, it does not need to be a full height shot, just head and shoulders, [other anti-dandruff shampoos are available] will be enough, or you can simply turn the image off with display: none;

Any suggestions for handling the other view, which is the "about" page with all the text? The designer wants the height of the content sections to be percentage based. In landscape mode, it would be a jumbled mess.

 

[chrishirst]

I believe the idea is that a programmatic workaround could break if an update in the OS ignores it or doesn't completely work with it as it used to.

That's only if you are using "hacks" to get around browser/OS rendering problems.

The designer wants the height of the content sections to be percentage based. In landscape mode, it would be a jumbled mess.

Why would it be a jumbled mess?
The good thing about using percentage based layouts is you are in control of how they adjust to the browser window, and how the text 'flows' around images, which is the real purpose of the "float" property.

 

[ajmarriott]

That's only if you are using "hacks" to get around browser/OS rendering problems.


Why would it be a jumbled mess?
The good thing about using percentage based layouts is you are in control of how they adjust to the browser window, and how the text 'flows' around images, which is the real purpose of the "float" property.

I'm not going to use floats. There's no need for that considering the design we were given. I'm talking about the second png I posted up there with all the text. There are stacked, full-width sections of content. Ignore the fact that I put tables in there. The point is the designers want a few sections of freeform text content to be written by each user talking about their hobbies, etc. The designers decided how tall they want the sections to be (percentage based as I said) and they are going to determine a maximum number of characters for each section. The page also has to be 100% of the viewport height (their idea, not mine) so I'm planning on using height: 100vh. Due to the data we collected about our users, the designers also decided to base the content sections' and viewport's heights on an iPhone 4. A real simple test of their design concept shows that in portrait mode of an iPhone 4 it looks ok. But if I turn it sideways, the text bleeds into the next section. I've attached screenshots.

Because the layout looks bad in landscape, I'm looking for thoughts on either 1) a different layout specifically in scenarios where the device height does not have enough room to display all the text without overlap or 2) if we should tell the designers that their original idea stinks and they shouldn't be designing specifically for portrait mode on mobiles. Option 3 is for us engineers to remove the height: 100vh in short heights and have the page be scrollable, but here's the thing (some backstory): our designers are trying to push this movement, if you will, of only creating mocks for phones and not for tablets anymore, saying it will cut their work time as well as ours (engineers). I'm ok with not having tablet designs, but let me tell you what this all really means, at least at my company - It means they want to design for phones in portrait mode only, which is not necessarily a bad thing unless their designs don't work well when a person turns their device sideways. Guess what? The new designs we got are in fact optimized for portrait mode and don't take landscape into account. The whole "the height has to be 100% of the viewport and not scrollable" is the problem. As such, the engineers are not happy because we don't want the product looking like crap on a sideways phone. That's our nature. So we feel we should take it upon ourselves to do extra work to make this thing usable and look ok regardless of device orientation. Unfortunately this defeats their lofty little mission of saving everyone time. Sure, we could say, "Screw it. We're not doing the extra work." But that's against our principles. The designers don't seem to care that it'll look bad. That is something that separates us from them. I'll also add that it's not just a matter of removing one line of css (height: 100vh) and we're done. As far as the whole ecosystem of user interaction in this new feature goes, we have to do extra things to make sure it works just as well. There's more to it than the two sample mocks I posted. And then in the future if they keep giving us new mocks and interaction requirements that simply don't translate well in landscape, we have to build a separate structure to support that. Their wanting to save time is really about saving them time, not anyone else's.

We know that just about no one uses their phone in landscape mode, but as I said, we take a lot of pride in our work and product. So we want it to look like we care when someone accidentally turns their phone. I've read online how some people show an overlay "This site must be viewed in portrait", but god, that seems so lazy. Also, this new feature will be integrated in our existing site built in a certain framework that I'm pretty sure doesn't have a solution for locking the website in portrait mode. Building this thing in React is not an option for us.

That is my rant.

 

[chrishirst]

I'm not going to use floats. There's no need for that considering the design we were given.

You do realise that flowing text around images IS what floats are actually for, so it would mean that you are using them correctly.

[From https://www.w3.org/wiki/Floats_and_clearing ]

What are float and clear for?
If you look in a typical magazine you’ll see images illustrating the articles, with the text flowing around them. The float property in CSS was created to allow this style of layout on web pages. Floating an image—or any other element for that matter—pushes it to one side and lets the text flow on the other side. Clearing a floated element means pushing it down, if necessary, to prevent it from appearing next to the float.

But if I turn it sideways, the text bleeds into the next section. I've attached screenshots.

Which IS why you SHOULD be using floating and clearing appropriately to prevent that from happening.

 

[ajmarriott]

You do realise that flowing text around images IS what floats are actually for, so it would mean that you are using them correctly.

There are NO images in our mocks that need text to flow around them. This is irrelevant.

Which IS why you SHOULD be using floating and clearing appropriately to prevent that from happening.

Using floats and clearing them DOES NOT fix this overlap. Not clearing is not the issue. The issue has to do with the fact each section will have a defined height all totaling 100% of the viewport height so that each section is constrained to a fixed vertical space, once it's calculated. If the calculated heights do not provide enough vertical real estate to accommodate the text without overlap, they will overlap. Period. Floating and clearing floats are not applicable here.

 

[chrishirst]

If the calculated heights do not provide enough vertical real estate to accommodate the text without overlap, they will overlap.

No they will not, you have something incorrect in your code.

Element contents ONLY 'overlap' IF you have 'told them to' in your CSS code, this is generally caused by using positioning incorrectly (usually position: absolute or missing off a 'clear: left|right|none' after using a float plane. From your descriptions the problem appears to be one you have created, probably by trying to 'fudge' your way around using floats, when floats ARE the correct rules to apply to the layout.

'Designers' are NOT always 'right' in what they insist their design to do, especially in the "modern" world of 'Responsive layouts", as a/the developer your part in the enterprise is to make the conceptual design translate to the 'real world' in the closest way possible, and in this aforementioned 'modern' world, using absolute widths or heights is simply NOT practical or possible in some cases.

Absolute dimensions ONLY 'work' at one single size of X/Y and only one orientation (landscape|portrait) of a display device or at sizes that are exact scales of that one size in the same orientation. So; because of this fixed heights and widths have no place in 'responsive' layouts and no matter how you try to make them 'work' they will NOT.