Page MenuHomePhabricator

Too much left padding in search box
Closed, ResolvedPublic

Assigned To
Authored By
Esanders
Mar 11 2016, 10:55 AM
Referenced Files
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

Description

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:

pasted_file (87×518 px, 4 KB)

Proposed (even .5rem all around):

pasted_file (92×518 px, 4 KB)

Event Timeline

debt triaged this task as Low priority.Mar 14 2016, 2:07 PM
debt added subscribers: MSyed, debt.

Hi @MSyed - can you take a look at this suggestion and comment? Thanks!

Please ping @Volker_E . These rules were defined by the UI Standardization team.

@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.

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:

pasted_file (63×268 px, 4 KB)

@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

https://gerrit.wikimedia.org/r/278275

Change 278275 merged by jenkins-bot:
Make search input padding even

https://gerrit.wikimedia.org/r/278275

debt claimed this task.

Closing and this will be part of this production update: https://phabricator.wikimedia.org/T130755