Q: What are your top 3 missing things/features in Fibery?

Fibery’s own medium-term (possibly long-term?) goal is apparently to implement functionality such that a fully ProductBoard-like user feedback experience can be built. This will have to involve public, anonymous interaction such as upvote/like/react to Entities/Blocks, and ultimately will also involve the necessity of a Form view. So it’s coming, though as Chris says, it’s unclear when.

I definitely agree with the value of a better view for non-admin users for Spaces, e.g. Configurable Dashboards, and other related discussion in Suggestion for Team Dashboard, and is there a tool for this on the Roadmap?. Personally I think the ongoing conversion of Docs/Pages and Entity Views to “blocks” could address some/most of this need if we could specify a Doc/Page (or even Entity??) as the non-admin “view” that is seen when clicking on a Space. Alternatively just putting a Doc/Page at the top of a Space’s hierarchy and highlighting it with a cool icon might do.

“Docs” (now perhaps moving to “Pages” it seems?) will definitely have embeddable Views (Table, Board, etc.). If you haven’t already seen their public Roadmap, check it out, some indication of pieces of your requested features are on the way:
https://the.fibery.io/@public/Public_Roadmap/Roadmap-Board-5974

Personally the integration of actions and comments drives me absolutely crazy in ClickUp :smile: I get that many people want it integrated, but I’m curious how you’d feel if you could simply add an Activity “Extension”/“block” to an Entity View and position it, for example, right above or below Comments… Would that address your need well enough or do you really need them in the same “stream”?

@Oshyan - its interesting that you mention Productboard, because we use that internally for our product planning and roadmapping. I’m currently evaluating and prototyping a model in Fibery in hopes of getting 80%+ of the functionality of Productboard. It would be wonderful to have one less app in our toolchain to manage.

I agree with you here. Having a doc/page with flexible blocks gives us the ability to craft it into a view that meets our needs (and likely 1000s of others). In the meantime, we have resorted to a read.me doc as the first nav item inside of a space.

You make a great point that sometimes the “everything in a timeline” implementation can be overwhelming. There’s a nice UX pattern for providing users with quick filter tabs across the top of the timeline to show/hide comments, actions, etc. when the timeline has too much going on. I understand your recommendation of an “activity block” and can see the pros/cons of such a block. Though, the flexibility of that specific block will likely cause unnecessary cognitive load for users trying to find the “activity” block because it most likely will be located in different areas. The ideal implementation would be to promote users’ familiarity with the location of the activity feed, regardless of the entity. Here are a couple of scenarios we often experience for which a unified timeline is immensely helpful:

  1. When a user visits an entity page and checks the activity history for changes, the user may often need to inquire about that specific change. This invokes the user to perform a few more clicks to close the activity history and open the commenting pane to submit a comment, losing the visible context of the details from the activity history.
  2. The same could be said for the inverse. When a user visits an entity record and notices a comment regarding a “change” to the record. The user then must navigate to the activity history and scroll back in time to find the specific event to which the commenting user is referring.

Hopefully, you can acknowledge the benefit of users seeing a continuity of events in the timeline, including both changes/actions and comments, with the option to quickly hide/show types of events in the timeline. This, as you mentioned, also introduces a the potential for a lot of “noise” that some users may find overwhelming (hence my recommendation of a quick filter). All things aside, this is one of those features that depend on the way a user thinks/operates. I may be alone in this, but I find significant value in having access to a chronological context of all actions on a record. Maybe I’m just jaded from my days using the FrontApp activity history for so long.

Appreciate your comments and thoughts @Oshyan! I enjoy hearing other users’ perspectives as they’re great opportunities to learn from each other. :+1:

1 Like

Maybe you will be curious to check this article then :slight_smile:

2 Likes

@mdubakov - Yes yes! I have been thoroughly enjoying scouring your blog. It’s been very informative and entertaining at the same time. I greatly appreciate your candor and no BS approach :wink:

Yes, I can definitely see the benefit. And… I’m ashamed to admit, but now that I know there is a quick filter there, I feel better about it all being in one place. What I’ll say is that, maybe it’s a minority of people that would fall into my camp, but the simple fact is I just didn’t see or understand the quick filter for what it was in ClickUp. :smile: I’ve never taken the time to thoroughly read through ClickUp docs, only piecemeal as I felt the need, and this is something so fundamental and basic that in most apps I wouldn’t feel the need to. So I find it interesting I missed it. And again I wonder if this is just an issue for a small minority of people, or if it’s a problem they should solve. The fact that the filter only shows on-hover of an otherwise blank space was for me an issue in its discoverability, however I can understand why it would be like that too…

