How to deal with components in a responsive design being larger at smaller breakpoints?

Question

to note, I'm using screen size heuristics to make estimations on viewport height based on width to simplify the deisgn. This is possible a faulty heuristic and maybe would be better off using a height query rather than a width query for complete accuracy. The issue will exist in either method

another note is that the banners and navs as described are required to be static elements. Once they're displayed, you cannot scroll them away.

I have a web app design that is very vertical-space sensitive (supporting users at 1024x768 resolutions minus browser chrome), requiring two navigation elements because of certain technical reasons.

A third banner component needs to be added to the screen in certain contexts. Given this sensitivity, I'm looking to wrap the component into the top navigation as soon as horizontal space allows, as such

(I've removed identifiable elements)

At the smallest breakpoint there isn't enough horizontal space to place the banner into the top nav and we have to make do. It's ok, at these widths you're not as vertically challenged because you're likely in a portrait orientation.

At the next breakpoint it becomes possible to place the component into the top nav:

It leessens the pressure on vertical real estate because at this size you're likely into a landscape/4:3 environment and now we're pressed for vertical space.

At first glance everything seems fine. The component fits, and it's a little larger than at the 320 breakpoint.

However, the whole app is fluid and so that 320 breakpoint is also the design at 500, or at 577. In these situations the space available for the banner is far larger than it is at just a 1px increase in viewport.

for example, at 550 the banner could be 518 wide but when we increase the viewport to 600 the banner is suddenly only 328 wide.

And this becomes a challenge because the banner actually has a dynamic display and is far more usable at 550 than at 328. I'm trading off usability in one direction for usability in another.

((e: it is plenty usable at any size. but the experience as we get more space is admittedly nicer. The banner has a minimum standard for information and the result cna become compressed))

I can't be the only person to have encountered this issue (responsive nav do this sort of thing all the time but in their cases the extra width is not being utilised to the extent that the banner component here would be).

Any advice or guidance from experience or otherwise to help me out with this issue?

Do i just keep the banner underneath? Do I prevent the full banner experience at the lower breakpoint to improve the progressive expansion at a larger breakpoint? (no) Do I just accept that when trying to account for these competing sensitivities that something has to give and as long as the banner is usable then these edge cases are just a thing that happens?

Cheers for the input.

Answer 1

I would recommend keeping the banner in the top bar for as long as it is usable and the user can get the full experience from it. When there are issues with the available space, move the banner below the navbar as the user will prefer to scroll down a bit than to have a considerably worsened experience just because of an unlucky display size.

You could also try to remove some less important options when there is less room, if you really don't want to move the banner below the navbar. I would suggest using the solution in the first paragraph but the decision belongs to you.

Answer 2

Seems like you are actually looking for "element queries", that currently don't exist, instead of media queries.

So you want to change behavior according to the actual banner width.

Recently there was a script called eqio (https://github.com/stowball/eqio) wich sets classes based on width rules you define for that element. There are other scripts emulating element queries.

As css is not capable of doing these queries, a script is a fallback solution. I am not that happy with this solution, but it's the only way to support good ux in either case.

Answer 3

It sounds like you may just be moving this element into the top bar at too small of a breakpoint, if the 328 space is compressing the content too much.

You may want to add a custom breakpoint that applies to this area -- a lot of people use the standard 768/1024 breakpoints, but really you can base breakpoints on any number if it does a better job of laying out the content at particular sizes.