Collections, missing function: "Restrict this View to ..." (objects with this feature)
I want to have a quick way to restrict a Collections View so that it only displays Objects with a certain feature.
This new way should work much quicker then manually setting up a new filter rule:
In the collection's table, the right-click context menu for a field, should offer the needed function.
Example: song management:
I have a huge Collection for songs (more then 1000 songs). The songs are from different artists.
Let's say the table is not filtered and not sorted at the moment, or we don't want to touch the filters and sorts.
Now, while randomly scrolling through that Collection, I suddenly see a song from the group "Scotch" in the table.
I suddenly want to see all other songs from this group! And all other entries should therefore temporarily vanish from the table.
In legacy Anytype, typing manually the name of the Artist "Scotch" in the Collection's search field would do the trick.
But I want it even quicker (without typing), also, btw.: searching for the artist doesn't work yet in AnyTwo.
What I request for:
A right click on an artist in the View, should offer in the context menu the entry "Restrict this view to this feature".
(The "feature" is here of course the name of the artist: "Scotch")
-- As result, the actual View suddenly displays only the 3 songs from the group "Scotch", but no other songs.
When you watch my video where I mimic the situation, don't be confused
-- have in mind what I want but isn't possible yet: to see only songs from "Scotch".
(But whithout cumbersome modifying the filters and sorts.)
6 Comments
Sign in to comment
·2 days agoThanks for the detailed request and the video walkthrough — it's really clear what you're after.
To make sure we understand the full scope: when you right-click a cell value and pick "Restrict this view to...", should that filter apply only to the current view (leaving the collection's base state unchanged), or should it modify the collection's filter rules permanently? And if it's view-only, what happens when you navigate away and come back — does it reset, or stay in place until you manually clear it?
Also, just to confirm — this should work on any field type (artist, date, status, etc.), not just text fields, right?
It seems like the search/filter would solve the exact problem. You just have a preference for clicking a menu button rather than typing?
A search filter could off course deliver the same results in the table.
But configuring such a filter would cause a lot friction. Also, the user would need to remember it that he has applied it and remove it later when no longer needed.
My suggestion on the other hand, would only need a right click, followed by a left click.-- That's way quicker and doesn't feel like friction.
I should add, that this kind of filter is only temporary. It works as long as the user interacts with the results.
But when he either clicks outside of the results, or he closes the Tab, this temporary filter is gone.
I send you as PN an invitation to my Space so that you can try it direct there.
Try to get only the songs from "Scotch" displayed in the table.
-- If you need more then two clicks for that, then you have lost against my suggestion! ;-)
I understand the desired outcome, but as you can imagine, it is very easy for a system to be come bloated with too many options, too many menus, etc. The search filter actually does the same thing, once you navigate away it disappears (it's temporary).
We'll see if other people vote for it, but it doesn't seem necessary in my mind—more of a preference of how one wants to do something.
Nope,
1. the search filter "actually" doesn't do the same thing.
I've shown it in my video: typing "Scotch" into the search field, delievers 0 results.
2. If, in uncertain future, the search works as expected, it would be way more cumbersome. First needs the user move the mouse over a long distance to the search field; then he must click there; then he must put the mouse away and reach to the keyboard. And finally, he must type in the search term.
Compared to my two-clicks suggestion, a huge friction! And that for a function that'ts needed multiple times per day.
3. A strong argument more:
If the search would work, what would happen if the artist isn't "Scotch", but "Aha". Or "Now". Or "Jazz man". Or "Police"?
The search would deliver lots of irrelevant results!
-- But that's of course not what the user wants!
Wanted is, that the table shows really nothing else then the relevant results that have exact this specific feature:
The related artist is "Scotch" (or "Aha", or "Police" etc.).
-- The search function doesn't do that.
Also: we talk here about ONE SINGLE entry more in that right click contect menu.
-- Only one entry more, that's without doubt needed more often, then all the already existing six entries together!
The existing entry "Open" there is not even necessary, because to open "Scotch" works already also with the left mouse button..
Oh, and btw.:
If the artist is "Maëlle" I get a problem if I would need to type that name into the search fielsd How to type in the character "ë" ?
Same with the artist "Юрий Шатунов".
-- I can read that. But I can't type it.
Visitors of my Space would even less be able to type that.
But my suggestion that needs only a middle-click plus left click, solves that.
No problem to find all titles from that singer.
-- These are real examples, I have both artists in my Space; both with multiple songs.
Oh, and what if the artist is "Orchestral manoeuvres in the dark"?
(A popular group in the 80th... btw.)
What delivers the search function if I type that in?
Delivers it all kinds of "orchestral" music?
And what if I don't want to restrict the table for the artist, but for my date Relation? Or for another Property, like a Tag?
-- You see we really need my requested feature!