[DONE] 🎬 New Apps Creation flow, new getting started flow, new terms

Nope for sure

1 Like

I like the naming Database and fits well with Fibery. Looking on my own workspace, everything I have fits with Database… database of companies, database of users, database of tasks, etc

1 Like

Some progress with faster relation creation

2021-10-29 20.56.32


I just have to say it’s this two-way communication and seeing real impact on the direction of Fibery that results from it which really makes me love this team and Fibery itself. My top features aren’t always prioritized, I don’t always like the way something is implemented, but I do feel like all of our opinions are listened to here, and they can’t all be “right” anyway. :grin:


4 posts were split to a new topic: Q: What are your top 3 missing things/features in Fibery?

A post was merged into an existing topic: Q: What are your top 3 missing things/features in Fibery?

To be honest I think this is a less urgent issue than making the rest of the system more usable.

It is important to simplify the onboarding on Type/relation so the Fibery conversion ratio will get better, but it make sense only once the system is more usable in practice, so having: blocks in entities views, search, edit in table, edit in collection (when name is a formula it is unpractical right now), avoid input duplicates, polymorphic relationships.

I understand the pressure to have more users. But if the current users who are tech/data savvy people struggle to use Fibery to really replace task management, CRM, knowledge wiki, etc. I’m pretty sure less advanced users will have hard time to adopt Fibery.

1 Like

In fact this is almost implemented and we are not going to spend too much time on that.

1 Like

Almost Done! :crossed_fingers:


Very nice - very clear! :sparkling_heart:

This is looking much more clear and straightforward! I am hopeful this will increase adoption/retention. Great work!

1 Like

Looks great. The one thing I noticed that confused me a bit was the primary CTA at the top right from the table, right next to the “new field” button. For some reason it kind of feels a little outside or separate from the table. I think the initial naming of the database to “New Database” highlighted it though ("+ New New Database"), so I could just need some time to unsee that.

It also might help to somehow support calling it the “Task” database, but then use the plural form in the interface. Since the heading is a singular “Task”, then a CTA of “+ New Task”, it seems to add a little uncertainty of what is going on.

But yeah, overall it is looking much more approachable.


Here is a visual of what I’m talking about


1 Like

These are all good points. New XXX button can be helpful if the table is long, but we will see whether it is helpful. Maybe we will remove it. “New New Database” is a nice catch :slight_smile:

Also it is interesting observation about Database name vs Database Table. We did not think it will be perceived this way, but it seems it is. We will think how to fix that. Thanks!

Oh, I do think that is worth having in some way or another. I think just making the name plural would help a lot in avoiding confusion. Maybe that could cause name conflicts, but it seems like a pretty common practice in headless CMSs I’ve played around with.

Another option would be to just remove the table heading there completely, instead of making it plural. You already have a heading for it accounted for in the tab right?


Not sure about how it looks overall without, but this feels a little less complicated.

I agree with @rothnic , the New New looks confusing. I’m wondering if the “New x” button will be used at all, it might confuse new users and also might give the impression that’s the main view to work on, not a “configuration” view. I think most users will use this new view for 2 reasons: configure their space and have an overview of the data, i don’t think it will be used to create new items …

1 Like

I have worked through Michael’s video and translated some of the new object names from the video narration in order to clarify the abstraction for myself.

This post adds a possible perspective from a semi-technical fibery user that has some exposure/knowledge of traditional relational database concepts.

The terms in bold below are standard terms used in relational database design.

  • The video is about a Project Management process. Information related to this company process is grouped in a collection called a space in fibery.
  • A space in fibery can also be called a database containing all the information related to a specific company process.
  • The project management database (called a space in fibery) in the video contains two tables (called databases in fibery); a project table and a task table. A table is a two dimensional object storing data, organized in rows and columns. Each row represents a unique record and each column represents a field in the record.
  • In the video two tables (called a databases in fibery) stores records of a specific things, projects and tasks.
  • In the case of the project table (database) in the video each row represents a different project and each field of a row defines information of the specific project.
  • In the case of the task table (database) in the video, each row represents a different task and each field of a row defines information of the specific task.
  • It is possible to define relations between the tables (called databases in fibery) in a database (called space in fibery). The relations can be one-to-one, one-to-many and many-to-many.
    *In the video a project in the project table (database) may have many tasks stored in the task table (database) so a one-to-many relation exists between the tables (databases).
  • The automations in fibery can be viewed as a type of stored procedure that can be stored for later used to be executed manually using a button or by a defined trigger.
  • Views are used to combine and visualize data from different tables (databases). The view does not store the data, it just maps and displays it using a number of different objects (table, board, list, timeline, calendar, document, report etc.)
  • Records in tables (databases) are uniquely identified by the Public Id. This field is effectively the primary key in the table (database).
  • Fibery is not as flexible as in relational database design where primary and foreign keys can be defined. I am sure it is possible to work around this limitation by using JavaScript to “extract” the primary key (Public Id) of a record in a table and use it as a foreign key in another table,
    it could be very simple if the Public Id field is included as an option of a Lookup Field. I am still thinking what benefit this would have as it is not possible to run queries in fibery as is possible in relational databases.

