Towards Mozilla 1.0
Tuesday June 26th, 2001
Gervase Markham recently posted his feelings on what a 1.0 release of Mozilla would be. Gerv has sent us the follow-up to that posting, including much of the feedback he received. To read it, click the full article link. Once you have read through it, we welcome you to post your feelings on what you think a 1.0 release would have. [As Gerv says, please don't post your favorite list of bugs, only the criteria for choosing what bugs to fix.]
#1 End-user experience might be important
Tuesday June 26th, 2001 11:38 PM
The nightlies in the last couple of weeks have been fun to work with. Now that the crash landing period has been overcome, Gerv asks what's needed for 1.0. I think this question should be driven by end-user experience, maybe using the user feedback of PR1 as one of the sources.
Why? The goal for 1.0 should be to achieve a high level of acceptance in the user base. Show people that there is a usable, solid piece of software. Up to now, people have concentrated on features. That's fine, but you can't go on like that forever, and Gerv rightly asks for a feature freeze. Now we need to phase out the problems that might prevent users from saying "Wow, that's decent software. I'm gonna use it." It is my feeling that to achieve this, some polishing work on the interface is necessary. Bookmarks have improved a lot recently, but think of focus bugs. If users open links in a new window, they'll intuitively expect content area to have focus. It does not. Stuff like that is important. It's a minor issue, but annoying and user-visible.
In the past I always had the feeling that most polishing bugs always slipped "through the net". After a release, we had landings. Then the regressions of the landings were fixed. Then the next branching was coming closer, so the bug list was reduced to the "important" bugs. After the branch, the cycle started again and the polishing bugs were forgotten. But now is the time to take a look at that stuff.
PS. I'm pretty much impressed with the current state of Mozilla and looking forward to 1.0. ;-)
#2 Re: End-user experience might be important
by cplyon <firstname.lastname@example.org>
Tuesday June 26th, 2001 11:58 PM
I totally agree with your comments about polish. That's what end-users will see. Some don't care about Mozilla's DOM1 compliance, or the new PSM, they just want a browser suite they can use.
IMO, bugs that need to be fixed for 1.0 are ones that limit the user's ability to use Mozilla. Accelerator keys for ALL menus and buttons is one example. Yes, these types of bugs are mostly in the UI, but that's where a lot of the flak has been aimed. Mozilla's UI may be different-looking than most apps, but that doesn't mean it should be harder to use.
#183 Re: Re: End-user experience might be important
Friday June 29th, 2001 6:29 AM
"Some don't care about Mozilla's DOM1 compliance, or the new PSM, they just want a browser suite they can use."
One good example of the type of thing I believe should be watched for in bugzilla is bug 58104 <http://bugzilla.mozilla.org/show_bug.cgi?id=58104> which only affects Mac users running ATM. At first glance it doesn't seem to be major. Then when you think about it, you realize "Wow. This should be fixed."
(Let's do that now... "Hm... There aren't many Mac Mozilla users in comparison to the other platforms. And this only affects those running OS 9 and ATM. Not the vast majority of Moz users. Wait a second. Any Adobe product you install installs ATM. How many surfers can live with 'You can't install Acrobat Reader and use the browser'? Of course you can turn off font smoothing. Oh. Then PostScript fonts are nearly illegible. Why are there ANY Mac Moz users?!?")
OK, that detour may not have been how you thought. But you get the point. Having to choose between legible fonts/PDFs and opening a second browser window or even the preferences should definitely stop a 1.0 release.
There are a number of bugs like this for all the platforms. I'm not posting all the IDs since this isn't supposed to be "my favorite bugs".
(I posted the one I did since I deal with it daily and thus have vested interest in it seeing the light of day.)
#11 Re: End-user experience might be important
Wednesday June 27th, 2001 1:16 AM
> The goal for 1.0 should be to achieve > a high level of acceptance in the user base.
Why do you say that as if it's obvious? It's not necessarily a given for a _Mozilla_ 1.0 release, because Mozilla is an end-user product.
This is not to say we shouldn't have a good UI or user experience; but it could be argued that the criteria for 1.0 should be based on e.g. embedding, API, standards support stuff rather than "user experience".
Also, how do you plan to measure it? This article is looking for ways of defining whether we've got there or not. "Wait until users say 'Wow, that's decent software. I'm gonna use it.' is not a very hard criterion. :-)
I agree with your comments about polish, though. Hopefully having a feature freeze might help this. Mozillazine readers diving in and learning about XUL and JS (it's not hard) and doing some patches would help even more.
#15 Re: Re: End-user experience might be important
Wednesday June 27th, 2001 2:11 AM
I'm not sure I understand your first paragraph. With "acceptance in the user base" I refer mainly to new users who will then try Mozilla for the first time or revisit it (e.g. current IE users) and might go away again if "it doesn't feel right".
Gerv writes: "This is not to say we shouldn't have a good UI or user experience; but it could be argued that the criteria for 1.0 should be based on e.g. embedding, API, standards support stuff rather than "user experience"."
One sure could. It all depends on what your aim is. Mozilla certainly has a number of different aims. My comments were for the "Mozilla browser suite desktop end-user" aim. Embedding is a different aim.
He continues: "Also, how do you plan to measure it? "
As there aren't the resources for a MS-like usability lab available, we should employ the Mozilla user base. One possibility: have some discussions in a newsgroup about what current users think right now is really necessary to polish. Ask the developers what's realistic. Then have a little team make up a filtered list of those requests that is feasable for 1.0. File necessary bugs and target a meta bug for 1.0.
#32 Re: Re: End-user experience might be important
Wednesday June 27th, 2001 5:55 AM
Gerv wrote: > Mozillazine readers diving in and learning > about XUL and JS (it's not hard) and doing > some patches would help even more.
I suppose these are questions that would be answered with the new documentation suggested.
I'm just afraid my lack of C++ coding skills would significantly hinder me in trying to help.
The wonderful thing about Mozilla is that you really don\'t need to know ANY c++ to help code the UI. You don\'t need a compiler either; since the UI is all interpreted at run-time, you can just change chrome files and restart the browser to see your changes.. All you need is a text editor, a jar packer/unpacker, knowledge of XML, JS, and CSS, and an inquisitive spirit.
The only thing that has hindered me has been the lack of and/or obsolescence of docs on XUL, XBL, and XPCONNECT. But the best way around that, I\'ve found, is just to start digging into the chrome .jar files, changing stuff, and seeing what happens.
The newsgroups are also great sources of information and answers.
Hope you decide to contribute! If so, welcome!
#86 Re: Re: Re: End-user experience might be important
Wednesday June 27th, 2001 4:19 PM
> Love to, but i'm confused as to > whether or not i have to compile the > entire beast myself to test my > patches?
No. You don't need to compile a thing. Having the bandwith to maintain a CVS checkout is handy, but again not essential. If you do a CVS checkout, you can use the Patch Manager <http://www.gerv.net/software/patch-manager.html> to install new nightlies and keep your CVS tree in sync. You can then do CVS diffs to submit patches but use the precompiled Mozilla nightly for testing.
In terms of review and super-review, yes - so if you are making small fixes, it's a good idea to do a number at once in the same file.
> Is there any sort of tutorial or > walk-thru out there?
#89 Re: End-user experience might be important
Wednesday June 27th, 2001 4:28 PM
I think you underestimate the takeup of Mozilla.
Taking linux as the best example, the distrubutors are already (not surprisingly) favoring Mozilla over Netscape for two reasons. 1) Its meant to be totally, 100% open source 2) There is normally a newer release with bugfixes that aren't in the latest Netscape release.
Secondly, many browsers based on Mozilla will take its UI as the start point, and only change a small number of things. In the case of Netscape, any changes which are not made to Mozilla will have to be made on the Netscape branch, which is wasting development resources, and any changes not in Netscape will not be in Mozilla. (does that made sense?)
#251 Re: End-user experience might be important
Saturday July 7th, 2001 10:17 PM
The points made by Nilse and some of the others are important. The "end-user experience" is important!
Think about this for a little while. While Mozilla has made great progress with version 0.92, there remains one nagging issue: "end-user" usability. In comparison with Netscape Navigator 4.7, Mozilla 0.92 has some great features which Mozilla developers can readily appreciate: the Gecko rendering engine, better XML standards compliance, support for skins(thus a more flexible user interface), the Sidebar, among others. However, if I were to pull the "average Internet user" out of his office or home and ask that he compare Netscape 4.7 with Mozilla 0.92 (with its "classic" skin on, not the modern one), he may be hard pressed to come up with a long list of items. To him, it is important whether that he can print webpages, and perhaps get a preview of how it will look before he prints it out. It is important to him, that he can save a webpage to his computer and have it look the same as it offline as it online (In other words (or "geek-speak" if you like), he hopes the pictures in webpage are saved to the hard drive along with the HTML file). Also, he would not think it unreasonable to expect that he be able to publish the latest version of his webpage to say, Geocities, through the "Publish" feature available in Netscape 3, 4 and 4.75. He doesn't know what Ws_FTP is and why he should/could use it instead.
I may be wrong, but I think all these features are missing from Mozilla 0.92 and their absence detracts greatly from the end-product's appeal to the "average" user.
In my humble (and not-so-technically-aware opinion), Mozilla 1.0 should be a browser that is "elegant" in its look and feel. In all honesty - and with great respect for all the technical wizardry that made Mozilla 0.92 possible today - I would have to admit that Mozilla today is not elegant in its look or feel. Elegance is subjective, you get at least a general idea of what I am getting at.
I use a fairly slow laptop (380 Mhz AMD chip, 32 mb of RAM) , with AOL. My laptop had been running so slowly lately with AOL along with either IE or Netscape, that I decided to try out and older version of Opera (ver.4), which I had installed some time ago. I was so stunned by the gentleness with which it treated my computer (no thrashing of the hard drive, no sucking out the remnants of the available RAM) and the beautiful simplicity of its interface. I tried out version 5.12 after that, and was even more impressed. Forgive me for stirring up the equivalent of sibling-rivalry in the browser world, but I do have one observation from this digression into and comparison with Opera. Opera's design philosophy seems to be "more is less" and "simple is better than complex." With Mozilla, this cannot be said.
I hope my comments will prove useful.
Regards, - Jayesh
#3 Perf, XSLT, SVG, Jabberzilla
Wednesday June 27th, 2001 12:31 AM
Obviously, performance has been a top concern lately, and it should be. Hopefully Moz 1.0 will be quite a bit snappier than the current builds. Also, I hope that damn startup splash-screen is killed :-)
I really hope that XSLT would be ready to go into Moz 1.0. IE has it, and Moz should too.
There have been some AWESOME strides in SVG development lately. It would be VERY sad to not see them added to Moz 1.0.
Finally, how many people would be interested in seeing a 1.0 quality version of Jabberzilla in Mozilla 1.0? It is an IM client that works with Jabber, AIM, ICQ, MSN, Yahoo, and has other cool features. It would sort of be the equivilent of Netscape 6 having AIM, so maybe Mozilla could use Jabberzilla?
So what you are saying is that if any of XSLT, SVG or Jabberzilla are not ready when we want to declare Mozilla 1.0, we should hold up the release?
If not, then saying "it would be nice" has no value. Of course it would be nice. :-)
(XSLT's been in for over a month, by the way.)
#9 Jabber - Yes
Wednesday June 27th, 2001 1:09 AM
It's really sad that Jabber is the coolest IM architecture ever made but there aren't any decent clients on Windows... I'd say JabberIM comes the closest, but it has some serious bugs and focus issues... WinJab has lots of features but the UI seems a little freaky to say the least. I'm not sure I want our fellow Mozilla engineers to work on it, but if the people could help out the JabberZilla guy on mozdev.org and make it awesome before 1.0, I'd be quite happy. :)
#22 Re: Perf, XSLT, SVG, Jabberzilla
Wednesday June 27th, 2001 3:16 AM
XSLT has been in for some time, but I would recommend that it be not included in Mozilla 1.0 . Why? There hasn't been enough testing and or documentation on it yet.
SVG should not be in the release, it should be an optional add on for now at least until it has gone through enough testing and SVG is finallized as a standard.
Jabberzilla would be nice, but if it is not ready, lets not wait.
#30 XSLT (yes!), SVG, Jabberzilla
by AlMalossi <AlMalossi@gmx.net>
Wednesday June 27th, 2001 5:22 AM
I personally thing that XSLT is important for a mozilla1.0 release.
It is one of the "promises" to the developers that mozilla will be more than a browser, it'll be a platform for web-applications.
Mozilla.org made a lot of effort to create a architecture for web apps, but it must be visible for the web apps developer. This developer don't need XUL, which is only supported by one browser, they wanna have standard XML-XSLT-XPath....Xxxx
We all can see the hype about XML everywhere, and as a XML-developer i can say that there is no serious XML without XSLT.
XML will take over the company intranets first, where there are standard software installations on every workstations. if ie6 will have XSLT (and it will) mozilla will have it hard in this segment.
The Point about SVG is not yet a w3c standard is good, but as we follow w3c we can see that things there are often pre-final-public-drafts rather then standards ...for years
Jabberzilla, needs work, and if there will be a mozilla 1.1 release one or two month after 1.0 (release fast, release often) it would be a nice new feature. Oh look it has a IM client now.
And we want people to switch to mozilla 1.1 very fast, because with the many 100 bugs fixed there, it's getting more and more stable, and getting more and more good reputation.
I think that XSLT falls into the "really really nice to have...but not absolutely necessary" category. It isn't one of the standards that we promised for Moz1.0, and if it comes down to a choice between working on one of the core standards (DOM0/1, HTML4, CSS1) and working on XSLT...we need to give the former top priority, and not succumb to feature creep. Once the Mozilla project has accomplished its primary goals, then we can set new ones for the next release. If XSLT is not stable enough to turn on by default in 1.0, we could make it an official requirement for 1.1, along with a few other top picks from the feature list.
#41 Beware of feature creep
Wednesday June 27th, 2001 9:01 AM
Feature creep can be one of the deadliest things when pushing for a commercial release. That's not to say that essential features should be shortchanged, but the core product needs to be there before all the bells and whistles. Jabbarzilla is an excellent example of something that's non-essential for a 1.0 release, IMHO.
The things that an end-user will notice most about a product are: 1) user interface considerations 2) stability 3) speed (but only if some operations are noticeably slow)
Non-essential features, memory footprint, etc will be way down the list. And you want something for 1.1 and 2.0, don't you?
#106 Re: Beware of feature creep
Wednesday June 27th, 2001 11:42 PM
"Feature creep can be one of the deadliest things when pushing for a commercial release."
I appreciate the sentiment but wanted to make sure that we all remember that this is not a commercial release. I agree that feature creep and "big number" release delays can cause PR problems. And even (maybe especially) open source projects have to care about public perception so there is definite value in moving from a feature writing mode into a feature fixing mode. But I strongly oppose any changes to process that move Mozilla in the direction of making decisions based on "commercial release" pressure.
1.0 is a tag of the source code in cvs.mozilla.org at some point which we have deemed it to be suitable for consumption by mozilla embedders, distributors and as maybe some "open source power user" types. 1.0 is not a commercial product, it's barely even a non-commercial distribution. (think "reference implementation").
#145 Re: Re: Beware of feature creep
Thursday June 28th, 2001 12:33 PM
"1.0 is a tag of the source code in cvs.mozilla.org at some point which we have deemed it to be suitable for consumption by mozilla embedders, distributors and as maybe some 'open source power user' types."
Though of course by that time Netscape probably would have released two end user products based on Mozilla (three if you count 6.01). Oh well...
#133 Re: XSLT (yes!), SVG, Jabberzilla
Thursday June 28th, 2001 10:10 AM
RE: SVG is not a W3C standard yet.
IIRC the W3C don't declare anything a standard (or whatever they call it) until there has been a reference implementation to weed out any bugs.
#141 Re: Re: XSLT (yes!), SVG, Jabberzilla
Thursday June 28th, 2001 12:04 PM
"IIRC the W3C don't declare anything a standard (or whatever they call it) until there has been a reference implementation to weed out any bugs."
I think you're thinking of RFCs. Those require 2 independent implementations before they become official.
In any case, there is already a SVG implementation available: Adobe's SVG plugin.
#25 Re: Perf, XSLT, SVG, Jabberzilla
Wednesday June 27th, 2001 3:25 AM
don't worry-mozilla.org isn't going away after 1.0 :)
#4 Stability, useability
Wednesday June 27th, 2001 12:32 AM
Mozilla definitely needs a slowdown in feature additions. I'm not sure a total freeze is needed (yet), but I agree that you need to concentrate on fixing what's there rather than adding more.
Personally I would not be so quick to dismiss stability concerns. It has improved greatly but you ought to shoot for having as few known crashers as possible. Few things are as annoying as losing a session because of a crash. I would also add to that anything that corrupts data - which can be even more insidious than a crash. I know that there will always be obscure problems in a project of this size that has to interact with lots of different window managers, X servers, graphics drivers, etc, many of which are buggy themselves, and it may be difficult to put an exact number on how many known bugs of this type to allow, but I think that improving that needs to remain a priority.
Do not underestimate the impact of continued improvements in things like dialog layouts and other user interface items. Even though this is not quantifiable, it can greatly enhance a user's overall experience of a product. Whether it's fair or not, many people WILL judge a book by its cover.
Memory footprint issues are rapidly becoming moot given the plummeting price of DRAM. Don't make it worse, and if there are easy changes that make it better they could be considered, but it shouldn't be a priority.
Performance is more of an issue but things have improved a lot. It should probably receive somewhat more priority than footprint but not as much as the first couple unless the change is easy or the performance hit severe. Startup time is still longer than ideal but fixing the preloader to work reliably should address at least some of that; but it's hard for me to think of any other very visible performance problems.
It's making a lot of progress, it will be great to see a really solid release.
#67 Re: Stability, useability
by krmt <email@example.com>
Wednesday June 27th, 2001 1:12 PM
"Memory footprint issues are rapidly becoming moot given the plummeting price of DRAM. Don't make it worse, and if there are easy changes that make it better they could be considered, but it shouldn't be a priority."
That's what they said about Java, and it still runs slow overall in user-land. There's a good reason you don't see Java apps filling the CompUSA store shelves. Performance is a big issue, and while you're right that things have improved, it's not an issue that should be saved for later.
I've heard that one before. A lot of times. Maybe for us geeky engineer types. But I don't see a lot of people running out to stores, plopping down $150, opening up their computer cases, and installing memory chips just so they can run a new, free browser.
If memory footprint doesn't matter, maybe we can forget the pretences and accept Mozilla only for new computing environments ala Windows XP. In fact, maybe the Windows XP launch with all of the upgrades and computer tradeins required for its success can be the compelling event that makes Mozilla a valid choice.
BTW, it rocks on a 1.4mhz Pentium with 512MB of memory :-)
by gerbilpower <firstname.lastname@example.org>
Wednesday June 27th, 2001 12:44 AM
Remember everyone, Gerv is asking for specific criteria for Mozilla 1.0, not specific bugs.
There has also been discussion on the newsgroups that performance, stability, and memory use are difficult to specify criteria for, since comments such as "performance needs to be faster" or "needs to crash less often" are far too vague to be of any use. These are very important areas, but just difficult to specify as a check-list goal or to quantify in a useful manner. Alex <http://www.gerbilbox.com/newzilla/>
Alex, I send a message on perf newsgroup, discussing ways to define performance - footprint measurement. Not sure if it's quite useful, because I am only a hobbyist programmer. But I still insist those criteria aren't that hard to define.
The point is not that criteria are hard to define (anyone can make up numbers - "Mozilla should do foo in under X seconds") but that the criteria are arbitrary, and we might as well accept that and go on gut feeling. And my gut feeling is that, if we continue the current level of perf work, by Moz 1.0, we'll be fine. We're pretty good now, and it's not going to get worse.
What's wrong with using Netscape 4.77 as a benchmark/criteria for performance? After all, the people most likely to start using Mozilla1.0/Netscape6.2(or3 or whatever) are the current users of Netscape4.x browsers. If this is supposed to be an upgrade for them, then we need to ensure that their browsing experience (and email experience) are equivilent or better than what they currently have, otherwise why would they upgrade? So wouldn't it be reasonable to expect that 85% (or more) of a test case with web-pages (something like the top page of the top 20 websites visited) and common email procedures (like get POP email, create and send new email, reply to a test email) would be as fast or faster in Mozilla1.0 than in Netscape4.77? These are solid, reproduceable numbers, and can give hard targets to aim for in the 1.0 release.
Gerv, the problem with your approach is that every developer will try to fix performance problems in the way he thinks it's right. Instead of focusing on big but difficult to resolve performance hits, they might work on small not noticeable improvements that would be out of scope if solid performance / footprint criteria were established. A lot of man hours might be lost without any significant improvement.
On the other side, my impression is that qa and developers working on performance issues (cathleen, law, syd, morrison and others) do a very nice job . They have some constant targets, they did some very nice feasibility studies and benchmarking and that is what I would mostly expect from a well managed working group. If they had some performance standards as well ...
I think baffoni hinted a nice (although hard to reach) target: maintain some percentage of NS4.x performance scores, well below 100% of course (since NS4 wasn't such a complex cross platform application).
Even though performance has increased significantly, I still use the nightlies only on the 900MHz/250MB machine at the university for daily use (there mozilla rocks). At my home machine (350MHz/250MB) it's really not usable for everyday work. I have to wait ages for the mail-window to come up.
I understand that it's difficult to push this harder. But then I expect that the page stating the system requirements gets updated, 233MHz is way to slow.
Or can we expect a major performance difference between the nightlies and the final release due to more time to optimize all compiler options etc.?
What I think needs the most focus are the rendering bugs. I agree with him that we should strive to be as compliant as possible with CSS1, HTML 4, DOM 0, DOM 1. I'd also like to see a bit more work on DOM 2, CSS 2, if possible. Why? Well Netscape signed all these deals to embed the browser on different pieces of hardware. So the embedding stuff needs the most focus. Plus, I have no intrest in using the UI for Mozilla. <http://www.netcaptor.com> is just too perfect for my needs. I want mozilla engine slapped on that baby and it's goodbye IE! I need control of my multiple browsers that are open. IE and mozilla just suck at this so badly. I d/l a few webpages and while thier d/l'ing, I'm reading one that gets finished first and then when one of the others is finished, it pop's up in front of the one I'm trying to read! Hello IE & Mozilla? Please stop doing that. I hate it. Netcaptor has the UI perfectly laid out and it rarely, if ever, crashes. :) However, I don't expect him to work on porting mozilla to his cool program until mozilla is stable, API freezed, and standards compliant as possible. Maybe next year? :)
> I'd also like to see a bit more work > on DOM 2, CSS 2, if possible.
More work on these means less work on DOM1 and CSS1, and therefore a later release. It's the same set of engineers that work on both. Why would we want to do that?
Also, saying "The Mozilla team should work on code X so I can go away and not use Mozilla" is a little bit cheeky :-)
Yes Gerv is right!
Keep the (mentioned) promises for the developers DOM0, DOM1, css1, HTML4 (XML, XSLT)
once they are there, jump on the over next generation of the web!
#82 I know, no specific bugs but...
by FMXii <email@example.com>
Wednesday June 27th, 2001 3:57 PM
What he said was right... I really hate the windows that pop up from the background. Also I have a problem with the fact that when I right click a link and use "Open Link in New Window" the link color does not change to the "used link" color. (like i said, no specific bugs, i know, but i wanted to state them before i forgot).
#134 Re: I know, no specific bugs but...
Thursday June 28th, 2001 10:25 AM
FYI the bug on this is 77675 <http://bugzilla.mozilla.org/show_bug.cgi?id=77675>
I think mozilla's UI is the coolest part. I just clicked on a link, restarted and got a new button on mozilla that keeps track of my bookmark keywords for me ( see <http://www.silverstone.net.nz/software/smartwords/> ) It's so easy to add functionality to the UI this way-there's even a multizilla project that adds tabbed browsing to mozilla.
#66 Re: Re: What needs to get done
Wednesday June 27th, 2001 1:02 PM
REALLLLLLLLLLLLLLLYYYYYYYYYYYYY?!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :P Link please!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :) :) :):):):):):):):):):):):)~
oh I forgot to give the multizilla link. It's at <http://multizilla.mozdev.org/> still not complete but it's certainly cool
#13 Modularity, clean installs, and upgrade paths.
Wednesday June 27th, 2001 1:40 AM
"Modularisation. It has long been a goal of mozilla.org's to get the Mozilla codebase into a state where each component could develop independently and you could pull and build the "latest stable" release of each component to make a stable browser. This can only happen when APIs freeze. I would therefore suggest that this reorganisation be the key priority in the immediate post-1.0 period."
The idea that you can pop modules in and out of Mozilla in order to upgrade or extend it is a big deal and I think important to get right so that upgrading to 1.1 doesn't mean another full 11 meg (or more) download. Ideally after 1.0 you'll be able to pull just a new renderer or a new UI or whatever, right?
Will Mozilla be able to do any kind of "smart upgrade" to take advantage of the modularity? I haven't heard of this...is this something we should see in a 1.0 release?
Also, maybe 1.0's installer should come with some kind of "sweeper" for everyone who's been using nightlies and betas and netscapes and stuff that deletes old registries and stuff so that people are sure to be getting a nice fresh clean install that can then be updated cleanly to 1.5 and 2.0 and onward.
#88 Re: Modularity, clean installs, and upgrade paths.
Wednesday June 27th, 2001 4:24 PM
> The idea that you can pop modules in > and out of Mozilla in order to upgrade > or extend it is a big deal
You can sort of do that already. The modularisation work doesn't affect those building a Mozilla-like thing, but has a great impact for embedders - people who just want to take out and use small bits of the codebase.
It's not sexy, but it needs doing :-)
#230 Re: modularity
by josh_hall2k <firstname.lastname@example.org>
Monday July 2nd, 2001 9:42 AM
How difficult would you anticipate it to be to have a sidebar app (maybe not an application, but you get my drift...)which would automatically update the various different modules when they are updated/improved? As you said, this would reduce the need dramatically for a heftly download every time a new release is available.
My criteria (largely pulled out of you-know-where):
There should be zero crasher bugs in the main components themselves. (Crashers in third-party plugins, Java, and so on might be considered acceptable; the hypothetical "buck stops here" guy should consider each bug, or each minor component that could be buggy.)
There should be zero bugs relating to data corruption or loss, period. These problems are *not* acceptable.
The promises for standards support and compliance that have been made should be honored; if full support is impractical, full compliance should be considered acceptable, but the software *must* perform to established standards.
The standards for which support or compliance has been promised should have zero rendering bugs (or in the case of promised standards which may not have any visual effect, such as mail protocols, there should be zero bugs in the backend implementation).
There should be no memory leaks. If Mozilla must be a hog, then let it be, but it should be a *steady* hog, not one that eventually swells to the size of a house.
If these requirements seem unreasonable, consider that in recent years, the acknowledged inevitability of 1.0-release bugs has served to make buggy 1.0 products acceptable in the public eye. I believe that Mozilla should strive as much as possible to avoid this "public beta" philosophy when defining criteria for a 1.0 release.
I would suggest that window drawing performance should be *equal* to that of OS-native windows, but I don't know whether this is feasible. I would also suggest that the UI be polished as much as possible, but UI polish is difficult if not impossible to quantify.
You request "zero crasher bugs", "zero bugs relating to data corruption or loss", "no memory leaks" and so on. I think you're asking for too much. Even coming close to what you're asking is unrealistic in the given timeframe. And how would you determine when you're there? You can't prove the absence of bugs. You can only prove the opposite.
#17 Re: [INSERT TITLE HERE]
Wednesday June 27th, 2001 2:22 AM
"There should be zero crasher bugs in the main components themselves."
Not gonna happen. Not worth even shooting for. I'm not gonna hold mozilla 1.0 because one bug crashes one AIX user one out of every 50 times she accesses one particular site. a little exaggerated but do you see my point. Mozilla compiles on more than a dozen platforms today and may compile on even more by the time we get to 1.0. Even if it only built on one platform I think that zero crashers is simply unrealistic. It becomes even more unrealistic when you consider that anyone can file a crasher bug in Bugzilla any day. I could compile my own build for Mac OS X and not being very sophisticated in the build process I could leave something out or pull on a red tree producing a build that crashes on startup. Would it be reasonable to hold 1.0 because I file a bug the day it's scheduled to be released saying my OS X build crashes on startup? I know these are a little exaggerated examples but the point is that zero crashers just isn't realistic. Maybe something like zero crashers which have been confirmed to affect some significant (what's the number here?) percentage of Mozilla users might be a little more realistic. Even that seems a little extreme. A crash might affect all platforms but not unless the user followed some really exotic/unlikely series of actions. I think it would need to take into account how many users could be affected and how often they are likely to be affected.
#23 What about XP crashes?
Wednesday June 27th, 2001 3:20 AM
How feasable is it to cut down crashes that affect all platforms to minimal?
#37 Re: "Zero crasher bugs"
Wednesday June 27th, 2001 8:07 AM
You're right, of course. But there should be a goal to get as many of the crashers out as possible. There will always be a certain number of them that will be hard or even impossible to track down and fix (for example, when you have a lot of users hammering on it you will sometimes get crashes on machines that simply have hardware problems. You can't hold everything up simply because someone reports a crash that you can't duplicate).
I appreciate very well the problems of cross platform development. One large project I worked on compiled on nearly 20 (!) different platforms. It's a bitch.
The _goal_ should clearly be zero crashers, but this isn't going to be achievable in the real world. It's difficult to put a quantifiable number on it because as you get close to zero a lot of the remaining ones will be that kind of "noise" crasher. Even among crashers that are traceable to real bugs some of them will be a lot more important than others, and some may be so rare and so difficult to fix that it's not practical to do so.
However I would submit that in the software industry in general (not just Mozilla, please, I'm not trying to say that you're any more guilty than anyone else) there has developed a much more relaxed attidude towards this than there ought to be.
#52 Re: Re: [INSERT TITLE HERE]
Wednesday June 27th, 2001 10:47 AM
In addition; Microsoft Internet Explorer 5.5 crashes more often than the Mozilla nightlies do in my experience. If IE55 is loved by so many, then the few crashes that Mozilla has should be forgivable.
#60 Not my experience...
Wednesday June 27th, 2001 12:26 PM
This is not my experience; IE seems to be slightly more stable than Mozilla at this point. I would put it at
IE > Mozilla >> Netscape 4.x
at this point. Still, I find IE and Mozilla's level of stability at the "barely tolerable" level -- they crash several times a day for me (!). Still much better than NS 4.x which crashes several times an hour (!).
Well, my 0.9.1 browser has been up since Monday morning (2 and a half days) without any issue. Of course, I don't visit the latest whiz-bang sites much so that may be a factor. I usually update the nighlies on one of my desktop machines every Monday morning, and I've let it slip a whole week without any problems before. The current generation of Mozilla browsers seem to crash about as frequently (if not more so) as Opera. I'd put this as my stability graph from least stable to most stable:
o Netscape 4.x o IE 5.5 o Opera / Mozilla o IE 5.0 o Netscape 2.x
But another bonus for Mozilla is that when it does crash, it won't take out your desktop with it like IE does. I usually use Linux, so that is reflected above -- perhaps the Linux version of Mozilla is more stable for some reason or other (?).
#64 Might be part of it ....
Wednesday June 27th, 2001 12:43 PM
As it turns out I do seem to visit a lot of what you call "whiz-bang" sites, that may well be part of it.
I've noticed that the Linux version does seem to be more stable than the Windows versions.... that may well be the other part of it, a lot of tools I need for some of my projects at the moment are only available for Windows :-(
With Windows at least I suspect that user experience will vary wildly, depending upon how stable one's OS install is and which platform, etc. I haven't crashed Moz for at least a month, though I don't exactly go to all the Flash-encrusted sites. Of course, I do have an only 4-month old install of WinSE. But I've crashed IE5.5 at least four times today, mostly on simple little HTML pages.
#18 Totally Agree
by TonyG <email@example.com.Yuk>
Wednesday June 27th, 2001 2:28 AM
This encapsulates nicely all that I want to see in Mozilla 1.0.
The other aspect of Gerv's post I was pleased to see was mention of documentation. I am a programmer and I have lost cout of hte attempts I have made to get involved in Mozilla as a hacker. Its inpenetrable to non-prodigy code monkeys like myself.
I think a cross project sabbatical to do a brain dump would be a reasonable thing to ask for before 1.0. I would be happy to help converting this info to some sort of Mozilla walkthrough - which is what is sorely needed.
I know at least 3 programmers interested in working on Mozilla, all of whom are just totally put off by the lack of "adequate" documentation.
We need tutorials, case studies, brain dumps, diaries (.plan files?) etc etc.
I totally, toally accept Mozilla is a monstrous project and the time has been spent getting the product out. I won't wonder aloud how many programmers would have got involved if it was more accessible.
Anyway, I think it reasonable to ask for a 24/48 hr period for every developer to put something down on paper.
Maybe we could have an "adopt a developer" initiative to encourage people to help out with every programmers favorite task of doccing their code :-).
#42 Re: [INSERT TITLE HERE]
by caseyperkins <firstname.lastname@example.org>
Wednesday June 27th, 2001 9:01 AM
"There should be zero crasher bugs in the main components themselves...There should be zero bugs relating to data corruption or loss, period...There should be no memory leaks..."
Certainly noble sentiments, but I don't think God is on the Mozilla development team.
Maybe, along with the above requirement list, we can get Moz 1.0 to deflect incoming killer asteroids too... >;-)
> zero crashers > zero dataloss > zero bugs in other stuff
If we put these in the 1.0 definition document, we'd never have a 1.0. At some point, we have to say "ship it." As I said in the post, defining that point is hard because it means shipping with bugs we'd like to have fixed. Saying "zero" is merely ducking the hard question.
There is space between the Netscape 6.0 level of "1.0 software" and perfect software for Mozilla to release a 1.0 which is solid and capable. We just need to quantify, if we can, how to know when we've reached that space.
I think you've got the right idea - here are my somewhat more moderate suggestions.
1. API stability - absolutely critical. Mozilla needs to have stuff work between versions. Do whatever it takes - drop stuff or add simple implementations if necessary for stuff that's not ready. Specifically the theme breakage that happens is terrible. At least two themes were either suspended or delayed because they kept having to update them on weekly/monthly basis.
2. Documentation - ksozez's comments are right on the money.
3. Stability - right now I think the memory leaks are the worst thing. Bad memory leaks are just as bad as low MTBF because you end up closing the browser either way. The way I would quantify memory leaks that should be fixed is any that commonly occur - e.g. any memory leaks that happen every time you perform a common action like loading a page, pressing the back button, loading new windows, etc. This has to be my worst gripe with Mozilla, it really increases the system requirements. For example, last night I ran the random link buster on Linux and within 20-30 minutes I went from 24 -> 35+ megs of ram used. There are supposed to be some fixes the window (<a href=<http://bugzilla.mozilla.org/show_bug.cgi?id=84136>>84136</a>), but for some reason that ones not working for me yet. Obviously 10-15K leaks aren't too bad but when you're leaking 100K+ on every page load it adds up fast. Asking users to upgrade their ram is find for the techies, but is the target audience really going to go out and buy ram so they can run Mozilla or Netscape. I've seen very few crashes lately, but obviously any crashes or data corruption that occur frequently should be addressed.
4. Polish - got to agree with what's been posted earlier. Hard to establish criteria here, but things should work as expected, no pixel misalignments, text display errors, etc.
5. Performance - seems pretty good. One criteria would be to get Mac and Linux builds up to Windows level performance (especially interface speed). Mozilla on my work K6-2/333 is much slower in X (Deb unstable, 2.4 kernel) than in Windows. I found the Windows performance relatively acceptable for almost everything, so how about establishing this a metric. When <a href=<http://bugzilla.mozilla.org/show_bug.cgi?id=53486>>53486</a> lands, performance should increase slightly, but probably not to the level of Windows.
BTW, it would be really nice if Mozillazine had a preview button. With a text field this small it can be hard to tell if you've typed everything correctly.
the bugs should be:
84136 - closing windows leak <http://bugzilla.mozilla.org/show_bug.cgi?id=84136>
53486 - optimize unix builds with -O2 <http://bugzilla.mozilla.org/show_bug.cgi?id=53486>
#19 Usability and ease of use
by vda <email@example.com>
Wednesday June 27th, 2001 2:29 AM
>Bookmarks have improved a lot recently, but think of focus bugs. If users open links in a new window, they\\\'ll intuitively expect content area to have focus. It does not. Stuff like that is important. It\\\'s a minor issue, but annoying and user-visible.
YES!!! This is VERY important! I am a new user of Mozilla and such (easy to fix!) inconsistencies really annoys newcomers! Try to browse some local directory with .URL and .HTM[L] files with MSIE and with Mozilla and you will feel the difference. MSIE is much easier to use. Mozilla\\\'s keyboard handling is weird and incomplete.
by vda <firstname.lastname@example.org>
Wednesday June 27th, 2001 2:35 AM
And these \\\\\\\' things are a little bug in your website. Don't forget to stripslashes() if you use PHP! :-)
Er wait, if it's so "easy to fix", why don't you do it? Don't claim it's easy to fix if you can't fix it. But if you can fix it, please do.
Before I get flamed because I said "fix it yourself", this is just in answer to the "easy to fix" comment in the post to which I reply.
Fabian. (too many fix in one sentence)
Bro, vote for this bug! At least part of the problem is handled by this bug, and there are a few others. Search for file:// in bugzilla.
Standards support is the most important thing to be worked on. I thought the reason for rewriting the browser from scratch was to have 100% standards support. That way you can make a browser out of mozilla for any platform and the content is the same. Isn't that the whole point of the web?
#73 Definitely (n/t)
Wednesday June 27th, 2001 1:47 PM
Have you read any of the specs? "100% standards support" is not, in fact, a clearly defined thing. And what about bugs? Are you saying zero bugs? Which standards do you think we should have "100% support" for? Just the key ones I named (DOM0/1, HTML4, CSS1) or others?
Yes I'm talking about DOM0/1, HTML 4, CSS1. There are many tests that we can check mozilla with. There are 2 ways of thinking about standards. One is "oh good I can do some new cool web tricks" That person would accept a partial implementation of CSS3 even though it's not an official recommendation yet. To many web designers, standards means you write to the standards and not to a specific browser's quirky implementation. That way our web sites on Mac's will look the same as what appears on PC's
#26 the benchmark and the personal satisfaction
Wednesday June 27th, 2001 3:27 AM
I believe there are two sets of criteria which apply to a 1.0 Mozilla release: the benchmark and the personal satisfaction.
If Mozilla wants to go anywhere it has to beat the rest of class in the benchmark. In every aspect. Development took such a long time - if this can't be possible, something went wrong somewhere. All critics will jump on the release and compare it to the rest of the field. If you want to recapture all the lost users from IE, you should be better.
What does IE different? They're concentrating on the core product: a browser. Let me provoke: who gives a shit about some email/composer/irc/whatever application? Get the basic thing right. The rest will come. People will use the best in class. The best IRC they can get, the best composer they can get and the best browser. The browser doesn't get better by having a big footprint and carrying some email client in its back.
Instead, the browser should do its job right. Why does it seem so difficult for browsers to perform the most basic tasks: printing? I have not seen a decent solution yet - which means one can make a difference and set new standards.
Beat the rest of the field exactly there: printing (must be better than IE), fast page display and persistence between sessions (must be better than Opera), bookmarks (must be better than NS 4.x), autocomplete widget (must be better than Konqueror), cookie, pop-up and ad-blocker (must be better than Naviscope and Opera), ... this is how Mozilla's success will be measured. Do a good job at what you're supposed to do for the stupid user who just wants to browser the net a bit.
And then there is the personal satisfaction field of criteria. This seems to be the one where a lot of the Mozilla development went on: get full standards support, design some most beautiful interface language, be elegant from the inside... But frankly, the user doesn't care. These are nice to have and might prove strategically crucial - but what use is skinnability if I can't print my page?
I know, I'm provoking. But I'd like to make the point that I don't see 1.0 anywhere near. I don't see a browser that makes a big difference to the user - and that is what counts. But I do see a solid basis to get to this stage. However, this will require some priority reshuffling.
I agree totally that Mozilla needs to deliver a market improvement in order to be a qualified success. I also agree that some of the features of Mozilla are overkill to the normal surfer (ie. Composer). But I think you are completey missing the boat on the email component. My experience has always been that the surfing guru wants a slick browser (Opera) separate from their slick email program (Eudora). I.E. also works this way, but ever notice that IE's largest customer base combines them (AOL). The average internet user wants usability, not always the BEST product. AOL has grown into the largest ISP offerring a stripped down MSIE browser bundled with their email program to offer the "whole online experience". They recognize the correlation that customers want Word = typing, Excel = spreadsheet & AOL = online experience.
Hm, yes, guess you're right. I'm just fearing that the 'try to do everything at once approach' takes so many resources that in the end you have a big package of average class software.
Personally, I don't know many people using Netscape email, but quite a few people use the browser. They might then use the email client as well (or stick with what else they prefer). I dont' know anyone who uses NS *because of* the email client (or composer,...).
#140 I do (n/t)
by johnlar <email@example.com>
Thursday June 28th, 2001 12:03 PM
If you think I'm out of date here, it is because since Netscape 3 I have been prejudiced against microsoft.
I didn't use Netscape 3 because of them email, I used it because of the browser, but I did use the Netscape 3 email and have used the email which came with my browser ever since (inlcuing brief spells with Internet Mail & News, and later, Outlooks Express).
If Mozilla removed the email componant then I would seriously think about changing browsers (well, I would if I didn't hate MS so much). I just don't like the way Eudora and Pegasus work, which are the only non-browser email clients out there.
BTW we need to have a HTML edit for HTML email messages (granted it doesn't need to be nearly as good as composer).
"BTW we need to have a HTML edit for HTML email messages (granted it doesn't need to be nearly as good as composer)."
Not sure what you mean here. We've had HTML compose in Mail forever.
#166 Re: Re: Me too
Thursday June 28th, 2001 5:57 PM
I presume that you misinterpreted thelem's post as saying that HTML composing capabilities should to be added to Mail.
I think thelem actually means that bits of Composer are required for the composition of HTML mail messages (i.e. Composer is not really an unnecessary component as some people claim because parts of its code are used in, for example, Mail).
#160 Here we go again...
by kb7iuj <firstname.lastname@example.org>
Thursday June 28th, 2001 4:04 PM
"pop-up and ad-blocker"
Not going to happen. Ever. If a major browser *ever* blocks ads, you just shred a major part of what funds companies. Companies which help to pay our salaries.
#63 Best of Breed vs. Integration
Wednesday June 27th, 2001 12:38 PM
Advanced users will take the time and make the effort to install "best of breed" software, but "stupid users" want one single integrated product that does all that they want to do. (i.e. Windows and its bloated list of features.)
What many users are still waiting for is a browser that includes truly easy-to-use WYSIWYG webpage creation and publishing. If Mozilla included ftp publishing driven by a simple wizard, or could be remotely configure by an network/isp administrator, or auto-configured from a network file? If Mozilla offered end-users a publishing experience indistinguishable from saving a Word doc to a local drive? If Mozilla allowed you to email your composer creations as not an attachment but an inline document? then many users would be tempted to simplify their lives and abandoned their word processors.
I am not saying that this should be a criteria for a 1.0 release but removing or de-emphasizing work that pushes toward making Mozilla a word processor alternative is, imho, the wrong thing to do.
#122 Re: Best of Breed vs. Integration
Thursday June 28th, 2001 4:51 AM
In the future I see less people using some client side standalone software to create webpages. This is old days stuff. All you do is use your browser and to access your company portal / content management system and fill the dialogues.
Professionals use professional software like Dreamweaver with Zope or Vignette. Composer is far too simple for them.
Users in a corporate environment won't build their own pages from scratch but just fill some forms in their browser to feed some databases.
Composer caters for the 'I got a homepage as well now' type of AOL user. But even these use more and more some webpage wizards, because things like composer are too complex for them.
#92 Re: the benchmark and the personal satisfaction
Wednesday June 27th, 2001 4:34 PM
> who gives a shit about some > email/composer/irc/whatever > application? Get the basic thing right.
Most of composer is required for the browser to work. IRC is not a requirement for 1.0. As for email, others have already made the point.
People may scream and shout, but mozilla.org's position is clear. Mozilla is not just a browser, it's a framework for building web applications. Lots of people have build lots of stuff, even a web-surfing Communicator-like suite. This is cool, and helps to exercise and test the underlying technologies.
> "must be better than X"
We can't put criteria like this in the 1.0 document. You need to be more specific, and define classes of bugs that you believe should be priorities.
#123 Re: Re: the benchmark and the personal satisfactio
Thursday June 28th, 2001 5:01 AM
Ok, I didn't point at the classes of bugs but rather kept ranting so sorry for that. Here comes my suggestion:
All UI bugs have to be fixed because the user will spot them immediately and claim the browser is stupid - even if it's not.
Standards conforming display of pages is something the average user won't care about, but the critics will. The user just wants to read his favourite pages without pain. So I would put this on lower priority (and communicate this decision well to the critics).
Skinnability should be stable - once it's official the designers out there would like to create some graphics. But if the interface keeps changing, you don't want to put work into keeping your theme up-to-date. Funky skins are a good reason for some to switch the browser (or to customise it to your corporate needs).
The only other application that is probably under heavy use will be the email client, so the criteria apply for it as well. Composer, etc.. should have lower priority.
Data loss especially in email is a total killer and not acceptable.
The occasional crash might probably be expected from 1.0. Lower priority.
To get printing right would be a good reason for me to switch browsers - but that's probably asking too much.
#27 Complete HTML4 and useful quirkmode
Wednesday June 27th, 2001 3:31 AM
I really would like to see HTML4 implemented correctly and quirk mode become more of a useful feature rather than a headache for web developers and users. Moz is currently quite close to it.
The only really hard to fix bugs I can seen are replaced elements issues in HTML4 (like form element issues, iframe, applet and object), and applying inline element style stuff to block elements in quirk mode.
i.e. <font size=-1><div>abc</div></font>
One thing I\'d really like to see in 1.0 is this <http://bugzilla.mozilla.org/show_bug.cgi?id=47108> . It\'s targetted for 1.0, but of course it could be put off. I hope it isn\'t because it would really help Mozilla\'s efforts. If people try Mozilla, and see a page rendered wrongly and then notice that it is because of the poor quality of the page, then they will be more inclined to blame the page designer than Mozilla.
I think this would really encourage people to clean up their sites, and of course that would lead to better rendering in Mozilla.
I like this. I'm tired of all the "this page looks awful and I don't know what to do" complaints (and I'm guilty of them too see bug 22274)
I'm sure you'd like to see it, but would you hold the 1.0 release if we didn't have it? If not, you are in the wrong discussion :-) If so, you have to justify that.
#33 Whatever happened to Total Recall?
Wednesday June 27th, 2001 6:16 AM
Okay, so about a year and a half ago, Alphanumerica promised us a wonderful contribution to Moz - a crash recovery module, that would store open windows, and resurrect them, complete with form elements, in the case of a crash.
I understand that people want to say 'We don't want this - we want moz never to crash, so you'd never need this thing', but I'd seriously suggest that if 1.0 is still going to crash (which it surely will), the addition of Total Recall into the codebase should be given *serious* consideration. The project on mozdev seems to suggest that an XPI installer would be relatively easy to produce.
And no, I don't think this is an absurd 'We should have a word-processor included' request, especially given we were promised this functionality, what, a year ago?
#53 Re: Whatever happened to Total Recall?
Wednesday June 27th, 2001 10:59 AM
Total Recall has just been updated to work with the latest builds. You can get it from mozdev.org.
I know Mozilla crashes a lot for me, but that's because I'm doing funky stuff with it all the time.
Something that hasn't been mentioned, but I think is *very* important, is security. If you need one compelling reason to use anything-but-IE on Windows, it's not that IE is produced by Microsoft, it's that IE effectively gives anyone on the internet complete access to your computer. Moz 1.0 should have NO known security holes (fairly obviously), and should be sure to continue to warn people when they're about to do stuff (installing things) that could compromise security.
Probably this hasn't been mentioned because everyone takes it for granted that Moz is secure, but if we're driving towards 1.0 we mustn't forget the importance of this, and mustn't compromise it.
That's a good point, and a very important area we have so far neglected.
This is one we could probably leave on mstoltz' plate - he has to sign off on Mozilla not having any known security holes before we can declare 1.0.
Is there a paper on the security implications of XUL? Remote user interfaces have the potential to facilitate login spoofing attacks, as well as remote access to dangerous local APIs. I'm sure this has been looked at, so I'm just asking where I can follow up on the issue. Thanks.
There is some coverage of XUL security here ( <http://www.mozilla.org/rd…hat_is_the_security_model> ), as well as this paper ( <http://www.mozilla.org/pr…ty/components/design.html> ) from early June of this year.
This also implies that anyone running Mozilla is vulnerable to exploits through these mechanisms, since these safeguards have not yet been put in place.
I'd like to hear the answer that it's not really that bad, so please feel free to correct any errors I've made in reading these pages. For instance, it may be discussing things in a way that makes them look like they're for the future, when in fact they're already implemented.
When you say ``it may be'', do you mean that
People running Mozilla may well be vulnerable to security flaws (bug 83038 was present in 0.9.1, for example), but we're pretty good about fixing them for the next release. If you're bothered by the possibility of there being security flaws in your browser, perhaps running pre-release Mozilla builds isn't the right thing for you. (I expect that we'll be much more likely to do fast respins for security issues once we get to 1.0.)
I have no comment on any Netscape 6.x issues, and I wouldn't share such comments here if I did.
I think I was clear enough, first in asking the question "Is there a paper on the security implications of XUL?" (not for the first time here), and then in stating that I was unsure how to interpret the documents that I found for myself when no one answered: "it may be discussing things in a way that makes them look like they're for the future, when in fact they're already implemented."
The reason I was unsure how to interpret the policy document is that it uses tentative phrases like "I am proposing" and "Mozilla should," which makes it unclear whether this is someone's own ideas or actual policy. This ambiguity is why RFCs are careful in using terms like "MUST" and "SHOULD."
Since then, I've looked in Bugzilla and I see that there are definitely ongoing efforts in the areas of preventing spoofing and firewalling dangerous APIs. I can't tell how complete they are, but clearly some work has been done, which confirms my original observation, "I'm sure this has been looked at, so I'm just asking where I can follow up on the issue. Thanks."
I am still quite confused as to the state of the policy document at <http://www.mozilla.org/pr…ty/components/design.html> , which proposes restrictions such as "No web-based XUL" and "no downloadable chrome". I've found Bugzilla bugs from this year which relate to both of these features, which according to the policy document are supposed to be forbidden. Are they forbidden or allowed? Is the document policy or suggestion?
It also appears from my Bugzilla search that Netscape 6.x and Mozilla 0.9.x versions have gone out with significant security holes, which I speculated might be the case. It's all very well to patch these, but in practice the end user installed base is likely to adopt such patches at a very slow rate after the first stable release. The fact that they are made public in Bugzilla means that Bugzilla is a source of useful information to people looking for holes in recent browser versions. Advocates of open source have claimed that open source makes for better security. That may be true in some ways, but this shows one way in which open information charing can actually harm security. To document security bugs in currently-used browser versions is to facilitate exploits.
It might make sense to change the current policy -- making security bugs public after they are fixed -- to incorporate a time-out linked to the observed upgrade cycle, so that only security bugs in now-largely-disused versions are made public.
#35 Why can't Mozilla be as fast as K-meleon?
Wednesday June 27th, 2001 6:57 AM
I dont really like K-meleon but i have noticed its render pages far faster than Mozilla and even faster than IE,
What is the diffrece that makes K-meleon to be faster than mozilla? aren\'t they use the same engine?
#154 Re: Why can't Mozilla be as fast as K-meleon?
Thursday June 28th, 2001 2:32 PM
The difference is that K-meleon uses a minimalist UI where as Mozilla has a rather large one.
K-meleon shows a more true representation of what Gecko can do when a system isn't bogged down with the Mozilla UI.
#36 Criteria for 1.0
by pallando <email@example.com>
Wednesday June 27th, 2001 7:24 AM
Gerv has asked what our criteria should be for choosing when something is ready to go out the door as Mozilla 1.0
There are many things I\'d like to see get into a release as soon as possible (email encryption, jabberzilla, mathml), but they arn\'t relevant to Gerv\'s question.
When we label a rease as 1.0 we are saying two things.
1. We are saying to potential users \"This is no longer Beta software. We want you to use this release, and give our word that it is fit for using as your main workaday browser.\"
2. We are saying to potential plugin developers and website writers: \"This is now stable software. Anything we put out the door from now on is going to be backwardly compatible with this release. You are safe to go ahead and develop to these technologies and APIs.\"
From this, I\'d have thought it obvious what our criteria need to be:
1. Benchmark the Mozilla user experience against other leading browsers (IE 6.5, Opera, Netscape 4.x). Round up some novice internet users (your old granny) and monitor 100 hours of use. What\'s the average number of crashes? The average time to load a page? The average time to learn a new feature? Create a metric from these numerical criteria that best approximates The User Experience. And don\'t call it 1.0 until the Mozilla user experience is at least 95% as good as the best.
2. Freeze the APIs and include all technologies that you have advocated that developers _should_ use as the way to do things that they can already do with IE 6.5
This is really part of "usability", but it's a part that's readily specifiable. Basically, when installed on platform Z, Mozilla 1.0 should (1) install the way most things install on Z; (2) launch the way most things launch on Z, and (3) be controlled the way most things are controlled on Z.
Examples (all from Unix, where I use Mozilla): instructions insist that each user must have his own copy, vs. all other software is shared; mozilla ignores -geometry unlike every other X Window application; mozilla ignores /etc/mailcap and ~/.mailcap unlike every other multimedia application (this is being worked on, hurray!).
#71 Re: Platform integration
by krmt <firstname.lastname@example.org>
Wednesday June 27th, 2001 1:38 PM
I agree totally on this one. The geometry thing is really annoying, although the one copy per user thing doesn't affect me because of the outstanding packages in Debian right now. I'd also like to see an option to fire up something like mutt, kmail, or evolution instead of Mozilla's email client. Unix philosophy and all.
My big one for the Mac is the key command to switch windows, due to the Mac's particular windowing system. It's one thing that makes me want to use IE instead of Fizzilla on OSX, even though Fizzilla outperforms the IE preview by a lot.
#221 Re: Platform integration - not just Unix
by vcs2600 <email@example.com>
Saturday June 30th, 2001 11:15 AM
There are platform integration issues on Windows and Mac as well. For example, the mailer issue is something that IE does (almost) right but no version of Netscape/Mozilla has ever handled correctly.
(The mailer thing has always been a particular pain in the ass because in a corporate setting there isn't necessarily a generic SMTP mail server available to users. My shop is on Exchange for example, with the SMTP gateway inaccessible in the DMZ. The admins shouldn't have to change the infrastructure and server configs just so I can run Mozilla.)
#43 Simple algorithm for establishing 1.0 criteria.
Wednesday June 27th, 2001 9:02 AM
This is easy. At some arbitrary point in the near future require _all_ employees of Netscape (including marketing, office workers and CEO) to use the latest build (say 0.9.3).
Within days, the important criteria for a successful 1.0 release will have been screamed into the QA teams ear from neighboring cubicles.
#54 Re: Simple algorithm for establishing 1.0 criteria
Wednesday June 27th, 2001 10:59 AM
Excellent Idea! The animal food will be easy to spot.
#85 Re: Re: Simple algorithm for establishing 1.0 crit
Wednesday June 27th, 2001 4:19 PM
That should be done with computers that have 64 megabytes of RAM.
#170 Re: Re: Re: Simple algorithm for establishing 1.0 crit
Friday June 29th, 2001 1:31 AM
No no, what was I thinking, far better to hire a team of employees to analyze the issue, consult with focus groups and produce a vast and detailed report..
#193 Re: Simple algorithm for establishing 1.0 criteria
Friday June 29th, 2001 11:03 AM
Believe you me. Some of us are working on that where we work...
I propose a major push to check in or discard existing patches. At last check, there were over 450 open bugs with the patch keyword, which translates to 450 bugs that at least someone thinks they've fixed. These patches arr from outside netscape.com, and sometimes it can be difficult for outsiders to get a review and super review, or even any attention at all. It would be cool if the major project contributors could set aside a week or so to comb through the existing patches. This might fix a lot of issues!
#216 numbers look very wrong to me
Friday June 29th, 2001 8:28 PM
Can you please post a query here which shows all of the (450 or so) patches which have not been checked in yet and were submitted by people not at Netscape. I'm fairly comfortable with queries in Bugzilla and no matter how many times I try I can't come anywhere near the 450 hits result of your query. I've actually been working on tracking this kind of information since early in the year and my numbers don't look anything like yours. My numbers generally show that there are about 3 or 4 patches which have not received the attention that they deserve. If you found 450 then you're in possesion of a goldmine that I'd like to get my hands on.
As far as I know you cannot query for attachement <data|description> changed by sub-string or regexp (for example @netscape.com or not @netscape.com). If you have found a way to do this please share it with me. It seems to me that the boolean tool only allows you to query for exact matches on "changed by".
And how did you determine if the patch was attached before the bug was reopened? Many of the open bugs with patches were fixed by those patches and then reopened and the patches are no longer relevant.
Also, If you got that far can you tell me how you determined which patches were not in the r= or sr= state of being reviewed. I worked really hard to try to develop a query that would show bugs which have comments of one thing (ex. [sr]=?|r=[a-z]) but not comments of another (ex. r=[a-z]|sr=[a-z]). The problem there is you cannot query for bugs where _no_ comment contains some string, you can only query for bugs where _one_ comment does not contain some string. So if you were to query for all bugs that had one comment that contains r= and one comment that does not contain sr= you effectively end up with the same first batch of bugs that contain r= since it only takes one comment not containing sr= to result in a hit (most bugs have one comment that doesn't contain just about every string).
And then there's the whole problem of determining if the attachment is even a patch. You cannot rely on "Attachment is patch equal to 1" since there was a bug in Bugzilla which treated all attachments as patches for a period of time. And you cannot rely on the patch keyword since it is applied so randomly (along with the review and approval keywords). I did find a couple of queries which could narrow it down quite a bit but there were still false positives. (attachment data contains certain strings like @@@ and ++, etc.)
Then there's the whole problem of patches which simply didn't pass review or were rejected as incorrect immediately (and even by their author in some cases).
Like I said, if you have come up with methods of query which work around or solve these issues please let me know. I would very much like to be able to better track this info in Bugzilla. (It should all get better when myk's attachment manager addition to Bugzilla lands but that won't help us with the existing attachments).
Oh God please help us! No! A more complete CSS2 implementation is not what Mozilla needs at this point. It also doesn't need modularization or complete HTML 4 support. Nor does it need XSLT, SVG and other stuff like that.
One of the few posts that got it right, IMHO, is the first one in this thread by NilsE. What Mozilla really needs is to polish the end user experience. This includes things like 100% consistent user interface from installation, through the browser and all the way into the last dialog. It includes things like pixel precise margins, borders, layout, icons, no typos... It includes not just looks but feel. If a tree node takes one click in bookmarks to expand, it should take one click in every other tree in the app to expand. The upper-right edge of each tree or table should be identical. Clicking on form fields should not resize them and reflow the page. Text should be properly aligned inside form fields. Etc. etc. etc..
These kinds of things (in one word "polish") is what is needed in order for people to get the feeling that they are dealing with a good quality product. The fact that Netscape 6 shipped without this polish surprised me majorly. I can understand things like crashes or non-complete CSS2 implementations.. That's like selling a car with slightly less horsepower than planned. But lack of polish is like selling a car with scratches in the paint.
We need to get the scratches out of Mozilla!
#47 Mostly agree....
Wednesday June 27th, 2001 10:23 AM
There's always a strong temptation for the "techies" to want every possible feature. That needs to be resisted. The typical user isn't going to care whether Mozilla has complete CSS2 or HTML4 support. You _do_ intend to make another release after 1.0, don't you? Some of this could wait.
User interface polish is VERY important for the end user, and something that most techies tend to ignore. They shouldn't if they want to build something that people will actually want to use.
My primary disagreement with macpeep is that there needs to be a continued attention to stability, that's also an issue that can be pretty visible to a lot of end users. As has been noted elsewhere that's something where perfection is probably impossible, but it's worth making a serious effort to make continued improvements in that area.
I think I sounded like I thought stability wasn't important.. That's not the case at all. I value stability far above features and just slightly below polish. In a way stability IS polish too..
In order to 'advocate' use of Mozilla and commercial offshoots, the user experience must be exceptional in the initial release.
Let us all learn from the company which members have a variety of, good and bad, feeling about; Microsoft. Their product may not be complete, but it is polished and somewhat bugfree.
So I agree that user experience is very important.
My second criteria would be stability.
Third criteria, the ability to download updates without having to download an entire new release. Users, like my parents and other non-techies, cannot and will not download newer releases unless an easy 'Update' feature is built in. Good examples are the Windows Update and Symantec's LiveUpdate feature.
The worst offender, IMHO, is the Status Bar at the bottom of the page. It seems to say whatever it feels like saying, regardless what Mozilla is actually doing. Doing a search for 'Status Bar' in bugzilla <http://bugzilla.mozilla.o…us%20bar&cmdtype=doit>
shows some of these; It's this kind of stuff that irritates the end-user: "Is the remote site down? Is the name resolved? Is it Mozilla that's hanging up here? Grrr, I'll fire up another browser"
As a user, the flow of the application should be emphasized for 1.0. Such as the much maligned focus bug, but more in general, being able to go through parts of the application, both browsing and menu items, w/o having to, work around an issue. Rendering isn't that big of a deal at this point. Those are issues that can be worked on w/o the user noticing the difference (as much as say, having to press 'cancel' because 'ok' doesn't work). But now is the time to convince others that this is a usable browser. I don't even care about mail/irc/news, etc, either, though that's certainly my opinion. I should be able to browse at my leisure w/o ever wondering 'why did that not work?' or 'why did I have to do it that way?'
The stability issue is almost gone. I've had one crash since .9.0 came out.
It's time to make others know that Mozilla/Netscape is (still) a force. The features that Moz offers (such as security manager) simply blow IE6 away. While rendering is still an issue, that'll be a mix of bad page coding and browser bugs for some time, but this is finally a browser that can be considered 'better' than its competition.
Beside that I personally see the need of some _just cool techi_ features, I agree that mozilla needs a little bit ui polish.
but it shouldn't go to wild. I think if a few things in moz1.0 don't fit of one or two pixels it's ok.
#61 Car metaphor
Wednesday June 27th, 2001 12:28 PM
Personally, if a car advertises itself as having a certain horsepower, but when I buy it it turns out to be a lower horsepower than advertised, I'd be pretty pissed. On the other hand, I wouldn't care too much if there was a scratch in the paint job (of course, if the paint was flaking off I'd be pretty dubious, but Mozilla's UI is nowhere near that bad).
I can always paint the car. I can't make the engine more powerful without some serious nuts-and-bolts customization.
I'm using the latest nightly build right now - downloaded some 10 minutes ago. When I logged into Slashdot, and clicked on the username field, the cursor was placed about 2 cm to the right of the left edge of the textfield and the screen reflowed and the textfield jumped about 5mm up. When I started typing, the cursror jumped to the left.
Right as I'm writing this, there's an empty line above this, but when I start typing, the R in right is moved down a full row and I end up with TWO empty rows between the two paragraphs.
When I type c:\ into the URL bar and press enter, I get a blank screen . When I type d:\ and press enter, I get a directory view with directory icons that are totally unlike any other directory icons in the app. When I re-type c:\ and press enter, I get the contents of the c-drive.
Writing an email earlier, as I was typing, my Win2K task manager showed up to 20% CPU usage. When I stopped typing, it came back down. I could *feel* the slowdown, which is why I checked the CPU usage. Now that I'm typing, it seems fine and another email I typed also seemed fine.
The summary file for my trash folder was created twice in a row, even though it appeared to have been built just fine the first time around. Having said that, the app feels much MUCH better than the nightly build I downloaded about a week ago. Mozilla has only crashed once (a lockup actually) and that was when I went to the ABC site to play "Who want's to be a millionaire", which seems to be a Flash game or something so I won't hold that against Mozilla.. too much anyway... In fact I just sent an email to my brother recommending that he tries the latest nightly build because it's the first build that I could contemplate using as my primary browser.. If only the issues I mentioned above, and the many others like those, would be ironed out first.. POLISH.. Get the metaphor now gwalla?
#144 Re: Re: Car metaphor
Thursday June 28th, 2001 12:30 PM
I should note that you never actually used the metaphor in your last post.
I understood what you were saying. I just think that it's a bad metaphor.
I also don't think it's worth going back on promised support (Mozilla *guaranteed* support for the basic standards by 1.0).
> A more complete CSS2 implementation is > not what Mozilla needs at this point. > It also doesn't need modularization or > complete HTML 4 support. Nor does it > need XSLT, SVG and other stuff like > that.
Are you replying to the article? The only one of those things that my article advocated was complete HTML 4 support, and that's because we've been promising it, and people have been demanding it, for years. Do you believe we should break that promise?
#112 Re: Re: Wrong, wrong, wrong!!
Thursday June 28th, 2001 3:01 AM
"Are you replying to the article?"
Well, my reply was on the root level, but I was replying to the community on a whole, not the actual article.
Just because I think UI polish and a feel of quality and stabilty is important doesn't mean that I don't value standards support such as HTML4, CSS 1, 2, SVG etc. You ask if we should break the promise of delivering full HTML 4 support. Well.. if that support means that the UI will feel like a toy, like it does now in some ways, then yes.. break the promise and fix the UI! In a way, there's an implicit promise to ship a polished product and by releasing a product with a UI as unpolished as it is now, you'd be breaking that implicit promise. Do you believe we should break THAT promise?
"Well.. if that support means that the UI will feel like a toy"
There is no deadline for Mozilla 1.0. It will be released whenever we decide we've achieved all we want for it. So, these two things are not mutually exclusive.
Another reason they aren't is that different engineers work on each. :-)
#217 Re: Re: Re: Wrong, wrong, wrong!!
Friday June 29th, 2001 8:53 PM
"In a way, there's an implicit promise to ship a polished product". I don't think this applies at all. When mozilla.org declares some Milestone (in the not too distant future) to be 1.0 it is not "shipping a product". Netscape is shipping a product when it releases something like Netscape 6.x. Commercial distributors ship products. mozilla.org is building a technology. When it is declared 1.0 it will be because it is ready to be consumed by commercial vendors/distributors, embedding interests, app builders and some open source power users who just like using non-commercial software. The linux kernal isn't "a polished product". It is a piece of technology that when bundled with other technologies and packaged up by distributors like RedHat and Caldera makes a "polished product". I don't know that I've ever seen mozilla.org issue a statement that it was going to "ship a polished product" and I don't know that shipping a product even makes sense in our system. If it does then we've been shipping a product every day for the last couple years. That's not to say that I'm against polish. Polish makes it easier for vendors to slap a brand on Mozilla and have a decent product. The easier we make it for them the more vendors step up and do distributions. The more distributions the more mozilla user agents there are on the web. I think polish is a fine thing. I don't think that it is the only or even the most important thing. --Asa
#225 Re: Re: Re: Re: Wrong, wrong, wrong!!
Sunday July 1st, 2001 3:00 AM
You're right in that, in theory, Mozilla doesn't need to be polished but the actual releases (Netscape, Nokia etc.) should be.
Unfortunately the truth is that Netscape has done next to 0 polish on top of the UI that Mozilla provides. As far as other actual releases go.. well, I haven't seen any other, except very limited browser-only products that have tossed out everything except Gecko.
Netscape's release, in a sense, is *THE* release of Mozilla and since there's no added polish by Netscape, Mozilla needs to be polished. Sad but true..
#226 Re: Re: Re: Re: Re: Wrong, wrong, wrong!!
Sunday July 1st, 2001 11:18 AM
You should take that arguement to Netscape and other distributors then. Mozilla should not be your prsonal backdoor to Netscape management. Saying that because Netscape isn't catering to its audience means that Mozilla has to start catering to a completely different audience (Netscape's) is like saying that because the Campbell's soup company has really ugly soup cans no consumer would want that all the mushroom growers and tin can manufacturers have to become graphic designers and provide cambell's with the soupcans, the mushrooms and the can labels.
I'll say it again. I'm all for making the task of doing a distro as easy as possible and that means, in part, that Mozilla needs to make a usable codebase that doesn't require a lot of extra tweaking. But to say that pixel perfect UI is a stopship for 1.0 is completely rediculous.
I think a good guide to using Mozilla would go a long way to showing off it's merits. I feel like it's already beyond most other browsers.
#51 documentation more important than one would think
Wednesday June 27th, 2001 10:46 AM
As a developer myself I know what a drag it is to document your code. The difference here is that it is almost impossible to come in out of the blue and jump into this project with any sort of speed. When Moz was only at M8 (!! Wow, it's come a long way !!) I began following it regularly, and was very interested in helping out the cause. After peaking at the code and trying to decipher cryptic classes and references without any detailed info, I put that idea on hold. I even thought about applying for the internship that NS offered a couple years back (I'm a senior at the University of Vermont now). Anyway...I think that with all of the good points above, and the talk about NS dev team working on a 0.9.2 exclusively, if any more outside help is wanted, better doc and brain dumps are going to be necessary...
#59 XP Speed
by BryanH <BryanZx@excite.com>
Wednesday June 27th, 2001 11:51 AM
Mozilla needs cross-platform speed. Plain and simple. It needs to out-run IE on Win and Mac, and at least out-perform Netscape 4.x on Linux (and it doesn't right now). Moz used to load things immediately, but now it delays until the full page is loaded. We need to realize that some servers are slow and will never deliver all the images or whatever it may be waiting for. If we can get the memory footprint, stability, and speed issues resolved, then we can define a Mozilla 1.0.
Actually, mozilla renders the pages every x seconds (I think it is either 5 or 10).
This is because on fast connections, constantly re-rendering the page when each packet arrived caused a serious slowdown in rendering time.
#65 3 Things Matter: Documentation, Documentation & Do
by ksosez <firstname.lastname@example.org>
Wednesday June 27th, 2001 12:50 PM
(Ran out of room in the topic) :)
Anywhere here we go, Before 1.0 is released we *MUST* have better documentation. I don't care if we have to stop all the developers for 24-48 hours and have people take notes while they talk we need better documentation.
I know its hard and not the fun part of development (trust me I have done my fair share of development too and I hate documentating stuff) but in order for Mozilla to continue to be successful we need to have more help for people who want to get involved/patch and this means documentation.
The reason I say this is because the way I view open source projects. Open source projects start very small usually with only a few people working on it, as more people hear about it and get involved they tell there friends and so on. At a certain point you reach a critical mass where so many people are working on it the development starts to out pace any commercial development project on the planet. However Mozilla *cannot* and will *not* reach that point until we have better documentation.
As one of the largest QA contributing people outside of the Mozilla and Netscape organizations I must say its quite frustrating to have people want to help out only to have no way to help them get started coding besides just looking at the code and patching a bug.
In addition if Mozilla is going to be built upon by other organizations (for cool plugins or whatever) we need to have how the internals work documentated or it will be a moot point.
So again i Say.....sit the developers down for 24-48 hours and have them spill how everything works and then throw it up on a webpage and format it as we go along. This will help tremendously, and I am available to take notes. :)
#116 Reduce the need for ducumentation!
by rydstedt <Rudolf.Rydstedt@svenska.gu.se>
Thursday June 28th, 2001 3:52 AM
I do agree that Mozilla neads better documentation, but that's not always a strong argument for writing a lot of text that has to be translated in a lot of languages. Sometimes, it's much better to change Mozilla in a way that reduces the need for documentation.
In the post 1.0 era that means that it would be nice if people who are making decisions about arcitecure etc. asked themself "Which alternative is the most simple to explain". For the moment it means that it makes sense to concentrate on bugs that complicates documentation.
I am actually a programmer, with about 10 years experience in the industry (java, c, but sadly not c++). There are a lot of bug's I'd like to have a go at fixing, but I have no idea even where to start looking in the code. Even something as simple as a block diagram showing how the various parts of the code fit together, e.g what function gets called first, what is the flow when a user clicks on a link - would be a good start. What do the various string classes mean in mozilla - there seem to be an awful lot, with no explanation of which to use where. How do you read preferences. Things like that, so that people who know how to code could at least look in the right area and then get some idea of what mozilla is doing.
I think if even this basic level of documentation were available, you would find the number of patches increase dramatically.
Another idea you could use is a wiki wiki web <http://c2.com/cgi/wiki> - basically editable html. Then as people discover more about mozilla they could document it themselves. You've made the code open source, so why not make the documentation open source too ?
>>There are a lot of bug's I'd like to have a go at fixing, but I have no idea even where to start looking in the code.<<
Likewise. In response to all the "fix it yourself" stuff we keep hearing, I thought I would take a look at what it would take to fix some of the UI bugs I noted recently. I couldn't even find the preferences dialog. I went through a bunch of XUL, RDF and CSS files that I got by dezipping every JAR file in the Mac distro but I couldn't find the damn dialog for the life of me.
If Mozilla ever actually becomes a viable browser, then I'd love to be able to play with the browser interface and integrate utility functions into the main browser UI. But it's such a behemoth I have no idea where to even start.
come to #mozilla or #mozillazine on irc.mozilla.org and maybe you'll find someone that knows what you are looking for
No, thank you. IRC is the biggest drain on productivity since USENET.
I should be able to find a dialog in the source code without having anyone hold my hand. As it is, the XUL files I went through seem to be almost entirely devoid of comments.
Those of us who have no intention of wasting our days and nights in inane chat rooms with programmers are second-class citizens in the IRC-based open source world, unfortunately. It's time for the open source community to lose the attitude that "I don't have to comment it -- I'm available on IRC if you gotta question."
#69 UI Polish
by Brendon <email@example.com>
Wednesday June 27th, 2001 1:15 PM
Macpeep has a point. Standards support is nice, same with new features, better performance and more stability.. but seeing the many small quirks in Mozilla's UI is not acceptable for a 1.0 release.
Get the UI sorted out, then the top crashers and finally performance. Mozilla 1.0 doesn't need any more features than it has now. Granted, it would be nice to see a few of the many nifty little features filed in bugzilla but when you see the UI shifting a few pixels under your mouse cursor.. it's not going to give a good impression.
So, UI polish is top priority, then top crash bugs, performance in relatively slow area's and finally documentation.
UI polish and documentation are a must for the 1.0 release. Crashes would become even less important (for the 1.0 release) if Total Recall could be included.
BTW, why _is_ it not included?
It's gratifying to see everyone (except Gerv) prioritizing UI polish so high. As I noted a few weeks ago, I was able to find about fifty UI bugs in ten minutes of use.
I just want to reiterate a point I made then that wasn't much noticed. It's not good practice for people to be checking in code with obvious UI problems (like text clipped off the edge of windows) in hopes that someone else will fix it later. There needs to be a cultural change where people do not check in their code until it is user-ready. Otherwise there is just going to be a never-ending string of these problems.
Good software engineers know that their bugs are their own responsibility, and no one else's. One of the most pernicious aspects of the "Cathedral and the Bazaar" model was ESR's feeling that it was OK to make lots of mistakes, because other eyeballs will fix them later. That is the kind of thinking that puts software in the situation Mozilla is in now. "Polish" (that is, not making obvious errors) needs to be an ongoing priority, not a late-game push.
#104 Re: Re: UI Polish
Wednesday June 27th, 2001 8:52 PM
I'm not sure I would go so far as to say that every checkin should have a wonderful UI from the very beginning ... especially if it's necessary for other developers to access settings in the dialog (or whatever) for their own projects. However gross problems such as clipped buttons and the like _should never occur_.
But if anything with poor UI design _is_ checked in, the item that generated it can't be marked "fixed" and it needs to be bubbled to pretty near the top of the stack for the appropriate developer. The Mozilla project has seemed to allow some of these monstrosities to exist for weeks or months on end ... this is amateurish.
I think we are missing a point. Of course UI IS importantant. But in most of the cases ui issues will be dealt by different engineers than those working on say mail/news or working on improving the browser.
However having said that UI is important especially for the 90% of computer users who will judge a program by how it looks. If mozilla and hence netscape looks cool they'll give it a go and then might discover how good it actually is. If it looks bad like the first modern skin , they will not even bother with the browser.
#198 Re: UI Polish
by nfisher <firstname.lastname@example.org>
Friday June 29th, 2001 11:34 AM
I agree that UI polish should be a top priority.
Ever seen sites that use hyperlinks that look like regular text? They look like links (blue, underlined) only when you move the mouse over them. These make the site annoying because links are harder to find. It's features for the sake of features.
And now the Mozilla Personal Toolbar is doing the same thing. It's copying a bad web design trick. Even if it's not bad web design, is it really a good idea to make the Toolbar behave like a web page? I think it just makes it more confusing to new users.
#72 GNKSA Compliance
Wednesday June 27th, 2001 1:42 PM
Gerv mentions that 100% GNKSA compliance might be a good goal, and says that the relevant tracking bug is <http://bugzilla.mozilla.org/show_bug.cgi?id=76449> . That bug is actually for minimal GNKSA compliance, not 100%. 100% compliance is tracked by <http://bugzilla.mozilla.org/show_bug.cgi?id=12699>
Just a minor correction. 100% GNKSA compliance would be an admirable goal for 1.0.
Given the pace of work so far on the relevant bugs, I'm not sure that it could be achieved in a reasonable amount of time. Then again, if it was a requirement for 1.0 they might get more attention and get fixed much faster.
#77 Cut the bull or put the bull in?
Wednesday June 27th, 2001 2:19 PM
For starters, I don't see any vagueness when I say "Make it as fast and small as IE 5.5 - both for page loading time and for startup time". Anyone think that can't be checked off a list?
I think a lot of the goals outlined here are rediculous. So I've put together a new list. I'm calling it:
Joe's list of I hope they don't listen to Gerv for 1.0.
1. use voting - I hope that voting doesn't come into the checklist at all. I see no reason to treat voting as anything different than what it's meant in the past releases.
2. don't set a performance goal - this goes against the number 1 complaint against using Mozilla; so, you better set a performance goal, and you better try to hit it.
3. CSS-isation of Composer - I've been told this means changing html bold elements into something like div's with style=bold. Won't this just make the HTML output less readable on older browsers? Can't we give composer something better to shoot for?
4. Good Net-Keeping Software Award. - raise your hand if you think consumers care. while your at it raise your hand if you think mozilla 1.0 is for developers rather than users. ;) Again, I think we can come up with a checklist for mail that people really care about. If we're going to add more features into Mail (as achieving this award would require) why don't we try to implement something useful like system tray biff notification?
5. Full standards support. - This is a hard one. But, seeing how there is soo much more to work on; I'd have to say that "most standards support" should be good enough. As long as we support more than the competition, and we don't have any broken standards support (we don't want people's web page code to break when we fix our bugs) - then we should be ok.
6. Build system cleanup. - you can already selectively build individual components. Anyone think that we'll win more than 2% of the market with this one? :P
2. Make it as fast and small as IE 5.5 - both for page loading time and for startup time. Does this sound vague to anyone? If it's vague I'll gladly point you to charts that are sent out regularly within my company that address Mozilla's speed on a week by week basis, as compared to IE.
> Make it as fast and small as IE 5.5
This misunderstanding must end some day. IE isn't small (although it's UI is faster than Mozilla). It *seems* to be small because of OS integration (partial preloading). There's no way to measure it's actual footprint.
Voting isn't regarded as a reliable measure of user's acceptance (this is what developers and qa people think), so why it still exists in Bugzilla? Let's get rid of it.
#158 Re: Wholeheartedly agree except...
Thursday June 28th, 2001 2:57 PM
> Voting isn't regarded as a reliable measure of user's acceptance
No, voting isn't regarded as the best way with which to set priorities. Lets say you have one bugs with 100 votes that will take a team of 10 a month to fix.
Lets say you have 50 bugs, each with 2 votes that will each take an hour to fix.
Which would you suggest gets fixed? Which is a more productive user of developers' time?
Of course any bug with 100 votes should be fixed or marked wontfix after long discussion, but not necessarily as a priority over all other bugs.
#98 Re: Cut the bull or put the bull in?
Wednesday June 27th, 2001 4:49 PM
"Make it as fast and small as IE 5.5 - both for page loading time and for startup time".
How do you measure the size of IE 5.5? Also, why should a Linux Mozilla user (or someone on any other OS) care about performance in relation to IE 5.5? Why pick version 5.5? Do you use Mozilla's -turbo to mitigate the IE preloading factor or not? Do you take into account that Mozilla may be doing far more with a page (supporting <LINK>, doing hover correctly) than IE? How do you do proper metrics on things which take fractions of a second, when you can't compile IE with timing?
"you better set a performance goal, and you better try to hit it."
What do you suggest? If we only _try_ to hit it, what's the point of having it at all? Would you hold the 1.0 release if the performance figures were a bit off those you'd pulled out of thin air but everything else was in place?
" I think we can come up with a checklist for mail that people really care about."
Go for it. That would be great. We need one.
""most standards support" should be good enough."
Mozilla.org has made promises in this area; would you be happy with breaking them?
#101 Re: Re: Cut the bull or put the bull in?
Wednesday June 27th, 2001 6:13 PM
"How do you measure the size of IE 5.5?" Why don't we start with the download size?
"Also, why should a Linux Mozilla user (or someone on any other OS) care about performance in relation to IE 5.5?" Just because they're not running an OS with Windows doesn't mean that they should accept a browser that is slower than IE5.5 on a comparable win/mac system.
"Why pick version 5.5?" Why Not? You have to pick some target. I could easily retort every target you make with "Why pick that?", but doing so doesn't produce any valuable concerns.
"Do you use Mozilla's -turbo to mitigate the IE preloading factor or not?" Personally, I run with the -turbo option. But again, you set a goal, and you hit it. If you say "startup time should be as fast as IE with the -turbo option" then you hit it. If you decide to set your goal differently, then you do so.
"Do you take into account that Mozilla may be doing far more with a page (supporting <LINK>, doing hover correctly) than IE?" Do you take into account that IE supports other features that Mozilla does not? Like favicon.ico. Of course not. Zdnet's ibench doesn't take that into account, and neither is any other benchmark program. I can't reiterate this enough, "You pick a goal, and you hit it"; goals can be so simple. Like, "beat IE 5.5 on machine X in Zdnet's ibench".
"How do you do proper metrics on things which take fractions of a second, when you can't compile IE with timing?" In that case, how does any timing benchmark ever get created? Did you know that they do happen, regularly? C|net posted benchmarks for page loading. This is no big technical feat.
"What do you suggest?" I suggest that you pick a benchmark and beat IE in it. Any benchmark. I know my team regularly puts out benchmark results versus AIM 4.3 (I work on the NIM sidebar in the commercial arm of Mozilla).
"If we only _try_ to hit it, what's the point of having it at all?" What's the point of having any guideline? Are you really going to freeze the API's? (probably not) Are you really going to achieve 100% Good Net-Keeping Award? (probably not). Everyday mozilla engineers are asked to triage their bugs to the milestones they think they can fix those bugs by. Why bother (you might ask)? Since they're not going to hold the release for all the bugs! Why not just ignore the milestone field in bugzilla until the bug is actually fixed, then go back and set when the bug really was fixed! The reason, because we *want* to try.
"Would you hold the 1.0 release if the performance figures were a bit off those you'd pulled out of thin air but everything else was in place?" I take offense that you say I pulled performance figures out of thin air. For starters, I never mentioned any performance figures. But if I were going to use performance figures, they wouldn't come out of thin air; and I would hold the 1.0 release to hit those figures, just as much as any other guideline.
"Mozilla.org has made promises in this area; would you be happy with breaking them?" Mozilla.org never, in the beginning, promised a 1.0. Mozilla was, originally, meant as a developers browser, not meant for the consumer. Since that has changed, Mozilla has decided to also promise a 1.0. Anyone remember the Milestone system before this? M1 - M30, with really no end. So if you want to know if I think it's okay that Mozilla break it's promise. Ask the WSP. One of the promises was about developing a browser in a reasonable amount of time. Why don't you read <http://www.mozilla.org/apology.html> for a good idea of what mozilla.org promised (for a 5.0, note that Mozilla 1.0 had been acknowledge as having only taken 7 months to ship!). Or read <http://groups.google.com/…c=1&selm=an_353682358>
In short, yes. I think most people would be happy if Mozilla delivered what they promised long ago.
#108 Re: Re: Re: Cut the bull or put the bull in?
Thursday June 28th, 2001 12:49 AM
My point has always been not that it is hard to set goals, but that any goals you set will be totally arbitrary. If I say "Why IE 5.5?" and you say "Why not?" then I'll say "then why not Netscape 6" and we can do all our performance criteria relative to that.
"Why don't we start with the download size?"
Which download size? Mozilla has a net-based installer so you just download what you want. Full download? Mozilla includes far more than IE. Just the "browser"? Mozilla's "just-the-browser" contains a bunch of stuff IE doesn't touch (RDF, for example) and does a whole lot more - it would support arbitrary XUL-based apps.
Comparisons to IE of this form are the same as saying "Mozilla is a browser. Any other stuff we do must be accomplished without decreasing speed, increasing footprint or increasing file size." That's not feasible.
"Just because they're not running an OS with Windows doesn't mean that they should accept a browser that is slower than IE5.5 on a comparable win/mac system."
--> "Sorry, Linux user, we aren't declaring Mozilla as 1.0 software because it's not as 'fast' as some program you never use on some operating system you hate."
"If you say "startup time should be as fast as IE with the -turbo option" then you hit it. If you decide to set your goal differently, then you do so."
That's a pointless point. The entire reason for this discussion is to set the goals and have a rationale for the ones you set. Merely saying "set one" doesn't help.
" "Do you take into account that Mozilla may be doing far more with a page (supporting <LINK>, doing hover correctly) than IE?" Do you take into account that IE supports other features that Mozilla does not?"
Right, then we'll do all our benchmarking against Netscape 6 again.
" "If we only _try_ to hit it, what's the point of having it at all?" What's the point of having any guideline? Are you really going to freeze the API's? (probably not)"
Yes. Mozilla will not be 1.0 software until we have a good API freeze story. This is one of the key requirements.
"Are you really going to achieve 100% > Good Net-Keeping Award? (probably not). "
The point of having this discussion is to see if it's feasible or not.
"might ask)? Since they're not going to hold the release for all the bugs! "
1.0 is different. As Ben Bucksch said, "we're busy" is not an excuse for 1.0 bugs, because the response is "if we think this is necessary for 1.0, delay the declaration of 1.0." "Mozilla.org never, in the beginning, promised a 1.0. "
Mozilla.org promised full support for html4 dom0/1 and css1 in the first release. This is well-known, and has been for ages.
#110 Re: Re: Re: Re: Cut the bull or put the bull in?
Thursday June 28th, 2001 2:06 AM
Oh my, be a little more realistic - when you go through the performance newsgroup on Mozillanews, you'll see that Mozilla is far slower than NN4 in everything except page-rendering. No need to compare it with IE, NN4 does the same. And don't bite back that Mozilla is better than NN4, we all know that. But what is important for end user? UI polish and speed. And in this NN4 is FAR better than Mozilla. If you really want Mozilla to be accepted as a browser (yes, I know it's not a browser) at least these two issues MUST be solved.
#115 51.5 MB (!) for an IE5.5 installer
Thursday June 28th, 2001 3:44 AM
51.5 MB is the size of a downloaded installation pack (saved locally before starting installation) that includes:
Web Browser Offline browsing pack Help IE core fonts Media Player codecs Pan-European text display support
Leaving out virtual machine, netmeeting, connection wizard, outlook express (!!), media player, flash and shockwave plugins, vb scripting support. This isn't even a fair comparison to Mozilla since Moz includes Mail&News and shockwave plugin (but no media player codecs). Mozilla full installer (nightly) download is 8.5 MB. Additionally, mozilla doesn't use most of windows dlls because they are not cross-plattform. I don't think downloading size is a concern on Mozilla.
#151 Re: Re: Re: Re: Cut the bull or put the bull in?
Thursday June 28th, 2001 2:20 PM
"My point has always been not that it is hard to set goals, but that any goals you set will be totally arbitrary."
Yes. So you need to realize that the goals I suggest are only as arbitrary as the goals you put forward.
"If I say "Why IE 5.5?" and you say "Why not?" then I'll say "then why not Netscape 6" and we can do all our performance criteria relative to that."
Because users want a browser that is faster than IE5.5. They do NOT want a browser that is faster than Netscape 6. That's like offering a car buyer a geo metro and saying it's fast because you compared it to a toyota celica. If you want to say it's fast you have to compare it to the speed champ. If you're going to make goals for 1.0 they better mean something to the consumer.
"Which download size?" Someone said IE is 51megs. I've never really thought that Mozilla was too big anyways. So I'd have to say we beat them. Check that one off the list. And while your at it, try to realize that C|net and everyother review site is going to figure out a way to do benchmarks and compare download size. Why is it so hard for Mozilla to do them? When I know for a fact that Netscape is already doing them.
"Sorry, Linux user, we aren't declaring Mozilla as 1.0 software because it's not as 'fast' as some program you never use on some operating system you hate."
I use Linux, so let me just debunk a few things here. First off, no one said Linux users hate Windows. Second, would you rather see mozilla apologize for a slow browser? Most Linux users stuck with Linux in the past, because there was a Browser on the OS that was as good as any on Windows. Netscape 3/4. However, you're suggesting that Mozilla be able to get away with releasing a slow browser because there isn't a faster browser on that OS. Wow. Why don't we drop all the OS's and just support BeOS, then people will stop complaining that it's soo slow, because we'll be the only browser. And we better drop windows and mac support, because we're not even going to try to match the speed of the current browser king (IE).
"That's a pointless point. The entire reason for this discussion is to set the goals and have a rationale for the ones you set. Merely saying "set one" doesn't help." I think users will agree with me that fast startup time is a good enough rationale. *sarcasm* I should think you won alot of debates in school by saying the other sides argument was "pointless". *end sarcasm* I don't see a single person, other than you, here arguing that benchmarks are *whine* too hard *end whine* to implement so we shouldn't bother. Every review magazine does benchmarks. Everytime a new browser comes out Zdnet, C|net, and many print magazines all produce benchmarks that say Mozilla/Netscape is slower than IE.
"Right, then we'll do all our benchmarking against Netscape 6 again." If mozilla wants to release a browser that people will use you'd better start realizing that the industry is capable of benchmarking apples with apples - Mozilla should figure out how to do this too.
"Yes. Mozilla will not be 1.0 software until we have a good API freeze story. This is one of the key requirements." I said, "freeze the API's". It sounds like you're saying Mozilla won't freeze the API's, but instead they'll have a "good freeze story". Great. Let me tell you their performance story. Once, there was a little girl named alice. She tried using mozilla 1.0 and it wasn't nearly as fast as the browser she was already using. So young alice switched back to (IE/Konqueror/N4.x/Opera/Browser of choice). If in fact you meant that Mozilla will freeze it's API's, then either Mozilla 1.0 will never be released, or you will eat your words. That would imply that future versions of Mozilla would only fix bugs - and not a single feature would go in, nor would bugs that require API changes be fixed.
"Mozilla.org never, in the beginning, promised a 1.0. " Clever. They did promise a 5.0 though. It's nice to see Mozilla change it's numbering system so that they don't have to release what they promised.
"Mozilla.org promised full support for html4 dom0/1 and css1 in the first release. This is well-known, and has been for ages." Show me. I already proved with the links to the most earliest posts about Mozilla that they in fact did not promise any such thing in the beginning. Mozilla.org promised a 5.0 before the NGLayout was even supposed to go in. It's nice to think that one of Mozilla.org's first promises was full support for html4 dom0/1 and css1. But the truth is that Mozilla.org promised source code first, and a browser second. Everything else was added on while they spent years failing to deliver the browser.
Don't get me wrong. I love Mozilla. (although pundits will point to my kill mozilla (the mascot) bug in bugzilla). I was a mozilla advocate before I was a Netscape employee. What I don't want is for IE to continue ripping away the marketshare of Mozilla based browsers (currently somewhere below the 15% marker - if not seriously lower).
Let Netscape come out with buggy, slow browsers. They're going to release whether Mozilla hits 1.0 or not - as they've already done. Since Netscape has picken up the task of releasing a browser on time, let's let Mozilla pick up the task of releasing a better browser, "when it's ready".
#109 Re: Re: Re: Cut the bull or put the bull in?
Thursday June 28th, 2001 1:02 AM
>"How do you measure the size of IE 5.5?" >Why don't we start with the download size?
I can't find a "complete IE" for the sake of me. All the places where you can download IE report 490KB to download, but I assume this is the installer not the whole download. Also it seems that IE is taking A LOT more hard drive space that mozilla.
#126 Re: Cut the bull or put the bull in?
Thursday June 28th, 2001 5:41 AM
"Are you really going to achieve 100% Good Net-Keeping Award? (probably not)."
This is not something that should be that hard, other newsreaders manage it. e.g. Pan (part of GNOME) scored 100% on MUST and SHOULD.
GNKSA compliance is achievable, and desirable because it gives Mozilla bragging points :-)
#213 Performance, IE5.5, and API freezes
Friday June 29th, 2001 3:26 PM
Let's start with API freezes: One of the biggest advantages of using a COM-like component architecture is that you can (and should) freeze every interface in every non-beta release. So what if nsISomeInterface isn't perfect? You can add new functionality to the component and implement a new nsISomeInterface2 later without breaking compatibility.
As for performance, it's excellent overall. There are some exceptions, but page loading isn't one of them. So what if IE6 loads pages 150 milliseconds faster? Is it Mozilla's purpose to meet the needs of mainstream users or to help SlashDot teens win penis-waving contests? This is about producing quality product, not raising your self-esteem.
There are still serious CSS bugs and nearly all of these constitute broken rather than simply missing standards support. For example, float:right is still in a mess, I believe, and puts things in the wrong place; if you workaround some of the bugs with incorrect positioning (perhaps not realising you're so doing) you will be creating pages that break in correct browsers.
I don't think a release has to have 100% support though - I think by now everyone (Web developers) has realised that Mozilla's claims are *not* going to be met and the browser is *not* going to have flawless support for CSS in particular. At least it does a better job than IE5.5 and probably IE6, in most areas.
There are still cases where correct pages that work in IE might fail in Mozilla though. In practice, the most important thing is that Mozilla can handle all the CSS that IE can (and then some). Web developers will be restricted to whatever IE5.5 or IE6 can support, anyway, so it doesn't too much matter what the 'and then some' is as it won't get used. Poor Web developers (and they are legion) will continue not to bother testing in any other browser than IE, and it's important IMO that as many of these pages as possible actually work.
So I think 'IE parity' should be the main criteria with CSS for a release - certainly not that Mozilla duplicates IE bugs, but that for all areas where IE actually works and correctly implements CSS, Mozilla should too.
If Mozilla release is as good as IE in every area w.r.t. CSS and better in some, then Mozilla is raising the game. If Mozilla's worse than IE in a few areas then it's restricting Web design.
As for non-standards-related areas, I agree that user polish is the most important for a 1.0 release.
The most serious lack is editable bookmarks (right-click), but also important are textfields that actually work perfectly in all cases, focus that behaves as normal, password management that doesn't screw up, mailto links that load your preferred mail client not some lame Mozilla mail program you never use... The client is actually pretty good right now in those areas, IMO near release quality, and a lot of bugs were fixed, but some critical ones remain.
Second most important I'd say is killer features, by which I mean, at least ONE thing that the browser actually does BETTER than IE. (And no I do not mean 'standards support' or whatever). Right now, we do have one feature and that's privacy/security, both cookie management which is great (though I think IE has something similar now?) and, in particular, ad-blocking. Good. Make sure that's obvious to users and is high on the agenda. Maybe improve it a bit, too.
My third priority is that SOMEBODY REMOVE THE F***ING LITTLE TRIANGLE THINGS to the left of menu and navigation and personal toolbar. These are fantastic for accidentally clicking, but nobody has ever used these for their intended purpose in the entire history of mankind. They are useless. No other application has them. They sucked in NN 4.x, they suck in Mozilla, and their functionality is obviously available in a much more useful manner via the View menu.
(Yes, that 'third priority' was in fact a rant that isn't at all relevant to this discussion. Sorry. But it needs to be said. :) --sam
#127 Re: IE parity (CSS) - Agree
by AlMalossi <AlMalossi@gmx.net>
Thursday June 28th, 2001 5:55 AM
So I think 'IE parity' should be the main criteria with CSS for a release - certainly not that Mozilla duplicates IE bugs, but that for all areas where IE actually works and correctly implements CSS, Mozilla should too.
as a web developer i agree, than i can say to my customers, it doesn't hurt you in any point to switch from ie to moz....hey actually you really benefit.
Good points, even if I disagree with some of them. By the way, I use the little triangle thingies - especially to get the personal toolbar out of the way.
#184 Little triangle thingies (OT)
Friday June 29th, 2001 6:47 AM
Okay, I admit I went over the top just in order to be mildly entertaining on this subject, but I'm curious... ;) Why do you use the triangle thingy when if you use the View menu, you can 'really' get things out of the way?
The little triangle thingy only halves the space taken by the personal toolbar...
#185 Re: Little triangle thingies (OT)
Friday June 29th, 2001 7:05 AM
I'm actually starting to wonder what use they have in Mozilla myself. I used them in NS 4, but they seem fairly useless in Moz. After all there are now 2 bars instead of 3. Why not add one for the status bar too?
Better idea than the triangles: Hotkeys. They're the wave of the future. ;)
#147 What the GNKSA is really about
Thursday June 28th, 2001 1:00 PM
"4. Good Net-Keeping Software Award. - raise your hand if you think consumers care. while your at it raise your hand if you think mozilla 1.0 is for developers rather than users. ;) Again, I think we can come up with a checklist for mail that people really care about. If we're going to add more features into Mail (as achieving this award would require) why don't we try to implement something useful like system tray biff notification?"
Okay, it's pretty obvious that you have no idea what the GNKSA is actually for.
It's not about features for the user, it's about "playing well with others": encouraging good netiquette and behavior that does not make the USENET experience unnecessarily unpleasant for other users.
The GNKSA 2.0 specification can be found here: <http://www.gnksa.org/gnksa.txt>
The only "features" the GNKSA requires are actually basic, necessary parts of netnews: ability to edit headers, quoting, allowing the user to change his/her mind about whether to post or email, providing filtering. Only one standard asks for uncommon features (cancelling and superseding articles), and that is just a SHOULD, not a MUST.
#148 Re: What the GNKSA is really about
Thursday June 28th, 2001 1:48 PM
It's obvious that you make broad stereotypical assumptions about people.
I know what the GNKSA is for. Why do you think I said that consumers don't care? They don't care because the "basic, necessary parts of netnews" are already in the newsreader - otherwise we wouldn't have a newsreader. What isn't is 100% support of GNKSA - because no users care about it right now. It's only meant to prevent spammers, and spammers have their own autoposters anyways.
Why don't you go read the GNSKA bug that tracks the issues associated with scoring 100%. <http://bugzilla.mozilla.org/show_bug.cgi?id=76449>
Does anyone care about a bug entitled "overzealous blocking of cross-posting to multiple hosts"? Wouldn't you rather have developers work on something entitled "Mozilla crashed in Necko.dll as install finished, now application will not start"?
#207 Let me explain this slowly
Friday June 29th, 2001 1:22 PM
You still don't understand the GNKSA. It's not meant to prevent spammers (no software can prevent somebody from being a complete ass if they really want to be). It's to prevent newbies from making common mistakes that irritate the rest of the USENET community.
And if you'd paid attention, you'd have seen that I had already posted a couple of comments to that bug. Hell, I submitted the bug for minimal compliance.
Your example is pointless. Those would be different groups of engineers anyway, so fixing one would not mean not fixing the other.
Finally, I think people would be somewhat miffed (actually, some people already are, if you read the comments in that bug) if their newsreader refused to post a crossposted message for no legitimate reason (which is what the "overzealous blocking of crossposts" bug is about).
As for "users don't care", here's a non-USENET example of why user interest isn't the only criterion for a good feature: think of the favicon.ico feature of IE. Whenever a user bookmarked a site, IE would send a request to the server for a file called "favicon.ico", which it would use as an icon next to the page title in the favorites menu. Users thought it was kinda nifty, if they noticed at all. Server admins, however, were pissed because their servers were being bombarded with requests for "favicon.ico" files, which frequently didn't exist, and it was eating up their bandwidth. The problem wasn't that it ruined the user's experience, the problem is that it caused problems for *other people*.
The GNKSA is about promoting news software that doesn't cause problems for other people.
#214 Re: Re: Cut the bull or put the bull in?
Friday June 29th, 2001 3:29 PM
I see that you understand the GNKSA in your own way. What you don't understand is that saying my opinion is wrong is like me saying that you like chocolate is wrong. Wow, what an I opener, thank you for clearing up my opinion, for a second there, I thought it was my opinion, but apparently my opinion is wrong. I read the GNKSA document, I don't know if you have, but my opinion is that the GNKSA is not something worth achieving as users aren't going to care. And if users don't care, then we should spend time working on the things they will care about. Like getting a stable browser.
"Your example is pointless. Those would be different groups of engineers anyway, so fixing one would not mean not fixing the other." So you're arguing, against a Netscape employee, against a Mozilla developer - that you think you know more about what engineers can and can not do. Let me tell you, when an engineer - or a team of engineers - decide that their component is "good enough" they move on to help other teams. So to say that they would be different groups of engineers is a misguided statement. If the engineers spend time working on complying with GNKSA that's time they're not spending on other bugs. Was, or is Mozilla's 1.0 goal ever to promote software that doesn't cause problems for other people?
"Finally, I think people would be somewhat miffed" - so you agree that GNKSA is going to miff users, but you still want to push it?
#223 Apparently illiteracy really is running rampant
Saturday June 30th, 2001 7:42 PM
"I see that you understand the GNKSA in your own way. What you don't understand is that saying my opinion is wrong is like me saying that you like chocolate is wrong. Wow, what an I opener, thank you for clearing up my opinion, for a second there, I thought it was my opinion, but apparently my opinion is wrong."
Bullshit. Saying "the GNKSA is just for preventing spammers" is not a statement of opinion, it is a statement of fact, and can therefore be shown to be wrong. It's not like saying "I like chocolate", it's like saying "Francis Bacon was the first President of the United States".
"I read the GNKSA document, I don't know if you have, but my opinion is that the GNKSA is not something worth achieving as users aren't going to care."
By that logic, it would be fine if Mozilla sent threatening emails to the President using the email addresses of server admins, since the user would not know and therefore would not care.
"Was, or is Mozilla's 1.0 goal ever to promote software that doesn't cause problems for other people?"
That's pretty much the idea behind standards compliance.
Of course, if you're saying that you prefer sociopathic software, that would be a statement of opinion and I would simply have to say that I do not.
""Finally, I think people would be somewhat miffed" - so you agree that GNKSA is going to miff users, but you still want to push it? "
How the hell did you get that interpretation from what I said? The full quote was:
"Finally, I think people would be somewhat miffed (actually, some people already are, if you read the comments in that bug) if their newsreader refused to post a crossposted message for no legitimate reason (which is what the "overzealous blocking of crossposts" bug is about)."
I said that users would be miffed if their newsreader failed to post a crossposted message, which is behavior that *violates the GNKSA*. According to the GNKSA, a newsreader must support crossposting, and the bug is about certain times when Mozilla does not properly post crossposted messages. I was saying that users find that particular GNKSA-violating buggy behavior unpleasant. How did you come up with "users would be miffed if we followed the GNKSA"?
#227 Re: Re: Cut the bull or put the bull in?
Sunday July 1st, 2001 9:57 PM
"By that logic, it would be fine if Mozilla sent threatening emails to the President using the email addresses of server admins, since the user would not know and therefore would not care."
Not exactly. It would be more like if Mozilla refused to send my threatening letter to the President because it supported the Good President Keeping Seal of Approval. Great, someone wrote an RFC that says we should support not emailing the president threatening letters, so suddenly "standards compliance" means supporting every RFC or guideline that comes out whether Mozilla promised to support it or not.
Here, go complain that the IMPS isn't supported in Mozilla.
<http://www.faqs.org/rfcs/rfc2795.html> And don't forget to ignore the fact that if developers are working on GNKSA compliance, they're not fixing other, possibly more important bugs.
#234 Re: Re: Re: Cut the bull or put the bull in?
Monday July 2nd, 2001 1:55 PM
"It would be more like if Mozilla refused to send my threatening letter to the President because it supported the Good President Keeping Seal of Approval."
Give me one good example of the GNKSA preventing someone from doing something they should be able to do.
"so suddenly "standards compliance" means supporting every RFC or guideline that comes out whether Mozilla promised to support it or not."
No, if Mozilla didn't promise to support something, that doesn't mean that it isn't a good idea.
"And don't forget to ignore the fact that if developers are working on GNKSA compliance, they're not fixing other, possibly more important bugs."
You forget that this is just a matter of numbering. Do we wait for GNKSA compliance before we call it "Mozilla 1.0" or not? There will still be nightlies, and possibly an intermediate 0.9.x milestone if it takes a while.
#240 Re: Re: Cut the bull or put the bull in?
Tuesday July 3rd, 2001 3:19 PM
"Give me one good example of the GNKSA preventing someone from doing something they should be able to do." Here's one: "11) Provide a user-specified "Subject: " header When creating a new article, the software MUST require the user to provide a non-empty Subject."
The GNKSA is very much about restricting what the user is allowed to do. Such as posting with bogus information.
"No, if Mozilla didn't promise to support something, that doesn't mean that it isn't a good idea." Very right. And the inverse is true also. If Mozilla didn't promise to support something, that doesn't mean that it is a good idea.
"You forget that this is just a matter of numbering." If it were just a matter of numbering then we wouldn't be seeing two mozilla 1.0's released to the world in a matter of 10 years. Don't forget that Mozilla 1.0 was released by Netscape some years ago. Mozilla.org clearly means this new mozilla 1.0 to mean more than just another number on the horizon. If it were only meant to be a number to users and mozilla.org, then why have it at all? Why not just release 0.9.x.x.x.x releases forever? That way mozilla.org doesn't ever have to fulfill it's promises.
#241 Re: Re: Re: Cut the bull or put the bull in?
Tuesday July 3rd, 2001 10:53 PM
"Here's one: "11) Provide a user-specified "Subject: " header When creating a new article, the software MUST require the user to provide a non-empty Subject." "
But users are *not* supposed to post messages with empty subjects on USENET. It's bad netiquette. Which is the whole point.
"The GNKSA is very much about restricting what the user is allowed to do. Such as posting with bogus information."
The GNKSA is about preventing users from doing things that piss off large portions of USENET or make it difficult for others to use. Those are things that users *should not do*.
" "No, if Mozilla didn't promise to support something, that doesn't mean that it isn't a good idea." Very right. And the inverse is true also. If Mozilla didn't promise to support something, that doesn't mean that it is a good idea."
Right, but all that means is that "Mozilla didn't promise it beforehand" isn't sufficient reason for or against implementing something, which does no damage at all to my position (which was *never* "Mozilla didn't promise the GNKSA, so we should go for it"), but debunks your argument that "Mozilla didn't promise the GNKSA, so it shouldn't try".
"If it were just a matter of numbering then we wouldn't be seeing two mozilla 1.0's released to the world in a matter of 10 years. Don't forget that Mozilla 1.0 was released by Netscape some years ago."
That has no bearing on what the requirements for Mozilla-project Mozilla 1.0 should be.
"Mozilla.org clearly means this new mozilla 1.0 to mean more than just another number on the horizon."
All the more reason for the newsreader component to behave the way a newsreader should.
#246 Re: Re: Re: Re: Cut the bull or put the bull in?
Friday July 6th, 2001 5:29 PM
You said, "Give me one good example of the GNKSA preventing someone from doing something they should be able to do."
I did, and now you're saying, "But users are *not* supposed to post messages with empty subjects on USENET. It's bad netiquette. Which is the whole point."
If users were meant to not be able to post messages without subjects than the USENET would have been architected that way. The Usenet was designed with a purpose and one of those purposes was flexibility. Next thing you know the GNKSA is going to start approving websites, and suddenly I won't be able to create a web page in Composer unless I give it a title.
The restrictions are meant for a purpose, but at the same time they're restricting what users should be able to do - according to the architecture of USENET, not according to your opinion, or the opinion of the GNKSA, or even the opinions of a "large portions of USENET" - as you say. That's like prohibition, just because it disturbs the majority, doesn't mean it should be outlawed entirely.
So finally you're starting to see that the GNKSA is about restricting what users can and should be able to do. The GNKSA is about restricting USENET use to what you call "netiquette", but what others might refer to as "arbitrary restrictions". Specifically, you sasy "The GNKSA is about preventing users from doing things that piss off large portions of USENET...". :) I'm glad that you understand, now, that the GNKSA is about arbitrary restrictions.
I for one don't want to help build a browser that restricts my freedoms or the freedoms of others, just so the USENET can be a better place for you. I hope that better place never makes room for me. Joseph Elwell.
#250 Re: Re: Re: Re: Re: Cut the bull or put the bull in?
Saturday July 7th, 2001 6:03 PM
"You said, "Give me one good example of the GNKSA preventing someone from doing something they should be able to do." I did, and now you're saying, "But users are *not* supposed to post messages with empty subjects on USENET. It's bad netiquette. Which is the whole point."
If users were meant to not be able to post messages without subjects than the USENET would have been architected that way."
From RFC 1036 <http://www.landfield.com/rfcs/rfc1036.html> , which defines USENET:
The "Subject" line (formerly "Title") tells what the message is about. It should be suggestive enough of the contents of the message to enable a reader to make a decision whether to read the message based on the subject alone."
According to the relevant RFC, the subject *should* describe the message. Since a blank subject doesn't describe anything, it is discouraged by the RFC.
Furthermore, Son-of-1036, the intended successor to RFC 1036, describes the format of the Subject header in EBNF <http://www.chemie.fu-berl…news/son-of-1036.html#5.4> :
"Subject-content = [ "Re: " ] nonblank-text"
There's nothing arbitrary about that restriction.
Then you write:
"I for one don't want to help build a browser that restricts my freedoms or the freedoms of others, just so the USENET can be a better place for you."
Get off your high horse. You're trying to make it sound like a violation of your first amendment rights. It's not, any more than having to put a properly formatted address on a mail envelope is a constitutional issue.
#243 Re: Re: Re: Cut the bull or put the bull in?
Wednesday July 4th, 2001 1:55 PM
"That way mozilla.org doesn't ever have to fulfill it's promises."
Which promises? The promise that mozilla.org "to act as the virtual meeting place for the Mozilla code"? These promises:?
* We will provide technical and architectural direction for the project.
* We will collect changes, help authors synchronize their work, and periodically make new source releases which incorporate the best work of the net as a whole.
* We will operate discussion forums (mailing lists, newsgroups, or whatever seems most appropriate.)
* We will coordinate bug lists, keep track of and publicize works in progress, and generally attempt to provide ``roadmaps'' to the code, and to projects based on the code.
* And we will, above all, be flexible and responsive. We realize that if we are not perceived as providing a useful service, we will become irrelevant, and someone else will take our place.
I'm reading and re-reading this list of promises and I just don't see anything about releases. Can you point me to the list of promises mozilla.org made to you?
I mentioned earlier in this article what Mozilla.org promised me. Here's a link <http://groups.google.com/…c=1&selm=an_353682358>
This was the stabilization schedule mozilla had come up with in may of 1998.
#245 mozilla.or posted some "thoughts"
Friday July 6th, 2001 5:16 PM
How do you manage to translate "Here are my current thoughts on mozilla scheduling for this year:" into "mozilla.org promised me." Do you translate "I was thinking that we should try to do lunch later this month when I'm in San Diego for O'Reilly" into "I promise to meet you for lunch when I'm in town for O'Reilly"? :-)
From the Mozilla at One page: <http://www.mozilla.org/mozilla-at-one.html>
Under "Lowlights and Debatable Decisions", Mozilla.org addresses their change of plans - that some say cost the organization 3 years (not I).
"Netscape and mozilla.org could have proceeded on the original plan to release "Mozilla Classic," i.e., a version of Mozilla using the original Communicator 5.0 source code, instead of rewriting Mozilla using the new NGLayout HTML layout engine (a major component of the new Gecko technology). This might have produced an official 5.0 release sooner and (as a side effect) resulted in having much earlier a relatively stable code base buildable by more developers; however this would have been at the cost of having a level of standards compliance not much above that of the Communicator 4.x releases."
It's apparant that Mozilla.org had other plans, that they did not follow through on. How much of those plans involved promises, either direct statements or by continually parading around release date talk does not matter. What matters, to me, and to many others. Is the promise we all felt, and sometimes still feel for Mozilla. As you seem to feel a need to nitpick my words, I looked up 'promise' for you:
2 : reason to expect something <little promise of relief>; especially : ground for expectation of success, improvement, or excellence <shows considerable promise>
Many people expected something, if only because Mozilla.org existed; but quite undeniably because members of Mozilla.org believed sometimes silently, sometimes thoughtfully, and sometimes loudly in it too. Joseph Elwell.
It's weird to me that anyone thinks, "What schedule? We never promised you a schedule! Show me the schedule!" is an answer that will impress anyone.
Remember the Nathan Thurm lawyer character from Saturday Night Live? Martin Short, wasn't it?
How unfair of you to bring up that issue of the three-year slip! Don't you understand that Mozilla is free of capitalist paper tiger concerns such as schedule? Counter-revolutionary! Embrace the true path!
#248 Re: Re: Mozilla promised me.
Saturday July 7th, 2001 12:03 PM
where did mozilla.org state that we would release a 1.0 in July of 1998? See, I've been watching this project closely since the release of the classic sourcecode. I've been directly involved with the project for over 2 years and I don't ever remember mozilla.org posting a release date for 1.0 or 5.0 or M100 or whatever it is you seem to remember.
1. Full support for HTML4, DOM0, DOM1, CSS1. I wish we could wait for genuine XSLT usability (my XML/XSLT pairs don't work in Mozilla, though they do tranform fine in three other engines), but I think it will take longer to get that up to speed that Mozilla has time to spare, and from what I remember XSLT and CSS2 were not promised. This is something IE is mediocre at (though the Mac version is better), and will give Moz an opportunity to shine. Composer should not use deprecated HTML elements.
2. Internationalization: Greek, Hebrew, and Arabic are also important, especially as second languages. Remember that some of the documents browsers will be used for will be in the user's second or third language. This is something IE is very good at, raising the bar a bit for Moz.
3. Stability: I should be able to go to the top sites, using the most widespread technologies (Java, Flash, QT & RealMedia, etc.), and expect not to crash. Ok, maybe I can't reliably expect to plug in some wild 3 party viewer that no one else has even heard of; but the major plugins should work reliably every time; CSS1 and HTML pages that are valid should never crash the browser, and the most common coding errors in HTML should be gracefully handled.
4. Encryption/E-Commerce, Security. I should be able to use Mozilla anywhere I can use IE to buy anything, and know that I'm getting commercial-strength encryption.
5. Un-4-ication. I should never have to use Netscape 4.x because what I want to do can't be done in a Mozilla browser.
6. Usability: this is mostly what folks have been calling polish: the UI should always behave consistently: there should be no reason why I'd notice a rendering bug in the UI.
Hope this is of some use.
I think it is important to get HTML4 support perfect for Mozilla 1.0. Browsers based on 1.0 will be around for many years to come, and we don't want people to be working around incompatabilities like they do now.
Mozilla will have lots of critics, and will no longer have the 'its only in beta' defense. If we don't have one of the major things Mozilla was meant to have then we will never hear the end of it. World-beating support isn't good enough, we need perfect support (or at least parity with IE6, and by that I mean that anything that works correctly in IE will work correctly in Mozilla, not just that Mozilla supports more things correctly than IE).
I'm also worried that bugs in HTML 4 support that haven't been fixed already are ones which don't have much support from the developers or are difficult to implement. If this is the case, then when will these bugs be fixed?
#95 To Make It Acceptable
Wednesday June 27th, 2001 4:37 PM
If the goal is to make the browser popular with non-Mozilla users, I think the best thing to do is show it to people who are not Mozilla developers or flu... fanatics, and ask them what they think.
Every Mozilla developer and fanatic is already using Mozilla. Their approval is not going to make the browser any more popular than it is. If the goal is to spread the browser then it must appeal to people who are not already using it and probably not going to compliment it unconditionally.
Take the browser to anybody who will listen, and ask for an opinion. Do not assume Mozilla websites, newsgroups, and employees know what the world wants. If they did then the rest of the world would have downloaded Mozilla.
Do not attack anybody who tries to tell you what is wrong with the browser. Stop typing, "It's not a browser!" with many additional exclamation marks. Stop telling people a certain version will be magic and then saying, "Wait for the next version," when that version arrives in a disappointing fashion. Stop expecting people to use Mozilla to build software. Nobody wants to add 64 megabytes to her memory requirement before she starts programming.
#107 All you need is love (and doc)
Thursday June 28th, 2001 12:00 AM
There are a number of things that need to be there, but none is more important than documentation. If we had some idea of the post 1.0 plans (and perhaps some faith in an ability to deliver on time), some people may be willing to let thier favorite "bug" slide. I personally would let xslt slide if I was reasonably confident that 1.1 would have it and that 1.1 would be out two months after 1.0. If 1.1 won't appear for another 6 months, then I'd say xslt is a 1.0 must. Our company is developing a web client, and we're forced to use ie (much to my dismay). Sticking to deliverables defined 2.5 years ago hardly seems like a good idea.
Having said that, documentation of the system is the most important thing you could accomplish. Who knows, it might just give you the resource to "release fast, release often".
#128 Re: All you need is love (and doc)
by AlMalossi <AlMalossi@gmx.net>
Thursday June 28th, 2001 6:36 AM
I love this simularity.
as i mentioned somewhere at the top in the XSLT. We are developing a XML content management system for a intranet, and (it hurts my soul) we have to say to our customers that they MUST uses IE in their intranet.
where I agree with wwrafter after reading als this responses. when there is a fast (release fast and often) 1.1 release two month after 1.0 even I can wait for xslt support (but i would be sad).
please don't stick to much in the "we promised it 2.5 year ago" . so much happend in the meanwhile
maybe 1.0 is the dom0-1-css1-html4-documented-polished proof of standards release in e.g. november.
1.1. just two month later (or so) with nice xslt
1.2. (4 month later )svg and mathml
1.3. (6 month later) jabberzilla, css2, and feature X
1.4. feature Y
1.5. feature Z
2.0 world domination
please don't beat me about the ranking of the features above, they are just very personal. (beside of 2.0)
i just downloaded komodo 1.1.
where komodo 1.0 was just the proof-of-XUL-as-a-cross-platform-ide release, i suddenly can debug my xslt (and php) in 1.1. and i'm already excited what's comming up in komodo 1.2.
btw: some of the postings are getting a little bit rude and personal... not really neccessary. actually we discussing here what we want for 1.0 a thing we all waited for 3 years. it's something very positive.
just read the title of the above message :-)
#111 Stability, speed, THEN features
Thursday June 28th, 2001 2:27 AM
To me (for how much its worth) the stability have to come first. I don't want to crash when playing chess at yahoo (java applet), or just surfing websites. (No, total recall is not the answer for these problems)
If stability is acheived, then we worry about the speed of the thing, loading is ok, but things like opening/swapping new windows is too slow. Anything that help 'preceive' mozilla as fast would be good.
If thats fixed, then we worry about svg, xslt, and other niffty stuff. In fact, I dont even mind if mozilla 1.0 isnt fully html 4.0, css1, dom1 complient. Its fairly good as is, as long as stability and speed is there.
I donīt think it has been mentioned before, and since I donīt know if this goes under stability or features or useability I think itīs worth to mention it now.
When Mozilla 1.0 there should be high a priority to have ALL major plugins running flawlessly. This adds tremendously to the end user experience. I could also think of a routine in the installer that detects plugins already installed for other browsers and offers to copy them to appropriate Mozilla directory.
I also second the idea of having a modular uodate mechanism, so you donīt have to download the complete browser everytime an update gets released.
Besides this I think the priorites should be: 1. stability 2. UI polish 3. Speed.
If the app is stable and easy to use, speed is not the major issue. I also think that Mozilla already reached a high level of standard compliance. More would of course be better, but as it right now itīs ok for must end users.
#137 Re: Plugins
Thursday June 28th, 2001 11:03 AM
The plugins should not be copied. Mozilla should use the other browser's plugin folder.
Rather than using the other browser's plugin folder, how about creating links/shortcuts/whatever-you-want-to-call-it to the other plugins - otherwise you have no idea what plugins are in your folder. However, I really don't like the idea of using plugins in other folders because, you lose them when you finally decide to ditch the other (lousy) browser. ;-) If you copy the plugins, you get to keep them, no matter what happens to the other browser. That and you can bet that MS would release something to ensure incompatibility ... er ... propriatary additions. ;-)
#124 Mozilla does need features
Thursday June 28th, 2001 5:30 AM
Mozilla 1.0 is not going to be better than ie in all respects (eg page rendering speed). There will be many people who try it out and then return to ie for general browsing. We want to make sure that they keep mozilla around and use it for *some* things which it does and ie does not. It will then be easier to encourage these people to use post 1.0 mozilla. Examples of such features are mathml and pgp email. The main thing is there have to be some clear (to an average user) ways in which mozilla is *better* than ie.
And No I would not hold 1.0 for either of the above features but I would for some features like the above.
Mozilla 1.0 should features not found in other browsers like
- image and popup window blocking support - advanced cookie management
Frontends for this should be completed where the backend is already implemented. Lots advanced users use cookie management tools and filtering proxies. This is the kind of audience we should try to appeal to and win over.
At the same time Mozilla should not feel less than other browsers. For this we need UI polish and consistent behavior. Mozilla should not surprise you with weird focus handling or other unexpected quirks. Mozilla should not take significantly longer for some rendering tasks (like complex forms) as its predecessors, the user experience should never feel like taking a step back.
In short, we are mostly on target already, we just need to polish our best features and bring the rest on par with NN4.
#162 Re: Browser for the advanced user
by kb7iuj <email@example.com>
Thursday June 28th, 2001 4:26 PM
No! You cannot publish a browser which blocks popups. This shreds the business model for a lot of companies. Companies which hire web design companies. Web design companies which pay our salaries.
#163 Re: Re: Browser for the advanced user
Thursday June 28th, 2001 5:00 PM
Actually, as almost everyone in the field knows, the advertising model of funding web sites has now failed.
In any case, there's nothing to stop someone from adding ad and popup blocking to the Mozilla sources and distributing it. (Except the impenetrability of the Mozilla source, that is....)
#209 Re: Re: Re: Browser for the advanced user
Friday June 29th, 2001 1:47 PM
"In any case, there's nothing to stop someone from adding ad and popup blocking to the Mozilla sources and distributing it."
or from running an ad-stripping proxy like Junkbuster.
acutally has a popup suppression so you can publish a browser which blocks popups. And users do like this pretty much...
It's my computer, and I see no reason why I shouldn't be able to control its behavior. Furthermore, statistics seem to indicate that popups lower your income rather than increasing it, due to the lost users. You end up with a higher cost-per-thousand, but with fewer thousands in the first place.
In any event, popup blocking is already in Mozilla and has been for ages.
Mozilla already has the popup blocking feature implemented in the backend. Only the frontend is missing. See
Unless a pulldown menu is added to view source, I don't think many people will use Mozilla for online developement. It's such a simple feature but it's invalueable when your developing new sites.
Huh? View > Page Source has been in Mozilla for as long as I can remember. Plus you can right-click for view page source and view frame source.
Yes of course view source is there but can you do a find, replace, goto, save etc. No!
You must be using an old build. View Source has had menus for around a month now, including Find, Save, Cut, Copy etc. It's not supposed to be an editor, so it doesn't have Replace, but there is a menu to "Edit Page" which places the page in the Editor where you can edit it to your heart's content.
Mozilla's feature list, IMHO, is pretty much there. It just needs some tweaking, and I think this will always be the case.
The things to focus on now are performance and plugin support. I agree that 1.0 should mean that it is ready for prime-time, rather than the public beta release that defines many 1.0 releases. Mozilla needs to render its pages faster, and be more stable. Plugin support needs to be much more consistent (0.9.2 still crashes when I try to run Java applets on Linux). Otherwise, Mozilla has come a long way. To those of you who have been working long and hard on this, great work! You're not quite there yet, but you're close. This is a real opportunity to put IE in its place--just keep the faith.
by davidjoham <firstname.lastname@example.org>
Thursday June 28th, 2001 10:01 AM
First off, thanks for asking Gerv. I appreciate y'all listening to us.
In my opinion, Mozilla will not have a successful 1.0 release without a concentrated effort on polish. From the talkbacks posted, it looks like UI polish has been beaten to death, but I'd like to add a couple of specific areas to make sure are addressed.
1) focus issues 2) Dialogs. I can't count the number of times the download dialog has had buttons off the screen 3) buttons - there are far too many instances where pressing a button does not actually cause the button to appear pressed in the UI. 4) UI performace, specifically with textareas and text controls. These can be very slow at times. 5) Favicon support. Similar to Konqueror's support. Users love this and it says that you care enough to go the extra mile. 6) HTML form control UI. Frankly, they're ugly. Look at any site that collects data in IE, Moz and Konqueror. Moz looks really bad where IE and Konqi look much better. A little polish on the CSS for the borders and making everything the same height would do wonders here.
I would also like to point out that there is another class of users for your product that demand polish as well: developers.
Personally, I feel that the support Mozilla has now for standards is perfectly fine for a 1.0 release.
In answer to your inevitable question, yes I would prefer to have a polished (end user and developer) 1.0 release than further work on HTML 4.0. The 4.0 support that we have now is sufficient for today's web. 1.1 can be where we put in XSLT and full HTML 4.0 support and fulfill our original promise.
Just my .02
Since everybody is posting his opinion, here's mine :-)
It is very clear from all the talkbacks above that everybody sees 1.0 differently. Some want more standards compliance, some want more features, some want more polish, some want more speed, some want more stability, etc etc. Will we be able to satisfy everyone? Honestly I don't know. Too many things, not enough time.
I think documentation is important, but the fact is that it becomes very quickly obsolete.
I will probably get beaten on for the two next ones, but oh well: Stability is fine as far as I'm concerned, both on linux and windows (I build on linux). Speed is fine also as far as I'm concerned, having a good computer, but I can understand that it's still slow for some people.
UI polish is important, but I must admit that I couldn't care less if a text is one pixel to the left of a button or something like that. Make the functions work as expected, like the OK button in preferences, and we'll be fine.
Standards support is what we bet our "business" on. It can't be dismissed. It is a good thing we are doing well already in this category.
So for me, it's basically Documentation > Polish > Standards compliance > Stability & Speed.
I should probably add, that I'm already doing my fair share of work w.r.t. documentation. (mozilla.org/docs/dom). It's not all that hard, it just takes a lot of time.
#161 Re: So few time, so many things
Thursday June 28th, 2001 4:15 PM
When was the last time you read the documentation that came with a web browser? If it isn't immediately obvious what moving the mouse and clicking does, then it's too complicated anyway. Wasting time with "A Tratsie on Hyperlinks and the French Nobility" would be a complete waste of time, IMHO. Now, source code documentation is another thing... Of course, I'm the typical programmer-type; but I always assumed that the 'Help' menu was put there by the interface builder so that you'd feel happy, not that anyone actually used the thing.
I think all the talk of UI polish being essential is somewhat absurd. Sure, if things are a pixel off, people that want to pick Mozilla apart will be able to use these silly sorts of niggles as complaints. But SURELY it's **far** better to have everyone laugh at such negative critics, because they can see perfectly well that the stability, security, good design, standards support, portability and astounding feature set far eclipse such petty complaints.
Frankly, and this may sound elitist, but it's more about what a good software project should aim for, the user that will complain about the nowhere-else-seen feature being presented in an imperfect way (with buttons /slightly/ off centre, for example) is not the user we should be trying to appeal to (/pandering to).
Look at the Netscape 6.1 PR1 review page. You might possibly find a single petty complaint, but the majority of criticisms will be about sensible issues, like speed and stability - and happily the vast majority of responses are filled with praise: people genuinely seem to see the value and promise or this browser.
To put it briefly, and get back to the topic at hand: The UI is fine as it is, sure there are things that should be improved, and they will be, but to suggest that the current UI(s) are in any way seriously deficient is laughable, and we CERTAINLY shouldn't hold off on 1.0 because of them.
#142 Polish is important in the long run
Thursday June 28th, 2001 12:26 PM
The reviews focus on crashes and start-up time because these are the issues that are most visible when you first load up a new version. Minor interface inconsistancies don't crop up as problems immediately. But when you actually settle into regular day-to-day use, UI polish becomes a major issue.
This is why I keep giving up on Mozilla for MacOS and returning to IE5. When I hit TAB in IE5/Mac, the focus goes exactly where I expect it to. It doesn't go off into neverland or into some random pane. After loading a page I can scroll with pageup/pagedn immediately; in Mozilla it pops up an unwanted URL auto-complete menu unless I reach for the mouse and click the window, or hit TAB some arbitrary number of times. For things like keyboard-only navigation, it's not good enough if it works *most* of the time. It has to work *all* of the time. Mozilla's dozens of tiny flaws like this add up to an interface that forces the user into awkward behavior. In the long run, "minor" bugs that prevent the browser from responding as expected to user input will become the most irritating.
I use Mozilla full-time on Unix because there is no competitor with a better-polished interface. But MacOS users spoiled by working, consistent interfaces will find very painful to switch. Interface polish makes a huge difference, as IE5/Mac has shown.
I say the 1.0 feature freeze is a perfect time to focus on polishing the user experience. Make a really good interface, not just a functional one.
#143 Re: Who are we aiming it at?
Thursday June 28th, 2001 12:29 PM
Buttons that are so far off that they are clipped off the edge of the dialog box are not "a pixel or two off." This kind of UI problem has been pretty common through the life of Mozilla. The main ones I know about have been fixed but .... it really shouldn't have taken this long. I'm not at all sure that they are all gone, I saw one recently but it might not have been in the most recent nightly.
I'll agree that you can spend a lot of time to little effect playing around with pixel-sized tweaking of the UI... but that's not what I'm talking about and I don't think it's what I see others talking about.
#149 Re: Who are we aiming it at?
by Brendon <email@example.com>
Thursday June 28th, 2001 1:53 PM
no no no, i (and most likely the other people who've mentioned UI polish) mean the odd behavior of the UI.
i.e. mouse over a bookmark on the personal toolbar.. the text shifts a pixel or two.
on linux (not sure 'bout other platforms) text is sometimes oddly displayed, as if it was rotting away. heh, no.. i don't have a better description but if you use mozilla on linux i'm sure you know what i mean.
when you change themes sometimes you won't be able to access the "View" menu.
and god knows how many other small, but very disturbing glitches which aren't seen in anyother browser or even application than Mozilla.
It gives a very amateuristic feeling to Mozilla (no offence to any of the developers, but a fact is a fact) and will seriously put off potential users.
don't bother with the argument Mozilla isn't for users; Netscape will push a release regardless of Mozilla's UI glitches which ensures that the users will come across the bugs found in Mozilla (with one or two visible exceptions that they happen to fix with their own releases).
like an API freeze and documentation, UI 'polish' is a must.. you can't ship a 1.0 release that has taken years with a UI as bad as yahoo's java chatapplet.
#153 news.com story about Netscape and Mozilla
Thursday June 28th, 2001 2:32 PM
#182 Re: news.com story about Netscape and Mozilla
Friday June 29th, 2001 6:04 AM
" The company claims 38 million registered users for the portal and cites Nielsen statistics showing that the site reached 21 million unique visitors in April, both from home and from work, with the average time per visit at 46 minutes.
Netscape.com's traffic initially came from the fact that it was the default for people using the Netscape browser. Netscape capitalized on that traffic to a certain extent, charging search destinations such as Yahoo and Lycos to funnel the traffic their way. "
Hell, this is the main reason IE has such a huge market share. It was the default browser on every new web user's new computer.
#210 Nothing really new there
Friday June 29th, 2001 1:55 PM
It's mostly another story about Netscape concentrating on Netcenter.
It also treats Mozilla and Netscape 6 as synonymous, which they aren't.
#155 Functionality, Stability, Polish, Performance...
Thursday June 28th, 2001 2:36 PM
...these are the qualities I'd like to see in Mozilla 1.0.
First and foremost, I use Mozilla to get work done. The worst bugs are those that cause functionality to be missing. I don't mean missing features like full screen... I mean that sometimes Mozilla cannot download a file that I need. In these cases, I have no choice but to use another browser. The cases where Mozilla cannot perform a common function that other browsers can perform should be given top priority for Mozilla 1.0.
Closely related to functionality is stability. The more Mozilla crashes, the harder it is to get work done. Top crashes and dataloss crashes should get priority right behind functionality issues.
If Mozilla is able to perform the tasks I need it to without crashing, I'm relatively happy. However, I start getting picky about UI issues. My latest beef is that nearly every time I download a file I must set the default to "Save to disk". This is quite annoying, so these UI polish issues should be given priority right behind crashes.
I know that many people would like Mozilla to run faster, but with faster computers becoming available all the time, this will become less of an issue. I have an 800 MHz Pentium III with 256 MB RAM and Mozilla does not seem any slower than IE 6. Besides, given the choice of Mozilla not working, crashing, being positively irritating, or just being a little slow, I choose slow any day. Performance issues should come behind functionality, stability, and polish.
Addtional features that are not needed, enhancements, and theoretical targets like 100% standard compliance should wait until these more pragmatic issues are solved. I'm more interested in getting Mozilla to the point that it can perform all the tasks I need without crashing, being irritating, or being slow than I am about some arbitrary goal like the GNKSA.
Some people have been complaining that Benchmarks are too hard to create, and are too hard to set goals with.
Here, use this one. And I say "Beat IE5.5 on either windows or Mac": <http://i-bench.zdnet.com/ibench/i-bench.htm>
A little more proof that news sites do create benchmarks: <http://www.cnet.com/inter…1-3.txt.3779-8-3607741-10>
I can't understand the mindset that one must have to decide that suddenly benchmarks aren't accurate enough an appraisal, and to pretend that they simply can't exist.
Sadly, I just ran a comm version of mozilla from 06252001xx and it got beat hands down, by a factor of 2 for every test in ibench. :(
...and correct CSS2? And <LINK> tags? And XUL applications? And mail? And IM? And image blocking? etc. etc. etc.
Nobody EVER questioned the fact that you could take an arbitrary benchmark utility and throw it at different programs; the thing people have debated is how you compare like with like. IE is FAR, FAR, FAR slower on Linux than Mozilla is, for example.
No doubt you'll find that on a 486 netscape 2.0 puts up a very good fight against ie6 - look at it render pages almost instantly in comparison!!!
When you say: "Nobody EVER questioned the fact that you could take an arbitrary benchmark utility and throw it at different programs;"
Maybe you should speak for yourself. Here, Gerv debates the use of benchmarks entirely: From Gerv: "How do you do proper metrics on things which take fractions of a second, when you can't compile IE with timing?"
"IE is FAR, FAR, FAR slower on Linux than Mozilla is, for example." This statement is just simply wrong. IE under vmware or even with a version of WINE that works ok, knocks the socks off of Mozilla on Linux. "No doubt you'll find that on a 486 netscape 2.0 puts up a very good fight against ie6 - look at it render pages almost instantly in comparison!!!" While this is true, Mozilla is meant to be a browser for the current generation. And that means beating the previous generations with support and speed and stability.
#222 Re: Re: Re: Re: Benchmarks.
Saturday June 30th, 2001 3:53 PM
jelwell said: '"No doubt you'll find that on a 486 netscape 2.0 puts up a very good fight against ie6 - look at it render pages almost instantly in comparison!!!" While this is true, Mozilla is meant to be a browser for the current generation. And that means beating the previous generations with support and speed and stability.'
Actually, no. Mozilla is meant to be a browser for the NEXT generation. In fact, basically what that means is that it isn't simply a browser at all, it's much more than that. It does things which truly fulfil the Netscape dream of a cross-platform web, and is able to properly interact with the internet perfectly.
The fact is that (IMHO) IE6 is an iteration before Mozilla 1.0, being basically IE4 with certain bells and whistles. That means a comparison of Netscape 3 and IE 6 is probably as fair as IE6 and Mozilla....
#228 Re: Re: Cut the bull or put the bull in?
Sunday July 1st, 2001 10:23 PM
I understand this argument completely. It narrows down to "Mozilla is excusably slower because it does more, and it does it better.". The problem I see with arguments of this nature is that means Mozilla has to beat IE with marketing. It has to envangelize the world into writing pages that actually take advantage of Mozilla's "more and better" so as to differentiate itself from the latest offering of IE.
Call me a cynic, but I just don't see that happening. As far as I can tell Mozilla needs to beat IE with stability, and performance to regain market share. Of course AOL switching over to Mozilla would change everything...
#169 Re: Re: Benchmarks.
Thursday June 28th, 2001 10:56 PM
You might want to try investigating individual tests and see what the problems are and file bugs.
#219 Diminishing returns
Friday June 29th, 2001 10:00 PM
At some point a millisecond (even a couple hundred of them) just doesn't matter that much. The latest "ad-hock benchmark" results I heard was that on dial-up connections our page load time was beating IE. But I don't even care too much about that. If I'm not waiting (the concious act) for pages to load in Mozilla any more than I am in IE then I don't much care that IE is technically 200 milliseconds faster on some set of webpages. If IE can load a page in 4/10ths of a second and Mozilla takes 6/10ths of a second to load that page I don't find myself cursing at the 1.3 minutes of productivity that it costs me every day to use Mozilla (and I use the web a lot, all of my work tools are on the web). I easily recoup that time ten-fold by being able to get _to_ the page faster (with my custom keywords and wildcard lookups <http://www.mozilla.org/docs/end-user/keywords.html> ) Page layout performance is simply not that big of a concern to me.
I don't know the numbers for Navigator off the top of my head, but for IM, a new IM window takes roughly 3 1/2 seconds on a decent win machine. The same task in the AIM 4.3 client takes 1/2 a second. Most of the time is spent creating the XUL document and resoloving style.
So we're not talking hundreds of milliseconds, we're talking thousands of milliseconds. But then again, I probably just need a newer machine.Joseph Elwell.
#237 Re: Re: Diminishing returns
Monday July 2nd, 2001 10:31 PM
"page load times" I said "page load times". I did not say "new window creation time". I'm all for improving that. But as long as we don't regress page layout time I'm fine with it. Like I said, I don't wait for pages to lay out. I do notice a (minimal) lag in new window creation. For me it's a tiny bit less than a second for a new window and less than two seconds for a new window with usable content. IE is about 1/3 second for new window and 2 seconds for usable content (win2K PIII 650 with 128 MB RAM, commonly referred to as the suite spot in computing for the first half of 2001, high end in the first half of 2000 for laptops). We do have some improving to do here. I'd love to see our new window creation time cut in half or in 1/3 but I wouldn't hold 1.0 for it. I might consider holding 2.0 for it. There are far too many other areas that I'd rather see improved to waste my time thinking about the small handful seconds lost. --Asa
#239 Re: Re: Cut the bull or put the bull in?
Tuesday July 3rd, 2001 3:08 PM
I was hoping to wait for a good game to push me to upgrade my machine. But as it is even the most intense 3D game plays great on my P2 300Mhz machine at home. It looks like it's my browser that's going to make me upgrade my home machine now. :( Joseph Elwell.
#242 Re: Re: Re: Cut the bull or put the bull in?
Wednesday July 4th, 2001 1:37 PM
My PPro 200 with 64 MB RAM runs mozilla tollerably. It's not quite competitive with IE6 on winXP (which itself lags a bit on 64 MB RAM). I think that with half a gig of ram available for about 50 bucks that I'll up that machine to its max (not sure if it's 256 or 512). I have no doubt that Mozilla will run just fine on that old PPro 200 with that much RAM. Anything PII/PPro or above with sufficient RAM should run Mozilla at a quite usable level. For those people who can't run Mozilla on the equipment they have and can't afford 50 bucks to upgrade some ram (or 500 or 600 bucks for an entirely new screamin' 1Ghz or faster PC) then I recommend that they continue using 4.x or IE until Mozilla is performant enough. For some that will be a few months off, for others it may never happen. But as most of those browser statistics show (with all those IE 2.0 agents still out there) most people don't upgrade browsers at all. Most people stick with whatever came on thier new PC. So Mozilla based browser distributors should be focused on getting onto some of those new PCs (where we are more than adequate performers) and not trying to convice everyone with win95 on a classic pentium to upgrade from IE 2.0.
#167 IE 6.0 won't support Netscape Plugin's anymore?
Thursday June 28th, 2001 8:38 PM
#197 Re: IE 6.0 won't support Netscape Plugin's anymore
Friday June 29th, 2001 11:31 AM
Mozilla doesn't support Netscape plugins any more either. There's a new and incompatible plugin system based on XPCOM. LiveConnect was a bad idea that has gone away....
#200 Re: Re: IE 6.0 won't support Netscape Plugin's any
Friday June 29th, 2001 11:47 AM
Mozilla certainly does support 4.x plugins, and goes to pretty great lengths to do so. What plugin isn't working for you?
LiveConnect still works, I believe, just not with plugins.
#203 Re: Re: Re: IE 6.0 won't support Netscape Plugin's
Friday June 29th, 2001 12:21 PM
No, Mozilla breaks all plugin APIs, which have had to be converted from LiveConnect to XPCOM. This has been well known and thoroughly documented for over two years now, and I was involved with one effort to convert a company's plugin to the new format -- which was quite difficult.
One thing that would be a cool feature for Mozilla would be more "icon" plugins that is graphical shown in the navigator. In IE you can add things that makes you able to export the page you are viewing into Word, Textpad etc. I think extra modules for Mozilla has to much focus for being implemented into "My Sidebar" Why ? I want as much as space as I can get for my browsing window and the sidebar is just in the way.
Anyone who agrees, disagrees or even know what I mean ???
#211 Re: Cool feature
Friday June 29th, 2001 1:58 PM
We're in the middle of a push towards 1.0. "Cool new feature"s will have to wait.
No. 1 criterion - whatever results in mozilla being widely adopted in the long run. Does this mean pleasing the users or developers for 1.0? My own guess is the users.
As a user my top priorities in this order are: 1) speed 2) stability 3) polish 4) lower memory footprint - I just checked my memory and moz is using 56K!!! (i commonly browse with many windows as i have a slow connection)
And finally - NO more features - get the browser right first. Even though i use composer all the time (and it is terrible for editing) I would much prefer to have a top class browser first.
The thing is everybody uses the browser whereas most people only use a subset of the the other features.
From the comments above and my own experience what the mozilla project needs is more developers (I know this is slightly off topic).
The mozilla project needs more developers - and there are developers who want to work on Mozilla. There just needs to be somebody to connect the 2 up. Somebody who would be a bridge between current developers and would-be developers. Their responsabilities would be
1) Monitoring sites like mozillazine and responding to people who express a wish to get involved. Pointing them at the right documentation, suggesting areas of code where they could be most useful, suggesting areas of code that would match their skills. Pointing them at individual developers that they might wish to talk to
2) Chivvying the current developer community into documenting their code properly - providing overviews of code areas and packages etc
#175 Get me involved!
Friday June 29th, 2001 3:38 AM
I agree with you. I think the documentation for example how to build your own Mozilla distrubition is pretty poor. There are some steps on howto but thats it. When i compiled I got an error that was something I never heard of so I gave it up pretty fast. If I had got involved better from the beginning Im pretty sure I would be a master today on compiling Mozilla :) but today Mozilla is that big so it needs more documentation how to use it.
I also thinks their need to be (more) communitys in the developing process like you are talking about where the "beginner developers" could meet and develop their own Moz applications.
"No. 1 criterion - whatever results in mozilla being widely adopted in the long run"
mozilla.org does not push the Mozilla builds it produces for wide adoption. This is left to distributors of Mozilla like Netscape, Beonex and Nokia. So, Mozilla technologies will be widely adopted if the distributors know they can build products safe in the knowledge that they are building on a stable foundation.
#177 "Everything's ready but X, so we're not shipping."
Friday June 29th, 2001 4:17 AM
When you make a post saying "we need X for 1.0", say out loud to yourself:
"Everything's ready for Mozilla 1.0 but X, so we aren't shipping."
Imagine saying it to your mates. Imagine saying it to mangelo. ;-) Imagine saying it to the press.
I saw someone above saying "Mozilla 1.0 needs favicon.ico support". Let's try this out, shall we?
"Mr. CNet journalist: Everything's ready for Mozilla 1.0 except favicon.ico support, so we're not shipping."
How silly does that sound?
"Mr. CNet journalist: Everything's ready for Mozilla 1.0 except our HTML4 support is not complete as we promised, so we're not shipping." You can justify that (although if it's a long way off, something's gone wrong in the planning process which we are now working out.)
Also: what I meant by not naming specific bugs, but specific goals. "UI should be polished" is a goal, and you can say "We're not shipping 1.0 because the UI isn't finished" and still have some credibility, but you can't put it on a list and tick it off to say it's done, because it's so subject to opinion.
"Mozilla should never steal focus, all UI elements should be inside their respective windows, and the UI should not change unexpectedly (i.e things shift around) when you interact with it." would be a lot better.
Get the idea? :-)
#180 Re: "Everything's ready but X, so we're not shipping."
by Brendon <firstname.lastname@example.org>
Friday June 29th, 2001 5:21 AM
--- "Mozilla should never steal focus, all UI elements should be inside their respective windows, and the UI should not change unexpectedly (i.e things shift around) when you interact with it." would be a lot better. ---
I honestly believe this is the only thing that _I_, as a user of only the browser component feel is required for the 1.0 release of Mozilla.
I'd say in that area you're pretty much set, so concentrate your efforts on other components of Mozilla when possible. Reassign most of the developers working on the browser to Mail, Composer and general problems with the Mozilla framework only leaving a few people to fix top crasher and render bugs. Roll out 1.0, and then continue adding features to the browser and gecko.
#186 Re: Re: "Everything's ready but X, so we're not sh
Friday June 29th, 2001 7:42 AM
I don't know what platform you use, but I'm willing to make a guess it's not Mac. Before you say "Reassign most of the developers working on the browser", be sure that you just aren't lucky. ;) The past few months my Windows machine hasn't been booting windows (Been using Arachne for DOS <http://browser.arachne.cz/> for various reasons...), so I've been testing nightlies on MacOS. They're coming along, but the UI needs work. I've noted a bug in particular earlier, so I won't note any more particular bugs. I also am not sure if you can even *use* certain features on the Mac yet.
A short list of things I'd like fixed on the MacOS at least. (For an idea of the types of UI/performance bugs I've seen...)
#1: Blank windows are bad, as I've said before. At least load the chrome. Mac users are not going to uninstall ATM in order to run Mozilla.
#2: The Preferences window. (Where to begin?) 2a: the left pane should scroll. 2b: the right pane should: scroll, resize window when content exceeds space [not necessarily possible on say 640x480 or 800x600], or be resizable by user. 2c: should be resizable by user. I'll stop there on Preferences...
#3: There should be an easy way to turn off search from address bar. There may well be, but the preferences window is blank. no chrome even... ;) (see #1)
#4: Is there -turbo on a Mac? If so, where is it documented? If not, why not? Simply because of the Application Switcher?
#5: Mozilla should *NOT* need its memory partition resized to 64MB to view some web pages.
#6: Scrolling past the end of a textarea with the right arrow key should not take me back to the top.
Those are the types of things a user will definitely notice in a 1.0 release. It's things like this that should stop a 1.0. If it glares at you, don't put on sunglasses.
Also, a good idea of what users see is at <http://download.cnet.com/…6204.ur.10201-601-6266204> . Note the "Stability" indicator...
#188 Re: "Everything's ready but X, so we're not shippi
Friday June 29th, 2001 8:03 AM
>> "Everything's ready for Mozilla 1.0 but X, so we aren't shipping."
Agreed. ;-) That's what you need.
>> "Mozilla should never steal focus, all UI elements should be inside their respective windows, and the UI should not change unexpectedly (i.e things shift around) when you interact with it." would be a lot better. Right, but remember you were specifically asking not to post a "personal bug list" (tm). ;-) Anyway, in the first thread above I've been proposing a meta-bug for exactly this kind of stuff.
Basically, it appears that this discussion showed that there are quite some different views and expectations from the Mozilla project, hence the differently emphasized opinions on what the "must haves" for 1.0 are.
I basically agree with the "browser user" crowd that says:
- Now more new festures now (even when I personally really miss email encryption) - Stability is fine now, can still be improved, but no blocker anymore - Speed could be improved and footprint could be decreased, but it's about OK now and due to the x-platform development unlikely that especially speed can be improved much. Fine. - UI needs to be polished, for the various reasons that already have been noted (please note: I'm not talking about these one-pixel-off tidbits, but the annoying stuff that Gerv thankfully summarized) ;-)
So, let's go for it!
PS. Someone said this before: Gerv, thanks for asking in the first place. I do hope that the core Mozilla development team is at least now aware of our (different) views ...
#202 Re: "Everything's ready but X, so we're not shippi
Friday June 29th, 2001 12:11 PM
I can't define what are the bugs that need to be fixed for Mozilla 1.0, but I know them when I see them! :-)
How about: if there's a known Internet page (filed in a Bugzilla bug report) that won't work in Mozilla, and does work in the other major browsers (IE 5 or 6 and Opera 5), and it's valid or "nearly" valid HTML (not an Evangelism bug in other words), that's a bug that MUST be fixed for Mozilla 1.0. Perhaps we should limit this to bugs with at least 1 vote -- that way, multiple bug accounts won't help expect to allow someone to vote for more than 10 bugs.
That still may be a little silly: "I created a valid HTML page that Mozilla can't deal with, and I reported and voted for the bug, so Mozilla 1.0 can't ship." However, this may get more people involved with finding and reporting and voting for the bugs that they do find most annoying. If someone wants to open three Bugzilla accounts and enter a few dozen of these bugs, at least they are making a significant positive contribution to the project.
The other criteria for Mozilla 1.0 that I can think of cannot be defined or are too hard to define. Mozilla should not crash "often", Mozilla should not be "extremely irritating to use", and Mozilla should not be "slow" or "take much memory".
#249 Re: Mozilla should never steal focus
by jesse <email@example.com>
Saturday July 7th, 2001 3:17 PM
When you say "Mozilla [1.0] should *never* steal focus" (emphasis mine), you introduce two problems. First, you haven't avoided adding a bug to the "must fix" list -- instead, you've added two or three bugs to the "must fix" list. Also, one of those bugs is 88810, and not everyone agrees on whether/how to fix that bug.
#191 Defining criteria for 1.0 release.
by JBassford <firstname.lastname@example.org>
Friday June 29th, 2001 10:59 AM
It would be unreasonable to think that everybody agreed on this subject.
As I see it there are 7 categories that have been thrown out, along with what each person sees as the order in which they should be prioritized. These categories follow, in alphabetical order:
Documentation Features Functionality Interface Stability Standards Speed
It has been asked that we respond with our personal opinions on the subject, but what is the actual scope of this question? It's well enough for us to all start typing but what's going to be done with this feedback?
1. Does anything we say have any REAL bearing on the project itself?
a) If the point of soliciting opinions is to figure out what people on this planet want from a Mozilla 1.0 release - then asking just the people in this forum is a waste of time. The question should be posed on a far wider scale, soliciting response from a much wider sample.
b) If the purpose of the original question was just to figure out what people who follow this particular forum think, fine.
2. How will our response be used?
a) The implication is that our feedback will (help) determine the decision criteria for a 1.0 release. Is this actually the case? If so, to what degree and in what manner?
b) Is this a way of taking our pulse in terms of Gerv's personal ideas about 1.0 or is it part of a broader effort to actually bring idea to the Power That Be? (My apologies for the wording.)
3. What criteria will be applied against our feedback?
a) It seems to me that a whole series of debate and free-flowing subjective replied will do no more than give an overal "feel" about what we think. If that's the purpose of the original question, that's fine - although I'm not quite sure what good that does the project itself, above and beyond some subjective testing of the waters.
b) If objective metrics are being sought, then it would be much better to withdraw the "open" form of question form resubmit it in the form of a poll. ("Rate these 7 areas of work in terms of the priority you think they should be given. Do you think that Mozilla should be 100% compliant with X prior to a 1.0 relase?", etc.) Then take the feedback, all of which would follow an objective standard of reply, put the numbers into a spreadsheet, and run some statistical analyses on them.
In other words, I can't really see the usefulness that will be gained from simply opening up a subjective, extremely small sample of discussion / debate / argument as has been done here.
If the point is to base Mozilla development on what people want to see - then feedback needs to be solicited in a much more organised and wide-spread fashion, not in a quick "one-off" manner that can't possibly (unless you're really lucky) result in understanding Mozillas eventual user base as a whole. The intentions here are good, but the implementation needs some work.
#194 Please excuse typos and grammer.
by JBassford <email@example.com>
Friday June 29th, 2001 11:07 AM
Oh, how awful. I just read through what I wrote and it's full of all sorts of English mistakes. This MozillaZine interface is definitely not very good (it was my first post here). Next time I will compose offline and copy / paste. Anyway, my apologies to anyone like myself who notices such things.
#196 Re: Please excuse typos and grammer.
by BryanH <BryanZx@excite.com>
Friday June 29th, 2001 11:17 AM
Don't worry, not everyone speaks or writes perfect English here... your thoughts were well organized and correct enough. I agree with you on the poll. And also, why not submit the question "What keeps you from using Mozilla?" to Slashdot or somewhere else with a wider audience?
#195 Re: Defining criteria for 1.0 release.
Friday June 29th, 2001 11:15 AM
I think you've misunderstood.
Basically, this question should have *nothing* to do with development, and shouldn't affect who is working on what. All that the answer to this question - about what the criteria for 1.0 are - outlines is the point at which we should say 'Right, this browser is now ready, this milestone is 1.0'.
What Gerv is asking about is not what people should be working on, but what needs to be finished before the browser is good enough to be labelled 1.0.
#201 Re: Re: Defining criteria for 1.0 release.
by JBassford <firstname.lastname@example.org>
Friday June 29th, 2001 12:09 PM
"What Gerv is asking about is not what people should be working on, but what needs to be finished before the browser is good enough to be labelled 1.0."
How can you determine what needs to be finished without knowing what people should be working on? Answering the question "By what do we judge the readiness of 1.0?" has EVERYTHING to do with what people will be working on between now and then - especially if the answer to that question changes existing work priorities...
Or do you suggest that work just continue and continue until that magical point when "it's ready"? <grin>
Even so, my post has relevance to that also because we're talking about guidelines for readiness and how they are to be judged / incorporated into the Mozilla project...
#235 I would like to suggest a feature freeze and audit
Monday July 2nd, 2001 8:13 PM
I think that its is very important to have stable code. Features are nice but they can be implemented in later releases. The real important thing, especially right before going to 1.0 is to audit that code. That means not just getting a reported bug, sifting through the code and changing 2 lines so that the bug does not happen anymore. No I mean audit. Read that code from head to tail and check for inconsistancies, errors, exploits, or things that have been commented with `well i don't know about this piece but it seems to work' After the audit you got code you can rely on, work with. Then lets see what more brilliant features can be added.
#236 I would like to suggest a feature freeze and audit
Monday July 2nd, 2001 8:13 PM
I think that its is very important to have stable code. Features are nice but they can be implemented in later releases. The real important thing, especially right before going to 1.0 is to audit that code. That means not just getting a reported bug, sifting through the code and changing 2 lines so that the bug does not happen anymore. No I mean audit. Read that code from head to tail and check for inconsistancies, errors, exploits, or things that have been commented with `well i don't know about this piece but it seems to work' After the audit you got code you can rely on, work with. Then lets see what more brilliant features can be added.
#238 Forms! And make Gecko standalone
Tuesday July 3rd, 2001 9:22 AM
Well, I can't speak about the UI cause I only use the engine together with Galeon. But so I can be a bit more detailed about it. :) To make it short: I would consider the engine to be almost perfect. I can't remember the last time, when I had a problem with website rendering. Of course their is a problem with IE based sites but you can't do anything against it (if you encounter such a problem, email the site authors, not the mozilla team!). There is only one thing, that is REALLY annoying. Macpeep already pointed it out quite well. The HTML forms! To be honest, they suck like hell. At least they improve from release to release, but they still suck. I'm not talking about the design, but about the functionality. Sometimes lines disappear or appear, pasted text isn't pasted where I wanted it to be pasted at, sometimes it does not even work... Or I click the end of a line and the line above is selected instead of the line I clicked... I move the cursor above the end of the text and it jumps to the beginning, but it doesn't work the other way round, so I have to scroll down to the bottom everytime I move one char too far... The more text I write, the worse it becomes... really, this is a major annoynance. If a website element isn't rendered perfectly, that's not a problem. It just doesn't look as well. But if it becomes a pain in the ass to write a larger forum entry (luckily I write this one with Netscape 4 at work), I get really pissed... I mean, a textfield isn't something very complex... you could even use the default textfields of either Gtk or the toolkit you use for the port. You wanted to do it more flexible and now it's crap. :( I really think you shouldn't release a Mozilla 1.0 before all those problems are sorted and fixed. Don't get me wrong, I don't want to offend anyone at Mozilla.org for crreating this HTML forms, I just wanted to tell you what is the last thing that I don't like about the engine. I also think that another focus should be the UI. I just don't care because I never use it and I would even suggest, to seperate the engine from the whole Browser package. Let's gecko have it's own version number, so that a final gecko can be released much earlier. You should also think about merging with projects like Galeon and K-Meleon or at least work with them. Cause I don't see that everyone will prefer a cross plattform application. It's nice to have Mozilla cause it's great, but you should also power those plattform depending great gecko browsers. They just kick ass.
So here are my suggestions in short form:
- Work on HTML forms, I mean usability, not visuality - Release a Gecko 1.0 before Mozilla 1.0. - If Gecko 1.0 is released, you should concentrate your work on the Mozilla shell and make the existence of K-Meleon and Galeon more public. - Release stable versions of every shell and/or Gecko if they are ready (I think at least Galeon is almost ready and only waiting for Mozilla 1.0). And make every release public on Mozilla.org. So if Gecko 1.2 is ready, you would just download that and all your shells would work with it. If a new shell is ready, you just download it and it will work with your Gecko. You get my point? I think that would be much more flexible. Of course there should be always a complete Mozilla package with the newest Mozilla shell and the newest Gecko.
I just wish, that would come true. :-|
#253 A personal list of 1.0 release criteria
Monday July 9th, 2001 3:27 PM
While I see no reason to rush to 1.0, I fully agree that a set of release criteria should be established ASAP. I think that if release criteria are established and agreed to by the Mozilla development community (not necessarily users) that a commitment from Mozilla developers to try to address open Bugzilla issues related to the release criteria in a timely fashion is required.
Below is my list of "goals" and the base level below which it should be declared "do not ship this release as 1.0".
DNS = Do Not Ship as 1.0 if requirement is not met
Goal - Mozilla 1.0 must be as fast as Netscape 4.76 or "target" (whichever is faster) for all three major platforms (Mac, Linux, MS-Win) - as measured in the weekly mailnews performance results. <http://www.mozilla.org/ma…_performance_results.html> DNS - Mozilla 1.0 must be no slower than 125% of the speed of Netscape 4.76 or "target" (whichever is slower) for all three major platforms.
Goal - Mozilla 1.0 must be as fast as Netscape 4.76 or "target" (whichever is faster) for all three major platforms (Mac, Linux, MS-Win) - as measured in the weekly browser performance results of I-Bench. <http://www.mozilla.org/qu…wser-archive/i-bench.html> DNS - Mozilla 1.0 must be no slower than 125% of the speed of Netscape 4.76 or "target" (whichever is slower) for all three major platforms.
Web Standards ----------- Goal - Mozilla 1.0 must pass the Official W3C CSS 1 Test Suite <http://www.w3.org/Style/CSS/Test/> DNS - Mozilla 1.0 must meet goal
Goal - Mozilla 1.0 must support all Elements and Attributes in the HTML 4.01 specification DNS - Mozilla 1.0 must meet goal
Goal - Mozilla 1.0 must meet all MUST or REQUIRED level and all the SHOULD level requirements in the HTTP/1.1 specification (rfc2616) "unconditionally compliant" DNS - Mozilla 1.0 must meet all MUST or REQUIRED level requirements in the HTTP/1.1 specification (rfc2616) "conditionally compliant"
Goal - Mozilla 1.0 must meet all HTTP Authentication (rfc2617) requirements DNS - Mozilla 1.0 must meet goal
Goal - Mozilla 1.0 must pass the official MathML 2.0 test suite on all three major platforms. <http://www.w3.org/Math/testsuite/> DNS - Mozilla 1.0 must pass at least 95% of tests on all three platforms
Goal - Mozilla 1.0 must pass the PNG Browser Gamma- and Color-Correction Consistency Tests on all three major platforms. <http://www.libpng.org/pub/png/colorcube/> DNS - Mozilla 1.0 must meet goal
Goal - Mozilla 1.0 must pass all completed DOM Test Suites for DOM Levels 0, 1, and 2 on all three major platforms. <http://www.w3.org/DOM/Test/> <http://xw2k.sdct.itl.nist…v/xml/dom-test-suite.html> DNS - Mozilla 1.0 must pass at least 95% of tests on all three platforms
Goal - Mozilla 1.0 must contain no Common User Agent Problems as described by the W3C discussion document. <http://www.w3.org/TR/2001/NOTE-cuap-20010206> DNS - Mozilla 1.0 must meet goal
News ---- Goal - Mozilla 1.0 must (by default) meet all MUST or REQUIRED level and all the SHOULD level requirements in the current "Good Net-Keeping Seal of Approval" document. (Preferences may be present to disable conforming behavior where desired.) <http://www.newsreaders.com/gnksa/gnksa.txt> DNS - Mozilla 1.0 must (by default) meet all MUST or REQUIRED level requirements in the current "Good Net-Keeping Seal of Approval" document.
Goal - Mozilla 1.0 must meet all reader MUST or REQUIRED level and all the SHOULD level requirements (i.e. "unconditionally compliant") in the NNTP draft document (draft-ietf-nntpext-base-13.txt) <http://www.ietf.org/inter…-ietf-nntpext-base-13.txt> DNS - Mozilla 1.0 must meet all reader MUST or REQUIRED requirements
Composer -------- Goal - Documents produced by Mozilla 1.0 Composer must pass the W3C HTML Validation Service. <http://validator.w3.org/> DNS - Mozilla 1.0 must meet goal
Stability --------- Goal - Mozilla 1.0 must have zero (known) bugs which cause an operating system crash on any of the three major platforms. Application crashes which do not cause the operating system to die may still exist. DNS - Mozilla 1.0 must meet goal
Goal - Mozilla 1.0 must have zero (known) bugs which cause an application crash when visiting the front page for one of the top 25 web sites. DNS - Mozilla 1.0 must meet goal