Problem Skeleton Exercise Pt1

Owned by Connor Haugh (Deactivated)
Sept 20, 2022
2 min read

May 9, 2022 | Problem Skeleton Exercise Pt1

Attendees: Bernard Szabo Ben Warzeski Connor Haugh Jeremy Ristau Ken Clary Raymond Zhou

Important Resources: 

Project Board: Content Libraries

https://jamboard.google.com/d/10qZppFd6ynmtz8QhOfcMl_hqTcSHgmyAySQelbw1YZ0/viewerhttps://github.com/open-craft/capa-visual-editor/blob/master/visual-editor/src/containers/ShortAnswerContainer.js

Agenda

  1. Views outline

  2. Identify The “The Tree” to create Stubs

    1. What top-level views do we have?

      1. “Landing Page” Select Problem Type View

        1. Outer chunk (Widget)

          1. Header: 

            1. Text, 

            2. Cancel (This is a stub)

          2. Footer: Cancel, Select Button

          3. Content:

            1. Problem Type Select (Remains Static)

            2. Preview (Content of chunks varies based on problem type)

              1. Title

              2. Preview 

              3. Description

              4. Help Link

      2. “Edit Problem” View

        1. Outer Chunk -> Editor Container

        2. Question

          1. Text Editor

        3. Answers

          1. Title 

          2. Description

          3. Answers

            1. Row “Answer”

              1. Singleselect

              2. Multiselect

              3. Text Field

              4. Feedback popup

                1. Positive

                2. Negative

              5. Delete

            2. Add Row

        4. Settings

          1. Title 

          2. Set Of collapsable widgets

            1. Basic settings

            2. Expandable: advanced settings

      3. “Bad Markdown” View (Error State) (not really a separate view)

    2. What is the top-level structure of those views

    3. How does the user

  3. Component dive “Iterate on stubs”

    1. What are the componentry chunks of the different core widgets of the UI?

    2. What are the variations between the different views in componentry?

  4. Implementation considerations

    1. Re-use considerations: 

      1. What can we reuse from the core UI to implement this?

        1. Editor Container  ->   “Edit Problem” View 

        2. TinyMce stuff

        3. Settings Widgets ->  

      2. What do we need to tweak in those tools/widgets to match the requested design?

        1. Answers have default set each time

    2. Default values and initialization behaviors: Are there any state-tied pieces of the design that will be the responsibility of the UI, such as initial/default values and behaviors?

  5. Data Design

    1. What are the top-level pieces of data we want to track?

      1. Core Redux Data App:

        1. Problem Type: (String)

        2. Question (html)

        3. Answers[] (ordered)

          1. List of answers:

            1. Feedback: { selected, notSelected }

            2. Text <string>

            3. isCorrect

        4. Settings: <Key>/<Value> Store

      2. No need to save static guard rails – these can go in config files

    2. How should it be structured?

  6. Actions