Two intensive weeks of Anytype from a Zettelkasten and P.A.R.A user

Hello there !

I just wanted to share my experience of Anytype, from an avid user of personal knowledge management software, and of the P.A.R.A and Zettelkasten methods.

Some context

  • I use the P.A.R.A method to organize my digital information into different areas : Projects, Areas of Responsability, Ressources and Archives.
  • I use the Zettelkasten method to organize knowledge from my studies or from topic that interest me.
  • I really enjoy the topic of personal knowledge management software , and I’ve even made a free online workshop to help colleagues and friends to start using some software and methods to use them.
  • Like many people interested in personal knowledge management, I seek for the holy grail of software: something pretty, flexible, private, free, quick and easy to use, etc.
  • I came to Anytype as I though that it represented the opportunity to finally have a software to rule them all, and in the darkness bind them.

My impressions of Anytype (as of November 2021)

  • AnyType’s design and philosophy is wonderful
    • But IMO, it currently misses some key aspects to really make it explode when compared to other software (see at the end). Much of this is very certainly due to its alpha status, so nothing to worry about on the long term !
  • I love being able to use nicer and more complex formats and designs than with markdown (like in Joplin), and that templates help me do that
    • However, I don’t feel certain about using Anytype daily, because the export and import functions are currently so poor; especially the export, which makes it difficult to share content with colleagues.
  • Creating the templates and objects that you need (and understanding how it works) takes a bit more time thank with other note-taking software; I personally think that for new users to come, it’s very, very important to make the tutorial/new experience absolutely easy to understand, and to have tons of objects and templates at hand.
  • Some things, like the possibility to create multiple sets for one type of object, are sometimes hard to visualize.
  • I often feel like I’m fighting against the editor’s interface to do what I want, especially with side by side blocks. It sometimes feels a bit clunky.
  • Tasks are very interesting, and could allow for the most flexible task management needs that could be imagined (Sorting by priority, by areas, indication of “Today’s task list” with a custom relation in tasks and inline sets, etc.) !
  • Despite me wanting to, I just cannot use AnyType for Zettelkasten purposes right now, because of different hindrances that make it too unpractical. The tagging system is much too slow (see this post), integrating scientific references is too heavy and slow (see this post), research function is not precise or informative enough, etc. I’m sure that this could be changed with some updates, and especially with plugins.
  • The P.A.R.A method adapts very well to Anytype, which makes me think that Tiago Forte could adopt AnyType if it fits his list of needs; this, in turn, would certainly give Anytype a huge advertising.
    • However, getting someone like Forte on board (and many people of the personal knowledge management community) would certainly require ticking the boxes he described here (see image). This is an ambitious goal; but really not impossible IMO, seeing Anytype’s philosophy.

Conclusion

In short, currently, Anytype feels very great on many places (design, object system), and a bit clunky on others (editor, import/export, etc.). Most of it will be fixed as Anytype gets developed, I am sure. Most importantly, I believe that given its current fondations, Anytype have the potential to become an amazing “one fits all” app, as long as it will get the functionalities that it needs.

However, from the point of view of the user that I am, it is currently too lacking in its functionalities for me to use it full time. I will, however, keep testing it and see how it evolves.

In my opinion (and this is just me), here is a list of features that Anytype needs the most in the near future:

  • Proper import or export of data (to motivate users to migrate and stay on Anytype)
  • Multi-window, tabs, or the two together (to help Anytype be something that you use for many things at once)
  • Inline sets, to display custom list of objects that you don’t need to update by hand (to unleash the dreadful power of the objects of Anytype, and lead to incredibly useful auto-updated objects)
  • Improvements to tagging (to make it easier for Zettelkasten purposes, among others)
  • Improvements to the search function (to make it easier for Zettelkasten purposes, among others)
  • Notification from tasks (especially on the phone, to help people migrate their tasks to Anytype)
  • Bibtex import (to get the research nerds like me, who are often interested by software like Anytype, into the mix for good)

That’s it ! Thank you again to the team for the opportunity to be an alpha tester. I feel really grateful for it, and I tried to take careful notes about the bugs I encountered and the features I’d like to see implemented. Normally, I was able to post about all of them, and will keep doing so in the future.

28 Likes

@Klemet thank you for your thoughts and putting everything together!

We share your thoughts about that! We are working on in-app onboarding and first version will come out very soon. Some things should be simplified in terms of UX in next months.

Inline sets are currently in development. Other things are waiting for development with high priority rates, so hopefully, these changes won’t take long.

4 Likes

I’m sharing most of your struggle too, maybe besides the BibTeX as I’m not into the research field myself. Great insight. The ones that hit home the most for me is the “fighting with editor”, “side by side pane” (there is an issue on this from March), and the inline sets.
I’m thinking an easy way to enable notifications would be to support any push service, for example, “pushover”. This is an excellent service I’m using for tons of other things.
More importantly, having a system of plugins through scripting would allow us to write some simple code to interact with various APIs. We could even handle the notification push ourselves that way.

I will continue using Anytype, though, enjoying it so far.

1 Like

It’s interesting to see that I’m not the only one having those impressions !

And that’s a great insight concerning a notification push service. I’m just worried that this would oblige users to go into priced/not open source/not private territories; but still, it’s very encouraging !

1 Like

A lot of them are free or have free plans that almost no one would require bumping, and reliable. Some example that comes to mind:

  • pushalot
  • pushbullet
  • pushover (the one I use have 10k notification per application I create per month, needless to say I rarely go over 300 each).
  • growl
  • prowl
  • plain email (smtp)
  • sendgrid
    Etc etc
1 Like

On the contrary, I think it is very important that there are not so many choices :smiley:

The profusion of choices is often more of a problem than a solution. The feeling of helplessness in front of these choices is overwhelming. It is better to design an in-app onboarding as @vova indicate, hopefully well designed and didactic and thus make users understand how to adapt their own operating mindflow to the application than the other way around.

A child will have much more fun and will understand much faster how to use Legos if you put at his disposal the few dozen main parts, rather than all the parts that ever left the factory.

Thanks anyway for this wishful review that many of us share.

2 Likes

I think that I get your point, @AyneHancer ; the analogy with the legos is very interesting. However, I think I might have a different way of viewing it. I think that it’s because for me, the “lego pieces” are relations and objects fields that you can fill or define; the lego constructions are the object types themselves.

Hence, in my view, onboarding new users without a lot of types/templates ready would be like saying to them something like “here is what you can do with Anytype; now, you just have a blank space to fill. Have fun !”, I have this feeling (which might be unverified) that many will feel more overwhelmed and discouraged than happy. In comparison, I feel that it would be like saying to a child “Yes, you build can the ships in star wars with those legos things. Just try !”. Wherever you give to this child 6 types of lego pieces or 12, you’re still asking them to design different constructions from scratch (here, you’re asking the user to build all of the objects types that they might need, if no template exist). Some will love it; but I’m pretty sure that many will not.

In contrast, I know that I started to learn Anytype’s system (types, relations, sets, etc.) not by reading their tutorial page multiple times, nor by creating new objects; but by first using, and then tweaking existing ones. And because there was existing object types, I didn’t felt forced to create my own to start using Anytype.This would be the equivalent of giving a child a couple of lego constructions, and say “Well, you can play with them, or just remove or add things as you wish !”, which is already much more inviting IMO.

In short, I think that many new users - myself included - will not have the patience, the energy, or the time to create make the mental effort of thinking of the objects they might need, and then try to create them with a system they’re still not familiar with. Hence, I’d say that not having many initial types/templates represents a huge barrier of entry to Anytype : either you’re ready to put the effort to create the object types/templates, or you don’t. If you don’t, you have only one or two types of objects to work with, which makes Anytype no different from over note taking apps. Compare that to Notion, that have a huge database of community made templates ! I don’t think I’ve ever heard anybody saying that this was confusing to them, but I might be wrong there.

