I am trying to approach it from a need / use case point of view, rather than from a solution point of view.
Setting aside the UI, I am trying to determine which elements of the need are ‘must-have’ in order to achieve what you want to achieve, vs which elements are merely implementation-specific.
For example, are we talking about a ‘vertical timeline’ view that is specific to an single entity?
If so, then any of the existing data views (table, board, list, feed) are not going to be suitable, and a new type of data view (= ‘vertical timeline’) is not going to address the need, since these views are designed to present aggregated data from multiple entities.
Also, it’s not clear to me from your description whether the text provided by the user as the update text is expected to be ‘ephemeral’ (and only available as ‘historic’ information) or whether it persists / is added to (i.e. an entity’s current state includes all update text that has ever been submitted to date).
Obviously this will determine where the data lives. If you think that this means I am taking an engineering approach, then so be it.
But that’s where my questions came from, and I think it’s worth getting them answered.
And when I asked about existing functions, I was asking in order to understand where you felt this ‘view’ might live? Not because I thought any of them could achieve what you wanted.
Yeah, and I can understand why this is clunky. A separate database for updates seems overkill (especially when it would potentially need to exist for all databases)
But what if there was an optional Comments-like field (called Updates) that was configurable so that it could show attributes, as well as the text the user added, and if it could have a UI that showed the timing of the comments, vertically grouped by month (as shown in the screen shot)?