You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rory O'Farrell <of...@iol.ie> on 2012/05/18 07:26:33 UTC
[UX] The Save Process
One aspect of the User Experience which frequently manifests itself for Users is a bad file save, leading to a corrupt file, which is partially or totally irrecoverable
--
Rory O'Farrell <of...@iol.ie>
Re: [UX] The Save Process continued
Posted by Rory O'Farrell <of...@iol.ie>.
On Fri, 18 May 2012 16:11:51 +0200
RGB ES <rg...@gmail.com> wrote:
> 2012/5/18 Rory O'Farrell <of...@iol.ie>:
> > On Fri, 18 May 2012 06:26:33 +0100
> > Rory O'Farrell <of...@iol.ie> wrote:
> >
> >> One aspect of the User Experience which frequently manifests itself for Users is a bad file save, leading to a corrupt file, which is partially or totally irrecoverable
> >
> > Sorry! My previous posting got away before I had completed it.
> >
> > In my programming days (some 25-30 years ago) it was de rigeur that the original file was never over-written until the new file had been completely saved, so that if there was a crash (app, OS, or power failure) the original file existed, perhaps as a .bak file, but there, untouched. This does not happen in OpenOffice (all forks as far as I know). Some thought needs to be given to this and to the defaults of the backup ("always create backup" to be on by default).
> >
> > Many of the instances of corrupt files are caused by User error (too quick shutdown before write buffers are flushed?); a part of the User Experience is to ensure against the stupidity of Users.
> >
>
> +1
>
> There is also a second, less harmful, problem with the save file
> work-flow: it is quite easy to accidentally uncheck the "add file
> extension" on the save dialogue so every now and then we get on the
> forums windows users that do not know how to open a file because when
> they double click on it the OS do not recognize it. Maybe we need to
> eliminate that option and always save with the correct file extension?
Yes, Ricardo, I agree. That option should bbe the default and the switch to turn it off should be well hidden (but available to those who really need it). On the Forum we often get Users complaining that the OS cannot identify their file; diagnosis is almost always that the file has no extension (Windows is stupid about identifying file applications if no extension!).
--
Rory O'Farrell <of...@iol.ie>
RE: [UX] The Save Process continued
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I agree with Regina that deciding whether and how to add an extension automatically is a tricky case.
I also suspect that the dialog may be standard bits from the platform, at least in the case of Windows.
- Dennis
PS: For me, the crime was the Windows Shell coming with common extensions not shown by default. This just screws everybody up and it is also a threat opportunity.
-----Original Message-----
From: Regina Henschel [mailto:rb.henschel@t-online.de]
Sent: Friday, May 18, 2012 07:36
To: ooo-dev@incubator.apache.org
Subject: Re: [UX] The Save Process continued
Hi Ricardo,
RGB ES schrieb:
> 2012/5/18 Rory O'Farrell<of...@iol.ie>
[..]
> There is also a second, less harmful, problem with the save file
> work-flow: it is quite easy to accidentally uncheck the "add file
> extension" on the save dialogue so every now and then we get on the
> forums windows users that do not know how to open a file because
> when they double click on it the OS do not recognize it. Maybe we
> need to eliminate that option and always save with the correct file
> extension?
There is no "correct" file extension for all cases. For example consider
text vs csv. But it might help, when the state of the check box is not
remembered, but always starts with being checked.
Kind regards
Regina
>
> Regards Ricardo
>
RE: [UX] The Save Process continued
Posted by Hans Zybura <hz...@zybura.com>.
> From: Regina Henschel [mailto:rb.henschel@t-online.de]
> Sent: Friday, May 18, 2012 5:33 PM
> RGB ES schrieb:
> > 2012/5/18 Regina Henschel<rb...@t-online.de>:
> >> Hi Ricardo,
> >>
> >> RGB ES schrieb:
> >>
> >>> 2012/5/18 Rory O'Farrell<of...@iol.ie>
> >>
> >> [..]
> >>
> >>> There is also a second, less harmful, problem with the save file
> >>> work-flow: it is quite easy to accidentally uncheck the "add file
> >>> extension" on the save dialogue so every now and then we get on the
> >>> forums windows users that do not know how to open a file because
> >>> when they double click on it the OS do not recognize it. Maybe we
> >>> need to eliminate that option and always save with the correct file
> >>> extension?
> >>
> >>
> >> There is no "correct" file extension for all cases. For example
> >> consider text vs csv. But it might help, when the state of the check
> >> box is not remembered, but always starts with being checked.
Currently, this check box is indeed always checked when the "save as" dialog opens, with WinXP and Win7, at least.
That does not alter the fact, that for Windows users this checkbox is 1) totally useless 2) confusing and therefore producing unnecessary support cases.
1) From an UX perspective, a file without file name extension is broken.
2) An option that is not really optional is confusing. Confusion is the most counterproductive UX.
To add some more complexity, there are differences in behavior on WinXP versus Win7.
WinXP: In case of a new document, the default suggestion in the input field for the file name has no extension, i.e. it reads "Untitled 1". If you uncheck automatic extensions and then forget to manually add the correct extension, your file is saved without extension, which essentially means broken.
Win7: The default suggestion in the input field has the default extension for this file type added, i.e. it reads "Untitled 1.odt" with a new writer document. When the user unchecks automatic extensions before or after changing the name, the default extension is still there. Most users will only change the file name part and not delete the extension, I think. So the risk of getting a broken file is somewhat reduced on Win7.
By far most of OpenOffice users work with Windows. I really can't see a reason to stick with a counterproductive automatic extensions check box.
> >>
> >
> > You have a point here... ;)
> >
> > But this makes me think on the difference between "Save As" and
> > "Export": if you create a cvs file from a spreadsheet document I think
> > you are "exporting" it, not just "saving us" because you are losing
> > format and properties like formulas, etc.
> >
> > I think that those specially ambiguous file types belongs to "Export"
> > (which is now pretty empty), not to "Save / Save As". By reorganizing
> > "Export" and "Save / Save As" it is possible to let the file extension
> > option on the Export dialogue and erase it from "Save / Save As". Does
> > this make sense?
>
> Currently a filetype goes to "Save/ Save As", when an export _and_ an
> import filter exists. It does not distinguish whether something is lost.
> If you do not save to 'ODF1.2 extended' always something is lost.
>
> I remember there had been a similar discussion on OOo, and especially
> saving to .doc had been controversial. And also the discussion about this
> check box is not new and as far as I remember the removal of that check box
> has been rejected. But I would need to search for those discussions.
>
> Kind regards
> Regina
Kind regards, Hans
Re: [UX] The Save Process continued
Posted by Regina Henschel <rb...@t-online.de>.
RGB ES schrieb:
> 2012/5/18 Regina Henschel<rb...@t-online.de>:
>> Hi Ricardo,
>>
>> RGB ES schrieb:
>>
>>> 2012/5/18 Rory O'Farrell<of...@iol.ie>
>>
>> [..]
>>
>>> There is also a second, less harmful, problem with the save file
>>> work-flow: it is quite easy to accidentally uncheck the "add file
>>> extension" on the save dialogue so every now and then we get on the
>>> forums windows users that do not know how to open a file because
>>> when they double click on it the OS do not recognize it. Maybe we
>>> need to eliminate that option and always save with the correct file
>>> extension?
>>
>>
>> There is no "correct" file extension for all cases. For example consider
>> text vs csv. But it might help, when the state of the check box is not
>> remembered, but always starts with being checked.
>>
>
> You have a point here... ;)
>
> But this makes me think on the difference between "Save As" and
> "Export": if you create a cvs file from a spreadsheet document I think
> you are "exporting" it, not just "saving us" because you are losing
> format and properties like formulas, etc.
>
> I think that those specially ambiguous file types belongs to "Export"
> (which is now pretty empty), not to "Save / Save As". By reorganizing
> "Export" and "Save / Save As" it is possible to let the file extension
> option on the Export dialogue and erase it from "Save / Save As". Does
> this make sense?
Currently a filetype goes to "Save/ Save As", when an export _and_ an
import filter exists. It does not distinguish whether something is lost.
If you do not save to 'ODF1.2 extended' always something is lost.
I remember there had been a similar discussion on OOo, and especially
saving to .doc had been controversial. And also the discussion about
this check box is not new and as far as I remember the removal of that
check box has been rejected. But I would need to search for those
discussions.
Kind regards
Regina
Re: [UX] The Save Process continued
Posted by RGB ES <rg...@gmail.com>.
2012/5/18 Regina Henschel <rb...@t-online.de>:
> Hi Ricardo,
>
> RGB ES schrieb:
>
>> 2012/5/18 Rory O'Farrell<of...@iol.ie>
>
> [..]
>
>> There is also a second, less harmful, problem with the save file
>> work-flow: it is quite easy to accidentally uncheck the "add file
>> extension" on the save dialogue so every now and then we get on the
>> forums windows users that do not know how to open a file because
>> when they double click on it the OS do not recognize it. Maybe we
>> need to eliminate that option and always save with the correct file
>> extension?
>
>
> There is no "correct" file extension for all cases. For example consider
> text vs csv. But it might help, when the state of the check box is not
> remembered, but always starts with being checked.
>
You have a point here... ;)
But this makes me think on the difference between "Save As" and
"Export": if you create a cvs file from a spreadsheet document I think
you are "exporting" it, not just "saving us" because you are losing
format and properties like formulas, etc.
I think that those specially ambiguous file types belongs to "Export"
(which is now pretty empty), not to "Save / Save As". By reorganizing
"Export" and "Save / Save As" it is possible to let the file extension
option on the Export dialogue and erase it from "Save / Save As". Does
this make sense?
Regards
Ricardo
Re: [UX] The Save Process continued
Posted by Regina Henschel <rb...@t-online.de>.
Hi Ricardo,
RGB ES schrieb:
> 2012/5/18 Rory O'Farrell<of...@iol.ie>
[..]
> There is also a second, less harmful, problem with the save file
> work-flow: it is quite easy to accidentally uncheck the "add file
> extension" on the save dialogue so every now and then we get on the
> forums windows users that do not know how to open a file because
> when they double click on it the OS do not recognize it. Maybe we
> need to eliminate that option and always save with the correct file
> extension?
There is no "correct" file extension for all cases. For example consider
text vs csv. But it might help, when the state of the check box is not
remembered, but always starts with being checked.
Kind regards
Regina
>
> Regards Ricardo
>
Re: [UX] The Save Process continued
Posted by RGB ES <rg...@gmail.com>.
2012/5/18 Rory O'Farrell <of...@iol.ie>:
> On Fri, 18 May 2012 06:26:33 +0100
> Rory O'Farrell <of...@iol.ie> wrote:
>
>> One aspect of the User Experience which frequently manifests itself for Users is a bad file save, leading to a corrupt file, which is partially or totally irrecoverable
>
> Sorry! My previous posting got away before I had completed it.
>
> In my programming days (some 25-30 years ago) it was de rigeur that the original file was never over-written until the new file had been completely saved, so that if there was a crash (app, OS, or power failure) the original file existed, perhaps as a .bak file, but there, untouched. This does not happen in OpenOffice (all forks as far as I know). Some thought needs to be given to this and to the defaults of the backup ("always create backup" to be on by default).
>
> Many of the instances of corrupt files are caused by User error (too quick shutdown before write buffers are flushed?); a part of the User Experience is to ensure against the stupidity of Users.
>
+1
There is also a second, less harmful, problem with the save file
work-flow: it is quite easy to accidentally uncheck the "add file
extension" on the save dialogue so every now and then we get on the
forums windows users that do not know how to open a file because when
they double click on it the OS do not recognize it. Maybe we need to
eliminate that option and always save with the correct file extension?
Regards
Ricardo
Re: [UX] The Save Process continued
Posted by Rory O'Farrell <of...@iol.ie>.
On Fri, 18 May 2012 06:26:33 +0100
Rory O'Farrell <of...@iol.ie> wrote:
> One aspect of the User Experience which frequently manifests itself for Users is a bad file save, leading to a corrupt file, which is partially or totally irrecoverable
Sorry! My previous posting got away before I had completed it.
In my programming days (some 25-30 years ago) it was de rigeur that the original file was never over-written until the new file had been completely saved, so that if there was a crash (app, OS, or power failure) the original file existed, perhaps as a .bak file, but there, untouched. This does not happen in OpenOffice (all forks as far as I know). Some thought needs to be given to this and to the defaults of the backup ("always create backup" to be on by default).
Many of the instances of corrupt files are caused by User error (too quick shutdown before write buffers are flushed?); a part of the User Experience is to ensure against the stupidity of Users.
--
Rory O'Farrell <of...@iol.ie>