search

sugarlabs / musicblocks

Music Blocks -- A musical microworld
https://musicblocks.sugarlabs.org/
GNU Affero General Public License v3.0
565 stars 762 forks source link

Define the behavior of each block that could be put into the Pitch-TIme Matrix #201

Closed pikurasa closed 5 years ago

pikurasa commented 8 years ago

Hi,

So I demoed the software with someone today and we ran into the following conceptual issues.

  1. New users want to put rhythm blocks (from the Matrix) into the coding language stacks.
  2. New users want to put note blocks into the matrix stack.
  3. New users want to play/stop the music (especially stop) running in the matrix using the top toolbar.

...basically, it is not self evident where the "matrix world" ends and the "programming language" for scripting the notes begins.

Others have mentioned this as well. Some students at our workshop had problems with this as well, too.

So, what do you think we do?

@erilyth @hemantkasat @khandelwalYash , I am really interested in your opinion.

Devin

walterbender commented 8 years ago

So, what do you think we do?

  • Do we have a separate workspace for our widgets--separate from the music coding language scripts?

I think we could have separate workspaces that generate TB code, but we should make these widgets work in TB as well.

  • Do we create error messages to tell the user what can and cannot be done?

Yes, but...

  • Do we think of creative behavior for when users try these actions?

I think this should be our priority. (1) Rhythm blocks are a tough one... probably an error message (or maybe treat them like drum beats? or some sort of grace element?) (2) Notes in the matrix already works. (3) No reason not to make the main buttons (play, save, etc.) work as matrix buttons when the matrix is open.

I am guessing we can find useful things to do with most blocks (we should head down the path of adding graphics blocks to the matrix as we have discussed previously.

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

pikurasa commented 8 years ago

Okay, I will draft something up...

khandelwalYash commented 8 years ago

I have 2 things in my mind:

The second idea can be executed by keeping a tutorial mode for the software. This can be just a button. If user turns the tutorial mode on, then the help messages will be displayed when the user uses the corresponding blocks for the first time!

walterbender commented 8 years ago

FWIW, I add a Rhythm block to the Tuplet block by default when grabbing it from the palette. One small step down the path of making sensible defaults.

pikurasa commented 8 years ago

FWIW, I add a Rhythm block to the Tuplet block by default when grabbing it from the palette. One small step down the path of making sensible defaults.

Yeah, I really like that.

Also, I like that the note blocks play when you click them (maybe this was fixed long ago? Just noticed...)

erilyth commented 8 years ago

@pikurasa @khandelwalYash I like the idea of showing help messages when users use blocks for the first time. It was tough when I was getting started and I got quite a bit confused as well.

I would like to work on this feature. @pikurasa any suggestions for the text to display on "help" for each of the blocks from the "matrix world"?

walterbender commented 8 years ago

FWIW, the Python version of Turtle Blocks does this. I have mixed feeling about it, but it is a good source for short help messages for most of the non-music-related blocks. Perhaps we can just provide a link into the guide for the matrix at the top of the matrix palette? Similarly for the other palettes?

On Thu, Feb 25, 2016 at 5:48 AM, Batchu Venkat Vishal < notifications@github.com> wrote:

@pikurasa https://github.com/pikurasa @khandelwalYash https://github.com/khandelwalYash I like the idea of showing help messages when users use blocks for the first time. It was tough when I was getting started and I got quite a bit confused as well.

I would like to work on this feature. @pikurasa https://github.com/pikurasa any suggestions for the text to display on "help" for each of the blocks from the "matrix world"?

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

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

erilyth commented 8 years ago

@walterbender but don't you think the users would refrain from visiting links outside the activity for help?

walterbender commented 8 years ago

Let's think about (1) the help style vs (2) where the help files are located.

Regarding (1), I think help in context is great, but the turtle implementation suffers from (a) being annoying -- think pop ups and (b) being too terse and specific to individual blocks. Seeing example code I think is better, which the guide can provide. (How do you add anchors to Markup? We should be able to direct the user to specific entries in the Guide.)

Regarding (2), not sure I understand what it even means on the web to be outside of the activity. If you are concerned about offline mode, we can open the "file" version of the Guide.

On Thu, Feb 25, 2016 at 7:07 AM, Batchu Venkat Vishal < notifications@github.com> wrote:

@walterbender https://github.com/walterbender but don't you think the users would refrain from visiting links outside the activity for help?

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

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

erilyth commented 8 years ago

@walterbender regarding 1) Okay, I understand your concerns. Do you mean adding anchors to .md files? I think this can help Add anchors to markdown 2) I was talking about the offline mode, didn't think of the file version earlier. So that won't be a problem I guess.

erilyth commented 8 years ago

@walterbender Or we could port the guide to an HTML document if it doesn't hinder any other uses of the guide.

walterbender commented 8 years ago

An HTML version would probably be good.

On Thu, Feb 25, 2016 at 8:26 AM, Batchu Venkat Vishal < notifications@github.com> wrote:

@walterbender https://github.com/walterbender Or we could port the guide to an HTML document if it doesn't hinder any other uses of the guide.

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

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

walterbender commented 8 years ago

The main menu run fast and run slow buttons work with the matrix now. Have not implemented step by step or note by note yet.

pikurasa commented 8 years ago

I think we could have separate workspaces that generate TB code, but we should make these widgets work in TB as well.

To the comment about the code, yes of course we want to keep the code for the Matrix in the UI (I like the "scripting the matrix" idea -- even though it the matrix more a widget that actual code itself).

Does it make sense to separate our widgets in a separate area of the screen? I think that is what I am getting at -- I think it might be better to segregate the "widget scripting" from the actual "programming language scripting".

@walterbender I know you cringe everytime you hear the name, but maybe there is something we can learn from the UI of the following program:

Nameless other visual programming language UI

Are there coding pedagogical reasons not to have separate workspaces like in the above example?

walterbender commented 8 years ago

I think that screen space is always at a premium and hence to chop the screen up into separate sections is just making the situation worse I see no advantage in MB, where the typical use is sound only. So really the two panels on the left in MB would serve no purpose at all. Then the only difference is the palette is in a scrollable panel as opposed to floating. What is the advantage you see that I am missing?

On Sat, Mar 5, 2016 at 8:32 PM, Devin Ulibarri notifications@github.com wrote:

I think we could have separate workspaces that generate TB code, but we should make these widgets work in TB as well.

To the comment about the code, yes of course we want to keep the code for the Matrix in the UI (I like the "scripting the matrix" idea -- even though it the matrix more a widget that actual code itself).

Does it make sense to separate our widgets in a separate area of the screen? I think that is what I am getting at -- I think it might be better to segregate the "widget scripting" from the actual "programming language scripting".

@walterbender https://github.com/walterbender I know you cringe everytime you hear the name, but maybe there is something we can learn from the UI of the following program:

[image: Nameless other visual programming language UI] https://camo.githubusercontent.com/ca13f3a754ce498c12271d4393b898ff7f795d0d/68747470733a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f636f6d6d6f6e732f372f37362f536372617463685f322e305f44656661756c745f73637265656e2e706e67

Are there coding pedagogical reasons not to have separate workspaces like in the above example?

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

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

pikurasa commented 8 years ago

My comment missed its mark (as I thought it might). Presenting the image was not meant to suggest a literal take from what they have...

I will create a mash up in GIMP with the idea I have in mind.

The only take away I am suggesting is a separate space for widgets--that is it!

pikurasa commented 8 years ago

This is what I am thinking about...

ui-mash-up-proposal-3-annotated

The idea is:

  1. There seems to be "widget-specific" code and visual output, which is different than the "main code". It is confusing to have it all in the same workspace, I think. ...it is creating clutter...
  2. I am dreaming up 5 main widgets, so I think that we need to get these under control or the resulting clutter will take over the entire UI.
  3. Cleaning things up also helps to discern the "widget-specific" toolbar tools (i.e. playback tools for matrix) without interfering with the toolbar stuff for main code.
  4. We should have a show/hide (which I put in the image as well) for the widget bar, because I totally agree that screenspace is prime real estate.

If you want to mash up my mash up and posit something different, it might save you time to download and use the following files (I used all images as separate layers in GIMP):

http://owncloud.libretools.com/index.php/s/C6vsGtxrD04LEmi

walterbender commented 8 years ago

Rather than break things up, why not allocate the whole screen to the widget and just show the palettes and blocks that are appropriate to the widget? So when you click on the matrix button you see the appropriate palettes and the matrix blocks and the matrix itself. Will need more thought though.

On Sat, Mar 5, 2016 at 11:22 PM, Devin Ulibarri notifications@github.com wrote:

This is what I am thinking about...

[image: ui-mash-up-proposal-3-annotated] https://cloud.githubusercontent.com/assets/13454579/13552250/d200d604-e328-11e5-8f2a-01c4011c8833.png

The idea is:

  1. There seems to be "widget-specific" code and visual output, which is different than the "main code". It is confusing to have it all in the same workspace, I think. ...it is creating clutter...
  2. I am dreaming up 5 main widgets, so I think that we need to get these under control or the resulting clutter will take over the entire UI.
  3. Cleaning things up also helps to discern the "widget-specific" toolbar tools (i.e. playback tools for matrix) without interfering with the toolbar stuff for main code.
  4. We should have a show/hide (which I put in the image as well) for the widget bar, because I totally agree that screenspace is prime real estate.

If you want to mash up my mash up and posit something different, it might save you time to download and use the following files (I used all images as separate layers in GIMP):

http://owncloud.libretools.com/index.php/s/C6vsGtxrD04LEmi

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

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

pikurasa commented 8 years ago

Rather than break things up, why not allocate the whole screen to the widget and just show the palettes and blocks that are appropriate to the widget? So when you click on the matrix button you see the appropriate palettes and the matrix blocks and the matrix itself.

This approach is worth investigating. One place, however, that would potentially be lacking is seeing both a) the widget workflow and b) the results/output of the widget workflow on the same screen. We would need to account for this somehow, so that the user can see clearly how their work in widget-land results in the main code.

pikurasa commented 7 years ago

The analysis charts that @Tabs16 and GCI students are helping to create should help us understand this issue better.

Tabs16 commented 7 years ago

Yes,it will provide a holistic overview .

pikurasa commented 5 years ago

FWIW, @walterbender's comment from this thread (above and quoted below) was my rationale for requesting the full-screen option for the widget:

https://github.com/sugarlabs/musicblocks/issues/201#issuecomment-192914900

Rather than break things up, why not allocate the whole screen to the
widget and just show the palettes and blocks that are appropriate to the
widget? So when you click on the matrix button you see the appropriate
palettes and the matrix blocks and the matrix itself. Will need more
thought though.

From my original issue, this is what I see as our current status on this issue:

  1. New users want to put rhythm blocks (from the Matrix) into the coding language stacks. Solved as this creates a rhythm with sounds in the specified drum/instrument
  2. New users want to put note blocks into the matrix stack. This is not problematic anymore as this transcribes the blocks into the matrix
  3. New users want to play/stop the music (especially stop) running in the matrix using the top toolbar. This is still problematic for new users. The play button for the code is often mistaken to play the widgets.

2 out of three ain't bad. I think what we need is to take another look at our widget design (full screen? and if not, what to do to make play/stop and other tools more obvious).