I'm also an experienced Windows User. Since I figured out why the icon
was greyed out I think it is a very good feature. Why save when
nothing has changed. That was something that always annoyed me in
MS-Office (I'm still using Office97 and I don't know if this was
changed in later versions), I never knew if the document had to be
saved or not.

Yeah, I knew what it was instantly but it was my mum (and a few
others) who had the problem. She panicked a bit and thought the
program had crashed. After I reassured her she seemed happy enough but
said that it was unintuitive so I said I'd levberage the power of open
source and issuezilla it!

I personally think the behaviour is correct (as you say) but the
feedback mechanism is wrong. We shouldn't grey out the image but
instead allow it to be pressed and flash up a message in the status
bar saying: "This file is already saved." or something similar.

Hmh, I understand your point. Let's see what others will say to this
issue.

Joost->Christan: reassigned as usability issue to you. Perhaps
Matthias could have a look at this one

Any ideas in the last month? Just wondering what the 'usability'
standpoint was.

Reassiged to Bettina.

If one types even just one letter the icon becomes visible, so I can't see it as
a big problem. The one that doesn't type even one letter may have a problem, but
then there is a question why he installed OOo at all?

Anyway, I would like to propose this: Change the tooltip over grayed-out icon to
something more informative like "can't save document with no changes".

I really think that this is great feature and should not be disabled, maybe just
upgraded this or some other way.

changing the bug data as this is not just for Writer but for all components.

I also argue that disabling the Save operation when the document is not modified
is a usability defect.

There are many good reasons for never disabling the Save action even when the
document is not "modified".  For instance, view data may have changed, which
does not necessarily trigger a modified state but the view data get saved with
the document.  Here, the term "view data" includes such things as the cursor
location, zoom level, current active sheet (in Calc), etc.

When looking at applications on Windows, in almost all Microsoft applications
including Word, Excel, PowerPoint, Visual Studio, the Save operation is always
enabled.  Non-Microsoft applications that I know of (such as AutoCAD) also
follows this behavior.  A colleague of mine checked a few Mac applications and
the trend was the same.  So, even from the competitive analysis point of view,
it makes sense to always enable Save.

Created attachment 51506 [details]
proposed patch to always enable Save

Changing the issue type to PATCH.

The attached patch always enables Save even when the document is not modified. 
But internally, the modified state is still tracked in order to prompt the user
to save on closing when the document is still modified at time of closing.

Carsten,

I know this is mostly a policy issue and is technically not very difficult to
go, but it would be great to get your input on this.

Thanks.

s/go/do/g

cd->kohei: I think that always enabling the "Save" function is the better way to
go. But that's my opinion. I want to get "User Experience" involved and decide
it based on user input.

cd->cj,fl,bh: We now have a patch for this issue, please try decide as soon as
possible if this problem is a usability issue and should be solved. From my
point of view we should accept the patch.

cd->mav: Please check the patch as it make changes in your code area. From my
point of view the patch is ok.

I'm not sure if this is a good idea. A lot of people take the state of the
"Save" button as an indication whether the doc is modified.

Please always enable the save icon. This makes sense.

Changed the owner to handle this patch.

Christian, did you do a competitive analysis? 

It sounds strange to me to have a function enabled that actually doesn't do
anything. In my small developer's world I always considered it to be good style
to disable stuff that can't (or shouldn't) be executed.

If you maintain your point that the "Save" button should be enabled though
saving isn't necessary my question would be: why stop at "Save" and keep other
functions disabled? Why not also enable e.g. "Undo", "Paste" etc.?

> Christian, did you do a competitive analysis?

Yes. MSO 2007, Wordpefect 13, even jEdit or Paint.net behaves in the proposed way.

[...]

> If you maintain your point that the "Save" button should be enabled though
> saving isn't necessary my question would be: why stop at "Save" and keep other
> functions disabled? Why not also enable e.g. "Undo", "Paste" etc.?

If there is nothing to undo it makes no sense to have this option enabled, same
for past. In case of save the situation is a little bit different. Users should
have the control over the app not the other way around. If one wants to assure
that the document is saved one should get the chance to repeat the saving
process with out modifying the document.

@mba: The reason Save should be enabled is because the view data (such as the
cursor position, zoom level, current sheet in Calc etc) does not trigger a
document modified state, but the users often times want to save it with the
document.  For instance, in an unmodified Calc document, if you want to switch
to the next sheet, and set the cursor to C10 and start from there the next time,
currently you have to "delete" an empty cell to enable Save, then you can save
the current sheet and cursor position. 

So, to solve that we have two choices.  Either set the document dirty every time
a view data changes, or always enable Save.  In terms of necessary code changes,
the latter is much much easier.

As for tracking document's modified state, there is a prominent place in the
status bar already for that purpose.  So, not all is lost by always enabling Save.

I don't "buy" the argument that the user wants to save "just because". But yes,
the use cases presented by Kohei make sense, especially in case of Calc.

Setting target 3.0.

I had to change the patch a bit (there are still situations where SID_SAVEDOC
must be disabled). Fixed in cws mba30patches01.

.

Please verify

Verified in CWS mba30patches01.

Can "always enabled" save button be optional?
State of "Save" button was a great *feature* of OOo, provides easy visual
indicator of document modification flag. And now it is lost.
There are lot of negative feedback about this change.

I don't like this change also but it seems that there was some common sense to
apply it.

I don't think that we should make it an option. Either - or.

