No doubt there are many different perceptions of this. From a layman’s perspective “Database” still seems like enough of a technical term to be confusing in my opinion. I’m guessing that the majority of potential users are coming from spreadsheets and familiar with each “sheet” as a table. Given that paradigm, it’s not a huge conceptual leap to look at easy Type as a Table. And from a technical perspective, “Database”, to me, implies a collection of tables related to one another. So calling a single entity / type a “database” would be very confusing. But that’s just my opinion.
1 Like
Yeah, without doing a poll of people who did not adopt Fibery because they were confused, we are somewhat shooting in the dark. 
I’m curious, though, if you think these spreadsheet users actually are familiar with the term “Table”. Anyone who uses “pivot tables”, maybe. But I think most know, as you said, these terms: spreadsheet, and sheet (for multiple sheets). In my years in IT I almost never heard anyone refer to a “table” in a spreadsheet up, much more often in a table in a presentation (Powerpoint) or document (Word). 
Good point, perhaps “Sheet” view might be a better term for a table view
Chiming in on the new name discussion here. I really dislike the idea of “Table” or “Data Table” for the new name of Type because a table is a display concept to most people. That will easily get confused with the idea of a table view for people, so I think it would introduce more challenges than it solves. I also agree with people above saying that “Database” is too technical, while being somewhat of an inaccurate use of the word.
Reading the original release, I liked the term “Data Type” because it’s accurate and to me doesn’t sound too technical. I also like @Haslien’s idea of “Model”, which is both understandable to regular users and accurate use of the word. This could be made more specific with “Data Model”. Some other thoughts to throw out there:
Template (or Data Template)
Shape
Entity Type
Object
2 Likes
I would agree that “Table” is not a very good name for a Type.
It is too commonly used as both a View and a (spread) sheet.
1 Like
I have thought from the early days of Fibery that the term “App” was difficult, and that what an App represented was more like an “Area.” I think Extensions have more of an App-like functionality, very similar to the “ClickApps” of ClickUp which, when installed, perform some function to enhance ClickUp, just like with Fibery when you install say “Workflow” extension. Incidentally there hasn’t been much development around extensions and I this is a great place for a lot of important features, really hoping we’ll see more extensions coming along soon.
Would love to see things also discussed around here like:
- Description areas for both Apps & Types
- Ability to reference Apps & Types
- Ability to click on an App/“Space” and see at a glance all the entities within the App by default
Thanks guys!
1 Like
I think there will be something to address this sooner rather than later 
Michael’s first post is an indicator of what is coming.
I also don’t like “Table” as for me as well feels simply as a view, not a type of data. I think most people when they think at table they think of html like tables, or excel spreadsheets or something, more related to how you see some data not the type or structure of data.
I think it is important to point out that this isn’t just renaming Type. The new UX at least appears to be both a database and a definition of what can be stored within it. So, “Type” (and Schema, Data Type, Model, etc) is not only a technical concept, but also isn’t consistent with the new UX.
I’d agree if you changed the word “display” to “visual”, which I think is the point of it. It is a visual thing they can think about existing somewhere. Imagine you are the Fibery PM with goals around user activation and retention. Given a target audience of knowledge workers familiar with competitor tools, what do you think would maximize your chance at success? Trying to re-educate on an established concept, or instantly having understanding of the core concepts and focusing on differentiation? To me, the value in fibery is what it does that you can’t do (at least affordably) with Notion/Coda/Airtable.
Another way to look at it is when considering specifically the new UX. What do you think most people would prefer when polling people not familiar with Fibery, but are knowledge workers?
It is because of the new UX that Type, Data Type, Schema, Object, Model, etc are not only going to be confusing, technical terms for people that don’t care about technical correctness, but also could introduce inconsistent language for people that do. Do you import data into a Table/Database, or into a Data Type?
1 Like
We’ve selected Database as a term to replace Type.
- It’s much less abstract than Type and most people know that it stores some data somehow
- It does not conflict with Table.
- Notion has it. If you are familiar with Notion it will click right away.
- It seems we can live with the fact that there is only one datatype in our database… at least this is less wrong than Table.
I want to thank you all for the very insightful arguments here. It helped us a lot!
7 Likes
I think that will work great for Fibery, especially in how the new UX has a single specific place where you can see the data associated with a space that still feels a little under the hood. I’m really looking forward to it.
Will the renaming cause breaking changes for the API?
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
5 Likes
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. 
5 Likes
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