At small font sizes it can make sense to have more horizontal padding than vertical, but in this larger search box it looks like there is room being left for something:
Proposed (even .5rem all around):
Esanders | |
Mar 11 2016, 10:55 AM |
F3648831: pasted_file | |
Mar 17 2016, 10:57 AM |
F3648793: pasted_file | |
Mar 17 2016, 10:45 AM |
F3648801: pasted_file | |
Mar 17 2016, 10:45 AM |
F3648811: pasted_file | |
Mar 17 2016, 10:45 AM |
F3648798: pasted_file | |
Mar 17 2016, 10:45 AM |
F3648806: pasted_file | |
Mar 17 2016, 10:45 AM |
F3614332: pasted_file | |
Mar 11 2016, 10:55 AM |
F3614340: pasted_file | |
Mar 11 2016, 10:55 AM |
At small font sizes it can make sense to have more horizontal padding than vertical, but in this larger search box it looks like there is room being left for something:
Proposed (even .5rem all around):
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Make search input padding even | wikimedia/portals | master | +5 -5 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | debt | T130755 [EPIC] Portal Production release: bug fixes and small updates | |||
Resolved | debt | T129636 Too much left padding in search box |
@JGirault @Esanders We haven't had a input field at big font-sizes defined so far in M101, the padding should be 1em left and right for small input fields, that's correct. If we're going away from that rule, I need to stress that we might run into a situation where the padding of a button label in the next line is not left aligned with the text input value any more.
Buttons are rarely left aligned close to text boxes, so I don't think there is an expectation that labels align with input text.
I don't think it's helpful to refer back to the monolithic design boards such as M101. Creating giant Photoshop files that exist on one user's laptop, or one team's Dropbox, is the antithesis our our collaborative process. Our style guide is constantly evolving and has to respond to real world use cases. OOUI differs from that guide in many sensible ways that have not been reflected in it, for example it already uses even padding on all text input widgets:
@Esanders Big input fields are so far rarely used. But if, for any reason, we have a big input field with different padding where there are small inputs or buttons in the next row, we have to weigh in the consequences. I'm in no ways opposed to add a modified big input field to the widget collection, as long as we also look upfront into possibly connected problems and broadly agree that modifying padding is the best possible way.
To your second point:
What do you mean by monolithic?
From a design perspective it is more than useful to refer to boards like M101 to have an overview of the affected widgets of seemingly small changes in greater context.
The comparison of antithesis of the collaborative process is IMO unfair. Not every designer or page designer has access to Git and Grunt either. UI Standardization team made very clear where to find our work and how to get involved. And while M101 is currently not reflecting some of the latest changes, it has been evolving around discussions with OOjs UI developers as well and it's continuously improving.
Actually having this discussion is an example and the outcome will be reflected there! Let's work on the process to reduce hurdles for participation.
monolithic - "large, ... indivisible, and slow to change".
I'm not saying designers need to write patches or build code, but the can still partake in the "change"/"patch" process. There should be /one/ canonical source of the current style, and changes to that are processed as tickets that clearly describe each change being made. Currently M101 appears to be developing as a separate branch to the real world, and we are then left trying to resolve all the conflicts. It also has no real product context, which leads to issues like the oversized radio buttons.
To get back on topic though:
We don't need "modified big input widget" - OOUI already uses even padding so just stick with that. Even in the rare case that we left-aligned an action button I don't think there is an expectation for user input text and interface text to align (e.g. in the screenshot above, the label has 0 left padding).
Change 278275 had a related patch set uploaded (by Esanders):
Make search input padding even
Closing and this will be part of this production update: https://phabricator.wikimedia.org/T130755