Chris, thanks and no apologies necessary. You deserve a medal for the work you do around here
Your solution is also useful and something we may like to have to just see how long a task has been in its current state (I believe that’s the intent). I was looking to try to keep a record of how long something is in each state, as I think you gathered. And my point is that this could be done with a range of hidden formulas fields that would be invisible, only surfaced in a Vizydrop that would access that data to create the report.
There are probably tons of other uses of hiding fields which just serve to make calculations. I know when Notion revealed their ability to hide those fields, they made a big deal out of it, and rightfully so as it’s a very useful feature. Especially with Field Proliferation a real issue to deal with in Fibery for the moment.
I just happened to be revisiting this discussion, and I realised that the CFD charts that are now available in reports would somewhat satisfy the need to
We’ve had a need for this too in our company, mostly with a particular Type of ours; product order.
Already we have plenty of Fields. Some Fields are utility fields for other Types or Fields (which uses them for filter/sorting/calculations), some Fields are used for all kinds of orders, and some Fields are used on most orders.
Having to create different order Types is not a suitable solution either. We have category and then a subcategory of products. The Fields would even depend on the subcategory. There’s also no way to have some sort of wildcard Field that can show links from many Types in one Field.
There are other things (e.g. specifications) we wish was a dedicated Field, but they’re only used for an order of a specific product. This means a condition is met to determine if a field is useful to show or not. Therefore most of the time they’re useless and adds to clutter, and instead we have to write them into the description field and highlight.
If you insert new fields from a custom view, do you mean that these fields are only available in / associated with that view?
Or are you actually just creating fields for the type itself?
The former sounds a bit like subtypes, which has been discussed elsewhere, with pros and cons of course
I was thinking more of static UI elements like text and images, or Views; I guess “fields” is the wrong nomenclature. Except for Buttons, which would belong to the Type.
The basic idea here is to expand the concept of “multiple views” to include Entity views, not just Type views (collections).
Much of this has been discussed previously and I believe many aspects you mention are planned in some form. Overall I am interested in similar capabilities long-term.
And I can’t help but wonder again how this conversation would be unnecessary if this board had some basic feature voting, or at least organization of features. As it gets older, requests are starting to proliferate that are the same.
As far as I can tell, here in the Fibery community the only hope to avoid duplication of requests is reliance on the Discourse native search: it will suggest that you are repeating a post as you type a new one, and you can search the forum for something you are about to post, and possibly Discourse will return the request if it’s already been made.
But as requests proliferate, repeat, and have unclear weight and visibility, I think the flaws of the reliance on Discourse’s search as a means to run a proper Feature Request Forum are becoming more evident. Compare this with the clarity you get with tools like Canny or UserVoice, which can do things like show trending, popular, recent, etc. requests. Not to mention some basic categorization of requests. I mean here in Fibery we have a category “Feature Requests” which has double the posts of the next biggest group - Bugs - and within the Feature Request category - zero subcategories! It is getting messy. On top of this, there is an unclear and inconsistent manual process that the Fibery team undertakes to edit posts with a status, further adding to confusion about how requests are really handled. At the very least they could publish an article defining what the statuses are, and what they mean, like Wrike does.
I, for one, am starting to lose steam when I come in here and see, more and more frequently, the same requests being made anew. And, the only thing tying them to the existing request is when good samaritans like yourself or @Chr1sG taking their own valuable time to try to merge or reference old requests. Other tools have staff that puts in time and monitors forums such as these to vet requests, merge, and communicate with posters about the existence of similar requests. The Fibery team does not do much of this. They respond here and there, but I have seen very little, if any, activity of them merging requests, or referencing similar ones to each other. I think hands down both you and myself have tons more posts in here than the combined Fibery team that link to repeated requests, try to bring similar request into one post, and so on. And ironically, we are actually leveraging some of the features of Discourse that that also make Fibery shine such as auto-linking, highlights, and others!
Fibery made the choice to use Discourse to track Feature Requests, and Discourse isn’t designed to do that. But since they made that decision, I expect more involvement here from Fibery directly to keep these repeated and concurrent discussions organized.
To that point, here is what Discourse is about:
On that page, you do not find the word “feedback” or “features” anywhere. Discourse is not designed to do what most of the people using the Fibery community - as evidenced by the huge disparity in post volume in the “Feature Request” category vs. all others - are trying to use this community for!
I really hope Fibery will rethink the way they publicly handle Feature Requests. Where would you rank Fibery in this regard among the tools in this list?
As a tool that is presenting itself as a Product Management and Feature Prioritization leader, I feel like Fibery needs to do this better than anything else in the market. Do you think that’s the case?
I don’t really feel like Discourse is non-functional for managing feedback, but I agree it needs more hands-on maintenance to work ideally. Canny and others arguably also need such maintenance to e.g. merge similar/duplicate feature requests, etc.
We both agree that the addition of a “vote up” plugin here would be nice, but that may be somewhat mitigated by Fibery’s own direct support of Discourse, depending on how the interactions here are ranked. I know you are frustrated by how opaque that is, and I don’t disagree that I’d like to understand it better. But ultimately I do have some trust in the team that they want to understand real usage and feedback as much as possible and they do a lot of deep thinking about development processes, prioritization, etc. (as evidenced by many articles in the blog), so I have to trust that they are choosing sensible approaches to incorporating feedback, even if I don’t know the details.
I also don’t mind contributing to organization and interlinking here, as time allows. And while I agree it is the company’s responsibility, I also know resources are tight for startups. Since I want Fibery to succeed, I am willing to trade some of my time and energy to try to help that in ways like this. Certainly it should not be an expectation on their part that anyone but them do so, but I don’t think it is. That said I also think they might benefit from empowering a few people here as mods, with thread merge capability, which might help keep things tidy. But I can understand them not wanting to do so.
Things are imperfect, no doubt. Improvements could be made, and hopefully some will in time. I tend to feel like there are some compromises that are difficult to avoid at this stage. And I’m still glad I’m here and not with Notion. Would I like to see ClickUp’s pace of development here? God yes. But they’ve been at it longer, have more funding, etc. And so far they haven’t actually introduced the functionality I need anyway, which are the powerful arbitrary Types and various kinds of relationships, among other things. So here we are, no better place to be for me, even with the frustrations.
What you can’t see is all the times I started to post a feature request, but canceled it because Discourse found a pre-existing one that matched. But yes, all your points are good ones.
Yes, it does work the search, but I think the use of it here in the way the team has structured its Discourse instance to track Feature Requests is in and of itself limiting. What I mean is the requests are organized the right way - distinctly in groups, or merged so we have less duplicate posts. Or, we could have something like guidelines from the Fibery team to limit your Request to just one feature, and if somebody comes in and lists a bunch in one thread, a mod would need to merge that to the relevant existing requests and delete it. This way, Discourse’s search can be used to its fullest.
The problem with the way this Fibery Discourse is set up is you don’t really have anything close I think to a Canny-type approach. I’d be curious how you think Discourse is functional at handling specifically Feature Requests, not general “feedback” which is what you mentioned above - although maybe you meant the same thing?
At this point here in the Fibery community, we have one mass of requests all organized in one category, growing by the day. There is an unclear way to see what is really being worked on. It’s up to the users to connect what’s here in Discourse, with the WIP’s published in Twitter, and more abstract discussions in the Blog, to figure out where their desired feature is on the list, like this one simple feature that remains to me a mystery as to whether we’ll ever get it:
I have been here over 1 1/2 years and still many, many key features remain unclear to me as to where they are in prioritization, or whether they will be done at all. I just don’t think these fragmented sources of info on what’s being developed in Fibery are easy to figure out, and overly helpful to paying users who are in pretty desperate need of some of the stuff that’s missing in Fibery.
I do agree as I just wrote that Discourse has great search, and in general it’s a market leading suite for managing communities. If Feature Requests were outside the realm of that scope, that would be one thing. But they are entwined here with all the other, more typical community areas like “Ask the Community” and “Share your App.” In fact, I continue to hope that Fibery will present a way to manage Feature Requests via Fibery directly, including a public-facing Feature Board, which is a key piece of Aha and ProductBoard that they are clearly going after. And then dogfood on that, leaving Discourse here as a true community piece.
Now that we have Voting in place, it becomes more important to merge similar/same requests together so people can properly distribute their votes (limit of 10 per person!). So I think this thread here should be merged with this earlier one:
This time I’d like to suggest some abilities around limiting views of fields in entity views. Here is what is on my mind:
A cornerstone feature of Fibery that has attracted me is the deep linking and visibility between entities across the Fibery app. However, my use calls for free linking between any entity in any app, to another entity. Right now you have to specify which entity type you want to link to another. I know @mdubakov you’ve mentioned that the ability to choose an entity within an app is in the works, but this is also limiting.
So in order to accommodate my need, I am having to set up links to certain types of entities I’d like to be visible to any other, within those “destination” types. So in my case for example, I have an “idea” entity that I want to relate to practically all other entity types in all Fiber apps. I am going to create a relationship to “idea” in each of those types. This is not only a lot of work, but also as I build this out, I have some types with relations with 8 -9 other entity types, as I may need to link those at some point.
This has led to some clutter in those entity views, and my team and provided me some feedback that the views are getting busy and hard to read.
So one solution I thought about was if it were somehow possible to minimize, or mask, non-used fields, particular those with relations, if there is no relation present. One idea would be to minimize those so that just the name of the relation is showing. Fully masking those fields would basically block the user from adding the related entity, but if they were minimized, and could be easily “opened’ back up so an related entity can be added, then I think you’d gain a much superior view of the task details, but also maintain full ability to do relationships as needed.
@B_Sp It would be great to see a screenshot of entity view and a screenshot with the whole domain. It will help us to get the problem better and maybe even advice something
To preface re: my domain, I am in big experimentation mode, so this is not my intended set up. I will say that I do intend in fact 20 - 25 apps to represent the entire needs of my team/organization (we develop websites and have an SaaS product), so things that aren’t here yet include:
Feature tracking/feedback from users
CRM
Content planning
OKR’s, Goals
Marketing
HR
and others
(and I hold out high hopes that Fibery will build to the promise of Burnout, which would appear to incorporate much of this stuff in a true “Single Source of Truth” solution I am really hoping you guys can pull off!)
Now, what I’m trying to do is have the ability to talk about just about anything in the domain in a meeting. Do things like create interviews for HR candidates, note a new idea for a new partnership, flat up a bug, take notes on a new section of a website we’ve thought about, or put on the agenda for the third time this week to make a decision about which laptop provider we’re going to use.
I am using a “meeting” type to represent the actual meeting. I hope later to integrate with a calendar solution, and track time for each team member present when you guys have those capabilities. In the past we used Confluence for team meetings, and we’d have a table in the Confluence doc for each topic item. But once the meeting was over, nobody would read the notes, and things that didn’t get solved would get stuck in that particular Confluence doc, disappearing into a blackhole. I realized that if my meetings consisted of topics that were actual entities, you could have a chance to not lose site of these if they were not covered in a meeting. And by attaching, in the case of Fibery, various reference items that would be types to these “Agenda Items,” you’d have a really good system with some good benefits:
ability to quickly build notes in a meeting by quick adding entities to the Agenda items;
the “Agenda Items” live on their own, and by linking each to the entities, you can always see decisions about entities right in the relations area
the meeting note itself has great context as you can see the Agenda Items as live entities, with status, so if you decide in meeting that an Agenda Item is “for future consideration,” in another part of Fibery you can have those topics assimilated in a board for easy reference. In Confluence as I say they will disappear as random sentences across many docs.
So ideally I’d like to be able to link anything from my domain above to the “Agenda item” I am describing. I have a Type called “Agenda Item” that represents these in Fibery. But since I can’t link to any entity in Fibery, but rather the relation has to be to a certain type for now (eager to see “Polymorphic” when released!), I have to create relations for all the types I’d potentially want to discuss in a meeting. So this “Agenda Item” type looks like this for now:
In a lot of cases most of these fields will be empty. The main reason I have so many relations in the first place is to have the flexibility to relate, if needed, to anything else in Fibery. So with Polymorphic relations allowing me to reduce to just App relations, and not each Type in an App, or even the ability to relate to any entity across Fibery, which I think would be great if you guys release that capability, I wouldn’t need to have all these relations.
Hey guys, sorry to reply to myself, but would be grateful for some insight here. If it’s easier feel free to Email me. This issue is very closely related to my other request of Reciprocal reference when using "/" commands in entities. Would be grateful if you could respond to that, too, as I assume it’s on your radar, and when you implement that is really key to my continued hesitation - although getting closer all the time! - to bringing my team over to Fiber.
The reciprocal linking is also missing in both Coda and Notion, would be terrific if you could beat them to the punch with this. And just to repeat again (sorry!) why this is so key to me, your excellent ability to convert stuff in a rich text into an entity is missing a “2nd half” until the linked entity gets an auto-reference back to the entity where it’s referenced in the text field. Basically exactly the way Confluence and Jira work together for those familiar with those two tools.
Thanks guys and eager to see you get back to moving things forward this year! Been missing the updates!
For example, I do not need to view some fields in the entity card (mostly it’s calculated fields), because there are used only in the list or in reports.
Would I like to see ClickUp’s pace of development here? God yes. But they’ve been at it longer, have more funding, etc. And so far they haven’t actually introduced the functionality I need anyway, which are the powerful arbitrary Types and various kinds of relationships, among other things. So here we are, no better place to be for me, even with the frustrations.
