Year: 2002

On Monday the Mozilla Phoenix project released its first milestone, version 0.1. Download it and try it out. This is a terrific first milestone. Because of its heavy use of Mozilla, this browser behaves more like a 1.0 release in terms of the quality and capabilities of its page layout and rendering. Yes, there are many parts that still need polish, but this is awesome. Keep up the good work, guys.

Of all the things the Phoenix developers are doing, I believe the plug-in/add-on manager is one of the most important. It is getting more difficult for add-ons to integrate into Mozilla, let alone the Gecko-based browsers that they should also work with. In most cases, the add-ons make assumptions about what menus are available and add overlays. I was thinking the other day, what if Windows 95 had included a generic program installer. Every program does similar things when installing. It would have made more sense to just have a standard package format and script for the installer to run. Of course then InstallShield would be out of business and Microsoft would be charging for installs of everyone’s apps. In any case, it would be nice if Phoenix could set up well-defined hooks into the application that mean that the add-on doesn’t need to know much about the menu structure. Microsoft products, especially Word, have had this kind of extensibility for years.

Off the top of my head, here’s a few application hooks that I believe will be important for add-on creators. I’m thinking new menus, new toolbars, and new buttons for specific toolbars will be heavily used, particularly now that toolbar customization is a reality. Event hooks to support things like mouse gestures and context menu changes also need to be considered. I suspect there are more exotic kinds of hooks that haven’t even been considered because nobody’s invented useful things for them yet. For example, I can imagine automatic spell checking of textareas and inputs or adding user page load filters. I’m hoping that Phoenix will provide an elegant mechanism for adding on to the application and managing these add-ons. If they do this right, I hope it can become a part of all Mozilla-based browsers.

I’ve been working on a web app that uses UTF-8 encoding and have been surprised at how little information is available about how to do internationalization that works with all browsers. (A.J. Flavell’s “FORM submission and i18n” article and related charset issues site were quite helpful.) Consider this my small contribution. Here’s the scenario for my app: users can enter a search string and it will search a database for matching entries. The search form includes a few other contols so there are a number of variations and potentially 20 named fields. I only want to show the relevant name/value pairs on the URL if possible. If I submit the form with the GET method, all fields are shown on the URL, even if their values are null, which is fairly ugly. I could use a POST, but then the URL can’t be sent to others and generate the same result. The search is also an idempotent transaction (it is just retrieving data and has no side-effects), so I’d prefer to use GET.

When I submit the form, the search field is properly encoded according to RFC 2279 (which obsoletes RFC 2044). That means that non-US-ASCII characters are converted into a %nn format, where n is a hexadecimal digit. For example, α would be converted into %CE%B1. Since I want control of the resulting URL, I thought I’d use JavaScript’s location.href to set the URL explicitly. I then ran into the problem of how to properly URL-encode the strings. I’d used the JavaScript escape() function in the past to fix up ASCII characters that are not URL safe, but escape() does not handle unicode characters well. In IE, unicode characters are suported, but the function generates a %unnnn format which is not well understood by servers. It would give %u03B1 for the previous example. What to do?

I found the encodeURI() and encodeURIComponent() functions that are new to IE5.5, Netscape 6+, and Mozilla. Thankfully, they do exactly what I want. Now I just need to figure what to do with older browsers such as IE5 and Netscape 4 (forgetting them is not yet an option). I wonder if anyone has written JavaScript code that does this encoding. I suppose I could submit the form and just live with the long URL.

I just happened to think that all my mozilla and IE5.5 bookmarklets should probably be converted to using encodeURIComponent() instead of escape(). That would allow searching for non-ASCII characters.

I’ve been trying out the latest nightly of Phoenix and was about to complain that form scrollbars were broken. Turns out that bug 170184 is undoubtably the cause. Sharing most of the codebase with the Mozilla trunk has many advantages, but running into this kind of problem when you’re trying to release a milestone has got to be frustrating. Since Phoenix contains so much of Mozilla, determining where a bug is may be challenging. At least they’re in the same bug tracking system so it will be easy to move them if they’re incorrectly classified.

Asa has apparently decided it is a good idea to ignore or downplay complaints about the usability of his blog. He writes:

Some folks are complaining that my site doesn’t provide the same experience for folks on low-resolution systems. They’re right…. If … 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.

[He then provides a link to view the source of the page.]

