Ok great, thanks for all that and the clear discourse (no pun intended ), you are a real master of this forum!
For myself, and potentially colleague @Matt_Blais, patience is a problem as working hours in Fibery a day, which I am now doing, as are most of my team, these quirks are borderline debilitating. For example the one I just mentioned with the odd behavior of the cursor when typing. I’m not exactly feeling confident, sorry, when we have not a lot of detail on many of these things getting fixed, and in reality the quote in the blog post was ended with “bs bingo.” How confident do you really feel the team is going to take this stuff seriously? I am glad for a lot of feature releases like action buttons and impending Automations, huge stuff, but I’d like more detail on what “polish” really means. There are a host of these funny issues kicking around this forum without much attention by the Fibery team. I develop software so it makes me wonder what is taking so long to fix this particular issue with the home/end button, it shouldn’t be that hard, unless what Matt is fearing about some underlying issue with architecture is indeed the case. When Polina says the “backlog is too big” is this of all the quirks, etc. we talk about in here a lot?
From my experience @Oshyan points are spot on. Indeed rough edges can turn people away, but they are here for something special that do provide unique value that overweights the problems. Roam is a good example, since UI-wise it has many rough edges, but the value (connected blocks of thoughts) is just huge so you can live with other quirky things. To be honest, the core Roam UI is very good and easy to use, you should just get the concept right.
We are indeed struggling to show the real value of Fibery to companies, since you have to have 3+ processes connected to feel it, and that is not so easy to do right away. We are learning how to demo Fibery better and how to explain it better. But when it clicks, retention is very good, since you are not ready to loose all these connections and flexibility in exchange of a more polished tools.
So our top problems as I see them are:
Better getting started experience (we’ve added ready connected workspace with familiar domains and it works to some degree), but there are many things to improve here
Core value functionality (Blocks in entity view, better connections better bi-directional links support)
Side functionality that impedes adoption (permissions, users management, etc)
Polishing and quality improvements.
I’d say we are still focusing on 1-3 more and 4 is a back-burner, but as I said earlier we are committed to make the change really soon and focus on smaller problems.
I hear you. If “having patience” only needed to start today, I imagine it would be easier, but I understand you’ve been having patience for a long time now. Nonetheless it does seem as though some focus will be put on polish, which would mark an evident shift from previous priorities (though Michael’s message below shows that they have not yet shifted to focus on polish). It’s one of those frustrating moments where of course it would have been better to have this stuff done sooner, but it wasn’t, that can’t be changed retroactively. So here we are, and if it is indeed worked on soon, it will be something… and hopefully enough to help you guys feel better about Fibery’s long-term place in your orgs.
This may be an unwise thing to point out, but I can’t help but call it as I see it, too, and it speaks to Michael’s points below: you are talking about the issues with retention due to lack of polish, but you’re still here after over a year (I know that has never been and remains now not a given), and so are many others who nonetheless express their (understandable) frustrations. So your own case(s) demonstrate that Michael is right: once you get the value of Fibery, even though there are frustrations and non-ideal aspects, it does something that no other tool seems to do, and so it has some stickiness, despite even daily annoyances.
That is not to say that these issues of polish should not be improved, only that I do understand their priorities to-date to some degree. A high degree of polish is not going to translate into tremendously greater income for them, while developing and communicating their differentiating factors might. But as I’ve said before in this thread, it’s important to have balance, to indeed put some real time and effort into polish sometimes, ideally on a regular basis, even if features must still take priority. So the polish phase seems to be where we are now, fortunately. Later than you and I and others might like, but I’m still glad we are coming to it soon.
I took that to be Fibery/Michael’s typical irreverent wit, which I’m sure you’re familiar with now. But indeed in a situation where you already feel frustration and lack of confidence, this kind of approach can feel a bit flippant or tone-deaf. I get it. Still, I do not think it would be mentioned if it were not a sincere goal.
It is of course mere speculation on my part, but when I look at all the team has shared many times especially in the last 6 months that shows their issue and feedback lists, backlog, etc., it is clear to me that they do have a very big list of requests, and most of those are not the polish issues we’re talking about here. There is little that can be done about a genuinely big list of features and goals when money is finite except to just keep chipping away at it.
Michael has been fairly clear up until now that polish was not the priority. He may feel Fibery’s experience is more polished overall than you or I, but I think there is a clearly communicated understanding that some focused work is needed in that area, and will be started soon. I feel like I’m getting apologetic and repetitive though, so I’ll stop here.
Yeah, I saw this poll on Twitter. Interesting, to be sure, but I wonder if there is some variability in what people define for themselves as “quality” vs. “usability” for example. Since there is such a wide margin between those, it seems important to know what they mean, more precisely. Would you say things like this thread topic (home/end button issues) fall under Quality? Or Usability? (I am guessing the former)
The other thing to note (and remember, I recognize the difficulty of balancing features vs. polish) is that this is from a relatively small sample size which may also have other bias. Unfortunately it’s hard to be sure what that bias might be. But for example it may be that this is largely from non-users, who see the promise of Fibery but are missing some features they require in order to fully adopt it. Maybe they’ve tried Fibery and it seemed of good “quality” (and it is, overall), but they haven’t used it enough to run into some of the smaller but persistent “quality” issues this thread is highlighting, which only really become greater annoyances once you are using Fibery daily.
Doing an Integromat poll of actual users would be an interesting adjunct to this informal Twitter poll…
Whenever I run into issues like this, in components such as text editors, markdown parsing, dropdown widgets, etc. I worry that the developers are spending time reinventing the wheel rather than focusing on the essentials of their tool. There are such excellent components available these days that I would love to find a reference to the component used, so that I have complete documentation, know that my experience transfers, know that there is an extension ecosystem etc.
I think @B_Sp is in a different phase than we are, so I have a different opinion here. For the phase Fibery is in, I’d suggest capturing these kinds of issues into their own little backlog and assigning some low, fixed resources so they aren’t just not addressed at all, but at least the most egregious ones are being fixed over time. I think transparency is important though, and hope that in the future Fibery can help here. For example, just seeing these key buckets of work and what is prioritized would be majorly helpful. This brings me to my suggestion on prioritization
I’m an advocate for lean product management that talks about thinking of the user journey and building end-to-end slices across the full journey as iterations. Even as an advocate for the features listed out as “Core value functionality”, I would just suggest that before reworking or improving what does currently work now, that there needs to be an initial version of what I’d call key-features for a small product team in a larger organization. The reason I say small product team is because most of your potential users are going to have to build confidence in the tool themselves and then with the broader organization. Currently, I do not think fibery is key-feature-complete for this audience, meaning there is a version of each key feature within Fibery. There is always going to be a lot of friction until that is the case. What I see as the key features with my notional assessment of maturity (1-5):
Missing: fibery cannot gather input from external users/stakeholders
For a small team that is exploring or starting with fibery, it is easier to think about users/stakeholders as all being external. Other parts of the organization don’t want to have to learn how to use a new tool that is being explored. Fibery must be able to accept external input without 3rd party tools (basic shared form view)
Power users can work around this, but will require some non-insignificant technical skills
While there are little issues here and there, fibery is among the best at connecting information together through direct relationships, backlinks, etc.
A big component of consuming all this data is there needs to be effective ways of classifying it. It is currently difficult to manage many to many relationships and to associate multiple items with another easily at once
Full automation I expect to really help with connecting things together and implementing more consistent processes
Pros: a decent set of views
Limitations on what fields can be used in certain visualizations causes a lot of friction when modeling your data
Effectiveness of multiple visualizations is hampered by the ability to effectively present the content (text being cut off more than needed).
Apps and smart folders definitely help with organization more so than the blank canvas of some apps (notion, coda)
New users still feel overwhelmed and don’t have a true “home” place to go work on stuff without potentially impacting others. A higher-level organization into the apps isn’t very easy to provide. I feel like ClickUp does exceptionally well here for giving each user their own space to start from and personalize
Integrations are all one-way, so any data you augment the synchronized types with needs to be able to be shared from Fibery externally
Views cannot yet be shared externally and there are no read-only users yet (i know these are coming)
Search is pretty good, but sometimes you can’t tell the different between items with the same name
There are things like comments that aren’t indexed yet, but overall search is quick and works pretty well
Audit logs are pretty comprehensive for a tool at this stage
Permissions are at the app level, so pretty coarse
Personally, I feel like it is so immature in what i define as Gather, Visualize, and Share that it is no surprise that the “Getting started phase” is a challenge. Focus on the end-to-end demonstration of getting external data in, visualizing it in different ways, then sharing it externally as the starting point and I think you’ll have a more compelling value proposition to build off of. I’m sure I’m missing some stuff here, but this provides my personal feeling of where the pain points are for our small product team.
Your feedback resonates with me. Let me provide some comments
Indeed Form View in our requests backlog is in top 10, but we are still dragging its implementation since Zapier + Typeform is a possible solution. I do agree that it is not super simple though,
Yes, it should set relations based on rules and solve many cases here. We expect to release it really soon
That is our recent insight as well. We are starting “My Space” design/implementation this week, so people will have a place to in Fibery that it stable and private in near future.
This is what we are working on right now.
Overall, I think your evaluation is mostly correct, but I’d give Visualize at least 3 out of 5 and Gather 2 out of 5 (since you can capture feedback from external tools and there are workarounds). And we are addressing almost all these problems, only Form View is not planned yet.
This is a really nice outline of your perspective on Fibery’s status in major functional areas. Well done! Without giving it more thought I don’t know if there is anything significant that’s missing. But it’s certainly a helpful overview and model to use to consider where the product is now and where it needs to go.
In general I mostly agree with your evaluation, with one exception, which Michael also mentions below. You put Integrations only under “Sharing”, and I can see how it would belong there. However its inclusion there - while justifying a 0 (one-way sync) - misses the significant value that is being provided by the integrations already, which I would probably classify under Gather.
The reason why I think there is more value being provided here than is accounted for comes down to Fibery’s unique ability to mirror the data model of other apps. There are plenty of tools that integrate with e.g. Github or Intercom, or whatever else. But few - if any - of them actually let you incorporate, interlink, and act on the incoming data in the powerful ways that Fibery’s integrations allow. Of course there is the one big missing piece, which is bi-directional sync and being able to perform actions in Fibery that control the remote system. This is super important.
But from a “Gather” perspective, the existing functionality actually goes beyond what many other systems provide. For example the Intercom integration is actually a huge “gather input from external users” feature since Intercom is widely used by product teams to gather feedback. So it seems that your “Gather” rating is based more on one specific type of input, and an important one, but far from the only one, and Fibery handles other types of input well (Intercom, Discourse, and more).
Overall I think your model and ratings ring fairly true and show a pretty good picture of why adoption may still be challenging for many users and teams.
Yeah, I agree that integrations have their place (or could) under both share and gather. The mention under share was to point out that without 2-way integrations, you have to share the views externally one way or another. I was also implying the integrations/APIs would be leveraged by “Power users can work around this”.
I didn’t make it completely clear, I approached this from the standpoint of a small product team evaluating fibery for the first time against other options. They are going to be thinking about things like not only “can i integrate in what we are using now?”, but also “how much work will it take to maintain?” and “how can I show others how great this is!?”. There is an API and some integrations. However, if you pull in data from the existing integrations, it isn’t clear how they should/could be used or integrated into the native Fibery Types. In general, it feels like the ones that Fibery doesn’t personally use are pretty rough around the edges and haven’t been setup in a way that demonstrates how they can fit into the end-to-end flow. For example, utilizing Epics from JIRA is a mess.
While I 100% agree with pushing off functionality due to workarounds when prioritizing, I was trying to point out the relative maturity across the core capability areas a product team will expect. If you just look at little issues that your active users have, it ignores the challenges and reservations that exist for the non-early-adopter type group. Having integromat integration is great for the person that has bought in and are ready to fully build what they need. However, it would make the end-to-end value proposition difficult to understand, experience, and demonstrate for a new user/team trying it out for the first time.
You just don’t want new users to hit high friction points or roadblocks in that early phase and right now gathering and sharing are roadblocks. Fibery has zero capability in those areas without the use of an external service. There is no guarantee a new potential user has the permissions to setup an integration, so now they have to think about that. They maybe don’t have experience with Zapier or Integromat, which can be somewhat complicated to utilize in some cases. There is super great stuff that will provide great value to product teams within Fibery, but it is hard to demonstrate the broader value at the moment without significant effort.
To me, this is what would be amazing to demonstrate to a small product team:
Look, you can share a page with your users/stakeholders to receive input into Fibery. Watch as I submit this bug that references specifically our Mobile App. Already use an external service for collecting input? Great, we can pull that in for you, or you can get rid of it and save some money With Fibery, you have an instant custom form for everything you work with, which are always in sync with your data.
Remember that bug you submitted for the Mobile App?, here it is in your bug reports kanban board, grouped by channel and state. It is already associated with the Mobile App, and the App engineer was automatically notified
The Mobile App engineer commented on the ticket, noting that this was fixed in v1.0.0 for the Android app in ticket #10, but seems to be an issue for older IOS versions. In the comments, he captures a Task to make sure the testing process is updated to include the older version in the future. (This is where you show how all this stuff is tied together)
It looks like our Mobile App engineer has pushed a fix for Mobile App Release v1.0.1. Any users subscribed to updates on the public Mobile App update history page will automatically be notified or they can review it anytime with the rest of the update history
Your users can then follow the link to your public prioritized roadmap and comment/vote on the planned Features
You can see that this use case is focusing on what Product Teams need end-to-end to make their life easier, rather than just the current Fibery experience. While this devolved a bit, the whole point was to say I notice the small things as well and don’t want them to get lost, but there are major holes in base functionality that I hope are filled first.
Yes, great points and I thought the same. I don’t really give much credence to this poll, and I think it’s a shame it’s being put forth here almost as an affront to this whole thread. I don’t use twitter, and I’m not about to sign up just to vote in that poll, so you have one concrete example (myself) of a user who’s voice was not counted! And agreed, how do we know if twitter users are actual Fibery users who would indeed be concerned with usability? Also, I’m not sure where to draw the line between features and usability? As you and I have discussed, a lot of the usability issues in Fibery are around notifications and communication. But much of what I would like improved is definitely additional features that are missing, like quoting comments.
While I agree with most of your reply here, I just want to highlight that I think this is an unfair interpretation of why Michael posted that. It’s data. It’s something relevant that they tested. It adds information to the conversation. He presented it without any other kind of apparent (to me) criticism or bias. I know you are frustrated and your reasons and needs are valid. I just want to caution you to try to avoid interpreting potentially neutral things through a negative lens. I could of course be wrong, as well.
I still think this is ultimately what will lead to friction, or i guess mitigate it. We know there are lots of usability issues, but if anyone should be able to communicate what issues have been captured and how they are prioritized in the grand scheme of things, I’d hope that Fibery would think that is important to be able to communicate. The lack of the ability for Fibery itself to provide that is what I was highlighting. Otherwise, we don’t even know if an issue has been captured in many cases, and you have to bump discourse threads for updates on status.
Always good to get your input! However, I think we’re going to disagree on this one. That graph was dropped in this exchange with no commentary whatsoever. Reminds me of sometimes getting an annoying text from somebody with an image only - the old “I told you so.” I think it’s here expressly to point out that Features, not Usability, which I am asking for, is the desire of the “community” - and of course that’s a twitter poll, not one here in Discourse, which is convenient because it’s specific audience asked the question, one that has a different dynamic. Michael could have easily added some of his own commentary, but he didn’t. Maybe he will now in another defensive response to me, and then go on a storm of responses to unaddressed requests, which again happens periodically in response to a “complaining” post I make. Perhaps we’d get some acknowledgement of a series of unaddressed requests in this forum such as the one regarding quoting! , which you and I have discussed; is a fundamental of most competitors; and is a real pain in Fibery - have you tried to consistently use the “quote” functionality around text, in comments where it’s most needed?
@oshyan and @Matt_Blais are echoing my sentiment. I don’t think the regular WIP in Twitter, and some more discussion in a monthly blog, is near enough, when there are hordes of unaddressed items in this discourse forum which Fibery itself encourages people to use!
This is so true! I have spent so much time trying to keep track of unaddressed requests so I can try to bump them, but over the last year or so I have all but given up as most of them remain dangling in the wind and it’s just a waste of time to try to get Fibery to address them…
There are a few requests guys about getting a proper voting / feature ranking system in here
Of course, the Fibery team hasn’t bothered to consolidate them, so I’d suggest voting on both. Not that you’ll be able to know how much influence that has, since we have no clear guidance from Fibery about how they count votes in the forum (is it “hearts” on the initial post, or total within a post?), although it’s been asked that they address that.
And perhaps continued voices in the community will help move this agenda along, because Michael has decided for now that he won’t accept “raw votes,” even though many world-class tools use that measure.
I agree that we are not doing good enough things about the problems/backlog transparency. We are quite good at large features/requests consolidation though and here we have a good understanding what’s important and what is not.
The real problem is in aggregation (and it is tricky). Now we have ~800 open bugs. Should we fix all of them? Not at all. Chrome has 10K+ open bugs and it is a great piece of software. How to decide what bugs need to be fixed? Sometimes it is easy, like an obvious critical issue that blocks the flow. Sometimes it is not so easy. In theory, we can show a whole backlog with 800 open bugs, 200 user stories, and 100 features. But it should be synced with Fibery, so we have to implement some kind of portal that has limited functionality for external users (like add comments and votes). We have this in plans, but here we are waiting for better permissions management, they block this feature implementation.