Proposed Refactoring of PictureChoice? and PictureChoiceLesson?
Right now, each "frame" of a PictureChoiceLesson? is stored independently. The resource contains the phrase, the correct image, and three incorrect images.
It may be beneficial to instead store a group of four frames together as one resource. This resource will contain four phrases, each associated with an image.
If the new way is adopted and frames are grouped together, there are a few advantages:
- The block of four phrases/images can easily be edited as one. If an image is updated, it must only be changed in one place instead of four.
- If a user clicks on the wrong image in a frame, the correct phrase for that image can be displayed alongside it, thus reinforcing its correct answer.
There is one difficulty that must be overcome, however. If resources store groups of 4 frames instead of frames themselves, one of the two things will need to occur:
- PictureChoiceLesson?'s will no longer have intrinsic order set by the author. Each time a lesson is used, the frames will be presented in a random order. Or,
- We will need to develop a way to address each frame individually, even though there are 4 frames stored in each resource. Possible solutions include:
- Use the "id" XML attribute within each item of the PictureChoiceGroup?, and address each frame using a URI fragment. One downside to this is that the w3c specifications seem to specify a fragment as something that a URL can have, not a URN. (This conclusion was arrived at very quickly and may actually be incorrect.)
- Simply create a tuple in the PictureChoiceLesson?, or anything else that needs to link to a specific frame. The first item is the link to the PictureChoiceGroup?; the second is the index of the desired frame in that group.
If we are going to go forward with this refactor, it would be very nice to do so before we have much content.
Resolution
This refactor was discussed in IRC on 2009-03-26. We decided to go ahead with the refactor, choosing the route in which PictureChoiceLesson?'s have no intrinsic order.
The refactor was completed on April 15 in changeset [fd134645e863e21d2597b1cb4bd009c7879541aa].
