a way for users to quickly see the value of their variables without having to create a text-sprite

[stevekrouse]

Idea 1: have a show() function to show variables

Idea 2: have a development mode for Woof that has an easy way to show variables. Maybe a plus button on the output screen where you type an expression

[stevekrouse]

We used to accomplish this with the debug() function but I took that out because it confused students.

Idea 3: Tynker has a button that looks like a bug that pops open an expression value viewer which is neat:

It wouldn't be hard for us to do this for all of the sprites in a user's program because we have those in the sprites variable.

We'd probably also want a way for a user to add a custom expression here so they can see more relevant data to their usecase.

Unlike how Tynker does it with a popup that obscures what's happening, It would be cool if we could do this in a way that's side-by-side with the project output so you can watch how your data changes as you play your game.

[madduccino]

Here's some recent feedback from a teacher that I think relates to this issue:

It would be awesome to have a way to print in WoofJs! I ended up showing a student how to use console.log and open up the developer console, but it was a bit difficult to see on the small computer screen.

The specific thing she wanted to do was print an array as well as an item at a given index in that array.

I'd be interested in tackling this if you think it makes sense.

[stevekrouse]

Definitely! Very cool feature idea.

However, the WoofJS screen is already quite busy, so it's going to be an interesting challenge to put it in an intuitive place that's also not intrusive or confusing.

Idea 4 (I numbered the above ideas): you could put the data in the text editor somehow (similar to how you can click the code in Scratch to see the value).

Idea 5: basically Idea (3) from above, but we add this view as a panel in the editor (along with Code, Preview, Tutorials, Blocks).

Idea 6: put this in the variables panel of the docs tab... or somewhere in the docs tab...

[madduccino]

I'm leaning towards a version of 3 but can't find the bug icon you're talking about. In Tynker's JS editor, they have a console at the bottom that you can open and close. Could we create something like that that toggles open or closed on the bottom and in the editor, have the ability to log an expression to that console and also the ability to log the properties for an entire sprite? The console could cover the entire bottom of the screen when open, so would run across output, docs, editor, etc.

[stevekrouse]

I think I found it in Tynker's block-based environment. I like the idea of a panel where you can just see the current value of expressions.

But I also see the necessity for console.log for debugging things where you want to see what the value is at a specific line of code. Maybe the most general solution (Idea 7) is to copy JSBin and simply add a Console tab along with our other tabs. I don't like this because it does complicate things....

Here's another idea... Idea 8: If a student puts debug(x) in their code, we will put a debug panel right on their game preview - as it would be another sprite that's on top of all the other sprites. Does this make sense? The benefits of this is that we don't add any more panels to the UI. We can also provide people with the ability to customize where on the screen the debug panel shows on their code...

[madduccino]

Interesting. So are you saying debug would be another method of Woof - like Woof.prototype.debug? And it would still look like a panel, ie a rectangular shape with a fill color (white,black) that covers the bottom, top, left or right side of the output panel?

On Fri, Nov 2, 2018 at 4:52 PM Steve Krouse notifications@github.com wrote:

I think I found it in Tynker's block-based environment. I like the idea of a panel where you can just see the current value of expressions.

But I also see the necessity for console.log for debugging things where you want to see what the value is at a specific line of code. Maybe the most general solution (Idea 7) is to copy JSBin and simply add a Console tab along with our other tabs. I don't like this because it does complicate things....

Here's another idea... Idea 8: If a student puts debug(x) in their code, we will put a debug panel right on their game preview - as it would be another sprite that's on top of all the other sprites. Does this make sense? The benefits of this is that we don't add any more panels to the UI. We can also provide people with the ability to customize where on the screen the debug panel shows on their code...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168#issuecomment-435499665, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAI8bY5rJ2Q-WvkmuQy8v4P9Q_EK44Vks5urLCUgaJpZM4JarxX .

[stevekrouse]

Yep, in the preview panel. On top of the other spites. It would only show up if you use debug.

Or we could have a debug panel in the UI with similar behavior. It could only show up when you type debug (x) in your code and it'd go away when you remove those pieces of code.

On Fri, Nov 2, 2018, 5:17 PM madduccino notifications@github.com wrote:

Interesting. So are you saying debug would be another method of Woof - like Woof.prototype.debug? And it would still look like a panel, ie a rectangular shape with a fill color (white,black) that covers the bottom, top, left or right side of the output panel?

On Fri, Nov 2, 2018 at 4:52 PM Steve Krouse notifications@github.com wrote:

I think I found it in Tynker's block-based environment. I like the idea of a panel where you can just see the current value of expressions.

