Wednesday Notes

Wednesday

overview:

sketch out directory structure and project structure

The structure of Oahpa 2.0.

modules

General functionality-oriented module structure for backend

backend (data processing)

project configuration
- system settings
- languages available
- grammar data
learning progression
- create progression/levels
  - add task to progression
  - create deep links to progressions, or levels
- create/edit task
  - morfa-s: select question morphology, answer morphology
  - leksa: select question semantics and language, answer language
  - morfa-c: select template, task type, add words to empty slots
  - ... more for each type ...
  - adding help/reference info for tasks
- order progression
lexicon and grammar management
- group words into levels
- group morphology into levels
- choosing words for exercises
- adding help/reference info for words or categories
media management
- audio links/files <-> word relationships
- image links/files <-> word relationships
exercise generation
- morfa-s
  - answer type subclasses? text -> text, text -> select word, etc?
- morfa-c
- leksa
- numra
- vasta
- sahka
- dictation
- translation
- ... general subclasses for more ...
exercise answer validation
- numra: requires FST for answers
- morfa-s: uses database for answers (but also FST for orthography)
- leksa: uses database
- sahka: complex question
- ... more ...
- general mechanism for spell-relax
lookup server
- includes various pipelines
- main oahpa process launches this together with web/wsgi service
database
- installation and models
- maintenance
  - backup and restore
  - add/correct/delete a single object (word etc.)
user data
- authentication
- user roles (instructor, admin, linguist)
- survey responses
user interaction logging
- generated exercises and answers submitted by users (used for spaced repetition?)
- feedback submitted by users (error reports, suggestions for new words, example sentences etc.)
django localization
unit tests
feedback
- morphological feedback from user errors
- FST feedback from error FST
- morphology & syntax feedback tooltips for vasta
feedback / reporting errors in content

Functionality-oriented structure for frontend

frontend

introductory pages
- set interface language / help language (dialects?)
- surveys
- account creation
- data anonymity message
  - course selection (public vs private via deep link courses)
administrator interface
- user administration
  - student <-> teacher connections
- database tasks
  - extract
linguist interface
- browse lexicon, and FST to construct exercises
  - type in sentence -> turn it into a morfa-c exercise (or other)
- extract data for research
instructor interface
- create/manage progression & levels
  - add tasks to progressions
  - create/edit tasks
- create/manage lexicon
- create/manage reference and help info for levels and lexicon or morphology
- view student progress
- create localization translations
- access deep links to progressions, levels to invite users
student overview
- scores
- view progression (one of two 'paths to the top')
  - view exercises
- view tasks to jump to wherever (two of two paths to the top)
learning/exercise interface
- do exercise rounds
  - see exercise wordlist
  - do individual exercises
  - different exercise styles
  - report a bug / error in exercises
  - morfa-c
  - x text -> text
  - x text -> word selection
  - morfa-s
  - x text -> text
  - x text -> multiple choice?
  - x picture -> text
  - x audio -> text
  - etc... for each exercise type
- track student progress

misc:

consider: mobile vs. desktop views when responsive solution isn't enough

common app directory structure

we'll take the functional module structure from above and make it into the following django app structure:


    icall/oahpa/backend/levels
    icall/oahpa/backend/exercises
    icall/oahpa/backend/feedback
    icall/oahpa/backend/users

    icall/oahpa/frontend/views
    icall/oahpa/frontend/blah

intended deployment structure

Each language project should not be a copy of Oahpa, but we'll use the new Oahpa as a module which we can include in the Python environment via virtualenv, and constrain project-specific directories to including language rules, possibly lexica, and other options.

When updates to Oahpa occur, we can bump the version number in these projects.

    icall/rus_oahpa/
    icall/rus_oahpa/requirements.txt (oahpa==1.0.0)
    icall/rus_oahpa/grammar_rules.yaml - should be yaml?
    icall/rus_oahpa/lexicon/asdf.xml
    icall/rus_oahpa/morphology/asdf.xml

Perhaps something like a cookiecutter template would be useful for helping a linguist/programmer to get going on a new project?

app directory structure

backend

oahpa/backend/database - data structure oahpa/backend/configuration - project configuration oahpa/backend/generation - exercise generation oahpa/backend/answers - exercise answers oahpa/backend/linguistics - lexicon, grammar

oahpa/backend/tests - oahpa/backend/lookup_server -

oahpa/backend/progressions - learning progressions oahpa/backend/users - authentication, user data oahpa/backend/interactions - user interaction, logs

oahpa/backend/feedback - morphological feedback, error FST, oahpa/backend/suggestions - reporting errors in content

oahpa/backend/media - media oahpa/backend/localization -

frontend

oahpa/frontend/pages/ - mostly static content views oahpa/frontend/administrators/ - administrator interface oahpa/frontend/linguists/ - linguist-based frontend oahpa/frontend/instructors/ - instructor-oriented views interface oahpa/frontend/students/ - student overview oahpa/frontend/learning/ - learning / exercise interfaces

wireframes

We drew some wireframes, which we will upload somehow

landing page
package summary / are you following a course?
topics page
learning package A