HTML form widgets need polish

VERIFIED DUPLICATE of bug 74058

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED DUPLICATE of bug 74058
18 years ago
17 years ago

People

(Reporter: german, Assigned: german)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-][NEEDINFO][UE1])

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
I know this dicussion has come up before. We need to get this fixed before beta3
This widget set looks sloppy. Need consistent level of quality for widgets. 

3 avenues we can take for HTML form widgets:
- Platform specific, 
- skin conforming 
- web look, same across platforms and skins.

right now do we do sort of the third approach which is a bad joke copy of Win32 
widgets. We need to at least improve the quality and usability.
(Assignee)

Comment 1

18 years ago
nominate for nsbeta3
Keywords: nsbeta3
We need to be more specific about what the task will be for beta3.
Which form elements look bad? What needs to be changed to make them look better?

Adding [NEEDINFO] to status.
Whiteboard: [NEEDINFO]
(Assignee)

Comment 3

18 years ago
first of all we need to decide which of three path we need to go- this will 
happen shortly.
Based on that we can determine the deficiencies in the current implemnentation. 
E.g. if the goal is to make them look like windows than we can easily see the 
delta by comparing the classic skin widgets on windows with HTML widgets. If 
the goal is to make it like 4.x than yes the widgets need to be platform 
specific, this is not even close right now. 

Specific design examples that come to mind (hiliting why we seem to follow a 
bit of each of the strategies above, but none properly):
- most widgets have coarse, blocky 2 pixel borders
- mouse over feedback that looks like neither specs or OS based and only on 
some widgets but not on others
- drop down menu areas (html:select) have indented 2px borders
- radio buttons and check boxes look particularly bad, ie rounding is 
unpolished, checkboxes are indented when not moused over (if we can't get those 
to look good with CSS we should use an image)
- base colors are hard coded to e.g. #CCCCCC which makes them look a bit like 
modern skin
more...

Comment 4

18 years ago
cc'ing myself since I've been working on this lately (agreed that the current 
widget set is a sloppy-looking joke)

- I removed the hover effects for all widgets.
- What's wrong with radio buttons?  I personally feel they look the best of any 
of the widgets right now, and in the normal size are pretty darn close to 
NS4/IE5.

Rod, you can reassign this to me if you want, I'll do some of the work needed 
here.

Comment 5

18 years ago
Premise #1: Learning two languages is harder than learning one. Similarly, 
learning the look and behavior of two widget sets is harder than learning the 
look and behavior of one.

Therefore, usability is maximized where users are required to learn and memorize 
the look and behavior of the lowest possible number of widget sets. Up to now, 
that number has been 1 -- the widget set used by the platform toolkit (except in 
oddities such as media players, e.g. Winamp or QuickTime Player). The same 
widgets were used in the platform, the browser chrome, and the Web.

At the moment in Mozilla, the number of toolkits which need learning is 3, which 
is laughable. (It's 2 in the special case of the Classic skin; but while the 
architecture is such that 3rd-party skins don't automatically inherit from the 
Classic skin, this will be the minority case.)

So, on to German's options.

Option 1 (platform-specific widgets): The user has to learn and memorize the 
look and feel of either 1 or 2 widget sets. 1 if their chosen skin is Classic, 
in which case platform == skin == Web; 3 if their chosen skin is not Classic, in 
which case platform == Web != skin.

Option 2 (skin-specific widgets): The user has to learn the look and feel of 
either 1 or 2 widget sets. 1 if their chosen skin is Classic, in which case 
platform == skin == Web; 2 if their chosen skin is anything else, in which case 
platform != skin == Web.

Option 3 (same widgets regardless of platform or skin): The user has to learn 
the look and feel of either 2 or 3 widget sets. 2 if their chosen skin is 
Classic, in which case platform == skin != Web; 3 if their chosen skin is 
anything else, in which case platform != skin != Web.

