Improve the Miden Playground UX

[Dominik1999]

Improve the Miden Playground UX

We want to have the Miden Playground look more like the 8086 Compiler page. Here are some preliminary thoughts about what we want to change.

Tasks

• [ ] We want to have a new Design for the Miden Playground, see here
• [ ] When a user visits the playground for the first time, there should be those small explainer popups. On the 8086 compiler page, they call that tutorial
• [ ] The instructions should be shown in a window right next to the code window when clicked
• [ ] Inputs can be entered in different ways:
  • A user can enter the operand_stack in a line under the code window (similar to the 8086 compiler
  • A user can click on the + symbol to add another line to also enter the advice_stack or secret input the same way
  • A user can also enter an input file (or the copy thereof) by first clicking the +-Document symbol. This opens another window right next to the code window. Here the user can input JSON data
• [ ] When a user runs a program, the stack output should be shown under the input line and some information right next to the code window
• [ ] Debugging shows a lot of info right next to the code window. The format could change, let's see what looks best
• [ ] We should also keep the mobile version in mind
• [ ] We need another tab to switch to Move / Rust as a secondary language. Move / Rust can then be compiled to Miden Assembly
• [ ] We want to add some syntax highlighting for Miden Assembly. This is possible using CodeMirror

[Dominik1999]

I am not a Figma expert, but the design should look similar to this.

No user interaction so far

Clicking "Instructions"

Enter input

Enter secret input (clicking the +)

Enter input as JSON (clicking the +-Document symbol)

Running the program

Debugging a program

Proving a program

[bobbinth]

Looks great! A few comments:

On the right side:

• What is "trace" and "overflow addrs"? I don't think we need to expose them to the user.
• We do need to show the stack stack there.
• In the future, we should probably have a way to see contents of the advice provider in a way similar to how we can see the state of the stack and memory.

On the left:

• I would probably make example selection separate from the code window.
• How are we thinking about inputs/outputs working? In our case, these would need to define initial/final state of the stack which could be like a small table.
• We also need to provide a way to define advice inputs.

Overall, are you thinking that the contents of the right part will depend on what is selected on the left? That is, the right side would differ depending on whether the user clicks on "run" vs. "debug" vs. "prove" vs. "verify"?

[Dominik1999]

Looks great! A few comments:

On the right side:

• What is "trace" and "overflow addrs"? I don't think we need to expose them to the user.
• We do need to show the stack stack there.
• In the future, we should probably have a way to see contents of the advice provider in a way similar to how we can see the state of the stack and memory.

On the left:

• I would probably make example selection separate from the code window.
• How are we thinking about inputs/outputs working? In our case, these would need to define initial/final state of the stack which could be like a small table.
• We also need to provide a way to define advice inputs.

Overall, are you thinking that the contents of the right part will depend on what is selected on the left? That is, the right side would differ depending on whether the user clicks on "run" vs. "debug" vs. "prove" vs. "verify"?

Thanks for the comments @bobbinth

I wasn't quite ready; maybe have another look now. Took me a while to get used to Figma.

Some questions:

• when do we want to show the Memory? Only when in Debug Mode?
• should users be able to input merkle_stores via the playground? That might be a bit much imho

[bobbinth]

Looks great! A few thoughts:

• Instructions
  • I wonder if there should be a way to quickly search for an instruction so that people don't have to scroll through the entire list.
• Inputs
  • I think entering inputs would require more space. For anything but very simplistic programs, this would be almost as important as the actual code. We might want to have this as a separate tab on the left or something like that. We could still keep the summary of inputs/outputs below the code panel - but that one would be read only.
  • We should be able to provide all types of inputs. Initially, we could be just copy&paste of JSON file (same format as what we use for .inputs files in CLI). Eventually, we can improve the UI for entering these.
• Running a program
  • I'd add a panel with some info on the right (i.e., program hash, running time, number of cycles, maybe something else).
  • I'm not sure we need to highlight output in green.
• Debugging a program
  • I'd make the right-hand side much more structured. There could be a separate field for clock cycle, executing instruction etc. And I'd break out the stack into separate cells (one for each value).
  • For memory, I'd also make it much more structured. For each entry, we'd have an address and 4 values. And yes, this would only be relevant for debugging.
• Proving a program
  • I don't know if we actually need to show proof string.
  • I would show much more detail about proving execution (execution time, proof size, proof security level maybe something else).

[Dominik1999]

Thanks @bobbinth - it might be easier to check out the design and comment here https://www.figma.com/file/R8553pUNA62HDadXBi9Tdm/Miden-Playground-Design---next-level?type=design&node-id=1%3A198&t=A85UFhkFZr8F01uD-1

*Instructions

• I wonder if there should be a way to quickly search for an instruction so that people don't have to scroll through the entire list.

Sure, we already have the search now. I added it to the picture.

• Inputs
  • I think entering inputs would require more space. For anything but very simplistic programs, this would be almost as important as the actual code. We might want to have this as a separate tab on the left or something like that. We could still keep the summary of inputs/outputs below the code panel - but that one would be read only.
  • We should be able to provide all types of inputs. Initially, we could be just copy&paste of JSON file (same format as what we use for .inputs files in CLI). Eventually, we can improve the UI for entering these.

I wonder for what this playground will be used. Do you think someone uses it for more than simplistic programs? To me, it is more like quickly checking how everything works. But if you want to do real coding, and inputting a Merkle tree, one would probably use an IDE, right?

At least also, the 8086 Compiler page only allows for super simple inputs below the coding window.

Alternatively, we could have a window right next to the code window to enter all the inputs. Then when the user runs, debugs, or proves the programs, the inputs are only shown below the coding window.

Maybe let's discuss in a short call.

• Running a program
  • I'd add a panel with some info on the right (i.e., program hash, running time, number of cycles, maybe something else).
  • I'm not sure we need to highlight output in green.

That's a good idea. I added a "Program Info" window

• Proving a program
  • I don't know if we actually need to show proof string.
  • I would show much more detail about proving execution (execution time, proof size, proof security level maybe something else).

I would show the proof string, but we could also just show a symbol or so. Let's see.

• Debugging a program
  • I'd make the right-hand side much more structured. There could be a separate field for clock cycle, executing instruction etc. And I'd break out the stack into separate cells (one for each value).
  • For memory, I'd also make it much more structured. For each entry, we'd have an address and 4 values. And yes, this would only be relevant for debugging.

Nice, take a look.

[bobbinth]

I wonder for what this playground will be used. Do you think someone uses it for more than simplistic programs? To me, it is more like quickly checking how everything works. But if you want to do real coding, and inputting a Merkle tree, one would probably use an IDE, right?

I think even some simple programs may want to use various parts of the advice provider. So, I'd still provide the ability to add all parts of advice provider inputs. It doesn't need to be anything fancy - just pasting of JSON data should work.

[Dominik1999]

Agreed, let's do it. I will find a fancy way to do it.

So in the Input line, the user can now also click an icon to copy & paste inputs from a file.

I think, we should normally do user interviews and test how this is used. But maybe we can start with this and iterate.

[bobbinth]

Yep - looks like a good start and we don't need to do anything more complex without user feedback.

One thing I do wonder is whether it might be better to have "real" tabs on the left side and maybe move inputs there. For example, it could look something like this:

[gubloon]

I ideated on two layouts that are just slightly different; please add your comments. Thanks. 1: 2:

[gubloon]

Further ideas to experiment: ability to interact with docs, node and SDK within playground.

[Dominik1999]

I like the second design better as well. But I like the black design from above even more. You don't like it?

[gubloon]

Or what I can do is to make 2-3 barely working mock-ups from these ideas and see which one we like. In that way, it will be even more easy to decide and pick.

[Dominik1999]

Completed