monotasker / paideia Goto Github PK

flags should be added in Walk._introduce

Hi Jeff,

I'm thinking about what logic is missing still to make the interaction loop work. The one piece that I don't think is working at all at the moment is a "stay here" option when the user finishes a step. In the 'reply' state the view walk.load includes a button labeled 'map' that allows the user to return to the 'start' state and enter a new location via the map. That should work fine with (functional versions of) the existing code. But I'd like there to be a second button giving an option to 'continue' or 'stay here' (i.e., in this location). In that case what should happen is either

(a) if there are more steps in the current path, and those steps can be completed in this location, initiate the next step in the path;
(b) if the current path is finished, initiate a new path in this location (without going back to the map);
(c) if there are no more paths available in this location, initiate a StepStub step that tells the user "there's nothing more to do here right now" and presents a "map" button as the only option.

I've been writing more content and ran into a stupid design mistake (on my part) -- for multi-step paths I don't have any way of indicating the order in which the paths have to be completed. Could you take a look at this and suggest a solution and (if necessary) a migration path for the existing paths/steps? The one thing I've realized so far is that the order information can't be stored on the step because I want to be able to re-use steps in different paths (the regular expressions are a dog to get right sometimes!) and this may produce different orderings. So I think the ordering data will have to be stored either in the each path record or (probably not ideal) a separate junction table. Anyhow, this probably means that the steps can no longer be stored in a single list:reference field. The simplest thing, I guess, would be to hard-code a number (say 5?) of new fields into the paths table: db.paths.step1, db.paths.step1order, db.paths.step2, etc. This isn't very elegant but would probably be workable for the time being. If you have a better idea that wouldn't take too long to implement, please let me know.

Each student is required to complete 20 paths per day (successfully or not) at least five days per week. This means that we need to track these numbers and:

1. give the student a visual indicator at each step of how many paths s/he has completed in the current day.
2. aggregate this information in a report (in the student's profile page) that lists how many questions have been completed on each day. The old version of this logic (much of which would still work) is in models/paideia_stats.py

We'll need to provide for the possibility of students being in different time zones. We'll need to collect time zone data as part of user registration and make all of theses "daily" statistics based on the user's own time zone (not UTC or local server time). I think the best way to do this (already partially implemented in the old system) is to store all records in UTC and to adjust it on-the-fly based on the individual student's tz offset.

Ian

• shift from tags to badges

• order of multi-step paths
• add instructions
• divide answers with |
• correct spelling
• double-check regex for steps with bug reports

for bug_reporter, tips, and "more correct answers"

Hi Jeff,

I mentioned the child classes that inherit Step. None of those are necessary for the basic interaction loop except the StepStub (which at the moment is just a hollow placeholder). That is supposed to be a Step in which the prompt/response loop is left out. Rather than returning a 'responder', it simply returns a 'reply' and the student is presented with the usual navigation options for the end of a Step. This would be used where:

• The student no longer has any available paths/steps to complete in this location, but there are some available elsewhere; or
• The Npc is simply giving an information for an assignment (subsequent step) that must be completed in another location

I think it should be fairly simple to put together, since it's just a matter of skipping a stage in the Step interaction cycle.

Ian

I've written a default path that we should make appear if a user enters a location for which no paths are available at the moment. (This can happen without triggering a new tag introduction if there are still paths available in other locations.) The default path is id=30, but I've also created a tag "default" (id=70) that we should probably use to select it instead. That way I can create a few different default paths down the road (for variety). The single step in this default path is a step_stub, i.e. it doesn't call for any user response.

Not sure where the problem lies

I'm thinking again about why I moved Location and Npc into separate classes. It was because the information they hold doesn't necessarily change with the end of a Step or Path. So a student will often finish more than one Path in the same Location, speaking with the same Npc. What I was thinking, then, was that having them in separate classes would allow us to

• create a Location instance when the user first clicks on a map location
• store that instance in the user's session object
• send it as an argument when we instantiate every Path object
• until the user returns to the map (at which point we reset session.location to None)

Similarly, with Npc

• create an Npc instance when the user starts the first Step in this location
• if the user continues in this location after the Step is finished, prefer steps that are in the current path, but after that is factored in prefer steps that interact with the current (session) Npc
• that Npc object could then be re-used by the new Path and Step instances.

I'm not positive that having the separate classes is the way to go, so let me know if you see problems in my thinking here. Otherwise, let's go back to using the separate Location and Npc classes.

Cheers,

Ian

I was thinking more about your suggestion that we use cache() instead of the session object to store the active Path and Step instances. I've been thinking more about that and wondering whether the session object wouldn't be better because

• It's threaded, so (as far as I understand) will scale better with multiple simultaneous users
• I think I would actually like a single session to persist (be continuous) over a day -- in other words, I'd like students to be able to do ten minutes here, five minutes there, another ten minutes waiting for the bus on their phone, and have all of that continue a single session.

Do you see any disadvantages of that that I'm missing?

What I haven't looked into is (a) How session objects are destroyed; and (b) how the duration of a session object is set. They seem to roughly correspond to a calendar day, but that's just a vague impression.

Ian

The map is rendered differently on Chrome and Firefox and you can't click on locations in Chrome. The menu bar is also different in each browser. I've emailed screenshots that show the differences.

I decided to create a new db table called 'images' to hold all of the uploaded images for npcs, location backgrounds, etc. The upload fields in the npcs and locations tables have been removed and replaced by reference fields. These reference fields also have new names: locations.bg_image and npcs.npc_image respectively. So references to the old image fields will have to be changed.

The Npc class has two methods holding the logic that used to be in these two methods of Step. Npc.pick() used to be Step.npc() and Npc.img() used to be Step.img(). Those methods of Npc have the logic for selecting the right npc (based on location and step) and sets up the IMG() html helper. So you should just be able to cut and paste those methods back into Step.