One of my colleagues just made me aware of a somewhat confusing and disturbing feature of the problem editor.
If you are editing a local problem, which already exists (let's say it is called 3-4-01a-def.pg), you have two radio buttons that are confusingly similar:
1) Save to [TMPL]/3-4-01a-def.pg and View
and
2) Save to [TMPL]/__________________
where the blank will be, by default, filled in as 3-4-01a-def.pg.
So the two radio buttons typically have _very_ similar words next to them.
But, if you choose the second of those, and press "Take Action" then not only will the file not get overwritten (which is probably what you wanted to happen) but the text in the editing box will revert to the existing version of the problem, losing all your edits!
(Now, if you are canny enough to know what has happened, you can get it back though use of the back button, but if you aren't you probably just panic and are annoyed, etc.)
So my questions are:
1) Is the behavior I'm seeing the normal behavior for the problem editor?
2) If so, isn't it a bad choice for normal?
3) Does anyone know what to do to change this (before I go rooting through perl code)? I't like either the save to succeed (assuming it really is a local problem and I have write privileges) or to fail in a way that tells the author what to do, and doesn't appear to lose all the author's edits.
thanks, Hal
I think the two lines are
Save to ......
and
Save as ......
(the latter has come to mean that you will create a new file rather than over write the old one for most computer users).
Two thoughts -- capitalizing the A in "as" might help -- that might be enough to emphasize the difference. Very small changes in user interface can sometimes have a big effect.
I don't think that the file should be overwritten even if it is local and you have write privileges-- because presumably you were making changes to save in a new file but wanted the old file preserved. (To overwrite the current file you use the Save to... choice.)
However the error message could easily give directions for using the back button on the browser to recover your work. With more difficulty the changes could be preserved in the textArea box when the error message is presented -- I don't know how hard that would be without looking at the code -- it might be easy also.
The behavior you describe is "normal" in the sense that it works as designed. Editing through a web browser was pretty tricky when this module was first designed and written -- with AJAX and javaScript now commonplace and stable on browsers something much snazzier could be written which would make the user interface more intuitive.
Finally -- on a slightly different topic: Two things that can make editing easier.
(1) "It's all text" is a firefox plugin that allows you to
edit textArea blocks in your favorite editor. You do have to save twice -- first from the editor to the textArea block then from the textArea block to the server.
(2) if you are writing many problems, not just correcting small errors in existing problems, then using your favorite editor on your desktop or laptop in conjunction with the command line client in webwork2/clients might be the quickest way to write and test most problems. (The command line client doesn't currently do such a good job if there are static graphics involved.) There is a README in the clients folder. The command line client is fussy but it can be useful.
Save to ......
and
Save as ......
(the latter has come to mean that you will create a new file rather than over write the old one for most computer users).
Two thoughts -- capitalizing the A in "as" might help -- that might be enough to emphasize the difference. Very small changes in user interface can sometimes have a big effect.
I don't think that the file should be overwritten even if it is local and you have write privileges-- because presumably you were making changes to save in a new file but wanted the old file preserved. (To overwrite the current file you use the Save to... choice.)
However the error message could easily give directions for using the back button on the browser to recover your work. With more difficulty the changes could be preserved in the textArea box when the error message is presented -- I don't know how hard that would be without looking at the code -- it might be easy also.
The behavior you describe is "normal" in the sense that it works as designed. Editing through a web browser was pretty tricky when this module was first designed and written -- with AJAX and javaScript now commonplace and stable on browsers something much snazzier could be written which would make the user interface more intuitive.
Finally -- on a slightly different topic: Two things that can make editing easier.
(1) "It's all text" is a firefox plugin that allows you to
edit textArea blocks in your favorite editor. You do have to save twice -- first from the editor to the textArea block then from the textArea block to the server.
(2) if you are writing many problems, not just correcting small errors in existing problems, then using your favorite editor on your desktop or laptop in conjunction with the command line client in webwork2/clients might be the quickest way to write and test most problems. (The command line client doesn't currently do such a good job if there are static graphics involved.) There is a README in the clients folder. The command line client is fussy but it can be useful.
>I think the two lines are
>
>
>Save to ......
>
>and
>
>Save as ......
>
>(the latter has come to mean that you will create a new file
>rather than over write the old one for most computer users).
Good point. And I guess I don't read very carefully since I missed the prepositional change.
>Two thoughts -- capitalizing the A in "as" might help -- that
>might be enough to emphasize the difference. Very small
>changes in user interface can sometimes have a big effect.
I'd suggest a slightly bigger change: get rid of the "to" in "Save to" and maybe capitalize both letters of "as."
>I don't think that the file should be overwritten even if it is
>local and you have write privileges-- because presumably you
>were making changes to save in a new file but wanted the old
>file preserved. (To overwrite the current file you use the Save
>to... choice.)
Ok - that probably make sense. Especially if we help the sloppy readers like me notice that there really is a difference between those two radio buttons!
>However the error message could easily give directions for
> using the back button on the browser to recover your work.
> With more difficulty the changes could be preserved in the
> textArea box when the error message is presented -- I don't
> know how hard that would be without looking at the code --
> it might be easy also.
I think this would be good. A message like "The text box now contains the source of the original problem. To go back to your edits, use your browser's back button."
>The behavior you describe is "normal" in the sense that it
> works as designed. Editing through a web browser was pretty
>tricky when this module was first designed and written -- with
> AJAX and javaScript now commonplace and stable on browsers
> something much snazzier could be written which would make
> the user interface more intuitive.
Yes, I believe this. And even though I dislike this behavior, I am grateful that we _have_ this editor!
>Finally -- on a slightly different topic: Two things that can
> make editing easier.
>(1) "It's all text" is a firefox plugin that allows you to
> edit textArea blocks in your favorite editor. You do have to
> save twice -- first from the editor to the textArea block then
>from the textArea block to the server.
That sounds exciting!
> (2) if you are writing many problems, not just correcting small
> errors in existing problems, then using your favorite editor on
> your desktop or laptop in conjunction with the command line
>client in webwork2/clients might be the quickest way to write
> and test most problems. (The command line client doesn't
> currently do such a good job if there are static graphics
>involved.) There is a README in the clients folder. The
>command line client is fussy but it can be useful.
I'm assuming these clients can be run from the desktop
and don't need to be run by logging into the webwork server. We've been conservative about giving people accounts on the server - ordinarily instructors should not need that, and if they do have that (and have access to say, their own course's templates directory) then they end up having access to everyone's templates directory.
If that is the case, this might be a nice idea too.
thanks, Hal
ok:
Save: [TMPL]/setDemo/limits.pg and View
Save AS: [TMPL]/setDemo/limits.pg and View
seems good to me. Any further comments?
This message is easy to add:
"The text box now contains the source of the original problem. To go back to your edits, use your browser's back button."
I'm assuming these clients can be run from the desktop
and don't need to be run by logging into the webwork server. We've been conservative about giving people accounts on the server - ordinarily instructors should not need that, and if they do have that (and have access to say, their own course's templates directory) then they end up having access to everyone's templates directory.
The clients run on the desktop and use the WeBWorK server's built in webservice feature to render the problems. So the client machine does need an internet connection and a WeBWorK server it can connect to but it does not need access to the unix server command line.
My view is that with some more user interface work and some slight augmentation on the webservice side these clients could allow someone with the appropriate permissions to edit, modify and sort a library of WeBWorK questions from their preferred platform and editor without direct access to the unix command line. This can be done now if the library being worked on resides on the client computer.
Save: [TMPL]/setDemo/limits.pg and View
Save AS: [TMPL]/setDemo/limits.pg and View
seems good to me. Any further comments?
This message is easy to add:
"The text box now contains the source of the original problem. To go back to your edits, use your browser's back button."
I'm assuming these clients can be run from the desktop
and don't need to be run by logging into the webwork server. We've been conservative about giving people accounts on the server - ordinarily instructors should not need that, and if they do have that (and have access to say, their own course's templates directory) then they end up having access to everyone's templates directory.
The clients run on the desktop and use the WeBWorK server's built in webservice feature to render the problems. So the client machine does need an internet connection and a WeBWorK server it can connect to but it does not need access to the unix server command line.
My view is that with some more user interface work and some slight augmentation on the webservice side these clients could allow someone with the appropriate permissions to edit, modify and sort a library of WeBWorK questions from their preferred platform and editor without direct access to the unix command line. This can be done now if the library being worked on resides on the client computer.
Hi:
Save: [TMPL]/setDemo/limits.pg and View
I agree this is better:
Save AS: [TMPL]/setDemo/limits.pg and View
This is better but we should add that the default name "limits.pg" needs to be edited since you can not save to an existing file. Or better yet, maybe the default name should be "limits_new.pg"
Arnie
Save: [TMPL]/setDemo/limits.pg and View
I agree this is better:
Save AS: [TMPL]/setDemo/limits.pg and View
This is better but we should add that the default name "limits.pg" needs to be edited since you can not save to an existing file. Or better yet, maybe the default name should be "limits_new.pg"
Arnie
I have made most of these changes in revision 6447 of the svn trunk:
Save to is now Save
Save as is now Save AS
There is a helpful message about using the back button on the browser to reclaim lost edits.
I have not changed the default naming scheme because determining the correct behavior is complicated. If the file to be saved is a library problem (the most common situation for me) then one does want the file to be saved with the same name but with local prepended to the path. If local is already prepended to the path a second local is not added. Hence the suggested Save AS path is the same as the current path. Determining the correct logic for the most "intuitive" behavior in renaming a file is a bigger project, which I have postponed.
--Mike
Save to is now Save
Save as is now Save AS
There is a helpful message about using the back button on the browser to reclaim lost edits.
I have not changed the default naming scheme because determining the correct behavior is complicated. If the file to be saved is a library problem (the most common situation for me) then one does want the file to be saved with the same name but with local prepended to the path. If local is already prepended to the path a second local is not added. Hence the suggested Save AS path is the same as the current path. Determining the correct logic for the most "intuitive" behavior in renaming a file is a bigger project, which I have postponed.
--Mike