So the usability maximizing choice is obviously not option 3. Now to look at 
options 1 and 2 more closely, in the case where the chosen skin is not Classic 
(as it won't be, unfortunately, for the majority of distributed copies of 
Mozilla, i.e. Netscape).
Option 1: platform == Web != skin.
Option 2: platform != skin == Web.

Which of these is the lesser evil? Here you invoke the principle of consistency 
of the closest aspects. Premise #2: If you *have* to know and switch between two 
languages, it is easier to switch between them infrequently (e.g. once every 
minute) than it is to switch between them frequently (e.g. once every five 
seconds).

The user will be switching between {Web content, browser chrome} much more often 
than they will be switching between either {Web content, platform} or {browser 
chrome, platform}. (This is obvious, because the Web content and the browser 
chrome are in the same window!) Therefore it is more important that the Web 
widgets be consistent with the skin, than that they be consistent with the 
platform.

Conclusion: option 2. Web widgets should match the currently-selected skin, and 
they should change appearance when the skin does. (If you can't implement that 
in the time available, though, making them match the platform is much preferable 
to making them match nothing at all.)

PS: Blake, I think the problem with radio buttons is the one described in bug 
28563.

Comment 6

18 years ago
Making the Web widgets match the skin is impossible before we ship.  Until we 
actually convert the HTML form elements to XBL (a huge task), they can't achieve 
the same looks that the chrome widgets can.

Comment 7

18 years ago
In regards to Hyatt's comment, would that not make it equally hard to make the 
widgets match the platform?  Since the HTML form widgets are not XBLified, 
wouldn't ANY change to them be quite time-consuming to implement?
My suggestion is to go with the platform look for form widgets *and* to default
to the Classic theme. It is by far the user-friendliest way.

I see the point in Matthew's comment, but per Hyatt's comment following the
theme is not an option at this time.

(I predict that next week we'll see Mac users complaining about defaulting to
Modern and Mac troubleshooting sites publishing the steps required in order to
switch to Classic. Then the focus will move to the form widgets.)

Comment 9

18 years ago
The HTML form widgets will have a hard time achieving a perfect platform look 
without the aid of XBL.  I do believe radio buttons and checkboxes could get 
pretty close.  Buttons can't.  Selects can't, especially on the Mac.  

I think the eventual right thing to do here is to map the HTML form widgets to 
the XUL widgets using XBL, thus unifying the widget sets.  rods and I have 
talked about this and agreed that there's no way we could get this done before 
shipping.

This doesn't leave us with much in the way of options.  We know we can't achieve 
a native platform look.  I'd argue for a neutral "Web platform" look of some 
kind for NS6, not because I like it the best, but because I believe that - if 
you can't get the native look - you may as well try to produce a 
polished-looking alternative.
(Assignee)

Comment 10

18 years ago
 i agree also for the reason of this is what I think wold work best given the 

reosurces and time we have

Comment 11

18 years ago
Yes, also agree. A L&F across the platforms that does look too close to anyone 
platform is probably the best. Call it a web-ubiquitous L&F....

If somebody does the spec, then I or somebody else can do the impl, also keep in 
mind that the CSS platform colors are now working (i.e. buttonface, etc).
Status: NEW → ASSIGNED

Comment 12

18 years ago
Ouch. Very ouch.

Ok. What do you mean by `the spec'? Would a graphical mockup of each widget 
(drawn at two different sizes, for extrapolation purposes) do? How sophisticated 
could the appearance be? (For example, because the widgets need to be resizable 
and use CSS colors, I assume we couldn't get the sort of subtle shading found in 
Mac radio buttons without using XBL and tinting.) What are the limitations? Not 
just `whatever we can do with CSS1/2', but what does that mean in English? For 
example, does it mean just one level of border (in which case we're pretty much 
stuck with the level of crumminess we have now)?

Comment 13

18 years ago
By "spec" I mean a mock up of what they will look like.

