I don’t know if it is helpful or speaking out of my place, but as someone who was once in the same outside alpha testing position as you are, I also saw certain features be developed to my surprise, when other things seemed to not get attention. Now “on the inside” I think I can speak a bit to what is going on, and why it makes sense to work this way.
The Graph View appears complicated. I would have said the same in your place. But behind the scenes I saw how quickly it came together. It was largely the work of a single dev, and the majority of it took shape over a couple week period, intermixed with other work. It was, in fact, a big feature request (see most recent blog post for stats), and given the lack of a “tree” view, it is also one of the only ways to really navigate all your objects at once. So I think it actually made a lot of sense to work on it when it happened.
The other thing I’ll mention, which may be a bit less “tangible” or necessarily relatable for some, but I think is also quite important to understand, is that developers often like working on new, cool, interesting features, and doing so makes them happy. Happy developers tend to be productive ones. This should not be done to the exclusion of bug fixing, of course, a balance must be struck. But you get a lot of the best work from devs when they are “in the zone”, working on something that excites and inspires them. And this inspiration can strike somewhat randomly.
In general you don’t want to have to be in a position to have to tell someone “I know you’re feeling really energized to work on X, but we need you to fix all these more tedious/annoying issues instead”. This affects morale, and you lose that momentum, that “flow”, that potential “lightning in a bottle” that the dev may have in that moment. They may also ultimately just be less productive in terms of output-for-hours-worked if they’re not allowed to follow their inspiration to some degree. Of course such feelings are fleeting, so on the flip side they are not occurring and taking priority all the time. But when they do, ideally there is space in the dev team to allow it, and if possible others may take up some of the bug fixing work, etc., or the overall priority just has to shift temporarily.
Meanwhile there are numerous reasons other than dev priority shift that unresolved bugs remain unresolved for some time. In some cases a bug occurs in a feature that will be completely redesigned or is already being refactored, so it is not worth fixing the individual bug directly. But since the work that will ultimately fix it (redesign/refactor) is more significant, it can take longer for the “fix” to come. At other times, while the issue itself may be obvious to a user (e.g. performance or space usage), the way to fix it may not be, and so again it might remain unresolved for some time, simply because a solution is not known. There are several other compelling reasons, but these are two notable ones that may not be immediately known from the user side.
Ultimately there are limitations in what can be done, and reasons for shifting priority between bug fixing and feature requests, which may not always be clear outside the dev team. It is a dance, a balancing process, that can only really be fairly evaluated over the long-term, I believe. But the one thing I would say which I think can help with all of this, and which the team can improve on, is external communication. Again this has to be balanced because it takes time even to reply to every feature request with “acknowledged, we will consider it”, or whatever. But I do think there could be a bit more of a shift to proactive communication of current priorities, features that are being considered or worked on, etc., and there is internal discussion to improve on some of that (Vova mentioned some).
I can understand the interest of the Graph View and its navigation possibilities are certainly welcome, but they are far from being equivalent to a Tree view, because unless I am mistaken, the spatialization of the Graph view evolves and builds itself automatically, preventing us to memorize the location of each object.
It is not at all comparable to the organization and navigation of a tree view. Not to mention the fact that its accessibility is not present from the home page.
Unfortunately, unlike other community forum platform, Anytype doesn’t limit features votes, so I bet that the Graph view would not have had so many votes if users had to spend their votes sparingly and prioritize them.
Concerning productivity and task assignment, it’s a question of point of view. The state of Flow is obviously the goal for all the reasons you mention, but I would never favor individual fulfillment to the detriment of the proper functioning and development of a company.
Instead, a company have to look for profiles that correspond to the needs and among all the developers on the planet there are some for whom bug solving is just as stimulating as a treasure hunt for a child. You just need to recruit these kinds of profiles, but recruiting is a whole other managerial topic.
Thank you for the explanation about all the unknow reasons behind a delayed fix. It would certainly took a dedicated fulltime job to notified every users. I’m glad to hear that the room for improvement about proactive communication is filled with thoughtful discussions.
You’re right that it is not equivalent to a tree view, and I did not mean to imply that it was a reasonable replacement for one. Rather just that Graph View can serve some similar purposes as Tree View, while of course being totally different. The other advantage it has from an implementation perspective is that it works more like Anytype’s back-end actually works, so it’s easier to implement and translate “actual graph network connections to visual Graph View”, whereas creating the Tree View takes more effort, consideration, etc., and requires more group discussion on how it should work. I have seen this unfolding over the past weeks and even months as initial planning and then some dev began in this area. Some things take more time and effort than others, and it can be unintuitive which is which, especially from the outside.
Fortunately, as I say, Tree View is being worked on already, so it was not a case of “work on tree or work on graph”. But I can say with fair confidence that Graph View was easier/faster to implement, so the alternative to its development would have been no new view at all, by this time. I think it made sense to implement graph view sooner.
It is an open question whether such limits are actually beneficial, though I certainly understand the theory behind them. To my knowledge no well-constructed and impartial studies have actually been done to demonstrate how vote limits impact the true accuracy in representing people’s desires for feature implementation priority.
We do have the capability to implement them, but there are some questions to answer, potential problems to solve (e.g. migrating “hearts” to “votes” and how you deal with that if you are moving from an unlimited heart/like approach to a system with limited votes). And while vote limits are common in some user feedback platforms, they are not universal, and plenty of very successful companies do not use them, e.g. ClickUp (using Canny) and Obsidian (using Discourse forums like we do). It is something we will continue to think about. Meanwhile if you have compelling evidence, studies, etc. to share that demonstrate its superiority, please do!
Without getting into the specifics of how this actually works in practice, inside Anytype or indeed any company, I broadly agree with much of what you’re saying. As I said in my original reply, a balance must be struck between individual fulfillment/enjoyment/productivity, and company goals. I believe the team is doing a pretty good job of that lately, but it is also an ongoing and ever-evolving process. And it requires diligence on the part of management and team members to maintain that balance. It may be appropriate for users like yourself to raise that concern again in the future, but I do hope that some increased transparency from the tea, can also help allay some of these concerns that are perfectly understandable from the outside, but also have a good explanation from the inside. The move to open source will also no doubt have an effect on all this in the medium-to-long-term.
I have split this topic off from the original so we can continue the discussion if desired, or at least it can surface these views better for anyone wanting to understand dev priority a bit more in the future.
Very good initiative indeed. Every insider’s point of view about Anytype’s development constraints is welcome.
ㅤ
Could the staff potentially share its main axis of reflexions on this particular subject? Or maybe propose a poll among several UI/UX models? I don’t know if the function exists on Discourse?
ㅤ
My only evidence is both empirical and theoretical and is not based on any studies. There are however several factors that reduce the impact of voting limits:
Lack of randomness in subjects access.
Partial knowledge about the diversity of topics available. Unless you tryhard the forum every day.
But despite these limitations, I am still convinced that voting limits are wise.
Why not propose to the members of the community to make the choice to adopt it or not? Is that too democratic?
As for the problems you raise, here are my solutions:
ㅤ
Do not migrating, let them complete themselves, so the hearts will become what they should have always been, i.e. the equivalent of “likes” and the votes will be real ballots.
ㅤ
One should not confuse correlation with causation. Success is not a guarantee of good decisions, only of decisions that have proven to be profitable and have allowed to establish a reputation.
But to use this argument of authority is to use a fallacious argument.
For example, the CocaCola company is certainly a successful company, but that doesn’t stop them from being one of the first producers of polluting waste in the world and from depleting the drinking water of some regions of the world for the benefit of their product and to the loss of the health of certain peoples. Their success does not exempt them from making good ecological, ethical and moral choices.
Moreover, innovation is not about copying competitive practices. It can certainly be inspired by them but should never feel obliged to conform.
ㅤ
I had well understood the subtlety of your argumentation, but I have to admit that I have a great appetite for debates and bounce easily on subjects that are close to my preference.
Polls exist in Discourse, yes. The primary issues I saw discussed internally were more technical (e.g. “what can we do that will have good performance and make sense given the current architecture”) than design, so not really appropriate for a poll. In any case it would be up to the dev team if they want to solicit that level of feedback. Sometimes they do.
More generally I am strongly in favor of people like yourself - with an interest in the specifics of how a feature might get implemented - creating or participating in forward-looking discussions that can help inform future development when the time comes. I take this approach myself, and some examples that might help illustrate what I mean would be:
or
Perhaps you see that not everyone likes to take this speculative approach by the fairly low participation in both topics.
There is, of course, already the existing Tree Nav discussion topic, where you can add your thoughts on what you’d like to see, and it can help inform the dev team’s process:
I see that you are, but I don’t know why. I’m not sure I need to know why, I’m just saying that your conviction about it is not, in itself, convincing.
Yes, it is indeed “too democratic”, because what matters here is what is the most effective way of gathering user opinion and measuring the relative strength of their desire for particular features and changes. And then how effectively and efficiently the dev team is able to take in, interpret, and incorporate this data into their own decision making process. So ultimately it is something the dev team needs to decide, weighing their own needs and internal processes, etc. against the available options for getting feedback and how useful the feedback generated in that way is to the dev team.
Also keep in mind that user sentiment is just one factor used in determining when and how something will be developed - it is an important one, but one among several, some of which (such as architectural limitations) are more “immovable objects” than user desire.
The problem with this idea (and of course we also thought of it) is that people were under the impression that hearts/likes were “votes” for quite some time (as we in fact told them) in the old forum. So they acted as if that were the case, casting many votes, and the current like counts reflect that. We gathered a lot of potentially useful data this way. If we now change the rules and essentially throw out all previous “votes” by converting them to just “likes”, we lose a year or so of potentially useful measuring of user sentiment on ideas.
Not only that but people are unlikely to go back and re-vote on things, so there will be a strong recency bias in what is voted on. There are literally hundreds of feature requests made to-date, nobody will go back through them all, most will not go back at all, or maybe will go vote on a few favorite features they think of, and this somewhat defeats the whole idea of the limits and their benefits anyway. It biases the feedback, which is definitely something we don’t want.
So I think we’d have to find a way to either convert likes to votes, or to keep the likes and votes but to also measure the likes in some way. In other words the Likes would have to still contribute to any measure of user sentiment on a feature request, even if Likes count for more. That was, in fact, my idea, which was that a “like” would count for 1 “point” in internal feedback weights, and a “vote” could count for more, perhaps 3 or 5 “points”. Then it would make sense that votes were limited and likes were not, and that both votes and likes existed, because they reflect different levels of support. That said, it was agreed at that time that having both would be too confusing, so we have not taken that approach yet. I still think it might be workable, but there is concern about it in the team, and I understand that. If you’d like to put in your support for the idea, I welcome it.
Of course. But you can at least reasonably say that the path taken by these companies (for gathering feedback) has not evidently harmed their intake of feedback management and acting based on it to the point that they are so out of touch with users that their product adoption suffers significantly. Obviously that is a large effect to judge, and the effects of varying voting behavior and rules may be smaller, but then… that’s part of the point. We are arguing about how best to handle votes, and the real question should be: how much does it matter? To what degree will it affect the outcome? If it is small, a difference of 10-20% of “accuracy”, then it is frankly not worth debating endlessly.
Perhaps more compellingly, the way that many entire feedback management systems like Canny work, by default, is to not limit votes. It is, in fact, a very old feature request in Canny’s own feature vote board (back to 2017), but ironically without much support, relatively speaking. Anyway, you’d think that a company whose entire business is essentially taking in and measuring user feedback would have thought about this and implemented it if it was really important. UserVoice does have vote limits, but they are not at all universally applied by customers. Ultimately I am not saying one is clearly superior to the other, in fact I am saying precisely the opposite: there is no clear consensus among experts in the area we are discussing.
This is… an interesting straw man.
Innovation in software design and development is not equivalent to innovation in the process of doing software design and development. One can innovate in the product one creates, but not take some incredibly innovative approach to the actual work. Indeed this is often what is done.
And in any case framing limited votes as if it is some innovative approach to accurately reflecting user sentiment makes little sense. It is first of all a well-known and reasonably widely used approach (though not, by any means, a dominant one), and second and perhaps more importantly in this case, it is how the Discourse voting plugin already works, by default.
I see this now. I’m afraid I can’t spend any more time digging into this at this level of depth, however. For one thing, it’s a time sink, but perhaps as important or more so, I am merely explaining from my perspective what is going on, but these things are not my decision to make. I am trying to help you (and ideally others) understand why some decisions are made, but I am not the person you really need to convince.
And you did it brilliantly. I understand very well the reasons of not pursuing this discussion further upstream, whose subjects have notably come to a very explicit conclusion, thanks to you.
ㅤ
ㅤ
I will definitely dive into your proposals, but concerning this one :
I’m afraid its “TLDR” aspect was detrimental to it
This too may look as a time sink for some. I guess it also helps to see the level of involvement and curiosity people have
ㅤ
ㅤ
Touché! But in my defense your initial statement in relation to the “Vote limits” was
So I haven’t really tried to convince you.
ㅤㅤㅤ
ㅤ
This is indeed a very good compromise. I would love to support your proposal, but you haven’t indicated this topic of yours. Which one is it?
ㅤ
ㅤ
I have corrected what I said about the portraiture of Coca-Cola because I had mistakenly said the opposite of what I meant
Of course I meant to say “Their success does not exempt them from making good ecological, ethical and moral choices.”
I am not a native English speaker and I must admit that the use of the word “straw” in this context puzzles me. The Urban dictionary doesn’t help me either. I guess that implies that the argument is either peremptory or too inappropriate, so to be sure could you please briefly explain to me the subtext?
ㅤ
ㅤ
The Pareto’s Principle proves you right. But usually I would have gone much further in my thinking. Until now I have tried to not waste too much of your time
I think we can both agree that there are some issues that will remain in disagreement, and that’s Ok. As you implied, the whole point is to give more perspective.
Sure, I can understand that. I can only really point out that this seems to me to at least be partly a symptom of good discussions that occur in chat when they should really be in a forum. Nobody else in that discussion on Telegram seemed really willing to move it to the forum, so with their permission I did so myself. But by that time I was responding to numerous of their messages, and my own single post became much longer to include and respond to each of theirs. Whereas if the conversation had occurred naturally in the forums to begin with, it likely would have been a series of shorter messages from multiple different people interacting with each other (akin to what it was in Telegram). I had hoped that the conversation would continue once I moved it to the forum, but it didn’t. But in general I’d imagine a discussion that had originated in the forum might feel like something people were more inclined to engage with over time (being composed of smaller, more digestible pieces).
It was only internal discussion. I will consider whether it makes sense to open it up for public discussion.
Hah, in this case UrbanDictionary is not your friend. It is a classic logical fallacy:
In other words I don’t think your example of Coca Cola is at all comparable to what we are discussing.
I will leave it there with this comparatively short reply.
