Block Graphics Framework: Requirements Analysis

[meganindya]

User Interface Elements

• Scalable Vector Graphics (SVG) artworks for the new block design

  There is an initial discussion about the designs of the blocks. It is only indicative — it is merely a pros-cons discussion exploring some different ideas from what Music Blocks v3 has. The design isn't finalised yet.

  There are key takeaways though. The programs tend to get tall in no time. For blocks that take arguments, if arguments are arranged horizontally instead of vertically, the increase along the horizontal axis isn't massive, but there is a significant shrinking of the height vertically. Another idea is that, colour coding connectors for blocks can help in figuring out what can be attached where.

  There is another expected requirement. In many cases, the attachments may generate invalid syntax, e.g. missing arguments, invalid argument types (some types may be dynamically inferred). In those cases, we need to provide some feedback to the user about such events. Possible ideas are hover symbols, colour coding, etc. And, these need to be bubble up through the nesting or chaining — if a nested block has a warning/error, the nesting block (which nests the discussed block) may have runtime problems, or if there is an argument chain where there is an invalidity, the invalidity will ripple up the chain.

• Attachment feedback

  When a user attempts to attach a block to another, the user needs to be provided with visual feedback about the possibility of the attachment. One idea in case of a possible attachment could be to highlight the edges that will sit together. In several cases shapes of the attaching set of blocks need to morph, e.g. when attempting to attach a block into a clamp, or when trying to attach an argument block when some argument blocks to the parent block are already attached. The shape shift feedback is required too. There also needs to be a feedback, in cases when attachment isn't allowed.

• Expandability and Contractibility

  In large projects, we might want to collapse (fold) a clamp block, or the argument chains after the corresponding syntax has been dealt with, to have more visual real estate to work with undistracted. We might want to expand that section when the user wants to visit back the code blocks contained. This complementary set of operations need to be feel smooth and instantaneous.

• Context Menus

  Depending on the type of block, various value options might need to be provided for value selection. Music Blocks v3 open up pie menus. However, opening a pie menu hides the block it provides values for. An improved design would be nice. Also, value fields currently aren't restrictive in values. And they aren't really contained within the limits of the block. Improvements are expected.

• Highlighting and State Values

  When a block is in execution, it'll get highlighted. Thereafter it is unhighlighted. In case of warnings/errors, feedback needs to be provided.

  When running in step-mode, there needs to exist visual feedback to state values passed between argument blocks.

• Interactive events

  Mouse events like click, click and drag, double click, right click will have some functionality. The effectivity of the interaction needs to be smooth and consistent.

  So far, these block-based Visual Programming platforms suffer from interactive bottlenecks. Using a mouse is slow. The experience can be greatly improved if there are keyboard navigation and interaction features.

• Labels

  Since blocks are the syntax elements, we may want to label them for understandability (like comments in text programs). We may want to insert such labels between blocks or within individual blocks. Since these are just text, these need look like blocks; labels can have different customisability.

Modules

There needs to be a framework for the creation, attachment, updating, and removal of the blocks as expected in the UI described above. A set of modules will be required. Loosely, they are:

• Factory

  This shall deal with the creation of different types of blocks. All aspects particular to a block needs to encapsulated in a class. Therefore, the factory will oversee a hierarchy of classes.

• Organizer

  This shall deal with the attachments between blocks. Stores the current state of attachments between blocks.

• Worker

  This will monitor the positions of blocks (and block stacks) and morph them during attachment feedback and completion events. This shall be responsible for the live changing of SVG markup.

Interface API

The bulk of the functionality is separate from the blocks framework. The user merely interacts with this framework to create programs. The actual syntax elements are maintained elsewhere. This framework shall only handles the View component of an MVC framework. Therefore, it need to pass and receive information to and from the module/s handling the rest.

An interfacing API is required to be developed to send and receive messages and signals for different events. For example, when the program is executing, the framework receives signals for highlighting and unhighlighting certain blocks; when a click event is made on a blocks, it sends out a signal describing that the user expects execution of a certain block stack.

[meganindya]

@walterbender @pikurasa

[ricknjacky]

@meganindya
I have shared my draft proposal pertaining to this project. It incorporates all of these requirements and is syntactically less convoluted than the current implementation.

However, thanks for the detailed description of the requirements. Will add these to the proposal as well.

If there's anything you'd like me to add to my proposal, kindly do share your feedback and suggestions.

Thanks.