I wonder if there will be a way to nest documents inside each other. I’m used to using Notion so creating a folder tree for all my documents makes sense. Is Fibery intending not to have docs be able to be hierarchical?
Nevermind, I guess the intention is to use the Folders to achieve this?
Yeah, honestly I find Notion’s approach to be easy but suboptimal. Having a folder “type” makes perfect sense because often you just want a container for other things. Notion has no concept of this. Not to say Fibery’s approach is perfect, but in terms of conceptual approach I think having this more clear distinction is beneficial in general.
1 Like
I actually have taken this to another step and as I moved along in Fibery, I have abandoned the use of Docs entirely and just use Entities. If you look at Docs, they really have no content that isn’t in Entities, in fact Entities can expand more elegantly with the “Reader view” and you can write more freely within them.
All you need to do is create a Type for the type of Doc you want to house in the Entity, and then configure it accordingly. Need Assignees? Add them. This Type then becomes a “Folder” of the Docs/Entities. It’s the same as a Table in Notion.
I will say that I could never get comfortable with the idea of using a Type called “folder,” which used to be one of the templates when I got to Fibery last year, but I think it’s gone now.
I think this is very true:
In that Fibery is still a bit “confused” I think about what to do with the concept of “Doc,” when in reality it’s enough to remove it in my opinion, and just use an Entity, since Entity’s have all you need for a doc anyway! This approach in fact is very similar to Notion, where everything is a page, like it or not!
1 Like
I definitely have identified the potential to use a Type and Entities as Docs, however I do significantly value the potential for foldering and sub-folders, and also prefer the option for simple docs that have no visible fields. Once field hiding is available maybe I’d be closer to thinking Docs should just be gone, but I think they’re useful enough for quick, simple, and ad-hoc stuff that they should definitely not be eliminated at this point.
2 Likes
Valid point as always!
You bring up a good point with the Folders. The issue of categorizing in Fibery is probably one of my biggest challenges. I actually don’t really “get” the need for Apps in the first place, as it seems they are arbitrary since you can freely link across them, and with the hope of Polymorphic Relations, we’d have a lot of their importance solved - for example the point you just talked about of needing so many fields to link to all Types in an App.
***Incidentally there is not much movement on that request maybe we can coax @Chr1sG and yourself to bring that one back to the mix as I’m sure many more users would be in favor!
Anyway, I tend to see Apps as more of an Entity that has similar functionality to “Spaces” that are a backbone of a ton of other apps - Wrike, Jira/Confluence, ClickUp, Zenkit, etc. But in reality I think they are basically a way to group Types in a way that’s logical to a team, but otherwise don’t have any other benefit. In fact, I think the Apps should evolve as more of a special “Type” of their own, kind of like how Docs are an outlier in the Fibery scheme (because everything else is an Entity of one sort or another, if not a view…). As a related point, I think the Fibery Extensions are a more appropriate “app” of a sort, as they provide extra functionality that I’d associate with an “app.” Jira, ClickUp, to name a few also handle these extra features with something call an “app.”
So where I’m going with this is Folders are also a sort of categorization tool, but without real substance. Not much Metadata for example. I have found it confusing to try to figure out if I want to set up folders on the left pane, instead of using the native Many-to-one basically relation to accomplish the same. In the latter case as least I’m using real entities to categorize stuff, giving me the capability to at least Refer to them - I can’t reference Folders sadly. I would even like to see a potentially additional step where you’d have a “Master” grouping capability outside Type relations, to help categorize stuff that otherwise you have to use an Entity for, like in the original Wiki Template where “Folder” was a Type for this sole purpose.
I hope that makes some sense and this feedback will be picked up somewhere as useful. Not exactly on topic, but I think very relevant to the issue of categorization, which we are talking about with the “sub-documents” motif!
1 Like
I must admit I am unsure the best way forward around all this. What I can say with reasonable confidence is that the current arrangement and functionality of docs is not ideal, but neither is it ideal to use a Type for docs. Hopefully the Fibery team can put together a vision that addresses these issues. I think it will take some studying of the pain points to really understand exactly what’s going on and how to solve it.
Having said that, the idea that makes the most sense to me at the moment is to make it possible to organize docs in a tree structure, and/or with tags (hierarchical if possible), and to allow them to be linked from/referenced in an “Extension” type field, as well as arbitrary linking (and arbitrary referencing of folders/tags too). In my imagination having the ability to keep a well-organized structure of docs over time in a single place, but also have them connected with the relevant Entities, would be very helpful. I want both for every doc, really. But I also want the references to be out-of-the-way. Perhaps this is where a tabbed interface for Entities could ultimately help… I’ve mentioned it before.
1 Like
A lot of good points here. I agree with Docs as they are, would be great to be able to link them more freely and arbitrarily across Fibery. In fact today I just introed a new dev group I’m bringing in and the first comment from one was “is there a Wiki Functionality as it would be great to connect some documentation.”
Yes good point re: tabbed Entities. I also think another option would be toggling References like in Roam. However, I do like seeing them all on the page at once, so I hope if they got that route, they keep a setting to allow for the entire set of References/Highlights to be visible at once as a setting. I would hate to lose the ability to see everything all at once now, as overwhelming as that can be, if some “collapsing” option is brought in, but without an option to keep the existing way highlights display!
1 Like
Just a quick comment as to one of the benefits if Apps - they allow users to be presented with only the subset of the workspace that is relevant for them, which helps prevent being overwhelmed. For example, the finance dept don’t need or want to see sprints, the sw devs don’t need or want to see CRM stuff, etc.
At the moment, App-level permissions make it possible to have a complex workspace that isn’t confusing/cluttered for the average user.
Of course, when entity-level permissions arrive, this can be even more granular, but for the time being, I get why App groupings make sense.
Also, i think they help the fibery team with encouraging/onboarding new users via templates. Without them, i think some users might find the lack of structure intimidating.
1 Like
Hi!
Could you please tell us more about your Use Case?
Notion consists of Pages. so its structure suggests this behaviour - have pages and pages inside pages.
Fibery fundamentals are a bit different and for now, I can’t imagine the case, that has to have documents nesting.
I am also not sure that folders are a good idea to store Wiki/Docs, as pretty soon that would become a horrible mess. Document can work pretty good as a Type, but not for all the cases as well.
Fibery has a bit different logic, so to help, I need to understand the case 
Btw, thanks all you guys for help and suggestions - a pleasure to read 
1 Like
If an entity in a folder and/or other entity position in the left menu were simply a pointer and not (only) an algorithmically generated display (i.e. smart folders), then we could have the best of both worlds: entity as doc, visible (or not, when desired) in left menu and freely repositionable, but also linkable in other entities.
Basically I think different teams/people will want to do things differently. So best, perhaps, to just increase flexibility of the organizational options over time, and let people decide. Then again you may want to be “opinionated software” and enforce some kind of structure, like Apps currently. I am not against the App model/metaphor, but I think within apps some more flexibility is ideal. So consider it perhaps a hybrid approach of rigid and flexible, where you define high-level structure based on derived “best practices” from your user research, etc., but allow more customization within lower-level sub-structures.
1 Like
Chris, this is a great point, thanks for adding it in!
I think you have hit on a real beneficial use of Apps - a sort of “Space” or “Team” that can have certain Entities tied in for those on a team they are relevant to. Although Fibery - and I support this - is getting less and less “tied” in its structure to apps - just look at the latest release of ability to move Views across apps:
…I still really like to be able to “group” or “Categorize” stuff at a meta level. I still would love to see Apps get full love in Fibery, such as:
- be able to be referenced like everything else - see in Search results, reference in “#” mentions, have their own descriptions useful for users, etc.
And I want to take another opportunity to mention that I think the term “App” is a misnomer, and it’s been confusing for my team, when you think about what an “App” really is. What do you think about what I was saying about this already:
Perhaps over time, if there is support, the “App” moniker will evolve to something more appropriate? Unless I’m in the minority on this one…
Finally, re: permissions, and you hit on this too, I am hoping we get all levels of permissions - App, Type, and Entity - even certain Views as I’ve seen places that would be helpful. Permissions are becoming more relevant to me as my team grows, and to have world-class permissions you really need multiple levels for it.
Thanks again and cheers!
PS I owe you a few more responses and will get to them soon!
But how useful is this before the Apps themselves stop being just an admin view (basically, at this point), and hopefully becomes more of a possible “dashboard” view?
Obviously your team’s experience is valid data. But it’s 100% intuitive to me the way the “App” term is currently used. They are intended to essentially represent other more stand-alone existing apps or app categories you might use, at least in provided templates (and by implication, suggested use). Fibery can do a lot of different things, but associating those things with existing tools and workflows is a helpful metaphor, at least in my experience, as well as intuition.
Generally I disagree here as well. Those are extending the functionality, so “extension” makes perfect sense. I will say the term “extension” makes a bit more sense perhaps at the app level (just because of the name and extending the metaphor), but I’m glad you can define them at the type level. Maybe there is a better term for extensions, but I definitely don’t think “app” is it… no matter what Jira and ClickUp say. 
(and anyway doesn’t ClickUp call them “ClickApps”, and surely that’s at least 50% just for the pun 
).
1 Like
Great points here as always!
Yes this would be great, although I could see reference inside docs and elsewhere the “Dashboard” with a link. I think this is a great feature of Notion actually, you can create a Dashboard that’s technically a “Page” as far as Notion is concerned, and refer to it all you need.
One final point re: calling Apps “Apps.” I think that as you say, “Extensions” does make sense and that’s an apt name for that part of Fibery, not necessarily “Apps.” However, I still think that an “app” inside a tool should be more of an additional capability, something that enhances the entire tool. Apps right now are more groups of Types. I don’t really think you can do much unique in terms of functionality with each of them. In fact, I’m not really sure I think the Templates are much more than just suggested ways to set up workflows. Think about would you consider any of the Notion expansive Templates in their Gallery an “App”? But you can certainly do almost the same thing in Notion - set up multiple DB’s inside a page and try to have that be dedicated for a Team.
Anyway this is a small point, much bigger stuff to talk about! I just think that in the end, “Apps” really don’t do what the average user is going to think they should, when they see the word “App.” I’ve had to explain around that term to my team when presenting Fibery.
Cheers!
1 Like