I would have to defer the "look" issues to german, that is his dept. I am 
reassigning this bug to german until we know what "look" he wants. Then he can 
reassign it back to me or to whoever want to implement the "look" in the style 
sheets.
Assignee: rods → german
Status: ASSIGNED → NEW

Updated

18 years ago
Keywords: UE1
Whiteboard: [NEEDINFO] → [NEEDINFO][UE1]

Comment 14

18 years ago
Is there any way to draw, say, a square border around the outside of a widget 
(like win32 IE5 does when a radio button has a focus) ?

Comment 15

18 years ago
Ian has been doing a lot of this sort of thing lately.

Comment 16

18 years ago
This bug refers to several different UI fixes.  Please create separate bugs for 
each piece so we can beta3+ or - each piece.  German and I talked about fixing 
the widgets within web pages (like pulldowns), but this bug also talks about 
radio buttons and other things.  Some of this stuff we need to do now, some of 
it can wait a little while.
(Assignee)

Comment 17

18 years ago
John: we are talking about verey widget on web pages namely:
radio
checkbox
select (popup menu)
textfield
texarea
button etc.					
In this discussion we were looking at the different options and we agree mostly
that with the time we have about the only option is to adopt one look and feel
acroos all web widgets.
In the interest of time I would even be hapy to say the should emulate the win32
look to save time which gives us a 90+ % coverage of our customers (Linux and
Win32) and it would look at least look more polished on Mac). If you do not know
what I mean please take a look at the Classic widgets on Windows and compare
those to the widgets you see on this bugzilla page. I was told these widgets on
the page were designed to emulate Windows. If you make the comparison you will
agree that there is a huge difference in appearance quality.
Especially the unpolished look is very bothersome, like double pixel inset or
outset borders on all the elements, clunky aliased looking radio buttons, 

Comment 18

18 years ago
Sadly marking as nsbeta3- while this sits with German.  These widgets need work 
but German is not going to do the work.
Whiteboard: [NEEDINFO][UE1] → [nsbeta3-][NEEDINFO][UE1]

Comment 19

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 20

18 years ago
*** Bug 58383 has been marked as a duplicate of this bug. ***
Created attachment 18284 [details]
Examples of how the buttons and textarea could look
Buttons and text areas are two examples that look bad.

I think that different themes should only be able to determine the colors of the 
buttons, and the scroll bar in the text areas should be determined by the 
current scheme. This is only if the user chooses to have it that way.

I put up some examples. Possibly, slightly rounded edges would look better.

If these are not possible with CSS - is there a way around this?
Adding myself

Comment 24

18 years ago
adding myself to cc
In Preferences, the widgets look very attractive. I believe that the widgets on 
the HTML should follow that. They should be more rounded, and less boxy. Of 
course, they should be shaded grey instead of blue like in preferences. Also, 
When you select a text box in preferences, it surrounds the text box with 
attractive shading. I think that should be done on the web page too for the 
selected widget.

Comment 26

18 years ago
adding myself to cc

i've played around with forms.css and found a nice way to give the buttons a 3d
look. i don't if it is the correct way to do this, but for the moment it works
for input,select,radio,checkboxes...

i replaced 'border 2px inset color' with...

  border-left: 2px ridge black;
  border-top: 2px ridge black;
  border-right: 2px inset white;
  border-bottom: 2px inset white;

have fun...

Comment 27

18 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Comment 28

17 years ago
I just searched for a bug like this and I'm glad, I found it. Mozilla REALLY 
needs nicer looking HTML widgets for 1.0.
Here are my (humble) opintions:

- Long term goal and perfect world would be:
Two new prefs. One to choose if HTML widgets shall match the current theme or 
the "web standard". Native Looks for Win32 and Mac would be neat to. I don't 
think that this is possible with Linux, cause of Gtk Engines. There is no native 
Linux look.
The other pref should be "apply CSS to HTML widgets". So if I want to have my 
nice theme widgets all the time, I can turn this off.