I still would opt for the previous behavior. The use case in Calc could be
handled differently: enable the save button also if View Settings have changed
but don't change the "modified" state so that you still can close the document
without being asked. Or - in case you want the warning - set the modified flag
even in case "only" a view setting is changed.

fl,cj,kohei: any comments?

Setting a modified flag, or any flag for view data change would require a
massive set of code change, and I don't think it's worth the risk.  And like I
said there already is a document modified status indicator in the status bar, so
I would still opt for always enabling save.  That behavior also happens to be
how many other applications behave.  The users reaction is understandable (for
any behavioral changes), but I don't think it's the save icon's job to tell them
whether the document is modified or not.

Maybe we should make the modified status indicator in the status bar stand out
more, but I don't think it's a good idea to revert this change.

Also, if this helps...

I was also like mba and pmike and used the Save icon to check for the modified
status, because it was convenient and visible.  And, while it took me some time
to get used to looking at the indicator in the status bar instead of the Save
icon, once I got used to it, it felt just fine.  And I like the fact that I can
always save the document.  So, for me, overall it's a win.

But I also feel we can do better by making the modified status indicator more
visible, instead of just setting '*' when the document is modified.  Maybe
putting some sort of small icon when the document is modified might increase its
visibility.  Just an idea for future enhancement.

This misses the point.
Users of OOo and all users of SO since more than ten years are trained to look
at the status of the "save" icon to see whether the document is modified or not.
I never met anybody who instead looked at the barely visible little star in the
status bar.

People also will be confused that the save button is enabled but when they close
the document no warning will happen (as this is what they are used to).

I'm not the one that says "never change anything" (on the contrary!), but OTOH
for a very visible change I would like to see a justification. And after some
thinking I have my doubts that the ones presented so far are good enough.

I don't believe that the necessary changes in Calc are that big. At least I
don't buy that without a proof. ;-)

I think I've given enough justification, from competitive analysis point of view
and logistical point of view.  I think it all comes down to personal preference
at this point.

mba, you obviously like the gray save icon behavior, so it pmike.  But there is
also silent many users who dislike this behavior.  And this is not just for
Calc's issue it applies equally to the other applications as well.

You mentioned the past OOo and SO users.  There is also a giant pool of migrant
users from the other office suits who find this confusing.  So, while the need
to satisfy the existing users is granted, please don't see that as the only
group of people whom we need to satisfy.

So, at this point I would opt for providing an option for this.  But reverting
to the old behavior just because of the existing users is to me missing the big
picture.

Well, it's hard to argue against "many silent users that dislike the current
behavior". Because they are silent. :-)
I don't think that this would lead to anything.

My personal preference is not very interesting.
I'm pretty sure that this *will* create problems for others but I don't have a
proof for that and as I don't want to use the "argument" of silent users I will
stop argueing against that.

So be it. 

Of course for 3.0 only in case the QA will accept this UI change after code
freeze for 3.0 Beta (as the CWS containing this code change was rejected today
because of a regression caused by one of the other patches integrated into it).
IMHO that shouldn't be a problem - but you never know ...

Oh, and I don't want to have an option for this, we already have enough of them.
If this is the right thing to do it because that's what Excel does, why should
we have an option to switch it off? :-)

Well, then maybe this proposal will be best solution: add *two* save buttons on
toolbar, one "saves always", other "saves if modified". Make second button
hidden by default. Then old-style users can easily customize toolbar for themselves.

@mba:

>If this is the right thing to do it because that's what Excel does, why should
we have an option to switch it off? :-)

I'll be okay with just having one behavior as long as you are fine with it.  I
mentioned making it optional in case some existing users miss the old behavior,
but having just one behavior would be fine with me. :-)

I'm one of the old users and I'm watching this topic for years (as you can see
in my comment on the very top of this list). My opinion has not changed. For me
the greyed out icon is a very good feature. And I'll bet that it will drive me
nuts in case this behavior is gone, because I will always think the document is
not saved, although it is. Only my two cents.

I think we have to test the new behavior in OOo 3.0 beta to get more than a gut
feeling. 

Furthermore I think it is a good idea from pmike to add a second
(optional/pre-configured) save button following the old known behavior.
Improving the document modified indicator is another good idea. I think this
indicator should show document modified status and current idle activities like
spelling and formatting. Updating a document (linked sections and indexes) could
also use this as an endless progress indicator.

This enhancement will not be part of the Beta as the CWS missed the code freeze
date.

A second button wouldn't be a good idea - we already have too much buttons and
this new one would do the same on click as the other one, except that it is
always enabled and the other one isn't. 

I don't want to invest more work here - neither in discussing nor in coding. I
think it's wrong to have this button enabled always but I can live with being
overruled. There's much bigger fish to catch.

This change has occured in the 2.4 release in Ubuntu and generated:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/208786

I don't think that just copying what other software does is a relevent reason
other software can be wrong. But I can see peoples point about view information etc.
Instead of greying out why not just change the colour of the icon?
When the document has not been saved the normal blue icon with a tooltip of
'Save Ctrl+S' (I like keyboard shortcuts in tooltips)
When there have been no modifications a green (or some other colour) icon with a
tooltip of 'Document has not been modified since last save Ctrl+S'

This way we have the benefit of showing the user whether the document has been
saved really obviously (saving takes a long time for large documents, I don't
want to have to do it more often than necessary) and at the same time people
won't get confused and think something is broken.

This way I hope everybody would be happy. :-)

Thank You

Well, this would at least prevent that users will think that we are complete
idiots because we can't manage something simple as the status of a "Save" button.

