[Kimchi-devel] [PATCH 3/3] Use action verb as the main button's label

[Hongliang Wang]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140516/1fffd1fa/attachment.html>