Merge concept of Set and View (also include Collection?)

[crystaln]

I would suggest changing Set to View. I know this may be controversial because View is already used, but consider it for a moment.

A View is currently a slightly more complex query than a Set. Why would they be different to a user? Any time the number of concepts can be reduced, the product is great simplified.

Notion has moved toward this (after IMO bastardizing the term “database”, which I would suggest avoiding).

Now in Notion when you inline a “database” (table? sigh), you can add views of DIFFERENT databases to the set of views in the same UI element. You can also copy existing views, however this is quirky as you can only copy them from the main database, and not from other instances of the database.

In this Anytype paradigm tho, Views would simply be referenced in the UI element, and would change everywhere when changed. That last part requires some UX thought, however I think you can do something like ask the user “change everywhere or just here?” the first time they change a View that is used in multiple places.

At this point there is no distinction between a Set and View (or Query, but View is better IMO).

For example:

One can create a View of all humans (currently a Set), a View all humans ordered by last name (current a View on a Set, but why?), of all humans filtered by age, etc.

You can also have a View of all tasks.

Now these Views can - like Notion - be combined as tabs on the same in-line UI element, (along with Collections).

And the user only needs to understand one concept - Views. A View can be a complex or simple query on an object type, relation, etc., which conveniently is also what it means in software.

With some more thought, Collections can also be included. Of particularly interest here is manual ordering…

[Neuru]

I know the set is going to be merged into a collection.

@ignatovv

The rough timeline I can forsee:

1. Ability to change default type for collections and sets by relation (start of Q4)
2. More robust sets querying (end of Q4)
3. More powerful search functions (first half of 2024 depending on other things)
4. Some things towards the sets being part of the search (Somewhere in 2024 hard to say, it is roughly a priority or smth)

I think of a collection as the object data collected and a view as the information processed and displayed.
I don’t think it’s appropriate to call them one term.

What do you think about adding the concept of inline views in addition to inline collections?
Currently, inline collections (and sets) share data with the original collection, but not views.
So I think inline views could be a good option.

[crystaln]

@Neuru

I think of a collection as the object data collected and a view as the information processed and displayed.

The only distinction here is the displaying of that data.

In software / databases, a “View” is a saved query - close to what a “Set” currently is, but also can be complex queries with sorting, etc… The goal shouldn’t be to use software development terms, however in this case it makes more sense than Set.

“the information processed and displayed” - is no different to the user. Also in order to be used, a View doesn’t have to be displayed. For instance a View in theory can be used as a data source for something else.

A displayed View is just opening the View to the user, so of course the query is executed and information displayed.

This just makes so much sense to me! I don’t see any need for the different terms. Hopefully others can see what I mean.

[Neuru]

I’m not sure if I’m understanding you correctly, but to me that sounds like you want to have only one view per collection.
Wouldn’t it be better to have multiple view options per data collection?
Every time we create a different view, do we always have to collect the data again?

[Neuru]

If that’s not what you mean, then it seems like collections and views should have different names. Like views and inline views.
If they were both just called “views”, people would be even more confused.
The terms views and inline views don’t even sound any better than collections and views, which are pretty awesome words for the average person to intuitively understand what they do.
Collections to collect data. And views to show it internally.

[zhinn0]

This makes sense to me. It comes down to having a saved query, basically a constraint on the information to be handled, whether it’s being handled transparently to a user like as a datasource for something or is visible like when a user is viewing the saved query.

I like the idea of consolidating the concept and Set and View into a singular “View” especially since the plan is for search to become more robust and to tie sets into search.

Making it very flexible on how to display these saved queries (or saved searches) would make distinction between Set & View unnecessary.

I’d also like to see changing filters & sorts on the fly to become much easier to do on the fly. Fewer clicks, ultimately.

[Neuru]

Since the set becomes a saved search, I believe it can be integrated into the inline view.
Also, collections themselves are databases, not searches, so I don’t think they can.

[crystaln]

It may be that a Collection would remain a separate concept, and a View is a query, which can be from anywhere, including any collections.