Hi, I come back to an idea of building a differentiated site for mobile and desktop. Would it be possible with Elements to build both a mobile page and a desktop page that can be modified at will to solve display problems, or even to present a completely different display? I am thinking of an option that is completely different from the current display and hiding possibilities according to the display media.
Can you provide more details? Maybe I just don’t get it, but what is your intended differentiation in usage?
You’d need some form of device detection (also see DeviceAtlas), either on the server (using PHP) or client (using JS) that would allow you to specify what devices you consider ‘mobile’ and what you consider ‘desktop’ (and where do iPads/tablets fit in?), and what actions you’d like to take for your various device contexts/conditions.
In the past folks used to build entirely separate sites when they wanted to offer very different experiences on various devices (ie. https://m.domain.com), but that practice has largely been replaced (for better or worse) by responsive design, which as you said, tends to hide things — unless you’re using component-based frameworks such as React/nextjs, Vue/nuxtjs, Svelte, etc which enable you to compose your interface at runtime (often in the browser) delivering only the components necessary for that device/context.
That’s a very different way of building websites (they’re more like web apps) than what we’re currently seeing within Elements, which is still largely a static site generator (much like the code-based ones such as Hugo, Jekyll, Astro and 11ty), but with the added option of using PHP on the server. So far, I’m not seeing any signs of being able to conditionally load components within Elements, but what would make a nice feature request down the road.
So to sum up, it is possible to do that in Elements (either on the client or server), but it won’t be easy (unless @dan has another surprise in store for us), and will require writing some fairly complex custom code.
FWIW the easiest way to accomplish this would be using something like js-mobile which would be a ‘good enough’ form of device detection, with which you could write some JS code to redirect to whatever page you want to send them to. It’s not a light bandwidth solution, and isn’t recommended for mobile devices - especially those not connected to wifi networks, but it would get the job done.
There’s a reason why most folks moved to responsive design, and modern component-based client-side frameworks. 
FYI in a previous life I was very involved in creating developer documentation for mobile web sites and apps incorporating responsive design and device detection techniques.
Thank you for this very detailed answer. To make it short, yes I hope for a surprise from Dan, even several 
I’ll take an example: overlay effects are good with a mouse, on a touch screen it’s less obvious (it’s also true for many other layouts and/or effects). This is the kind of obligatory distinction between mobile and desktop, in fact between with a mouse and without a mouse 
touch-not touch 
well I’ll stop there for the examples. I had already tried to bring up a discussion on this point (responsive is not always the right option) but I was taken back quite quickly so I didn’t insist but I’m persistent. So here I am again with a proposal for Elements. And yes it would be good if it were done server-side directly by Elements, you read my mind Bryan. What do you think?
1 Like
Hey @bruno, it’s actually very difficult to determine if the user of a device is actually using a touch screen, a mouse, or a keyboard (many Windows laptops support all three, as does an iPad/tablet with a keyboard and a mouse). If you simply assume that it’s an iPad therefore they’re using touch you’ll likely annoy many users who are using keyboards and mice.
The best strategy is really to design with accessibility in mind, as browsers will often utilize assistive technology built into the OS, as well as W3C/WHAT-WG/ARIA standards to ensure that the website/webapp is accessible, and behaves as expected regardless of which input modality or device(s) someone is using.
I’m hoping much of this will be baked into Elements, and that the developer docs will provide clear guidance on how to make custom and 3rd party elements fit neatly into the overall Elements user experience—both within the Elements app itself, as well as any site published using Elements.
Yes Bryan but I think only about mobile (smartphone). Not the multiple bull… intermediate formats. We also have to think about Vision Pro
1 Like