Frontend is essential!

I have a suggestion: why not create a feature request that is specific to this new ‘website view’ that you have in mind, and let other community members pitch in with comments/ideas.

Plus, create feature requests where you see opportunities for improvement with existing Fibery views.

I think a generic topic like ‘Frontend is essential!’ is inevitably going to mean many different things to different people, so we will end up talking at crossed purposes.

1 Like

This conflict with all fibery public statements…and even if that true, internal tasks need frontend :slightly_smiling_face:

Ill do that once the concept fully developed for me…

But this whole post explaining why fibery team need to think of frontend strategicly especially there is many suggestion about all fibery frontend components and the plan to build mobile / home page / website redesign … all these relate to lack of stratigic frontend plan.

May i ask a question? Why do fibery team decided to provide some information in the main site as fibery workspace (ie api, public roadmap, etc), and some as website (ie. Blog post, home page, etc)??

Yes, internal tasks need a ‘frontend’. That’s why we have tables, boards, lists, timelines, maps, feeds, documents, whiteboards, etc.
But they are views intended primarily to support processes involving ‘internal users’ e.g. I need a kanban of tasks, I need a timeline of my projects, I need a table of assets, I need an internal wiki, etc.
They do not support very well the processes where external users are involved, e.g. a public facing website, a customer support chat function, a blog, a marketplace, an email marketing platform, etc. It’s not what the Fibery views are designed for.

The information shown in the roadmap is based on data that is stored in our own internal Fibery workspace - we are exposing information that already exists by virtue of the development work we do. It made sense to share a space, rather than use a separate tool for our public roadmap (even though there are tools that exist for that purpose).
The user guide / api docs were previously hosted in dedicated tools/sites but we moved them to an internal space so that it was easy for many people to make improvements/corrections whilst staying in the tool they already spend most of their time in (= the Fibery workspace).
The public Fibery site indeed shows that Fibery is bad at serving as a CMS/website tool, but we live with the drawbacks for the benefits that exist from doing so.
If someone is not already using Fibery, then I wouldn’t recommend it as a tool for public facing sites.

If that is how our public-facing material comes across, then we are not doing a good job with our marketing :cry:
Please show us where we are leading people astray :folded_hands:

Fibery does aim to replace many tools (spreadsheets, documents, task managers, CRM etc.) but it can never be the one tool that will replace everything, and we are not currently focussing on the use cases that you indicated were important to you.

It’s not to say it won’t happen

1 Like

I know WordPress is old tech at this point, but would an official Fibery integration/plugin resolve this “lack of front-end” problem? Not that it’s really a problem, more an annoyance to the users in this thread

see while we are open this health discussion … softr started their backend.

that’s same approach is seeing from most of those ALL-IN-ONE tool they either start from frontend and then backend or from backend to the frontend … this whole discussion is needed for fibery near future!! and i hope fibery think of this strategically …

3 Likes

Well I was sceptical first but airtable is doing this quite good and the potential for client portals is huge with Fibery’s logic and structure. I would love to see something similiar to Airtable interfaces and I think it could push Fibery’s adoption. There’s no need to have Loveble like solution.

5 Likes

Hi everyone :vulcan_salute:

I have used Coda and Notion, there is a huge potential for Fibery to improve this.Using a doc and adding embedded views is not as nice as it could, with embedded frames feels clunky and not clean.
Dashboards are a great concept, but the execution is not there, I want to be able to add text, images, and views similar to a Notion/Coda Hub, instead, are more divided views.
Airtable is getting also more attention to this!
Fibery is complex and powerful! But I don’t want to have 7 views of my data separated, want to have them clean on a “Document” or like mentioned “Website view” without frames or any other buttons that break a seamless interface.
Imagine being able to add formulas on text, imagine to add the buttons inside the doc and create your own apps in that view!

Thumbs up for Fiberys Website, the look, the emojis, text, links, animations, all that stuff is how I imagine my data from Fibery, a modern clean interface

3 Likes

Well said @Finanzamt_Muellheim

Very good points!

1 Like

My search for “fibery frontend” led me to this thread, where OP describes the sort of full stack convergence I’ve been dreaming about for a while. But after reading every word of every response, I’m convinced many people still don’t understand OP’s core argument/request, or perhaps just disagree that such consolidation would indeed rock our worlds. And I presume the confusion stems from unintentionally conflating two very different types of frontends - one that is highly configurable for builders, like internal power users, architects, scriptors, developers, aka the producers - and another that is fully customizable for users, like external clients, vendors, investors, students, members, patients, residents, visitors, aka the consumers.

