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

**URL:** <https://community.fibery.io/t/done-new-apps-creation-flow-new-getting-started-flow-new-terms/2148>\
**Category:** Ideas & Features\
**Created:** [October 26, 2021, 7:00am UTC](https://community.fibery.io/t/done-new-apps-creation-flow-new-getting-started-flow-new-terms/2148 "2021-10-26T07:00:06Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![rothnic](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/rothnic/32/1850_2.png) [@rothnic](https://community.fibery.io/u/rothnic)\
**Post date:** [October 26, 2021, 8:15pm UTC](https://community.fibery.io/t/done-new-apps-creation-flow-new-getting-started-flow-new-terms/2148/11 "2021-10-26T20:15:26Z")

</div>

> [@Oshyan](#):
>
> If you do not already use the term “Database” somewhere in Fibery, you’re doing it wrong.

I agree it is a pretty good term and I’d be good with that. It is widely understood as a concept, isn’t abstract, makes sense to both define what can be stored, and also stores the data.

The more I think about Table in relation to some of Fibery’s features, I think alternative terms might be a little more ideal. Database, Collection, Datastore, Datasource, and Store all could convey things. I think Table could still work, but the place where it might be a little awkward is thinking about what you are doing when you create a view that shows multiple Types. Would it make sense to select multiple Tables, Databases, Collections, etc to present in a View?

- Add a **Database** for Tasks
- Connect the _Tasks_ **Database** to the Projects **Database**
- Connect the Tasks **Database** to the Users **Database** to handle Task Assignment
- Add the Tasks and User Story **Databases** to the Product Team’s Calendar View
- (sounds better like this) Connect the Product Team’s Calendar View to the Task and User Story **Databases**
- (Or) Show open items in the Product Team’s Calendar from the Task and User Story Databases

That last example is what makes me lean a little from Database, but I still think it would work overall. The term Collection is a little long but could work as well, but maybe isn’t as explanatory.

The Model and Schema terms are good concepts as well, but think they still suffer from being technical, abstract, and would feel odd to actually store the data. However, that is because I know what they are.

> [@mdubakov](#):
>
> How about **Data Table**?

That could work as well, but still prefer a single word if possible. Just for the ability to show a simple diagram, similar to the clickup one linked above. Database is kind of long, but it could be shortened in places to just DB while still communicating what it is to most people. Totally just a few opinionated opinions 😉 , but I think there is a good starting point to doing a ranked order user test on a representative target audience if you haven’t already.

My checklist for the term would be:

- Understood by non-technical knowledge workers?
- Consistent with the new UX? (configuration and storage)
- Intuitive in context of other Fibery features? (views, smart folders, searching, etc)
- (less important) Is relatively short or can be shortened and still understood?

---

_[View the full topic](https://community.fibery.io/t/done-new-apps-creation-flow-new-getting-started-flow-new-terms/2148)._