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)
> 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
Go ahead! Either "Save" or "Submit" is fine for me.
> Let me explain the naming rule of #guest-edit-button-save. It
> 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
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
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.