🎉 Glide Community Meetup This Thursday

[erwblo]

It’s 17.11 I’ll grab a beer

[John_Cabrera]

9:38 Regarding Desktop/Tablet conditional formatting and Glide’s desire to make formatting per device automatic. @david: “What we want to learn from you is where we’re failing to do that”

Tiles and Cards for Inline lists are scaled proportionally by the device’s screen width. That means small tiles that might have the use-case as buttons on a mobile device would be scaled so large on desktop/tablet as to no longer resemble buttons. Tall, single tiles (i.e. 1 tile visible per row in a 2:3 or 3:4 vertical ratio) no longer even fits height-wise on, say, a desktop’s landscape monitor or even a tablet in landscape view. I use 2:3 tiles in my app with only one item per row. Perfectly viewable on mobile, but on desktop/tablet in landscape, you’ll only ever see a portion of the tile while scrolling. And given that the tile has been scaled so large, users may wonder why we didn’t just opt for two smaller tiles on that one row, which would be large enough on desktop and tablet… the answer, of course, being that on mobile, two or more tiles per row may be too small. That means we are forced to choose one device look over the other.

I think in general, making the changes between devices responsive and automatic is great. But because components like inline lists are used differently by users (e.g. some use tiles like buttons, some to display classified style information, some to showcase big beautiful graphics), having the flexibility to change number of tiles per row based on the device would be very helpful from a design perspective. I would love to be able to tout having a desktop/tablet version of my app, but my tiled inline lists just don’t look right on those devices, so I don’t want folks seeing it like that.

[John_Cabrera]

26:09 Regarding a quick way to go back to the home screen. @Antonio “If you’re three levels deep, you just press the tab and you go back to the home page”

That is not the case for navigation originating from the sidebar. When you enter a tab that’s been placed on the sidebar, all of those bottom tabs go away and you now only have the Back button as an option to return to the home page of the app. This makes the sidebar limited to screens that only go one or maybe two paths deep.

[JackVaughan]

I think you mean @Antonio?

[John_Cabrera]

Yep. Sorry. I just quickly used the user selector as I was typing in the name and misclicked. I edited the post.

[Travis]

I have tried these options, but unfortunately it would still convert or alter the entry.

[_eric]

@JackVaughan Thanks for sharing the video. This is so informative!

I have a couple of request regarding the on boarding screens ( 48:02 in the video) functionality:

1.Please make sure that the screens are capable of conditions. For example if your user type is a teacher, certain screens show and if your user is a parent, other screens would show. So there would need to be some kind of conditional branching.

2. Please make this available as an option for any form. Not just initial app on boarding.

Thanks!

[Antonio]

@John_Cabrera Ah, yes! You’re correct It does not work with views where the tab bar is not present. While I would not consider 3 levels of navigation that weird or hard to navigate, I think it basically depends on what content you present in that hierarchy and views:

I put together a quick example in the Whatsapp app:

It takes 4 levels to actually get from the main view where the tab bar is present, to an actual image that was sent by a contact: Root level, chat view, contact info, media browser, and finally the image itself.

As a user I don’t really mind this navigation model and all the steps it takes to actually get to the content and back, but we need to consider than finding an image that was sent by a contact is not something that users will do all the time. So with that in mind, I think it really depends on how the content is structured. If there’s something that the user needs to recursively and constantly do, and it’s placed in the fourth view, then it would become a real issue because it would feel really slow and in-the-way.

Thanks for reporting it. I’ll consider what and if there’s an alternative for this

[John_Cabrera]

I just used the number three because you used the number three in that particular quote from the video

I agree it’s not much to ask a user. But some of my bottom screen nav does go deeper than that, and for those tabs I’m restricted to placing them on the bottom bar to give users a quick way out. Would be great to be able to use the sidebar for any tab that could be reasonable to place on the bottom.

Thank you for responding!

[John_Cabrera]

@Antonio perhaps a simple solution would be for the mobile app to function the way the desktop/tablet version current does in this regard… it keeps the bottom nav viewable (just with no accent color highlighting) and therefore is always available as a quick exit. It’s one of the things I really like about the tablet version… for my needs.

Or perhaps make it an option in settings (i.e “Hide bottom nav in sidebar”) Then for folks who only use the sidebar for single pages of info, they have the option to use the maximum screen real estate, and for those who want to place some screens that go a few pages deep, they can give their members a quick way out.

[ToOFa_Apps]

Hi, i’m trying to find out if there is another community meet-up happening this year. Would be very keen to attend that.

[Manikandan_R]

Hi Jack,

Sorry i couldn’t join.
I’m going to see workspace for my startup using glide.

All the best for the meetup.