Almost Done! 
6 Likes
Very nice - very clear! 
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.
Edit:
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 
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?
Edit:
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,
OR,
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 
:
- 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.
4 Likes
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
I’m not sure I’m with you on this. I’m a backend dev for 10+ years and even for me “type” didn’t make sense, sounds way to abstract. TBH, it’s also good to have a bit similar naming with other players in the market, especially when you’re competing with very big ones (like Notion), since most of the time popular ones are tried first. When they look for better alternatives, the term familiarity is transferred and helps a lot the user to get on-boarded and understand the whole thing. That’s one of the biggest benefit of having similar naming/terms with the big guys.
2 Likes
You did a good job of articulating why you like the term Type, but you did not seem to particularly address why “Database” is so much worse. You just said that it is, but why do you think so? Because it is technically “incorrect”? If so I would submit that this matters very little, as long as the target market understands the intended meaning in this context.
Someone who is a DB manager/architect/etc. or has some old school database app experience might bristle a bit at the “improper” use, but they will still likely understand it. They are unlikely to be confused about what is meant here. Meanwhile the 20+ million people who are used to the “database” term as now used and popularized by Notion and others will totally, 100%, and absolutely understand. And that, I think, is pretty valuable to Fibery, and is currently missing.
Implemented already
1 Like