Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1166055

Summary: [virt] checkbox position (left/right) inconsistency
Product: [oVirt] ovirt-engine Reporter: Michal Skrivanek <michal.skrivanek>
Component: Frontend.WebAdminAssignee: Tomas Jelinek <tjelinek>
Status: CLOSED WONTFIX QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: bugs, lsurette, mgoldboi, michal.skrivanek, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone: ---Keywords: FutureFeature, UserExperience
Target Release: ---Flags: tjelinek: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-16 13:43:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Skrivanek 2014-11-20 10:53:56 UTC
see New VM dialog where it's most visible, but it's widespread everywhere

checkboxes are either in front of the label or on the right hand side (aligned with combo boxes for other options)

New VM - General tab - [x] Stateless 
vs
New VM - Initial Run tab - Use Cloud-Init/Sysprep [x]

we should decide and consistently use only one style. Let's agree on one. (I'd favor "xyz    [x]")

Comment 1 Einav Cohen 2014-12-04 20:54:10 UTC
[I changed 'ux' Whiteboard to 'virt'; also modified summary accordingly - no point in documenting this cross-GUI issue in a single BZ if multiple people from multiple teams should take care of it; I added the 'UserExperience' Keyword in order to reflect that this is a user-experience issue. If the BZ assignee is willing to take care of all check-boxes across the entire application - feel free to change Whiteboard back to 'ux'; we can also make this a 'ux' tracker bug and open dependent bugs - whatever makes sense;]

(In reply to Michal Skrivanek from comment #0)
> see New VM dialog where it's most visible, but it's widespread everywhere
> 
> we should decide and consistently use only one style. Let's agree on one.
> (I'd favor "xyz    [x]")

actually, this layout is generally discouraged. see [1] for example. 

the convention should be "[x] xyz". 

in order to utilize the "[x] xyz" convention and still maintain a reasonable look-and-feel for the horizontal form layout [2] that we are using in our application [3], we should put the check-boxes along with their labels in the field "column" (i.e. on the right-hand side of the dialog), rather than the label "column" on the left (see [4] [5] for good examples). 
there can be a label in the label "column" (i.e. on the left) *in addition*, as depicted in [2] (see "Field Label" in the "Field Set Label 3" section of the dialog mock-up), if makes sense (typically more suitable for check-box groups rather than single check-boxes). 

all of the above is correct for radio-buttons as well. 


[1] http://ux.stackexchange.com/questions/5080/should-checkbox-labels-be-to-the-right-or-the-left

[2] https://www.patternfly.org/wikis/patterns/forms/form-layout/#horizontal-form

[3] we are not using the horizontal layout correctly at the moment, since form field labels are currently aligned to the left, rather than to the right; however, this is fairly irrelevant to this BZ. 

[4] http://alexking.org/blog/2005/07/18/css-checkbox-label-positioning

[5] http://getbootstrap.com/css/#forms-horizontal

Comment 2 Michal Skrivanek 2015-06-05 13:19:53 UTC
still want to consider this "soon"

Comment 3 Tomas Jelinek 2015-08-24 12:08:02 UTC
this is a big change, not going to make 3.6 - pushing to 4.0

Comment 4 Red Hat Bugzilla Rules Engine 2015-11-30 20:55:06 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 5 Moran Goldboim 2016-03-27 09:18:07 UTC
postponing to next version due to capacity.

Comment 6 Yaniv Kaul 2017-11-16 13:24:38 UTC
(In reply to Moran Goldboim from comment #5)
> postponing to next version due to capacity.

Can be closed in 4.2?

Comment 7 Michal Skrivanek 2017-11-16 13:43:03 UTC
give up waiting for it? It won't make 4.2