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

[calh-fsp]

@Oshyan

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.

@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.

@Oshyan

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.

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.

@Oshyan

Personally the integration of actions and comments drives me absolutely crazy in ClickUp 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”?

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.