No more switchable mobile/desktop layouts?

Contribute UX
,
1

Hi there, I’ve been on stable, now on the latest esr , and it appears that there is no longer an explicitly switchable mobile/desktop layout? I no longer see the toggle in the bottom left corner of the sidebar, and ?mobile_view=1 / ?mobile_view=0 no longer has any effect. It now transitions from desktop mode with the sidebar and the hamburger menu on the left to the mobile layout with no sidebar and the menu on the right by just horizontally resizing the desktop browser window. So is it now just based on the browser width? Previously it allowed for using the simplified mobile layout on a wider tablet screen if desired, or alternatively it allowed for the desktop mode (with more details in the topic list for example) to be used on a smaller phone or a narrow browser window for those users that preferred it.

1 Like
2

That’s correct - we’ve been moving to simplifying our layouts to be properly responsive as it’s a more widely accepted design standard to use a width-responsive breakpoint. We’ve also found it simpler to maintain, and a width-based layout also plays well with other external design elements, such as when integrating shared banners across a main site + forum.

5 Likes
3

One of the downsides of this approach is you can’t run device specific logic in an initialiser.

A classic example is setting a different homepage for mobile vs desktop - you can’t do this now.

Imho this is going to require a much more dynamic approach to how templates are made.

2 Likes
4

Thanks for the reply. In principle that makes sense, but in practice that is a bit of a problem for more advanced/frequent users. As I mentioned, there is much less information visible in the topic list when in the reduced layout mode, especially compared to the desktop layout of something like Sam's Simple Theme, so some preferred to explicitly force the desktop layout, and it even still adapted correctly to make it fit horizontally without overflowing.

2 Likes
5

There are limits to doing this that we’ve removed with new methods — determining capabilities on init is fairly inflexible, if something changes we’d have to reload the whole page.

This is useful because devices are less predictable now: phones can unfold into tablets, laptops can convert into tablets, you can plug in a keyboard and mouse to so many things…

It feels different if you’re used to the old way, but anything you were doing in an initializer is likely still possible and more responsive to changing capabilities.

You can, now it’s more granular and you conditionally show/hide content within the same template rather than swapping out the whole thing. For example, we have a viewport object in our capabilities service now…

In a template…

{{#if this.capabilities.viewport.lg}}
  Content for large screens
{{/if}}

{{#if this.capabilities.viewport.sm}}
  Content for very small screens 
{{/if}}

or in JS…

get myContent() {
  if (this.capabilities.viewport.sm) {
    return "short content";
  } else {
    return "the very very long content"
  }
}

and then in CSS you can align with the same breakpoints like…

@use "lib/viewport";

.my-element {
  font-size: 1em;
  @include viewport.until(sm) {
     font-size: 2em;
  } 
}
5 Likes
6

Sure, I’m aware of these replacements.

I’m looking forward to seeing patterns like this more fundamentally used though.

Like if my homepage is Categories on Desktop I get to see a Topic List.

A Topic List should also arguably show on Mobile too … currently you lose the Topic List element.

This is why the Force Mobile Homepage TC existed …

I hope I’m making sense …

3 Likes
7

Yeah makes sense, I think we will gradually make supporting changes like that… it’s just tricky when we’ve built so much using the old ways and have to support them in a way that doesn’t immediately break customization.

3 Likes