Generally speaking, I think many of us on this forum - whether we realize it or not yet(!) - would LOVE a single hybrid database visualization platform that could serve both internal AND external users equally via stock environment widgets OR bespoke white label interfaces - yes, including public websites, authenticated web apps, and even local-first mobile apps. And if all that sounds crazy, just wait and watch someone do it. :popcorn:

As a case in point, I intend to build my own property management software to run my multifamily real estate company, where I’ll need logins for residents, investors, employees, and vendors, along with unique UI/UX for each. Could I pair Expo React Native with Supabase? Sure. But ain’t nobody got time for dat! :sweat_smile: I’d rather Fibery or Notion or Coda or SmartSuite or ClickUp or Monday or someone with serious relational database / work management chops either acquire or draw inspiration from Softr or Adalo or Glide or another visual app builder to enable pixel-perfect publishing of anything we want anyone to see or interact with, rendered directly from our source repository, requiring no third-party service or sync.

I personally believe whoever controls the configurable backend has the leg-up in this custom frontend race, in part because holding the source of truth is sticky, but moreso because your technical gap is smaller, and you can close it faster. Softr, for instance, lacks so much of what Fibery can do out of the box (even after adding databases), and I doubt they’ll close this giant gap soon enough to win the all-in-one company-OS crown *unless they acquire Fibery somehow. :winking_face_with_tongue:

As for other contenders, Notion looks poised to pounce after their impressive 3.0 release, but then again, their previous Sites feature left a lot to be desired *to Super’s and Bullet’s relief(!), so I’m not holding my breath on a NotionApps killer either.

Airtable charges way too much for authenticated portals, especially when accommodating a high number of infrequent users, so they’re a cost-blocked non-starter as far as I’m concerned.

Baserow made serious strides in their recent 2.0 release. I already built some slick, responsive apps in v1.34, so next I’ll explore their new agents and automations too. Notably they seem to offer the most affordable authenticated portals for accessing live business data in whatever format. Plus they’re developing at a blistering pace, so I’m keenly perked. :eyes:

I guess if I had to choose this very moment, I’d probably pick Baserow for everything consumer-facing, even though I definitely prefer the more robust producer-side of Fibery’s core workspace environment as a daily driver for [literally] whiteboarding sandbox stuff internally. But realistically, honestly, the overwhelming majority of my users don’t need access to Fibery itself. They just need a stripped-down hyper-focused mini-app to login, pay rent, submit requests, schedule tours, sign agreements, view invoices, track distributions, etc.

All that said… Does anyone have any ideas or advice for me? If you were in my shoes, what critical capability or key factor would anchor your decision absent committed roadmaps? Authenticated apps? Scalable pricing? Platform maturity? Something else? Which single tool or minimal stack should I go with? And what are the tradeoffs? :thinking::face_with_spiral_eyes:

I swear this isn’t a joke. I’m deadly serious about needing to make a monumental decision for my growing company asap. I’ve been kicking tires for years, dating countless apps (often concurrently :face_with_hand_over_mouth:), breaking up, then getting back together, then remembering why we broke up the first time, feeling stupid for falling again, learning more about my dumb self in the process, what I like, what I don’t like, what’s non-negotiable, then prioritizing my preferences, compromising where appropriate, and ultimately realizing there’s no perfect partner, so I might as well ask y’all who I should marry? :ring::joy:

Thanks so much!

1 Like

I think the issue is that Fibery is not currently aiming to provide a tool which serves companies for whom sharing information with “external clients, vendors, investors, students, members, patients, residents, visitors” is a critical use case.

Fibery does not work well as a ‘portal’ for external users. It is not currently designed for that, and I think this is the biggest source of misalignment in this discussion.
Fibery is targeted at companies where the majority of ‘consumers’ are internal employees and/or collaborators.

Obviously, this will mean that some companies will be dissatisfied if they look to Fibery to cover all their needs (‘all-in-one’) if those needs include ‘portals’.

Interestingly, before I even looked at your list of ‘contenders’ I thought it sounded like Airtable (maybe + Softr) would be a good fit, but it seems that their pricing is putting you off :person_shrugging:
It doesn’t make sense for Fibery to attempt to replicate Airtable functionality and then try to compete on price.

1 Like

