Counting Pages Visited?

[PetrH]

I'd like to get the number of pages in a book where the page "visited" property is true. I am assuming that the visited property would be restored by an LMS if the lesson is launched from an LMS.

In any case, I need to be able to produce a count of pages that have been visited. I am trying to come up with a way to show progress through a lesson using the couple of rectangles on the background.

So far, I can determine the count of "critical" pages in the lesson. This number is needed as part of the calculation to determine a user's progress. I am having trouble coming up with code to determine the number of those critical pages that have the visited property set to true.

I have a list of page names to check in an array but how can I construct a statement to return the 'visited' property of another page in the book?

Ideas?

[Clifton]

I think the PowerPac function getPageNameList() is just what you need. This function analyzes the pages of your book and returns a list of qualifying pages based on the parameters you set.

Setup Example:
pgRange = "all"
Next parameter defines which pages to analyze. If you only require that your student visit certain pages, then use a filter to analyze only those pages. For example if the required pages all have the a pattern to their page names like "Critical 1", "Critical 2", "Critical 3" and so on ...
filter = "Critical "
... or use a regular expression like "/^Critical \d+/" which analyzes all pages whose page names begin with "Critical" are followed by a space and then any number of integers.
scope = "visited"
excludeCurrentPg = "" (leave blank for default)
listSeparator = "," (or choose a separator that is not contained in any page names if a comma causes a conflict)
sort = (leave blank for default)
resultFieldName = (leave blank for no hyperlinking; default)
... store return value in a variable like pageList

The result will be a comma-separated list of pages that have been visited in the pgRange and filter.

Now we need to count the number of pages returned by spitting pageList to an array and storing the count. We do this with pgSplitToArray():

Split to array parameters

Image 1.png (10 KiB) Viewed 912 times

The variable pageList now is an array where each index is one of the visited pages AND index [0] is the count of pages returned.
To access the count you would use pageList [ 0 ] in the actions editor.

Finally, you need to call this routine in a location where the LMS has already restored the previous session so it can be read back in by these functions. I would recommend trying to call it on load page for the background as this is one of the last events processed when the first page of the book loads.

Here is how simple this might look:

Actions for on load page for background

Image 2.png (3.04 KiB) Viewed 912 times

getPageNameList() is a powerful function for evaluating user interaction with a range of pages in a book. Using it to setup a progress bar is just one of its many uses.

Have fun!

[PetrH]

I looked at using getPageNameList() but only to get a list of pages to then examine for their "visited" property. What I didn't realize until your example, is that I could use it to do all the work for me. I didn't see in the help documentation that I could use the scope parameter to further limit the results to just pages that had the visited property set to true. Don't know how I missed that... guess I need to clean my glasses more frequently.

Fortunately, I already named the critical pages with "CP_" as the initial 3 characters of the page name so the filter already works.

Now, I wonder how much overhead this will add to the background. The basic question now, is should I just run this routine every time I need to update the progress bar on the background, or should I just use some other logic to increment a global var that is then used to update the progress bar. I don't see any reason this can't be in a shared action and just called anytime I need it.

Thanks!
Pete

[Clifton]

There is no real reason to put any of these results in a global variable because the way the PowerPac queries for this information is all based on stored/cached data already so the whole process is pretty fast. Plus if you use another variable that has to be managed, you risk getting things out of sync from what is actually the case with how your pages are being progressively visited. Admittedly the HTML help docs are out of date for many functions and we are working to remedy that, but the popup parameter help is always up-to-date; so you can always rely on that.

Glad this worked out for you, and thanks for posting to the listserv too as this keeps other ToolBook developers informed of the many powerful abilities the PowerPac adds to their projects.

[PetrH]

In my current prototype lesson, I'm just calling the same shared action as each page loads. Don't notice much of a delay and this keeps it to just one shared action with no global vars at all.

Next I need to work on hiding and showing the progress bar between page changes because if you are on a slow connection, you see the progress bar show 100% for a moment before adjusting to the correct size.

Glad to help on the toolbook list!

Pete

[Clifton]

Just an idea?
Put the progress bar on the background of the page and then the changes to it will be persistent during page navigation. If you need to stack it on top of page elements, just use changeObjectLayer() because that function can change the context of a background object to a page or foreground context without losing the connection within the ToolBook export structure (in other words, objects that think it is on the background will still be able to refer to it).
This is something I do a lot to save the need to copy something to several pages.
Also:
If the progress bar does not have to show on all pages, then just include the logic to hide it on the pages that should not be showing a progress bar.