In contrast, I don’t think that’s very difficult or confusing to have a lot of default types/templates and then convey to a new user: “either start using this and build later if you need it, or start building now”. Some people are builders, some people are not. Anytype caters to the builder type, but I think that it should cater to non-builder types from the get go. For that, I think that you can create many “default” objects types, and just make sure that the user understands that they can ditch them and build whatever they want in any case. I’ll also add that many people might also feel uncomfortable with what they created, and will always prefer to use what others have made; especially people that are not that confident in themselves.

1 Like

I do understand your concern and the comparison with Notion. But I side more with @AyneHancer as well. The core should have only the types and relations that are absolutely necessary. But a way for users to get premade templates from the team and community should also need to be possible. The team is already planning a way for users to share templates and types as far as I know. The last highlighted info section of the library page in the doc says that there would eventually be a place in the library where users can look at types and templates created by other members of the community and can use it in their app as their own. I think that is the best way moving forwards. So the current types, templates and relations can be moved into the library and be made so that the users can add them on demand if required. A win-win for everyone :grinning_face_with_smiling_eyes:

3 Likes

I agree that this could be a pretty good win-win; but we would have to say what is absolutely necessary, and what is not :smiley: !

The solution of telling the user “if you don’t want to create things, go and see the community object types” is interesting, but I think that it comes back to what @AyneHancer was saying in the beginning: it might be too much choice.

If I’m a new user of Anytype with nothing but the barest of objects to start with, with this method, this means that I have to choose a) the objects types I want to download from the community types (e.g. tasks, meetings notes, etc.), and b) for a single object I want to download, which community type do I take ? There might be dozens and dozens for a single type, as is the case with Notion. In essence, this still gives the user a huge responsibility from the start: either you go and put up the work of doing all of those things, or you can’t really use Anytype the way it’s meant to be.

So, on my side, I really think that there’s nothing to loose with having a big default bank of object types; builders can disregard them to make their own, customizers can tweak them or choose community types, and the others can just use the defaults ones and still have one of the best organizational app ever made. Meanwhile, I’d say that if the user have to choose which default type they use for this or that as they start to use Anytype, it’s still a lot less choices to make than asking them to build most of their objects, or to choose in a list community-made objects. Building objects requires a lot of choices; going to choose what object you’re going to need - even if they’re already made - also requires a lot of choices.

We also have to factor in the fact that many people are not going to have the huge imagination that other have; for example, if there isn’t a default “book” object type, many users might never ever think about creating one, or about searching for one in the community types. In that sense, the defaults types directly show the user what can be done with Anytype, instead of asking them what they can do with it, or what others can do with it. I still think that it’s pretty important, but I might be wrong.

You have misinterpreted my words because I was talking about avoiding the profusion of choices and not the absence of choice, the nuance is important. I am not against having pre-installed objects, but to limit their number. If I personally had to choose which Objects would be pre-installed, I would probably opt for these because I think it represents a good balance between a base of known data and a panel of Anytype’s possibilities:

  • Note
  • Contact
  • Document
  • Set
  • Task

If you talk about a blank space to fill after the onboarding, then yes I think indeed that it is not desirable and I have never recommended it. Besides, the first users of Notion were a bit confused about the possibilities of Databases which were not demonstrated at that time.

That’s why providing new users with a catalog of templates as proposed by @lynxlove seems to be the best solution. On the condition that you think about its integration at the end of the onboarding process, in addition to making it visible and accessible within the interface, as Notion did:
template

You seem to imagine that we would be drowned by the choice of Objects created by the community, when all you have to do is to take inspiration from Notion which offers a first catalog of templates created by their teams, and an advanced section for the curious and ready to waander through the maze of user proposals. No need to make a binary choice.

Furthermore I strongly recommend that the onboarding process should focus on the explanation of each feature, including the actual 11 core types of relations. Because having to do so much manipulation to materialize and integrate our ideas into Anytype is discouraging to say the least.

Indeed, but we can’t compare them because Notion doesn’t impose these templates, it puts them in a dedicated section. If it imposed them on each page creation, it would be confusing.

No it wouldn’t be too much choice, because there will be a dedicated section to these templates, like in Notion.