OTOH I still don't get why an unmodified document needed to be saved at all, so
it doesn't matter a lot whether the button is green or blue. This will need some
more work on the code that I'm not willing to invest.

Perhaps we could add a tool tip that says 

"You already saved your document, there's no reason to do it again. But in case
you want to do it anyway, just do it!". 

This will leave no uncertainties. :-)

Having just a tooltip would help - but it takes much longer (at least 3 seconds
:-) to move the mouse over the save button and wait for the tooltip to appear
than to look at the colour of the save button.

Of course I didn't want my comment to be taken seriously (thus the Smiley). ;-)
You can't save a wrong feature by adding complexity to it. Let's do the change
as wanted and keep it simple. Better wrong and simple than wrong and complex.

The patch introduces problem - http://www.openoffice.org/issues/show_bug.cgi?
id=88083.

No, the patch does not change the status of the "modified" flag, it just ignores
it for the status of the "save" button.

I don't know it the patch is the culprit, but with OOo 2.4.0 the "modified" flag is 
changed when loading excel or ppt file.

See Issue 87555 which has already received several votes.

Sure, there obviously seems to be a bug in 2.4 with that file. But this is not
related to *this* issue.

BTW: do you see the problem with the Sun built OOo 2.4.? This version does not
contain the patch for the "Save" button anyway. Rumours are that the Novell
version contains it (and so some others). And if they have bad luck they might
even contain the buggy patch that is attched here and not the corrected one. But
this is just guessing.

@mba

>if they have bad luck they might even contain the buggy patch that is attched
here and not the corrected one

Hmm..  I don't see the corrected patch attached here.  When can I get the
corrected one?

Also, could you give us the detail of that problem you mentioned?

> I was also like mba and pmike and used the Save icon to check for the modified
status, because it was convenient and visible.  And, while it took me some time
to get used to looking at the indicator in the status bar instead of the Save
icon, once I got used to it, it felt just fine.  And I like the fact that I can
always save the document.  So, for me, overall it's a win.

> But I also feel we can do better by making the modified status indicator more
visible, instead of just setting '*' when the document is modified.  Maybe
putting some sort of small icon when the document is modified might increase its
visibility. 

Well, OOo can place this 'star' directly on a save icon. If the document is not
changed - show 'disquette' icon. If it is - whos 'disquette and a star' icon. It
is visible enough, I can assure you.

The corrected fix is available from cvs (revision 1.102.24.1 of objserv.cxx).

The bug was that the patch allows to save read-only documents what usually will
create an error message or at least will do nothing (didn't test it). Both are a
bad user experience IMHO.

The code in objserv.cxx should be

case SID_SAVEDOC:
{
    BOOL bMediumRO = IsReadOnlyMedium();
    if ( !bMediumRO && GetMedium() )
        rSet.Put(SfxStringItem( nWhich, String(SfxResId(STR_SAVEDOC))));
    else
        rSet.DisableItem(nWhich);
}
break;

The code checks for readonly files. The attached patch does nothing in that case
and giving no state still does not disable anything, the slot stays enabled.

BTW: the GetMedium() condition is only of theoretical interest, it shouldn't
happen ever, but in case it happens the "Save" command execution surely will
lead to a crash. So I think disabling is also appropriate in that case.

mba said: "do you see the problem with the Sun built OOo 2.4.? This version does not
contain the patch for the "Save" button anyway."
- I confirm, save button is still greyed in my 2.4.0 when nothing to save :-)

My opinion on this feature:

- I discovered this Issue jumping from another recent Issue which related to it. Very 
few people are aware of this discussion. An Issue is not a good place to query for 
opinions.
Questions like this one should be explained with enough publicity in forums ( a 
mailing list is also too confidential) to get back votes and suggestions from real 
users of different countries, not developers and geeks. 

- on the feature itself: it will make some people happy (MS-Office addicts) and a lot 
of people unhappy. Long time users of OpenOffice will be disturbed, and there will be 
lots of Issues. This is exactly like the change of behaviour for hyperlinks : lots of 
recrimination, nobody satisfied. If you introduce this feature, add another checkbox 
in Tools > Options to defeat it.

- personnaly I prefer to stay with the greyed icon. Even if the * in the status bar 
is replaced by a "Modified". Because I look more at the top of the window than at its 
bottom.

+1 for leaving the behaviour as it is.  I have had numerous comments from
converts to OOo saying this is a feature that they *prefer* in OOo.

If it must be changed, then a second icon that can be added to the toolbar is a
good alternative to keep one of the two camps happy.  I would see this as
similar to the two print icons (one is Print > opens print dialogue, the other
is Print directly).

Shame we can put a minus vote on an issue ;)

Oops, should read "Shame we can't put a minus vote on an issue ;)"

