Currently, my app looks great in mobile and… works in desktop.
Do i make different set of screens for one vs the other? Would that impact app speed (use and initial load times)? Is that standard practice? Or make two apps?
Navigation/Menu Tabs dont seem to be able to have a visibilty condition based on screen size. Maybe a boolean function users can toggle to shift views? (internal tool only)
Also, i cannot get the desktop/large screen view to feel nice.
It is very narrow, leaving large areas blank on the sides
There is no persistent “shell” or layout that remains consistent throughout the app
Even breadcrumbs left at the top of the page, move up/down/left/right depending on the content and length of additional breadcrumbs
Settings > Appearance > Top puts all “Menu” tabs in the “More” dropdown at the top. If i move them to “Navigation” they end up at the bottom of the screen on mobile though.
Neither of these is what i want. If I double up all of the screens, and make one visible to mobile, one to large, does that impact loading time?
Speaking from experience, I avoid creating duplicate sets of screens. Instead, I have specific rules for elements that need to change based on screen size, which mainly apply to button alignment (left vs. right).
I simply duplicate the buttons as you suggested, but I have never duplicated entire tabs. That said, I don’t think using multiple tabs does any harm, and it shouldn’t significantly affect your loading times. However, it is best to test it yourself to be sure.
You can fix this using Settings > Appearance > Content Width (which you may have already tried) or by using CSS.
You can solve this by creating a “screen width” (number) column in your User Profiles and setting visibility conditions based on that value.
I have it on wide, and put some CSS to make it wider, although not all components work the same it seems.
I tried the number coloumn for screen width, but that also requires a set coloumn action. I did see that a template coloumn can have access to that data though, so that works!
With a bit of testing, it appears that if i zoom in on PC it will switch it to “small”, but not quite shift the view to a normal mobile view. A boolean toggle that users can set may be more consistent it seems. If i set component visibility to this template, it will show/hide objects as i zoom in, rearranging the entire screen.
Maybe this is why you had it as a basic column, although that returns me to essentially a boolean function.
I’ve never understood these discussions about using a column with screen width and using that as a visibility condition. That approach is so, so, so hacky. We’re talking about Glide here. We’re not supposed to be fiddling around with user interface design considerations.
My take, though probably not everyone’s:
At the very most, it’s probably acceptable to play around with CSS to get different layouts on mobile and desktop. At most. That’s the hard limit. At least we’re talking about code here, it’s back to the roots. It’s not what I personally want to do inside a nocode tool, but I understood it’s a safe go-to option.
Generally speaking, when it comes to apps on Glide, we’re talking about internal business apps and automations. If there seems to be an issue with mobile versus desktop layout, then the issue is actually one of two options: platform-project fit or mobile-desktop display bug. The screen width column doesn’t solve any of those two.
All of that being said, of course Glide still has a lot of work to do on the design of many of the components.
My 2 cents is screen size is pretty safe to be used, I use it for visibility conditions in cases like I mentioned, like @Darren_Murphy suggested and we can’t wait forever for Glide to implement our suggestions for our work.
It’s not safe to suggest CSS if the user is not familiar with it.
@Ja_ke I realized you can use this in your User Profiles instead of ScreenWidth. You don’t need to have a basic number column or write anything, it computes based on the device that is accessing the app.
