Closed Bug 962502 Opened 7 years ago Closed 7 years ago

[UX] Better styling for "unstyled" form widgets

Categories

(Firefox :: General, defect)

29 Branch
x86_64
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 31

People

(Reporter: phlsa, Assigned: mmaslaney)

References

(Blocks 2 open bugs, )

Details

(Whiteboard: [ux] p=5 s=it-31c-30a-29b.2 [qa-])

Attachments

(1 file)

While the normal form widgets in Firefox look good, as soon as you manually change one CSS property, they degrade into and "unstyled" state that looks extremely dated.
Even worse, some parts of the widgets can't even be styled manually. This means that for example a drop down menu with custom styling will always have an ugly button and some weird bevel around the pop-out.

Having better defaults and fallbacks here will make the web a lot prettier.

Here's a page where you can see how sexy the unstyled form widgets are:
http://people.mozilla.org/~shorlander/files/html5-forms/form-controls.html
Attached image Dropdown menu
Here's a screenshot of what a partially styled dropdown menu looks like. Notice the button and the border.
Assignee: nobody → mmaslaney
I think the input[type="range"] should also have a simpler unstyled styling. I don't think everybody will think of removing the background-image for the handle.
(In reply to Tim Nguyen [:ntim] from comment #4)
> How do you think of this :
> http://ntim.altervista.org/FirefoxUX/forms-refreshed ?

What*
Great work, Tim. I'm going to use this for my framework.
The styling of default form widgets could be improved too. For example Google Chrome has a slightly different styling even for default.
(In reply to Guillaume C. [:ge3k0s] from comment #7)
> The styling of default form widgets could be improved too. For example
> Google Chrome has a slightly different styling even for default.

We currently take  the styling from the system. Chrome uses it's own "Aura" UI, drawn by it's native code.
One form element I noticed was not found in the examples was the select box. The dropdown doesn't look too nice and doesn't fit in with the system's look either. Here's an example: https://people.mozilla.org/~vtsatskin/tmp/selectbox.osx.annoyance.png
(In reply to Valentin Tsatskin [:vt] from comment #9)
> One form element I noticed was not found in the examples was the select box.
> The dropdown doesn't look too nice and doesn't fit in with the system's look
> either. Here's an example:
> https://people.mozilla.org/~vtsatskin/tmp/selectbox.osx.annoyance.png

I'm afraid what you want is a bit more complicated since the select dropdown isnt drawn with css
(In reply to Tim Nguyen [:ntim] from comment #10)
> (In reply to Valentin Tsatskin [:vt] from comment #9)
> > One form element I noticed was not found in the examples was the select box.
> > The dropdown doesn't look too nice and doesn't fit in with the system's look
> > either. Here's an example:
> > https://people.mozilla.org/~vtsatskin/tmp/selectbox.osx.annoyance.png
> 
> I'm afraid what you want is a bit more complicated since the select dropdown
> isnt drawn with css

Given how widely used styled dropdowns are, we still need to fix this. It's not only the dropdown itself that looks less than great, it's also the box it usually originates from (see comment #1)
Summary: Better styling for "unstyled" form widgets → [UX] Better styling for "unstyled" form widgets
Whiteboard: [ux] p=0 → [ux] p=5
Status: NEW → ASSIGNED
Whiteboard: [ux] p=5 → [ux] p=5 s=it-31c-30a-29b.2
Whiteboard: [ux] p=5 s=it-31c-30a-29b.2 → [ux] p=5 s=it-31c-30a-29b.2 [qa-]
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
David, comment #12 shows the proposed changes for buttons, input, radios, and checkboxes. Note that the proposals have the dimensions of these elements changing, as well as introducing some color (a light blue).

Should we be concerned with web compatibility here, and are there any ways to mitigate this while still pushing forward with an updated design?
Flags: needinfo?(dbaron)
(In reply to mmaslaney from comment #12)
> Buttons and input:
> 
> http://people.mozilla.org/~mmaslaney/widget/firefox-html-forms.html
> 
> Radio and Checkbox:
> 
> http://people.mozilla.org/~mmaslaney/inputs/index.html

Looks good ! Just one concern though, the dimensions/padding of the elements should remain intact in case web developers worked the original small dimensions. Which is mainly why in the my first design, I didn't put much padding. 

Also, I would avoid putting any padding on the input[type="color"] since it makes the swatch smaller.
(In reply to mmaslaney from comment #12)
> Buttons and input:
> 
> http://people.mozilla.org/~mmaslaney/widget/firefox-html-forms.html
> 
> Radio and Checkbox:
> 
> http://people.mozilla.org/~mmaslaney/inputs/index.html

Btw, can you also provide the select dropdown boxes styles ? That was the first concern of the bug.
I also think that those look great, Michael!
I just fear that using color could have lots of side effects because web designers didn't design for those elements having colors so far. After all, this would become the default style for every web page out there.
Updated (sans color)


Buttons and inputs:

http://people.mozilla.org/~mmaslaney/widget/firefox-html-forms.html


Radio, Checkboxes and Dropdowns:

http://people.mozilla.org/~mmaslaney/inputs/index.html
(font determined on a system level)
(In reply to Philipp Sackl [:phlsa] from comment #16)
> I also think that those look great, Michael!
> I just fear that using color could have lots of side effects because web
> designers didn't design for those elements having colors so far. After all,
> this would become the default style for every web page out there.

Color isn't an issue, the native inputs already have colors. Padding is the most important issue here I think.
Here are the two versions we have currently:


Added padding and no color

http://people.mozilla.org/~mmaslaney/widget/firefox-html-forms.html
http://people.mozilla.org/~mmaslaney/inputs/index.html

Less padding and blue highlights:

http://people.mozilla.org/~mmaslaney/widget_v2/firefox-html-forms.html
http://people.mozilla.org/~mmaslaney/inputs_v2/index.html


From a visual perspective, I prefer our unstyled interaction elements to have more padding with blue highlights, as to improve the "perceived simplicity", but I do realize this may cause a break. Is it worth it? I'm not entirely sure. Many would have to adapt to the new, but IMPROVED changes.

Interaction wise, I believe both perform the job required of an "across the board" compliant set of interaction elements. We can even play it safe by using less padding and keeping our colors strictly B&W.
Whiteboard: [ux] p=5 s=it-31c-30a-29b.2 [qa-] → [ux] p=5 s=it-31c-30a-29b.3 [qa-]
Flags: needinfo?(philipp)
I think the padding on dropdowns etc. shouldn't be a problem since it can be styled. So we should go with the visually more pleasing version.
Not sure about the increased size of checkboxes and radio buttons. Those almost doubled in size in contrast to the old widgets.
Perhaps the best way to move forward is to implement the best case for now and then adjust accordingly while this is in Nightly.
Flags: needinfo?(philipp)
I like that idea.

Let's use the "Less padding and blue highlights" version. The padding is still generous, and limits the danger in scaling.

http://people.mozilla.org/~mmaslaney/widget_v2/firefox-html-forms.html
http://people.mozilla.org/~mmaslaney/inputs_v2/index.html
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Whiteboard: [ux] p=5 s=it-31c-30a-29b.3 [qa-] → [ux] p=5 s=it-31c-30a-29b.2 [qa-]
Target Milestone: --- → Firefox 31
Blocks: 997190
Clearing needinfo in favour of the one in bug 997190 regarding implementation.
Flags: needinfo?(dbaron)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #13)
> Should we be concerned with web compatibility here

yes

> and are there any ways
> to mitigate this while still pushing forward with an updated design?

 * stay within the range of sizes that other browsers are within
 * carefully consider how other styles applied on top of the defaults behave
You need to log in before you can comment on or make changes to this bug.