When presenting tables of results that have thumbnails or other complex content, it is often necessary to reformat some metadata into a "card" style presentation, making a taller and narrower layout for content adjacent to the 2D thumbnail. Currently, we do this with custom markdown formatting such as building a markdown table as part of the column-display annotation for one column that we abuse as the proxy container for this card view. Maintenance of these annotations is painful as they are so verbose and combine so much templating and markdown syntax.
It would be much nicer (and more robust) if the visible-columns annotation structure could support this functionality using a more model-aware system like we have in the rest of Chaise.
Imagine a new visible-column element type which looks something like {"card": [...]}. The inner list would support the same syntax as the current top-level list, so you could define a sequence of columns, foreign keys, or pseudo columns. The object could also contain other parameters as siblings to this list, e.g. to define "markdown_name" or other card-level presentation options.
The ermrestjs/chaise interfaces and presentation layer should be extended to understand the card as a first-class concept and we should refactor our presentation templates to reuse the same logic. E.g. the list of "columns" for a contextualized reference should be able to contain a card instance which has its own list of columns. The presentation layer should be able to reuse much of the record app's "main entity" template to render a card's content.
I'm less certain how the card concept should affect the "tuples" in the ermrestjs api nor the environments built for the templating engine. We would need to discuss this more and consider some use cases.
There might be more use cases to consider before designing a solution here
The vertical attribute-value list I would like to reuse alongside thumbnails in compact table presentations
Whole-entity cards, e.g. more like a conventional card UX representing a set of cards in a tiled space or in a carousel
A grouping structure within already vertical detailed record presentations?
Hybrids/nesting, e.g. card set within card or compact/tabular display within card?
When presenting tables of results that have thumbnails or other complex content, it is often necessary to reformat some metadata into a "card" style presentation, making a taller and narrower layout for content adjacent to the 2D thumbnail. Currently, we do this with custom markdown formatting such as building a markdown table as part of the column-display annotation for one column that we abuse as the proxy container for this card view. Maintenance of these annotations is painful as they are so verbose and combine so much templating and markdown syntax.
It would be much nicer (and more robust) if the visible-columns annotation structure could support this functionality using a more model-aware system like we have in the rest of Chaise.
Imagine a new visible-column element type which looks something like
{"card": [...]}
. The inner list would support the same syntax as the current top-level list, so you could define a sequence of columns, foreign keys, or pseudo columns. The object could also contain other parameters as siblings to this list, e.g. to define "markdown_name" or other card-level presentation options.The ermrestjs/chaise interfaces and presentation layer should be extended to understand the card as a first-class concept and we should refactor our presentation templates to reuse the same logic. E.g. the list of "columns" for a contextualized reference should be able to contain a card instance which has its own list of columns. The presentation layer should be able to reuse much of the record app's "main entity" template to render a card's content.
I'm less certain how the card concept should affect the "tuples" in the ermrestjs api nor the environments built for the templating engine. We would need to discuss this more and consider some use cases.
There might be more use cases to consider before designing a solution here