My personal preference is to keep the old behaviour. If the document has been
modified (and I don't count cursor position as modified), then I should be able
to save it, and should be bugged to save it when I try to close it. 

If there's no change, saving is pointless, and should be disabled. I shouldn't
be bugged to save when I close, etc. 

If anything needs to be done, I suggest that instead of enabling the button, the
button is left disabled, but either the image is changed to indicate that the
doc is already saved or the tooltip is modified to indicate why the save button
has been disabled (similar to the way the undo/redo buttons and menu items work).

added myself to cc

I've been missing the discussion on discuss@ux.openoffice.org...

I've read all the comments.

- Indeed, I sometime miss what Kohei writes: save a changed view in a spreadsheet.
- However, since the only thing needed to do to be able to save, is hit
backspace, I can't find thàt trouble is important enough to change a long time
known, by many appreciated and distinguish behaviour of OOo.
You may expect that users wanting to save the spreadsheets with a different
view, will be users smart enough to do this.

(About competitive analyses: being slightly different as the competition, giving
people some things to learn and then a chance to appreciate their new knowledge
of smart features in the new office suite, also is marketing.)

so a clear -1 for me

A clear -1 for me, too!

I especially like the greyed out Save button. A lot of other programs do the
same, like my favourite editor Notepad++.

A permanently active Save button will force me to save the document again and
again, because I will never be sure if it is saved or not.

OTOH, the user should never worry about saving the document and concentrate on
his work. OOo should allow this. In an ideal world, you wouldn't bother with
save at all.

There is a sign that indicates the status of modification. 
It is located in the center of the status bar at the bottom of window.

When a user modifies a document, an asterisk mark appears. 
When a user makes undo or saves the document, the asterisk mark disappears.

This is the feature implemented before StarOffice 5.2 and even works today. 

How about use of the feature or similar one? 
Duplicating and locating it next to the Save icon button, etc... 

Marking anything else than the "Save"-icon is a great waste of everything.

1.) Instead of looking at the "Save"-icon, the user has to look now at two
distinct locations
 - it can't be worst than the status bar:
   the user checks the status bar, then has to travel
   *one full screen height* to click the "Save"-icon
 - even a mark in the window title is suboptimal,
   because the user has still to look somewhere else,
   find this location and interpret it (e.g. the asterisk)

2.) user needs to interpret yet a new bit of information
 - "grayed"-out icon is simply impossible to click
 - but some other mark (e.g. asterisk) is a new information
   and user needs to be aware of it and always interpret it
  [especially in a complex environment this is not trivial]

So, instead of paying attention to his work, the user will bother to click the
"Save"-button over and over again. [No, most users won't bother IF the document
is changed; it is too complex to figure it out in a short time span.]

I won't be original:

A clear -1 for me, too!


cornouws@ wrote:
> (About competitive analyses: being slightly different as the competition, giving
> people some things to learn and then a chance to appreciate their new knowledge
> of smart features in the new office suite, also is marketing.)

I do completely agree! Please do not do something just because MS Office does it! 
On the other hand, the "View changed" feature, is an argument to open a new
issue, not to change the behavior of the Save button.

I think the option by default of OOo is greater of that of MsOffice, I like the
"Save" button dissabled when I have nothing to save, and have it enabled when
some changes has been made in the document.

If we copy everything from Ms, we will finish having something like "Start" to
close our OpenOffice.org.

Please, don't to that.

Francisco Alcaraz
Murcia (Spain)

I would like to propose leaving Save icon's behavior unchanged for now since 
we would need more studies on various user scenarios including Kohei's one.

For instance, current behavior around Save function is too simple and is not 
capable of avoiding overwriting a document file. 

 Scenario A
  1. User A ) Opens a document file X on the file server.
  2. User  B) Opens the same document file X on the file server.
  3. User A ) Starts to modify it.
  4. User  B) Starts to modify it.
  5. User A ) Saves it.
  6. User  B) Saves it. 

What will happen? The efforts done by the user A will be completely lost by 
user B's overwriting the file. No warning will be reported. How can we avoid 
such a situation? File lock? Maybe no. File lock sometimes causes more 
complicated problems. If an application software on a laptop PC locks a file 
on the file server and then the PC's Ethernet cable is unplugged, how can we 
unlock the file?

The editor Emacs gives us a good solution. It seems to use a time stamp of file 
or something else to find if a file has been changed. 
On the above user scenario Emacs will warn at step 6 prompting 
"X has changed since visited or saved.  Save anyway? (yes or no)"

 Scenario B
  7. User A ) Opens a document file X on the file server.
  8. User  B) Opens the same document file X on the file server.
  9. User A ) Starts to modify it.
 10. User A ) Saves it.
 11. User  B) Starts to modify it.
 12. User  B) Saves it. 

Emacs will warn at step 11 prompting 
"X changed on disk; really edit the buffer? (y, n, r or C-h)"

So user B will be warned and given a chance to choose what to do. Where 'r' 
denotes 'revert' - the contents of the buffer are refreshed from the file on 
disk. 'C-h' means pressing a key 'h' with holding a Ctrl key and shows a help 
message. 

If user B answers the prompt with 'y' and moves on to the step 12, the user will 
be prompted with the same warning message as the step 6.

So what i want to say here is that if we try to change behavior of the Save icon 
button, its specifications could be somewhat more sophisticated to cover various 
user scenarios, especially for enterprise use. 

Please, please do not jump to quick conclusions.

The issue that triggered request for change was this:
I tested some other issue with simple Calc table. 
I changed the cell, but I did not exited the cell, rushing to see what will 
happen on Save, I just went to File > Save and Save was grayed out.

For me file was changed and I wanted to save it, but due to way Calc is 
working change was not registered and Save button was grayed out. My reaction 
was quite average, to use 'Save as' button that was still marked as active and 
in popup window all I had to do was to click OK and file was saved including 
the change I made. Does anyone think that this way around is necessary and 
shows superiority of OpenOffice? 

BTW, argument that grayed out Save is good as indicator that file is not 
changed in this case fails. File was changed, but Save button was grayed out. 
How intuitive is this? 

Afterwards, trying to guess what went wrong, I opened file again, changed 
another cell, but this time moved cursor out of changed cell, and Save was 
available. 