Anyway, with a good implementation of dynamic filtering (an example for me would be the ability to set the default filter state per-user!), I agree an “all activity inclusive of comments” approach is probably ideal.

My top three wants:

Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type

Merge Comments and References in one common Stream for better flow

In day-to-day use of Fibery, this would make it much easier to see the key activity around an entity, which is when a user takes the time to comment, or refer, to an entity IMO.

Auto-Generate linked diagrams in Whiteboard

I have not used whiteboards much due to the lack of this feature. Just for comparison’s sake, ClickUp can do this with Mind Maps, but it is a much more primitive diagramming solution that Whiteboard in Fibery. Still, if you have tasks linked in ClickUp, they will show up in the mind map as such.

Thanks!

2 Likes

I’m starting to think the merging of Comments, and yes References, into Activity Stream with really accessible, quick filtering might be the way to go? Including perhaps defaults per-Database, possibly.

and of course earlier in this topic:

1 Like

Hey, appreciate the response. I have been meaning to respond to this comment of yours:

I can see where this might not be for everyone, but I actually like the ability to look in on an activity stream around an entity and see all the activity being done - status changed, comments made, due dates adjusted, and in the case of Fibery - references. In the case of Fibery though it’s harder for the average user to see this since you have to hit the “clock” icon and some of my users cannot get it in their head to remember that is what that icon is for. When the activity stream is right next to the entity and “hits you in the face,” you are forced to look at it, and thus see what’s been going on. This is actually useful in my case as I have a lot of project-type db’s and have found it would be better for those juggling multiple projects if they could see the activity right away, because what happens is they will at times go in and repeat stuff that’s already been done around an project entity, then have to be reminded that it’s already in the activity stream. For example, a due date was updated, with a comment as to why the change was made, but another user comes in and questions that because they can’t see at a glance the update in the first place. The original person changing the due date has to go in and comment back, reminding the person of the original change.

If there was a customizable way to display different types of activity on the entity card with quick filtering, so in the case of my request that you cited of Merge Comments and References in one common Stream for better flow, then yes this would be very good! Just to explain the use case once more, with Fibery’s excellent # tagging, which means you can type and reference anything else in Fibery in one click, you get a kind of “shortcut” to making updates when you reference an entity in another entity. An example - I have three tasks assigned to me of similar nature. I comment in the one task that I finished this task, and the other 2 while I was at it. I reference those other 2. If References and Comments were in one chronological stream, the other 2 tasks I did would pick up these references at the “top” of their stream, so anybody coming to read them would see the reference as the most recent update. Now in Fibery, my users are conditioned to reading comments to try to see if there’s an update, because this is the default way you look for updates in just about any app that supports comments - GitHub, SalesForce, Jira, etc. etc. If the reference I just did shows up right there at the top of the area where comments are, they will see that I updated all three tasks in one fell swoop, and you have a very effective tool here that only Fibery offers among all the other apps out there! Right now though, with Comments their own separate element on entities, I can’t get this benefit without having to say again and again to my users to “always read both comments and references on your entities,” but they still don’t do that, I think because it’s simply unnatural to them!

I feel like there is support for this (in the public roadmap among other places) so I look forward to seeing what the team will be doing. Evolving references like this really give Fibery an added edge when looking at the Roam/Notion/Coda environment and pulling together some of what those tools offer in isolation.

1 Like

This is a very interesting and well explained outline of problems and possible solutions, etc. Thanks! I agree at a minimum that Activity History is far too hidden/not discoverable right now. I am warming more and more to the idea of merging it with Comments based on this and other recent discussion.

So I am now particularly keen to hear how @mdubakov and other staff are currently feeling about this kind of stuff. Is their current intended future direction/work along similar lines, or do they have different ideas about how to solve the same problems, or are even still “working the problems” to satisfactory internal ideas. I’d be interested to hear an update regardless of whether such changes would be happening soon or not very soon at all. :smile:

Top 3 at the moment:

  • ad hoc formulas in views - or in fact at least ability to use ad hoc lookups without having to create a separate field. In our project we restrict number of creators, but still would like people to configure their own views (to be able to explore and collect their own insights).
  • history of view changes - it’s pretty easy at the moment for people to override each other changes or to forget (or not even know) who changed what and when. We specifically restrict view management to small number of people - which can be difficult as it is creating bottlenecks, but the alternative is too much chaos.
  • paginated search (or an equivalent workaround) - with a lot of content and some frequently occurring keywords the limit of 60 search results is well… very limiting (especially in the context of product management)
