I still haven’t had a moment to actually start the rebuild of my company’s website, so this might be an obvious answer but…
From what I remember of the “Sparkle” days, the mobile version of the site was a re-purposed version of all the assets of the desktop site. Which means a shoe-horn process of resizing, re-formatting etc. of all the assets from the desktop into a mobile-friendly version.
That always came up with incompatibilities or issues with even simple things like outlines or layout choices that had to be re-designed to be displayed properly on mobile.
What if instead of reusing desktop assets, can I build a completely **independent mobile version of the site, one that DOESN’T share desktop assets, but has it’s own mobile-specific items?
For example, I’ve got a gorgeous photo that works perfectly in landscape/desktop version. But trying to squeeze it into a mobile presentation just doesn’t look right, so I’ve simply re-created that one thing to already be vertically formatted - not having to resize it from the desktop version.
Is this possible, to have in essence two completely separate sites, one JUST for desktop and one just for mobile? Or am I forced to share desktop-version assets and shoe-horn them into mobile?
I’ve done this before, and its pretty simple but may have a lot of maintenance in Sitely depending on the website complexity.
I’ve grouped every element thats for the desktop version inside a group called “Desktop”, and then hid it from the mobile view. Then created all the mobile view i’ve wanted, grouped it into a group called “Mobile” and hid it from the desktop view.
But, if you can design it in a way to make use of structures from both views, then you can hide specific elements to each view and then you dont need all that maintenance. This is very doable by selecting the element > “Arrange” tab > check/uncheck the “Show on This Device” box. This would be great for your image, for example. On desktop view you have the horizontal one, and in mobile you’d have the vertical one, while having them “enabled” only in their respective views
The problem I always ran into in option #2 is that invariably something doesn’t format properly when trying to cross from desktop-to-mobile and then I’m spending lots of time testing the re-formats to discern what went wrong.
So designing exclusively for both platforms might be more effort in maintenance but it seems the only way to completely avoid element misinterpretation when crossing over.
Definitely going to have to test these options to get my head around how they publish.
Thanks!
It’s generally not recommended to completely separate layouts, the content of all devices is part of the main page html file, even if hidden it’s still downloaded to all devices. Assets are inevitably shared.
Additionally text that’s hidden is still technically visible to search engines (though smarter search engines use a browser to render page content and “see” the right content).
The point of a responsive page is to “respond” to a user visiting device and adapt itself to view optimally. Having completely different content doesn’t encourage that, and ultimately makes for a worse user experience.
While there are edge cases where you have content that’s desktop only and content that’s mobile only, either due to the layout, sheer size or special interaction, it would really be much better if the content was adapted.
A Sitely published website to my knowing is one website.
The Devices make up the entire website sharing content and elements. In effect totally separating mobile from desktop will in effect give you two websites which from my understanding will completely confuse the SEO bots.
In the case of other fluid responsive website builders out there, they would also have the same issue as it is one website, but fluidly adjusting itself via CSS to the device it finds itself on.
The idea of hiding the desktop image on mobile, and introducing the newly reformatted image, and then hiding it on desktop is a good solution.
That makes total sense, Duncan, and knowing how things are “seen” by the search engines is critical information.
I always design for visual interest and excitement (when possible) first, then arrange things to have the most useful information second. Kinda the same process I just saw from Nathan’s “one day site build” he just shared.
So knowing the site in it’s entirety is seen as a complete package, not separated items really helps my swiss-cheese brain pre-assemble elements to be as efficient as possible while retaining visual appeal. Not always a straight-forward process, but now I need to think like a search engine and consider content availability/placement not just how good looking it is or how many backend tricks like keywords are placed.
A related question: How do browsers know if you’re viewing on desktop vs. mobile? Do they send out two-way communication that says, “I’m a desktop” vs. “I’m an iPhone or Android”? And if so, do they communicate what the available screen resolution is? Or is it just basic stuff - desktop/mobile and then it’s up to the backend code to adjust things for view-ability?
The mechanism is only based on the width of the screen, and is interpreted by the browser in a relatively crude way, but it’s how all properly responsive websites work. The technical means is something called “CSS media queries”, where Sitely lists the pixel width ranges and the different settings for each.
So we are actually always transmitting this background info out to the web as we browse, that’s the only way the site and the browser can coordinate assets. Got it.
And the ad-blockers could potentially prevent this bi-lateral communication I assume, preventing something from being properly displayed?
It’s never going to be blocked because it would be too disruptive of the user experience. It would mean viewing a mobile layout on desktop or a desktop layout on mobile. Definitely never going to be a problem.
Last question: For the CSS Media Queries, is that metadata automatically encoded when you build the element, or do you need to manually input the physical size/X-Y coordinates on the page so the browsers properly read size and location?
The information necessary to position elements differently on each device is what in the user interface is exposed as the devices concept, so by positioning an element as you want it in each device you’re already providing the necessary information for Sitely to generate the appropriate code.