I’ve started introducing Fibery to some of my key teammates, preparing to pitch it as a replacement for our current Asana-and-Google-Workspace based system that we use to coordinate and manage all of our our department activities (designing, building and updating websites and brochures, SEO work, and running weekly client meetings). We have about 20 people in our department, and successful adoption of Fibery here would mean the possibility of extending it to the rest of the company (~200 people and growing).
There is a wide range of “tech savvy-ness” among our team members– and even more so in the rest of the company. The biggest adoption hurdle will be the the learning curve, not just of Fibery itself, but for the Workspace I’m building to replace our current system. How successfully I can make the system “self explanatory”, “discoverable”, and “hand holding” for new users may determine the success of this effort.
There are a few wished-for features that would be very helpful here:
Allow every field in every DB to be have a short Description, which would appear as a popup hint when the field is hovered in any view. (Maybe it could be toggled on/off per user)
Allow the same hint capability for every Space, and every DB.
Allow “unassociated” Buttons to be created in Spaces/DBs – i.e. buttons not associated with a specific entity/DB. It’s counter-intuitive that in order to find the button for “create a new Client”, you have to first open an existing Client! Also allow Buttons to be linked in a Rich Text, so a document can be created with instructions and buttons (and other links) to, e.g. walk you through a process like creating a new Client.
Improvements to script writing and debugging: Scripting will play a big role in my system, and Fibery has the most frustrating, time-consuming scripting workflow I’ve ever used . Some minor changes (previously requested) would really help ease this pain – e.g. allow updating a script without closing the script editing popup. Improving script execution speed would also help, because how long do I wait before deciding a Rule didn’t work? Too long.
Ability to selectively hide fields in entity views. This would reduce cognitive overload for newbies who don’t know where to focus. If this could be done dynamically on a per-entity basis, even better because it could emulate…
Polymorphic types! LOL j/k But seriously, it would be super helpful.
UI polishing. Every UI bug, oddity and inconsistency is another bump in a newbie’s road.
These things could really ease the learning process. FIbery’s adoption in our department may be a hard sell due mostly to the steep learning curve, so every feature that helps here will make a big difference.
Wish me luck!
Allll of this is so blindingly obvious, I don’t know why it hasn’t gotten more attention before. Great stuff!
This is basically this existing feature request, right?
Overall I support most of what you’re requesting though. Perhaps you could (or already did?) prioritize the requests in order of how important and impactful to likely adoption you think they might be?
All these requests make total sense. We have plans to dedicate a team that will focus on getting started improvements, and specifically on “Help Builders explain solutions to the Team”. So the first two cases are in our scope for the relatively near future.
Fields hiding will be added really soon, I speak weeks, right after Pinned Fields completion.
Polymorphic types! LOL j/k But seriously, it would be super helpful.
What do you mean by Polymorphic types?
I’ve linked your feedback to related features and product areas
I use a regular Button; there is no problem. But in the Button Action I do not reference the “current Entity” at all, because I am only creating a new entity. So, the Button does not need the context of any specific entity - It would make more sense for the Button to have the context of the DB or the Space.
I refer to Type inheritance, so I could have a Type hierarchy like:
– Project
---- Web dev Project
---- SEO Project
---- Brochure Project
The need for this is that there are many fields common to all Projects, but there are also some fields specific only to each particular type of Project. Right now the only ways to model this in FIbery are unsatisfactory – See: How to best model Hierarchical Types?
What are the advantages of using such a button vs. creating a new Client from a View/Search?
For some people it is not obvious that you would use “Search” to create a new entity, so instead we go looking for that entity’s DB, and expect to find the functions/Buttons there for creating new entities, etc.
Additionally, it would be quite useful to be able to create a document to summarize and collect all info, links and functions for a particular DB/topic, e.g. “Creating new Clients/Projects” - so someone can go here to learn about this part of the Workspace, and even have the buttons right there in the document to do what is described.
Out of interest, when a user goes looking for an entity’s DB, where do you expect him/her to end up?
Doesn’t this depend upon which views you have created?
Wow, I have a lot of the same items on my Fibery quality-of-life wish list.
Airtable handles this pretty well:
The way @Matt_Blais is using it, its pretty much just a button that shows a form-like modal/popup to streamline new entity creation. So instead of using a Table view or viewing the entity (with all its irrelevant fields) there is a button that shows a modal with only specific fields that need to be entered for the creation of a new entity.
I have the feeling that a lot of people that want to have a “Form view” could be satisfied by having a button automation that shows a modal/popup with specific fields to create a new entity. Bonus points if the future feature of field descriptions in Table view are shown in the modal.
Notice how I am using the Button automation in the same way as him. You guys already implemented 80% of a “Form view” and just need to add basics like: field description, ability to reorder fields, etc.
Yes, it does depend, unless you’re going straight to a “Space” overview from the Left Menu.
But I do think it would be helpful if every View of –e.g. the “Project” DB– could have the same (user defined) Buttons available, for things like “Create a new Project”, or whatever other useful actions have been create for Projects.
In Table Views there is already an “Actions” menu/button, though it only appears when rows have been selected; This would be a good place to show un-associated Buttons for the DB (if it was always visible).
I’m interested to hear what the other use cases for ‘unassociated buttons’ are apart from ‘Create new entity’, especially since every view of a database does have the +New button (except Timeline where you create by dragging a time range)
I essentially want to replace that ubiquitous “+New” button with my own form.
This is also related to forms and validation, because ideally we want to be able to e.g. require that a newly created Project entity is linked to a Client entity, has a name, etc.
Backing lacking that, I decided the next best thing was to have a Button that makes it clear to the user which fields they should supply (since there are so many “noisy” fields that we can’t yet hide).
. Some minor changes (previously requested) would really help ease this pain – e.g. allow updating a script without closing the script editing popup. Improving script execution speed would also help, because how long do I wait before deciding a Rule didn’t work? Too long.
But seriously, it would be super helpful.
Great stuff!
