Re: emelFM2 pre-release available

  • From: <tpgww@xxxxxxxxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Fri, 25 Jul 2008 09:59:15 +1000

On Thu, 24 Jul 2008 20:29:03 +0200
"Liviu Andronic" <landronimirc@xxxxxxxxx> wrote:

Excellent, this is the sort of feedback we want. Keep 'em coming in like this, 
please.


> I've just tried the pre-release, and at least emelFM2:configuration
> feels counter-intuitive. "Apply" applies and closes the dialogue,
> while "Proceed" applies and keeps the dialogue open. In all
> applications that I can think of at now, "Apply" applies and keeps the
> dialogue open.

I understand that this is common. IMHO "apply" is essentially about doing 
something to selected item(s), and so is "apply to all". I still like the 
notion that these 2 should have the same consequence except for different scope.

 More, "Proceed" has the connotation of "continue",
> "move on" from this dialogue.

Yes, and also commence, start (i.e. do something but do not end). This remains 
the label about which I personally am least comfortable. I added tips to the 
effect "apply and continue", to help a little bit.


 To me, "Apply" "Discard" and "Commit" or
> "Accept" would feel better.
> 
> A minor issue: "Discard" lacks the "Cancel" icon. Is this intended?

Discard button uses gtk icon GTK_STOCK_DISCARD if that's supposed to be 
available (since 2.12). Apparently it's not yet always provided in themes, even 
when it should be.


> For the user input: "Keep" and "Apply". Same intuitiveness issue:
> "Cancel" or "Close" and "Commit" or "Accept" would feel better. As for
> "Keep" and "Delete", this feels the good combination.

In english language at least, "cancel" implies changing something already done. 
That "something" could be the commenced change-process, or the change arising 
from that process. Up to now, e2 cancel-buttons have been for either or both of 
these cases. But now, I've tried to distinguish between change ("keep" etc) and 
change-process ("stop", "abort" etc). So ATM I've not used "cancel" anywhere.

Except for gtk file-chooser dialogs (where there's limited control over the 
buttons and labels) I've used "stop" for terminating multi-item operations, and 
want something else for single-item operations, stronger than "close" (that's 
for contexts where no operation is pending, like file-info dialog).

cease ? (something already started, another 'c' mnemonic) finish, halt 
(something already started) ?

Maybe one of the above instead of stop, and stop instead of abort etc ?


> Is it intended that emelFM2:configuration uses "Discard" and other
> configuration dialogues (like bookmarks or file types) use "Abort".

Config dialog has "discard" because until the dialog is closed, changes made 
via the dialog can be undone. So in fact, you would "discard" any changes 
already mode. But in general, dialogs don't support undoing, hence something 
else is needed there.


 It
> may be a bit more subjective, but "Abort" feels strong. Wouldn't the
> good old "Cancel" do the job in most cases where both "Discard" and
> "Abort" (and "Keep"?) are used? The latter would also apply for "Stop"
> (in file.pack): "Stop" archive creation and "cancel" archive creation
> seem as correct, while the average user would expect the latter, I
> suspect. "Cancel" would also achieve a certain consistence between
> various dialogues.

I understand that things can seem bad merely because they're different from 
previous situation. Such difference is not _necessarily_ a bad thing, of 
course. I'd want any "re-learning" to be minimal and easy.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: