User Interaction for Matrix Improvement

[sugarlabs]

User Interaction for Matrix Improvement

[khandelwalYash]

Try it out!
http://rawgit.com/khandelwalyash/musicblocks-1/master/index.html
make the matrix, add notes to it then change the # notes of rhythm block. After that click on the 'black and white' clear button(svg needs to be changed) on top. It'll re-render the matrix keeping the unchanged notes unaffected

[walterbender]

Let's review. I am not 100% that we have the right UX defined. Meanwhile,
I made a patch to let you recreate the matrix from a chunk. But I am not
yet making the selected cells.
On Oct 13, 2015 4:11 PM, "Yash Khandelwal" [email protected] wrote:

http://rawgit.com/khandelwalyash/musicblocks-1/master/index.html
@pikurasa https://github.com/pikurasa make the matrix, add notes to it
then change the # notes of rhythm block. After that click on the 'black and
white' clear button(svg needs to be changed) on top. It'll re-render the
matrix keeping the unchanged notes unaffected

—
Reply to this email directly or view it on GitHub
https://github.com/walterbender/musicblocks/issues/27#issuecomment-147838495
.

[pikurasa]

@khandelwalYash This is one step in the right direction because it is able to refresh the matrix after the user has input a new argument into a rhythm block.

However, it falls short in two ways.

1. We would want it to be able to accept more rhythm blocks, with their respective arguments. (tested)
2. We would also want it to be able to accept more pitch blocks as well. (tested)

If it were able to do all of these things with reliability, I think that we would have a real improvement.

As always, good work!

[pikurasa]

@walterbender Are you proposing that a different design would be better?

I think, for starters, this would be a patch that could improve the users experience quite a bit. I also imagined it to be fairly simple compared to other things that I also came up with.

We should, however, have a separate icon (refresh arrow) and put it onto the matrix, I think. The black and white eraser is unclear. However, I think we are just doing that to have something to work with for the short term.

