Yes, this is extremely inconsistent and confusing.
I can imagine that someone who is new to Anytype is now completely confused and will give up on the whole thing. I myself am confused and don’t understand the intention behind such a decisive change of switching the right and left sidebar.
To me, it looks as if they simply didn’t have a better idea of how to combine Chats and Spaces.
I fundamentally don’t understand the decision to separate Space and Chat. For me, it would make more sense to add the chat function as an additional feature to a Space. I’m sorry, but I don’t understand why a Space should be converted into a Chat, still being actually a Space?
I think I’ve spent a lot of time working with Anytype and I install every available alpha version to follow changes, but this Chat implementation is very strange to me.
@anton Do you think someone who is not yet familiar with Anytype will find it easier?
I will keep myself from “complaining” about the sidebar until next release and see what the end goal is. I will only say anything, if I have something to say as a solution.
We will see, next version. (and before that, through the alphas and beta releases).
on one hand multi-chats are coming that will be a part of a normal space where you can have multiple chats within one space.
I understand and appreciate the functionality of having a stand-alone chat in the left sidebar where the chat is the primary function and space-functionality with additional objects secondary. this way I can faster switch between a chat with my SO with one click and back again to a space where I’m working at.
But I guess this also could get worked out by having the ability to select a chat as the first view when one enters a space.
on one hand it feels natural for new comers to create a chat and go directly into it without having to deal with a space and objects. this is how users know it from other messengers. it is especially neat on mobile.
as they plan to unify the whole sidebar situation in the coming releases I also hope this all gets better. everything feels very inconsistent. we now have 3 different right sidebars and one of them is the same as the left sidebar in another context. the more they add on the existing UI the more it feels like a frankentype. I also know that a complete rewrite of the client would be just too much. but at some point I wish they could back to the drawing board and create a consistent plan for the desktop client and how they want to proceed, make it maintainable, modular and future proof.
anton also said it’s just temporary and the new solution will be more customizable.
let’s wait, see and have faith
Often, you don’t need all the space structure and objects right away. When you open a chat, you expect conversation. When you open a space, you expect structure. On mobile, this difference is especially obvious — in a space, you need an extra tap to reach the chat.
Once multichats launch, the distinction will be even clearer: multichats will only exist in Spaces, not Chats. There’s no reason to switch between them constantly — each format suits different needs and moments. You might start with a simple chat and later expand it into a multichat as things grow naturally.
It also works the other way — some people began in Spaces but later found that a basic chat is enough. That’s actually my case; most of my channels are just chats, since that’s what I use most. Of course, some people will still experiment by switching back and forth, trying to find what fits best.
maybe this gives more context:
We also already have a more intuitive and consistent solution (yes, with the sidebar on the same side). We just need more time to implement it — and we didn’t want to delay this launch any further.
actually yes, in a chat format you don’t need to think anything except just a very familiar interface. Sidebars? Could be confusing - we’ll fix that.
Thanks for taking the time to breakdown the feedback to give us some insight on the process. It is greatly appreciated.
One last remark: The roadmap is hard to interpret as it consists of feature names with no description behind them to understand what we are talking about. With just a paragraph we could have a better idea of what it means. Whats sharing extension? How about multi-chat? You mentioned them in the previous comment but I’m even more confused, I thought it might be a private group chat but it seems to be in a space so then it looks more like discussions but discussions is now it’s own thing. Plugins are missing from the roadmap although you say someone is working on it so is that also the case with other features that are being worked on? It’s all very fuzzy and raises more questions than it answers. It would really help us understand where the platform is going since a lot of big changes have been announced in the town halls and I’m along for the ride but I’d like to have some idea of what to expect and in what order, otherwise it feels like i’m trying to build my shared-personal database on shifting sands, every upgrade looking like a UI overhaul…
@anton Maybe AI could help here to collect all your messages (in the forum, in Anytype-Chats etc.) and condense them into structured output somewhere… whether it is the roadmap on Github or in the new Anytype Community Space. Because I’ve read now a lot of very good feedback from you but it is quite distributed amongst a lot of communication channels and people are now asking similar questions everywhere. Just thinking loud here…
Hey guys! Amazing update–really loving the chat feature so far and love the ability to organize the tags manually for tags/multi-selects. I did notice a bug, the organized tags do not apply in sorting and the sorts continue to sort by alphabetical order rather by custom order.
In addition to @krst ‘s solution, an alternative is to have a Query “Pins” coupled with a “Pinned” tag option. This alternative can be faster (less clicks), if you set up your Object Type(s) to display the “Pinned” tag in the header of each object.
Good idea, too. I also have a pinned property (checkbox) that I use for sorting in type queries so that I always see “pinned” notes there on top of the list - but I don’t want then in my sidebar, just more visible in my lists
I just want to add also this use case for those who are interested. Many roads lead to Rome (as we say it here).
I haven’t checked the source code, but in theory, queries should be dynamic. So every time you run the query, the “manual sorting” would be erased.
Collections, since manual groups of objects, can have manual sorting (in theory).
Also, I think Krst solution of using collections is the proper “good” solution. Adding a property to a note based on pinned or not, you are adding properties/relations to objects based on interface/visual information to the platform, instead of they note values.
This is different, than saying that for example, a music or video is your favorite.
I want my notes/files to have information based on their information and value, not based on the platform they are on. (this of course, in an ideal system, not a pragmatic one)
Just giving my opinion, not saying that it is correct! If your system works for you, it already is the correct way!
I agree with @shannon. I also preferred the old way how pins worked.
For me it is not the amount of space the new pin-widgets occupy but that they always appear at the top when I pin a new page. I have a dedicated ‘Dashboard’ page as a widget that should stay at the top of the widgets but with the new pins that is not possible anymore.
With such changes I wish I had the possibility to decide myself in the settings how the pins should be displayed.
Well, I finally have updated the desktop app up to 0.50.3 version. And I’m really not sure about new logic for the sidebar and pinned objects.
First of all, I don’t think that Objects menu is so popular to put it on the sidebar.
Second of all, now I have to create a new collection to replace Pinned / Favorites objects. It was a particular group of objects from different places of my space (they could even had a different type). That’s not a big problem, but now additional links have occurred that are impact on Graph view. Pinning them is not a solution as they are not grouped in that case and take more space.
can help new comers though getting familiar faster with the concept of types. new users can be overwhelmed as they don’t know what to do. this could help them to start faster and they also directly have all the type queries at hand.
so this move is pretty much understandable. and even I appreciate it as I had a lot of queries from previous versions that are redundant to the default system queries. All in all it gives me a new feel of an “overview”.
It’s what users expect I think. Like if you have a look at your file manager where you see Movies, Documents, Pictures right in the sidebar. This concept is familiar. Would it be buried behind another button people perhaps would ask why this is the case and why they have to click twice to get a list of their images for example.
You can just collapse it if you don’t want to see it all the time. basically you already have dedicated button to view and hide them.