How many users, used to another programs, would consider this as normal? 
Until they get that they have to place cursor to another cell in order 
to "ungray" Save, Calc behavior will appear as erratic. Sometimes Save works, 
sometimes not. 
How many of users would go extra step to check what happened? 
Majority will come to conclusion that you get what you pay for, and forget 
OOo. In case of OOo that will not change balance sheet, but StarOffice bottom 
line will suffer. 

For me, until someone finds time to change Calc behavior, having Save always 
on is good workaround. 

Current behavior of OpenOffice.org 2.4

Scenario I
 Steps                                  Save icon button 
 ====================================== ================
 1. File - New - Spreadsheet                    Disabled 
 2. Type something in the cell A1               Disabled <- Unexpected (*1)
 3. File - Save As  (File selection dialog appears) Enabled 
 4. Name it and press the [Save] button         Disabled 

Scenario II
 Steps                                  Save icon button 
 ====================================== ================
 1. File - New - Spreadsheet                    Disabled 
 2. Type something in the cell A1               Disabled <- Unexpected (*1)
 3. Press an Enter key                          Enabled
 4. Edit - Undo                                 Enabled  <- Unexpected (*2)

rajko_m points out *1 and I would like to add *2.
Those behaviors, however, seem as design of Calc... 

In comparison with *2, Writer behaves in the following way:

Scenario III
 Steps                                  Save icon button 
 ====================================== ================
 1. File - New - Text Document                  Disabled 
 2. Type something                              Enabled
 3. Edit - Undo                                 Disabled <- As expected

In the use case described by rakko_m and tora, the behaviour of OpenOffice is 
perfectly correct.

In Calc, while you are editing a cell, nothing is changed. The change only occurs 
when the edition is validated (typing Enter or click the green check icon).
Proof:
In a new Calc document, in cell A1 put the formula =C1 (and type Enter)
Cell A1 displays 0
Now edit cell C1, and type 123  : cell A1 still displays 0.
Type Enter : now cell A1 displays 123.
A formula or a value is only evaluated when edition is validated. There is no 
modification in a cell being edited, this is not a stable state. You may still click 
the red Cancel icon or type Escape key.

There is an equivalent case in Writer:
Menu Format > Character
Change the font : nothing happens until you click OK.

> Scenario I
>  Steps                                  Save icon button 
> ====================================== ================
> 1. File - New - Spreadsheet                    Disabled 
> 2. Type something in the cell A1               Disabled <- Unexpected (*1)

The Calc document stays "unmodified" until the cell edit mode is left. This
would be a situation where the changed behavior of the "Save" button would be an
improvement. 

> Scenario II
> Steps                                  Save icon button 
> ====================================== ================
> 1. File - New - Spreadsheet                    Disabled 
> 2. Type something in the cell A1               Disabled <- Unexpected (*1)
> 3. Press an Enter key                          Enabled
> 4. Edit - Undo                                 Enabled  <- Unexpected (*2)

This is an ancient bug in Calc. Only Writer is able to handle that correctly -
for whatever reason. Enabling the button always to "mask" this bug would be
lame. ;-)

> Scenario A
>  1. User A ) Opens a document file X on the file server.
>  2. User  B) Opens the same document file X on the file server.
>  3. User A ) Starts to modify it.
>  4. User  B) Starts to modify it.
>  5. User A ) Saves it.
>  6. User  B) Saves it.

This doesn't happen as indeed OOo uses file locking. But because locking has
some problems on heterogeneous networks we are currently implementing a new
mechanism to handle that. But this is not related to this issue, please let's
leave that out here, the story gets more and more complicated.

rajko_m:

> BTW, argument that grayed out Save is good as indicator that file is not 
> changed in this case fails. File was changed, but Save button was grayed out. 
> How intuitive is this? 

It isn't. But this is a particular Calc problem, not a problem of the treatment
of the "Save" button in general. Taking this as motivation to always enable this
button IMHO would be a lame excuse.

After rethinking all the pros and cons I have to admit that my initial comment
(------- Additional comments from cj Fri Feb 15 09:01:49 +0000 2008 -------) was
probably wrong. Maybe it really the better solution to offer set of more fine
granulated modified flags for view data changes, etc. Never the less it would be
interesting to hear why  MSO 2007, Wordpefect 13, Photoshop, or Paint.net offer
a permanently enabled save button/feature.

>it would be interesting to hear why  MSO 2007, Wordpefect 13, Photoshop, or
Paint.net offer a permanently enabled save button/feature.

Add AutoCAD to that list as well.  Almost all major applications do this, not
just MS Office.  Those apps that disable the Save icon tends to be simpler
applications, and even so, the apps that I consider to be simple always enable
save, such as 'gedit'.  One good reason for this is that it makes it simpler for
all of us, the users and the developers.  When you hit save, that's when the
document gets saved, period.

Consider the current OOo situation.  We need to decide what change sets the
document modified, and what change doesn't.  It may be a simple decision but
it's not always so simple.  For example, rajko_m already pointed out that, when
you type something into a cell in Calc, he considers it modified, but Calc
doesn't consider that modified until you hit enter to commit the change.  How
about a cursor movement, zoom level change, switching the current page in Draw,
switching the current sheet in Calc etc.?  And even if you think the current
situation is manageable, as the application grows larger and more complex,
making such decision is not always an easy one.  I could almost see us arguing
back and forth on this every time a new feature/enhancement is made, whether or
not that should set a document modified flag.  And such decision becomes
sometimes highly subjective, and non-obvious.

