Checklist feature

[gchadwick10]

1. What does this feature afford users? This feature allows users to monitor their status in the workflow and their system's viability. Users can also use the checklist to click around to different points in the workflow in a non-linear fashion if they want.

The checklist will occupy the left-hand side of the window at all times while the user is building their radio graph. It will consist of text, an icon, and a color background.

2. What are its constraints and how do they help or hinder users? The checklist is constrained by a limited, 3-state status system. In other words, the specificity of the message conveyed by each status is limited. This means that users may not know what they need to do from simply looking at the checklist.

3. How does the feature signify its affordance or how to use it to users? The checklist will use color and iconography as signifiers. More specifically, the checklist should use colors as signifiers that action is required or not required. Red could mean that action is required, yellow could mean that action may be desirable, and green could communicate that action is not required. Additionally, the checklist could use exclamation points, question marks, and checks to communicate the same information for users who may have trouble seeing colors. The order of the checklist items would signify a suggested workflow, but it would not enforce that it be followed.

4. What conventions does this feature either respond to, incorporate, or reject, either in the context of interface design generally or GNURadio specifically? The checklist will follow cultural conventions by using red, yellow, and green to indiciate how urgent actions. Similarly, the exclamation points, question marks, and checks are a cultural convention. Since the checklist essentially acts as navigation during the graph building process, its placement on the left-hand side of the screen fits with the convention of placing page navigation on the left side of the screen.

5. How will you go about arguing for the inclusion of this feature? In any interface, it is necessary to let users know about their status and the status of the system. The checklist lets users know the status of their workflow while it also communicates the status of the system they are building. Additionally, since our users are thought to be tinkerers, the possibility of jumping around in the workflow in a non-linear fashion should provide our users with the control they desire.

[tfrahm]

Need to clarify specifics of user group!: Are we designing for: 1) New users who are LEARNING how to do this and what to do, or 2) Knowledgeable users who are using this as a tool for efficiency?

@jdmar3 @Electrocute

[gchadwick10]

1. What the feature does (functionally) for a user.
   • The feature allows the user to navigate through the flowgraph building process and provides them with status notifications.
2. Expected user inputs (what does the user do?) and program outputs (what can the user expect in response?). The user clicks the text titles or the circles to transport themselves to the corresponding page. The user can expect the middle and right panels of the wizard block to change. In the left panel (the checklist), the user can also expect the colors, text bolding, and borders to change to indicate which page is selected.
3. Possible errors that may result (if any) and corrective suggestions for user. Programming errors may result in bad mappings and false status reports. If error checking is bad, the notification feature may require modification.