Screen layouts that appear multiple times in my app have are cumbersome to create and maintain

Feature Requests
21

This would be great and very helpful, I suggest that screen layouts get a name and can hence be reused at different places of the usage flow.

From what I read in the documentation I got the impression, that one sheet only can have one screen layout.
But that is unfortunately not true. If you’ve built one screen based on a sheet and on another place you want to show the same content based on the same sheet, you have to build the screen again, duplicating all changes which come up during the development.

22

The layout attached to the sheet rule comes into play below the top level of a tab or link to screen button. If you have multiple tabs that all refer to the same sheet, you can design each tab independently because it is the top level. If each tab contains a list and you then view the details of each list item by clicking on it, then the details will have a layout that is shared throughout the app because you are now at the second level below the top level of a tab. Layouts are still attached to sheets, but only the details layout and only once you drill down into those details from a top level list.

In my app, I have a list of student lessons that are listed and added from the top level Lessons tab. The details screen of each student lesson was designed at this point to my liking. Drilling deeper into the app, I have billing and invoicing and I can have a relation that can pull and display those student lessons for that billing period. When I add a relation to the relevant student lessons in the lessons sheet, I can add an inline list withing that billing section and when I view the details of each lesson in that list, the layout is already set from what I did previously in the Lessons tab.

As I always say “layouts are tied to sheets”, but this only applies at any level below a top level tab or link to screen button. Basically viewing the details of a list item will respect the layout throughout the app.

1 Like
23

Jeff – Stepping up a level, does this mean that it is unlikely that embedding standard parts defined once and included many places (such as a standard footer) is going to be difficult to implement and thus not likely to happen – at least not soon?

I got to this discussion because I want to define a footer that is composed of several components and include the one footer in multiple tabs throughout my app. Pretty standard way to think of including a module in lots of places but to change it, you only have make the change in one place.

– Harry

24

If you’re doing it on a tab level then it won’t work, the only way to do it as of now is to have those components in an item-level details view.

25

If everything, then I’d like the ability to copy and paste some of @Lucas_Pires designs :laughing:

1 Like
26

Would be amazing @Darren_Murphy :laughing:

27

What did you ultimately end up with for your footer? Was it a combination of components, or did you get it all in a rich text component with CSS and HTML? If you have is all in in a rich text component, then there are a few ways to store it globally, load it on each screen, and still only need to change it in one place. I do this myself using user profiles. If I recall your app correctly, you may not have the option for user profiles. However what I have is a couple of sheets that store CSS and Images in one location.

In my user profile sheet, I have Single Value columns that pull those images and css from the other sheets. I load this into the user profile sheet, because it’s easy to access that sheet’s data anywhere in the app. Then I can simply add a rich text component and fill it with any css or image urls that are globally stored in the user profile sheet.

In your case, you may not have user profiles, but you could easily do something similar and create single value columns that pull in the html and/or css from a single sheet into every other sheet. Then add a rich text component that is filled from that single value column on each sheet. That way every page can have the same footer, and you can update and change it in one single sheet. From there it will propegate to all other sheets via the single value column.

If you ended up using several components to build your footer, then this is obviously more complicated. You would still have to add each component separately, but some aspects, such as links or images could still reference a single value column like I mentioned above.

To have a set of components that can grouped together and copied to other screens is probably a bit more complicated than it might seem. I think a lot of components and screens are deeply rooted to the sheets and columns that they were set up with. To be able to copy things around would take a lot of write checking to see if the new location is compatible. I feel like it could be more of a headache, than a convenience…at least with the way glide is currently designed…bit that’s not to say that maybe glide will consider it someday.

3 Likes
28

Jeff,

You asked:

“What did you ultimately end up with for your footer? Was it a combination of components, or did you get it all in a rich text component with CSS and HTML?”

Originally, I was using a rich text component with HTML & CSS. The problem I had with that was that the images in the footer were stored on my own fileserver and frequently would show up as broken images when viewed on my iPhone and on my laptop – although curiously they were downloaded correctly when viewed in the Glide editor. I tried to keep that strategy because, as you said, I could put the HTML & CSS in one sheet so that changes could be made in one place.

Then I started thinking perhaps the problem was my file server and read that the best place to store images was through Glide, so I tried that. It seemed to work better.

But, I still wanted to try to live the promise of the Glide claim: “Create apps visually, without code”. Doing things with HTML & CSS seemed to be cheating. And that is why I wanted to go back to using only Glide components for my footer.

So, I still believe that we need to continue to push for the standard good practice of modularization and embedding for all components, even if the implementation might have to be rethought.

As a programmer I love the very unusual practice for a startup like Glide to have such an active user community like this so early on in their existence, having an influence on the development of Glide. I think this has been great for experienced developers to put their needs into the forefront of developments, but it has also resulted in a somewhat chaotic path to getting to the point where the Glide experience will feel like we are building apps without writing programs.

This is my biggest concern: In our desire to get everything we can do with a general purpose programming language, are we pushing Glide to become like all of the other development systems we use to produce real smartphone apps. What happened to the original goal of Glide which I remember hearing in one of the early marketing videos, which went something like this:

Our goal for 10 years from now is to have a development platform that 1 billion people can use to create smartphone apps.

I have a lot of thoughts about what this statement means:

  • What the vision of Glide represents
  • What things need to change from the current way (procedural programming) we use to build such apps
  • The impact initial users have on the incremental design of Glide
  • The feedback incrementally developing Glide has had on the increment design Glide
  • The realities that a startup has and how those realities shape a product.
  • How we enthusiastic programmer developers of smartphone apps can help the Glide team get to their declared goal.

Stay tuned for my thoughts on each of these points. I will appreciate all of your comments when I complete this missive :slight_smile: .

3 Likes
29

Note: I submitted this and then spent the next 15 minutes revising it so that it said more of what I was thinking. I hope it reads better now …

1 Like
30

Totally agree. Even though I have a handful of css and html tweaks in my app, I try my hardest to build as much as possible with only the native glide tools available to us and with little to no back end scripting. So, I completely understand what you are saying. I’m also a fellow programmer, but I like that I can step away from code every once in a while and still be able to build something useful.

I think Glide is getting there bit by bit. I think back to what it was two years ago, and how most logic had to be done with formulas in the google sheet compared to what we can do natively now. It’s amazing how far they’ve come. I think the glide team does see a lot of these workarounds that people do and ultimately take that idea and build simpler native solutions for them.

But yes, at what point does it start becoming a complex IDE? I think there is always going to be some people that want granular control over their design and logic, which may be out of the scope of Glide, but we are getting more and more options handle these things natively.

5 Likes