Thanks Chris. Great answer. I totally get it. I realize Fibery isn’t targeting customers like myself today. I just wish y’all would target me tomorrow. :wink: Because I genuinely prefer your stock internal UI/UX and would love the ability to layer a custom external app-like interface on top of it. But admittedly, this would be a huge undertaking *with explosive growth potential, so I can respect Fibery’s decision to focus on existing customers and not get distracted by ambitious unicorn ideas. :unicorn:

All that said… Does anyone have any ideas or advice for me?

In your shoes, I would be asking myself whether a single-platform technology strategy will actually deliver more profitability and happier customers, or if I am better off choosing customer facing products based on CSAT/Retention rather than whether I can build it myself with UI lego.

A few hundred lines of middleware code to pull data back into Fibery every night might let you give an A+ impression to customers and investors, without really giving up anything in terms of internal tooling.

1 Like

The world becomes rapidly agent-centric and normal users quickly gain architect level capacities in organizations.

This means that that the surface UI needs to resemble a simple cockpit like app (ideally even working on your phone)

So the sentence “Fibery does not work well as a ‘portal’ for external users. It is not currently designed for that, and I think this is the biggest source of misalignment in this discussion.” …is in my view incorrect, and based on the outdated concepts of backend and frontend ui.

I think that fibery still keeps dropping the ball thinking that it should target tech nerds with its complex ui.

Startups are already using AI agents/agentic systems for building company workflows and if Fibery does not realize that (see my comment in fibery 2026 strategy topic) it wont make full advantage of the database driven environment that fibery already has which is ideal for agentic workflows.

2 Likes

I think you are conflating two topics here.

  • a tool/interface for external stakeholders (aka portal)
  • a tool/interface that supports the use of AI (by internal stakeholders)

I think it is perfectly possible for Fibery to be the latter without being the former

(of course, that isn’t to say Fibery will never be the former)

Rant on:
I agree it’s hard to pinpoint exactly what the “wish” is here, but the underlying “pain point” is the UI.

I believe the argument, and maybe I’m conflating with my own arguments here as well, is that Fibery is extremely powerful in its capabilities and a heaven for nerds like me/us who deeply enjoy using those capabilities to ease our and other’s lives. But as much as we control what happens in the back-end, especially with scripting and API, and we lack on the front-end, which is the first touching point of every actual potential user we’re trying to convince.

While Fibery is and was extremely strong in managing (store, generate, transform) data, it lacked in the department of showing it. And while things like multiple entity views, dashboards, improvements to whiteboards and more added A LOT, most of those were absolutely core and necessities to even begin with (e.g. multiple entity views are HUGE).

Still, the UI feels a bit “clunky”. If UI was great, we might not be having this discussion, but this probably makes us thinking: what if we would have a similar amount of control over the UI? What if we could create “Dashboards” within Entity views, what if we could format field names, group fields together, have control over how compact they are etc.
Fibery with an excellent UI.. wow. Add full table capabilities incl. in-cell formulas, pivoting, cell coloring.. (true GSheets integration?) and you easily have the best product in the segment by far.

Now, if it’s possible to allow the nerds you’re targeting to also customize UI, and the fact that I can install an external add-on (Fiberflow) in 20 seconds and fix some of the most basic UI problems with a few lines of CSS code makes me believe it is, it might be the most game-changing and unique feature ever. And what better way to get fulfil the impossible goal of (subjective and company & context dependent) “perfect” UI, than to allow tailoring?

Now here’s an idea: integrate the idea of Fiberflow (or Fiberflow itself) into Fibery. It could be a regular Space Template, “Fibery Plus”, “Fibery Tweak”, “Fibery Design” or “Fiberflow”… where a CSS Script entity holds a piece of CSS customization code, which somehow can be “injected” to the users via automation when enabled and reverted when disabled.
This way, people could customize, present and share individual tweaks like many already existing in Fiberflow, or even entire Layouts, in the form of space templates. Maybe there could be an integration which synchronizes verified tweaks and templates into the space?
With some additional templating-enabling databases you might be able to define font sizes (e.g. Space, indent level… in sidebar) in a regular entity field where the script reads the variable from? I don’t know, I’m brainstorming.

