Another day and another big batch of Phoenix improvements. Joe checked in his slick new toolbar customization work. From the customization dialog, you can now add new toolbars, spacers and spring spacers as well as buttons for Blake's shiney new sidebar panels which are toggled on your customized toolbar. Oh, and Joe's satchel work landed so we have inline autocomplete for web forms! Also, if you've been waiting for import bookmarks to return, Pierre has that working now too. And last but not least, Blake checked in the new download manager and sidebar work. Now you can drag and drop links to the sidebar to begin a download and you can keep your eye on those downloads right there in the sidebar. It's starting to feel a lot like 0.2 :-)
September 2002 Archives
Joe Hewitt rocks! (tomorrow's Phoenix build is worth getting).
Phoenix 0.1 for your browsing pleasure.
- yeah, we know. it's not done. it's just begun.
- yes, your favorite pref will probably make a return in the prefs "advanced" panel.
- the toolbar button order has already changed (use it as an excuse to test toolbar customization).
- yeah, isn't it fast! Don't ya just love that.
- yes, we know about that bookmark hang.
- no, it's not Orbit. It's Orbit iconography applied to the Classic theme which respects system colors, fonts and themes.
- well, theme developers and XUL add-on developers can probably, without too much trouble, modify their goods to make them work with Phoenix (and we'll have incentives).
- yeah, I know, it is fast :) isn't it.
I love learning. Today I learned that Mozilla is an unusable piece of crap because "Mozilla's progress meter is a different color from those in almost every other program." If only we had picked a different color then maybe we'd be closer to having hundreds of millions of users. And here I was thinking that distribution was the problem. What was I thinking! How could I overlook something as obvious as progress meter color.
Wow, cool! People actually read this blog. How exciting. Thanks for all the email.
There have been some misunderstandings about my last post. I'm not suggesting that any of the Mozilla add-ons are bad. On the contrary, I love them, all of them, and use many of them. Neither am I claiming that image #1 represents the Mozilla default. It clearly doesn't. There are easily 7 or 8 non-default items visible there.
My point is this: there are two basic voices that I hear in this project, when it comes to features. The first voice says, "make everything part of the default build and just give users a pref to turn it off if they don't like it." The other voice says, "make it easier for people to build add-ons and plugins and support communities and projects like mozdev for niche features or even popular features that aren't now part of the core mozilla.org release." The first voice has led to an increasingly bloated app with decreasing performance and an almost unusable preferences manager. It's my hope that Phoenix speaks with the second voice. I think it will and I'm encouraged by the potential that customizable toolbars will allow the add-on builders. I also can't wait for the add-on/plug-in manager that will be implemented in Phoenix, making install, management (selective enabling and disabling) and uninstall of plug-ins and add-ons much better. These and other Phoenix changes should make it a lot easier to for the mozdev and other developers and the miriad of wonderful extensions they're building, to flourish.
There are lots of questions swirling about Phoenix. Dave Hyatt, the project owner, has a nice little quiz to help you determine whether or not Phoenix is the right browser for you. But words and sentences are hard so I've put together a visual aid. Take a look at these two images. If you think that image #1 represents a great default browser configuration then Phoenix is probably not for you. If you think that image #2 represents a resonable default configuration then Phoenix might be for you.
We're down to just a couple of changes left to make a Phoenix 0.1 release. The browser is coming along nicely. With customizable toolbars, quicksearch in bookmarks and history, a sensible set of default prefs and a pref manager that doesn't overwhelm people, I think we've got something that people will really like. Not only that but I think we can get the download down to about 7 MB which compares well to Mozilla's 11 MB. And starting up and creating new windows 30-40% faster than Mozilla is pretty sweet too. It's damned cool what expert XUL developers can put together in such a short timeframe.
If you're interested in where we're going with Phoenix after 0.1 you can find out by clicking the milestone of interest over at the Phoenix Roadmap.
Well, I've finally get this "temporary" laptop set up and broken in so that I can actually get work done. I guess that means it's time for the repairman to return my real laptop with a fresh and hopefully longer-lasting hard drive. So I guess I'll be back to normal after a few more days of setup on my old machine.
Some folks are complaining that my site doesn't provide the same experience for folks on low-resolution systems. They're right. This page probably looks like crap on a cellphone too. There's nothing interesting here anyway. If you just can't get enough of this lame weblog and you can't cope with the links over to the left not all showing up in your browser because your resolution is archaic then you're in luck. I've constructed a special version of this site just for you. Click HERE! for the special low-resolution version of the site that I've created just for you.
Last night I fell asleep with Phoenix building on my laptop which sits on a small stool about 4 feet from my bed. I remember thinking as I drifted off to sleep about the curious grinding noise coming from the disk as the build progressed.
When I woke up this morning the machine was powered down. For a moment I thought maybe the power in the house had gone out and the laptop battery had gone down. "This sucks, I'll probably have to restart that build," I though. Then I noticed the green led battery indicator and started to think something might be wrong.
When I went to power up the machine it wouldn't get past the intial bios without failing to find some necessary file and I knew my disk was toast.
The laptop is a Dell Latitude PIV 1.6GHz with 512MB RAM. It's approximately 2 months old. The disk is dead and along with it all my data :(
Today I got a "loaner" laptop from the PC support folks. It's a blazing fast PII 400 with 128MB RAM. It took them about 7 hours from the time I called till I had the loaner in hand and I've spent the last 2 hours getting it set up to be able to build (and all the other stuff I need to get work done). I can't even communicate how much it sucks to set up a build environment on Windows. I really can't wait for linux to get good enough that I'll want to use it as my primary OS. It's a real pain having such a great build system and such a crappy desktop on linux and having such a crappy build system and a great desktop on windows.
What's this Mozilla 1.0 branch all about? Do I want 1.0.1? 1.1? Does 1.1 have all of the 1.0.1 fixes? These questions and more answered over at the mozillaZine forums.
mpt attempts to sidestep his failure to call IE on one if its most obvious and painful usability flaws. Tim Powell calls mpt on his failure and gets bonus points for noting one of Mozilla's most important usability shortcomings.
Whew! Another one down. 3 releases in less than 3 weeks. What fun.
Lots of people have been asking me about the different releases and which ones they should be using. The answer is that it depends on what you want. If the most important thing to you is stability then you probably want to be using Mozilla 1.0.1. If you're interested in performance and new features but you're not willing to endure living on the cutting edge then you want Mozilla 1.1. If you want to see new features before they're released in a final product then you probably want to be using the cutting edge Mozilla 1.2alpha just released. And if you're actually involved in the Mozilla project, testing or developing, then you want to be using the bleeding edge nightly builds. Does that clear it up?
Today the the great mpt dispenses with this bit of wisdom:
To make software learnable and efficient, you can start by asking a couple of simple questions.We'd all like to make mozilla learnable and efficient as well as pleasurable so let's ask and answer these four questions. We'll start with "learnable and efficient" and then move to "pleasurable".
1. What action might someone want to perform?
2. What is the most obvious and efficient interface that can be implemented for triggering this action?
To make software pleasurable, you need to attack the problem in the opposite direction. Examine each action which could be performed on every element in your program.... For each of those, ask:
1. If someone did that, why did she do it?
2. What was she expecting to happen?
So question number one: What actions might someone want to perform? It's clear to me they might want to load up a webpage and use the browser to determine if the page validates according to the World Wide Web Consortium specified
Doctype included in the page source. Yes, it positively the case that most users regularly desire this functionality. What user in his right mind wouldn't want to perform this action? Check documents like HTML and XHTML for conformance to W3C Recommendations and other standards? You bet. All the time. So we move to question number two. Oh, my mistake. Sorry. Validating a page is a task that exactly 3 users in the world actually want to do. What was I thinking.
"There are few advantages to using XHTML if you are sending the content as text/html, and many disadvantages." Only a few people on the planet really get this stuff and Hixie is definitely one of them. Go read what he has to say.
Stop the madness
Today mpt posted his top 10 usability problems for IE. I'm particularly amused that he considers uninstalling a major usability problem for the IE browser. I can just hear mpt's 'users' now, "This thing so easy to use except for the lack of an uninstaller. If only I could uninstall it easily my IE browsing would be the most user friendly experience." Maybe I'm weird, but I when I'm uninstalling an application it's because I don't want to use it any more. When I'm not using it any more the application's usability is moot. I guess he defines usability differently than I do. Things that I think matter the most when it comes to usability are things that help or hinder people while they are _using_ the application.
And in addition to a couple of items which clearly don't belong on the top 10 list mpt omits something that has to be one of the most important usability flaws in IE, that the main browser scrollbar has a fat border to the right of it forcing the user to actually look where he puts his mouse pointer rather than just tossing it against the edge of the screen and knowing you've hit your target. That he would leave off a major usability flaw in one of the most frequently (if not _the_ most frequently) occurring human to browser interactions to make room for his number 5. item "It's extremely difficult to uninstall," just baffles the mind. And this is the guy you want setting priorities for Mozilla UI???
I wonder how long mpt can keep "Plug-ins" off of his top 10 usability problems in Mozilla list. Maybe he'll see the light and pull "Validation" off the list and add "Make the plug-in experience not suck". Matthew, the evidence is mounting. From massless.org (a top mozilla application evangelist):
Then they email me. Then I feel ashamed. Then I email sloppy love letters to Bjarne Stroustrup seeking validation. Then he does a reverse lookup, traces back, exploits an IIS security hole and leaves my server a smoking ruin. Then I feel ashamed. Then I buy a cat and it pees on my bed. So, then I email sloppy love letters to Adrian Tomine* who performs a reverse lookup, traces back, exploits an Apache security hole...
Which can't be good for the users. To have to watch that?...
So all I know is, in regards to the argument they're having: I'm having a harder time getting people to use Mozilla who otherwise would because they have to think about the whole plug-in situation whereas they didn't in IE.
Which is a point that doesn't really address their argument at all, does it?
And, I have to add, the feature everyone loves is tabbed browsing. :)
Oh, and mpt says we should get rid of tabbed browsing too, " leaving it to the window manager". He's so clearly tuned into the pulse of the users.
...all the geeks and the people who coordinate this project have done an admirable job making a web browser that most closely suits the task of grasping and pulling the grand thin tendons of human wisdom today.
It's so much better to use Mozilla, I am even dealing with remembering or re-emailing all my passwords for all the web site memberships I have so I can use Mozilla for everything.
A fellow named Kevin Basil seems to agree with mpt that the lack of a notification to the user that the a page has invalid markup is "a top usability problem for Mozilla ... because it prevents users from using the browser for their daily operations." The problem is that most users don't care why the page isn't working. They care that the page isn't working. Telling a user that he can't use Mozilla to do his banking because his bank wrote the page to work with IE (which is a far cry from mpt's call for a notification "to list the errors in a Web page") simply doesn't make Mozilla more usable. Until he can actually use his bank's web site to do his banking the browser is unusable and no amount of explaining where the blame lies is going to change that. Like Tim Powell says of this indicator, "users will think it reflects their feelings and will do nothing to help them."
Mr. Basil then says "mpt is simply suggesting a simple element in the UI to indicate to the user when the problems are not Mozilla's fault." But as I hinted above Mr. Basil is actually making a different argument than mpt. Mpt is calling for a notification "when a viewed web page contains errors". He is not calling for a notification when a web page is not behaving as expected in Mozilla because the author wrote the page for IE. There's a very big difference between those two.
Anyone that wants to run 50 of his bookmarked sites through the W3C HTML validator will see how quickly an indicator like mpt has suggested becomes almost completely worthless. A majority of the pages I visit regularly have errors. Mpt's error indicator would therefor be active on the majority of pages I visit, even pages which appear to work just fine. There are also pages which validate just fine but contain sufficient real HTML errors (like using alt text for something other than it was intended and failing to use the title attribute correctly) that they are considerably less usable in Mozilla than IE. Mpt's indicator would do nothing for those pages.
This feature request, to visually indicate to the user when a page uses invalid markup, is a fine idea and I support it. I think something like that would be nice. I dispute, however, that it will make the browser significantly more usable for average users or that it belongs in a top 10 list of usability problems with Mozilla. I don't dispute that pages not working for users of Mozilla and Mozilla-based products is a major usability issue. I agree completely. As a matter of fact, if mpt had said that the number 9 usability problem is that pages don't work well in Mozilla I would have said "that's number 9? why not number 1?" But mpt wasn't saying that. He was saying that the lack of a validation indicator was the number 9 usability problem in Mozilla. I don't believe that an indicator makes broken pages any more usable. I also assert, again, that adding a validation indicator would do far less for Mozilla usability than improving the current plug-in experience.