Well, I guess I'm out of place here:
There have been cases when a once cool, simple application gradually became way too complex, slow and crammed with options and features. It passed from being as refreshingly simple as an Ultralight trike plane to becoming as button-filled as a Boeing 777. Among these are:
- MS Word (Come on... so much buttons just to write a letter?)
- MS Outlook (I stopped using it a few years ago because of that)
- Winamp 3 (I had to go back to Winamp 2)
- MusicMatch (I still have a now ancient version, and I prefer it)
- DivX Player (idem)
And I don't want that to happen to Stackz!
Stackz! goal has -so far- been to emulate a stack of physical flashcards, giving us the cool feeling of being in complete control of the process.
Improvements brought with each version sought just to streamline the process.
IMHO, Stackz! is almost perfect just as it is.
I really think adding links to audio files would be nice, but it would have to be implemented in a discreet way that does not destroy the Wabi-Sabi, the Zen beauty of the program, and these features should be concealed from view to those not interested in using them. Just like stowing away a futon when you're not using it. The room you're using should have only the furniture you need right now.
I liked Gigapops approach, and here I'll try to flesh it out. The following is just a proposal of how these features could be discretely concealed, and at the same time easy to activate:
If someone wishes to have a sound file linked to some of his cards in a file:
In the file options dialog, the column name "File Language" is already a misnomer, since most users have different languages mixed in a single file. A more appropriate name would be "Attribute language", or, making room for sound and images, "Type of content". Then, when clicking in the "..." button, one could choose if the content type for the selected attribute is either text or sound. If one chooses text, the "Select language" dialog would appear, but if one chooses "sound", there is nothing else to be set. Then, when one is in edit mode, one could just write the relative or absolute path to the sound file in the cell reserved for that Attribute within the current flashcard.
A concrete scenario: Let’s say that someone decided to make room for sound file links in the column where the “Entry” attribute normally resides. Of course, he would have renamed this column to “Sound” or something like that, and selected “Sound” from the “Type of content” column in the File Options dialog. Then, in the Edit dialog, in the cell reserved for the link to the sound file for Japanese word “Sumimasen”, he would just have to write, let’s say, “C:\stackz_sounds\sumimasen.mp3” (absolute path), or, if he is more organized and has all the sound files in a sub-folder names “sounds” within the same folder containing the Stackz! Files, he could just write “sounds\sumimasen.mp3” (relative path). Then, during test, instead of displaying the actual link (which would give away the answer), Stackz! Could display a text message, something like “Press P to play sound”.
To keep Stackz! simple, perhaps it could invoke a background sound player to do the sound-playing stuff instead of trying to integrate a sound player within Stackz!. I think there’s a sound player integrated in Windows… but Winamp is a lot more open to sound formats…
Well, just dreaming… As I said before, Stackz! is almost perfect just as it is, and this is just a suggestion about how to implement new features without making it way too gaudy or flashy.
As a final note, from the two file linking approaches (Absolute or relative), I really favor the relative approach, because it would make it a lot easier to share the new stackz! lists with sound links… The creator would just have to pack both the stackz! file and the folder with the linked sounds into a RAR file, and upload them, knowing that there isn’t going to be any broken link issues when someone downloads and unRARs his bundle.
I'll make mock-up images of how this will work when I get some free time.