Re: issue-#63 fixes in StdStamps
Posted: Fri Oct 16, 2015 3:25 pm
I do not like the way this Draft version adds new comments.
Case 1: Open a new Stamp. Add a comment (eg "Potato"). The form displays a meaningless date of 0000. Now list the History.The comment is invisible. Save it to disc. Now list the History. It is visible. Now open the Comment editor. It is hidden; you have to click the Age field to see it. This makes it easy to overwrite it with a new Comment without knowing.
With my version when you first open the editor to add a comment it tells you the date the comment is associated with. Add it, then list the History. You can immediately see it is there; there is no hidden Comment queue. Save to disc. It is still visible in the history. Now open the Comment editor. It is immediately visible, and when you overwrite it you are doing so explicitly in the Editor field, not accidentally.
Case 2: An old Stamp with no comment for today. Add a comment. Close the editor. List the history - the comment is not visible. Open the Editor, The comment is also invisible. There is no way to know it is there, but save to disc and it appears without warning.
With my version it is always immediately visible in both the history, and in the comment editor. This is much more user friendly.
Case 3: An old Stamp with a comment for today. I open the editor, write and apply a new comment.
With the draft version I am unaware I have overwritten an existing comment, with my version this is immediately obvious in the editor.
A bit later I think about saving, and list the history, which I now think is ok (I have forgotten about the new, and hidden comment.) I save. The hidden comment overwrites the existing comment without warning or notification. This issues do not arise with my version.
In summary it is much simpler, for the user, if comments are applied and visible immediately. Deferring applying them, and in the meantime hiding them, is not helpful. (I know that finger prints cannot be pre-viewed, but I don't find that a problem.)
I agree that there is "Surprisingly tricky and buggy stuff in this module", and considering / implementing this behaviour takes a lot of time and effort. But in fact I think there are several places where my code is simpler than the current suggestion (mainly because the first comment is not treated as such a special case) although there are a few cases where it is less so. On balance it is simpler.
Case 1: Open a new Stamp. Add a comment (eg "Potato"). The form displays a meaningless date of 0000. Now list the History.The comment is invisible. Save it to disc. Now list the History. It is visible. Now open the Comment editor. It is hidden; you have to click the Age field to see it. This makes it easy to overwrite it with a new Comment without knowing.
With my version when you first open the editor to add a comment it tells you the date the comment is associated with. Add it, then list the History. You can immediately see it is there; there is no hidden Comment queue. Save to disc. It is still visible in the history. Now open the Comment editor. It is immediately visible, and when you overwrite it you are doing so explicitly in the Editor field, not accidentally.
Case 2: An old Stamp with no comment for today. Add a comment. Close the editor. List the history - the comment is not visible. Open the Editor, The comment is also invisible. There is no way to know it is there, but save to disc and it appears without warning.
With my version it is always immediately visible in both the history, and in the comment editor. This is much more user friendly.
Case 3: An old Stamp with a comment for today. I open the editor, write and apply a new comment.
With the draft version I am unaware I have overwritten an existing comment, with my version this is immediately obvious in the editor.
A bit later I think about saving, and list the history, which I now think is ok (I have forgotten about the new, and hidden comment.) I save. The hidden comment overwrites the existing comment without warning or notification. This issues do not arise with my version.
In summary it is much simpler, for the user, if comments are applied and visible immediately. Deferring applying them, and in the meantime hiding them, is not helpful. (I know that finger prints cannot be pre-viewed, but I don't find that a problem.)
I agree that there is "Surprisingly tricky and buggy stuff in this module", and considering / implementing this behaviour takes a lot of time and effort. But in fact I think there are several places where my code is simpler than the current suggestion (mainly because the first comment is not treated as such a special case) although there are a few cases where it is less so. On balance it is simpler.