MozillaZine's ChromeZone Now Open!
Monday May 24th, 1999
Steve Morrison, creator of the XULTool, has joined MozillaZine (as some of you may already know). He has been hard at work getting the XULTool working on our site, and we're pleased to announce that the ChromeZone is now online.
Now, with a simple form, you can change the look and feel of Mozilla, and create your own themes! You can also choose from some ready-made themes we have available. You can also send your own themes to ChromeZone for addition to our site.
So, fire up apprunner and head over to the chromeZone.
We got a lot of great entries for our little "name our new chrome area" contest, but in our final vote, "ChromeZone" came out on top. A number of people submitted the name "ChromeZone" or a variation for our contest. Clayton Scott was the first, however, and his prize is a stuffed Mozilla doll from Netscape. I know we didn't promise any prizes for the contest, but we wanted to give something to the winner.
Thanks to everyone for you contributions, and if you have any suggestions for the chromeZone, let us know.
#361 Re:MozillaZine's ChromeZone Now Open!
Tuesday June 8th, 1999 2:16 PM
You are replying to this message
Anthony, "The 'chrome' of MSIE 5.0 was originally slated to be an XML wrapper that would be rendered by the ShellDocObject itself."
Yes, I was aware of that fact. A fact you brought to the table (aprox 75 or so posts back). My comments were directed at Bruce's argument stratigy specifically, not the "XUL vs. Native" argument as a whole.
The reason I posted them was because, your comment aside, there was no forward movement in the "XUL will fail" statements Bruce was posting (since just before the posts numbered 100). He was simply stating that "average windows users would not take to XUL, and when asked to back up said argument, he would make a glib remark, or off-handedly dismiss the request as "you just don't get it".
Now, again, your post aside, he seemed to be reverting to this line of "attack", by changing tact slightly and now claiming that XUL/chromeSkins won't fly because no other windows apps did this (at least none that he decided were valid) and used his patented "dismiss and dodge technique" by insinuating that arialb was possibly too young to have a valid point.
It just seemed to me that after 350+ posts within which he put forth very little actual argument, and just re-phrased and side-stepped, he was only arguing for arguments sake.
Now, your point WAS valid. However, before ringing the death-nell on XUL, just yet. lets consider some other points.
The comparison MS made was between IE with standard UI, IE with XML UI and IE with proprietary skinability. It was simply a test of UI. Also, without access to the three versions, I can't say as to how drastic a difference there was between these UI's
This isn't the case here though. we have a comparision of Mozilla, and its UI, with IE and its UI. so, take into consideration that Moz is a MUCH smaller install, its browser engine is faster, more stable, and more complient, then throw in the fact that it has XUL. While there will be (almost impersievable) differences in widget "look and feel" you have a whole bunch of other factors to consider, it isn't as simple as Native UI vs. XUL anymore.
Now, on to "skinability". This is a side effect of XUL. Its main goal was to make the software more portable. This was a decision on the part of the designers, so that extra time wasn't wasted re-coding for all new platforms, and thereby decrease the time-to-release. They just happened to design user-definablity into the model as well. While XUL will most likely be used in this manner (wookie-head back buttons here we come) there will be also the exceptional ability to produce real web-apps.
As a quick example, online e-mail servers (besides MS's HotMail) could offer a XUL app to actually edit HTML e-mail online, not just a big text box for subject, that's an amazing value add to an end user.
The rest of mozilla's, and XUL's appeal will be, and must be, brought into consideration, when considering XUL's end-user viability.