err… I didn’t mean this to be saved between power cycles. what more space do you need in your mental model to make the difference between “what I last used” and “what the defaults are”?
1 Like
Although you may not have intended it across power cycles, that is how the BusPirate handles a few things.
expand if you really care...
TLDR; Layer one is default values. Layer two is last-used values. Default values are learn-once, store long-term. Last-used values require short-term memory (and query-ability, or never sharing a device).
Default Values … Long-term Storage
Default values are generally documented, generally common for a given version of software, and generally do not often change even between versions. Having a consistent default value over time allows folks to rely on that default value. Even when a default changes, most time folks don’t care, because such change is typically for a default value that “does the right thing”.
That said, for the purposes of this discussion, let’s go worst-case and presume that the default value is part of the mental model. Even then, default values would migrate to long-term memory, which generally has greater recall capacity than short-term memory.
Moreover, with substantially static defaults, the interplay between those defaults can be fully considered, slowly over time.
A Single Option with Last-Used Override
Now consider adjusting the the system to remember the “last-used” value, and use that instead of the “default” value when the option is not explicitly provided. Immediately, the results from running a command change from repeatable based on the explicit inputs provided (plus defaults), to potentially non-repeatable because it’s further based on a hidden variable … the last-used value.
Impact
Scripts and tutorials that instruct the user how to perform any operation are therefore going to need to deal with all the hidden variables, or the results of a user following the instructions will be non-repeatable (or worse, cause the user running the script / following the tutorial to get different results). That’s a cost … neither good nor bad, but still a cost.
Having a mental model that accurately predicts the results of an action increases the sense of “safety”, and thus makes that action more approachable. When a mental model cannot be easily constructed that captures the results of an action (not limited to computers), then a few things may occur:
- The user’s mental model is “good enough”, so they continue blissfully happy as the results match their mental model.
- The action’s result falls outside their mental model, and causes a positive result. (Gambling; Foraging new type of area resulting in finding abundance of food; etc.) Endorphins are released, and the action is strongly re-inforced… the user naturally continues to explore in a similar manner.
- The action’s result falls outside their mental model and causes a negative consequence. (a child’s first time touching a hot stove / glowing embers.) The action is associated with the negative consequence, making the action less desirable / friendly.
Therefore, where the goal is to provide a generally “safe” space, it’s critical to minimize the occurances of that third situation. Enabling a simple mental model is a major step to enabling that.
Hidden Variables Increase Complexity
At a high abstraction, a hidden variable is one that the user does not know the value/state of, and which impacts the results of the action.
A mental model is made more complex when it relies on hidden variables … potentially multiplying it by X when that hidden variable has X possible states. If there are then n hidden variables, each with X possible states, a perfect mental model would then expand X^ⁿ * 100%.
Adding a “last-used” override for a default value adds a hidden variable … and moreover one that stays in short-term memory.
Of course, practically speaking, there’s a balancing between needs. For example, in the BP5+ case, there are modes that inherently reconfigure the BP based on the target bus, and thus change the behavior of various commands, and enable/disable other commands.
This IS a hidden variable (at least for scripting). For the CLI, this is mitigated by the CLI prompt clearly indicating the current mode. For scripting, this is mitigated by having a single command enter a known states (mode hiz). The user’s mental model (and short-term memory) must include the mode the BP is in. This is seen as a negligible-cost as the modes tend to correspond to bus / protocol types … things inherent in the use of the BP … mitigated as noted above … and outweighed by the alternative’s complexity of having to do bus setup / teardown for each command.
But it IS a cost to the short-term memory / mental model, as knowing the mode is critical to knowing how various command might work.
Current Limiter
As to this specific example, if the BP does something unexpected with the current limiter, it can destroy stuff. That falls squarely in the “unexpected negative consequences” case #3, and thus a “bad thing”.
Having a “last used” default for the current limit means that the option will NEED to be provided 100% of the time … else the risk of the negative consequence, as there cannot be reliance on default value.
The alternative to not explicitly providing the value each time (for interactive use) is that the mental model then needs a layer above the “default” settings … and must be in short-term memory, since it must be discoverable (e.g., ask what that last-used value is … currently missing from BP CLI).
That’s a lot. You may disagree with some or all of it, but I think it’s clear that there is a need for short-term memory, and relies upon having a way to query the last-used values (something currently missing from the BP CLI).
3 Likes