On 05/16/2014 01:37 AM, CrÃstian Viana
wrote:
On 15-05-2014 00:30, Hongliang Wang wrote:
It's an interesting topic here.
I agree :-) I wish we had more discussions like this here.
Take edit template for example. The flow is:
List templates =>
Select a template to edit by clicking the "Edit" Button
=>
Edit template window is open, and user changes some fields.
=>
Click the "Save" (Or "Submit") Button to save (or submit)
changes.
Notice that "Edit" means the user is about to edit the template,
so "Edit'" Button should trigger a pop-up window to allow user
to change some fields.
And "Save" Button is for saving user's changes to server. So I
think it's reasonable to use these 2 labels for these 2
different purposes.
You're right, that's another way of labeling the buttons. But this
is also not used in throughout Kimchi and that's what concerns me.
Some windows have the "Save" button, some windows have the same
label as the button which triggered it; we need a consistency.
Whichever way is fine for me, as long as it looks consistent. I
don't like the idea of having each dialog of the same application
designed differently, even if subtly, which is how I feel it is
now.
I also thought about always using "Save" as the buttons' labels,
as you said, and that sounds totally fine for me. If we think this
approach is better, I'll use this approach on the next version of
this patchset.
Go ahead! Either "Save" or "Submit" is fine for me.
Let me explain the naming rule of
#guest-edit-button-save. It follows name space style like Java
package mechanism.
guest-: It's within the scope of guest page
edit-: It's within the scope of guest edit window
button-: It's a button within the scope of guest edit window
save: It's a button named save
So please remain the original ID string of the button. If we
will introduce another button in the future, we can simply name
it "#guest-edit-button-newid".
Thanks for the explanation, it makes total sense. I just blindly
removed the "save" string from the variable name, I should have
left "edit" instead, which is the new label I'm using.
But, again, this variable naming rule is also not consistent
throughout thel Kimchi code. For example, the submit button of the
dialog "Create Storage Pool" has an id="pool-doAdd". According to
this naming rule, it should be something like
"storage-add-button-create". In this patch, I was just trying to
remove the reference to "save", which was the label I removed. I
agree I should have left the new label on the ID, "edit". But I
think this is a different discussion, regarding coding
consistency, which [definitely] needs to be addressed in future
patches. I'll use "guest-edit-button-edit" in the next version of
this patch to keep the style you mentioned.
Agree. The naming rules is totally not consistent because we didn't
propose one unified. I also think we need have a unified naming rule
(as well as same user experience through out Kimchi, including
windows, dialog s, buttons, operation behaviors, etc.). Maybe we
need propose a coding/designing guideline documentation for future
code. If we are planning to, I'm glad to be involved in.