What do you expect to see?
IMHO, no one would get it clear, what’s going on when someone else from “far far away” clicks on my checkboxes, writes a line, then, suddenly, a text part becomes red or green for no visible reason, and so on.
Impressions from the side menu and the thing with “Widgets”
I’m one of the users that never cared so much about the Widgets in Anytype.
But as I know, my dear fellow @Shampra misses them a lot.
I don’t get it why, because I think the actual possibilities in AnyTwo are not so bad, but see the first impression in the video.
You should know, that the Favorites section in the left side menu is able to store things that can physically be located even in different Spaces.
And we can add folders to that Favorites section, then nested folders inside of these folders … and so on.
– Have a look:
This is absolutely amazing! It’s a great way to work with hierarchical folders while maintaining the typical Anytype structure (did I understand correctly?). It’s fantastic for me, it simplifies my workflow and yet the data remains organized organically. I love it. Thank you C.J. for the visual feedback!
Grouping in Views – and where to find “Last modified” Pages, etc.
In the Feedback Board came questions similar to “where do I find my recent things? I’m lost”
In this video, I show you two things:
- Where to find your recent created/modified Objects.
- The group feature for Views that becomes handy in this relation.
If you are new, go into the section “Formats”. There you’ll find “Page”.
This is a Mini app that behaves similar to a Query, that lists all your Pages, no matter where they are.
You can configure the Views of that query -like Mini app, so that it works similar to the “Recent …” Widgets in Anytype.
– It makes sense, to put it into your Favorites menu on the left side.
From now on, you have your substitute for the known old “Recent” Widget in the left side menu, where you can move it into a folder if you like that.
A nice feature that Views now have, is the possibility to group the displayed entries.
Similar to “Page”, there are other Mini apps in the “Formats” section, that list for example images, or chats (if you have multiple), or human Profiles, or Tasks, etc.
Look for yourself:
@Code-Jack thank you for the detailed reports, this is great! Are you already using Anytwo as your main driver, or is Anytype still your main driver and you’re still on Anytwo in testing mode?
This brings up a really interesting question about the “birth state” of an Object in AnyTwo:
Can you actually create a new Object from “thin air” - meaning a completely naked, blank Object that belongs to no Collection at all?
From what I understand of your description, when quick-capturing incoming info, doesn’t the system still default to creating a base entity - usually a “Page” (which acts as a base Type/Collection)?
If so, when you later triage that Object and assign it to its proper destination (e.g., adding a “Contact” or “Project” tab), do you have to manually remove the initial base “Page” tab?
While that might sound like a minor detail, having to perform that extra cleanup step adds up to a noticeable friction for high-frequency users. For newcomers, it also introduces a subtle cognitive hurdle: “Why does this new note have to be a ‘Page’ first if it’s actually an invoice, a person, or a quick snippet?”
Having to create, or tolerate the existence of such a placeholder type/collection in AnyTwo just to catch newly created, unclassified objects, only to discard it later, feels inherently redundant both in terms of system architecture and user workflow. More importantly, it goes against common-sense intuition: why should the system require an artificial container just to capture a raw, unclassified thought?
A much cleaner and more natural approach would be allowing a truly raw, standalone Object state: an entity born completely clean, carrying only space-wide properties, with zero initial Collections attached until you actively decide where it belongs.
Does AnyTwo currently have any mechanism to create such a raw object?
The base object is a page.
This is really the basic concept,there’s no such thing as a “Page,” “Note,” etc., so there’s no need to worry about it. So, a little different from Anytype pehaps.
As for collections, you can add them later if you want.
In my case, I create a lot of notes and pages without giving it a second thought (except for being able to find them easily later…)
I see now! Looking back closely at the videos shared above, it seems “Page” is indeed no longer a rigid Type/Collection, but has essentially become a Format.
That makes me wonder, though: where do these raw, unclassified objects actually get aggregated for easy tracking and triage, if someone prefers not to rely on a Mini-App?
Finally I made it into AnyTwo.
There was a discussion somewhere about the presence of AI-options that are shown in AnyTwo, even when you do not use it.
It is possible to switch them off in Space-Settings => Preference => Features => AI-free mode
and all offers to register or use AI are switched off.
For me this is perfect for the moment. Although I would be curious to use a non-techie fools-proof system or plugin provided by the AnyTeam.
For my real data, I still use Anytype, because it was told to us that things are under heavy development and it could maybe happen that things suddenly no longer work as it was, or even some partial data losses occure.
But deep inside me, I already don#t care anymore about Anytype.
Mentally it’s already history for me.
I’m an Anytype enthusiast since long, but AnyTwo is such a big step forward, that I would like to migrate as soon as possible.
But it’s still too early for that.
For example, there are no inline Queries or Inline Collection yet, but the devs work actually on it.
Also the global search is still very rudimentary.
Some other things are also not finish yet. Many of them should be ready in the very next update, because they are already marked as “done”.
Maybe it comes already tomorrow.
That update will be a big step forward – when I see what’s already marked as “done” in difference to my actual version 0.1.4, it’s really a lot. It will make many things much much better.
But we should wait, the release was announced for “end of this year”.
There’s no doubt that this will become true, but it’s better to really give them the time.
Hmm, yes.
There are even multiple ways.
What you create in the “Page” Mini app is the most raw Object possible.
You could put “Page” into your Favorites. From then on, it would need exact two mouse clicks to generate such a raw Object, no matter where you are in the moment.
I’ve just tested it: these two clicks need actually ca. two seconds.
There is theoretical a little improvement possible (one click, one second), but compare it to Anytype!
And there is no need to remove the “Page” header from the Object. It will remain there and that’s good so.
In principle, it works as a relative tiny link button there.
Mate, I show it to you:
Warning: Maybe the video looks a little chaotic and you would wish that everything looks somehow different.
But you know, you can configure so many things, including the behavior of the Views.
I, personally, like the optional Side Peak Layout, it is great. But if you only watch it in the video, instead of doing the things by yourself, it may look chaotic how it behaves.
Thanks for the video, @Code-Jack, that really made things click for me!
Turns out my earlier assumption wasn’t quite right. “Page” now seems to act as both a format (just like Action, File, View, etc.) and an implicit type/collection. It’s not redundant baggage at all; it simply reflects the underlying data layer, and you don’t even need to delete it when triaging the object into its proper place.
That mechanism actually seems pretty reasonable. It also helps me understand why Kaye said Objects and Collections can’t be blended right now, under the hood, the engine keeps them strictly separated (to write, the format has to be a Page; for collections, it’s a View).
Still, I really hope down the road they can either merge Page and View or introduce a new format that brings them together. Having notes, child objects, and all those backlinks truly unified on a single object would be the dream setup.
They are doing the heavy lifting to shape something really promising!
Yupp.
And it’s worth to mention:
- The “Page” Mini app is in principle a Query, that automatically finds and lists every Page in the whole Space.
- Its name “Page” is a little confusing for newbies. They could confuse it with a single Page, although it’s in principle a Query.
I’ve therefore requested to rename it to the plural “Pages”, so that it makes sooner “click” in the head.
Btw.: I’ve also requested to add a “Create Page” button on top of the left siede menu.
This would avoid the long mouse distance from the left side menu to the “+” button on the rigth of the “Pages” Mini app aka Query.
As result, it would always need only one single mouse click to create immediately a raw new Page, no matter where you actually are in your Space.
You see, the (actually) two seconds and two mouse clicks actually are good, compared to Anytype, but it is still a little friction with room to improve it even further and to the maximum:
- One single click, one second → a new Object is generated. Always and everywhere, no matter what you do at the moment.
Oh, and after doing things in the new generated Page:
The “Back” button brings you reliable back to where you was before!
– So, don’t be afraid that an interrupt disturbs you with new incoming information. I’ts no problem to handle that, even in a single Tab.
Reflecting further on my previous comment, I realized I was too hasty in accepting that exposing the “Format” of an object is a good thing.
I caught myself looking at it from the subjective perspective of someone interested in data architecture. But how does this actually look to an everyday user or someone just starting their PKM journey – the vast majority AnyTwo wants to welcome? Do they really need, or want, to know about the underlying data plumbing?
Why should an everyday user ever care what an object’s underlying technical format is? Does surfacing Page, View, or File on the interface genuinely bring clarity, or is it just the software’s internal plumbing leaking into the user’s mental model?
I ask this because years ago, I fell into this exact trap myself – partly because the tools back then simply weren’t mature enough. I remember spending countless hours obsessively sorting, converting, and categorizing my digital library by formats and file types: segregating PDFs, converting EPUBs, tweaking metadata schemas – I even hoarded files in the old LIT format, a relic nobody on Earth uses anymore today – until one day I caught myself realizing I had spent all my mental energy managing digital containers, completely losing sight of the only goal that actually mattered: simply opening the book and reading it.
A truly great tool should shoulder all of that difficult, tedious work for the user beneath the surface.
When someone wants to read, all they care about is the narrative – the ideas, the prose, the insights. Whether the file payload under the hood happens to be an EPUB, a PDF, or a DOC is completely irrelevant to the human experience. A smart, modern system should quietly recognize the payload, launch the right viewing engine, and get out of the way so the user can immerse themselves in the actual work.
Yet, that is essentially what we risk repeating when we elevate “Formats” to a prominent interface concept in AnyTwo.
In a personal knowledge system, an Object named “Office Key” or “Dune Universe” is a conceptual entity. Whether it contains a narrative text block, an image, or a collection view is merely payload. When software forces users to consciously parse and interact with these technical containers, it drags human attention away from the essence of the thought and redirects it toward the mechanics of the tool.
This distinction is critical across the entire user spectrum:
- For everyday users and beginners: It introduces unnecessary cognitive friction. It risks trading Anytype’s old “Type paralysis” for a new “Format ambiguity,” making onboarding needlessly intimidating.
- For advanced and power users: It fuels that insidious trap of procrastination through system tinkering that I lived through myself. Seasoned thinkers don’t need more meta-work; we need a system that acts as cognitive armor, quietly managing the plumbing so 100% of our mental energy remains focused on synthesizing real knowledge.
Therefore, as AnyTwo matures toward its final release, my proposal is simple:
Hide all of these underlying technical mechanisms by default.
Return the default Object to simply being an Object – pure, clean, and unburdened. Please do not pre-classify or categorize incoming objects by default in any way, whether through labels, badges, or format icons. Let the software handle the technical heavy lifting invisibly, and leave classification entirely in the hands of the users, shaped purely by their own intent and practical use cases.
Software reaches its absolute finest when its technical genius remains entirely invisible, quietly doing the hard work underneath so that human thought – and only human thought – takes center stage.
Moment,
the format make sense.
One Format is “Page”.
One other Format is “Image”
– You will surely confirm that at least this distinction makes sense, don’t you?
OK, if so:
There are some other Formats, that are not a Page, nor an Image.
Task (aka “Action”)
A Task may have similarities to a Page, but it has other features, like for example a meeting date and an automatic reminder that rings a bell one hour before etc.
The user doesn’t need to care or to know about the differences underneath. The raw thing is an “Object”.
Only in the moment when he applies a specific Collection to the Object, it inherits the needed features aka Properties.
For example: he can have a Page. It was always a Page, nothing else. Then he writes something in that Page about the flirt with the waitress that he has had last week. So he decides, to add the “Contacts” Collection to that Page. Immediately he has the Properties that make sense to manage a contact.
While further writing in that Page, he suddenly remembers, tat he has sold his clock to a guy. so he decides, to add also the “Deals” Collection to that Page.
That are no different Types anymore, like it was in Anytype.
You can put all what you want into that Page, but you can make it that it has all needed Properties that are needed in another context.
There is no need anymore, to split this Object into three different Objects and to transfer them into different Collections. Simply add the needed Collection, so easy as if you add a Tag.
There is something still a little half-backed at the moment and under development.
Behind the “Formats” are Mini apps.
They actively do something.
For example the Mini app “Page” that appears in the “Formats” section, behaves de facto as a Query.
It DOES something, actively.
What does it do?
– It automatically gathers and lists all Pages in the whole Space.
This is a VERY basic Mini app. There is way more to expect from Mini apps in the near future.
It’s not worth to discuss the details of “Formats” and “Mini apps” and the difference or similarities to “Objects” at the moment.
Already the next update, that maybe appears tomorrow, will bring a lot changes and news – renaming of certain things included.
But there ARE different formats (Page vs. Image for example), although they all are “Objects” in an abstract sense.
If the user searches for a certain image, he definitely doesn’t want to see Pages, because they are clearly of a different format.
AnyTwo makes it well that it separates these different formats for the user.
Under the bonnet, they are “Objects”. A stream of binary data, made of ones and zeros.
And each Object has features aka Properties.
About global Properties
Not so long ago, there was a Thread from @Kaye, where he asked if we think that global Properties are still needed (can’t find the thread at the moment).
My first reaction on it was WTF??? – Off course!!!
Meanwhile, after all these tests of AnyTwo, I’m not sure anymore.
– I would say, I’ve changed my mind to the opposite: Get finally rid of the dammed globals!
They are not needed. To get rid of them brings us even advantages!
Yes, even although we all have lots of global Properties in our Anytype Space, I can imagine a migration tool that handles that.
And in AnyTwo, the Mini Apps can perform active things that magically work for us in such a way as if there are still our usual global Properties – although they not exist anymore.
– That’s relatively hard to explain and I’m not absolutely sure about that, but to 90%.
At the moment, it’s speculation, because the needed migration tool doesn’t exist, nor does the Mini app.
(At least, we testers don’t see something like that yet.)
But my basic idea is this:
- The migration tool splits our global Properties (for example date Properties, or Tags) into lokal Properties that are then in each AnyTwo Collection.
It will be easy, to program such a function for the a migration tool. - After the migration, we find the situation where each Object still has the same Properties as it always have has in the old Anytype. But they are no longer global, their scope is now bound and restricted to the Collection.
- Now comes a Mini app to the game. – A Mini app that in our perception works like a Query.
Under the bonnet, it merges the local Properties temporarily together, so that the Mini App can work with it like with normal globals.
For us and our work, nothing has changed.
All this is just my imagination at the moment, but I believe this concept would work.
We wouldn’t even notice a difference.
And when we add a new Object?
– Nothing special. We would fill in the values for our (now local) date Property, we would chose our (now local) Tags, etc. – in our perception is everything as always. (Although, hidden from us under the bonnet, with restricted scope, bound to the Collection).
Look: the COLLECTIONS and their Properties are encapsulated sets of local data.
But the MINI APPS are active programs that have access to everything that there is in the Space.
For them do local restrictions not matter at all. They “look from above” on everything and they can be dammed intelligent!
But why all that? Why not simply use global Properties?
– Now, if you can program, you surely know the difference between the old fashioned, bad style global variables, and a beneficial object based approch.
Object based code encapsulates functions. This has many advantages.
If I apply this principle to our new AnyTwo application, one of the advantages jumps direct into my face: it becomes WAY more easy, to transfer Collections from one Space to another, or to copy it.
To give you an image in mind:
- Encapsulated aka local restricted: It’s very easy to transfer one bottle beer from one fridge to another.
- Global, without restriction: It becomes another (worse) story to transfer the beer, if the beer was spilled and has splashed onto all sorts of surfaces and is mixed with some splashed milk.
More concrete (most of us will know the problem):
Imagine you have two Spaces.
They contain different things with different (global) Properties.
What happens if you now import the data that come from Space 1 into Space 2?
– Most of us know what happens: We have suddenly a lot more Properties in our lists and we think “wtf?”.
Import data from 10 Spaces into one. You will have as many Properties as hairs on the head!
And conflicts may (or will) happen, if there are Properties in the different Spaces that have the same name, but maybe not in all cases the same kind of data in it.
Maybe one Space has the Property “Temperature” but the unit was meant in Grad Celsius.
The other Space has also the Property “Temperature”, but the unit was meant in Grad Fahrenheit.
After an import, everything is mixed! Pure chaos!
You see, global Properties can cause trouble.
But if everything is encapsulated and restricted to local, it doesn’t matter. One Collection works with Celsius, the other with Fahrenheit – no problem.
But what about Queries, if gather everything and filter or sort for temperature?
– AnyTwo uses Mini Apps instead of Queries.Mini apps can bring as much intelligence with them, as needed.
The mentioned problem with Celsius vs. Fahrenheit is still problematic, yes. I don’t have a simple solution in mind yet. But at least, the data don’t become mixed with each other. They remain clean encapsulated in their Collections.
– That’s a huge benefit, even although a kind of “Query” may have issues to display the values in a sensefull way, they are at least not contaminated with “foreign values”.
Global Properties would make everything worse! They would mix up everything.
Nothing is worse then a kind of list that contains for example number values, but their meanaing is different!
One would never know how to interpret them.
And btw.: years ago, because of such a case (metric data from Europe mixed with imperial data from the USA), did once a Mars probe crash on the planet’s surface – a very expensive disaster!
The more I think about everything, the more I come to the conclusion, that we should get rid of global Properties!
The only things we need was already mentioned:
- A good migration tool.
- Sufficient Mini apps that hide from us the fact that Properties are now encapsulated and local – not spilled global anymore.
So, I would say, I’ve changed my mind.
No more global Properties!
Interesting thought.
On the other hand, there were quite some arguments in favor of global properties.
And with respect to migration, you could just mark the incoming global properties in an appropriate way, i.e. the first characters of the imported space-name in brackets or else.
I can tell you now! 
Because the feature to choose the category of news can be overlooked easily, so it happened to me just now.
And in the end you have no way to orrect your fault. At least, I don’t know it yet.
Yes, I did ask that question and I’m sure many peoples eyebrows were raised—seems idiotic that it’s even a question. It was difficult to explain why I was asking such a question at that point in time, as too much about Anytwo’s architecture was not yet explained.
On a high level, your points about the problems with global properties is accurate. It creates a huge mess when import, export, merging, and cleaning up properties. It’s silently a big cause for data integrity issues when moving around data between spaces. In the user’s mind, it’s clear what something is, but to the system it is absolutely not clear. When you add collaboration and the need for users to share types/properties/templates across spaces, you can see why it’s pure chaos in our local-first system where changes sync asynchronously.
But indeed, we can’t just remove global properties without finding a solution for what they were used for. Hence why we were looking to better understand the actual use cases. I don’t think our solution is leaning towards it being a specific mini app, but we’ll see how it develops.
As I said, an impression of how the collaboration features feel in comparison to AnyType and how full featured they are. A video would not be required for that.
But how is that different from the issue of moving objects that have collection-specific properties from one collection to another?
To me, none of the things mentioned here remove the very critical and central need for space-properties