Skip to content

Teacher — Live Preview (Dyglot Studio ↔ Dyglot Student)

One of Dyglot’s key design goals is to allow teachers to design learning views visually and see the result immediately on a real device (phone or emulator), without requiring programming skills.

This is achieved through a live preview mechanism between a desktop tool (Dyglot Studio) and a running Dyglot Student application.

Purpose

Live Preview allows a teacher to:

  • Design or modify a view (Question, Answer, layout, visible fields)
  • Instantly see how this view appears on a real student device
  • Validate readability, spacing, fonts, and information density
  • Test the transition between Question and Answer
  • Verify how the chosen learning engine affects buttons and behavior

All of this happens without rebuilding the application.

High-level Architecture

Dyglot Live Preview relies on a clear separation of responsibilities:

  • Dyglot Studio (Desktop)
    The authoring tool used by the teacher.

  • Dyglot Student (Mobile / Emulator)
    The runtime application used by learners, temporarily running in preview mode.

The two applications maintain a live communication channel.

Communication Model

The Studio and the Student communicate through a persistent connection, typically:

  • WebSocket (recommended)
  • or any equivalent real-time bidirectional channel

This connection allows the Studio to push updates instantly to the Student.

The exact transport mechanism is an implementation detail and may evolve.

What Is Sent to the Student

Dyglot Studio does not send executable code.

Instead, it sends:

  • A serialized description of the view
  • A structured representation of:
  • layout
  • fields
  • visibility rules
  • question/answer separation
  • presentation metadata

This description is interpreted by the Dyglot Student runtime.

Rendering Model on the Student Side

Dyglot Student contains a view renderer capable of:

  • Interpreting the view description
  • Rendering it using native UI components
  • Updating the UI dynamically when a new description is received

This renderer is shared between: - normal student usage - live preview mode

Role of the Learning Engine

The teacher selects a learning engine for each view (for example: V1-compatible, Anki-like, etc.).

The engine is responsible for:

  • Injecting the button bar (Good / Wrong / Easy / Again, etc.)
  • Managing progression logic
  • Managing session state transitions
  • Providing optional header information (stacks, progress indicators)

The teacher does not design buttons manually.

Buttons and header elements are generated by the engine, not by the view.

View Zones

A typical practice screen is composed of four logical zones:

  1. Header (engine-controlled)
  2. Question view (teacher-defined)
  3. Answer view (teacher-defined)
  4. Button bar (engine-controlled)

The teacher defines what is shown in Question and Answer.
The engine defines how progression works.

Question vs Answer

Dyglot does not assume that the Answer is merely a “revealed” version of the Question.

The teacher may define:

  • Two distinct layouts
  • Different visible fields
  • Different emphasis or typography
  • Different spatial organization

This allows: - traditional flashcards - complex multi-field questions - non-binary learning models

Preview Mode

When Dyglot Student runs in preview mode:

  • No session progress is stored
  • No statistics are committed
  • The student UI behaves as a sandbox

This allows safe experimentation by the teacher.

Design Principles

  • Teachers do not write code
  • Teachers do not design buttons
  • Views describe presentation, not logic
  • Engines describe logic, not presentation
  • Live preview must feel immediate and forgiving

Future Extensions (Non-binding)

Possible future enhancements include:

  • Multiple preview devices
  • Split-screen Studio + preview
  • Snapshot sharing with collaborators
  • Recording preview sessions

These are not required for the initial version.