Skip to content

Design Criteria

Jump to bottom
Kent Rasmussen edited this page Feb 7, 2023 · 7 revisions

Design Criteria for a Computer Tool to Model and Document Participatory Methods

This page lays out the design criteria for A-Z+T, from larger issues to more detail, including examples of how they are implemented.

Facilitate a Participatory Method

Not pose any significant barrier to participation

The user interface should be intuitive and require no more than one hour of orientation for someone who has never used a computer before

  • Decisions the user is asked to make should be straightforward and presented in sufficient context to make the point clear. For instance,
    • Icons should accompany instructions, for more immediate visual clarity.
    • Utterances are presented in their entirety, so users compare whole utterences with whole utterances (i.e., 'two dogs' rather than '2 + the plural of dog').
  • In most cases, the user should simply select from an appropriately minimal set of options. For instance,
  • Syllable profiles are selected from those actually present in the current lexical category.
  • Lexical categories are selected from a list of those present in the database.
  • Where keyboard entry is needed, users should be presented with one field at a time, to minimize the possibility of putting data in the wrong field. For instance,
    • tone frame definition requires the user input content before and after the form in each language, resulting in six (6) fields for a language form and two gloss languages. Each of these is set in its own window.

In addition to the need to meaningfully engage the computer novice, the tool should respect the various competences participants may have, e.g., language, analysis, logistics or management.

  • Where possible, tasks should depend largely (or entirely) on just one competency. For instance,
  • Sort tasks depend on native competence in the language only.
  • Transcription tasks depend on transcription competence only.
  • the tool should never present a decision in a way that depends on a competence unnecessary to that decision.
  • Transcription tasks reference sound files, so transcription can be done without native comptetence.
  • Sorting tasks generally do not reference group names (except as numbers); knowning phonetic values of surface sort groups is not required for the sorting process.

All other tasks should be managed by the tool, outside of the view of the user.

  • All tasks that can be automated should be. This includes anything not depending on human judgment, either of language comptetence or analysis. For instance,
  • Deciding which tasks the user(s) are ready to do, based on work done so far.
  • Selecting the largest (or next) slice of data to work with
  • Recording individual decisions to the database
  • Saving database to disk
  • Deciding the next word/utterance to evaluate
  • composing whole utterances out of words and frames
  • saving, naming, and linking recorded sound files
  • analyzing, sorting, filtering and presenting data in reports
  • The tool should automatically record judgments in real time, rather than wait for the initiative or confirmation of the user.
    • This would allow for maximum interruptibility in the face of power outages and other electrical inconsistencies.

The logic and function of the tool must be highly fault tolerant

  • whether a fault might come from
    • inexperience with computers
      • clicking with the mouse on the wrong place (or wrong button) should be easily recoverable
    • human error
      • clicking on the wrong button, releasing too soon (on recordings), or not speaking correctly (again on recordings) should each be easily recoverable.
    • the chaos natural to the participatory collection of data.
      • any speaker judgement can be undone through a cyclical process, if it is determined later by the group to have been wrong.

Document a Participatory Method

To sufficiently document the work, the tool must

facilitate the collection not only of speaker judgments

facilitate the collection of sound files to confirm speaker judgments

All data should be stored in a future proof manner

That is, data should be encoded in unicode plain text, in a format which is

  • a non-proprietary,
  • publicly available
  • XML This is necessary to ensure that data is both manipulable by current technology (e.g., XSLT), and will remain readable in the future —even in the face of legacy font loss or radical changes to proprietary utilities or formats.

Recordings should be appropriately linked to the lexicon

File names should be meaningful, including multiple identifiers like

  • the form itself
  • name or context
  • gloss
  • identifier for the relevant lexical entry or sense.

For example:

  • Nom-1s_poss__L_33cf6761-73e3-4224-8458-63602c3d54e7_example_magər_ga_mon_ma_milieu_.wav
  • Nom:Lexical Category
  • 1s_poss__L:Frame name_
  • 33cf6761-73e3-4224-8458-63602c3d54e7:Database GUID
  • example:field name
  • magər_ga:form
  • mon_ma_milieu:gloss (composed) Including this information in the audio filename makes the file system itself a searchable archive, useful to a much wider set of tools —including whatever sort, filter, and media playing functions are native to one's operating system.

Additionally, the tool should generate reports which either link to or embed available recordings.

The tool must use a distributed, version controlled repository. It should in no other way depend on an internet connection

Collaboration and archival are essential for team work. Work should have maximum robustness in the face of internet instabilities.

The tool itself should be cross-platform and built on open tools.

This is to ensure the widest possible base of people who can maintain and use the tool in the future.

Clone this wiki locally