What I see in this discussion is that the users need a way to see whether the
document is "modified" or not.  Keep in mind that even now, when OOo says the
document is not modified, some values may have bee modified that need to be
saved, and you just don't know about it.  And working around this by "deleting"
an empty cell etc. is to me simply lame.

And this is not just an issue with disabled icon; when the icon is disabled, the
save action itself is disabled.  To me disabling the save icon just to show
whether the document is modified or not (even though that information may not be
accurate) is a lame excuse to disabling the save action itself.

Well, I claim that all those applications that permanently enable the save
button simply had too lazy developers (or too un-visionary UI designers) to
implement/invent the "disable the icon when there is nothing to save"-feature.
Of course, this claim is as unproven as a lot of other things here :)

Point is, I think this is highly a matter of taste, I don't see any *really*
convincing argument (and things like "all others do it, they must know why" or
"this is lame" aren't convincing arguments, really) for either of both behaviours.

I don't have an immediate solution to this dilemma, but I think it needs further
discussions. We should ask a wider audience, since obviously the change is
highly controversial. For the moment, I suggest we revert the fix in the CWS,
until we came to a final decision.

>I claim that all those applications that permanently enable the save
button simply had too lazy developers (or too un-visionary UI designers)

Or they are just trying to keep it simple.  Raising the complexity unnecessarily
just to prove you're not lazy is not a very convincing argument.

Hmmm ... I forgot the smiley, it seems. The real thing I wanted to express is
some lines below the one you cited.

I think Kohei and Frank have made some wise statements. So for our issue the
problem is that we must find out which of them applies:

is not trying to enable saving only when necessary "lazy" or is it "avoiding
complexity"?

I tend to say that disabling buttons if their functionality is not available or
if it doesn't make sense to use them is a good design and it is not too complex
for users to understand.

If we never disabled the "Save" button - why should we disable any button? We
could always enable the "paste" button even if the clipboard is empty. Or the
"undo" button, or ...

All these changes would be simplifications. Or lazyness?! You see, both
statement can be applied - but it depends on the particular case which fits better.

Since I didn't mention this explicitly above: Yes, I like the behaviour as it is
before the patch. Here is why: I am paranoid. I save often, very often. In fact,
when writing texts or spreadsheets, Ctrl+S is probably my most often used
keyboard shortcut. Maybe because I had OOo to crash and lose my changes too
often in the past years :)

So, for me, the *unpatched* behaviour is a useful feature, not a bug. Let's say
I'm an advanced user who can handled the "additional complexity" of this feature.

Then we're down to: Which user group to we want to satisfy? Either way, we will
lose (the sympathy of) parts of our users. What's the bigger loss?

Given the positions exchanged in this issue and in discuss@ux, I tend to think
that there are less friends of the new/patched behaviour than of the old one.

@mba:

>If we never disabled the "Save" button - why should we disable any button? We
could always enable the "paste" button even if the clipboard is empty. Or the
"undo" button, or ...

It all comes down to how simple or complex the criteria is to disable an icon. 
It's relatively simple to determine whether the clipboard is empty for the paste
icon, or where the current position is in the undo stack for the undo/redo
icons.  For the save icon, the criteria is "whether or not the document has been
modified".  It's such a simple question but hard to answer accurately, and I
hope you already know the reason why.

Even for the paste icon, it is extremely hard to be accurate on whether the
clipboard is really empty simply because you could always copy something in
another application.  To get the state of the system clipboard always right, OOo
must query the system clipboard state at regular intervals.  Given that, it's
certainly easier and more efficient to always enable the paste icon, then once
the user requests a paste action, query the clipboard to see if it's empty. 
This would avoid wasteful polling of the system clipboard, and keep the code
complexity lower.  (Actually I just found out that OOo disables the paste icon
when it thinks the clipboard is empty, but copying something in another
application does not re-enable it.  Is this a bug or a feature? ;-) )

For the undo/redo buttons, I can think of one situation where getting the state
of the undo stack is not straight-forward; when it involves editing of charts. 
But other than that, the criteria is pretty simple; when the current position is
at the top of the stack, enable undo and disable redo, when it's at the bottom
of the stack,  disable undo and enable redo, when it's somewhere in the middle,
enable both icons.

So, back to the Save icon.  It all comes down to how easy/difficult to
accurately determine the document modified state.  You would have to answer many
other questions before you can answer it reliably: what does a document include?
is view data a part of the document, if yes, which view data should be part of
the document, if no, should modifying the view data trigger the document to be
modified?  If the view data should not trigger the document to be modified,
should they be saved with the file? etc.  Any sophisticated applications save
the view data and other accessory data that are not part of the core document to
the file on disk.  But because of this, it is extremely hard and (to me) no
longer realistic to disable the save action at correct time in such a way to
satisfy all users.  Having said that, I can see I'm in the minority in this part
of the world.

Actually for the clipboard, we could use a callback from the clipboard for a
clipboard state change (if such mechanism is available, and no, I'm not an
expert here).

Anyway, my point is, if we can always get the state of the criteria correctly,
by all means disable the icon when appropriate.  If not, leave it enabled at all
times.  That's my take.

@fs:

>I am paranoid.

me too. :-)

>I save often, very often.

me too. :-)

>In fact, when writing texts or spreadsheets, Ctrl+S is probably my most often
used keyboard shortcut.

I wouldn't say I use Ctrl-S most frequently, but I see your point here.  But
still I don't think you save your document every second, do you? :-)

>Maybe because I had OOo to crash and lose my changes too often in the past years :)

Haha.  A little humor here. :-)  On the bright side, the document recovery has
been working for me pretty good in this area.  But no, I wouldn't still trust
the document recovery feature 100% of the time.

