Wireframe Idea

[meganindya]

I initially thought we need to only work with the "engine" and the eventual communication. But I studied the codebase over the last two weeks and found the DOM-code very tightly coupled with the logic. I don't think it is worth going through the effort of separation.

Besides, I considered the several UI/UX features we discussed would be good additions. Again, decluttering the screen remained a priority for me. In view of these, I designed a mock wireframe of a different layout, with collapsible buttons and pie-menu/dropdowns for deeper options.

Here's a link to directly view on figma (designed for a 1600 x 900 screen to help with 10-based calculations while positioning):
https://www.figma.com/file/szkEfxtcsJ3IPs2EkJAAON/Home?node-id=0%3A1
(I've added comments on figma)

@walterbender thoughts?

Here are the screenshots:

• All collapsed
  

• Tooltip and Pie menu
  

• Expanded Palette
  

However, at any time only one group of buttons can be expanded.

[walterbender]

I like these--they are more compact and less cluttered than the current design. And maybe they would work better on smaller displays as well--not sure about that. But I am not sure this really resolves the more fundamental problems we have.

[meganindya]

I understand what you are saying. This isn't replacing that. Our most fundamental problems are non-modular components, heavy inter-dependence, and unoptimized state management. But, we need a context of the features we need.

The component tree is independent of the complex parts, re the new architecture. This too needs to be written before the bridge between the two layers can be written. I think it is almost a 50-50 separation of code between the two layers. This can be done in parallel.

[Saibaba-Alapati]

Hey, can I try some new interface designs for this wireframe? I will try to make sure all the components were covered @meganindya .

[meganindya]

Go ahead.

[meganindya]

Create a new discussion though when you want to share them.

[Saibaba-Alapati]

Yeah, I will do that and share updates here. Thanks for the fast reply.

[Saibaba-Alapati]

Create a new discussion though when you want to share them.

ok

[Saibaba-Alapati]

Create a new discussion though when you want to share them.

I have created a separate discussion please check that.

[valessiobrito]

Hi, I don't know how much I can collaborate. Anyway, I would like to invite you to think about a responsive structure, designed primarily for small screens. My 5-year-old niece already uses a mobile phone and I find it very difficult for her to use larger screens for a long time.

One suggestion is to know these experiments: https://musiclab.chromeexperiments.com/

[meganindya]

Yes, indeed. The long term plan is to have different user-end interfaces for different types of devices. The idea is that non-UI part (we're calling it the 'engine') shall be a separate module, so different UI modules (we're calling it the 'client') can use the same thing independently.

I was thinking that we'll start with a desktop-size web UI because we've a good idea about how that should be. Then, we shall move towards implementing other form factors. For devices like smartphones, the screen real estate is very low in comparison, so I think a newer design would be better than forcing the desktop UI to adapt. In fact, certain interactions better be done differently in such cases. For example. touch-screen devices lack the 'hover' behavior; it can be replicated, but that's a poor experience in my judgement.

Will add more designs once we identify the full set of UI features for the desktop web. Please feel free to share any ideas you would have (anything — UI or non-UI) by creating a new 'ideas' discussion.

BTW, thanks for the link.

[daksh4469]

Hi @meganindya, can we get rid of the STOP button as an independent button and put it under the navigation of the PLAY button where RUN SLOWLY and RUN STEP BY STEP buttons are present or instead maintain its state and change PLAY into STOP only when a program is running on musicblocks. Also in this wireframe, the Search functionality is missing.

[meganindya]

I like that idea

[meganindya]

I think we could replace the STOP with a RESET

[daksh4469]

Yup, that would be nice.

[daksh4469]

Hi @meganindya @walterbender,

I designed this wireframe on Figma (inspired by the one posted above by @meganindya) in a 1920 x 1080 resolution. Please have a look at this and share your thoughts. The Toggle that is present in the toolbar is for enabling horizontal scroll. The dropdowns from PLAY button and a PALETTE would be similar in this case. However, STOP button is deprecated in this design as discussed in the above comment.
Would appreciate your opinions.

Thanks.

[walterbender]

I think this is a great start. Two initial thoughts: (1) we were thinking the menus would be vertical on landscape displays and horizontal on portrait displays; (2) maybe the palette icon could appear on the colored dots? Then the user would not have to hover to find the right palette in case they don't recall the color/position (or if they are color blind).

[daksh4469]

Yeah, it would be great to have icons on the palette colors Also, vertical palette menus would be great. However, if palette menus are set vertically, as shown by @meganindya , would it be a nice idea to fit all the 13 palettes icons in one single column?
About the toolbar, do they also need to be vertical? I was thinking of maybe shifting the search bar to the toolbar from the palette menu as in the current musicblocks. To do this, wouldn't the horizontal search bar on a vertical toolbar look a little inconsistent?
Please share your thoughts on this @walterbender

[walterbender]

The palettes could expand either horizontally or vertically (the Python version actually lets the user choose on the fly). A search box should always be horizontal, but it could be a popup, in any orientation. (In Japan, a vertical search box could work :) )

