And did you experiment with tana?
2 Likes
Yes! I actually really enjoy Tana. I use it for brainstorming and collab with my husband. I really need formulas, API access, document mode, some other things for it to be my main app. Luckily the team has been super responsive to my feedback and the things I need are coming at some point so we’ll see.
2 Likes
Please consider prioritizing this higher. It’s actually really helpful for research and handling product feedback, etc. from sources Fibery doesn’t support natively. For example rather than using a generic Web Clipper (or having to develop specific e.g. Twitter connection for Fibery), instead just leverage the many input sources that Readwise already handles, and then connect that to Fibery and you suddenly have a very powerful “ingestion engine”. Takes the pressure off e.g. your own web clipper, perhaps. And also I hear Readwise is very easy to work with for devs, has a good API, etc. Would probably also make Fibery more visible in the general PKM community as lots of people are hyped about Readwise. If you are not already thinking about integrations as a marketing channel, you should be. 
This is a common workaround for many Fibery limitations, but it only works for certain things. In this situation I’m fairly sure it doesn’t go very far to address the underlying need. If I’m not mistaken, she wants something similar to the “Strange New Worlds” plugin for Obsidian:
(correct me if I’ve misunderstood @Sarah_Arminta )
I think you give some fairly good example use cases here. But I must agree with Michael, despite watching closely across the PKM/TfT community for years now, I have seen very, very few actual use cases for automatic graph views in personal knowledgebases (mindmaps and e.g. “tree maps” are a different story). Not to say that they do not or cannot have utility, but it’s quite uncommon for people to be able to actually describe tangible and specific value from those kinds of features. I personally suspect that an “actionable” and “insightful” graph view has simply yet to be designed or implemented, but I think there is a lot of potential value there, with the right design and affordances. I also think graph views can have perhaps more obvious value in other contexts besides PKM (think for example of word relation models as a way to explore synonyms or the etymology of a word).
A Daily Notes Page is just another kind of Database, with a Date field(s), etc. I record everything in bullets in Rich Text. I frequently #reference other Databases/Entities, etc. to establish ad-hoc links. The two missing features to fully enable this kind of workflow are Transclusion and Blocks). Both are coming. Once we have Transclusion, we can write something in a Daily Note Entity, then Transclude it anywhere else we want, thus being able to organize our unstructured Daily Notes into multiple more structured places. In the meantime we can highlight-link in Fibery and it will show up in the References of the linked-to Entity, which is not as good, but not bad either. References can also be operated on with formulae to e.g. generate a field showing references within the last X days, etc. (I haven’t done this, but fairly sure it’s possible).
I have a couple of Projects/Tasks setup specifically for this. 
Basically “come back and do something with this later”, and it reminds me on a schedule relevant to that kind of thing, daily, weekly, etc. When the reminder comes up, I go look at the References for that Entity and see if there are any I haven’t processed yet. I may or may not Unlink the ones I’ve processed at that time, to make it easier to see the new ones next time the task comes up.
Aren’t “dashboards”, as defined by e.g. Notion, basically going to be enabled by the coming Blocks efforts? Being able to embed View blocks, etc. will make Fibery at least as capable as Notion in this respect, and more so given the powerful Charts for example. Only real limitation will be lack of “columns”, I think (though maybe/hopefully you have a column block type planned ).
I am similar, though not quite as in-depth as you, it seems. But I would also suggest you consider how many things actually need to be their own Database. You basically have two major tools for differentiating a “type” of thing. You have the Database itself, which is a “heavy” solution, creating major distinction between things, and databases are particularly distinguished by their set of fields. And then you have Fields and their Values, so e.g. you can have a single “Documents” database, but have a single or multi-select Field that is a “Type”. This is a “fiction” document, that is a “poem”, etc., and they can be distinguished by a single Field denoting a “Type” (single or multi-select). Then you can e.g. create a View (Table, List, etc.) that only shows Poems vs. Fiction (or colors each differently).
The main limitation on using a regular Field for e.g. “type” distinction is field values cannot be shared between databases, so if you want to define common “types” between databases, that’s when you’d use a separate Database for those “type definitions” themselves (i.e. “tags”), and then use a Relation to multiple other Databases to define that commonality (essentially allowing shared values between multiple databases for a common field).
So do you have Fields that are specific to “fiction” that would not be shared by “poem”? Or between different kinds of “products”, e.g. a candy bar vs. a can of soup? Maybe, maybe not. I only create a new Database if the content I’m wanting to contain in it has a sufficient amount of unique field-type (i.e. structured) data. If there are just 1 or two but several other Fields are shared by another, similar “type”, then I’ll often just add those extra fields, knowing they’re only used by some of the Entities in that Database, but it’s acceptable (especially now that we can Hide fields, Collapse fields, etc.). Also this would be further helped by Individual Layouts for a node, hide fields etc.
Now all of your examples above may in fact have enough different structured data elements to justify being their own DBs, but they (or others you haven’t mentioned) may not, and could perhaps just be distinguished by one or more field values on a more generalized Database “type” (e.g. “documents”, “notes”, etc).
I would say the Color options are quite basic and inconsequential through the Fibery system right now, which is to say that they are confined to the View they are defined and shown in. I think there are one or two prior requests about more system-wide, “intrinsic” color properties of entities/databases/fields, which I think would be nice to have.
So, having read through this thread thus far, and seeing that you and I have similar, broad personal data management needs, and also being a fairly long-time Fibery user, I can speak to the choices I’ve made and the principle challenges I see in implementing my own workflow and hopefully that will be helpful. Currently I am all-in on Fibery, for reasons I outlined in the other topic. In large part my own limitations of time and brain power are the main impediments to a complete setup as I envision it. Which is why I hope to share my template(s) when I’m finally done. Other than that, I continue to make feature requests, bug reports, and advocate here in the forum for the many things I think are needed, both for my personal use case and, as much as possible, for broader business use cases.
There are relatively few thing truly “missing” for me to get most of what I want done, er, done. In some cases there may be a bit more rigidity than I’d like, I may have to do some workarounds where another app might have native functionality. But at the moment Fibery still feels like the best option for building this kind of all-in-one integrated system, whether for personal or business use, especially if you take data portability into consideration (last I heard Tana only bulk exports JSON?). But there are a lot of apps trying to tackle this general problem space, and a surprising number particularly aimed at the personal, or at least personal-first use cases (as opposed to business-oriented tools like Fibery). Tana, Capacities, Mem.ai, Anytype, and of course Obsidian, Logseq, etc.
As I also mentioned in the other topic, Tana is really the main app that is potentially diverting my investment in Fibery at all right now. No other team seems to have thought through how to handle the transition between unstructured and structured data as well as the Tana folks (I mentioned several other cool apps here, but only Tana seems to be well-architected and rapidly evolving enough to currently be a real contender as an in-depth PKM like we’re discussing here). So I think what you’ll have to do is just decide how important ad-hoc data organization is to you. For me one of the biggest pain points with Fibery is lack of combinatorial “types”, property inheritance/combination, etc., and “Polymorphic relations”.
One of Tana’s great powers is the ability not just to progressively structure content into “data”, ad-hoc and in-line, but to then combine those structures on-demand, as-needed, and in non-rigid ways. The ability to use multiple supertags and get the fields of both applying to the current block(s) is incredible, IMO. Fibery cannot do that as far as I understand, and probably never will. At the same time for me Tana isn’t quite structured and “bespoke” enough, in design, in page structure (outliner), etc. But that stuff ought to be easy enough to add, if they decide to (that’s the big unknown to me: what is their future plan, where are they heading with Tana, will it always be a strict outliner? etc.). To be clear, I do not yet have access to Tana, but I’ve watched a ton of videos of how people use it.
But basically that’s the tension I see: very strong structured data functions and bespoke design oriented toward that model, e.g. Views, Charts, etc. (Fibery), vs. ad-hoc, flexible, page-level data, i.e. blocks + in-line Views, etc. (Tana). The two are not entirely incompatible, but they are based on fundamentally different data models AFAIK (graph vs. more traditional DB, I believe). Fibery is further along than Tana in many respects, but Tana does things Fibery doesn’t yet do and perhaps never will. Tough choices. For now I continue to invest in Fibery. Maybe if I got access to Tana it might change my mind For personal use, mind you, not for business use. Fibery is still king there for me.
1 Like
From what I see in Tana videos, I’d go for Tana for personal use. But I did not try it by myself yet.
1 Like
As someone that ran away to Tana for a month or so, Fibery is better for personal use.
The outliner format is fantastic for input, but terrible for different views of the data. Tana do offer views, but they really don’t work that well.
Fiberys entity view and other views are why I came back, and because of your weekly releases and velocity.
2 Likes
Yes, Readwise would be a valuable integration IMO. Btw @Oshyan you can kind of do a Readwise integration workaround by syncing Readwise into Obsidian. Then because I keep my Obsidian in Dropbox I can sync my dropbox file changes to Fibery using Make.com and Hazel. It’s not perfect but 
Yes exactly!
Yes, right now I’m using a DNP database and a feed view that I’ve bookmarked on mobile. There’s just something I miss though about always being greeted by that big open DNP page.
I will do some consolidating if I go with Fibery. It’s not as easy to create types and maintain them vs a tool like Tana or Obsidian. I just really don’t like having to make extra decisions if I can help it (is this a database? a subset of a database? etc)
I agree. I’ve balanced the 2 for a long time with Obsidian + Coda. That may be what I end up with again. The only reason I’m looking to move away is because my Metadata Menu setup broke and really messed it up. The hazards of relying on a plugin…
I will never be able to do without formulas and calculations and automations. I can do that in Obsidian with a lot of work and more maintenance than I would like + API connections to tools like Coda/Fibery that can do some things externally and sync the results back. Tana is far far away from satisfying my needs right now. I use it for brainstorming just so I can drag bullets around lol (Although Logseq obviously can do that too and sometimes I do that directly with a shared folder)
I dream of a tool that will build real databases based off of queries (from tags/properties/whatever) + formulas/automations/API + block based + internal linking + collaboration/share to web. It will happen. Who first?
1 Like
Or, alternatively for Readwise and the many other integrations I personally want (but know aren’t aligned with Fibery’s current strategic direction), maybe Fibery could have some short vs long term solutions for enabling a custom integration library? Something like this:
Shorter term solution = similar-ish to Obsidian via an official Fibery GitHub master repository where users can contribute code for various unofficial custom integrations (maybe sub-repository per integration? Not a GitHub expert here lol) and users kinda work on it together so no one person feels like they have to do it all alone, since this solution would not result in any revenue incentive for individual developers…Fibery could make it clear that users are “on their own” here, but it’s at least a centralized platform for users to easily find any existing custom integrations from the user base.
Longer term solution = similar to Coda or Jira, where it is an actual integration platform officially hosted by Fibery where users can upload integrations and choose to either make it free, a one time charge, or some type of subscription…if it is an integration that Fibery was eventually going to do anywhays, maybe Fibery could include some sort of clause where they have the right to purchase it from the developer or something, I don’t know (clearly I don’t have the kinks worked out at all).
3 Likes
That is a fantastic idea. Tana also has a similar GitHub thing going for community members to contribute imports for various tools.
Obsidian, Logseq, Coda, Remnote, all have a plugin framework.
2 Likes
You can create your own integrations already
We do have plans to create a repository of community integrations in future
3 Likes
Any thoughts on “composable” data structures in Fibery, like using multiple Supertags together in Tana? Instantiate a Field from a DB in another DB’s entity at will? Arbitrary in-line Fields? Dreaming big, I know.
Very interesting feedback! The strict outliner approach and the in-line views are definitely my major concern about Tana at the moment (as I expressed in a thread here). The views can get better, I have faith in that, and it’s relatively early days for Tana yet. Not sure how hard it would be for them to move away from the outliner approach, I mean they could just let you hide the bullets, but not sure that really addresses your concern.
Interesting! Would love to know more about how this works because I have yet to find an easy way to get Obsidian (.md) files into Fibery in bulk in general. It sounds like you’re saving if I put my .md files into Dropbox I could then just use Make to sync into Fibery? I’m familiar with the Fibery ↔ Make connection, and explored it a bit for doing this, but didn’t figure out a good workflow. Tell me more! 
It’s outside the scope of this forum’s topic, I suppose, but I’m curious what specifically is missing from Tana (short list, high level). There are some obvious ones I can think of, but I’m curious your list, and whether you have doubts that your needs will ultimately be met by it. I had thought Tana would actually be closest to meeting your needs, at least in the medium-long-term…
It seems like Tana is furthest along on this, at least as far as “native” functionality. No?
Yes, there is a Dropbox integration in Make (You could use Google Drive as well). I just watch the folder of my vault (or just Readwise if that’s all you want), then download the file in Make, get the data and convert it to a string, put it in Fibery. I then sync back changes the opposite way as well then use Hazel to turn the .doc files into .md.
You can even use Make’s text parser to pull out inline Dataview key:: value pairs
- Formulas/Calculations
- API
- more automatic reverse relations
- Lots of little things, but mostly the 3 above
It would, but the no formulas/API is a must and a deal breaker for me. I would sacrifice query databases, blocks and collab before formulas/API.
1 Like
I should have noted that I’m aware we can make our own integrations. I’m just hoping for the win-win scenario of Fibery having a “user-developed custom integration marketplace” to (1) entice more people to use Fibery and (2) so I personally can selfishly get more desired functionality out of the platform on things that Fibery can’t prioritize internally.
Glad to see it’s on Fibery’s radar!
1 Like
This is a key one for me at the moment 
I’m still getting my bearings with Fibery, but with the date picker, I couldn’t seem to find a way to change the date format. As someone in Australia, it’s always a bit jarring to see the date format as MMM-DD-YYYY 
Would also love the option to show the day of the week when picking a date (all in one field). If someone knows if this is possible, would love to hear!