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.