[daksh4469]

Oh sorry, I meant horizontal search bar on a vertical toolbar in the above comment. I was also going for a horizontal search bar. Messed up words.
My bad 😅
But Popup search bar is a nice idea.

[daksh4469]

Hi @meganindya @walterbender, I was exploring the wireframe idea designed by @meganindya. The RED buttons on the right are under the group Default Settings Buttons, and the PURPLE ones are under the group Canvas Settings Buttons. I just wanted to ask about what settings exactly will these buttons include? And are they finalized or still in the discussion?
I was designing another WireFrame in Figma, keeping the suggestions on the earlier one in mind and trying out certain layouts. Thus, I wanted to ask whether these are the exact and finalized number of buttons and menus in general.
Please share your views.
Thanks.

[daksh4469]

Hi @meganindya @walterbender,
I was thinking something along these lines.
We could maybe keep all the toolbar buttons on one side, and the opposite side could contain all the palette buttons and settings buttons. Also, how about keeping the BLUE color as the primary color in the Toolbar. In the below wireframes, the Search Bar expands horizontally on click and similar for other pop-ups (PLAY, SAVE, etc.)

Would love to hear your feedback and thoughts on this.
Thanks.

[meganindya]

I like these. We need to discuss and settle on a list of buttons we need. Maybe some can be replace/removed and some new ones added. Will get back to you on this.

About the coloured circles on the right in my original rough wireframe, they were meant for canvas specific operations that currently float on the canvas. Will know for sure what we want after a discussion.

The palette designs are something I'm not very much at peace with though. The design should aid in quick access to the blocks, and must be intuitive.

[daksh4469]

Yes, once the buttons needed are decided, we could make a more intuitive design with a suitable layout. About the palette designs, I also think that there is a need for brainstorming to decide how to keep all the palettes in a compact and clean UI.

[daksh4469]

Hi @meganindya,
Are we planning on orienting the toolbar vertically or horizontally? In my opinion, we should probably stick with the horizontal one, as there are going to be many buttons in the toolbar, and assigning them to the lesser dimension of the window might result in too many buttons getting "high-shelved." Please share your thoughts on this.

Also, I believe that we can transfer the RUN STEP BY STEP and RUN SLOWLY buttons inside the navigation of the PLAY button, and the same for the LOAD, NEW, and SAVE project under a PROJECT navigation. To further compact the UI, can we add LOAD PLUGIN, and REMOVE PLUGIN under the navigation of a PLUGIN button.
Also, has the list of buttons finalized or still in the works?

[meganindya]

About the search bar, we were thinking of something like a pop up modal. For demonstration, this is a screenshot of spotlight search on Mac OS.

Perhaps, the search bar could open up like this. Only an idea though; comments and other ideas are welcome.

[walterbender]

There is no guarantee that even the longer dimension is sufficient. So we need an overflow strategy regardless.

…

On Sat, Apr 3, 2021, 2:41 PM Daksh Doshi ***@***.***> wrote: Hi @meganindya <https://github.com/meganindya>, Are we planning on orienting the toolbar vertically or horizontally? In my opinion, we should probably stick with the horizontal one, as there are going to be many buttons in the toolbar, and assigning them to the lesser dimension of the window might result in too many buttons getting "high-shelved." Please share your thoughts on this. Also, I believe that we can transfer the RUN STEP BY STEP and RUN SLOWLY buttons inside the navigation of the PLAY button, and the same for the LOAD, NEW, and SAVE project under a PROJECT navigation. To further compact the UI, can we add LOAD PLUGIN, and REMOVE PLUGIN under the navigation of a PLUGIN button. Also, has the list of buttons finalized or still in the works? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6PXYNFQGUG6AWKZDM7HGLTG5OONANCNFSM4UYR4QHA> .

[pikurasa]

Perhaps, since our goal is simplicity, we start with a mobile design, and then work toward a desktop design (instead of the other way around)?

This may force us to think simpler.