[IDEA] A better in-Fibery editor for Custom HTML Pages

Ideas & Features
1

IMG-20260522-WA0045(1)
IMG-20260522-WA0045(1)1600×739 204 KB

I have been using Custom HTML Pages more and more inside Fibery, and there is one thing I keep missing: a more comfortable way to create and maintain those pages without leaving the workspace.

The current editor works, but once the page gets a bit more serious — more structured HTML, repeated edits, previewing, drafts, multiple pages — it starts to feel like I am jumping between two worlds: Fibery for the actual page, and some external editor for the real work.

So I started experimenting with a different approach.

The idea is a Custom HTML Page that works as an editor for other Fibery HTML pages. It is still just one HTML file installed inside Fibery, with no backend and no separate account/service. You open it in your workspace and use it to create, edit, preview, organize, and save other Custom HTML Pages.

What I am trying to solve:

  • edit HTML in a more focused editor;
  • preview changes locally before saving;
  • avoid automatic writes to Fibery;
  • keep drafts/recovery data locally in the browser;
  • keep a local manual history per page;
  • organize pages into local project folders;
  • search across Fibery HTML pages;
  • update the editor itself from inside Fibery when needed.

The main design principle is: Fibery should only change when the user explicitly clicks Save.

Everything in progress stays local: drafts, autosave, recovery, history, project organization. The preview is local too. This makes the flow safer for shared workspaces and avoids unnecessary API calls while typing or just moving around.

I already have a working prototype, but this is still very much in progress. I plan to keep improving the editor a lot, so I am mostly posting this as an idea and asking for feedback from people who use Custom HTML Pages in real work.

I would love to hear what feels useful, what feels missing, what looks confusing, what could be improved, and also what already feels right. Even small comments are helpful at this stage.

The kind of feedback I am looking for:

  • would this solve a real problem for you?
  • what would you expect from an editor like this?
  • what looks good in the current direction?
  • what feels bad, risky, or unnecessary?
  • would local drafts/history/projects be enough, or would you expect something shared?
  • does the “save only when I click Save” model feel right?
  • what would make this confusing in your workspace?

Repository:

2

It looks like claude might be leaning into html too. @ChrisG Could you support html fields like you do markdown fields on entities?

3

That makes sense, and I think I’m starting to understand the direction you mean.

For now, the initial goal is still pretty focused: make this a solid HTML editor for Fibery HTML pages, with a good editing/preview workflow and the core features around that.

The idea of connecting HTML content more directly with entities or supporting something similar to Markdown fields, but for richer HTML/AI-generated specs and reports sounds interesting, but I’d probably treat it as a future direction rather than part of the first scope.

I still need to understand better what Fibery exposes through the API for this kind of use case, and what the safest workflow would be. If more people ask for this, I’d definitely consider moving it up the roadmap. For now I’m trying to keep the first version focused on the editor itself, then open up the deeper entity/API integrations once the core experience is stable.

4

@rabrunos in case you didn’t notice, we are moving in the direction of a custom interface builder.

You might want to hold off doing too much work on this idea until you see what we release (shortly, I hope)

5

Thanks for the heads-up, that’s good to know.

For now I’m keeping this focused as a lightweight HTML editor for the current Fibery HTML pages workflow: editing, preview, saving, and small quality-of-life improvements.

I’m also treating it as a playground to learn more about Fibery’s current HTML/custom page workflow and explore what’s possible there.

I definitely don’t want to overbuild in a direction Fibery may cover officially soon, so I’ll keep the scope conservative for now and wait to see what you release before making bigger roadmap decisions.

Curious to see where the new interface builder is going.