1 Like

It sounds like these two things are somewhat in opposition, no?
Would it make sense to encourage users to create whatever views they would like in My Space, but not allow views in other Spaces to be changed?

seems like a sticking plaster fix for a fundamental challenge with permissions.
It wouldn’t stop people from messing up shared views, only allow you to retrospectively attempt to revert changes.

1 Like

Perhaps I wasn’t too clear - that’s exactly what we do now. When I said “would like people to configure their own views” I meant “My space”. And when I said “we specifically restrict view management to small number of people” - I meant global workspace.

Ability to configure views in “My space” is unfortunately only limited to whatever fields have been exposed to them.

In the context of my team doesn’t seem like “sticking a plaster fix” - that’s exactly how software version control works. You have collective code ownership with ability to see the history of who changed what when.

History of view changes does stop people messing up shared views - as when I notice that my friend John added a column yesterday I can go to them and ask what is the purpose of that column. And even so - I wouldn’t downplay ability to retrospectively reverting changes - as knowing who removed “my favourite and the most useful column” is a pretty good start of a conversation (compared to not knowing who might I need to talk to).

I understand what you’re saying, but I guess I don’t see views as being analogous with source code. I can see why seeing the history of an entity is really useful, but I would hope that views would not need regular changes/updates in the long term.

When you say, “added a column…what is the purpose of that column” do you mean, “added a new field…what is the purpose of that field”?
Or do you really mean column?

Because, the way I see it, showing/hiding a particular field may come down to personal preference (for which My Space is a great solution).

Whereas if someone truly thinks a new field is needed (e.g. a lookup) then should your friend John be allowed to do this? Limiting this capability to Creators (following suitable round table discussion if needed) may actually be advisable, otherwise the database could get ‘polluted’ with loads of fields of which only a small subset is actually used/useful for any given user (though not necessarily the same subset).

Perhaps this is related to the idea you were getting at with ‘ad hoc formulas in views’? If this means something like ‘per-user fields’ then that’s a really interesting proposal :thinking: but I’m not sure it would be on the radar any time soon.

1 Like

Ask me tomorrow and maybe it’s different! But tonight at 2100…

  1. ability to write dates in fluent formats (e.g. tomorrow at 7, 1h tomorrow at 1300, etc)
  2. ability to watch an entity (and not be assigned to it)
  3. ability to visualise permissions (currently a black box)
2 Likes

Have you taken a look at mu Tripetto SDK recommendation?
If this was integrated, much in the way Viziydrop was integrated, it would be an incredibly powerful way to create interfaces and conditional logic in data entry.

Many of us end up using apps like JotForm and Typeform just to get around the interface of apps like Airtable and Google Sheets. A robust form creation & chatbot app covers a wide range of uses.

2 Likes

In general, I think a meta layer is important: describing what fields are for, how tables fit together, etc. I.e. it should be possible to make structures in Fibery directly self-documenting (i.e. not in a page talking generally about the workspace, but directly on fields etc.).

3 Likes

Asana’s My Tasks view allows you to organize your assigned tasks in a way that makes sense to you. It’s one area that’d be a downgrade if my team moved from Asana to Fibery, so I’d love to see something equivalent supported by Fibery.

Within My Space you can create views of Tasks (or any other data) in whatever way makes sense for you. I’m not deep into Asana, but I don’t immediately see anything that’s not possible in Fibery in this regard.

1 Like

Here’s my current My Tasks view in Asana. The board lanes (circled in orange) are private to me, and they aren’t part of the tasks’ public fields nor any projects. In Fibery, it seems like I can only pick public fields as board rows or columns.

Board lanes in Asana are just groups of tasks (called sections), not assembled from a task field, so its implementation is probably simpler than per-user fields.

Screenshot of the list view of My Tasks, which is grouped by section

Per-user fields would still be useful for adding personally meaningful marks to tasks. I use the FVP method to choose which task to work on when it gets overwhelming, but since that kind of workflow isn’t supported by Asana, I write down my task list in Notion to be able to attach marks to tasks (which involves just prefixing task names with a dot ‘.’). This particular use case could be doable without a full-fledged per-user fields: allow users to favorite entities with a shortcut key and make favorited entities visually distinct.

1 Like

Well, the images you show (putting tasks into groups that you define) effectively imply per-user properties. I guess you could call these ‘fields’ or something else (folders, sections, groups, tags) but either way, it’s not something that’s in the works, sorry.

However, Fibery does allow you to mark items (or views) as Favourites, and they will show up in your Favourite section, as well as being indicated with a star.