Re: gperiodic

[Camilla R Fox <cfox@mit.edu>]

> > Another thing occurred to me.  Camilla raised a valid point about
> > accents and dialects.  If we try to provide audio files for all
> > languages and accents, the program will become gigantic and unwieldy. 
> > How about providing an easy-to-use interface for the instructor using
> > the program to record those audio files him or herself?  That would keep
> > the download small and allow the audio to be immediately localized for
> > the particular environment.  It could be considered just part of the
> > initial setup.

Note that I haven't suggested doing too much variety of accents, I just
brought up the issue as a potential problem, in particular that your
audience will be limited by it.  Most of my argument was a recomendation
to avoid featuritis, justified by bashing the feature in question.

The ability to add audio files would be nice (provided that you
want audio at all), but I don't think it belongs in gperiodic itself.
This is because it's going to take a fair level of ability (beyond what
is assumed by gperiodic) to record audio files, even with all the help
that gperiodic can give.  Because of this, the audience of people willing
to record sounds is much smaller than that using gperiodic, and those
people (presumably a teacher or administrator) can read documentation
telling them to "use this or that program to make audio clips Ns long,
and give them the following file names, in such and such a directory".

Adding a feature to the main program which will only be used by 1%
of it's users is a problem - that 1% will probably be better served by
a specialized program, and the other 99% will waste time figuring out
what the extra feature does, as they explore the program.

The other issue with the "user add audio files" idea is that we don't
seem to have a clear idea of who the audience is; if the audience is
foreign students in their homes, then the audio is useful to them, but
they have no means of recording it.  If the audience is school kids in
a classroom, they have a teacher who can record audio files, but does
the school computer lab really want all the noise pollution that using
the feature is going to cause?  Besides, if the students are together,
they will pick up pronounciations correctly, without even noticing that
they are doing so.  Essentially, the only people who would benefit from
the audio are those that don't have a teacher who can demonstrate the
pronounciation.

> my idea was to break the language/pronounciations out into seporate pakcages,
> and allow the user/installer to only download the particular portions
> they were interested in.  If space is really an issue, we could use the
> mp3 format (average 10 to 1 compression), or real audio format, and invoke
> an external player to output the sound.  That would keep the size down as
> a whole, and allow users to select only the portions they wanted/needed.

Increasing code size is far more dangerous than increasing data size.
Code must be debugged and maintained, so extra functionality, along with
extra dependencies, will make the program harder to install and maintain.
The system of a bunch of uncompressed data packages one of which will
be downloaded and installed seems just fine to me - remember, storage
has come down in price a lot, and optimizing for space at the expense
of maintainability, favorable licence, or elegance, is a waste.

-Camilla