(something like this: https://cdn3.iconfinder.com/data/icons/3d-printing-icon-set/512/Refresh.png)

[walterbender]

I don't have any great ideas yet. Still thinking about it.

On Tue, Oct 13, 2015 at 10:46 PM, Devin Ulibarri [email protected]
wrote:

@walterbender https://github.com/walterbender Are you proposing that a
different design would be better?

I think, for starters, this would be a patch that could improve the users
experience quite a bit. I also imagined it to be fairly simple compared to
other things that I also came up with.

We should, however, have a separate icon (refresh arrow) and put it onto
the matrix, I think. The black and white eraser is unclear. However, I
think we are just doing that to have something to work with for the short
term.

(something like this:
https://cdn3.iconfinder.com/data/icons/3d-printing-icon-set/512/Refresh.png
)

—
Reply to this email directly or view it on GitHub
https://github.com/walterbender/musicblocks/issues/27#issuecomment-147908772
.

Walter Bender
Sugar Labs
http://www.sugarlabs.org

[khandelwalYash]

@walterbender Let us know what you think about the UX
@pikurasa Thanks! I'll make the re-render work for pitch as well as multiple rhythms.

[pikurasa]

I think Walter is saying that he suspects there may be a better way--and I also have that feeling this may be true. However, all the "other ways" I thought of seem very challenging to implement and this sounded doable for the near future. It is also congruent with our current "block world" or "block interface"

@khandelwalYash Just let me know when you have made the patch.

[walterbender]

We need to come up with a rigorous design.

[pikurasa]

GOAL: Flexibility at MATRIX level of User Interface

I was thinking this would be a patch that would work with what we have now that would make a subtle but important improvement to the UI and user interaction at the level of the matrix. Basically the same as if adding rows and columns to a spreadsheet (adding keeping original values, which are Boolean now--note = on/off).

Other ideas I could come up with would need a major refurbishing...

Walter mentioned (something to the effect) that, currently, Turtle Code does not keep track of the individual blocks so that would be one challenge to implementing a system like this.

[pikurasa]

I have continued to ponder this issue and keep coming to the same conclusion. Any other solutions or improvements I can think of have more to do with the GUI than the underpinnings of what the user really needs to get stuff done. Yes, my solution is basically the same interface for spreadsheet software, but is that so terrible? Everyone is familiar with spreadsheets so I think they will get the idea without having to read any manuals. I liked where Yash was going with this with his last patch.

That being said, I did take some time to write out all my thoughts to get toward a design without any loose ends and will put it below. If this is not going to work, please identify specific places that need to be rethought.

PROBLEM: The Matrix must be re-rendered in order to make even small changes
Right now, if the user scripts the incorrect pitch or rhythm (as input for Matrix Block) they must re-render the entire matrix. This has been only a minor problem for me as I test things because, as a trained musician, I have a good understanding of what I want to create and what I need to do to get the software to do what I am imagining (I am basically just translating one code to another in my head—EASY!). However, the rigid design of the matrix may become a frustration for new users, who unfamiliar either with music, the matrix, or with our software will make mistakes when trying to input what they imagine onto the matrix.

GOAL: Flexibility at MATRIX level of User Interface

IDENTIFIABLE USER POSSIBILITIES:

• Adding Pitch Blocks
• Deleting Pitch Blocks
• Changing Pitch Values on Contained Pitch Blocks
• Changing Octave Values on Contained Pitch Blocks
• Reordering Pitch Blocks in a stack
• Adding Rhythm Blocks
• Deleting Rhythm Blocks
• Changing Number of Notes values on contained rhythm blocks
• Changing Rhythmic Values on contained rhythm blocks
• Reordering Rhythm Blocks in a stack

MY PROPOSED SOLUTION:
Let's give the user a way to dynamically add/delete pitch/rhythm blocks from the matrix and change pitch/rhythm block parameter values without losing the work that they have already done.

1. If the user adds new pitch/rhythm block(s) to matrix stack, when the matrix is re-rendered all of the other columns would remain unaffected but the new row/column will be completely blank by default. Stack order would be maintained; if the added pitch/rhythm block(s) are inserted between existing blocks, the new (blank) row/column would appear in its respective position.
2. If the user deletes new pitch/rhythm block(s) to matrix stack that had note(s) chosen, those note(s) will simply disappear, but all other unchanged note(s) will remain unaffected. Stack order is maintained for all remaining (and unchanged) rows/columns.
3. If the user changes the Number of Notes parameter value on a rhythm block, that should be treated as an addition/deletion to the rhythm (as defined above).
4. If the user changes a value for the (a) rhythmic value, (b) pitch value, and (c) octave value parameters, then the rhythmic value, pitch value, and/or octave values alter the values for their respective rows/columns. These changes are independent of any additions/deletions to rows/columns as defined above; points on the matrix with notes already input will remain—they will just represent notes of a different value(s) respective to the changes made by the user.
5. We would need a "re-render" button as a separate button from "clear" (the latter of which will be used by the user for a complete restart). (Yash already did something like this in the last patch)

IMPORTANT NOTES:
Walter mentioned (something to the effect) that, currently, Turtle Code does not keep track of the individual blocks so that would be one challenge to implementing a system like this.

SET THEORY OPERATORS AND THE MATRIX: THINKING AHEAD:
The above solution, I think, solves the issue of flexibility for the matrix. Other issues that I find that would remain after implementation of these design improvements can be dealt with in other ways, namely we can tackle the issue of pitch order when we introduce set theory operators. For example, right now it is up to the user to order all of the pitches themselves. Pitch being faithfully ordered exactly as the user has scripted it by the matrix is by no means problematic in itself. We want to maintain the open-ended nature of the matrix scripting—the notes rendered on the matrix do not always need to be in order of pitch and it would be overly rigid design to have it do order pitches without the user's requesting it to do so. Instead, order can be achieved through set theory blocks (https://en.wikipedia.org/wiki/Set_theory_%28music%29), which be either ordered or unordered (maybe even a separate "ordering" block for ordering a contained set [of pitches]).

[walterbender]

This is all fine except that when we consider tuplets things suddenly get
very complicated.

On Wed, Nov 4, 2015 at 3:33 PM, Devin Ulibarri [email protected]
wrote:

I have continued to ponder this issue and keep coming to the same
conclusion. Any other solutions or improvements I can think of have more to
do with the GUI than the underpinnings of what the user really needs to get
stuff done. Yes, my solution is basically the same interface for
spreadsheet software, but is that so terrible? Everyone is familiar with
spreadsheets so I think they will get the idea without having to read any
manuals. I liked where Yash was going with this with his last patch.

That being said, I did take some time to write out all my thoughts to get
toward a design without any loose ends and will put it below. If this is
not going to work, please identify specific places that need to be
rethought.

PROBLEM: The Matrix must be re-rendered in order to make even small
changes
Right now, if the user scripts the incorrect pitch or rhythm (as input for
Matrix Block) they must re-render the entire matrix. This has been only a
minor problem for me as I test things because, as a trained musician, I
have a good understanding of what I want to create and what I need to do to
get the software to do what I am imagining (I am basically just translating
one code to another in my head—EASY!). However, the rigid design of the
matrix may become a frustration for new users, who unfamiliar either with
music, the matrix, or with our software will make mistakes when trying to
input what they imagine onto the matrix.

GOAL: Flexibility at MATRIX level of User Interface

IDENTIFIABLE USER POSSIBILITIES:

• Adding Pitch Blocks
• Deleting Pitch Blocks
• Changing Pitch Values on Contained Pitch Blocks
• Changing Octave Values on Contained Pitch Blocks
• Reordering Pitch Blocks in a stack
• Adding Rhythm Blocks
• Deleting Rhythm Blocks
• Changing Number of Notes values on contained rhythm blocks
• Changing Rhythmic Values on contained rhythm blocks
• Reordering Rhythm Blocks in a stack

MY PROPOSED SOLUTION:
Let's give the user a way to dynamically add/delete pitch/rhythm blocks
from the matrix and change pitch/rhythm block parameter values without
losing the work that they have already done.

1. If the user adds new pitch/rhythm block(s) to matrix stack, when the
   matrix is re-rendered all of the other columns would remain unaffected but
   the new row/column will be completely blank by default. Stack order would
   be maintained; if the added pitch/rhythm block(s) are inserted between
   existing blocks, the new (blank) row/column would appear in its respective
   position.
2. If the user deletes new pitch/rhythm block(s) to matrix stack that had
   note(s) chosen, those note(s) will simply disappear, but all other
   unchanged note(s) will remain unaffected. Stack order is maintained for all
   remaining (and unchanged) rows/columns.
3. If the user changes the Number of Notes parameter value on a rhythm
   block, that should be treated as an addition/deletion to the rhythm (as
   defined above).
4. If the user changes a value for the (a) rhythmic value, (b) pitch
   value, and (c) octave value parameters, then the rhythmic value, pitch
   value, and/or octave values alter the values for their respective
   rows/columns. These changes are independent of any additions/deletions to
   rows/columns as defined above; points on the matrix with notes already
   input will remain—they will just represent notes of a different value(s)
   respective to the changes made by the user.
5. We would need a "re-render" button as a separate button from "clear"
   (the latter of which will be used by the user for a complete restart).
   (Yash already did something like this in the last patch)

IMPORTANT NOTES:
Walter mentioned (something to the effect) that, currently, Turtle Code
does not keep track of the individual blocks so that would be one challenge
to implementing a system like this.

SET THEORY OPERATORS AND THE MATRIX: THINKING AHEAD:
The above solution, I think, solves the issue of flexibility for the
matrix. Other issues that I find that would remain after implementation of
these design improvements can be dealt with in other ways, namely we can
tackle the issue of pitch order when we introduce set theory operators. For
example, right now it is up to the user to order all of the pitches
themselves. Pitch being faithfully ordered exactly as the user has scripted
it by the matrix is by no means problematic in itself. We want to maintain
the open-ended nature of the matrix scripting—the notes rendered on the
matrix do not always need to be in order of pitch and it would be overly
rigid design to have it do order pitches without the user's requesting it
to do so. Instead, order can be achieved through set theory blocks (
https://en.wikipedia.org/wiki/Set_theory_%28music%29), which be either
ordered or unordered (maybe even a separate "ordering" block for ordering a
contained set [of pitches]).

—
Reply to this email directly or view it on GitHub
https://github.com/walterbender/musicblocks/issues/27#issuecomment-153854290
.

Walter Bender
Sugar Labs
http://www.sugarlabs.org

[pikurasa]

The solution for Tuplet, I imagine, would be the combination of what is proposed for BOTH changing #of notes AND rhythmic value parameters.

There are other corner cases as well (pitch and rhythm inside action blocks, reordering blocks without add/delete, use of repeat etc.), but they should all be addressed by combinations of what is proposed above.

Can you think of any that cannot be addressed by combinations of the above?

I am currently away from my computer, my desk and all associated conveniences. Please excuse my brevity and any typos.
www.devinulibarri.com

On November 4, 2015 4:12:52 PM EST, Walter Bender [email protected] wrote:

This is all fine except that when we consider tuplets things suddenly
get
very complicated.

On Wed, Nov 4, 2015 at 3:33 PM, Devin Ulibarri
[email protected]
wrote:

I have continued to ponder this issue and keep coming to the same
conclusion. Any other solutions or improvements I can think of have
more to
do with the GUI than the underpinnings of what the user really needs
to get
stuff done. Yes, my solution is basically the same interface for
spreadsheet software, but is that so terrible? Everyone is familiar
with
spreadsheets so I think they will get the idea without having to read
any
manuals. I liked where Yash was going with this with his last patch.

That being said, I did take some time to write out all my thoughts to
get
toward a design without any loose ends and will put it below. If this
is
not going to work, please identify specific places that need to be
rethought.

PROBLEM: The Matrix must be re-rendered in order to make even small
changes
Right now, if the user scripts the incorrect pitch or rhythm (as
input for
Matrix Block) they must re-render the entire matrix. This has been
only a
minor problem for me as I test things because, as a trained musician,
I
have a good understanding of what I want to create and what I need to
do to
get the software to do what I am imagining (I am basically just
translating
one code to another in my head—EASY!). However, the rigid design of
the
matrix may become a frustration for new users, who unfamiliar either
with
music, the matrix, or with our software will make mistakes when
trying to
input what they imagine onto the matrix.

GOAL: Flexibility at MATRIX level of User Interface

IDENTIFIABLE USER POSSIBILITIES:

• Adding Pitch Blocks
• Deleting Pitch Blocks
• Changing Pitch Values on Contained Pitch Blocks
• Changing Octave Values on Contained Pitch Blocks
• Reordering Pitch Blocks in a stack
• Adding Rhythm Blocks
• Deleting Rhythm Blocks
• Changing Number of Notes values on contained rhythm blocks
• Changing Rhythmic Values on contained rhythm blocks
• Reordering Rhythm Blocks in a stack

MY PROPOSED SOLUTION:
Let's give the user a way to dynamically add/delete pitch/rhythm
blocks
from the matrix and change pitch/rhythm block parameter values
without
losing the work that they have already done.

1. If the user adds new pitch/rhythm block(s) to matrix stack, when
   the
   matrix is re-rendered all of the other columns would remain
   unaffected but
   the new row/column will be completely blank by default. Stack order
   would
   be maintained; if the added pitch/rhythm block(s) are inserted
   between
   existing blocks, the new (blank) row/column would appear in its
   respective
   position.
2. If the user deletes new pitch/rhythm block(s) to matrix stack that
   had
   note(s) chosen, those note(s) will simply disappear, but all other
   unchanged note(s) will remain unaffected. Stack order is maintained
   for all
   remaining (and unchanged) rows/columns.
3. If the user changes the Number of Notes parameter value on a
   rhythm
   block, that should be treated as an addition/deletion to the rhythm
   (as
   defined above).
4. If the user changes a value for the (a) rhythmic value, (b) pitch
   value, and (c) octave value parameters, then the rhythmic value,
   pitch
   value, and/or octave values alter the values for their respective
   rows/columns. These changes are independent of any
   additions/deletions to
   rows/columns as defined above; points on the matrix with notes
   already
   input will remain—they will just represent notes of a different
   value(s)
   respective to the changes made by the user.
5. We would need a "re-render" button as a separate button from
   "clear"
   (the latter of which will be used by the user for a complete
   restart).
   (Yash already did something like this in the last patch)

IMPORTANT NOTES:
Walter mentioned (something to the effect) that, currently, Turtle
Code
does not keep track of the individual blocks so that would be one
challenge
to implementing a system like this.

SET THEORY OPERATORS AND THE MATRIX: THINKING AHEAD:
The above solution, I think, solves the issue of flexibility for the
matrix. Other issues that I find that would remain after
implementation of
these design improvements can be dealt with in other ways, namely we
can
tackle the issue of pitch order when we introduce set theory
operators. For
example, right now it is up to the user to order all of the pitches
themselves. Pitch being faithfully ordered exactly as the user has
scripted
it by the matrix is by no means problematic in itself. We want to
maintain
the open-ended nature of the matrix scripting—the notes rendered on
the
matrix do not always need to be in order of pitch and it would be
overly
rigid design to have it do order pitches without the user's
requesting it
to do so. Instead, order can be achieved through set theory blocks (
https://en.wikipedia.org/wiki/Set_theory_%28music%29), which be
either
ordered or unordered (maybe even a separate "ordering" block for
ordering a
contained set [of pitches]).

—
Reply to this email directly or view it on GitHub

https://github.com/walterbender/musicblocks/issues/27#issuecomment-153854290
.

Walter Bender
Sugar Labs
http://www.sugarlabs.org

---

Reply to this email directly or view it on GitHub:
https://github.com/walterbender/musicblocks/issues/27#issuecomment-153866970

[walterbender]

I think we have covered this with the restore matrix code. Please reopen if you disagree.