To sum up, I agree with you when you say that some people are builders and some people are not, but I am convinced that it is better to propose than to impose.
When it comes to the usefulness of a didactic and exhaustive in-app onboarding, I think we can take inspiration from this famous quote:

"Give a man a fish and you feed him for a day;
teach a man to fish and you feed him for a lifetime."

— Anne Isabella Thackeray Ritchie

3 Likes

I don’t think that I understood it as a lack of choices, and I apologize if I gave that impression. I thought that what you proposed was to have some pre-installed objects; but only enough so that a new user would get the concept and start building others.The five objects that you’ve cited, for example, looks great to me as a way to learn Anytype, but not to use it.

My point of view is that while I agree with the famous quote of teaching a man to fish, I think that you first need to think if the man you’re talking about knows what fishing - or even a fish - actually is.Here, we’re talking about a brand new software, with a very different philosophy from what they might have seen before, which means that they actually never tasted - maybe never saw - the metaphorical fish. Why would you spend hours to customize Anytype if you’re not even sure that it beats using Joplin, or the Trello you’ve been using ? In our busy life, I think that it’s quite the commitment to ask up front.

Of course, you could argue that there is another important factor: reputation. I’m sure that many people start using Notion not because they like to build and customize; but because they heard that it was awesome for productivity and organization. I imagine that you might see it this way : that to push users to be builders up front might scare some users away on the short-term, but that it would make Anytype truly shine on the long-term.

That’s very interesting ! So if I understand correctly, the difference between what you’re saying here and what I was saying is that these templates created by Anytype’s team would be in a given “template” section - you’d have to go to this section, and install the ones you need if you want to use them. Hence, they wouldn’t be pre-installed, but available at start, right ?

If that’s the case, I think that we might be coming back to the issue I was talking about; that the user will end up with the responsibility of thinking about what templates they should install or not. Of course, that’s not the end of the world at all; I’m sure that even with the style of onboarding that you propose, there would still be a lot of users coming in.

But I was thinking about targeting other types of people. I can see it around me : I have a couple of “builders” in my colleagues and friends, but I think that the majority of people want a “mindless” experience where everything is already made for them (wherever it is by lack of confidence in themselves, lack of time, lack of interest, or because they prefer the sense of having something made “by pros”).

Talking about it, I think that there might be an opportunity to allow flexibility on this issue, and even pander to the “role-ification” that seems to always have great success in our societies. What if the onboarding screen looked like this ?

(Character icons are from 16 personalities)

Choosing “Shopper” would redirect you to the template catalog for community and Anytype’s templates. Choosing “Builder” would redirect you to an advanced tutorial about relations, object types, etc.
Choosing “Casual user” would redirect you to this kind of screen:

That way, we would have an onboarding with few choices put on the shoulders of the user; a flexible outcome adapted to the user’s need and priorities; and, in my mind, not a lot a of coding. The “Casual user” options would just come with choosing a list of pre-installed objects types, while the “Builder” and “Shopper” would start almost empty, with the 5 object types that @AyneHancer suggested. The only problem would be that some people might use Anytype with tweaking or customizing; but maybe this would be OK. Hard for me to know for sure.

4 Likes

Lovely mockups :star_struck: This would definitely help both new users who just wants to use Anytype and power users who wants to customize or setup everything by their own.

Casual users should be able to delete the built in objects and templates making it possible for them to eventually become a builder / shopper if required.


The team is already working on self-onboarding from within the app. If that is a guided tutorial ( I hope so ) asking users to complete various tasks such as:

  • Create a new block
    • Add something to the block
    • Delete the block
  • Create new page
    • Change cover / icon
    • Change type
    • Add / Remove relations
    • Link to a page
  • Create a set
    • Create different views
    • Filter set
    • Sort set

It would surely reduce the difficulty for new users by giving them the idea of the basic structuring of data followed in Anytype. This along with the User type selection in the initial setup would greaty reduce the complexity in onboarding / migrating their data to anytype.

Let’s hope for the best :crossed_fingers:

4 Likes