My feeling is these standard relational database terms fits into fibery and could work well for non-technical users and technical users with relational database knowledge.

Couple of thoughts/comments/observations…

I think Fibery needs to appeal to non-technical users who have no relational database knowledge.

Why should a user want to define (or extract) a primary key or a foreign key?
A user wants to know which tasks belong to which project(s). Does he/she care about primary/foreign keys?

Fibery does not support queries in the traditional sense, but in many cases I consider views (when properly configured) to yield the records that would result from execution of a query.

1 Like

@Chr1sG , comments on your comments :wink: :

  • I have been experimenting with fibery for the last two years modeling an integrated service orientated company process workflow and I am super excited about what I see compared to using TargetProcess to manage agile software development 13 years ago.
  • I agree about the requirement to appeal to non-technical users. Fortunately these users have no knowledge of relational databases, thus they will not be “confused” by “technical terms”. To them it is just new terms. The sweet spot is to find terms for the abstractions that is clear and intuitive.
  • Fibery is very powerful and flexible, that implies complexity and being an increasingly “technical” application.
  • Abstraction is complicated, this is confirmed by the need to change/improve fibery as detailed in the extensive discussions on this subject. I believe this evolution process has to and will continue to keep fibery ahead of the other solutions out there.
  • The reality might be, to create a company workspace that fulfils all the requirements, will be complex, therefore I believe the fibery partner approach is what is required to get there for those “complex” customer requirements.
  • I agree with all the comments that the proposed changes improves clarity and useability. I believe it is because it is closer to what fibery actually is as indicated in my “translation” of terms. My post on this is not critique but excitement.
  • I believe that behind the scenes, fibery is a massive relational database that has an amazing user configurable user interface overlay enabling things that are very difficult to achieve in a formal relational database environment. This fits in with the general move to no-code applications.

I trust that my philosophical discourse is not overbearing. I find resonance in similar posts from the visionary @mdubakov.


I may be a little late to the party here, but — for whatever (if anything) it might be worth — I feel compelled to offer a thought here. Specifically, I urge Fibery to reconsider its abandonment of the “Type” nomenclature/concept and instead do the thing which in my view fixes any of that term’s shortcomings: more specifically, to simply pair and precede it with another word — “Entity” — thus renaming “Type” to the only term which as I see it is proper here. In other words, “Type” can and should be renamed exactly as just described — “Entity Type.”

The term works because that’s exactly what a Type is: a Type is a type of entity — it is an Entity Type. A type is not a database. That form of terminology is one of the things that I accepted when using Notion for a great many months and which I couldn’t see was wrong — until Fibery introduced me to the “Type” concept. No, “Type” has never been a perfect term, but it is way better than database, and — when changed to “Entity Type” — is made into as close to perfect of a term as can possibly exist. When I first started with Fibery, I couldn’t grasp the “type” concept, and then after a few days it clicked. “Type” is a beautiful thing that Fibery invented, and which changed and improved my conceptualization of connected information, and I respectfully suggest and urge the adoption of “Entity Type” as the new name rather than the much less apt term “Database.”

At any rate, I thank you (Michael) and everyone at and who uses Fibery for this beautiful and life-changing invention, and (I hope) for your time and consideration of this suggestion.

I think a lot of what you said makes sense. Type is a really good name for what a Type is in Fibery at the moment. Entity Type is a little more explanatory of the current UX, but the key issue here is that it doesn’t fit the new UX.

A key point to product development is constructing a language that effortlessly describes the UX to as many people as possible. If you look at the new UX, it appears to be storing data. It comes down to, if you were to show the new UX to the target market unfamiliar with Fibery, what language would best communicate what is happening?

So, it isn’t that the current language doesn’t communicate well the current UX and hasn’t converted some customers. It just is believed that by reducing the friction in the language and UX, there would be less “grasping” (aka friction) that needs to occur, which would drive a higher conversion/retention rate.

1 Like