PhoneticExplorer: Difference between revisions

From OLPC
Jump to navigation Jump to search
(added Status section)
 
(3 intermediate revisions by 3 users not shown)
Line 4: Line 4:


The IPA symbols are displayed; user can click on a symbol and hear it pronounced.
The IPA symbols are displayed; user can click on a symbol and hear it pronounced.

==People==
==People==
The following people are interested in or committed to working on this project:
The following people are interested in or committed to working on this project:
Line 30: Line 31:
* Finding reliable quality, copyright-unencumbered sound recordings
* Finding reliable quality, copyright-unencumbered sound recordings
** Wikipedia seems to provide recordings in GNU Free Doc License; is the quality good, across the board?
** Wikipedia seems to provide recordings in GNU Free Doc License; is the quality good, across the board?
** Follow up on possible permission to use the sounds from [http://www.sil.org/computing/catalog/show_software.asp?id=16 IPA Help]; quality is good.
* [[OLPC_Human_Interface_Guidelines]]:
* [[OLPC_Human_Interface_Guidelines]]:
** What does collaboration/sharing mean in this activity?
** What does collaboration/sharing mean in this activity?
*** Maybe a teacher guiding/watching the student's exploration?
*** Could do a collaborative matching game; maybe that would work best simply as a data set supplied to the existing Matching activity.
** Competing goals:
** Competing goals:
*** conformance to OLPC-specific HIG
*** conformance to OLPC-specific HIG
*** portability to other low-cost computing platforms
*** portability to other low-cost computing platforms
===Portability===
* Given the split between OLPC and Sugar, and the inability to predict where a particular hardware or software platform will go in the next year let alone five years, one design principle I would like to observe is keeping the activity as portable as is practical. In particular, whenever Sugar- or XO-specific classes and methods are used, we should check whether those are available; and if not, ignore those features gracefully. I would like children to be able to use this activity on a Classmate or EeePC as well as the XO, rather than have the program needlessly tied to one platform. Obviously, there are some innovative features of Sugar that will be unavailable in other environments; let's take advantage of them on Sugar, but not make the program unusable on other platforms. To this end, it's probably sufficient to keep testing the program in a Sugarless Python environment, e.g. Python on Windows and (Sugarless) Ubuntu.


==Development approach==
==Development approach==

Latest revision as of 15:04, 30 April 2009

Potential resource material: IPA chart

Basic idea

A phonetics toy, allowing children basic exposure to sounds of the world's languages, via the International Phonetic Alphabet (IPA).

The IPA symbols are displayed; user can click on a symbol and hear it pronounced.

People

The following people are interested in or committed to working on this project:

Please add your name here if interested in the project (and feel free to contact Lars).

Features

  • sounds are organized into rows (e.g. nasals) and columns (e.g. bilabials) and other categories
  • hover mouse over a symbol to see its full name
  • click on a symbol to hear it pronounced (in context?)
  • double-click a symbol to add it to your "tray" at the bottom of the screen
  • click a "play" button next to the tray to play the sounds of the tray in sequence
  • save your tray contents to the journal, tagged as "phonetic words" or something. Tagged as "words", "phonetic"

Future Directions

  • could integrate to word list building, dictionary building, etc.
  • special project: give kids a structure to build a mapping from their writing system to IPA symbols. Then they push the 'play' button for letters -> IPA -> audio transformation: instant feedback. (Idea from Paul Zwierzynski)
    • This should have the advantage (compared to Speech / espeak) that it can be customized to minority languages by mother-tongue speakers of those languages.
  • Idea: The child types a word [orthographically, not using IPA], then speaks it. The computer finds the best 3-5 IPA matches for the spoken sample (where do we get audio->IPA mapping functionality?). These matches are then synthesized and the child chooses the best match. The winning IPA match is added to the dictionary, and the synthesizer and recognizer "learn" from the sample to improve future performance. (Idea from Corey Wenger)

Design / Development Challenges

  • There is far more information that *could* be displayed than will fit on the screen.
    • Scroll it? OK, if necessary.
    • Display the broadest categories only, and drill down to get to the symbols? Not great for exploring.
    • Display only most common symbols on main page, and drill down for less-common symbols?
  • Finding reliable quality, copyright-unencumbered sound recordings
    • Wikipedia seems to provide recordings in GNU Free Doc License; is the quality good, across the board?
    • Follow up on possible permission to use the sounds from IPA Help; quality is good.
  • OLPC_Human_Interface_Guidelines:
    • What does collaboration/sharing mean in this activity?
      • Maybe a teacher guiding/watching the student's exploration?
      • Could do a collaborative matching game; maybe that would work best simply as a data set supplied to the existing Matching activity.
    • Competing goals:
      • conformance to OLPC-specific HIG
      • portability to other low-cost computing platforms

Portability

  • Given the split between OLPC and Sugar, and the inability to predict where a particular hardware or software platform will go in the next year let alone five years, one design principle I would like to observe is keeping the activity as portable as is practical. In particular, whenever Sugar- or XO-specific classes and methods are used, we should check whether those are available; and if not, ignore those features gracefully. I would like children to be able to use this activity on a Classmate or EeePC as well as the XO, rather than have the program needlessly tied to one platform. Obviously, there are some innovative features of Sugar that will be unavailable in other environments; let's take advantage of them on Sugar, but not make the program unusable on other platforms. To this end, it's probably sufficient to keep testing the program in a Sugarless Python environment, e.g. Python on Windows and (Sugarless) Ubuntu.

Development approach

  • Copy an existing activity like TamTamMini to make a grid of symbols linked to sounds
  • Set up a few (half a dozen) sounds with symbols, names, sounds, grid layout. Start with consonants. Then vowels. Maybe never diacritics & suprasegmentals (until Graphite is ported to the XO?).
  • User testing with children
  • Fill in the gaps
  • Release early and often (as soon as presentable): don't get bogged down in comprehensiveness, complexity and advanced features
  • OLPC_Human_Interface_Guidelines:
    • Sharing/collaboration:
      • Share the tray?
      • Go see what sharing looks like in other, similar activities. How do you avoid fighting over navigation control? First one in gets control?
    • OLPC-specific HIG features, like sharing and journal, should be implemented in a modular way so as to allow relatively easy replacement or removal when porting to other low-cost computing platforms.

References

Status

Still in initial envisioning / design stage. Suggestions and volunteers are welcome!