List of blocks feature

[iyayau]

1. What does this feature afford users? The list of blocks affords users a way to see and navigate in all blocks. The blocks are categorized based on different functionalities and provide the users an approach to choosing block depending on the type of the block.

2. What are its constraints and how do they help or hinder users? There are several pros and cons with this feature. Using the list as a format to present the categories of blocks makes it easier for users to navigate. But currently, it is presented alphabetically, which makes sense but does not show any importance of certain blocks or differentiation between blocks. Additionally, it is helpful that it shows the description of the block when the user moves the mouth on the block. But there is no indication of the description. Users can only find it by accident.

3. How does the feature signify its affordance or how to use it to users? The small arrow next to each block name indicates the hierarchy structure within different categorization, so the user would know what is clickable and what is not. The order of the blocks in the list is another visual signifier. But in current interface, the order does not really play an important role.

4. What conventions does this feature either respond to, incorporate, or reject, either in the context of interface design generally or GNURadio specifically? In other software or applications, using the list to present options for the users is a very common way. Such as Xcode (see screenshot below) which shows all view components in a list with an icon as well as a short description of the components in each line.

   

5. How will you go about arguing for the inclusion of this feature? I think we could include this feature in our design especially when we want to present something for the users to choose from. For instance, in the section when we suggest some blocks for the users based on their pre-settings, we could use the list containing all the suggested blocks. We could keep the hierarchy structure but one thing we could improve is adding icons and description of the each block in the list.

[gchadwick10]

I was thinking about doing this one! Where do you see this fitting in our window?

[iyayau]

[iyayau]

1. What the feature does (functionally) for a user.
   • Overall, the feature suggests block for the user to choose to include in the project
   • The suggested blocks are depended on user's pre-settings on priorities
2. Expected user inputs (what does the user do?) and program outputs (what can the user expect in response?).
   • User can add the suggested block into the project by clicking "Add" button and added block will show in the middle workspace for user to do further configuration
   • User can fill in detailed settings in the configuration by using editable blanks
   • User can also choose to apply the configuration or delete the block from the project using different button at the bottom
   • Every time the user click on a button, the interface will pop up an alert window for the user to confirm the request
3. Possible errors that may result (if any) and corrective suggestions for the user.
   • If the user chooses to add more than one block for each type, the wizard will show an error message and provide instruction on how to correct it
   • In the configuration section, if the user enters invalid value, it will point out the error either by showing error message right next to the blank or showing an alert when the user clicks on "Apply"