Menus and Palette: Requirements Analysis

[meganindya]

Case Study of Music Blocks v3 UI

The User Interface of the current iteration of Music Blocks has the following sections:

• Menu bar

  Contains buttons for: Tour, Run, Stop, New Project, Load Project, Save Project, Planet, Help, and Auxiliary Menu Toggle.

• Auxiliary menu bar

  Contains buttons for: Run Slowly, Run Step by Step, Display Statistics, Load Plugin, Delete Plugin, Horizontal Scroll Toggle, Merge with Current Project, Turtle Wrap Toggle, Key Signature, JavaScript Editor, Restore from Trash, and Language.

• Blocks palette

  Has 3 tabs: Music, Programming, and Art. Each tab has a Search Bar (which performs a universal search for Blocks). Following are a list of categories specific to the generic tab type. Clicking on a category opens a new list — this list contains the actual Blocks. Blocks are moved up by clicking and dragging out of the list onto the canvas.

• Canvas

  The Canvas contains: Sprites (the shape of the sprites are fixed; colours can change though; also, these can be replaced by images), vector Artwork produced, and the Blocks in the project. The container for the Artworks can be collapsed to a smaller window which moves to the top right.

• Canvas specific buttons

  There are floating buttons for effecting behaviour of Canvas items: Grid List Toggle, Clear, Canvas Collapse Toggle, Home , Show/Hide Blocks Toggle, Expand/Collapse Clamps Toggle, Increase Block Size, and Decrease Block Size.

• Floating windows (used by widgets)

  Floating Windows have a Menu Bar which list their name, and have 3 buttons: Close, Minimise, Stretch Screen Toggle. The Body is free to customise. Windows when out of focus become translucent.

The Menu Bar takes up 64px of height in the viewport. The rest of the viewport is taken up by the Canvas, Other sections float on top of the it, thereby hiding some part of it. The Auxiliary Menu Bar when open takes up another 64px of the height (over the Canvas). The Palette on the left (over the Canvas) eats up 128px width, with an additional upto 252px for the list of Blocks. The 8 Canvas Buttons each of 42px × 42px, are positioned on the top right and bottom right (over the Canvas), in groups of 3 and 5, respectively.

Expectations from New Design

• Maximise working space

  The bulk of the user time on the application is spent in arranging blocks. Therefore, the area for doing so needs to take up as much of the screen real estate as possible. In addition, it needs to be distraction free.

• Quick access to Palette Blocks

  As users build their programs, they need quick and easy access to Blocks they need (or want). Navigating around the categories in the Palette needs to be efficient in user effort. Plus, the list per category need to be sectioned into common and niche use case Blocks. Also, a few different Blocks perform similar operations, and they could be grouped together, thus shortening the list users need to run their eyes through. Minimising user effort here is paramount.

  In addition, a Search really can help. The design and behaviour of the Search will impact user experience.

• Decluttering

  As mentioned in the case study above, there are quite a few event buttons. There could be more in the future. Some buttons are frequently used while the rest are used much less. Some buttons are used rarely (users will probably use the Language buttons only once). While building programs, the less the number of buttons lying around, the more users can focus on building programs.

• Status Section

  Music Blocks currently doesn't have a Status sections which could provide some insights about the project, sort of like the Developer Tools in most web browsers. We currently have to use widget windows to have something as such. It'd be great if it could be integrated into the UI, which stays collapsed, until expanded.

• Customisability

  The current layout of the application is fixed (rigid). It could be a great user experience if users could customise the components of the UI. For example, users could be able to change the position of the Palette or the ordering of its contents, or the arrangement or visibility of buttons of a Menu Bar. However, users wouldn't like accidental customisability, and so the settings need to off the primary focus.

• Visibility Control and Code Module Independence

  The Canvas, specifically the Artwork container of the container actually displays any changes while the project is running. The rest are used only while building projects. The visibility (and loading) of the rest of the components and their contents should be easily controllable. A use case of this is embedding Music Blocks project in another web page. In such a scenario, the users would be only concerned with running the project and viewing the Canvas (and the AudioContext for the music), as the project would be complete by then.

[meganindya]

@walterbender @pikurasa