Closed Bug 47632 Opened 25 years ago Closed 24 years ago

HTML form widgets need polish

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 74058

People

(Reporter: german, Assigned: german)

References

Details

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

Attachments

(1 file)

Examples of how the buttons and textarea could look
12.26 KB, image/jpeg
Details
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.
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]
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...
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.
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.
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.
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.)
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.
i agree also for the reason of this is what I think wold work best given the reosurces and time we have
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
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)?
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
Keywords: UE1
Whiteboard: [NEEDINFO] → [NEEDINFO][UE1]
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) ?
Ian has been doing a lot of this sort of thing lately.
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.
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,
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]
Updating QA contact.
QA Contact: ckritzer → bsharma
*** Bug 58383 has been marked as a duplicate of this bug. ***
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
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.
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...
QA Contact Update
QA Contact: bsharma → vladimire
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.
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
> 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
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verifying Duplicate
Status: RESOLVED → VERIFIED
Keywords: UE1
removing myself from cc: sorry for the spam
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: