/
Problem Skeleton Exercise Pt1

Problem Skeleton Exercise Pt1

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/viewercapa-visual-editor/visual-editor/src/containers/ShortAnswerContainer.js at master ยท open-craft/capa-visual-editor

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

ย 

ย