Mozilla UI FAQ
Wednesday April 19th, 2000
Waldo writes, "Just a reminder that there's a Mozilla UI FAQ at this news post."
I've been meaning to get this up on the chromeZone. Hopefully sometime soon.
#1 inaccurate explanation of native widgets
Thursday April 20th, 2000 3:15 PM
I was disappointed to see that inaccuracies about the native widget set found their way into this FAQ.
>>... each platform has its own way of displaying widgets. In order for Mozilla to display exactly the same on each platform, it was necessary to create a "universal widget-set."
>>That way, web designers could design a web page and know *precisely* how it will look on all machines, regardless of platform. The same page on Mac and Windows will be identical.<<
Nope. This pretends that there is no such thing as skins. Not only will the page not look identical on different platforms, it won't look the same on the same platform if two different skins are in use.
>>Another reason that Mozilla has its own widgets has to do with standards compliance. Mozilla's widgets need to be able to do all kinds of cool and funky display things that your native OS's widgets probably can't do. The widgets have to be able to stretch, they have to be able to shrink. They may need to have a colored or patterned background behind them, or they may need to be semi-transparent. This is all stuff that most native widgets simply can't do.<<
Nope. And I asked Waldo to try to find a specific before he posted this, so I'm especially sorry to see it here. No one has been able to find any such CSS requirement. The one thing I've seen posted is a paragraph about bounding rectangles that does not by any stretch of the imagination say that form widgets need to be fully styleable. There's no such standard.
What's more, XUL widgets do not pay attention to the style attribute, so even if there were such a standard, XUL would not be living up to it!
>>Peter Trudelle <firstname.lastname@example.org> (a Netscape UI developer) adds, "The most compelling reason for this choice was economic: we couldn't afford to implement a separate toolkit using native widgets on each platform we wanted to support."
>>Or, as another developer said (paraphrased), "If we decided to support native OS widgets, there would never have been a Mozilla for Mac or Linux."<<
This is constantly stated as if it were a law of nature. The fact is that a priority call was made. I don't know why it's so hard for the people involved to say "We prioritized resources, and we decided it was more important to work on some other things" rather than "There were no resources for it."
Perhaps it's because when the issue is phrased in the more accurate way, that opens up the question of whether the priorities were correct, rather than making it seem as if a law of nature prevented this work from being done. It's more accurate but it doesn't work very well as a justification, especially given that so many people have asked why nonessential work (mail and news clients, html editor, skinnability) were addedto the project.
The fact is that there has been tremendous end-user outcry about this non-standard user interface, especially by Mac users, who have the highest expectations for user interfaces in the industry. Despite this, no one is re-examining this flawed decision, and the justifications given for it don't make sense.
#2 Re: inaccurate explanation of native widgets
Thursday April 20th, 2000 4:40 PM
"Nope. This pretends that there is no such thing as skins. Not only will the page not look identical on different platforms, it won't look the same on the same platform if two different skins are in use."
But skins (in Mozilla's sense of the word) don't affect content widgets. I'd argue that a skin should not be passed into a webpage. Heavily skinned widgets (look at some of the Neoplanet widgets) would look awful on just about all webpages.
"This is constantly stated as if it were a law of nature. The fact is that a priority call was made. I don't know why it's so hard for the people involved to say "We prioritized resources, and we decided it was more important to work on some other things" rather than "There were no resources for it." "
But there weren't the resources. There's a reason Netscape didn't get a personal toolbar on the Mac until 4.5, and even then didn't get the ability to have folders on it. There's a reason MozillaClassic/Mac lagged behind windows - there weren't enough resources. It was a lack of resources followed by a judgement call that sent members of the MacFE team to work on the XPFE along with members of XFE and WinFE...
#6 Native, but XP
Friday April 21st, 2000 5:21 PM
> a judgement call [...] sent members of the MacFE team to work on the XPFE along with members of XFE and WinFE...
Yes, this makes sense to me. However, what I don't understand is, why no existing XP toolkit was used. There're lots of toolkits out there, which provide a common API to widgets on all 3 major platforms (Win32, Linux, Mac), e.g. WxWindows (IIRC).
Given, they don't have 100% of the functionality we need, but I am convinced, that it would be a lot easier to enhance these adapters* (and maybe add a treeview for Mailnews) than writing everything from scratch.
*a layer, which just maps a common API to a native one and possibly works out the differences.
#7 Platforms != major 3
Friday April 21st, 2000 5:32 PM
A platform, which is not compatible to the major 3 can of course also implement the toolkit. E.g. I think, Mozilla's BeOS port has been neglected in favor of Opera, because Mozilla doesn't have a native UI. Amiga users propably feel similarly strong about their native UI. So, Mozilla's strongly XP UI doesn't really help much.
It's clear, that Netscape propably won't use native widgets. But I really dislike the fact, that a economic decision, which means a major disadvantage for a lot of users (I don't think, we need a usability study to prove this), is hyped as a feature or justifed by weak arguments. This doesn't make the game easier for people, who actually want to implement a (XP?) Mozilla version *with* native widgets.
#8 Re: Native, but XP
Saturday April 22nd, 2000 2:29 AM
supposed usability issues aside, the XPToolkit offered by Mozilla is more powerful and simpler to use than any popular native toolkit I've heard of.
#10 Re: Re: inaccurate explanation of native widgets
Monday April 24th, 2000 2:12 PM
I certainly hope you are mistaken about widgets from skins being inconsistent between the framing areas of the UI and the web page portion of the UI. Consistency is a very important usability criterion.
As for "there weren't the resources," we seem to have a failure to communicate. There were a few dozen resources to do mail, news, and HTML editing. Are you suggesting that those engineers would have been incapable of toolbox work? It was a prioritization of resources, not a lack.
#12 You make the assumption...
Monday April 24th, 2000 3:56 PM
...that mail/news and html editing work were optional work. They obviously were not. A "browser" is not just an HTML viewer, and hasn't been for many years. Ask Tim Berners-Lee what his original conception of a "browser" was.
The idea that a decision was made favoring mail/news and HTML editing over native widgets is simply erroneous.
#4 Re: inaccurate explanation of native widgets
Thursday April 20th, 2000 5:05 PM
"Nope. And I asked Waldo to try to find a specific before he posted this, so I'm especially sorry to see it here. No one has been able to find any such CSS requirement."
Do you have a list of html elements that must be stylable?
#3 Hi, my name's Peter & I'm a prioritizaion ween
Thursday April 20th, 2000 4:52 PM
Tim, you're beating a dead horse, or as we say at Netscape, playing with a dead snake. I thought I was pretty clear that the decision was based on resource prioritization. There was no way we could have done native development for our top-tier platforms given the constraints. This has been rehashed ever since in one forum or another, but there has been nothing new added that I'm aware of since the decision was made. I'm not going to revisit it in this release cycle. I would love to have a real native UI on each platform, but the only way that will happen anytime soon is if you, and others who care enough about them, write them yourselves. Weren't you on the UI development team for Mac OS? Why don't you head up the Mac-native Moz effort?
By the way, please point out the 'tremendous end-user outcry'. I've heard plenty of this from developers and other techies, but I have yet to see it even mentioned in any usability study or focus group.
Peter Trudelle XPToolkit Manager Netscape
#5 Re: Hi, my name's Peter & I'm a prioritizaion
Friday April 21st, 2000 11:41 AM
(Tim) >> The fact is that there has been tremendous end-user outcry about this non-standard user interface, especially by Mac users, who have the highest expectations for user interfaces in the industry. Despite this, no one is re-examining this flawed decision, and the justifications given for it don't make sense. <<
>> (trudelle) By the way, please point out the 'tremendous end-user outcry'. I've heard plenty of this from developers and other techies, but I have yet to see it even mentioned in any usability study or focus group. <<
Well, I'm sympathetic. But there's been a tremendous amount of it all over the place, but here's a start:
http://www.macintouch.com/netscape6.html and http://www.macintouch.com/netscape6part2.html
Lots of other forums, that's just a handy big batch. I'm not sure how you could miss it. ;-) Not that I disagree with the decision, I don't -- I would undoubtedly made the same decision. However, there's still no point in sugarcoating the seriousness of the problem. I've yet to see a positive Mac user response from outside the Mozilla community, and I've seen 100s (no exaggeration) of negative. To the honest eye, it's a PR apocalypse.
If you read these, you'll note that the audience is leaving the building in fairly large numbers. I'm not sure how useful a usability study would be after the fact, it would appear to be too little too late. So much damage has already been done.
There is a lot of ignorance and misunderstanding in these posts (e.g. they don't understand how easy it will be to customize the UI that offends them so, nor the initial startup speed, the debug speed -- speed seems to be almost as popular to ignorantly beat up on as the UI), but that doesn't make the damage any less apalling. As it stands, it looks like the legacy of the XP UI may be to run off the non-Unix user base. And that would be tragic.
May be a dead horse, but it's no less depressing. :-( I think the upside could (someday) be the fizzizilla opportunity. If M$ drops the ball here for X (going Carbon and sticking with legacy toolbox), that would be the opportunity to recoup some of these losses. Already too late for that on the UI front, but not too late in terms of back-end speed and reliability and so forth. And maybe some good press there will help get some of the Win32 crowd back.
But it ain't gonna happen with the AOL skin, that's for sure. I hope the lesson learned is that skinnable or not, the default skin is profoundly important and deserves a lot more usability attention than it obviously got. If they did do usability and/or focus groups, they need to get to work explaining the stark discrepancy between their results and the real world.
pax ex machina, email@example.com
#11 Re: Hi, my name's Peter & I'm a prioritizaion
Monday April 24th, 2000 2:17 PM
>Why don't you head up the Mac-native Moz effort?
Because I have a job already. I did an exploratory a little while ago to see whether it would be feasible to do Mozilla work on the side. I found that it took a quarter of my working hours just to keep up with daily builds, without actually doing any programming on the project. That doesn't work.
My impression is that most of the outside programmers contributing to this project have had time budgeted to it by their day-job managers, which is not the case for me.
#9 just opposed to misinformation
Monday April 24th, 2000 2:06 PM
I thought it was clear in my message that I was not attempting to open the issue of whether this was a good or bad decision, only attempting to correct factual errors in the UI FAQ. Whether it was a good or bad decision, misinformation should not be promulgated in the course of explaining it. I hope to see a revised draft that omits these errors.