I have always found it very weird, annoying even, that the archive is same as trash in Notion. It was surprising to see that Anytype used the same design. To give an idea of why I find it counter-intuitive, here is how I use both of them.
Archive:
A place for long term storage. Ideally, the pages in archive would not show up unless searched explicitly, but the links to these pages exist and can be linked in documents that are not in archive. For example, if I use anytype to write my journals, I would like to archive them every year or so, but still want them around and searchable. Additionally, archive should be sortable into folders.
Trash:
Basically stuff which I don’t want and get rid of. It could be a recycle bin of sorts which can be cleaned once in a while, so that there is no accidental deletion, but eventually I would want to either get rid of them or restore. That is, trash folder should be ideally empty (very different from archive which is long term storage).
I feel that these are non-overlapping features and cannot be combined. There are my thoughts on the topic - not sure if everybody agrees. Something to think about and possibly implement, if everybody agrees.
Some interesting points, which I partially agree with. I have a few perhaps disjointed thoughts.
“Archive” may simply have been chosen as the name because you can’t get delete things. Or possibly the concept is a mix of the uses you describe, and “archive” seemed most appropriate. Also possible non-native speaker factors.
In general I think a trash should work as you describe. I am less convinced of the implementation of an “archive” function as a core part of how Anytype works. What you describe is perfectly valid and functional, but it’s also a very “opinionated” way of doing things, especially in the way that things in the archive don’t show up in search, etc.
My sense of Anytype, and similar tools like Notion, is that they are trying to approach things in a fairly general, flexible way so that people can create their own unique workflows out of a set of capabilities, rather than creating a single, more specific workflow or way of doing things.
Of course they could offer an “Archive” function that does what you suggest and maybe lets you optionally enable/disable hiding its contents from search. But I feel like that kind of thing may be better as a plugin.
What I’d actually suggest as a solution to your problem and bringing greater functionality that would IMO better play into the core flexibility principles of Anytype would be a simple toggle in settings for every page/folder/container that allowed you to hide it and its contents from search. Ideally then there would be a corresponding toggle on the search dialog itself to “force” searching within hidden areas, which would of course be disabled by default.
This would allow you to do almost exactly what you’re requesting, create an Archive page/folder, move stuff into it for long-term storage, and disable search on it by default. But it would also let people do that for multiple folders, for those who have totally different ways of working or needs for the “hide from search” function. In other words add a more generic function that enables your use case and several others.
Thanks your thoughts, @Oshyan! You raised fair points. It might indeed be the case that the name “archive” was chosen because of a lack of delete functionality. Or due to non-native speaker factors - this is something that completely slipped my mind. With both with Notion and with Anytype, I guess I got triggered by disparity between the name and the functionality
The way I have suggested an archive should work is definitely “opinionated” - it is after all based on how I use an archive. I do agree with the generic method of giving an option to hide a folder or a page from search as it provides more flexibility to the users.
From my understanding, the Anytype team is going to enable deletion of pages soon, but its not a feature at the moment because of the complicating factor of IPFS. (There’s an update from awhile ago, [here](November Update) where they say that they’re going to enable page delete soon. It could be enabled already and I am none the wiser, but I’ll link it anyway.)
We will add your opinion to the discussion of how this feature should work.
Actually, yes, the way the archive works was based on the lack of deletion. It only marks the page with a flag that those pages, stacked in Archive, and should be removed from search and look different from the regular objects.
@laurara you are right! We are going to implement and release this feature in the nearest future.
I’m confused because when I press the “Archive” button, it goes into a place called “Bin” instead of “Archive”. Also I don’t see trash anywhere. Am I missing something?
Agree with @abstractgeek these are two very seperate concepts.
I don’t understand the need for both of these in a note taking applications.
Bin/trash/rubbish bin: This is a well established idea - this is a collection of files that are marked to be deleted - either immediately by the application, automatically on a schedule (when I close the app, every X days), or manually by the user.
Archive: this is a less defined concept, it can vary from application to application.
It can be as @abstractgeek mentioned - files that are wanted but to be used less often, or about to be moved to bin, or anything else.
I’ve seen archive uses in Kanban boards where cards are removed from the board column to simplify things visually, but can be “retrieved” from the archive of they become relevant in the future.
I don’t see the need for archive in note taking, but if it was included then it needs to do something different than bin/rubbish/trash.
Or possibly the concept is a mix of the uses you describe, and “archive” seemed most appropriate. Also possible non-native speaker factors.