Options
UI: How to fix the core note entry problem
Fixing the Note Entry Problem
Currently the note entry process in SP is not optimal. There are several ways to enter notes - using just your hands, using the built in keyboard, or using an external keyboard. I limit my discussion here to placing notes on the score with fingers only -- no use of fretboards or internal or external keyboards. I think this way because using keyboards places an extra burden of knowledge (and possibly playing skills) on users who just want to enter notes on the score.
The main issues are these, in order, most frustrating first:
(1) Correcting misconfigured notes (eg if length or sharpness is wrong)
(2) Correcting horizontally misplaced notes (eg note didn't align with chord properly)
(3) Correcting vertically misplaced notes (eg note has the wrong pitch)
(4) Configuring notes with the left toolbar menu structures.
(5) Placing a configured note vertically.
(6) Placing a configured note horizontally.
Notice that the correction processes top the list, and not the act of initially placing a new note vertically and horizontally.
Seeking the Core Cause of the Note Entry Problem
It seems to me that the core cause of the note entry problem is the "configure-and-place" model of note entry. There are other UI issues that contribute to the problem but they are not the core. The "configure-and-place" model requires users to first configure the properties of a note (length, sharpness, etc) on the left toolbar, and then place the configured note on the score. There are several user-unfriendly aspects of this process.
For example, the user doesn't get to see the configured note in context until it's initally placed on the score, but by then it's too late to correct any misconfigurations or misplacements. The usual choice is to undo and start over.
--
The core cause of the problem is that the "configure-and-place" model restricts the configuration power of the left toolbar buttons to configuring ONLY the FUTURE (next) note that is about to be placed. (The toolbar power can be used if a note is selected in Entry Mode = Select mode.)
Currently, toolbar buttons cannot be used to change (correct) note properties while in note-entry mode. They can only be used (1) to configure the next FUTURE note in Note Entry mode, or (2) to correct a selected note in Selection mode. At the instant when users tap the screen and enter a misconfigured note, or a misplaced note, in Note Entry Mode, that's the same instant when the note becomes the CURRENT note, and the SP "configure-and-place" model takes away the toolbar power that users need to correct the entered note.
That's why note entry is so difficult -- mistakes are easy to make, and there's no corrective power available to users when they need it most.
Key Solutions to the Note Entry Problem
The three key solutions are to
(1) Use a "drag-and-configure" model
(1) Change the UI to help prevent entry errors in the first place, and
(2) Change the UI to give users corrective power for the CURRENT note.
All three solutions can be simultaneously implemented with a floating/popup "note edit bar", and a floating/popup "note pitch" toolbar. First I will explain the two toolbars required, and then I will show how they are used in the "drag-and-configure" model.
1. A Floating/Popup Note Pitch Bar
The pitch bar is displayed when users change the SP Entry Mode to Note Entry. (For now, imagine the bar is below the note insertion site, so the user can see the note while tapping toolbar buttons.)
The function of the pitch bar is to change the vertical pitch of a misplaced note (the CURRENT selected note). The pitch bar looks something like this (enharmonic names can be changed based on the key, I suppose).
Ab A Bb B C C# D D# E F F# G
When a user misplaces a note, they can tap the desired note name and SP will reposition the note on the nearest staff line (up or down) from the note's current position. This saves the user from trying to pick up a misplaced note, messing with cross hairs, etc.
Users must have the skill of reading notes in order to use the toolbar, which is a knowledge burden, I admit. But it seems like a reasonable burden for people who are constructing sheet music.
2. A Floating/Popup Note Edit Bar
The note edit bar is displayed when users change the SP Entry Mode to Note Entry. (For now, imagine the bar is below the note insertion site, so the user can see the note while tapping toolbar buttons.) The note edit toolbar contains all the functions of the left toolbar in note entry mode, and looks something like this:
First, from the posting "UI: Design for a pop-up edit bar for the selected note":
chord left (spc) flat natural sharp (space) down up tie (space) + - dot (space) type right X
or more concisely (where _ means a space, b=flat, n=natural, nt=note, rst=rest):
ch <- _ b n # _ dn up tie _ + - . _ nt rst -> X
To this design, we need to add (1) note length buttons for dragging, such as a series like 32 16 8 4 2 0 for length (+ - buttons no longer required), and (2) an OK button to lock in and deselect the current note, for users who want to use the edit bar to configure the FUTURE note too. The (reordered) toolbar could look like this:
ch <- _ dn up _ dot 32 16 8 4 2 0 _ b n # _ tie n r OK -> X
3. How Drag-and-Configure Works
To use drag-and-configure, users select note entry mode to display the floating/popup pitch and edit toolbars.
If no note is selected, the floating toolbars configure the FUTURE (next) note to be placed. This happens for the first note placed after entering Note Entry mode, or after users tap the OK button on the edit bar.
If a note _is_ selected, the floating toolbars configure the CURRENT (selected) note.
To enter a NOTE with no notes selected: drag a note length (from the 16, 8, 4, buttons) to the score; this creates a new note of that length, and leaves the CURRENT note selected on the score (so the floating toolbar buttons can configure it). Configure and place the note accurately using the floating toolbar buttons. Repeat this process for other notes.
To enter a REST with nothing selected, drag from the rest button to the score. This leaves the rest selected on the score, so floating buttons apply to the CURRENT selected item. Set the length by tapping on one of the length buttons (16 8 4, etc), or by tapping on the + / - length buttons, or by tapping on the dotted length button.
Starting a new drag operation to place a new note has several effects:
(1) It deselects the old selected note, if one is selected.
(2) It sets the type of the new note (or rest) by the drag starting point.
(3) It sets the initial note length (from the starting point of 16 8 4, etc).
(4) It uses all active configuration settings from the floating bar (sharp, tie, dot, etc) when it creates a new CURRENT note.
----
This summary gives you the main ideas, so I'll end this posting here because a more detailed post is too long to fit in the forums.
The main takeaway messages are these:
- The root cause of our note entry pain is the current "configure-and-place" model
- Users need configuration power for the CURRENT selected note, to make corrections
- Users need functional help to reduce configuration mistakes in the first place
- the Drag-and-Configure model is very efficient for both user needs
- The pitch bar solves the vertical placement problem.
- The edit bar solves the configuration power problem.
Currently the note entry process in SP is not optimal. There are several ways to enter notes - using just your hands, using the built in keyboard, or using an external keyboard. I limit my discussion here to placing notes on the score with fingers only -- no use of fretboards or internal or external keyboards. I think this way because using keyboards places an extra burden of knowledge (and possibly playing skills) on users who just want to enter notes on the score.
The main issues are these, in order, most frustrating first:
(1) Correcting misconfigured notes (eg if length or sharpness is wrong)
(2) Correcting horizontally misplaced notes (eg note didn't align with chord properly)
(3) Correcting vertically misplaced notes (eg note has the wrong pitch)
(4) Configuring notes with the left toolbar menu structures.
(5) Placing a configured note vertically.
(6) Placing a configured note horizontally.
Notice that the correction processes top the list, and not the act of initially placing a new note vertically and horizontally.
Seeking the Core Cause of the Note Entry Problem
It seems to me that the core cause of the note entry problem is the "configure-and-place" model of note entry. There are other UI issues that contribute to the problem but they are not the core. The "configure-and-place" model requires users to first configure the properties of a note (length, sharpness, etc) on the left toolbar, and then place the configured note on the score. There are several user-unfriendly aspects of this process.
For example, the user doesn't get to see the configured note in context until it's initally placed on the score, but by then it's too late to correct any misconfigurations or misplacements. The usual choice is to undo and start over.
--
The core cause of the problem is that the "configure-and-place" model restricts the configuration power of the left toolbar buttons to configuring ONLY the FUTURE (next) note that is about to be placed. (The toolbar power can be used if a note is selected in Entry Mode = Select mode.)
Currently, toolbar buttons cannot be used to change (correct) note properties while in note-entry mode. They can only be used (1) to configure the next FUTURE note in Note Entry mode, or (2) to correct a selected note in Selection mode. At the instant when users tap the screen and enter a misconfigured note, or a misplaced note, in Note Entry Mode, that's the same instant when the note becomes the CURRENT note, and the SP "configure-and-place" model takes away the toolbar power that users need to correct the entered note.
That's why note entry is so difficult -- mistakes are easy to make, and there's no corrective power available to users when they need it most.
Key Solutions to the Note Entry Problem
The three key solutions are to
(1) Use a "drag-and-configure" model
(1) Change the UI to help prevent entry errors in the first place, and
(2) Change the UI to give users corrective power for the CURRENT note.
All three solutions can be simultaneously implemented with a floating/popup "note edit bar", and a floating/popup "note pitch" toolbar. First I will explain the two toolbars required, and then I will show how they are used in the "drag-and-configure" model.
1. A Floating/Popup Note Pitch Bar
The pitch bar is displayed when users change the SP Entry Mode to Note Entry. (For now, imagine the bar is below the note insertion site, so the user can see the note while tapping toolbar buttons.)
The function of the pitch bar is to change the vertical pitch of a misplaced note (the CURRENT selected note). The pitch bar looks something like this (enharmonic names can be changed based on the key, I suppose).
Ab A Bb B C C# D D# E F F# G
When a user misplaces a note, they can tap the desired note name and SP will reposition the note on the nearest staff line (up or down) from the note's current position. This saves the user from trying to pick up a misplaced note, messing with cross hairs, etc.
Users must have the skill of reading notes in order to use the toolbar, which is a knowledge burden, I admit. But it seems like a reasonable burden for people who are constructing sheet music.
2. A Floating/Popup Note Edit Bar
The note edit bar is displayed when users change the SP Entry Mode to Note Entry. (For now, imagine the bar is below the note insertion site, so the user can see the note while tapping toolbar buttons.) The note edit toolbar contains all the functions of the left toolbar in note entry mode, and looks something like this:
First, from the posting "UI: Design for a pop-up edit bar for the selected note":
chord left (spc) flat natural sharp (space) down up tie (space) + - dot (space) type right X
or more concisely (where _ means a space, b=flat, n=natural, nt=note, rst=rest):
ch <- _ b n # _ dn up tie _ + - . _ nt rst -> X
To this design, we need to add (1) note length buttons for dragging, such as a series like 32 16 8 4 2 0 for length (+ - buttons no longer required), and (2) an OK button to lock in and deselect the current note, for users who want to use the edit bar to configure the FUTURE note too. The (reordered) toolbar could look like this:
ch <- _ dn up _ dot 32 16 8 4 2 0 _ b n # _ tie n r OK -> X
3. How Drag-and-Configure Works
To use drag-and-configure, users select note entry mode to display the floating/popup pitch and edit toolbars.
If no note is selected, the floating toolbars configure the FUTURE (next) note to be placed. This happens for the first note placed after entering Note Entry mode, or after users tap the OK button on the edit bar.
If a note _is_ selected, the floating toolbars configure the CURRENT (selected) note.
To enter a NOTE with no notes selected: drag a note length (from the 16, 8, 4, buttons) to the score; this creates a new note of that length, and leaves the CURRENT note selected on the score (so the floating toolbar buttons can configure it). Configure and place the note accurately using the floating toolbar buttons. Repeat this process for other notes.
To enter a REST with nothing selected, drag from the rest button to the score. This leaves the rest selected on the score, so floating buttons apply to the CURRENT selected item. Set the length by tapping on one of the length buttons (16 8 4, etc), or by tapping on the + / - length buttons, or by tapping on the dotted length button.
Starting a new drag operation to place a new note has several effects:
(1) It deselects the old selected note, if one is selected.
(2) It sets the type of the new note (or rest) by the drag starting point.
(3) It sets the initial note length (from the starting point of 16 8 4, etc).
(4) It uses all active configuration settings from the floating bar (sharp, tie, dot, etc) when it creates a new CURRENT note.
----
This summary gives you the main ideas, so I'll end this posting here because a more detailed post is too long to fit in the forums.
The main takeaway messages are these:
- The root cause of our note entry pain is the current "configure-and-place" model
- Users need configuration power for the CURRENT selected note, to make corrections
- Users need functional help to reduce configuration mistakes in the first place
- the Drag-and-Configure model is very efficient for both user needs
- The pitch bar solves the vertical placement problem.
- The edit bar solves the configuration power problem.
0
Comments
For drag-and-configure:
Start at the left end of the edit bar. Drag a note on to the screen somewhere close to the desired pitch, tap the desired note name (eg F#) button to have SP reposition the dragged note on to the desired pitch, then move right on the edit bar, pressing buttons to configure the note. Skip the buttons you are not interested in. When you're done, drag another note to start the process over again.
For configure-and-drag:
Start at the right end of the edit bar. Press OK to deselect the previous note, if there is a selected one. Proceed leftward along the edit bar, configuring the desired note (or rest). When you get to the length buttons, drag the desired length on to the score. Press more edit buttons to fix things if your configure-and-drag attempt didn't quite work out perfectly (smiling). Press OK to deselect the note, and to start the cycle over again.
I imagine this bar as a floating bar or window that I can tap into using my left thumb as I hold my ipad with both hands on my knee. The current left toolbar has 13 slots in the note entry (note length) toolbar, and I know from lots of experience that reaching down to the tie button (11th down?) and up to the entry mode (select, note entry, delete) button are both long reaches for my thumb.
So if I was implementing the pitch bar/window, I'd first try to see if I could make it 7 x 3, for the seven note names A-G down the center column 2, flats on the left in column 1, and sharps on the right in column 3, like so:
Ab A A#
Bb B
C C#
...etc
I think the pitch bar should be a floating bar, so people can position where they like. SP should remember and save the coordinates, so SP can restore the bar position the next time users go into note-entry mode.
It seems to me the pitch bar would solve all note positioning problems immediately. In any order, just drag a note close to where it has to go, and tap one of the note names -- presto! SP will move the note to the nearest instance of that note name on the stave. Or in the reverse order, tap a note name to configure the note, then drag it close and let it go -- presto! SP will snap the note into the nearest right place. Goodbye touchy note positioning problems...
1. I dropped 12 notes in random pitches on the score. No attempt to position them at all. This was to create a "pile of notes" (mentioned in previous posts) to configure. I couldn't drag them down individually with the current UI, so I just dropped a pile for configuring them.
2. I switched to Select mode. This did several things for me:
(1) It allowed me to select individual notes for configuration really easily just by tapping the note.
(2) It allowed me to pick up the selected note really easily to slide it up and down to change pitch. And I didn't have to worry AT ALL about accidentally generating a new note, like I do when I try to pick up the selected note in Note Entry mode.
(3) It allowed me to bring the full power of the left toolbar to bear on configuring a note that was visible on the score. Recall that the left toolbar is disabled in Note Entry mode after a note is dropped onto the score, because the toolbar can't tell if a toolbar tap is meant for the CURRENT note (just placed) or the FUTURE note (the next one to be placed).
These three things are all really important for productivity. So I dropped 12 notes on to the score, switched to Select mode, and started configuring the notes into chords etc from the Meditation score (my favorite test score for experiments). Here is what I found out:
(1) There was an immediate feeling of higher productivity. Tap a note to select it. Pick it up easily with your finger to drag it up and down to set the pitch, or tap the up/down arrows on the pop-up toolbar for fine positioning. Tap the toolbar buttons for note/rest type, length, dots, sharps, ties, triplets.
It was all immediate, all correct, all productive, and with no errors at all. This showed me how convenient and fast it was to have the full note configuration power available to configure a note that was on the score.
(2) There were some serious limitations (not surprising, really, since I was using the UI in a way that it was not designed to support):
- There's no way to drag the selected note left or right to form chords. This was such a showstopper that it ended my experiment really quickly. If there was no way to build chords, there was no point in trying to do a serious timed experiment entering Meditation notes (the piano part is full of chords).
- There were no cross hairs displayed, and no visible note name (eg F#, Ab) to the left of the cross hairs when I picked up a note to set its pitch. This was another huge limitation, because it made it impossible to drag the note to set pitch. The only way was to use the little up/down arrows on the pop-up toolbar to set pitch. (The explicit note name F# idea was suggested in a previous post.)
- But even the little toolbar had its issues. Because the positioning arrows are at the left side of the toolbar, and because you usually need to tap them 4 or 5 times to position a note, when I tapped them with my right forefinger, my big hand on my little IPad Mini often blocked my own view of the note on the score. (So if you implement any other similar toolbars, put the up/down arrows at the right side of the toolbar, so right hand users don't block their own view.)
I state once again that these limitations are not "faults" of SP, since I was using the UI in ways that it was not designed for in this experiment. I simply list the limitations as part of what I learned from the experiment.
---
It seems to me that this little experiment:
(1) Showed me how very, very, useful it was to have full note configuration power available to configure notes once they are on the score, and
(2) Convinced me more than ever that drag-and-configure is a much more productive way of entering notes than the existing configure-and-drop model.
The difference in the user experience was really quite striking (at least to me). All configuration changes were immediate, all visual feedback was immediate, all changes were correct, all changes were productive, and there were no errors at all. I think everyone should try this little experiment to see for themselves.
I tried to think "How can design a smooth and efficient UI _without_ using dragging? Just toolbars." This is what I came up with.
I mocked up some toolbars and menus on Post-It notes and stuck them to my IPad MIni, and then (virtually) entered the toughest section of violin/piano music I could find in the Meditation score. Lots of triplets, chords, dotted notes, and sharps/flats/naturals all over the place; rests, multiple voices, etc. So I think it was a good test of the trial menus, shown here:
https://www.dropbox.com/s/yut4ly0ezd4hq59/SP Toolbars 01.jpg?dl=0
Design Thinking
I want to figure out a better user interface while keeping the software development work to a minimum. The drag-and-configure model was my best idea so far, because it brought full configuration power to the CURRENT note (while still supporting the FUTURE note).
But I think these simple toolbar menus are even more productive than dragging (and a lot simpler to implement). I wanted to support two-handed note entry, in the style of all those people you've seen who text on their phones at lightning speed just with their thumbs.
A Better "New-and-configure" Model
Here's a summary of the new model -- let's call it "new-and-configure", because it uses a "New" button to generate a new note, not a drag operation.
Left Toolbar - Create and Place the Note/Rest
The left toolbar creates and places a new note, both vertically (pitch) and horizontally (chord).
I put the NEW button between B and C because the NEW button anchors the
thumb position, and is the most natural place directly under my left
thumb. Since all new notes start with this button, it is important to
give it the shortest, most convenient reach position. After SP sees the events "new, note" or "new chord note", or "new rest", it can place the note on the score. (At the last used pitch.)
The rows G-A trigger pop out menus that assign a pitch and no accidental, or a sharp/flat/natural accidental. The software places the requested note at the corresponding pitch point in the score. It picks the nearest pitch that matches. It can sound the note when it places it.
The bottom X row pops out a menu that lets you delete (X) the note, or move it up (8^) or down (8v) an octave if the software gets it wrong for some reason.
The next-to-bottom row (TP for type? CUR for 'current note'?) lets you change the type of the note from note, to chord, or to rest, in case you get the NEW operation wrong. (I think this row is probably not required, because it's easy to hit delete and do NEW over again. Less thinking is required, it's very fast, and I'd rather use the toolbar space for something else.)
Two taps are usually required to create a note and place it horizontally (as note, chord note, or rest), and two taps to place it vertically (pitch) with a proper accidental (the A-G buttons).
In my tests, this was a very rhythmic and very productive left thumb pattern, with good mental wording "New note, CC (no accidental); new chord EE; new note F#; etc.
Right Toolbar - Configure Length and Attributes
The right toolbar sets the length of the note, and applies ties, triplets, and all the usual stuff from the existing grace note button. In addition, I added a bottom row to change the horizontal postion of the note - make it a chord with the previous time slot, or move the current note to the left or right of its nearest neighbors (allow you to "insert" a note by sliding it left).
So the entire note entry pattern in words (and thumbs) is something like "New note CC 4; new note EE (defaults to 4 from previous sticky length setting); new note GG; new note CC dot; new rest 8; new note CC; new chord EE; new chord GG; .. etc
Dots, ties, triplets, and other configuration things are toggles by default, so they only apply to the current note. They are not sticky, and do not carry over to the next FUTURE note (like length does).
Summary
These menus felt very smooth, rhythmic, and productive to me. I could easily enter any note sequences that I saw in Meditation, normally without any mistakes at all. It was comfortable to use both thumbs to enter notes on any stave, and to change the configuration of a note after placing it. And none of the thumb reaches were too long or too awkward.
I think the software development work to implement this model is much less than the drag model (with floating toolbars) that I suggested earlier. It's just simpler all the way around - fixed toolbars, fixed menus, no dragging coordinates code, no toolbar coordinates code, etc.
I would go with this design for a first run. I can't imagine a simpler design for the users or developers.
"The main issues are these, in order, most frustrating first:
(1) Correcting misconfigured notes (eg if length or sharpness is wrong)
(2) Correcting horizontally misplaced notes (eg note didn't align with chord properly)
(3) Correcting vertically misplaced notes (eg note has the wrong pitch)
(4) Configuring notes with the left toolbar menu structures.
(5) Placing a configured note vertically.
(6) Placing a configured note horizontally."
but I don't think that improving these requires major UI changes.
For (4): The left hand side toolbar already provides an excellent way to select note configuration (next note in Insert mode, current note in Select mode), except that it would be twice as fast if it could be made two columns wide (at least for power users) so that all the most commonly used elements (including all notes and rests) are instantly available with a single click.
For (3): The most recently entered note in Insert mode (or the selected note in Select mode) has a blue rectangle around it. It can already be dragged up and down to the correct pitch within the current scale, which is all that's needed most of the time. This seems a better method of selecting pitch than a note menu.
For (2): You can currently undo and then re-place the note horizontally, but it would be great if you could drag the current note horizontally as well as vertically, especially to place it between existing notes (perhaps with the aid of cross-hairs) which is very tricky to do as a new note likes to attach to the nearest note.
For (1): I agree this is a major frustration: I very often want to change the note I just entered, and it requires two touches to change to Select mode plus two more to return to Insert mode. It would be great if you could make note configuration changes in Insert mode and then tell Symphony Pro to apply the new configuration to the last note entered (as well as the next note). One possibility would be to touch the blue rectangle for a short amount of time (say 0.5 seconds) in Insert mode to force the new configuration to be applied to that note. Or there could be a button for this purpose. This simple change of allowing changes to the last note in Insert mode seems like it would be straightforward to implement, without changing the familiar interface for existing users.
Thank you for participating and contributing your thoughts to the UI discussion. Generally speaking, more ideas on the table (with discussion) often translates into a better final set of ideas. I've added a response to your thoughts to further the discussion, I hope you don't mind.
First, I imagine that the SP guys will do (must do) what they think is workable and right in the end anyway, regardless of what our opinions are, so it seems to me that there's no risk for us to speak our minds honestly and openly, in the spirit of positive contributions.
We apparently agree on my little list of UI issues, which I listed to show that the main UI operational issues are centered around the problem of correcting the CURRENT note configuration in some way. (I keep capitalizing CURRENT / FUTURE notes because that's the core underlying source of most of the UI issues; so I hope people don't mind the (shouting?) caps.)
Operationally placing a misconfigured note is easy. Currently, just touch the screen, intentionally or accidentally (when trying to pick up and drag the current note).
But operational issues are not the same as conceptual design issues, which is where we start to diverge in our thinking.
You express the opinion that fixing some (4?) of the correction issues doesn't require major UI changes, and then give a clear, nicely separated paragraph of supporting thoughts for each of the four, none of which requires significant UI changes. In a sense, I agree with your phrase that "improving these" doesn't require the UI changes that I finally suggested. But I think we are aiming at different goals. I seek optimal, not just improvement.
I suppose the track record of my early posts started off with "improving" rather than "getting it to be optimal." I suggested some menu reworking (esp for Symbols), some toggles instead of pop out menus, and I even suggested a dual-row toolbar at some point. But as you can see, I still ended up at a significantly different place. Even with all the "improvement" changes, I still saw unsolved issues.
I think the main underlying causes are: (1) method of creating the CURRENT note (which is to touch the screen); (2) method of placing the note vertically (pick up and drag); (3) method of placing the note horizontally (pick up and drag, as you suggest); (4) and then all of the non-optimal menu structures that require too many clicks to execute.
---
I read your points several times, and would like to respond gently here...
Your 4 suggestions are all based on NOT changing the two big underlying causes of the UI issues listed above -- (1) create by touching/dropping, and (2) correct by dragging. (Keep in mind that create-by-touching embeds the FUTURE/CURRENT note model, which is the cause of the problem of the left toolbar being restricted to FUTURE configurations only.)
But it seems to me that until those two underlying causes are removed, we're just putting more bandaids on a bad underlying conceptual structure. Fix the underlying causes (as my last posting with ipad picture suggested), and all these corrective UI issues just fall away. The misconfiguration error rate drops to essentially zero, and corrections/configurations are typically one click away (no error-prone pick up and drag operations behind fingers with limited visibility and cross hairs (which are a bandaid) are required).
Some short thoughts on your points:
(4) I disagree that the left toolbar is an excellent way to configure notes; it's capable for the FUTURE note, disabled for the CURRENT note (because of the create-by-touch model), and far from efficient or optimal for all notes (as my previous click count postings have shown).
(3) Sorry to say again, I disagree with the whole method of correcting by the pick-up-and-drag model. First, why do I have to fix so many notes in the first place? (Because the create-by-touch-and-drag model is very error prone.) Second, picking up the current note by the little blue box is extremely error prone. I'm quite coordinated, but I'm only successful at pickups maybe 20% of the time or less. Third, why can't I just tap F, # to create a note in the right vertical place initially, or New, chord, F, #, to place it exactly right the first time, both vertically and horizontally?
(2) Again, perhaps because I fail so often at pick-up-and-drag, I disagree again. This point calls for yet more dragging (horizontally this time), with another cross hair bandaid to help users with the low-visibility, error-prone operation, because as you point out, "it is very tricky to do." In contrast, my UI model suggested a high-visibility 1-button tap to place the note horizontally in a chord (error free, pick-up-and-drag free, low visibility free, cross-hair free, time efficient, etc)
(1) I agree with your statement here, that correcting the current note is a major frustration. Why is it so frustrating? Because, you say (and you're right), that it takes 2 clicks to get to Select mode, 1 more to select the note, some to configure, 2 more to get to Insert mode, and (maybe, I haven't tried it) 1 more to select the stave to insert on. And then do it all over again for the next note. Ugh.
Then you suggest a tap-and-hold click (or a separate button) to apply the FUTURE configuration to the CURRENT note by explicit user action. That was a really nice creative idea, IMHO. Overcome the big left toolbar restriction between FUTURE/CURRENT with a simple tap-and-hold, or a button.
Just working with the idea now.... How can SP tell the difference between the T&H, and picking up a note and slowly moving it somewhere? I can't see how that would work, so T&H does not seem viable.
But a separate button seems viable (if you can find a toolbar place for it). The sequence: misconfigure the note and place it, then use the (not optimal) left toolbar menus to change configuration, then tap the APPLY button. That seems workable to me, but far from optimal. Why the misconfiguration in the first place? Use inefficient left toolbar menu structures to reconfigure, then an extra APPLY step required, etc.
So I agree that the APPLY button is an excellent improvement suggestion. It nails a big corrective issue, and gets the left toolbar power across the great FUTURE/CURRENT restriction with a single APPLY tap. Well done. (But I still think it's a magnificent single bandaid to one of several deeper problems. :-)
(1) It seems to me that zooming your screen (as a corrective/preventative band-aid) before placing notes with your finger is a clear admission that the existing UI is not capable/reliable enough to place notes properly without zooming and using cross-hair assistance. Corrective dragging after placement is a follow-on statement that further work is often required to place a note.
In contrast, the new-and-configure model does not require zooming. You can see more of your score context all the time. No work is required to zoom. The user view of the score is never blocked by moving hands or placing / dragging fingers in the normal note entry process.
(2) The existing model (let's be honest) requires zooming, requires hand movement (blocking views), requires helping aids (like cross-hairs), and requires a fair amount of delicate hand / finger positioning and coordination to place a note, or especially to pick up a note for corrective dragging. All these things add complexity, and require dexterity, to operate the UI.
In contrast, the new-and-configure model requires none of these things. No zooming, no large scale hand movements, no cross-hairs, no delicate fine finger movements, and no dragging to fix misplaced notes. Mostly no placement errors, period.
Just keep your hands at the edge of the screen so you can see the whole score window, and tap the convenient buttons (New + note + F + #) to place an F# note _exactly_ where you want it the first time around. No errors, no blocked views, no movements, no dragging, you get the idea. Just efficient, correct note entries, time after time.
(3) The new-and-configure model is much simpler conceptually, because it removes the need for the whole Entry Mode (select, note entry) model. At any time, users can tap New to start a new note entry sequence (auto-deselecting the current selected note). Or at any time, they can tap a note on the screen to select it and apply toolbar operations to it.
This is "mode-less" UI design because it has no modes such as the existing "mode-full" design (which includes Select, Entry, and Delete). Mode-less UI designs are much more preferable (if they are workable), because users don't have to remember modes, and don't have to remember to switch between them. (For a second example, the existing FUTURE / CURRENT note model is an implied mode for configuration operations, and look at the difficulty it causes.)
The new-and-configure model is mode-less in two ways.
(1) It does away with the existing FUTURE/CURRENT note model and its associated F/C detection and toolbar restriction issues. In other words, under new-and-configure, there is no Future/Current note distinction. There is only "the selected note", marked by a bigger blue box, if one exists.
(2) It does away with the existing Entry Mode (Select, Entry, Delete) model, because at any time, users can tap to select a note, or tap New to enter a new note. This change is a LOT easier for users to work with because they don't have to think about modes, and because toolbar configuration power is always available (no modes to restrict it).
New-and-configure is easier for developers too, because there is no need to code around, and maintain, state variables for Entry Mode (Select, Entry, Delete) or for Future/Current notes. (For devs: If there's a note selected, apply toolbar events to it. If there's no note selected, ignore toolbar configuration events. Clean and simple.)
I guess I'm trying to say that new-and-configure is a simpler, better UI model (in many ways), because it solves the core underlying causes of the current UI issues, by not generating the issues in the first place (misconfiguration, misplacement, difficulty of fixing notes, hand movements, delicate finger operations, ... the list goes on).
New-and-configure simplifies the UI with a mode-less design, keeps the hands off the screen in "home" position, makes note placement exact and easy, makes note configuration easy, and makes the coding as easy as possible too (basic toolbar / menu code).
I think it would be difficult to present a better overall UI model / solution here. If someone does have a better overall model, I hope they post it... But if not, then new-and-configure is the best solution on the table, and therefore should be the target of future implementation efforts (at least according to the software dev conventions that I used for 25 years... Why would you devote precious dev resources to less-than-best solutions?)
It seems to me that it's up to the SP team now. Of course they have a bigger overall SP picture to consider than just the UI component, and they also have many implementation and resource constraints that necessarily influence their development path thinking. But at least this thread is trying to give them some clear thinking, reasoning, and targets for a better UI. That's our part, I suppose, and I hope we're doing it well.. :-)
I think my suggested new-and-configure model (with new left pitch toolbar and right side length/sharp toolbar) is compatible with the existing UI. In software-speak, I think they can co-exist side by side. SP could flip between the models with a mode button (eg Select, Enter, Delete, new-and-configure), or with a settings preference.
So I am not arguing in this thread that my suggested UI replace the existing UI (although I would asap, if SP was my product). Here is how they could coexist, if that's something that others and the SP team would like to do.
Add another menu choice to the current entry mode menu so users can voluntarily access the mode (Maybe label it "Adv" for advanced, or show a label '2T' or an icon with two little hands with thumbs up to mean "2 thumbs" entry mode. :-))
Display the left pitch bar and right length bar, and put SP into "Select" mode in the background, so if users tap a note, it gets selected, as usual. Users can now enter new notes with the toolbars, as explained at length above.
Users can tap to select, and then drag the selected note up and down, as usual. Or tap/hold and drag to select a region, as normal. All the existing touch screen operations remain unchanged, since new-and-configure is limited to toolbar changes only. The only touch screen operation that is removed is the tap that creates a new note (you know, the one that creates all those messy UI misconfiguration, misplacement, and pick-up-to-drag issues! :-)).
If users prefer the old way of doing things, they can just revert the preference setting, or tap the normal entry mode button. (If you keep the old entry mode around, I would add Redwave's excellent APPLY button to the UI somewhere, because it at least partially solves the lack of toolbar power for correcting misconfigured notes.)
Hopefully this posting shows that the suggested new-and-configure UI model is really not the giant UI changer that it might seem to be on initial inspection. You can hide the whole thing behind a preference setting or make it more visible as a choice on the existing Entry Mode menu, as you please.
Since new-and-configure can coexist peacefully with the existing UI (as explained above), it makes it easier for devs to implement because there's no need to have big internal UI arguments. It's simple menu / toolbar coding for the most part, so it's fairly low dev cost. Peaceful coexistence helps users too -- each person can just choose the UI that they like best.
(smiling now...) And when it comes time to phase out the old UI, you can just ship SP with the new one enabled, and make the old one available on a preference setting...