>So, for me, the *unpatched* behaviour is a useful feature, not a bug. Let's say
I'm an advanced user who can handled the "additional complexity" of this feature.

But the unpatched behavior prevents a certain group of users from saving his/her
document when they want to.  That's certainly not useful to them.  And we are
basically telling them to back off instead of providing them a solution.

>Then we're down to: Which user group to we want to satisfy? Either way, we will
lose (the sympathy of) parts of our users. What's the bigger loss?

Either case, why alienate one group in favor of the other?  I'm all for making
it configurable to satisfy both parties.  Doing that at this stage may be a
little too late, but we should at least consider it for future versions.

>Given the positions exchanged in this issue and in discuss@ux, I tend to think
that there are less friends of the new/patched behaviour than of the old one.

The users on discuss@ux are by no means representative of the whole user
demographic.  So, while certainly you have the right to consult them, you should
not base your opinion entirely on their input.

IMHO, just making Save function always enabled is considered regression. 

If we try to do so, we would need to add something that indicates the status 
of modification. For instance, a graphical image plus text message saying 
either "Not modified" or "Modified."

 a) Save function always enabled plus status indicator of modification
 b) Save function depended on the status of modification (current implementation)
 c) Save function always enabled

Our OpenOffice.org are currently classified at the level b) and some users 
find it unsatisfied. Always-enabled, c), however, could be considered downgraded 
by other users. So we can devise means to satisfy both groups of users, a). 

Well-designed software clearly reacts to a command issued by a user. 
 1. User ordered something.
 2. Software responses by showing something such as clock-shaped mouse cursor, 
    changing color of icon button or window, activating a progress bar, etc.
 3. Software reports the result of the action by showing something such as 
    changing color of window back, changing shape of cursor back, or showing a 
    dialog window to report an error, its cause, and possible ways to recover it. 

BTW, definition of modification is probably quite simple. 
Think of the following steps: 

 1. Do something.
 2. Attempt to close the document.

If OpenOffice.org warns at the step 2 telling "Your document has not been 
saved yet," the document is considered modified. 

Changing location of cursor on Writer, changing active cell or sheet on Calc, 
changing current slide on Impress, zooming in/out a document, changing the 
size and/or location of window, etc. are not considered modified. 

Such actions should not be warned upon closing the document regardless of 
saving it. But the results of the actions could be preserved by intentionally 
saving the document and be retrieved later by loading it. 

Don't you think so? :-)

> I wouldn't say I use Ctrl-S most frequently, but I see your point here.  But
> still I don't think you save your document every second, do you?  :-)

Well - every few seconds. That shortcut meanwhile is hard-wired somewhere in my
brain, and as soon as I end typing a chunk of text, I use it. Anyway.

> Either case, why alienate one group in favor of the other?  I'm all for
> making it configurable to satisfy both parties.

I agree here. I'd vote for leaving the current behaviour unchanged, and adding a
"Force Save". OOo packagers and OOo installation administrators are then free to
configure the default they find most appropriate for their user base.

> The users on discuss@ux are by no means representative of the whole user
> demographic.

Sure. Probably no single group of users in one of our lists is. Which shouldn't
stop us from asking them, as you said. Also, my hope was that in discuss@ux
some, well, user experience experts linger ...

One application that disables the "SAVE" button is: Adobe Acrobat.

I addressed further concerns in another post on the UX-mailing list:
http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1638

Please note, I do believe that unnecessary saves will create a number of
problems with:
 - concurrent editing of documents (e.g. new spreadsheet feature)
 - big documents
 - saving over the network (e.g. during my 2nd job I do save documents
   on a server in a different country)
 - will divert users attention away from their proper work
   will raise the error rate
   (numerous studies, including my auditing activity strongly support
    that diverting users attention increases the error rate)
 - will interfere with track changes and traceability of document changes
   [in the field I work this is a requirement by EU law]
 - excessive "saves" will interfere with other activities,
   e.g. with one of my feature-proposals:
   http://www.openoffice.org/issues/show_bug.cgi?id=80909

Adobe Acrobat has the following feature:
 - IF the user does indeed want to save the current document, then there
   is a Menu entry: "Save as";
 - this works always and overwrites the existing document

This is the better approach.

> Well - every few seconds. That shortcut meanwhile is hard-wired somewhere in my
> brain, and as soon as I end typing a chunk of text, I use it. Anyway.

Me too. In my case, it is from 'Bomb !' experiences with MacOS in the 1980s.
The Mac, at the time, often shows a Bomb image at the center of display. 
A graphical image of my works on the software such as word processor is still 
there, but the Mac freezes. 

> I agree here. I'd vote for leaving the current behaviour unchanged, and adding a
> "Force Save". 

That is a good idea.

For either "Always-Enabled Save" or "Force Save," the icon button could be 
implemented in the following or similar way to offer better UI.

 1. User clicks on the icon button. 
 2. The icon turns disabled. 
 3. File selection dialog appears if the document has not been named.
 4. Process of saving a document goes.
 5. The icon turns enabled after finishing with the process.

What about the following conclusion:

We will have two functions:

"Save" - only enabled if document is modified 
"Store" - always enabled if document is not read-only

Both functions fall back internally to "SaveAs" in case the document is new (as
"Save" does today).

The menu bar entry and the shortcut will call the first function and the toolbar
button could be either one (to be discussed), but we shouldn't have both buttons
in the toolbar.

