Re: [WWdevel] webwork page caching

[Sam H. <sh...@ma...>]

On Nov 3, 2005, at 11:02, John Jones wrote:

> Hi all,
>
> I also use the back button frequently, so I kind of like things the  
> way they are.
> For students who use the back button and then are mislead by what  
> the page says (be it "you still have 10 minutes to finish" or "you  
> have 2 attempts left on this problem"), I think that those students  
> don't deserve much sympathy since they did something to create the  
> problem situation.  Moreover, understanding what has happened with  
> web forms and the back button is no longer just for geeks.  With  
> internet shopping, it is now more of a basic life skill.
>
> That said, I would not be strongly opposed to adding no-cache,  
> especially if it were just for students (I sense another addition  
> to the permissions hash - which makes it easily reconfigured on a  
> course-by-course basis).

One low-impact improvement would be to place the timestamp more  
prominently on the page, and perhaps label it "Generated" or "Current  
as of" rather than "Updated" or something.
-sam

> P Gavin LaRose wrote:
>
>> Hi Sam,
>>
>> The biggest reasons I was thinking this could be a problem were:
>>  - On gateway tests I maintain a timer on the page indicating how  
>> much
>>    time is left.  At the moment I'm doing this as a countdown from  
>> the
>>    amount of time left when the page is first loaded---going back  
>> to this
>>    page therefore results in the student thinking that s/he has  
>> more time
>>    than is the case.  I can work around this if need be, but I  
>> think it's
>>    really part and parcel of the second comment, viz.,
>>
>>  - In general, when going from page to page working a problem the  
>> previous
>>    page's information won't reflect the current state of a  
>> problem.  This
>>    is particularly relevant when there are a fixed number of  
>> attempts at a
>>    problem, so that going 'back' makes it appear that one has more
>>    attempts than is actually the case.
>>
>> I agree that being able to go back through the browser's history  
>> is very useful, however.  One option would be to no-cache student  
>> pages, or for students only.
>>
>> I'm not entirely familiar with where WeBWorK is using GET vs POST,  
>> so I don't know where that becomes an issue.
>>
>> Gavin
>>
>> On Wed, 2 Nov 2005 at 23:35 Sam Hathaway wrote:
>>
>>> On Nov 2, 2005, at 11:34, P Gavin LaRose wrote:
>>>
>>>> Hi all,
>>>>
>>>> Watching some of our gateway testing, the following occurred to  
>>>> me: it would be good to avoid students being able to use the  
>>>> browser's "back" button to navigate.  And then I thought that  
>>>> this should be a desirable state of affairs in general.  Because  
>>>> WeBWorK pages contain state data, we don't really want people  
>>>> going back to previous pages.  I use this occasionally when I'm  
>>>> working as a course administrator, but on student pages I think  
>>>> it's something we don't want happening.
>>>>
>>>> Would it make sense to add a 'no-cache' command to the header of  
>>>> all WeBWorK pages, so that it would force the browser to go back  
>>>> to the server to get each new page?
>>>
>>>
>>> Is the problem just that there could be out-of-date information  
>>> on cached pages? (Like the case where a user attempts a problem  
>>> for the first time and then hits back to return to the problem  
>>> list and it tells her that she hasn't attempted it?) Or are there  
>>> more dangerous cases? (If there are those should be removed  
>>> regardless of whether we add no-cache.)
>>>
>>> I actually like being able to quickly pop back to the previous  
>>> page and then forward to the current one one without reloading.
>>>
>>> If we added no-cache we would also want to be more careful about  
>>> when we use POST versus GET. Good browsers warn you when a POST  
>>> request needs to be resubmitted (like in the case of no-cache)  
>>> and this is annoying when the re-POST isn't actually dangerous.
>>> -sam