What he describes is a common problem with framed pages: web designers will set frames to have no scrollbars and just pretend that everyone uses the exact same screen resolution and font sizes that they do. This frequently causes inaccessible content just like that seen in Asa’s blog. But Asa isn’t using frames, he’s using the shiny new CSS (validated no less!) that is supposed to cure world hunger and bring world peace. Or something like that.

The problem is that CSS position: fixed elements (those blocks that act like frames) get overflow: visible by default. If they had overflow: auto they would get scrollbars when necessary. Asa could easily fix his blog by adding overflow: auto to the .leftcontent class in his style sheet. I hope he does. I understand people blog for the fun of it and that you can’t please everyone, but this is a trivial change that doesn’t fundamentally change his design.

It troubled me that at least with old framesets, if you didn’t do anything special, the default was to get scrollbars automatically if they were necessary. With the CSS replacement, you now need to add both position: fixed and overflow: auto to get the same behavior. I suspect that many designers using position: fixed will, because of ignorance, arrogance, forgetfulness, or by design, omit the overflow: auto and therefore create sites that have accessibility problems. This prompted me to file bug 164983. Too bad this isn’t a technically feasible solution. In bug 105796 mpt made a similar suggestion which would also help with frames.

I find it ironic that because IE doesn’t apparently support position: fixed, Asa’s blog is more usable in IE.

I found a terrific article describing High Bridge in 1940. The article takes you on a “walking tour” around the village and tells you about the people and places you’d have seen at the time. The map related to the article is apparently missing, but even without it you can generally find your way around. The article is from the April 2000 issue of Kentucky Explorer magazine. As I continue to work on the rail-trail, I love finding out more about the history of the area.

Find out all about the accessibility work going on for the Mozilla project through the groovy shortcut URL of the day: www.accessmozilla.org

Death is a painful reality of this world. Sometimes it sneaks up on us and catches us by surprise. Other times we see it coming in the slow darkness falling over loved ones as they struggle for each breath in their last months with us. Either way, death shocks us. It feels terribly wrong, like we were never meant for this.

A year ago, the horrible events of a morning brought a day where we desperately wished for the routine, the typical. But the routine was gone, obliterated by the ever-present images, voices, and commentary. We stared at the massive flames, the crashing planes, and the sight of people falling or jumping to their deaths. In my office, we tried to work, if only to distract ourselves. We spoke in hushed voices of stunned disbelief.

We learned that people had come to our country, lived in the midst of us and our freedoms, and abused them in order to hurt others. The questions came: What kind of person would think to do this kind of evil? Why would they want to hurt us? How can we help those in need?

It’s a paradox: in the midst of seeing this tragic hatred unleashed, we also saw beautiful sacrifice and love demonstrated. It seems to me that this is always the choice we face. Expressed the most simply, we can use our freedom to love or to hate. And our choices can greatly impact others.

In response to the death and destruction, we pray and mourn, and care for those that have lost their family and friends. In the funeral hymn of the Orthodox Church we sing “Memory Eternal” As James Ferrenberg explains, this is not just to remind us, but that Christ will remember those who have died. As they were being crucified together, the wise thief begged Christ to remember him when he came into his kingdom. Christ replied that he would be with him in Paradise. Memory Eternal!

An IBM developerWorks article discusses design and implementation considerations related to Progress Indicators. The article distinguishes between responsiveness and performance. Responsiveness is how quickly an app acknowledges and indicates acceptance of user input. Performance is how quickly it completes a task and displays the final results. A more responsive app contributes more to user satisfaction than quick performance by itself. A quick response can make the application feel faster, even if it takes longer on an overall task.

“Progress indication is needed because: (1) there are inevitable limitations in UI performance, that is, there are always cases where the user will have to wait for a final result, and (2) increased UI responsiveness, or improved communication with the user, can make the wait more acceptable to the user.”

I noticed the other day that the throbber makes Mozilla feel responsive. It activates immediately after clicking a link or entering a URL. The progress indicator in the status bar only seems to show up after a fairly lengthy period of time. For those that want to eliminate the throbber completely, this points out the need for better responsiveness in the rest of the UI.

The article is packed with practical and specific information. All designers and developers would do well to carefully consider the information in this article and how they could improve their application’s responsiveness.

Thanks Blake for responding to my earlier comments about Phoenix. It’s always nice to get the scoop direct from the developers. I’m delighted to hear that Phoenix will be for “normal users” and that you’ll be working on it for a 0.1 release soon. I’m looking forward to it.

Wayne Olson recently posted an article from The Onion Dome. If you’re Orthodox, this is fun.