- Short time goal (would be great to have that before final release):
Simply a polished look. The current looks ugly.
I'm on a Linux box at home, but I would suggest to copy the win32 native widgets 
for those. Just use the widgets of the "classic" theme, they look good.
I think this would be the best decision, cause it would look native for most 
users. Linux users shouldn't care (cause there is no native look). Only Mac 
People would stay behind.
Another possibility would be to create something better looking than the win32 
GUI but I don't think, there is enough time.
So please do a simple polished win32 look. The example attachment looks good.

Mozilla is sooooooo close...

BTW, there is a problem with scrollbars. As you know, they look like the current 
skin. Even in HTML widgets! I think this is kinda stupid. IMHO the "frame 
scrollbars" should match the current theme, but the HTML widget scrollbars, 
should match the other HTML widgets. I know, that this would be a lot of work...
And for Gecko it should be possible to use the native scrollbars of the 
application. For example GtkMozilla should use native Gtk scrollbars for frames 
and windows. Galeon and Nautilus look weird with "modern" scrollbars...
I'm not sure if all this is possible, but it would be so damn great.
This is a very important issue.
Short term idea:
Just improve the widgets for each OS to look better for Mozilla 1.0. They 
should be platform-specific, and look exactly like platform widgets except for 
maybe a few tweaks (look at MS-Word 2000).

Long term idea:
I propose that one should be able to easily "theme" the widgets, then the 
widgets should be made skinnable. They would not be part of the ui skin but 
would have their own look. The default widget skin would look similiar but 
probably a little better than the OS-specific widgets. (Matthew Thomas (mpt) 
2000-08-05 03:06) - this is sort of a combination of his Matthew's statements 
on that day.

The premise:
Themeable widgets, widget theme != skin theme.
Standard widget theme looks similiar to but better than standard OS widgets

That way, it would remove the work that would have to be done from the hands of 
coders and put them in the hands of theme writers.

Fortunately, the widgets for forms could still look different from the ui. 

Also, users that love macs could make their widgets, for instance, look like 
mac widgets in windows.

Comment 30

17 years ago
hmmmm ... not to say that these are bad ideas, cuz i don't think they're 
necessarily bad at all ... 

and someone who's been around from the start, PLEASE correct me if I'm wrong (I 
might be) but wasn't one of the original ideas behind the new html form widgets 
to be consistent across browsers and platforms, so developers and users would 
have something they could count on for consistency?

hmmmm ... maybe i'm getting the XUL widgets confused here .... 
http://www.mozilla.org/xpfe/nsGFXWidgets.html

Comment 31

17 years ago
> Long term goal and perfect world would be: Two new prefs.

That's not funny.

> Themeable widgets, widget theme != skin theme.

That's even worse.

> wasn't one of the original ideas behind the new html form widgets to be
> consistent across browsers and platforms, so developers and users would
> have something they could count on for consistency?

No, it wasn't. It wouldn't be consistent for users, since most Mozilla users 
also use other apps, most of which use native controls. And it wouldn't be 
consistent for Web designers, since Mozilla is in the minority, and most other 
browsers do the right thing by having form controls which look and feel like 
the rest of the widgets on the user's chosen platform.

This is an overly general bug, assigned to someone who's obviously never going 
to do anything with it. I'm tempted to leave it open as a dumping ground for 
silly ideas and repetitive comments, so that they don't clutter up the RFEs 
which are actually aimed at doing specific things to fix the form controls ... 
But instead, I'm going to mark this as a dup of a newer bug, one which is 
assigned to the right person and which has a higher signal-to-noise ratio. If 
anyone thinks I'm doing the wrong thing, I'm available for torture on IRC.

*** This bug has been marked as a duplicate of 74058 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 32

17 years ago
Verifying Duplicate
Status: RESOLVED → VERIFIED

Updated

17 years ago
Keywords: UE1

Comment 33

17 years ago
removing myself from cc: sorry for the spam
You need to log in before you can comment on or make changes to this bug.