Review Request: Fix Inconsistencies with Organize Files Dialog when canceling Dialog

[Philipp Schmidt]

> On Jan. 8, 2011, 11:43 a.m., Sergey Ivanov wrote:
> > I think that It's a bad idea to apply any settings when user press Cancel, so storing Format Presets should stay in onAccept slot. 
> > Agree with second statement.
> > 
> > And finally this patch has nothing in common with mentioned Bug Report.
> 
> Philipp Schmidt wrote:
>     That's the thing. Pressing "Save preset" gives the impression that the preset has indeed been saved. It has happened to me a couple of times that I created a new Preset, checked the preview, found something wrong with my tagging, pressed cancel, corrected the tags and then wanted to use the saved preset again which was gone... The way I see it both ways are essentially wrong from a certain Design perspective. 
>     I am by no means a GUI or Usability expert (my expertise comes down to 3 lectures regarding User Interface Design and Consistency in the user interface and some small Project in University). But what I learned is that you should make Dialogs as unambiguous as possible and with respect to that the discrepancy between the *strong* implication of the preset being "Saved" and then again not when pressing cancel is very hard to resolve.
>     
>     A solution to that would be to add a third button like "Do not move files but save settings" (Better wording needed :D) or to remove the cancel button altogether and remove it with something like "Close" that does not imply that the settings are discarded and save them anyway... Of the two the first option would probably be preferable as it doesn't remove the Deesktop Paradigma that Dialogs should have a cancel button that aborts everything it does.
>     
>     With respect to the bugreport: You're right, this review request has nothing to do with it, but could you then please comment on the bug why you reopened it? When I was checking in IRC with the person who apparently initiated that I found all these inconsistencies but not that the bug was still there.
> 
> Sergey Ivanov wrote:
>     Well, I still don't like idea to save settings before user pressed Ok. But I agree that "Save preset" button doesn't do what user can expect from It, so probably we should just rename It to "Add preset" or something?

"Add Preset" would do it. I am now using 2.4.0 with German translations and there the ambiguity does not exist as the button is labeled with the German word for "add".

I would additionaly like to add a button that allows the user to save the settings manually. To preserve space this should be with the normal Dialog buttons like this:
Ok | Save settings and close | Cancel

Would that be ok?


- Philipp


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100321/#review771
-----------------------------------------------------------


On Jan. 8, 2011, 12:12 p.m., Philipp Schmidt wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100321/
> -----------------------------------------------------------
> 
> (Updated Jan. 8, 2011, 12:12 p.m.)
> 
> 
> Review request for Amarok.
> 
> 
> Summary
> -------
> 
> Fixes two errors:
> 
> First: Presets are being saved explicitely, meaning they should persist even when the Dialog is aborted/canceled.
> Second: The state of the Current Collection Directory is saved regardless of whether the Dialog was accepted or canceled. IMO it should only be saved like all other values when it is accepted.
> 
> 
> Diffs
> -----
> 
>   ChangeLog 3c337d1 
>   src/dialogs/OrganizeCollectionDialog.cpp b7d7850 
> 
> Diff: http://git.reviewboard.kde.org/r/100321/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Philipp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20110116/854367ea/attachment-0001.htm