Now that we have moved beyond initial development, I find myself forgetting things or running into configuration issues more often than software bugs. For example, classification files may be inaccurate, especially if a data layer's attributes changed.
There is already a symbol shown in the legend when a layer cannot be read. It would be useful if the same approach could be used to indicate not quite so serious problems, to help implementers. The following are technical considerations:
The layer object would need some code to keep a list of problems. This is similar to how TSTool has a list of problems for commands. The object would need methods to set and get problems.
The legend would need to detect and display an indicator. Maybe the problems need to be categorized as failure (red) and warning (yellow), or similar. I know this can be challenging so getting the basic mechanics working would be the first step.
We want to minimize the impact on users. For example, for TSTool I sometimes print warning messages to the log, but they don't rise to the level of the user needing to see in the UI. Anything shown in the UI is related to possible bad output from processing, which they do need to be aware of.
I have mentioned before that maybe a diagnostics tool or dashboard could be built-in. One way I did this in TSTool was there are generic components like diagnostics tools, and the Help / About tool for showing system information. These could be build in by allowing an item to be added to the application configuration file and if found, the routing would show a popup or page that had the information. In this way, warnings that are not user-level can be seen.
Decisions would need to be made about what problems do rise to the level of a user notification, but given that am also a user, I can say that during implementation, I would benefit from an indicator and log message, rather than relying only on console messages. Any messages shown to users would need to be clear and not use overly technical language.
Now that we have moved beyond initial development, I find myself forgetting things or running into configuration issues more often than software bugs. For example, classification files may be inaccurate, especially if a data layer's attributes changed.
There is already a symbol shown in the legend when a layer cannot be read. It would be useful if the same approach could be used to indicate not quite so serious problems, to help implementers. The following are technical considerations: