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

[mdubakov]

We’ve discovered that ~60% of new accounts spend less that 10 minutes in Fibery and never return.

Problems

• Type concept is hard to grasp. It is very abstract.
• People don’t understand the difference between View and Type
• App is a misleading term.
• App creation is a hard process that demands high level of abstraction thinking.

Now we are focusing on new getting started experience that will make Fibery easier to grasp. The main ideas:

App settings area with Types will be replaced with Tables as shown below

This is a move to a more concrete solution (similar to other vendors) where you operate with data directly.

Schema most likely will be put into a separate button and look like this:

Automations will be a separate popup as well (for a Type level so far, but later we’ll move them to an App level)

Left menu

• Click on App Name will navigate to settings, click on > icon will expand / collapse app
• Type will be a first-class citizen and will be visible in left menu (however, it can be hidden at later stages by an admin)

New Terms

We’ll rename App and Type terms.

So far the best candidates are:

App → Space
Type → Data Type

[Jean]

Agreed. This looks more natural. I remember when I started diving into Fibery it was all very confusing even though I’m a dev. I stayed because I eventually figured out how everything works and was excited by the potential it has.

“App” might not be the best naming as for me means something very dynamic and complex so I’m with you on changing the terms for both app and types. I remember i was confused by this term.

I know from our own app, to keep the user coming back you have to give quick wins as much as possible early on until they get hooked. Onboarding wizards have a huge role on this. Not sure if you use any type of wizards on Fibery, but for configuring “spaces” for new users might be a good idea, letting them step by step configuring their space and data types. If you throw them lots of terms and a complex setup, for sure they will get confused and leave.

BTW, the relations screen looks amazing and intuitive.

[rothnic]

Naming

I agree with the renaming, but think the biggest benefit will come from the UX. There is also something to be said for aligning the core concepts with competitors for ease in onboarding. I’ve gone through the renaming of concepts before in our product and it can be a bit painful to get to a clear answer.

Going from App to Space makes sense. I am not a huge fan of going from Type to Data Type though. I think in general I favor single words for key concepts like this so that it doesn’t make it more complicated. While Data Type explains it a bit more, it still sounds technical. Given the current UX approach you are sharing, I wouldn’t discount just renaming Type to Table. It doesn’t feel technically correct as a person with software experience, but suspect it might have the broadest understanding. Which one do you think would communicate what is happening to more people?

• Can you add a Task Data Type to the Project Management Space?
• Can you add a Table for Tasks in the Project Management Space?

More Options:

• Collection (need to rename how collection is currently used though)
• Dataset

Table UX

While I think the table UX to configure Types is a really good approach for the primary UX, I would still consider something like the current UX helpful for more advanced management. With the table UX, it is super intuitive for adding columns and for understanding the type of data in the columns, but it isn’t great if you are trying to maintain it. I don’t think you’d need to keep the full UX of what currently exists, but mainly would just hope it would be easy to see all the fields/field types that are on a Type in a succinct list.

Often times I find myself having to switch between the current Type editor and a view to verify things were as I was expecting, so I think this will be a big improvement for quickly building out Types.

[Chr1sG]

Interesting insights.

With respect to this:

@rothnic

I wouldn’t discount just renaming Type to Table…
Which one do you think would communicate what is happening to more people?

• Can you add a Task Data Type to the Project Management Space ?
• Can you add a Table for Tasks in the Project Management Space ?

We have had similar discussions internally, but I think there is a concern that Table can be interpreted as a view, rather than a type of data (especially since we have Table Views!)

So when you ask, ‘Can you add a table for tasks?’ I see that as a question similar to ‘Can you add a kanban for tasks?’ (both of which pre-suppose that ‘Task’ as a type of entity is already present).

How would you feel if the questions were posed like this?

• Can you define a Task Data Type in the Project Management Space ?
• Can you create a Table of Tasks in the Project Management Space ?

Too techy maybe?

[mdubakov]

Terms are hard

Here is the relevant research I’ve made

Terminology and App creation flows in ClickUp, Notion, Airtable and Coda

This is a review of several major competitors in terms of conceptual structure (Apps, Types, Views, Pages). The problem with the new waves of no-code collaborative tools is lack of consistent terminology. Fibery Term ClickUp Airtable Notion Coda App → Space Space Base Page Document Type → Database List Table Database Table Document → Page Document - Page Page View View View View View Field Field Field Property Column Relation Relationship Link Relation Lookup View is a com…

@rothnic

While I think the table UX to configure Types is a really good approach for the primary UX, I would still consider something like the current UX helpful for more advanced management.

Yes, we are considering to keep it for power users.

[rothnic]

Naming

tldr; I think the name is better suited as a concrete concept, rather than an abstract one

