It would be very useful to have the option to edit HTML, CSS, and JavaScript separately, in their own tabs or sections, while still keeping the option to write everything in a single file for those who prefer that. This would make larger pages more organized without limiting different workflows.
It would also be excellent to have the AI integrated directly into the editor. That way, users could manually adjust the code and ask the AI for specific changes in the same place, without going back to the workspace.
Another important improvement would be better integration between UI Pages and Embedded Views. When creating an Embed View, there could be an option to select an existing UI Page from the workspace, instead of manually copying and pasting the link.
Version history would also be very important. Since the AI can change a lot of code at once, being able to restore a previous version would make experimentation much safer.
Finally, a Data Sources / Dependencies panel would be very helpful. It could show which databases, fields, and entities the page uses, along with the permissions applied to that data, such as which roles or groups can view or edit those fields. Not to edit permissions there, but to clearly understand what data the page accesses and which access rules are involved.
As an extra for the future, real-time rendering while editing could also help with visual adjustments, but it does not feel like the most important thing right now.
Even as an experimental feature, the potential is already huge.
I think it would be very hard (impossible) to show which entities the view uses, since this is something that is not fixed but is determined at ‘run time’ i.e. when someone visits the view.
Just like any other data view, the entities that show up may depend on the person viewing, the datetime they are viewing and the values of entities themselves.
And we don’t have field-level permissions, so there is nothing to show in that regard
FWIW, we don’t show the permissions that are enforced for databases in existing data views, so I suspect we wouldn’t put time into implementing that for custom pages only.
By the way, the custom pages implement the same access controls that every other data view does, i.e. it should not be possible for a custom page to result in data being readable/editable to users who otherwise would not have those capabilities.
What I meant is not to force a specific style, but rather to offer it as an option by default.
For example:
When the user describes what they want to build, the agent could ask:
Do you want this to follow Fibery’s native UI style?
Or do you prefer a custom design?
If the user chooses the Fibery-style option, the agent could rely on predefined:
design guidelines
UI patterns
styling conventions
so the generated page looks and feels like a native part of Fibery.
If the user prefers a custom style, they can simply describe it and the agent would follow their instructions instead.
So it’s not about restricting flexibility — just providing a native-looking default option, which can be especially useful for users who want seamless integration inside Fibery without extra effort.
I just ran another test, and I’m even more impressed.
I asked it to create a QR Code scanner for entrance control. The idea is to generate QR codes using the entity’s Public ID. When the QR is scanned from a phone, the page reads that Public ID, finds the matching entity, and shows its information in the dashboard.
With this, it becomes possible to manage entrance flow in a very practical way: check whether the person is registered, whether the payment is correct, whether any data is missing, or any other important information. All directly from a phone, just by opening the page and scanning the QR.
The possibilities feel limitless. Creativity is the limit!
Edit: The camera worked perfectly. When I scanned the QR code, it showed all the information from the entity I selected perfectly.
OMG I’m so pumped about this sprint experiment! It reminds me of this thread - Frontend is essential! - where many users [myself included] crave custom UI/UX on top of our Fibery backend data. If you guys can figure out how to enable public portals and reasonably/attractively price licensing for external users, this could soon be the unicorn I’ve been treasure-hunting for years… Let’s ride!!
Surely this will be a sad day to come. It would be nice also, if we can bring our own agent API in case the team expects to make added pricing due to AI. at least to seperate the add-ons for AI and maintain or improve the current non-AI-related/dependent core features.
What I do is I make some examples so I understand how the HTMLs are working (how to get data from Fibery and puts it back), so I can make changes by hand and I need to use less credits. Otherwise you can get a second Fibery account perhaps to get more credits. 12 or 20 euro’s per month is cheap if it really helps you move forward until Fibery’s new AI agent is announced.
This is very powerful, I love this freedom! It’s great that Fibery is not just no code, but also has plays where you can actually code. We can do things that the Fibery team never foresaw, our creativity is the limit! This adds to the top of the pyramid of the hierarchy of needs (as well as strengthen some lower layers) described in the book ‘universal principles of design’.
This blog post summarizes it well (and the book itself is also highly recommended):
As well as some other topics I’ve made. Like I said many times now, this ability to make and embed HTMLs within Fibery (and do it with AI) is very powerful and I love it with all my heart
What I meant is not to force a specific style, but rather to offer it as an option by default.
