Challenges in QuML Spec and UI Design

Introduction

There are some challenges which we face currently with the QuML Spec. Existing spec restricts how the Question will look in UI and lots of CSS is needed to manage the look and feel.

How Questions with Plain Text Get Stored in DB

If we want to add a question with simple text: What is the Capital of India?

It gets stored as:

<div class='question-body' tabindex='-1'>
    <div class='mcq-title' tabindex='0'>
        <p>What is the Capital of India?&nbsp;</p>
    </div>
    <div data-choice-interaction='response1' class='mcq-vertical'></div>
</div>

How Questions with Images Get Stored in DB

If we want to add a question with simple text + image: What is the Capital of India? + IndiaGate.jpg

It gets stored as:

<div class='question-body' tabindex='-1'>
    <div class='mcq-title' tabindex='0'>
        <p>What is the Capital of India?&nbsp;</p>
        <figure class="image"><img src="/assets/public/content/assets/do_21408871175179468812/indiagate.jpeg"
                alt="indiaGate" data-asset-variable="do_21408871175179468812"></figure>
    </div>
    <div data-choice-interaction='response1' class='mcq-vertical'></div>
</div>

Since the data in the database gets stored in the form of HTML markup, it creates a problem in UI handling images of different sizes and resolutions.

Storing Images in Options

Similar to questions, the images in options get stored in the form of HTML markup as:

Option 1 - New Delhi + indiaGate.jpg It gets stored as:

<p>New Delhi</p>
<figure class="image">
    <img src="/assets/public/content/assets/do_21408871212497305613/indiagate.jpeg" alt="indiaGate"
    data-asset-variable="do_21408871212497305613">
</figure>

Option 2 - Mumbai + gateway-of-india.jpg It gets stored as:

MCQ metadata example:

Editor UI

Player UI

To address the challenges there are few proposed format in which we can store the question and options

Format 1:

Example JSON:

Pros:

Simplicity: Each content type is stored in dedicated fields, ensuring straightforward data management.
Readability: Clear field names make parsing and understanding easy.
Efficiency: Direct access to content without needing to iterate through arrays.

Cons:

Scalability: Adding new content types requires modifying the schema and related code.
Redundancy: Options include all fields, potentially leading to empty or redundant data.
Flexibility: Limited in handling multiple instances of the same content type efficiently.

Format 2:

Example JSON:

Pros:

Flexibility: Supports multiple instances of the same content type with an array-based structure.
Scalability: Easily accommodates new content types by adding objects to the content array.
Consistency: All content types are handled uniformly, aiding in processing and rendering.

Cons:

Complexity: Requires iterating over arrays to process different content types, adding parsing overhead.
Readability: Nested structure and type-checking can reduce immediate readability.

Format 3 (Recommended):

Example JSON:

Pros:

Simplicity: Clearly separates text and media, enhancing clarity and ease of handling.
Readability: Explicit fields for text and media improve understanding.
Flexibility: Supports various content types within a structured format.

Cons:

Scalability: Introducing new content types may necessitate schema and code adjustments.
Redundancy: Potential for empty fields depending on the question's media requirements.
Specificity: Structured format may be less adaptable for multiple instances of the same content type.

Summary: Format 3 stands out as the preferred choice due to its balanced approach in terms of simplicity, readability, and flexibility. It efficiently manages different content types while maintaining a structured format suitable for question data storage and rendering.