You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After playing a while generating the perfect dashboard for me (which quickly gets too addictive ☺️), I really miss a more strict separation of content (cards definition) and structure (dashboard layout).
Card configurations should be defined within an extra pool, from where they can be referenced and also re-used in multiple places.
Dashboards should be setup by defining the desired structure and referencing to existing cards from the pool to fill the grid places with content.
Especially with more complex layouts, mixing of actual content (i.e. card definitions) and structure information becomes quickly messy and almost impossible to maintain. Restructuring means major re-indenting, which is error-prone and tedious. Re-using of content in different dashboards (e.g. for different users) means copy/paste, changes have to be applied in multiple places. Complex layouts become a brain-twister to keep an overview about structure and content definitions.
With simple card references within the structure information, dashboards become easy to maintain, even complex layouts remain lightweight and clear, tooling can be implemented more simple. Cards can be re-used in multiple places with a single source definition for easy maintenance. It's natural to either focus on structure or on content -- at different times.
Beyond that, dashboards should not only be conditional to users, but also to screen size or other information. Most easy: a set of conditions (incl. templating) like e.g. for automations would be attached to the dashboard visibility. That way you can come up with the best dashboard for your wall mounted large screen, your large and small tablets and phone...etc.!
For backward compatibility (and quick shots), the existing structure def. doesn't need to be changed. You would just refer to a pool card ("card_ref: myNetworkSpeedChart") instead of inserting the complete card definition content.
This discussion was converted from issue #7919 on December 06, 2020 16:46.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
After playing a while generating the perfect dashboard for me (which quickly gets too addictive☺️ ), I really miss a more strict separation of content (cards definition) and structure (dashboard layout).
Card configurations should be defined within an extra pool, from where they can be referenced and also re-used in multiple places.
Dashboards should be setup by defining the desired structure and referencing to existing cards from the pool to fill the grid places with content.
Especially with more complex layouts, mixing of actual content (i.e. card definitions) and structure information becomes quickly messy and almost impossible to maintain. Restructuring means major re-indenting, which is error-prone and tedious. Re-using of content in different dashboards (e.g. for different users) means copy/paste, changes have to be applied in multiple places. Complex layouts become a brain-twister to keep an overview about structure and content definitions.
With simple card references within the structure information, dashboards become easy to maintain, even complex layouts remain lightweight and clear, tooling can be implemented more simple. Cards can be re-used in multiple places with a single source definition for easy maintenance. It's natural to either focus on structure or on content -- at different times.
Beyond that, dashboards should not only be conditional to users, but also to screen size or other information. Most easy: a set of conditions (incl. templating) like e.g. for automations would be attached to the dashboard visibility. That way you can come up with the best dashboard for your wall mounted large screen, your large and small tablets and phone...etc.!
For backward compatibility (and quick shots), the existing structure def. doesn't need to be changed. You would just refer to a pool card ("card_ref: myNetworkSpeedChart") instead of inserting the complete card definition content.
Beta Was this translation helpful? Give feedback.
All reactions