The "Warning there are unsaved changes" dialog
Simon Baird
Udo Borkowski
When the onbeforeunload event handler returns a string this will bring up an OK/Cancel dialog. Pressing the Cancel will avoid navigating away from the page.
I.e. we could do the following:
remove the
onunload="if(checkUnsavedChanges) checkUnsavedChanges();"
from the <body>
Add the following to the code:
window.onbeforeunload = function(e) {
if (store && store.isDirty && store.isDirty())
return "WARNING: There are unsaved changes in TiddlyWiki that will be lost\nwhen you navigate away from this page.";
};
In case the TiddyWiki is modified and the user wants to navigate away from the page a dialog appears:
--------------------------------------------------------------------
Confirm
--------------------------------------------------------------------
Are you sure you want to navigate away from this page?
WARNING: There are unsaved changes in TiddlyWiki that will be lost
when you navigate away from this page.
Press OK to continue, or Cancel to stay on the current page.
[ OK ] [ Cancel ]
--------------------------------------------------------------------
This way pressing Cancel ensures that no data is lost and the user is returned to the TiddlyWiki. Pressing OK will go to the new page and changes are lost.
Note that this is different from the current behaviour (Pressing "OK" does the save and navigates away, "Cancel" navigates away with data lost), so people used to the old dialog may be confused when we switch to the new approach (possibly they may even lose some data because they "automatically" press the OK button).
Nevertheless for me the "go back to TiddlyWiki on Cancel" is the nicer approach, since it allows the user to review his changes and explicitly do the save.
Udo
Eric Shulman
> event.
I like the improved usability this could offer, but there are some
issues that make me hesitant to get behind this suggestion...
Portability and cross-browser compatibility are really important to the
future of TiddlyWiki. Anything that goes into the TW *core* needs to
work in ALL browser environments, especially if we are going to rely on
catching a browser event as the 'safety net' for preventing TW data
loss on exit...
The use of onbeforeunload has some serious limitations in this regard:
1) It's an MS extension that is not part of the W3C standard.
2) Firefox only reluctantly implemented this, after a 2.5 YEAR
discussion, and there are cross-browser concerns (due to MS
non-standard event handling such as implicit use of event.returnValue),
as well as concerns about abusing this feature to make it hard to leave
a page.
3) According to my web research, onbeforeunload is supported in
IE4+/Win, Mozilla 1.7a+, and Netscape 7.2+, but is NOT SUPPORTED in
Opera, Safari, Konqueror, and many other alternative browsers, so a
suitable 'onunload' fallback is still REQUIRED to ensure TW data
safety.
Don't get me wrong. I like the improved usability that onbeforeunload
handling would achieve, but I'm not convinced that it can be a
rock-solid reliable replacement for the current onunload handling, for
*all* TW users. This particular 'safety net' feature has GOT to work
right for EVERYONE.
thoughts?
-e
Eric Shulman
TiddlyTools / ELS Design Studios
BidiX
Eric Shulman wrote:
>
> Portability and cross-browser compatibility are really important to the
> future of TiddlyWiki. Anything that goes into the TW *core* needs to
> work in ALL browser environments, especially if we are going to rely on
> catching a browser event as the 'safety net' for preventing TW data
> loss on exit...
I agree with you Eric, It's really important to be cross browser
compatible into TW *core*.
I put the Udo's code into systemConfig tiddler and I test it in local
TiddlyWiki or on a web TiddlyWiki. It's really nice. It works like it
would be. That's to say when you try to close your window or load a new
page into it, the good question is asked : "continue or not ?".
And if you chose *continue* the second good question then is asked
"Save or not ?".
For my personal point of view, this two popups are great together and I
will adopt this in myConfig tiddler. Very often I click on my browser
toolBar to open a window and I am editing in web TW. And
unintentionally I Upload my TiddlyWiki because I have no other choice
except lose my editing.
No really I can manage without it now.
But Eric you are right, since it is not cross-browser compatible, it
would not be put into the TW core.
-- BidiX
TiddlyWiki.bidix.info
Udo Borkowski
An alternative would be to use the onbeforeunload if is available (approx. 95% of the cases) and fall back to the unload approach in the other cases. Of cause this is only possible if there is a reliable way to detect if the current browser supports the "onbeforeunload" (is this possible?).
One drawback with this approach is that a user working with two browsers (e.g. Safari and Firefox) will get similar looking dialogs in the "leave with changes" case, one that save changes on "OK" and one that drops changes on "OK". Not nice, but hopefully a rare case.
What do others think?
Udo
Clint Checketts
On 2/9/06, Eric Shulman <elsd...@gmail.com> wrote:
3) According to my web research, onbeforeunload is NOT SUPPORTED in Opera, Safari, Konqueror, and many other alternative browsers, so a suitable 'onunload' fallback is still REQUIRED to ensure TW data safety.
-Clint
Eric Shulman
> (approx. 95% of the cases) and fall back to the unload approach in the
> other cases. Of cause this is only possible if there is a reliable way
> to detect if the current browser supports the "onbeforeunload" (is this
> possible?).
Actually, I kind of like BidiX's solution to add it as a plugin, and
leave the onunload handling in the core exactly as is. The resulting
interaction sequences are:
Exit? [cancel] ... back to TW
Exit? [ok] Save? [ok] ... changes preserved
Exit? [ok] Save? [cancel] ... changes discarded.
Sure, having two messages show up may not be ideal, but it does seem to
"flow" reasonably.
I like to use the keyboard to respond to these messages. When I am
working on a plugin, I often will click 'permaview' for that tiddler,
do some editing, and then press refresh(F5)-enter to perform a quick
save-and-reload, with the plugin tiddler displayed and ready for more
editing. Even with the second message box, this sequence is simply
F5-enter-enter, so it is still a really easy no-brainer.
I've added this to TiddlyTools:
http://www.TiddlyTools.com/#ConfirmExitPlugin
give it a try and see how it feels...
-e
Daniel Baird
Jeremy's mentioned before that he's refactoring out some of the lesser-used built in macros, like sparklines etc. I guess that means there will be a few "official" macros available from tiddlywiki.com that aren't packaged into the default download.
It seems right that this plugin should join that group of official plugins.
;D
Daniel Baird
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things That Suck)
[[My webhost uptime is ~ 92%.. if no answer pls call again later!]]
Simon Baird
Udo Borkowski
Depending on how we define "cross-browser compatibility" this would also allow us to make the "onbeforeunload" stuff go into the core:
on all browsers it is ensured that the user does not lose changes unintendedly (e.g. just be navigating away from the page). In addition in some (/most) browsers the user will even get the chance to go back to the TiddlyWiki when (accidently) leaving a changed TiddlyWiki. If cross-browser compatibility does not require "identical behaviour" this is just a more user friendly implementation of the requirement "User must not lose changed unintendedly". If some browsers don't support this nice implementation a less userfriendly solution must do for them.
BTW: this "make a feature more userfriendly" approach is even more than we do with other features. E.g. as Clint already mentioned: the "Save" and "Editing" features (very fundamental features, I would say) are not implemented *at all* in Opera or Konqueror. I guess no one would suggest to put the "Save" and "Editing" features into a plugin and remove them from the core, just because "Save" and "Editing" cannot be implemented in Opera or Konqueror ;-)
So I suggest to put the two lines of the ConfirmExitPlugin into the core:
config.messages.confirmExit = "There are unsaved changes in TiddlyWiki."
window.onbeforeunload = function(e){if(store&&store.isDirty&&store.isDirty())return config.messages.confirmExit;};
Udo
christianhauck
features that don't work on a particular platform - is essential, but
identical behavior is not. And the reason there is that many (normal)
users stick to one browser, and will get used to that one. They won't
complain is TiddlyWiki behaves slightly different elsewhere (if they
never go elsewhere, and don't even know it. Example: cosmetic
gradients). We want to satisfy them all - somehow. Core vanilla
Tiddlywiki should work, out of the box, that's the point of the
compatibility. If some environments offer small improvements, even
better. The other way around it's not true: if some "essential" don't
work everywhere, it's quite a problem.And sometimes it's so big (saving
witth Opera) that we still have to live with it.
Jeremy Ruston
wherever we can not to lose their data outweighs the need to strive
for a consistent cross-platform user experience.
I propose to implement Udo's suggestion, and to attempt to mitigate
confusion by making the 'new' alert look as different as possible from
the existing onunload one, and suppressing the existing onunload alert
when onbeforeunload is available.
Cheers
Jeremy.
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
christianhauck
that's what I meant, you just express it much more clearly ;-)
Jeremy Ruston
Necessarily, the new 'confirm exit' alert uses the following button meanings:
cancel = safe option; don't exit from the page
ok = unsafe option; exit away from the page
While the existing 'last ditch save' alert uses the following button meanings:
cancel = unsafe option; discard any outstanding changes
ok = unsafe option; save any outstanding changes
Now, there's clearly a reasonable argument for trying to avoid the
inconsistency by switching the meaning of the buttons in the existing
'last ditch save' alert (we can't change the meaning of the buttons in
the 'confirm exit' alert).
All the same, on balance, for historical consistency I propose to
leave the existing alert as it is.
Cheers
Jeremy.
On 10/02/06, christianhauck <christian...@googlemail.com> wrote:
>
> Jeremy,
> that's what I meant, you just express it much more clearly ;-)
>
>
>