# Updates on Requested Features? **URL:** \ **Category:** Feature Requests\ **Created:** [July 27, 2023, 9:49pm UTC](https://community.glideapps.com/t/updates-on-requested-features/64437 "2023-07-27T21:49:47Z")\ **Posts on this page:** 1\ **Showing post:** 25
**Author:** ![drascon](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/drascon/32/20070_2.png) [@drascon](https://community.glideapps.com/u/drascon)\ **Post date:** [August 29, 2023, 8:35pm UTC](https://community.glideapps.com/t/updates-on-requested-features/64437/25 "2023-08-29T20:35:06Z")
> [@david](#): > > We have 17 engineers at Glide. 1 of them is focused on AI, the rest are working on scaling infrastructure, SOC2, SQL data sources, CRM data sources, bugs, testing, and UI improvements. I am not questioning the number of Glide engineers that are on staff, nor am I questioning their work ethic, productivity, or assigned tasks. I am simply pointing out that there have been a handful of announcement posts recently in which users have been challenged to integrate AI into their apps; yet, since the official launch of Glide Pages / (new) Apps nearly 2 years ago, there have been requests on requests on requests by the user base for the features that I mentioned and it’s been either conjecture by forum members or total radio silence by Glide staff until you responded a few days ago. > [@david](#): > > - Floating button > > No work planned on this. > > - Zoom in / Enlarge action for images > > Not planned. So that all forum users are clear: how many more duplicate posts and feature requests are needed for these to be added to the roadmap? The workaround for our users to zoom in/see an image enlarged is absurd - not to mention impossible - if they have no internet connectivity. And, forcing users to scroll to the bottom of a (sometimes) very long screen just so they can return to the previous one (when there is a custom action tied to a non-floating button) is cumbersome and ugly. These are strange features to omit especially when they’ve been requested so many times; having them only help us make our apps that much more visually appealing and user (and no/low-code) friendly. > [@david](#): > > - TRUE offline mode - **actually loads offline** > > It’s impossible to load new data offline, but I don’t think that’s what you meant. You are correct - that is not what I meant. Similar to how a native Android or iOS app behaves, I’m simply looking for mine to download/cache ALL information on the end user’s device during the initial installation so that it will open and function normally when internet connectivity is low or non-existent the next time it is opened. Updates would be obtained the next time the app is re-opened in an area with adequate internet signal. If we are attempting (literally and figurately) to sell our apps to users by calling them “apps,” they should behave like an “app.” And yes, some folks create apps that DO require constant connectivity but there are some of us that don’t, and to have to jump through hoops to get ours to function appropriately offline shouldn’t be this difficult. Glide clearly has the ability to keep what is downloaded on the individual device in a cached and useable state, as evidenced by the functionality of the current “(partially) Offline Mode” feature. So, why can’t the session be stored indefinitely and the data can be updated every time the app is re-opened subsequently, and successfully (i.e., connected to the internet)? If Glide truly has no plans at all to introduce this type of offline mode, please let us know so that we can stop hoping the feature will appear someday and we can take our apps, and our time, to another platform where it is already available. > [@david](#): > > - TRUE offline mode - **actually loads offline** > > We’re currently focused on allowing customers to use Glide with their own databases (e.g. SQL), so offline support is becoming even less likely as we support databases. If I recall, and I may be way off the mark, we were advised that migrating our apps from Classic to (new) Apps was strongly recommend because they would be fully optimized for mobile and desktop devices, maintain all the same core capabilities from the Classic Apps that we loved, and would include powerful functionality like Big Tables, Actions, and Integrations that the Classic Apps would not; additionally, we were told that if we wanted to get the most out of Glide, we should consider using Tables instead of external data sources because they could hold much more data than a Google Sheet, we could share tables between apps, and they wouldn’t cause sheet edits/sheet reloads. Are you now saying that Glide Tables are no longer Glide’s focus? My assumption is that, because you made this statement as part of your response to my request for a true offline mode, those of us who built our app databases entirely within the Glide database structure (i.e., Tables), or migrated away from Google Sheets entirely in order to benefit from everything that is mentioned above, should no longer expect a true offline mode because Glide’s focus is on… external databases? Those of us who are all-in on Glide won’t benefit from a true offline mode because of users who aren’t? The logic here is baffling. > [@david](#): > > - Native Glide conversion tool to import data from Google Sheets > > Interesting. This is something we’re discussing. You mean, create Glide Tables from a Google Sheet? Exactly what @David_Gabler said: > [@David\_Gabler](#): > > What this means is that Apps that currently use a Google Sheet would be able to convert the Sheet to a Glide Table (along with all existing computed columns). You already have this for Excel. In fact, if you duplicate an App using Excel, all the references are changed to Glide Tables whether you like it or not. There is no option to retain the pointer into Excel. It seems that you could simply turn off the sync to Google and change the pointer to your internal Glide Table to do this. > [@david](#): > > - Ability to change the type of text component in use without having to re-type the input data > > Can you say more? I don’t understand. > [@drascon](#): > > Example: I have a significant amount of descriptive text that I want to appear in a specific way in my app, so I select the Text component, then add my text into the data field. After performing this action, I review what it looks like in the builder and realize that the Text component doesn’t present that data in the way that I want it to and it would be better served in a Rich Text component or, perhaps a Hint component, or even a Headline. > > Now, I have to re-select another component (i.e., trial and error) and copy / paste the data into that until I find the one that works. > [@david](#): > > - A native accordion component for lists > > Can you share an example you like? This: [CSS Trick: Inset Switch Components for Grouping](https://community.glideapps.com/t/css-trick-inset-switch-components-for-grouping/35134) > [@david](#): > > - RTL language setting > > Not planned. This one isn’t for me but it’s in the top-5 requested features so I wanted to make sure that my fellow Hebrews are represented 💪 --- _[View the full topic](https://community.glideapps.com/t/updates-on-requested-features/64437)._