The difference between communicating in person and communicating online is that in person you can almost always tell whether someone is trying to insult you or not, whereas online you can't tell, so if there is any doubt, everyone just assumes that they are.
8:48 PM A sudden thought
12:13 PM Topicalla Timelines
I've added some date handling functions to Topicalla. So now, I can view a set of weblogs in a timeline view. It shows when postings were made. There's a bit of overlap as the entries were made fairly close together. Eventually, you'll be able to zoom in to see each entry better.
11:07 PM Why use XUL?
A number of people have been coming to XulPlanet after being referred by someone who suggested they investigate XUL to see if it is suitable for their purposes. They have wondered why there is no introductory text as to what XUL is and why one might want to use it. So I added a Why use XUL? page.
11:46 AM What is a killer feature?
I posted this on Mozillazine. I thought I'd repost it here because I found it interesting:
Over the last few years, I've seen many people talk about how there isn't a good killer feature in Mozilla. Or in Opera. Or Linux. Or in any other product one might mention. Marc Andressen recently thought so too. Why? Because killer features don't exist. You can't create them.
One could say that tabbed browsing, or popup blocking or any of the Firebird extensions, or 'tools to organize and information-overflown workflow need' (this quote from the post I was repying to) are killer features. Are they? They could be. But they really aren't. Even though I use Mozilla because of them and wouldn't use a different browser.
You see, when a new kind of product is created (the very first browser, the first spreadsheet, the first music downloader,... ), nobody knows much about it. So the creator adds feature after feature. By the time 3.0 or 4.0 comes out, people pretty much know what the application is all about. 'Killer apps' will have millions of users by then. At this point, all of those users have a hard-wired notion of what that kind of application does. For a browser, for example, it views web pages, has a back and forward button and you can use bookmarks. Any feature you add beyond the 3.0/4.0 release simply gets ignored. The users don't care any more about features.
Microsoft keeps coming out with new versions of Office. Every version has lots of features, but no one notices them. Some people yell 'Bloat!", and complain. People figured out what a word processor was supposed to do 10 years ago. Features added after people decided on what the hard-wired definition of word processor was simply go unnoticed, regardless of how useful they might be.
People won't switch to Mozilla or Firebird because of any great features, because those features aren't what people think of as a browser. The only way to get people to use a browser is if that browser is something else. Like, a complex information-overflown workflow organizer.
Oh, and to anyone who wants to create that, don't put a Back button in it -- people will think it's a browser.
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 bugzilla.mozilla.org. 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.
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 http://musicbrainz.org/mm/mm-2.1#Artist), 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.
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="http://www.example.com/weblog"> <badge type="http://purl.org/rss/1.0/" dc:title="RSS 1.0" link="http://www.example.com/weblog/rss.xml"/> <badge type="http://www.w3.org/TR/html4/" dc:title="HTML 4.01"/> <badge type="http://creativecommons.org/licenses/by-nc-sa/1.0/" dc:title="Attribution-NonCommercial-ShareAlike 1.0"/> </rdf:Description>
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.
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.