If this is dreamt too big: the UI still needs some urgent improvements. I feel like it should have been a significant part of the (recently released) strategy but it was barely mentioned.
At the end of the day, you got us nerds already in the pocket, and part of your strategy is for us to convince others of Fibery. Where I had most difficulty with that (basically my colleagues), was due to the UI, and basically having to convince that the other benefits outweigh the initial UI limitations, which only party is unfamiliarity.
Most people are used to Spreadsheets, where you show a lot of information in such a nicely formatted way in a single window, due to grouping, highlighting, and overall formatting possibilities.
Then they are asked to try Fibery, where first impression is this overall feeling of “clunkiness”, and unclarity.

  • Lack of “visual distinction” of information pieces belonging together → I call it visual clarity:

    • Lack of control over semantic grouping of fields (e.g. Address, Personal data etc. fields..)
    • Lack of (control over) distinction between expected input fields and informational fields (could be view-dependent)
    • Poor “label-to-content” contrast
      • Tabs of Entity views
      • Tabs of pinned Relation Views
      • Field names:
        • To-many Relation view can show lots of information, especially with multiple views within, but it takes too much conscious effort to scan and understand where to click. Relation name and views within are too blended background.
        • Using to-many relation field with views within is a necessary work-around for many workflows, which I might want to describe in form of a title, but I can only use relation name.
        • Rich text field headers are barely visible, this becomes especially obvious between two RT fields.
    • inefficient use of space overall
      • incl. extensive padding
      • worsened by the problems above
    • Visual clarity in sidebar

Also pretty basic things like

  • no header wrap & no wrap for relations
  • no dynamic row sizing

That being said I love Fibery and have followed Fibery’s development for over 4 years now (dopamine hit each Thursday :heart_eyes:), and I am confident you guys will continue to improve Fibery and I will continue to get that dopamine hit each Thursday (i.e. build on and use Fibery):grin:
/rant

1 Like

Thanks @Eren_Turgut.

There’s a lot there, and it’s really good feedback :person_bowing:

I can try and address some of these observations, and maybe place my responses in context of how we decide what to focus on (as evidenced by our strategy 2026 document).

Yes. Fibery’s UI is not best-in-class, but we are trying to make continual improvements.

Our strategy (as you have seen) is to focus on “people who need power, embrace complexity, get abstractions and share our culture”.
Fibery is inherently complex. This makes it even more of a challenge to come up with a UI that works for everyone. But we won’t give up.

:100:

Something like this will almost certainly happen at some point. The only question is when - and this is decided by balancing it against the other opportunities we have to add value.
For example, would our users (and potential users) appreciate this more (or less) than validation rules? At the moment, we think the latter will resonate with our target, so we’re working on that.

But we do prioritise based on feedback, so the mere act of you mentioning the idea of dashboard as an entity view will serve to increase its score (and thus likelihood of being developed).

Probably less likely. The behaviours of spreadsheets are fundamentally different to those of databases. Something like in-cell formulas would imply that each cell represents a unique calculation (record) and thus it would grow the data management complexity by an order of magnitude.

Cell coloring? Maybe, since this could potentially be a front-end implementation.

It’s an idea we have considered (vote on it here :wink: ) but potentially this is an example of something we might not prioritise because it’s actually too ‘nerdy’ for some people :person_shrugging:

As it happens, the Fiberflow extension (thanks @derbenoo ) was a great opportunity for people to experiment, and thus gave some insight into what people would value. But as far as I know, the extension did not achieve massive adoption, so this is perhaps a sign that it’s not something for us to replicate (yet).

(or it could be a sign that people didn’t know about it, or chose not to use it because it only works at a per-user level rather than per-workspace).

These are all valid opinions/suggestions, and you’re welcome to elaborate on them here in the community :folded_hands: (and/or ping us in intercom to tell us when they/others are complete PITA dealbreaker issues for you!)

As I said in an earlier post, having a load of constructive criticism in a single generic topic like this is great for aggregation purposes, but is hard for us internally to process in prioritisation terms.

Currently there are 8 votes for this topic. If it suddenly jumped to 25 votes, we would never know if those people were voting for CSS tweaks, cell coloring, header wrapping, etc. but we will of course log these requests.

:heart_hands:

I don’t understand what you mean here. The behaviors are fundamentally different, but spreadsheets are in general quite lightweight (unless there are tons of interdependent references, etc). Are you using “record” here to mean “entity” or just “value”? Why does data management grow in complexity by an “order of magnitude”? Perhaps you’re thinking the spreadsheet functionality has to somehow integrate with databases and entities? (IMHO it absolutely does not for it to still provide large value to me)