We are using Grist as a database for a collection of local historic events and use the vibe widget to display it as a timeline. The result is really quite satisfying. I would love to share it with you, but the content can not be shown publicly yet.
We are planning to integrate this timeline in our website via iframe. One problem with our method seems to be, that a visitor sees more than just the rendered result. He can also see download options and every column via the filter menu.
Basically, “?embed=true” is not restrictive enough.
I´m pretty sure I found a similar topic via google from roughly 2023 a while ago but can´t find it again. Back then, there seemed to be no solution for this. Any developments so far?
Another problem would be, that the embedded vibe widget always offers a way to look at the vibe code. But that is something I can accept, because it is enough “out of the way” for the typical consumer. This project has no elements that are top secret. In contrast, showing the filter menu all the time suggests to the user that there are more options to interact with the timeline, even though it effectively does nothing, since they just have viewer access. I just want to avoid irritation.
I’m completely onboard with this - I think I’ve said something similar in the past. I’d like to be able to embed pages/widgets directly from Grist in other websites, but those users really don’t need (and in some cases shouldn’t see) details about the underlying data. It also takes up screen space for features I’d like to hide. This includes the title of the widget, since my vibe widgets generally include their own layout, including differently formatted titles.
Maybe either another variable on the link URL, or (better?) a property of the widget for whether or not to show the Title/Filter bar above the widget?
The ?embed=true and ?style=singlePage options are useful, but they still don’t allow the top menu to be hidden. This is particularly unfortunate because it can lead to serious issues.
For example, the ?style=singlePage mode still allows users to duplicate views and move them around the window in strange and meaningless ways. Even worse, the Custom Widget mode provides access to the HTML code.
At the moment, these limitations are preventing me from using Grist in my company.
After browsing the forums, I get the impression that this has been a known issue for several years. However, I haven’t found any information about whether a solution or improvement is planned.
One idea I suggest is a new value ?style=singleWidget. It would be much like singlePage, but if a page has multiple widgets, only the first would be rendered (the rest would not be visible), and the single widget would have no title, no filter menu, and no widget menu.
Interested to get feedback on this.
In particular @Florent_Beaufort , it sounds like your case needs multi-widget pages to show multiple widgets, only hide most of the interactivity?
In all these cases, it’s important to remember that these aren’t security features – a user would be able to find the URL of the embedded document and open it on their own, with whatever access they have. Actual permissions are still determined by the document’s sharing and access rules.
In our particular case, this would be enough. We usually want to display the content of a single widget publicly. Though that may change in the future, so scalability would be a win.
What determines the “first” widget? Is it always the widget in the top left corner?
Regarding the URL, you are right. That’s actually what surprised me: this type of functionality appears to be enabled simply by adding a parameter to the URL, rather than through the user role settings.
As for the possibility of returning to the “classic” view, would it be possible to use a custom URL with a redirect?
@Till , for the “first” widget, yes, I mean the one in the top left corner (ignoring any collapsed widgets).
@Florent_Beaufort , do you have embedding in mind (when a Grist page is included into an iframe in another website), or are you imaging sharing a Grist document URL directly with your users, and including some parameters to remove options that shouldn’t be relevant?