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
{{ message }}
This repository has been archived by the owner on Mar 17, 2023. It is now read-only.
Use Case / Scenario Background:
I see valid use cases for using ph-ash as a dashboard on "kiosk like" Systems. That means there is a screen running, but no real input devices. This can either be a Tablet, mounted in kios mode, or it can be screen combined with a small computer (e.g. raspberry). These dashboards can be mounted in shared offices, or as "companion device" in smaller offices (mounted at a wall or separate desk). A team can have the dashboard at a central position in the office, and get information about the status of their application(s). Another advantage of such a setup is, that it can run independently from any fat clients. You can concentrate on your work and still have the dashboard visually present in the room.
But: Without having any input device present at the dashboard, any mouse over effects do not work, and it is hard to see at a first glance which tile belongs to which component/check.
Description of Feature:
Giving a config option to provide a text label to a tile. A simple label, that identifies the tile. The most luxurious option would be to have a label that scales in size together with the tile, but as a starting point a label can be a simple text with fixed (configurable) size.
Implementation suggestions:
As I do not know the details of how the tile size scaling is implemented, following some ideas about implementation.
As a simple label does not need to be a multiple line text block, it can be limited to one line or a fixed number of characters. It should be a label, not the next harry potter novel.
For scaling the label a fixed ratio of tile width to text size can be set. This might have the disadvantage that very small tiles have tiny labels that are very hard to read. I consider this an issue of how the user uses his dashboard, and not a design issue that needs to be solved by the developers. Users can still decide to not use labels and have a large number of tiny tiny tiles. Or they use labels, but are ok with them only being clearly readable when the tile scales big in case of an issue.
A more code oriented approach would be to only show the label when the text size reaches a certain minimal threshold.
If it is too complicated to use text and text size, it might be another approach to either use png/jpg or (better) vector graphics svg instead, and place them on the tile / fill the tile. Transforming text to an image file is easily possible with third party tools and libraries (e.g. this implementation in php https://github.com/kartsims/easysvg ). Imagemagick or inkscape offer this feature as well.
I know about the "keep it simple" approach of ph-ash, but I consider simple labels not as a fancy "nice to have" feature but a necessary layer of information to any dashboard (especially when it runs in a kiosk mode setup or on a "companion device").
The text was updated successfully, but these errors were encountered:
Use Case / Scenario Background:
I see valid use cases for using ph-ash as a dashboard on "kiosk like" Systems. That means there is a screen running, but no real input devices. This can either be a Tablet, mounted in kios mode, or it can be screen combined with a small computer (e.g. raspberry). These dashboards can be mounted in shared offices, or as "companion device" in smaller offices (mounted at a wall or separate desk). A team can have the dashboard at a central position in the office, and get information about the status of their application(s). Another advantage of such a setup is, that it can run independently from any fat clients. You can concentrate on your work and still have the dashboard visually present in the room.
But: Without having any input device present at the dashboard, any mouse over effects do not work, and it is hard to see at a first glance which tile belongs to which component/check.
Description of Feature:
Giving a config option to provide a text label to a tile. A simple label, that identifies the tile. The most luxurious option would be to have a label that scales in size together with the tile, but as a starting point a label can be a simple text with fixed (configurable) size.
Implementation suggestions:
As I do not know the details of how the tile size scaling is implemented, following some ideas about implementation.
As a simple label does not need to be a multiple line text block, it can be limited to one line or a fixed number of characters. It should be a label, not the next harry potter novel.
For scaling the label a fixed ratio of tile width to text size can be set. This might have the disadvantage that very small tiles have tiny labels that are very hard to read. I consider this an issue of how the user uses his dashboard, and not a design issue that needs to be solved by the developers. Users can still decide to not use labels and have a large number of tiny tiny tiles. Or they use labels, but are ok with them only being clearly readable when the tile scales big in case of an issue.
A more code oriented approach would be to only show the label when the text size reaches a certain minimal threshold.
If it is too complicated to use text and text size, it might be another approach to either use png/jpg or (better) vector graphics svg instead, and place them on the tile / fill the tile. Transforming text to an image file is easily possible with third party tools and libraries (e.g. this implementation in php https://github.com/kartsims/easysvg ). Imagemagick or inkscape offer this feature as well.
I know about the "keep it simple" approach of ph-ash, but I consider simple labels not as a fancy "nice to have" feature but a necessary layer of information to any dashboard (especially when it runs in a kiosk mode setup or on a "companion device").
The text was updated successfully, but these errors were encountered: