We may soon release an integration template that would allow users to have a database of time periods (days, weeks, months, quarters, years) as the next step in making managing date information in Fibery more user-friendly.
We’re interested in getting feedback from users on the first iteration before releasing to a larger audience.
If you’re interested in trying out what we have so far, here’s what you need to do:
Go to the integration tab in any space (I suggest creating a new space for experimenting)
Note: this app will only function for the next couple of weeks. After that, attempts to install or sync will probably return an error. Please don’t use it for anything mission-critical. If/when we release the final version, it will not use the same url, so anything you have used this beta version for will be broken, and will need to be recreated
Very nice @Chr1sG !
The data-structure looks very promising!
I created several of these structures myself in fibery - but it is a fickle friend and you always have to update it manually (or by script).
This is very interesting and I will try it out and report back. I am wondering if the source code for the app is going to be available as another custom integration example for devs to follow.
I do wonder though why this functionality isn’t being built into the “date” data type? Extending date type to make capturing other temporal concepts like quarter, month or year seems to be a much more robust solution that doesn’t require an external app, syncing or explicitly defining Q3 1992 beforehand. It also means that the field remains fundamentally a date and would (hopefully) maintain date functionality and would be able to be visualized on timelines while allowing things like binning on boards (which is a source of frustration for me right now).
If you create a date column in excel, when you apply a filter, it automatically generates a hierarchical structure of year, month, day. PowerBI also has the ability to format date types into quarters, months, …. I think dealing with this at a field/data type level might be a more sustainable approach long term.
While creating entities for years, quarters, months … certainly works, it does seem like a workaround rather than a fundamental solution.
Overall, the end goal is to merge the functionality, so that there is a field type that has the best of both worlds:
a UI picker suited to the nature of time periods
variable granularity
functionally infinite ranges
support for time and dates (either and/or both)
available as an ‘axis’ for various views
semantic overloading
timezone/language configuration
…
But until that is possible (and there are technical reasons why it is not simple to overload the existing date field type with all this functionality) we figured some users would get benefit from this kind of solution.
Thanks for the explanation of the eventual goal. It is amazing and really comprehensive … and it makes me really happy to know fibery team is thinking along these lines. I hope some consideration would also be given to possible representation of fuzzy dates!
This integration is definitely very useful. Didn’t mean to come off as critical. Will definitely try and report back
Glad to know this is the long-term vision, but then will there be a migration path from the synced database approach? If not, why should I invest time/energy into making this undeniably more complicated/clunky approach work? I don’t mean to be harsh, maybe just a bit blunt.
I have no idea how long it might be until the long-term vision is realised, and I have no idea if/how migration would take place.
There is a good chance that a migration could be semi-automatic, but an equally high chance that manual adjustments/corrections would also be needed.
Unless you have a specific use case that this current solution helps with significantly, then you probably shouldn’t
But my hope is, for some people, a solution similar to this beta offering is valuable enough that it is worth using until a long-term ideal is realised (whilst acknowledging that there may be migration challenges down the line if an even better solution is released).
I’ve got examples from my domain of work and what I’m grappling with for PKM. However, I do admit my examples likely do not align with the “ideal” fibery users who are in the technology/content creation arena. I discussed a few examples of fuzzy dates in an earlier post on Anytype:
In that post, I also talked about using conventions and what I’ve found to be the pitfalls:
I shared one approach that I’ve seen. Just cross-posting that in case it is helpful:
From a broader perspective, I think dealing with fuzzy / uncertain data is an important challenge for all data tools (especially when you talk about “knowledge”). However, I’m not expecting fibery to lead this or come up with a solution because it is likely not at all important to your customers (although once you start thinking about uncertainty in databases, you see it everywhere in all systems of record). But I try and keep raising it anytime there is a discussion about fundamental data types in the hope that eventually a conventional tool starts to tackle this challenge.
With regard to ‘fuzzy dates’ it would certainly be possible to create a field that supported that, but it’s hard for me to understand how it would be different from a field that just used text.
In other words, how do you expect to manipulate or visualise a field that allowed both “Autumn 2013” and “the 1820‘s”?
I have to admit that I don’t have any particular answers on how best to do this (both from a data and UI perspective). The main reason I mentioned it hear is that I think there is greater value in encoding temporal information in a consistent way rather than just using plain text field. Within the application “date” fields carry specific semantic meaning (as temporal entities themselves), would have specific constraints & more specific UI, and allow fairly unique visualization (e.g. timelines, calendars and date wheels). Plain text fields would be very poor substitute.
I know the examples I provided above may not be all that interesting for majority of fibery users. However, I think uncertainty in the date field (and other data types like numbers) might still be valuable for core fibery uses (e.g. project management application). Examples include representing uncertainty in project cost estimates (estimate classes as +/- %) as well as project schedule (baseline schedule vs. worst-case). Almost all business applications mask uncertainty in values (or ask users to use comments or notes field to note them). Even when there are specific processes to assess & quantify the level of uncertainty, most data systems don’t have a way of storing this information and using it in future calculations, aggregation and reporting. It would be great if information systems would start to better represent reality by making uncertainty visible.
The former (being able to choose a week, or a month, or a quarter, etc.) is what is trying to be addressed with this integration
The latter (being able to choose a specific day/week/month knowing that you might be wrong) is not addressed, but is potentially solvable by using two or more fields, e.g. one field representing optimistic and one representing pessimistic, or perhaps a field representing best guess and another representing the magnitude of uncertainty.
I’ve been testing this out and finding it quite useful
One of the things that would be really helpful is if periods could also have prior and next periods (of the same type) as well. So if you are using quarters, it would be great if you could easily access the previous or next quarter through formulas.
