Implicit Save
One of the interesting things I learned at the last Ubuntu Developer Summit was the widespread use of implicit save in the GNOME environment.
Implicit Save (or can also be called instant apply or instant editing) is when changes made by the user are automatically saved by the system without the need of the user confirming the changes by performing a Save or Apply action (implied to be so by the action of the user making the change). Explicit Save is when the user explicitly confirms the change by performing a Save or Apply action.
In many cases, implicit save makes a lot of sense and makes the configuration and interaction with options much more natural. For example, consider (Ubuntu) GNOME’s Appearance Preferences dialogs. The widget theme selected is the current theme. Select a different theme and it is changed immediately and automatically:
The immediate apply is pretty neat, but there are a few things that have me worried. There is no obvious “out” for the user. If you are trying out themes and want to go back to your original one, you have to remember which theme was selected. Otherwise you’re stuck. (I’ve been told that clicking the X button in the window decorations instead of Close will reset your options, but this doesn’t work in the Appearance Preferences nor the Internet Proxy dialogs).
This safety net may not matter so much for changing window decorations or fonts, but it matters a lot when you are configuring more important system-level settings such as Internet proxies. Say a user is exploring network options and comes across the Internet Proxy configuration dialog. They click on a few options to configure a proxy but change their mind. The Close button in the dialog is a bit ambiguous and doesn’t give a hint as to if it will save the new options or not, so the user clicks the X close button on the window decoration thinking it is the same thing as Cancel. Now their network settings are messed up. When the user begins having network trouble, it is unlikely they will remember they reconfigured their proxy information because they think they cancelled the changes.
Look at how KDE handles changes in System Settings. Although the dialogs aren’t as well designed (we’re working on that), guessing the result of a user’s actions is much more clear, and an “out” option is provided to users who may have forgotten they made changes while they were browsing the dialog:
The problem with the current GNOME implementation is that it doesn’t support users who make errors. There are many reasons why a user could make an error when configuring a dialog, but the types of errors which would result directly from the dialog design (i.e. not user knowledge errors) would be attention-based: forgetfulness, interruptions, multi-tasking, etc. Also, users tend to “start over” when a task becomes too complicated or they think they’ve made a mistake. You can’t do that with these dialogs. Also, almost all of the dialogs use implicit save instead of selectively where it makes sense.
Although many long-term GNOME users may have adjusted they way they work with dialogs because of this behavior, your KDE and Windows users are going to suffer. OS X is selective about when it uses implicit save — when it makes sense, and provides revert/apply options for particularly sensitive options.
However, there are a two easy fixes alleviate some of these problems:
- Change Close to OK. Close is neutral and wont help the user when they’re not sure what will happen. In GNOME, Close has a bit of a negative twist to it because of the orange X icon associated with the button. OK is positive and when you click it, is like saying “I am OK with the information in this dialog”.
- Add a Revert or Undo button so users can get back to the original state of the dialog information if they need to start over
- Optionally, I would also change the window close button (X) to be a Cancel function instead of the current Close (OK) function. Users resort to controlling the window instead of the dialog when they are in doubt and don’t want to save their work.
As I’ve been discussing, implicit save isn’t something we really do in KDE, but it does get used in a few places. Here are two good applications of implicit save in KDE:
KNotes. When you create a new KNote, new notes are saved automatically as well as any text changes so if you close the note and reopen it, all of your changes are there. There is no need to explicitly save every text edit and since the information is very ephemeral, there is no need for a history of changes. Undo is supported.
Konqueror. The bookmark editor is updated automatically and there is no need to explicitly save your changes. Although the interface does not confirm destructive actions such as deleting a bookmark, it does support Undo and Redo actions so you can recover a bookmark you might have accidentally selected.
In summary, here are some pros and cons I can think of involving the use of implicit save.
Pros
- Makes sense in certain information contexts, especially when dealing with ephemeral data
- Supports tasked-based workflows more naturally without the need for supportive interaction procedures
- Easy to adapt to or relearn in cases where explicit save was previously used
Cons
- Isn’t appropriate for many types of information tasks which makes creating guidelines for use and implementation difficult
- Difficult to manage and easily abused since good guidelines would be difficult to write
- Can be destructive and hard to recover from; in many cases and will increase the number of user errors (lost data or unstable system)
I’m interested to hear what the KDE community’s thoughts are on this. Is implicit save something we should be investigating? I think it’s use in Plasma could be valuable, but this is not something I would recommend for configuration dialogs.
Celeste, the basic idea is that GNOME’s instant apply[1] should only be used for preferences, not settings. The difference between a preference and a setting is that you can’t have a “wrong” preference, but you can have a wrong setting.
So the proxy shouldn’t be instant apply; really you want a “test this setting” type button there.
[1] I wouldn’t call it “implicit save”; that sounds more document-related
Nothing wrong about investigating it to see where/when/if it could be worthwhile, but I have to admit: that’s one of my pet peeves when it comes to Gnome. There are some cases where it makes sense, but I think the Gnome guys overdid it.
Yes, I do think it is is good to have a HIG but it should have some leeway too. And implicit save is a big no-no, in my book at least, when it comes to settings that could affect the entire system. I mean, if I mess up the K3B or Gwenview settings - the worst that could happen is that I would have to reset those settings to the default. Adept/yast/package-manager-of-choice, network settings, activating composite, and other potentially hard-to-get-out of situations should require a explicit yes if you ask me. And it should definatly not require you to know which .kde/share/config file to edit to get out of it in case you mess up (or, in the case of Gnome, require knowledge of how gconf works).
instant apply, as collins call it, and I think he’s right, always made me remember those days when using a database browser like foxbase meant that if you changed something in the grill where data was presented you in that changed was also applied to the database too, with no obvious rool back function.
collins says that instant apply should only be applied to preferences, but preferences can also be “bad”. imagine I’m trying to set the color scheme for the theme I’m using. now, I’m no good with colors, but I always try to set a scheme that I like better. now, most of the time I just make it worse. that’s when a rollback function come handy, specially associated to a preview: when the user might think a new setting will be better, but then realizes it doesn’t. I prefer the kde way.
I’m a KDE user, and I consider “implicit save” in kbookmarkedit a bug. It’s made me angry more time than I care to count. It’s why I keep a half-dozen copies of my bookmarks files. kmenuedit doesn’t do this. No other KDE app does this. It’s a bad idea! Consistency!
There is a good post at http://blogs.gnome.org/desrt/2007/08/24/non-instant-apply-preferences-dialogs/ which explains why non-instant apply dialogues aren’t used in GNOME (much).
+1 to Roland Latour: Implicit save / instant apply is bad (exactly for the reason Celeste is pointing out: it makes it really hard to undo mistakes and really easy to accidentally commit them without even realizing you just did that), and the bookmark editor really shouldn’t be using it, as nobody is expecting it. (This is a regression which happened somewhere in the 3.x series, by the way, it used to require explicitly saving changes.) The suggestion of only using it in some dialogs is also bad, as that goes very much against the principle of least surprise. So if I had to vote, I’d vote for consistency and against using implicit save / instant apply anywhere at all (i.e. for explicitly banning it in the HIG).
KNotes is of course a special case, as the metaphor of a post-it note is very different from a settings/preferences dialog or from a regular text editor.
@Bruce Cowan: I don’t see why those 5 buttons are that bad. I’d actually add 2 more: Defaults (reset to the default settings) and Revert all (undoes everything you did since opening the dialog, even already applied settings). Those 7 buttons should provide the maximum flexibility. (And no, this is not a joke nor sarcasm, I really mean it.)
I believe the “clear” button (usually with the wiping icon) is for the “undo” cases. Because even if you have the apply button, you can still mess up, and forget the original option.
(I’m also wondering what will the line between Gnome and KDE be in the future, as prominent things like this set them apart)
I think instant apply can be nice. And realizing an undo option does not contradict with it at all.
Just have the buttons [Undo] [Close] and you’ll always be able to revert your settings to the state where you opened the dialog.
If you press [Apply] when there is no instant apply, you can not revert either so that is not really a valid argument.
On the other hand I think consistency is important and even more a HIG that define what is consistent.
Well, working at a mac store, teaching a 101 class…
Most people are impressed by implicit change when they discover it exists, but they didn’t expected implicit saving.
Nice article. The gnome appearance thing is one of the (many) things I don’t like about gnome. It was annoying when I’d just idly click a theme and all my windows start freaking out as the theme is applying.
I prefer the KDE dialogs. I like having the reset button so after I’ve clicked every option in it I can just cancel it all and go on.
I think the only place where an auto save makes sense to me is when writing an email. Its ok to have it save the email I’m writing every couple of minutes to the drafts folder.
I guess the KNotes is a good one too. Its one of those things where you don’t think about it saving at all, just pop it open, enter some text and move along.
I agree with what seems to be the common sentiment here. Implicit save is bad. It may make things easier, but it also makes them easier to mess up. The case where this bothers me the most personally is where there are a combination of factors that interact. For instance a user-modified color scheme. You may have to alter a dozen different colors, each with 3 or 4 parameters. I honestly can’t think of a use-case where an implicit save would be a good idea.
This is just my personal preference, but I like how KDE double-checks to make sure you don’t want to save your changes when you try to leave a configuration area. This handles the ambiguity between the “close” and “cancel” buttons just fine. Having that whenever you make changes and then click on the “cancel” button, for me, would be great. Similarly, having a “revert” button that then asks you whether you want to revert to your previous settings or the default settings would be good. This, at least for me, is not a common operation so having the dialog occasionally would not bother me. That would be 4-5 buttons: OK, Close/Back, and Revert, then Apply (in situations where there will be visible changes) and Preview (same). At least in systemsettings the “Back” button is out of the way, so it would not clutter things.
I do think Apply probably does not need to be available everywhere. Unless there are visible changes, someone shouldn’t be using the program while the configuration is open so there shouldn’t be any benefit gained from having the button. This obviously doesn’t apply to systemsettings.
Confirmation dialogs only save you when you’re experienced enough to know you’ve made a mistake, which very nearly sounds like being smart enough not to make the mistake in the first place. I can imagine people screwing up their networking just as easily with instant apply as with confirmation; the pop-up dialog might scare off those uncomfortable with the system, but it doesn’t help you much when you do need to make a change. As far GNOME versus KDE goes, I’d call it a tie. They’re both equally inadequate.
Amusingly, the general UI abomination compiz config tool CCSM had an interesting technique for handling this exact situation. Every setting comes with defaults (via gconf schema maybe?) and a method of restoring them, similar to the “Revert” idea in this post, but instead of reverting to the previous settings, it reverts to the stored default. Sometimes, you don’t really know if you want 15000 fire particles until its too late.
Please not, implicit save is the reason I switched from Firefox/Thunderbird to Konqueror/KMail.
Gnome and OS X, in my experience, don’t seem to have a grasp on when to use Implicit Save, and I feel it should “never” (never probably meaning “almost never”, realistically). It seems straight-forward without Implicit Save: an “Apply” button saves your change, a “Cancel” button closes the window without saving.
The problem with Implicit Save is: when should an interface designer use it? how does a user know it is being used? and how to establish a consistency in when and how it is used? OS X’s System Preferences are an excellent example of an inconsistent UI; half the choices do not require Explicit Saves and the other half do and sometimes it is difficult to tell which is which (see Startup Disk for a prime example, also the .Mac configuration in Tiger)
I don’t care much for implicit saving in preference- and settings dialogs. I DO care about it in other apps - it would be really great if eg KWrite would save the contents of the window and restore it on the next session restore (log in), even if I didn’t explicitly save it. Esp if it would also save undo information. I think that would really make a difference - automatically saving, including undo information, in all apps…
Those who are complaining about the implicit save, should have opened bug reports about it.
Complaining in the comments of blog, is of no help to the maintainer of keditbookmarks.
I, too, think that for many things, auto-apply is, for the current KDE, not a good idea. It is nice to see a preview of the effects of what you do (if possible), but that is not the same.
What is more, I think KDE needs to move in the opposite direction: instead of making it harder to undo making changes to configurations/settings/preferences/(documents even?), it would IMHO be nice if it were to be made much easier to revert changes that turn out not to be that great after all.
Innocent example:
Say, I am in a dark mood tonight, and I decide to change the appearance of my shiny KDE 4 to something really dark. The next morning I slept it off, and want to change back to the delicate balance of settings I used to have before. Wouldn’t it be great if I could just say that I want to revert to the settings for everything related to appearance that I had yesterday morning?
Less innocent example:
Say I am experimenting with my networking and proxy settings, and at first sight everything seems to be ok. But then I start using program Bar, and it turns out it has problems with the new settings. Now I want to return to what I had before, but…. hmmm… I changed that last week… What were those settings again?
I think it would be great if there would be some kind of automatic history for at least settings, neatly categorized, of course. It should allow you to from the settings dialog itself revert to a previously saved state for only the settings from that dialog. The system should also give you a central place for all settings where you can track changes in your settings, revert the ones you like to a previous state.
I think something like this would be real innovation, and make it much easier to undo configuration settings mistakes. With a system like this in place, it would also be much less problematic to have something like an auto-apply, because with a settings-versioning system like this, you can always backtrack.
Hmm,
I think changes should apply instantly and you should have an OK and a CANCEL button. If you don’t like your changes you CANCEL.
That would be the best solution.
@jldugger: I don’t think this is about confirmation dialogs, but more about having to manually click on Apply to propagate changes. Confirmation dialogs are a whole different beast.
Jos beat me to it.
Implicit save isn’t inherently bad. It is useful in certain contexts. I agree with Alan Cooper (at least what he said in his old book) that for document-creating applications (text/word editors, for example), implicitly saving the file, on closing the app and at certain intervals, is better than explicitly having to save things.
However, in the context of user/system settings, I feel that previewing the result and then saving/applying it explicitly is a much better and safer implementation.
But you know what? I don’t implicit/explicit save is the real issue here, in the final analysis. If you’ve noticed your own words as well as the previous comments, most of them talk about the problem of *undoing* a previous change. IMHO the real issue here is how to get a smart and sane undo system across the whole desktop, as well as a consistent UI for that. For example, I’ve known KDE to have inconsistent “Reset” and “Defaults” button behaviors. Then there’s also Jos’ suggestion of saving undo information, probably across desktop sessions or even across app sessions.
In summary: Taken in isolation, implicit save isn’t as bad as people might think. In certain contexts, it could even be more useful. But whether it is implicit or explicit save, the real important part is getting it to work with a good undo system. After all, an Apply button won’t really save a user from a bad setting he isn’t aware of. It will only delay it by one click. :)
@Jucato: You’re right. I simply wanted to use a term to describe what I saw in the system settings dialog to contrast it with gnome’s implicit save. I guess I should have called it “explicit save” as the post did, duh. But it doesn’t change what I said much — clicking apply doesn’t rescue you from bad edits any more than implicit save.
If there really is enough state in a settings dialog that you want explicit transactions, you might as well make explicit what’s being changed by clicking “OK”. That seems handy with these multi tab, pane / window settings editors where you make changes across a wide number of panels and most of them are hidden. That would at least make the user aware of the settings, though as I mentioned, sometimes you just don’t know what’s bad versus what’s sane until you try it.
Ok (or Apply), Defaults (or reset), Cancel (Or Previous Settings).
Some random remarks:
1) Your reasons for not doing instant-apply (like the user forgetting about it) is the same problem for explicit apply. The user changes stuff, clicks ok, and forgets he broke stuff. Not gonna help.
2) Have you ever used instant-apply for a longer time? I’ve been advocating against it back when GNOME changed it, but I honestly do not miss it in 95% of the cases. And when I miss it, an explicit apply doesn’t help me either. Here’s the use case:
I change a lot of settings (like in the Appearance dialog) to see if I like it. Then I play around with them. I do this a few times. Finally I realize my old theme was best, but how do I get it back?
Had it been delayed apply, I’d have likely clicked “apply” for 5-10 times, and no undo would get it back to me. Same for proxy settings: After I click apply to test them, the old ones are gone.
3) I haven’t really seen bugs about instant apply in GNOME. So I guess people were able to pick this up rather fast.
4) I’m sure even KDE has lots of instant-apply preferences. They sit in a menu as a checkbox and are named “view sidebar”. Or they sit in the toolbar and say “show previews”.
What if we change “Apply” button work only as “session apply”.
We would have four buttons. Defaults | Apply | Cancel | OK
- Defaults button would always revert back to defaults what comes with the packager settings.
- Apply would apply settings so user can preview things, but those ain’t really saved until user clicks “OK”. If user would click 5x Apply for new settings and then Cancel, it would revert to settings what was set when window was opened.
- If user clicks settings and click OK, those get saved.
I actually prefer few buttons more too.
Defaults | Undo (steps) | Cancel | Apply | OK
- Defaults as it sounds.
- Undo works like Undo/Redo buttons but only for backward of Apply settings.
- Cancel does not save anything what were saved after the window got opened
- Apply, applies the settings for so long that window is open.
- OK, Saves the applied or other wise set configs after that window got opened.
The Undo button could be two arrows (two buttons then?) on Kword etc. You could test all settings, and if something goes wrong, just click “undo” and last settings get applied automatically back, you can go back and forward with that to check themes or other settings and when you are ready, you click OK or if you dont like anything, you just click “Cancel”.
The “Undo/Redo” button could bring similarity from other applications when you can undo/redo edits (text/image/photo editors). But it will add more buttons. Problem might be that some dialogs are always top of the host window, so you cant hide the configuration window, like on konqueror, so the Apply/Redo/Undo does not help either. It would need that config window can be hided behind out of the way so the settings can be tested. But it has again new usability problems.
I believe that you cant make 100% working UI for every situation, you always need to do compromises, what makes usability even worse if you have 2 or 3 different kind working actions. We need to accept some of the UI things and leave them to be, we cant be 100% demanding same kind UI for everywhere.
I guess it was mentioned before, but I’d like an instant preview instead of save: Especially changing visuals it is nice if they are instantly applied, so I see their effects in real. But, I’d like to explicitly acknowledge them, to go safely back to the old way.
I guess the new KDE 4 Konsole does it in this way.
I can see why implicit save is better from a general perspective: it is just more natural. Most items around us work with that principle or metaphor: light switches, cars, ovens etc. (Microwaves do not, and some people found that very confusing in the beginning.)
As already mentioned, there are three problems with implicit save. You want a role back option - which adds complexity. You need to highlight the fact that implicit save is in effect, and there is no established way of doing that yet (no, the lack of an [Apply] button is not good enough). And you have to avoid any harmful settings, due to a mistake or because of inconsistencies between several interacting settings.
Maybe a role back option at the top of the settings window would do the trick, together with some logic that prevents bad settings. If that gets too complicated, implicit save is probably not appropriate anyway.
One more idea: if you do not have implicit save, it may be useful to show the current settings - contrasting with the new settings. This is a UI design challenge, but it would be quite helpful.
@jospoortvliet, @Jucato: I think implicit save can be even more dangerous when working with documents rather than settings. We have been trained for years that computers only save the changes when we click “Save”. Instant saving is very likely to lead to accidental changes to documents on disk. Saving the session, including edits, in some separate place, allowing saving to the real document when reopening, is an interesting idea (is that what jospoortvliet was suggesting?), but I think it also has an extremely high potential for confusion (”Why doesn’t my friend get my latest changes to the document when I e-mail it to him?”).
Instant apply of preferences is a good idea, though I agree that it can be anoying when the application isn’t applied smoothly (such as window decorations). However an Out/revent is definately needed, so that I would feel comfortable in exploring.
Instant apply of settings would agree is just asking for trouble…
Implicit save: the first thing my parents asked me when using a word-processor was: “why do I have to save my document? Is it in danger?” They weren’t kidding, the just didn’t understand how the document/file metaphore breaks because of the transient nature of online memory on a computer….
One of the things I’m hoping to explore with KDE 4 is a move away from the files metaphore: I work on a document (a letter, or a picture) and then I can put it away in a folder and get it back later. I don’t have to “save” it. When I’m working in the physical world, with paper, that’s how it works. It should be the same on a computer.
@Mike
Yes, I like that idea. So if I click on my text file it loads all the actions (think kwrite or openoffice) at the point at which I had left off, likewise if I click on a photo it either loads gwenview or digikam depending on which was being used on it when I closed the file last. And I think the history rollback like in Vim7 is a lifesaver and would be great if it carried across work sessions and was enabled in all kde apps.
Bob Swank.
@Colin: Ah, well I guess many GNOME developers don’t know that because it’s used in almost every type of editable dialog.
@Bruce: Thanks for the blog link. Besides “This is the way we do it in GNOME”, I didn’t get an answer as to why GNOME uses implicit save. The last idea with the Undo, Close, and Apply button seems to be a better design than what they are using now.
@Vadim: Clear means reset the form, not revert back to original defaults (whether that is what it actually does, as programmed by the developer, is another story).
@jldugger: What Revert is supposed to do has been something we periodically talk about with no solution in KDE Usability. It started out as restoring factory defaults, but whether it is implemented that way is inconsistent. In some cases, it reverts back to the previous saved session, which isn’t so bad. The inconsistency is what makes Revert suck and hard to understand.
@Benjamin: in System Settings there are preview widgets, they aren’t environment previews like in GNOME.
@klaatu: Exactly why creating guidelines would be extremely hard. Even then, It would still require governance in case developers or designers still don’t understand how to use it.
@everyone: It seems like many of you dislike implicit save in the same same cases and for the same reasons I state it doesn’t work well. I would like to reiterate: this is not something I would recommend for configuration dialogs, but instead would like to see how it could be used in the way it is used in KNotes (which, I think many of you seem to like). Implicit save is good for “building” things, and an application in plasma could be the Add/Remove Plasmoids dialog. Also, Plasmoids tend to deal with a lot of ephemeral data, and so that is why I thought the application could be most useful there. Thanks for your thoughts.
Or, stop making mistakes. If you are able to accomplish those 5-10 clicks to screw your theme up, why aren’t you able to revert? Especially as reverting in for instance the theme selection is one click away constantly, in a native feeling way. “Oh I didn’t like this, going to change it back.” You KDE scum shouldn’t attempt to apply anything you (don’t actually) know about usability into any actually usable environment. Go away, you just do more damage than good.
@Kevin Kofler: “We have been trained for years”, and that is the problem. A formed habit doesn’t make the habit valid or sensible. It only makes it harder to correct if it’s wrong. And this “habit” has been questioned and “refuted” as early as 1995, when Alan Cooper’s book, “About Face”, was first published. This is where I’m getting the idea from.
We’ve been trained for years to click on the Save button, only because an implementation detail (the program explicitly calling a save() function) has been imposed on the user interface and the user. Casual or new users to computers don’t have that concept unless they are told. They expect that once they’re done writing a document, it’s done. Just like as you would when writing a real document on paper. There simply is no “save”. You might erase and edit some parts of the paper before submitting it, but that’s more of an “undo” than a “save”.
In fact, we’re actually dependent on “implicit saves” when it comes to autosaving and recovering our work from crashes. So why not take that one step further? To me, an explicit save in a “content-creation” app would be the exception, not the rule. It’s a sort of “I want you to save this state at this particular time that I want to”, but more as a personal mental note that I’ve reached a particular milestone, not as a necessity to actually write changes to disk.
But again, this won’t really work smoothly without a sensible and powerful undo and, I might add, revision history system. At the moment, the best example that comes to mind is Google Docs (which I’ve recently been playing with). It still has those explicit Save buttons, but it does 1. save changes at some interval (for example if you’ve made a change and paused) and 2. provides some revision history that lets you see and rollback changes.
@seele: sorry for taking over your blog :P
What I did in Kasbar was to have instant-previews of the settings (ie the appearance etc. changed immediately), but the settings were not made persistent unless Ok was pressed. Pressing Cancel would roll back all of the changes made.
I am a gnome user and I think implicit save is awesome but without a Cancel option it’s completely the opposite of awesome. I am one of the users you mention who make mistakes. I guess most people don’t but I am human. I really think a Cancel button would make Gnome much more user friendly.
Absolutely hate instant apply with a passion. It means that if you change any settings or preferences and don’t like what you’ve changed you have to remember how to revert it back manually. It’s something Gnome seems to have pulled from OS X because it’s OS X, but they haven’t understood the implications of where they’ve applied it.
For some things instant apply is a good idea, but then, you should probably have some sort of preview to give users an indication what will happen in relative safety.
Let’s face it. Lazy programmers implement auto-apply. It’s so much easier because you don’t need an
Let’s face it. Lazy programmers implement auto-apply ;)
It’s so much easier because you don’t need an intermediate layer for the settings-data. Often you can directly connect a valueChanged-signal to a target without some extra model.
But some applications like Inkscape and Scribus really need auto-apply, e.g. for changing object attributes on the canvas.
I remember an Windows application which offered an auto-apply-checkbox (hmm CorelDRAW?). This was great in many cases.
@Jucato,
Regarding a revision history system…well, I don’t know how it would be implemented but I’ve thought that a SQLite equivalent of say svn or git would be a good idea to have. Something you don’t really need to be an expert in using but would “just” be there in case you need it.
Sorta like Apple’s TimeMachine or ext3cow (if it’s become remotely useful lately…).
@Jucato: What you’re missing is that the vast majority of computer users this day are _not_ “Casual or new users to computers” (well, “casual” maybe, but not so “casual” as to never have used a word processor which requires saving and not to have gotten used to it).
I consider this a major flaw in many usability studies: they explicitly screened for users with no prior computer experience, and then came up with revolutionary changes like what you’re suggesting. The big problem is: that type of changes confuses the heck out of everyone who ever used a computer before! And it’s not just “technical” users you’ll confuse, those are just one vocal group which will loudly complain about such changes, but they by far aren’t the only ones affected. Just look at how “non-technical” users reacted to KDE 4.0’s implementation of desktop icons: the main complaint wasn’t that it was buggy, but that it acted very differently from how they expected a desktop to behave. (Hopefully the KDE 4.1 FolderView plasmoid helps there.) They are the group who gets confused most easily and who adapts most hardly.
In this case, implicit saving will break a use-case many “non-technical” users use: they want to do temporary changes to a document, print them, but not modify the original document. So they do the changes, print them and then close without saving. (Yes, to many “non-technical” users, what counts is what is on paper, not what is on the disk.) I can already hear them screaming: “What? That paragraph I deleted from this week’s shortened version of the document is now gone forever?! But I’ll need it in a few months!” If you ask what types of documents would this apply to, a few examples: CVs, biographies, tests/quizzes/exams, … So implicit save in document processors sounds like a quick recipe for unexpected data loss to me.
+1 for Implicit Save from me :-) (the Mac way, btw, with “Apply” buttons where it makes sense)
omg…
so many…many comments…
but -1 implicit save in all system dialogs
it needs to stay in program dialogs such as notepads but it’s a toy
changing proxy settings isn’t “natural” for instance, and requires thought, no implicit save
changing visual settings could potentially lock them out of a usable viewable interface, implicit save with automatic 30 second revert as in most screen resolution dialogs, or no implicit save
truth be told
implicit save scares me, because it scares non-technical users anytime they ask “what just happened?” because they clicked something…i.e. it’s not an absolutely intentional act
it scares them…
ANYWHO!
@Kevin: If someone is explicitly screening for users with no prior computer experience for a usability test, they don’t know what they are doing. You want to recruit participants of an actual user group (or multiple user groups if they exist) of the product you are testing and research questions you want to answer. So for example, testing an administrative function on a newbie user is useless — you want to test an actual administrator.
@Paul: If it scares non-technical users, why do Macs see such an increase in adoption rate? It shouldn’t be that high if Mac OS X was a scary OS.