I don’t know if the rewording really addresses what I think the issue is, which is that both Type and Data Type are abstract concepts. As someone that loves thinking abstractly, I have surprisingly found that many knowledge workers I’ve worked with (SEO sme, Marketing Lead, etc) aren’t super comfortable with abstraction. I know there are many that are comfortable with it, but it has been less common than I’d expect at least in my experience.

If you are trying to make more people comfortable creating Types, the new UX will surely help, but I’m just not sold that the Type → Data Type renaming would directly help broaden the appeal on its own. I think the reason Notion uses Database and others use Table/List is that these are universally understood, concrete concepts. There is no translation that has to occur. For example, if you try to describe them simply, you could say:

• Database: stores structured data
• Table: stores data in rows and columns
• Type/Data Type: defines what data can be stored (not typically a concept that stores data)

Since the proposed UX defines what data can be stored but also feels like it stores the data (i realize it is just an unfiltered view), it makes me think Data Type and Type would not only still be technically confusing, but also wouldn’t describe the UX very well. So, my order of preference focused on simplicity and describing what it does would be Table, Collection, Database, Dataset, Type, Data Type. To @Chr1sG’s point, Collection or Database speak less to a specific layout.

UX

@Chr1sG

but I think there is a concern that Table can be interpreted as a view, rather than a type of data

I do think it would take some care to differentiate it from the current Table view. This is something I was curious about in the proposed UX. I can imagine someone seeing that UX, that they will likely want to sort, search, filter that interface. So, having some CTA to “Create new View” might be useful in there somewhere. That would create a new “Table View” in your Space. Then, you could configure the “View Layout”, rather than having to know which View type you want up-front.

[Haslien]

The renaming of App makes sense. In the beginning I thought it was some sort of integrations or some pre-made thing I used in the tool. I like Space, it sounds right to me.

I liked Type, and Data Type I’m neutral on. Another word could be ‘Model’.

• Can you add a Task Model to the Project Management Space ?
• Can you create a Model for Tasks in the Project Management Space ?

“Template” could also work, but used by the App Space templates. “Schema” too, but might feel technical.

[a2say]

@mdubakov

App → Space
Type → Data Type

Looked through all the main competitors (and use them all). I agree that in this case it is difficult to come up with a better name.

It seems to me that at the very first use, you just need to “reveal” the essence of the “data type” concept.

A very simple gif visualization:
«Project, task, contact, deal are all different data types. They differ in that each has its own set of fields. Not enough standard types ones? Create your own.»

ClickUp, by the way, even posted a link on description of its hierarchy in the main menu.

[mdubakov]

@rothnic

Since the proposed UX defines what data can be stored but also feels like it stores the data (i realize it is just an unfiltered view), it makes me think Data Type and Type would not only still be technically confusing, but also wouldn’t describe the UX very well.

How about Data Table?

[Oshyan]

This overhaul is looking great so far! I’m glad the overall UI/UX is getting some major attention. I want very much for Fibery to succeed and these changes will be necessary for that, I think. I know the team has always been aware of such challenges, but unsure how to solve them, so it’s good to see another experiment aimed in that direction. I hope it succeeds!

If you do not already use the term “Database” somewhere in Fibery, you’re doing it wrong. That is an incredibly familiar concept-term to even non-tech users, and it should be made use of. To me it actually seems like a good fit for a Type, although I fully realize it is not technically correct.

• “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”

That said few others here seem to agree, so maybe it’s not so obvious. Or… maybe most of us are techie people and know it’s not “correct”, and so wish to avoid that term.

What’s important is the people you need to appeal to and have them better understand are probably nobody in this topic, because we’ve all “got” Fibery already, even if at one time we would have benefitted from different terminology ourselves. It’s truly hard to project back and imagine what we would ourselves have better understood if the wording were different, but we’re all trying our best.

All that said, I also kind of like the word “Model”, although it has a different sort of techie vibe to me. And it also, to me, does not seem like something that holds data, but rather describes data or the interactions of things.

[rothnic]

@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?

[Chr1sG]

Dataset?
Category?

[a2say]

Digging in the wrong place: 0)

1. “Applications” and “Type” were really not very good names. So I agree with the proposed changes (space and data type).

2. UX changes are also important. People are used to working with Notion, so when they see a familiar interface, they will automatically understand how to work with it: tables, relationships between them, etc. The cognitive load at the first meeting will decrease.

But the rest of the “games” with names, in my opinion, will give nothing. The main problem is how to convey the meaning of these names. There is a problem of “conveying meaning and value”: information on the site itself during the first visit, initial onboarding, etc.

And I am a perfect example of this problem. I have been working with such tools since 2002. I don’t need to explain abstractions, databases and their design. I have long been accustomed to the fact that in different programs the same entities are called different terms.

