- Assignment 3: Implement Quiz Content and User Data Persistence
Original Proposal 8/18/08: "Interaction Design focused on quiz and clue-pyramid features, as well as login, score and other user-data persistence. Implemented online."
Above all else, what I will remember most about this project was struggling with getting the quiz to work, which mirage-like, seemed to always be a receding goal. Along the way I grappled with so many different approaches to the problems that came up that I feel like I learned a huge amount more than I intended or should have ever to have wanted to.
The first big stumbling block was getting the right variables off of the quiz form and delivered to the processing script. This would have worked fine in any situation where the variable-set was finite and/or static, but since content units have an uncertain number of questions (and by association answers) the design really wanted to use arrays for the questions and answers. Naturally, to imlement this data structures were created to hold them in the database, as well as a joining table which linked questions to their answers. And code interfaces for converting the data from storage to presentation, and presentation to processing.
To make things interesting, the questions are numbered and the answers are lettered, and they are deliberately in a different order than one another. Getting the user's choices from the form to the processing script required "serializing" the arrays, storing them along side other static variables, and passing them through. Getting that figured out took me about 2 weeks. Or 3.
Scoring the quiz in the processing script was easy and basically always worked. What seemed like it would never work was getting the pyramid interface (yes, that's what I call it) to properly reflect the newly changed state. You see, I had this totally crazy seemingly over-simplified idea that I could make the pyramid interface load off the $pyramidid url variable and then store state there for all the quizzes the user had taken in their navigational experience of the site. However, I couldn't figure out how to get a script to update the url variable. It could be set in code, but it wouldn't change the "real" [not really] url variable, which was how the 4-million line pyramid interface worked.
So I ran through what I thought I knew about how to store state from one script to another: form variables (of course), cookies, sessions, (and thanks to Lester) database. The only one which I implemented besides form variables was sessions, and it was obvious that it would work, but I still had the problem of the pyramid interface, and there was no way that I was going to redesign that thing if I didn't have to.
To shorten the story a bit, I recently discovered a way to send the page to the url of my choosing at the end of quiz processing (sort of a "refresh"), and this sets the url variable, and the pyramid interface properly "remembers" the state of the quizzes as they accumulate. (It had "amnesia" for several weeks, mostly while I thought about it and asked various experts for advice who almost unequivocally said "there are examples on the internet, look them up").
So finally the quiz works and all that remains is to get the save link to save the user's quiz results to the database as their score. The question of whether I will have time to implement quiz results loading on login is doubtful, although the original requirements of the project didn't clealy establish this as a goal (despite its necessity for the site to really work).
