Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

[Michael G. <ga...@ma...>]

Hi Davide,


On Jan 5, 2006, at 4:56 PM, Davide P. Cervone wrote:

>> I've been changing on the PGeditor incrementally during this last  
>> semester (and also trying to use it to write and fix the problems  
>> I use so I get the full experience) but I still think there is a  
>> lot work to do.  Part of my plan has been to bring the action  
>> buttons on that page in line with the style used on the "Hmwk sets  
>> editor" and "Classlist editor" pages.  I also wanted to make it  
>> easier to make a local copy of a library problem, since this has  
>> been requested by several users on hosted.
>
> Those are all good ideas, and they help.  But the editor doesn't  
> work properly with set headers: sometimes get error pages, can't  
> preview, the good and bad error messages are confusing and  
> sometimes contradictory (e.g., if you edit the default header file,  
> then save a new copy, you still get a a message about editing the  
> default file, then a message about a saved file, then another  
> message about a new local copy), you can't rename the header file  
> using "Save as", and so on.

My personal preference would be to get rid of the hardcopy set  
headers and make set headers complete synonyms for
problem 0.  This would solve a lot of special cases that need to be  
handled in the PGeditor.  The downside is that some
people like to use direct HTML in set header files which will then  
not work when hardcopy of the problem sets are corrected.  Perhaps we  
can figure out an ordinary PG problem format that will satisfy everyone.

> Things were in better shape for problem files, but I found the  
> "Save as" and "Save a copy as" buttons to be named in a way that  
> didn't correspond to my intuition of what those names mean.  My  
> expectation of "Save as" (from other programs) is that it makes a  
> copy of the file, leaving the original unchanged, and starts  
> editing the new file, while "Save a copy as" would make a copy of  
> the file but continue editing the original.  The effect of "Save  
> as" in the new arrangement is to make a new copy, edit it, AND  
> CHANGE THE PROBLEM SET to use the new problem.  That last effect  
> was a complete surprise to me, and counter to my expectations for  
> save as.  "Save a copy as" does what I think "Save as" should do,  
> and "Save as" does what I think "Rename" or "Reassign" or some  
> other such name should do.  I'm not quite sure what "Make a local  
> copy" is for, if you have "Save a copy as", but since it isn't  
> often showing, I didn't worry about it too much.
>
"Reassign" or "rename" sounds like a good suggestion to me.  I agree  
that the nomenclature is confusing, but I couldn't think of anything  
better at the time.

The "make a local copy" shows up when you are viewing a library file  
that can't be edited.  This was the first addition that was made and  
is for those using hosted courses and libraries of courses that they  
are not allowed to modify it shows up frequently.  It greatly  
simplifies that process of creating a local copy of the library  
problem and reassigning the file name path so that the problem set  
refers to the local copy.  It is then possible to make corrections or  
modifications. My experience is that this works pretty well, although  
there may be a better name than "make local copy".  Eventually I'd  
like to wire up John Jone's Compare module so that it is easy to view  
the changes between the local and library copy and then to make it  
easy to submit the local copy as a candidate to replace or supplement  
the library copy if that seems desirable.  This option shows up only  
when you are viewing a file that cannot be modified, so you might not  
see it often on your server.

The "save as" feature  was added later to allow you to perform the  
same function with problems that could be modified.
(e.g. you might have a problem that you liked but for this specific  
course you wanted to use a modification of it while still preserving  
the original file).  The "save a copy as" was added for  
completeness.  If you think of this as modifying the
problem in the current set, this nomenclature makes some sense --  
"save as" allows you to modify the problem that is currently being  
used in the set,  "save a copy as" saves a template of the current  
problem which you might, for example, want to later import into some  
other set as a template to be further modified.    Having said that,  
I'm not satisfied with the nomenclature either and would be glad to  
see suggestions for improvements.  I think the three functions are  
the correct ones (although "save as" and "make local copy" are really  
the same function applied in different contexts).

> Then there is the issue of opening new windows, which I always  
> found terribly confusing, and I think may have been the real source  
> of problem for our professors   For example, if you edit a problem  
> then view it, you get a new window (fine) and in that window there  
> is "Edit this problem", and pressing this gets me an editor in the  
> same window.  I now have two edit windows that I think of as being  
> the same file, but they aren't.  The new window opened a view of a  
> TEMPORARY file, and we are now editing the temporary file as a  
> SECOND temporary file.
Is this really true?  I don't think that more than one temporary file  
is created -- that certainly wasn't intended.  The original editor  
kept all temporary data in the HTML itself.  In some sense this was  
good, but lead to pretty large files being transmitted back and forth  
-- if your login timed out you were likely to loose all your edits.   
The current effort is to mimic this behavior but keep the temporary  
data on the server.
> Saving edits here saves to the first temporary file, and at this  
> point I have no way to get those changes into the original file.   
> Granted, the messages are telling me about which file I'm actually  
> using, but even after having spent quite some time trying to figure  
> out how it works, I still have to think hard when I look at the  
> file names to see that I'm doing what I should be.  For example, it  
> says I'm editing in a temp file, but I have to realize that saving  
> is to the NON-temp file, which is counterintuitive to me.  Plus I  
> get spurious messages about the temp file not being found (even  
> though the save message is generated).
>
I'll have to check this out.  I agree this is not desirable behavior.  
I though that a save operation always saved to the original file (the  
one without a .tmp extension).  I have one hypothesis of how this  
creeps in.
You may want to change the name of the temporary file in order to  
force the browser to refresh the data --
we had a problem a while ago where the data being displayed by the  
browser would not reflect the latest updates.
> I have to say I find the whole thing very confusing.  I don't like  
> to have several windows open editing different versions, and it is  
> FAR to easy to do that.  I would prefer to have one editing window  
> and one viewing window, and ALWAYS having editing occur in the edit  
> window and always have viewing occur in the other (rather than  
> sometimes have a window open, sometimes view in the same window as  
> the editor, and never know what is really going to happen, or where  
> you are).  I have to say, I understand why the faculty got  
> frustrated.  I don't see why you should be allowed to edit the  
> temporary file at all; when I view the file and then say edit it, I  
> would expect to back to the editing the same file I was viewing,  
> not a new copy of that file.

There is one problem with controlling the viewing and editing windows  
which we didn't know how to solve at the time, but perhaps can be  
solved now.  What you would like is a window named EDITOR and a  
window named "PREVIEW"
and you would like each to be properly linked to the other and you  
would like them to always contain current data.  You could bring up  
the second window as "PREVIEW" but there was no way to determine or  
assign the name of the first window.   In the early days we also used  
javaScript as little as possible -- it's possible we could relax that  
now in order to fix this problem.

Glad you are interested in working with the PGeditor.  It is one of  
the interfaces which I still think  could really benefit from  
additional work.

take care,

Mike

> Anyway, that's where I'm coming from with it.
>
> Davide

"Only dead fish swim with the stream."