Thorsten, >>> http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ >> >> Somehow I do not know what structural problem you are trying to >> solve for one million users. > > The current Save Changes dialog tends obscure the image. It is a modal dialog situation: we need a decision now. The dialog is a (hopefully) friendly reminder that some of your last steps were not saved. > If users would be damn sure about closing a window with unsaved > changes every time, there would be no need for asking back. So > the user should be able to see _what_ he's about to save or > discard. The image itself is likely to be much more informative > than filename and "changes from the last x minutes". I find this stress on looking at the image very worrying. What drives the decision is the state of mind of users: "these changes in the last xy minutes were useful/useless." Either this state of mind is there, because the one just worked on the file, or it is not there, because one worked yesterday on the file. In that case I am not going to invite anybody to investigate that within a dialog. Back off (Cancel) and investigate with all of GIMP's capabilities, I say. If I were to evaluate/improve the dialog, I would start with that state of mind. > BTW, from my own experience, hitting Save when the prior version > was actually better and something to be kept is much more of a > danger than not saving something you wanted to keep. The first thing you have to do when you want to help one million users is to forget about yourself. > Now that I write about it, another idea comes to my mind: > The Save Changes window could have a toggle to display the last > saved version. > > The dialog is very closely tied to the image window, but still > presented as its own window. Transforming the image window into > a Save Changes window is as clear as you can get about the > relation. I do not think so. First you have to realise that this "decide to save the unsaved" is an error scenario, a non-task if you will. You are building a full-fledged UI for a task that does not exist on users' radar screen. That is a misfit. > One can get rid of the visual noise of a dialog with titlebar > and border and avoid obscuring the image in one go. So this > removes unnecesary elements from screen, something that I think > is quite helpful if you deal with several image windows. Having the dialog there is not a long-term situation, no? It may be jarring, but it needs to be, for a transient moment. It is actually architecturally very worrying that you try to harmonise the dialog into the main window. It does not lessen the interruption in users workflow, and the overall presentation is more of a misfit of what is actually going on. "Somehow I do not know what structural problem you are trying to solve for one million users." --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