But! From the moment I learned about Fibery and until the moment I started working with it, it took 4 months. Although, as a tool, 4 months ago I really needed it.

I went to the site, read and bookmarked it, forgot. Then I went back in, registered and “played” for about 10 minutes, forgot. Because I did not see the most interesting functions for me. And quite by accident I started working with Fibery again and seriously figured out what kind of tool it was.

Because information is poorly transmitted at the first contact with the product. “Help Center” when using the program for the first time - no one reads: 0) According to Ilya Krasinsky, the strongest specialist in unit economics and product analytics in Russia, designing the first user session and “activation” is a critical element for the product.

Using “familiar user interface and terms” (similar to Notion, ClickUp, etc.), but without specifying the value of the product, can even be detrimental. The user did not find the missing features, which is not available in Notion and ClickUp. But he managed to compare prices. Gone. Didn’t understand the value.

Therefore, I vote for cool gifs

[Chr1sG]

@a2say

Because I did not see the most interesting functions for me.

What were they?

[a2say]

@Chr1sG

What were they?

Most of all the “Document” is misleading. Many are already accustomed to the fact that in Notion, Clickup you see backlinks in it, you can build a hierarchy from documents, this hierarchy of documents can be shared. And this is one of the most commonly used functions.

In Fibery, you can do this too. Just create a new type, name it “Page” for example. Set up recursion. And all these functions will become available. But in 10-30 minutes at the first acquaintance with the service, you will not know about it.

There is no way to see all existing Documents / Whiteboards in Workspace or App. This is also solvable. But again, it takes time to find options.

The article “Augmenting Organizational Intelligence” became the principal one for making a decision for me. And a roadmap that showed movement in this direction.

The roadmap, however, also needs to be found: 0) What% of new users come to the community site?

[a2say]

There is also such a thought.

All services write about their advantages, but few people write about the existing restrictions.

I started to make such a list of restrictions in Fibery for myself. With notes: they plan to add this, this is not yet in the plans, there is a workaround here. To give this list to my clients later.

People don’t have free hours right now to figure out the new SaaS-service. But there is an “internal” checklist of features that they expect to see. If they do not find some function quickly, then they leave.

For this, I am preparing a own list: what is not now. Yes, not yet. But there are options.

[mdubakov]

The only problem I have with Database term is that in real life it represents MANY tables, but in Notion (and In Fibery if we will use this term), it will represent only ONE table.

However I do agree that we have to merge into a unified terminology with time in all similar tools, it just will make users life easier. It looks like Database or Table will be the final term here…

[Matthew_Oates]

I would concur that “Table” is a better, more self-evident term for a Type. It’s more universally understood, and I actually initially found the term “Table” for a view a bit confusing. I don’t think you need to worry about users being confusing Table with a view. There’s a reason Airtable (and Google) refer to each Type as a Table, and the view as a “Grid” view.

[rothnic]

@Matthew_Oates

There’s a reason Airtable (and Google) refer to each Type as a Table, and the view as a “Grid” view

Yeah, I agree. If table is used, then changing the Table View to being called a Grid view would be an easy transition.

[Oshyan]

@mdubakov

The only problem I have with Database term is that in real life it represents MANY tables, but in Notion (and In Fibery if we will use this term), it will represent only ONE table.

Yes, this is exactly how it is not technically correct, but ultimately “correct enough”.

@Matthew_Oates

I would concur that “Table” is a better, more self-evident term for a Type. It’s more universally understood, and I actually initially found the term “Table” for a view a bit confusing. I don’t think you need to worry about users being confusing Table with a view. There’s a reason Airtable (and Google) refer to each Type as a Table, and the view as a “Grid” view.

I’m not sure I agree. It’s a universally understood concept, except that “Table” maps to numerous different actual functionalities: database tables, spreadsheets, and simple (formatting-only) tables. It is both a container and a way of representing data and a simple way of formatting content on a page. Most people who have never had any contact with a “data table” probably nonetheless are familiar with a formatting table, e.g. in MS Word. “Database” is not so fuzzy a term, IMO. And has a pretty widely agreed and well understood meaning, even if the very specific details are not correct in this case (as I mention above in reply to Michael). Using “database” also does not require changing as many terms in Fibery.

“Create a Tasks Table”
“Connect the Tasks Table to the Projects Table”
vs.
“Create a Tasks Database”
“Connect the Tasks Database to the Projects Database”

The latter definitely makes more sense to me. But perhaps more disagree with me than agree.

@rothnic

Yeah, I agree. If table is used, then changing the Table View to being called a Grid view would be an easy transition.

Yes, this is the solution if indeed Table is chosen.