Options
Add a metrics display for productivity analysis
Just an idea for long term projects...
Currently SP has no built in counter or display for how many times particular functions or buttons are operated. Of course this kind of thing is non-standard, because its usually only user interface developers who care about such things as how many keystrokes users have to execute in order to get their scores entered.
The current situation is not optimal because neither users nor developers can get feedback on the most efficient ways of doing things in Symphony Pro. For example, developers might want to concentrate efforts on use cases that take a lot of keystrokes, or that generate lots of taps on the undo button. Or users (me included) might want to experiment with different workflows and methods to minimize the number of keystrokes and undo button uses.
A better approach would be to include a simple way for users and developers to see button counts for productivity and error analysis. I can imagine adding simple internal counters to the event code for the toolbar buttons, to count the number of times buttons were pressed, menus were extended, notes selected, and so on. One full iPad screen could probably be used to display all the numbers. One menu choice somewhere could reset all the counts. Another menu choice could export them by email.
Internally, a linear event log of button presses could be kept in a file. Just a timestamp and an event, so the file wouldn't have to be very big. The max file size could easily be limited by the logging software, to keep only the most recent N events.
If this feature was added, it would be far easier for developers and users to analyze where they were spending the most time, or where they were generating the most errors that required undo operations. For example, statistically speaking, if 90% of the undo events were preceded by a note-placement completion event, that would be good evidence that note placement operations were the major cause of undo events (and maybe of user frustration).
Or imagine comparing two different workflows, such as a serial one-thing-only flow that did notes on one clef first, then slurs on the clef, then symbols, versus a workflow with a "completely treat each measure before leaving it" policy that did notes, slurs, and symbols completely before moving to the next measure. If one workflow had 1,000 less menu-extending or mode-flipping events, then it would be the more efficient flow.
It seems to me that this would be a good investment of resources because (1) the risk of failure is very low -- it's simple programming and counting, (2) the cost of implementation is fairly low, and the implementation would be easily extensible for future metrics, (3) the feedback on user interface metrics is very valuable for efficiency analysis, and (3) the invested work will never be obsolete, and will pay dividends for a long time in maintaining the user interface as the best and most efficient in the industry (with numbers to support various viewpoints).
Currently SP has no built in counter or display for how many times particular functions or buttons are operated. Of course this kind of thing is non-standard, because its usually only user interface developers who care about such things as how many keystrokes users have to execute in order to get their scores entered.
The current situation is not optimal because neither users nor developers can get feedback on the most efficient ways of doing things in Symphony Pro. For example, developers might want to concentrate efforts on use cases that take a lot of keystrokes, or that generate lots of taps on the undo button. Or users (me included) might want to experiment with different workflows and methods to minimize the number of keystrokes and undo button uses.
A better approach would be to include a simple way for users and developers to see button counts for productivity and error analysis. I can imagine adding simple internal counters to the event code for the toolbar buttons, to count the number of times buttons were pressed, menus were extended, notes selected, and so on. One full iPad screen could probably be used to display all the numbers. One menu choice somewhere could reset all the counts. Another menu choice could export them by email.
Internally, a linear event log of button presses could be kept in a file. Just a timestamp and an event, so the file wouldn't have to be very big. The max file size could easily be limited by the logging software, to keep only the most recent N events.
If this feature was added, it would be far easier for developers and users to analyze where they were spending the most time, or where they were generating the most errors that required undo operations. For example, statistically speaking, if 90% of the undo events were preceded by a note-placement completion event, that would be good evidence that note placement operations were the major cause of undo events (and maybe of user frustration).
Or imagine comparing two different workflows, such as a serial one-thing-only flow that did notes on one clef first, then slurs on the clef, then symbols, versus a workflow with a "completely treat each measure before leaving it" policy that did notes, slurs, and symbols completely before moving to the next measure. If one workflow had 1,000 less menu-extending or mode-flipping events, then it would be the more efficient flow.
It seems to me that this would be a good investment of resources because (1) the risk of failure is very low -- it's simple programming and counting, (2) the cost of implementation is fairly low, and the implementation would be easily extensible for future metrics, (3) the feedback on user interface metrics is very valuable for efficiency analysis, and (3) the invested work will never be obsolete, and will pay dividends for a long time in maintaining the user interface as the best and most efficient in the industry (with numbers to support various viewpoints).
0
Comments
I'm trying to think of everything required to make a convincing comparison of two things based on metrics. A developer or user could then say, "I did the experiment with two different approaches. The second approach had 40% fewer operations (keystrokes, taps, etc), generated 20% fewer errors (undo operations), and took 20% less time."