So different

I’ve just got to say that I found Katie’s recounting of the conversation amusing, perhaps because it is so familiar. If you take a step back—it’s not so hard for me to do as a former Protestant—Orthodox practice does sound unbelievably intense and mind-numbingly outside the realm of any other Protestant experience. There is something refreshing about hearing other Orthodox Christians describing the same struggles, the same challenges, and the sobriety (and tiredness) of the end of lent. One of the things I’ve grown to love is how Orthodox Christians repent together and fast together. Yes, it’s hard… yes, the conversations can get old… but you’re not alone.

More on the Phoenix renaming

Some people have suggested that Mozilla’s SQL support is unlikely to confuse anyone. I would say the same but that doesn’t change the fact that courts often try to prevent potential confusion. Two companies can, and frequently do, share the same trademark if they are competing with different products or are in different markets. I think that Mozilla SQL support might cause confusion with the FireBird SQL database, as I mentioned earlier. The Pilot pen vs. PalmPilot case makes me think the FireBird database people might have grounds for a legal battle. In that case, the makers of the Pilot pen made the claim that because you used a writing stylus to use the PalmPilot device, there was potential market confusion, despite the fact that the PalmPilot was a totally different market and that the stylus did not resemble a Pilot pen. This is why Pilot is no longer a part of the name of the company or products produced by Palm.

I hope that Boris Zbarsky is correct in his understanding of how Mozilla plans to use the FireBird name. If Mozilla uses it simply as an internal component name like “Necko” this is all overstated. However, given that the browser formerly known as Phoenix will be distributed as a standalone product, I doubt he’s right.

I’m sure it is quite expensive to pay for lawyers and trademark searches, but I believe the right thing for Mozilla to do is to pick a new name and forget about using FireBird. Potential legal issues aside—who knows, the lawyers may have already said there’s no concern with this—it just doesn’t feel good to trample on another open source project’s name.

Phoenix renamed FireBird

Mozillazine has an announcement that the Phoenix browser has been renamed FireBird. This has provoked furious discussion about the legality and morality of stealing the name of the FireBird SQL open source project. Helen Borrie of the FireBird SQL project harshly responded saying “we of the real Firebird Project ARE incensed about this filthiest of dirty tricks, launched without warning by a crowd which has pretensions to being ‘open’ in the broader sense espoused by the OSI. This is not a ‘free and open’ tactic in any sense except that by which felons believe others’ property is ‘free for the taking’ and ‘a glass door is always open’.… The heart of this dispute is not ‘legal comfort’, however. It’s the doing of this dirty deed in the heartland of open source, where we are all supposed to be above such things. If Open Source is to win, we can well do without brother cynically stealing from brother.”

Given that the Mozilla browser has added native SQL support, I believe there could be some confusion that would have legal teeth.

I assume the browser formerly known as Phoenix picked up this SQL support from the Mozilla code as well. If it did, then people may well ask: did the FireBird browser use FireBird database technologies to add support? I know the answer is no, but many will not know that or may be confused.

As much as I like the name FireBird (I liked Phoenix even better) I find it appalling that Mozilla would steal a name from another open source project. Yes, I know that it is typical for open source projects start out by accidentally using the name of another. This is usually easy corrected. I expected better from a well established project like Mozilla.

UPS: no joy

I found the following gem in the discussion thread related to the Speak Up post about the new UPS logo that I mentioned earlier:

I’m not just sad about this redesign. I’m angry.

Little by little, people that call themselves “designers” (but are in fact no-talent idiots who exist only to perpetuate the ill-conceived agendas of visionless corporate drones) are remaking our visual landscape. All traces of humanity—surprise, humor, charm—eventually get replaced by conformity, slickness, and above all, emptiness.

Here’s a company with an icon etched in the brains of every person in America. Anyone who had ever seen the UPS logo can draw it. And that was worth more than anyone could say. What they had was an integral piece of American visual culture. Now, they have a meaningless, overproduced logo which will no doubt be redesigned again in less than a decade.

When Paul Rand designed the UPS logo 42 years ago, he showed it to his daughter and asked her what it was. “It’s a present, daddy!” was her response. Will anyone (or anyone’s daughter) look at the blight on our culture that FutureBrand has brought upon us and say “that’s synchronized commerce through an efficient supply chain?” I think not.

As designers we have a responsibility to look past the petty concerns of the moment and act not just in our own interests, or those of the client, but to create work that speaks to people and adds something to the world. This new logo says nothing, does nothing, and removes a little bit of joy from the world. And that’s bad for designers, bad for people—and bad for UPS.

Shame on you, FutureBrand.

Posted by Scott on 03.26.2003 at 09:30 PM

Infant Usability

Scott McDaniel wrote A Heuristic Evaluation of the Usability of Infants:

“The infant does not conform to normal industry standards of night and day, and its natural language interface is woefully underdeveloped… Infants have only a single error message, which they use for every error. The user, therefore, is left to diagnose each error with relatively little information. The user must remember previous infant states to see if input is required, and the user must also independently check other routine parameters.”

Phoenix has a new name… Mozilla!

Just after the fifth birthday of the code release, draws a new roadmap that charts a bold course for the future. Partially a response to the failures and experience of the past development years, it is also a natural progression and recognition of projects already leading the way.

Key points:

  • All future apps will leverage the Gecko Runtime Environment (GRE).
  • The browser component will utilize the work on Phoenix.
  • Similarly, the standalone Minotaur/Thunderbird project will become the basis for the mail application.
  • The full everything-in-one-process Mozilla suite of apps will be replaced using a more modular approach.
  • Bless the 1.4 release as the new stable release and discourage the use of 1.0 for future work.
  • Fix architectural bugs in the Gecko layout engine to enhance performance, extensibility, and maintenance.
  • Give more power and responsibility to module owners and have fewer people with blanket check-in rights.
  • Relax super-review requirements for those people, such as the module owners, that demonstrate good judgment and ability.

It remains to be seen how this will play out, but I like the essence of the plan. The Phoenix browser is worlds better than Mozilla in some areas and even Mozilla 1.3 is fabulously better than 1.0. Having a more modular architecture should benefit not only Mozilla apps, but applications and products built by other organizations. Having better defined module ownership and the ability and desire to say no to poor quality code should also improve the project.

Still, I have concerns, primarily about user interface. The roadmap has this to say about UI:

It is almost always better to have a competent owner who rules decisively, than to have no owner and live in a state of indecision (N.B.: a committee of more than one or two is not an effective owner). This point is especially true for top-down application design and policy setting, particularly for user-interface design. For coherent UI within an application, there is no substitute for leadership by an “application czar”. For cross-application consistency where it is needed, we expect such czars to communicate, cooperate, and consolidate things such as common default keybindings.

That’s true, as far as it goes… where Mozilla, and open source projects in general have broken down is in actually having the application czar. (Or more to the point, in having good ones that understand user behavior and can design well—most open source projects effectively have an application czar that is the lead programmer.) Having UI involvement and management just at the module level isn’t enough. UI decisions frequently affect overall architecture, from the network on up to the browser chrome and everything in between. Add to the mix that for good or bad, the best designers are rarely top-notch coders. So how does the application czar get elected and respected in the community?

A related challenge is in determining target audience for the application. I’ve seen many end-user complaints that the mozilla developers just don’t work on the things that are most annoying and need to be fixed. Unsurprisingly to me, Phoenix is a better browser than Mozilla because it set out to be a browser for real people. Will the ficticious “Mozilla isn’t for users” mindset continue? Or will the Phoenix practice win? With many more companies deploying and shipping Mozilla (see RedHat and HP for examples) and with this roadmap it’s time to admit that Mozilla is for users.

But who is the user, specifically? I’ve often thought that using a Persona approach such as described by Alan Cooper and others could provide an answer for open source developers. It’d be worth a try. Until then, design for mpt’s mother.

Back to the big picture, the idea of providing an extension mechanism is quite appealing to geeks, but the average person wouldn’t even know to look for extensions. There’s also the shared-computer / internet café to contend with. How will the question of the default set of capabilities be answered? Whatever was in IE? Whatever the module owner likes?

Regardless of these concerns, I believe this is a step in the right direction. Even if done for reasons other than concern for the user, it will benefit them. I just hope can take the additional steps to create processes and products that will result in joyous and satisfied users.

200,000 bugs old and still going strong

Five years ago yesterday, Netscape released the Communicator source code. In the years since then, community members have hammered on the code to create an extraordinary browser that leads the world in standards support and is a platform for other browsers as well as other products.

By coincidence, the 200,000th bug was logged in the bugzilla bug tracking system on the five year anniversary of the source code release. Although bugzilla tracks many components and tools other than the browser and includes features and duplicates as well as unique and real bugs, the magnitude of that bug number is amazing. Many, many bugs have been found and fixed over those five years, making Mozilla a solid and stable tool. A number of these fixed bugs include security exploits that remain unpatched and troubling in other browsers.

Happy birthday, Mozilla!

UPS ditches logo

UPS has a new logo. I’d swear this was an April Fools joke if it hadn’t been announced earlier. Have they gone completely insane? The old UPS logo, one of the most recognized brands in the world, was a distinctive design by Paul Rand created in 1961. The new one, well, it has a semi-swoosh. Boring! I can’t imagine wasting an estimated $20 million on rebranding to that. And in a slow economy, too. The courier-journal has a story which notes the problematic timing of the rebranding.

Old UPS logo: a parcel tied with string above a shieldNew UPS logo: revised shield with no parcel

Update: Subtraction blog nails it:

What this logo lacks, and what Rand’s logo had in spades, is wit. Rand said that he knew when he’d hit upon the right design when his young daughter saw immediately that the top of the shield was a gift box. Its message was clear and simple: UPS delivers good things — the effect was to inspire a smile. In spite of the fact that UPS forbade the use of string to tie up packages, the company recognized the emotional resonance that Rand’s work communicated, and they allowed it to become one of the most well-respected design landmarks of the modern world.