@@ -35,14 +35,37 @@ We'll use a view-model-controller system that serializes user actions into a que
## The view should be reflective of the model
At the moment Diaggui does a fairly good job of this, though not perfect. Some of the view does directly affect the model and other parts are carefully managed by logic in the interface. This kind of interface handling tends to break during design changes.
## The interface should not punish the user.
There should be no point where the user can instantly regret an action. Saved files should contain all data. Bad configurations or data should not be wiped out when pressing "Ok", e.g. envelope for swept sine.
Ideally, tests should not fail halfway through due to some incompatible settings. Low start frequencies and low sample times in swept sine is a good example.
### The user should be able to undo actions
### External / automated actions should never automatically destroyed configurations set by the user.
Every conceivable action that could be undoable, should be undoable. User should be given a history tree that allows switching between branches of development.
### External / automated actions should never automatically destroy configurations set by the user.
For example, if for some reason the user cannot connect to an NDS server with the right channels, the channel list should not be wiped out.
## Transformations are views of measured data.
Measured data is essentially always a time history. Common calculations such as PSD, transfer functions etc. Should be treated as views of the measured data and not new datasets off themselves, even if they are cached in memory and saved to file.
Persistent representations of these views are purely practical. The user can of course export these views on their own as a distinct data set.
# Automatic Constraints Checking .
# History Tree
# Model-View-Controller
# Pure data structures and type safe update of data structures
