...

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

...

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

On 15-05-2014 00:30, Hongliang Wang wrote: 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. 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

On 05/16/2014 01:37 AM, Crístian Viana wrote: 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.