But I also see the necessity for console.log for debugging things where you want to see what the value is at a specific line of code. Maybe the most general solution (Idea 7) is to copy JSBin and simply add a Console tab along with our other tabs. I don't like this because it does complicate things....

Here's another idea... Idea 8: If a student puts debug(x) in their code, we will put a debug panel right on their game preview - as it would be another sprite that's on top of all the other sprites. Does this make sense? The benefits of this is that we don't add any more panels to the UI. We can also provide people with the ability to customize where on the screen the debug panel shows on their code...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/stevekrouse/WoofJS/issues/168#issuecomment-435499665 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ACAI8bY5rJ2Q-WvkmuQy8v4P9Q_EK44Vks5urLCUgaJpZM4JarxX

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168#issuecomment-435511383, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLtK53IAJnx62-PdwZq1fTjP1uoGO6uks5urLZggaJpZM4JarxX .

[truthgoddess]

All the ideas seem to work for me, question for you both @madduccino and @stevekrouse.

Like this look? https://woofjs.com/create.html#debug-display

Could code it so subsequent debug calls put the sprite combo below the other. The more it covers the student's window, the more likely they will delete debug() lines and use them selectively.

The color, size, shape, etc of the debug would not be changeable by students btw.

Thoughts?

[truthgoddess]

@madduccino @stevekrouse Feeling pretty good about that method of solution. A few reasons:

1) Helps students learn variable inspection before they are introduced to the browser inspector or console.log. 2) Does not go into the complication of the inspector. Once students know enough to use the inspector or other console.log tools, they should use that. 3) The bright and big lettering will be visible on small screens while using woof.

Since this is an aesthetic change, I'll wait for both or either of your go ahead to make a proper branch in which I'll put that into the Woof code. The provided link is just for aesthetic example purposes.

[stevekrouse]

I think you choose the right solution to move us forward quickly here. I took a stab at it via editing your code: https://woofjs.com/create.html#debug-display-3

1. I don't love the way it looks, but I don't think mine is all that better...
2. Your solution gives a snapshot of a value (like console.log). Do we want to allow students to get a more lively view of the current value of their expression like mine does (but it requires the funkier syntax)?
3. Do we want to try to parse out the string value of the expression as I did to help students correlate it with what they are trying to inspect?
4. Before you code this up, maybe code up how it would look with multiple values debugged? Maybe you could alternate the colors of the background (like in a table)

[truthgoddess]

1. I like your look better than mine. I'll play with colors to see if something strikes me as better, but I like your color choice a lot.
2. I don't know that 'lively' is the immediate goal. I think an inspector like this right now is a way to implement a very useful tool for students to help them learn, and it should inconvenience their project enough for them to use debug tools only when they know exactly why they are using it and don't want to use it on their projects for a quick title or anything.
3. I like it showing the name of the variable and the variable with multiple colors as you do. I didn't know how to do that after a tiny bit of research, so thanks for showing me how to do that. I learn a lot from seeing your code examples!
4. I will code this up to show how it might look with multiple values, and won't put it into the Woof code until we all agree on a look or solution.

[stevekrouse]

Let me clarify what I meant by 'lively'. I meant an always-up-to-date view. For example, if you change the value of speed in your example, the debug text does not update. It's the difference between text: expression and text: () => expression in Text Sprites. Does it automatically update when things change (like in a spreadsheet)? Or is it simply a log statement the prints to the screen?

[truthgoddess]

Oh! I see. Now I understand. I guess since students are coming from scratch, and scratch shows the auotmatic updates, then we should do that. Admittedly, I hadn't checked for that in my example, so I would totally use the constantly updating one now that I'm made aware of it.

[truthgoddess]

Using your code, which I agree with (put in a comment that it was mostly you, since it was, but let me know if I need to do that in the future and how), I thought the simplest approach was to introduce an optional parameter as you can see below. That allows students to put them wherever they want. And by the time students get to the level where they may want to see this, or multiple debugs, then learning about defaults and that type of thing this way might be helpful.

https://woofjs.com/create.html#debug-display-4

Thoughts?

[truthgoddess]

We could randomize the colors if we want. Another option is white background.

[stevekrouse]

I like pushing on the design of debug() as a really quick with good defaults, so I'd prefer if it would automatically stack subsequent calls to itself. (Of course, this means it'd need to keep track of how many times it's been called.)

I think we probably don't want any space in between these bars.

I think alternating light and dark colors (odd and even) like in a table is a decent way to go.

No need to give me credit in the comments

[truthgoddess]

Awesome. Yesterday when I was thinking about this, I couldn't figure out how to keep track of the calls, but this morning as I boxed, the answer was obvious, because the code for this will not be in the code window as in the example, so keeping track of it regularly is possible.

I've used up all the 10 extra hours I've been given in the coding space budget for this week, so sadly, I won't get to this until next week. Wish I could just do this much more. :)

[truthgoddess]

Good morning!

Like this look? https://woofjs.com/create.html#debug-display-4

Thought blues might go good with Woof theme. What do you think?

Believe it is not possible to do in the code editor what we would do in the woof code, so that code I put there is just to get the look happening. I wouldn't put the switch outside of the prototype in the real version?

Figure still that this idea is working for everyone, and that once we agree on a look and color scheme, I can put this in the stack of things to do.

[madduccino]

Looks good to me!

Also, it might be useful to allow users to drag it around the frame with their mouse and maybe resize it with the mouse? (What if something is happening in their game that they need to see or do during the debug and this is blocking?)

On Tue, May 28, 2019 at 7:56 AM Kate Norton notifications@github.com wrote:

Good morning!

Like this look? https://woofjs.com/create.html#debug-display-4

Thought blues might go good with Woof theme. What do you think?

Believe it is not possible to do in the code editor what we would do in the woof code, so that code I put there is just to get the look happening. I wouldn't put the switch outside of the prototype in the real version?

Figure still that this idea is working for everyone, and that once we agree on a look and color scheme, I can put this in the stack of things to do.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168?email_source=notifications&email_token=AAQAR4OKSJY6QPQYHNLPDZLPXUMVRA5CNFSM4CLKXRL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWL4JIY#issuecomment-496485539, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAR4NCN6EHSSGTLEFCP2LPXUMVRANCNFSM4CLKXRLQ .

[truthgoddess]

Definitely good points. One thought I keep having is that we don't want this to function like a better Text sprite. Students might end up using it instead of making their own. Therefore, the lack of functionality, and the fact that it covers the game is purposefully there to annoy students, just like the console isn't something that is part of the game. It is there to give information about variables only. If students ask how they can move the debug window, then we tell them that if they want it to be part of their game, to make a text sprite, and teach them more about the console and its purpose.

If we did want to make it so that students could move it around, that is why I first put the yOffset option in it, so that students could type in where they want it to be so that it isn't in the way for them. Steve mentioned above that he preferred automatic color alternating and side to side.

Steve, thoughts? Maddy, thoughts? Happy with whatever we all decide.

[madduccino]

I think including the yOffset is a good idea. Dragging it around would be easier, but I understand your point and I don't think we should necessarily start giving students more opportunities to drag and drop. Obviously the difference between this and the console is that the console appears next to and not on top of the output so it is less annoying and more helpful.

On Tue, May 28, 2019 at 8:36 AM Kate Norton notifications@github.com wrote:

Definitely good points. One thought I keep having is that we don't want this to function like a better Text sprite. Students might end up using it instead of making their own. Therefore, the lack of functionality, and the fact that it covers the game is purposefully there to annoy students, just like the console isn't something that is part of the game. It is there to give information about variables only. If students ask how they can move the debug window, then we tell them that if they want it to be part of their game, to make a text sprite, and teach them more about the console and its purpose.

If we did want to make it so that students could move it around, that is why I first put the yOffset option in it, so that students could type in where they want it to be so that it isn't in the way for them. Steve mentioned above that he preferred automatic color alternating and side to side.

Steve, thoughts? Maddy, thoughts? Happy with whatever we all decide.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168?email_source=notifications&email_token=AAQAR4JR6URZ7E5YYXVXS3TPXURNDA5CNFSM4CLKXRL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWL7LEI#issuecomment-496498065, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAR4JS4CIH6RLQMFO4BETPXURNDANCNFSM4CLKXRLQ .

[truthgoddess]

True! I believe that was one of your original thoughts, and I like it.

If we have it shorten the frames, and basically recreate what students can find with a right click and navigating their inspector, it does what codepen does. The laptops have tiny screens, but I see your point.

I'd vote for on project but I'm happy to go with whatever is best!

[madduccino]

Yeah, I think the tiny screens are what ultimately led to this solution. If we make it the easiest possible to move around, I think this could work. The other option proposed was making a new pane, like preview, docs, debug.

Also, is it possible to show the items in a clone (or any array)?

On Tue, May 28, 2019 at 9:00 AM Kate Norton notifications@github.com wrote:

True! I believe that was one of your original thoughts, and I like it.

If we have it shorten the frames, and basically recreate what students can find with a right click and navigating their inspector, it does what codepen does. The laptops have tiny screens, but I see your point.