I don't think that it is too complicated to detect the "Saveable" status
correctly. What I could agree to is that though it is not complicated it might
be not what is the best for all users and so giving them the choice to when they
want to save would be an advantage.

But the "CTRL-S" scenario is important, there are situations where saving too
often is bad. An example would be users that use the "version" feature where
each time when the document is saved a new versions is created. 

Perhaps the "two functions" approach can help. This still leaves the question
open which of them should be available in the toolbar by default. :-)

As it seems that the current solution won't be accepted without changes I have
reopened this issue.

> "Save" - only enabled if document is modified 
> "Store" - always enabled if document is not read-only

I'd buy that ...

>> "Save" - only enabled if document is modified 
>> "Store" - always enabled if document is not read-only
>
>I'd buy that ...

me too.

I can live with Save / Store, too.  (Even if my favorite solution is the
gray/green/blue tri-state icon.)

It seems fairly obvious that the default should be Save, i.e., no change to
current behavior.  That will be a minor nuisance for me, updating all my
customized toolbars, but it's a one-time effort.  I want the new behavior, I
have to work a little to activate it; seems fair.  /tj

You still can get your blue/green/grey tri-state icon. There's nothing that
prevents us from implementing the new "store" button that way. I will give this
some thought.

Moved to 3.1 to allow for implementation of the UI changes.
As the original patch will not be applied I also changed the type to "enhancement".

I can't tell exactly from discussion here where this issue is heading.
I am using 2.4.1.5 ("unstable") on OpenSuse 10.3 and the change to always enable
the Save button is still in effect. I dearly want to see the old behaviour back.
It should not have been changed, at least not in so cavalier a fashion.

The argument for programming simplicity (brought forward by kohei and others)
doesn't hold water when one is also arguing for the compensatory modification
indicator in the status bar: if it becomes too complex and equivocal to
determine what constitutes a change in the document for an enabled or disabled
save button, it is just as complex and equivocal to do so for the status bar
indicator. The fact is, there's a pretty good consensus about what constitutes a
file modification; and there is also a precedent of including a user option
about, for instance, print setting "document modified" status.

Calc is perhaps a different beast, since spreadsheets function differently, but
that is a distinct issue. I'll let the inveterate number crunchers decide
whatever seems right for them.

But in a word processor (and other document editing), what is the purpose of
saving when the document is already saved? Wanting to do so repeatedly "just to
be sure" is a sign either of complete neurosis or of a thoroughly unstable and
unreliable system. And I too am paranoid, like many here, and save automatically
and repeatedly while I type. But I like the "cleanness" in design and work space
of a save button that is only active when there is something to save.

Please roll back this change until the other option can be offered cleanly as
just that, an option. And please do so quickly. I don't want to have to wait for
3.1! When there are so many important issues crying out for attention, fervently
requested features and enhancements, why did you guys have to tinker with this?
Don't let a jittery eye on little differences with how some others do things
("competitive analysis") lead you astray.

> Please roll back this change until the other option can be offered cleanly
> as just that, an option.

Sorry, you're in the wrong place here. The version you use is a Novell-specific
version - Novell decided to include the patch for this issue, where in the
OpenOffice.org builds which you can download from www.openoffice.org, the patch
is not yet included.
So, you need to approach your Linux distributor, this issue tracking system here
is not for distro-specific issues, sorry.

(Nontetheless, I appreciate your argueing here on the matter itself - my above
comment *only* applies to you begging for reverting the change.)

I suggest the following solution.

1. Don't change the behavior in sfx2/source/doc/objserv.cxx, so we have dimmed
Save icon if the document is not marked as modified (old good behavior :) )

2. Change the ModelData_Impl::CheckStateForSave in sfx2/source/doc/guisaveas.cxx:
remove  

if ( !GetModifiable()->isModified() && !bVersInfoNeedsStore ) 
  return STATUS_NO_ACTION;

to allow save always.

This solution allows: 
* to save the document (always)
* dimmed Save icon as modification indicator

I prefer another solution.
The status of the "Save" button should depend not only on the "modified" status
but also by an additional "storable" status. If either of these values is true,
the button gets enabled.
This additional status could be set e.g. when a view change in a Calc document
is made. It's up to the application to decide when this status shall be "true".
And no: moving the cursor shouldn't trigger that.

But when the document is closed, only the "modified" status will be evaluated,
so that changing the view will not cause a dialog to be shown.

This will need some more code to write, but I prefer a good solution with a
little bit more work over a quick hack that causes trouble for others.

>And no: moving the cursor shouldn't trigger that.

In Calc, moving the cursor *should* trigger it, since the cursor position is one
of the useful view settings to save.

Also in this scheme, it would become a little tricky to trigger the storable
state when Calc is in cell-editing mode, since the focus then moves to
EditEngine.  IMO it would be simpler to either allow always save or not on a
per-application basis.  (Or we could simply set the storable state to always
true in Calc.)

SBA->MBA: Please proceed.

*** Issue 101970 has been marked as a duplicate of this issue. ***

Created attachment 66462 [details]
patches to make the behavior of the save icon configurable (sorry they are zipped)

In case you guys decide to make the save icon behavior configurable (I hope you
do), here is the patch set that implements it.  It adds a new check box in the
Options dialog to toggle whether the save icon is always enabled, or becomes
grayed when the document modified flag is not set.

IMO that's a reasonable, sane approach to this, instead of the proposed
tri-state (modified, storable, not modified) solution, which somewhat
over-complicates the logic of the functionality.

Created attachment 66463 [details]
new check box in the Options dialog

Reset assigne to the default "issues@openoffice.apache.org".