These are my plans to improve the underlying basis of how DTT works beyond what users requested based on my own understanding of user interface design.
# Principles
## User is in command.
DTT is an expert tool. We assume that the user knows better what they want to do than the programmer. Therefore, where possible to make the measurement, DTT will make the measurement. If there are ways the software can determine that a measurement will be degraded, these should result in warnings to the user and not used to block the measurement.
Two examples are: mismatch in DTT computer timing with front end timing, and display of frequencies to with in the attenuation band of anti-aliasing filters. In the first case, an expert user may decide that the timing difference is irrelevant. In the second, the user may know about the attenuation band of the filter than we do, or may hope to see something in the band regardless.
See "automatic constraints checking" below for how we'll address this.
## Models should not be tied to a specific file type.
Representation of the model in memory should be a pure data structure and not tied to some file format. Currently it appears that the XML library doubles as a structure for a dynamically configurable model. The code is obtuse and has no type safety.
In addition, I suspect writing modules for other file formats would not be easy in the current configuration.
## Measurements should have attached the exact configuration used to create them.
## User should get immediate feedback.
## Error conditions should be obvious and clear.
## The view should be reflective of the model
## The interface should not punish the user.
### The user should be able to undo actions
### External / automated actions should never automatically destroyed configurations set by the user.