I'd vote for on project but I'm happy to go with whatever is best!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168?email_source=notifications&email_token=AAQAR4LJBWVWVWQZQXGFFJLPXUUFNA5CNFSM4CLKXRL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWMBJSY#issuecomment-496506059, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAR4IKVM3R5KXVPQUWKELPXUUFNANCNFSM4CLKXRLQ .

[truthgoddess]

I'm not sure how created objects are named or referenced in Woof. I'd argue that this is an important question, but we should make another issue of it if the functionality isn't there.

I think a new pane might work, if we can figure out a way to make it really useful. I think a pane that has limited functionality might be an ineffective idea. However, what if we put the debug in the documentation menu somewhere? Maybe as a colored block that says console, and when students open it, it shows the same kind of text we are current showing?

[madduccino]

I like the docs menu idea!!

On Tue, May 28, 2019 at 9:21 AM Kate Norton notifications@github.com wrote:

If we wanted to add another pane

I'm not sure how created objects are named or referenced in Woof. I'd argue that this is an important question, but we should make another issue of it if the functionality isn't there.

I think a new pane might work, if we can figure out a way to make it really useful. I think a pane that has limited functionality might be an ineffective idea. However, what if we put the debug in the documentation menu somewhere? Maybe as a colored block that says console, and when students open it, it shows the same kind of text we are current showing?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168?email_source=notifications&email_token=AAQAR4JZ3UYO42TIBPDRGJ3PXUWT7A5CNFSM4CLKXRL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWMDEBI#issuecomment-496513541, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAR4LDNNKJ4SBH2XNSA6LPXUWT7ANCNFSM4CLKXRLQ .

[truthgoddess]

If so, then part of the large color blocks? (pro: integrated into documentation nicely; con: not like scratch)

Above or below the search text box? (pro: always visible in main docs; con: no easy way to provide instructions to students)

Other thoughts or arguments in favor?

[madduccino]

Yes, another block called Debug, just like Integrations, Sprites & Backgrounds, etc.

Let’s see what @stevekrouse has to say.

On Tue, May 28, 2019 at 9:29 AM Kate Norton notifications@github.com wrote:

If so, then part of the large color blocks? (pro: integrated into documentation nicely; con: not like scratch)

Above or below the search text box? (pro: always visible in main docs; con: no easy way to provide instructions to students)

Other thoughts or arguments in favor?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stevekrouse/WoofJS/issues/168?email_source=notifications&email_token=AAQAR4IGJAKV2TNVCPOS4B3PXUXTVA5CNFSM4CLKXRL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWMD5OQ#issuecomment-496516794, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAR4IRC76T5D6DZRPAJVDPXUXTVANCNFSM4CLKXRLQ .

[truthgoddess]

Looking forward to his thoughts on all this.

Might have to think about #460 in reference to this if we are adding blocks, since if we add one there will be an odd number of blocks.

Another thought: put the console in the data doc area.

[stevekrouse]

Great discussion! Considering how easy it would be to add Kate's existing prototype, I vote we do that and move these other ideas into other issues.

Putting the debug info into the docs is neat. Here's another idea: we could put the debug info into an existing pane by splitting it vertically. For example the debug values could show up at the bottom of the code pane or the top of the preview pane but without obscuring anything — it'd just make it a smaller window.

Another idea: we could augment the text of the code editor itself with this data! This might have technical issues, but the idea is we somehow capture the values and paste them in the code (dynamically) as comments as the values change.

[truthgoddess]

I definitely prefer the end result being that the console is at the bottom of the code editor. Seems a great way to do it. We can either just create that without introducing the temporary solution I put above, or do the first and put the console in the bottom of the code later. That is if you both agree.

I think it would be more efficient to just work on the final result, but if we want to roll out some kind of console functionality faster, we could do both. I don't feel strongly one way or the other on this.

[stevekrouse]

One thing to point out: there's a very big difference between a console (which you can print to) and a debug view of a variable which shows the updating value of a variable. Printing is more general and powerful, but less intuitive and ergonomic. Trade-offs... I'm leaning towards a debug view but a console you can print to is not a bad idea... This is probably a bigger discussion.

Here's another implementation idea: we could go with the version where the debug data is in the preview window, but we can do it in such a way that it just makes the game preview smaller, below the debug part. We could implement debug in the Woof library to shrink the size of the game by how many debugs it needs to display.

If we are going to do a debug window in the code pane, we might want to do it so that you can add debug values without editing the code text. Maybe you hit a "debug +" button and then you type in the name...

[truthgoddess]

Definitely agree with you on this Steve. Besides, the browser console is already there. And agree it should be some kind of easy button without code. Otherwise, again, console.log works in the code window anyway.