Neil's Place

July 26, 2003

12:35 PM Phil discusses bug tracking tools

Phil discusses bug tracking tools. I've used a number of bug tracking tools, both free and commercial. The commercial ones weren't particularly very good either.

In fact, one of them, which I won't mention by name, was so horrible that had I been a part of the company that produced it, I would have been embarrsed by the product, and would have strongly recommended that customers use something else. It's UI had unlabeled fields that you couldn't type into (only one of the fields allowed that), no scrollbars -- to get to bug 60, you had to click Next 10 times -- and you couldn't search by word, you had to search by selecting from a list of criteria. In addition, there were two different classes of bugs. Both were entered and modified in a similar way but with subtle differences in UI. In one bug type, you had no search capability whatsoever; in the other you had to save a bug in a different fashion. A key problem with that was that both bug types used a separate list of indices, meaning there was a bug 45 of one type and a bug 45 of the other. At least, I think there was. The email notifications didn't make it clear which kind it was, so you had to look through both types -- involving many presses of the Next button. Oh, and did I mention that you couldn't resize any of the windows? To top it all off, our company didn't want to pay for a separate license for everybody, so we only had one account per team. It's great fun when you can't reassign a bug to a particular person.

Phil doesn't like Bugzilla. He says:

So how did I manage with it as a user? Trying to see if a bug had already been logged? Failed. Simple search to return all bugs? Failed.

He didn't mention what installation of Bugzilla he was testing with. I assume he was using In Bugzilla's defense, neither of the two failed cases would easily pass on any system with over 200 000 bugs logged in it. One just can't easily narrow down a search from 200 000 to just one bug that easily. And displaying a list of all bugs? Er, no. I'm pretty sure that's wouldn't be a good idea.

Bugzilla does have the advantage over some other tools I've used in that you can easily bookmark searches and bugs. It also has a commenting system which is clearer. While it does have a lot of fields on screen, many of them aren't actually necessary in a non-Mozilla situation. Many users wouldn't need a patch review/acceptance system, for example.

Comments ( 31 )

July 25, 2003

9:33 PM Topicalla Update: customizing

I just added a few things to Topicalla. I put together a simple script to read and convert RSS0.9/RSS2.0 and subscription lists in OPML. Selecting an item in the OPML view opens the corresponding RSS. Of course, it will also work no matter what kind of content it is -- if the URL pointed to by the OPML turns out to be FOAF instead, it will be displayed as such.

I also made the customize window do something useful. One can now add, modify and remove UI associated with particular types of content. For example, given a musician (which has an RDFS class of, I might add some UI which presents the list of albums created by that artist. This works, although I had to pull from a local RDF file, since the MusicBrainz RDF doesn't seem to contain a lot of useful info.

In addition, one can add additional datasources for a type. That means that I can load data from MusicBrainz and from somewhere else -- for example, a source containing music reviews -- whenever I display an artist.

Next, I plan to add the ability to add support for any kind of content.

Comments ( 6 )

July 23, 2003

FOAF to fork ten times
Here's your chance to create your own FOAF variant.

12:57 PM Badges on Weblogs Idea

If you look at a number of weblogs, you'll notice that many have a wide variety of badges (or buttons), indicating various things they support. Such badges include RSS, FOAF, Valid HTML, weblog tools, Creative Commons links, and so on. It's like being a boy scout. Got some RSS? Get an RSS badge. Passed the CSS validator? Get a Valid CSS badge. Then, people proudly display all their badges on their web site.

While this is all fine, we're already starting to get overwhelmed by the sheer number of these badges available that one can receive. Some weblogs have 20 or more. Here's an idea. Rather than put all these badges on your main page, why don't we create a separate file we can list all of our badges in? Then, one can link to it from a weblog using a link tag, so visitors or search tools can find all the supported badges.

For example, the badge file might look like that below. I used RDF here since it is metadata after all, and it would also be easier to combine into a FOAF file.

<rdf:Description about="">
  <badge type=""
         dc:title="RSS 1.0"
  <badge type=""
         dc:title="HTML 4.01"/>
  <badge type=""
         dc:title="Attribution-NonCommercial-ShareAlike 1.0"/>

You could even stick the icon URLs in the file. This might make it suitable for display in an info panel in a browser. A Firebird extension could easily be created for such a purpose.

Then, weblog visitors don't have to load all these badges when they visit a weblog. They just load the badge file if needed. Search tools could index what badges people have, and gather a list of people with certain ones.

One disadvantage is that if one was to remove the RSS link, users and tools would need to download the badge file and then separately download the RSS file, a two step process that previously was one. For RSS (or its successors), it might be more convenient to leave it in a link tag as well.

Comments ( 12 )

July 22, 2003

Aaron gets very specific
It's a long time to wait to see if he's right

July 20, 2003

5:04 PM SVG 1.2 - reimplementing existing technolgoies in incompatible ways

Erik Arvidsson notes how the SVG 1.2 spec describes a set of tags (RCC) for creating custom elements. It's very similar to XBL (although RCC has less features -- and is less already implemented for that matter). It has an equivalent to the children tag and to some degree has the concept of anonymous content.

The spec also refers to dSVG which appears to be a limited set of UI widgets -- kind of like XForms has a limited set of UI widgets also. It also describes a pile of tags for doing scripting-like tasks without scripting (also like XForms).

The dSVG spec contains the phrase: 'Enables Web designers with no programming skills to create dynamic, interactive Web applications'. Aaaaaaaaaarrrrrrrrrrrggggggggggggghhhhhhhhhhhhh!!!!!!!!! Bzzzzt. Wrong! The last thing the world needs is more web designers with no programming skills making web applications. Have you seen the existing Web? Most of those web designers don't even understand CSS. Imagine:

Customer - how will you build our new web site?
Contractor - we are going to hire some web designers with no programming skills to build you a dynamic, interactive Web application.
Customer - and people will be able to use it?
Contractor - oh, you want a usable application? That will cost a lot more.

It's one thing to make things easier to implement. It's another to make it 'too easy'. (Note: people who don't understand programming won't understand programming even if you disguise it as XML.) In my opinion, it's better if something is more difficult to do -- you'll find that it makes for better, smarter people working on it.

Anyway, getting back on topic, there are already XUL and other similar languages for creating UI in web applications. Why not just use them, or expand on them, or use them as a starting point? Because they aren't W3C recommendations? I'm beginning to see why some people don't like the W3C.

The SVG spec also refers to some functions added to the 'window' object for loading and posting content. Huh? And this is specific to vector graphics how? Is it because the SVG working group wants to compete with Flash?

All of these things I've mentioned have one thing in common: None of them belong in a specification of a vector graphics language. I realize it's still a working draft, but it seems the authors have just given in and randomly added unrelated features, instead of creating a more robust vector graphics language.

Comments ( 30 )

July 19, 2003

2:53 PM Lifecycle of a Mozilla developer

Here are the traditonal steps used in becoming a Mozilla developer:

  • Hear about Mozilla from someone or somewhere
  • Download Mozilla or Mozilla Firebird and like it
  • Participate in discussions on Mozillazine forums
  • Start filing a few bugs
  • Help others get started with Mozilla
  • Learn some Mozilla terminology so you can help get bugs filed properly
  • Learn XUL
  • Start a simple project on
  • Start helping others with XUL and Mozilla questions on newsgroups and IRC
  • Submit your first XUL/JS patch for Mozilla
  • Check out and attempt to compile Mozilla for yourself
  • Continue submitting patches until people start to trust you
  • Get CVS access
  • Give code reviews for patches from other developers
  • Try to understand how the backend C++ code works
  • Submit your first C++ patch
  • Continue until people feel you are a key developer on some Mozilla code module
  • Become a module owner or module peer
  • Get hired by Netscape to work on Mozilla full time
  • Learn all of the secret in-jokes and make cryptic comments on your weblog
  • Keep developing until you get laid off
  • Say you'll continue with Mozilla development but to a lesser extent.

OK, so those last few don't apply any more. But, the farther you go up the ladder, the fewer people you find. Which is why there are so many more end users than developers and so many more XUL developers than C++ developers working on Mozilla.

Comments ( 34 )

July 18, 2003

Somebody has been watching too many Honda ads
I wonder if it took over 600 takes?

XPCOM components in Java
This could get interesting

Eric Meyer wants to go to Norway
Does he secretly want to work for Opera?

12:22 PM Some commentary on the future of browsers

  • Simon Willison - The Google Browser
  • Tim Bray - Browser Dream
  • Response by Danny Ayers
  • Edd Dumbill - Living in the unsupported 5%

Comments ( 1 )

July 16, 2003

Who knew so many things could kill you?
But I've always wanted a conveniently packaged box of everything.

Tim has a CSS cursors test page
Complete with CSS properties and images of each cursor

Mozilla + Google?
Anything could happen now

Mozilla as Server
By pavlov

July 15, 2003

6:48 PM Mozilla, Netscape and all that

I'm sure you've heard about the Mozilla News and the AOL cuts. Presumably this means the end of the line for Netscape Navigator.

I can only think of one thing to say.

Comments ( 2 )

July 14, 2003

Whoa! I just posted something on Slashdot!
I may just have completely lost my mind.

What Are We Afraid Of, Really?
The only people in the RSS community who may really lose when the big guys start throwing their weight around are those who have placed great personal importance on their contributions and roles being recognized and respected.

July 13, 2003

Sequences in XPath 2.0
I didn't know about sequences, but lists in Reopath work this way too.

July 12, 2003

Updated Topicalla Image
Searchable view of all loaded RSS feeds together

July 11, 2003

Mark adds a disclaimer
Too bad the "RSS feed isn't updating" (quote used without permission)

7:44 PM Topicalla not in Mozilla Firebird

By the way, I can't get Topicalla to work in Mozilla Firebird. I don't know why. It just won't recognize the component. Today, I have managed to write the ClassInfo stuff for it, which in Mozilla teminology means that it can be accessed without using XPCOM, as in, the component can be instantiated with a JavaScript constructor and called from a remote site. But I don't want to release it like that before the RDF security review is done.

Comments ( 23 )