Neil's Place

September 28, 2003

11:44 PM Weblog Milestone 1.0

Hmmm. I finally managed to mess up my weblog temporarily. I posted a link with a missing closing quote and this caused the edit page to not display so I couldn't fix it. This was also the time when I found that the backup system wasn't working. So I had to edit the files manually. All on the 200th entry.

Anyway, congratulations to me for managing to fit 200 posts into one year. That's just over one every two days.

Comments ( 27 )

11:28 PM RDF Introduction

OK. Since you asked, I created a more detailed guide to RDF. It has two parts. The first page describes the model including triples, types and so on, in enough detail to understand RDF, without barely a mention of syntax. The second page describes the RDF-XML syntax, using examples and terms from the previous section.

The goal is so that people can understand the purpose of RDF without getting distracted with XML syntax. So, if you are reading it, make sure to read the first page first, or you'll be confused.

I include it as part of the Mozilla SDK Guide, although it isn't particularly specific to Mozilla.

Comments ( 8 )

September 25, 2003

3:53 PM RDF is like pointers

A lot of people get confused about RDF. Many don't understand why one can't just use some other XML form to accomplish the same thing. For instance, one advantage of RDF is that one can freely mix terms from one RDF vocabulary with another. You can't really do this with XML. Of course, XML people will think you can.

One reason for this is that the XML people are thinking only in terms of syntax. RDF, however, is actually just a model, but happens to have a serialization syntax (there are several actually). If you think solely in terms of syntax, RDF-XML might not offer any advantages since it is just XML too. When thinking in terms of the RDF model being a set of triples, or as a graph, then there becomes a difference.

Unfortunately, thinking this way requires an intuitive leap that many may be unable to take. This is similar in some sense to how people look at pointers in C. Some people are just unable to grasp pointers, no matter how hard they try. Likewise with RDF. With the usage of HTML, XML and so forth, people have grown accustomed to thinking in terms of syntax. It's unlikely, for instance, that someone writing some HTML is thinking about the DOM tree the code produces, rather they are thinking about tags and text. When people start to use RDF, learning syntax is the first thing they learn.

People that are new to RDF, ask questions about problems they have, but are often thinking only about syntax. Often, they ask, 'how do I produce this RDF?' and give an example of RDF-XML. In can be difficult to answer since it's unclear what they have already and what they are trying to do. If the person doesn't understand the RDF model, it can be difficult to explain in terms they can understand.

Comments ( 11 )

September 23, 2003

5:51 PM OK. This is the last one.

There are so many different groups of people using or writing for different aspects of Mozilla, it's impossible to cater to everyone's needs. My recent posts have been based on comments made by others, not necessarily my thoughts. In fact, I didn't have strong opinion on the developer issues I raised until recently.

However, I did want to ensure that comments by dbaron, Boris, Pete Collins and project owners were addressed. There is a rift between groups, whether it be between Seamonkey and Firebird, user and developer, or something else. There are various developers (application, extensions, theme, or otherwise) that "think is [not] doing a good job *clearly* articulating at a higher level the direction the project is heading."

Axel Hecht tried unsuccessfully to get mozdev developers to come up with a set of goals and requirements so that we'd know what issues needed to be addressed. I think that is a great idea. What happened though? The discussion quickly went off-topic and a new Mozilla branch/fork/project was created.

Sure, end-users are important. You can debate about gaining market share for months. Maybe Firebird will achieve world domination. Maybe it won't. There wouldn't be many developers without any end-users. (Of course, there wouldn't be any end-users without developers either.)

The point is, whatever the developer rift is, there is one, and we need to find a way to address it. Petending it doesn't exist isn't helping.

Comments ( 30 )

2:27 PM So many thoughts, so few bullets

There are so many thoughts going on in my head over the last few days. It's hard to come up with a clear response to things. So I won't.

I will, however, do what Danny does by Turning a Blogger Off.

Comments ( 33 )

September 22, 2003

2:44 PM Using Sockets in Mozilla

Now available: a simple guide to using sockets in Mozilla, with an example.

I also added some links to the book Creating Applications with Mozilla in the SDK guide.

Comments ( 5 )

September 21, 2003

4:11 PM More on Mozilla Direction

Asa's weblog provides some commentary on my recent post about Mozilla developers. As would be expected, the comments there go off topic a bit.

I just wanted to clarify something. Asa quotes the following that I wrote:

Developers are getting frustrated by the direction Mozilla is taking and are unsure about developing for a moving target.

He then responds by saying that there are many more extensions for Firebird than the Mozilla Suite. That may be true, but I think that's primarily due to a much heavier marketing effort, the momentum of which creates more extensions and therefore even more interest. The quote mentioned doesn't mention extensions nor does it mention Firebird. Actually, I was refering to the refocus of Mozilla as an end-user product instead of a platform, not on the switch to Firebird. The developers such as myself who have projects that aren't extensions, are frustrated over the ever-changing APIs and the apparent lack of documentation and communication of changes.

Whether the Mozilla Suite is used or the Birds are used really doesn't matter. If people overall prefer Firebird, that's fine. Let's use it instead. We're just concerned that the new end-user focus is going to be at the compromise of the developer.

Comments ( 15 )

September 19, 2003

3:03 PM Mozilla Developer Documentation

Over the years there has been numerous attempts to improve the documentation for Mozilla. Unfortunately, all of these attempts have failed because everyone spends too much time arguing about organization, style sheets, and naming conventions, and no one gets around to writing any documentation. Mozilla developers need some organized and detailed information about how to build applications, with examples.

So I've set up a big Mozilla SDK Table of Contents. Currently, it provides only links to existing documentation such as the XUL tutorial and the book Creating XPCOM Components.

I'll add as much to it as I can. If you have additional documentation to add, please, just write it. Select a section from the table of contents and write it. There won't be any meta-discussion since you only have two choices:

  • Host it on your own site which means you can do what like.
  • Host it on which means you can write documentation the way I tell you to.

That may sound a bit harsh, but it's the only way to get things done. Eventually, I'll get around to providing a template you can just use, and adding a user notes section like just has. Or, I will do the formatting for you.

Also, any comments about additional sections to add would be most welcome.

Comments ( 38 )

September 18, 2003

4:52 PM Using the Mozilla Preferences API

Someone asked for documentation on using the Mozilla preferences service. So I wrote an introduction.

Comments ( 25 )

September 17, 2003

John now has a weblog
And, as expected, it's weird!

9:24 PM On the twelfth day of software devlopment, I received Twelve New Users

"People who write reviews in magazines and web sites aren't your target user. You may get a bad review if your product doesn't meet their qualifications, regardless of whether it would meet those of your users."

Read more about Marketability

This is also the final section of this series. What originally started as a response to a comment on a weblog grew into a twelve part series collecting togther various thoughts I've had over the last couple of years. I'm surprised I actually managed to write a section every day.

Comments ( 32 )

September 16, 2003

10:01 PM On the eleventh day of software devlopment, I received Eleven Mysterious Email Attachments

"Many people are reluctant to enter their age or even their gender on a web form. This is true, even despite that one can usually determine this information or approximate it by looking at you as you sit down on the bus. And someone sitting on the bus is far, far more likely to cause harm to you than Yahoo's database administrator living 2000 miles away ever could."

Read more about Security

Comments ( 30 )

3:31 PM Mozilla Suite vs Firebird causing a rift among developers

"I think the Firebird development community is too small and too exclusive and thus tends to change things whose original rationale they do not know." - David Baron

Indeed. There is a heated discussion on the mozdev project owners mailing list about this topic lately. Developers are getting frustrated by the direction Mozilla is taking and are unsure about developing for a moving target.

Mozilla Firebird, and the focus of the Mozilla Foundation on end users has only worsened this issue. Mozilla Firebird has had very little focus as a developer product for building applications. Sure, the extensions are there, but they target the Firebird UI directly, and since Firebird is a 0.6 release, the developers accept the ongoing changes to the base product.

The Seamonkey framework hasn't changed that much lately. Changes to XUL have been generally insignificant since 1.0. Firebird and the new toolkit seems poised to change that however. Sure, adding features such as custom toolbars are great, but why the change from the base XBL files being in /bindings to now being in /widgets? Compatibility seems to have been intentionally broken. I think that the Firebird developers began to focus too much on the 'simple product' user and lost track of the developer.

With regards to API changes, I think freezing interfaces that have some flaws now is better than rearchitecting them, breaking compatibility, and then freezing them. No matter how you improve the interfaces, there will always be something wrong with them.

One problem though is that Mozilla is significantly more customizable and extensible than other products. Many extensions actually rely on specific elements of the UI or other aspects to remain constant. If your extension depends on there being a Back button with a menu that works a certain way, of course it's going to break if an improvement is made to the base browser product.

Added to which are the hordes of people with nightly builds, beta releases, and people with the Mozilla suite and others with Firebird, and you end up with a vast array of incompatibility problems to deal with. Remember though, has only ever in their history released two API stable browser products. The first was Mozilla 1.0 and the second was Mozilla 1.4. Remember that it's only the hordes of users that want it to work on every release, not the Mozilla Foundation. I don't think that nightly builds should have any requirement to be compatible entirely.

The original point dbaron made was that developers are changing things that they don't know much about. Over time, this usually happens. The reasons why something was done a particular way are lost over time. Specifically, he was referring to the way that the font settings in Firebird were moved deeper in the preferences.

As I said when work on Firebird was just starting (then called Phoenix), the goal of the Firebird project is to make the browser simpler, not to make it more usable.

Comments ( 22 )

September 15, 2003

11:27 PM Better Searches

I've finally figured out how the search system on XULPlanet worked and have updated it. Doing searches should now return useful results.

I've also just noticed that some forums have appeared on I'm not actually sure who put them there though. Mystery administrator perhaps?

Comments ( 20 )

6:18 PM On the tenth day of software devlopment, I received Ten Corrupted Files

"Even if you provide the best documentation in the world about what to do and what not to do ... developers will find a way to do the wrong thing."

Read more about Compatibility

Comments ( 5 )

September 14, 2003

Why Mozilla Doesn't Use Native Widgets
Includes a few things I didn't know

3:12 PM On the ninth day of software devlopment, I received Nine Different Kinds of Linebreaks

"Don't assume that when you use a 'portable' langauge or toolkit, that it will handle all of the portability for you. The toolkits do some of the work for you, but they don't magically do appropriate translation for you if you make incorrect assumptions about how other platforms work."

Read more about Portability

Comments ( 6 )

September 13, 2003

5:47 PM On the eighth day of software devlopment, I received Eight Point Fonts

"When building an application, don't assume that one kind of user is in the majority. In fact, all of your users are in the minority."

Read more about Accessibility

Comments ( 25 )

September 12, 2003

4:25 PM Na'r sedmı giorno ni desenvolvimento do hugbúnağur, j'empfing Sewe Tercüme Ordbok

"People around the world won't be able to enter a valid [zip code] and you'll find that you have a disproportionate number of users from Beverly Hills."

Read more about Localizability

Comments ( 34 )

September 11, 2003

1:19 PM On the sixth day of software devlopment, I received Six Gradient Filter Plug-ins

"The more additional tools that are needed to extend an application, the less likely it is that extensions will be created."

Read more about Extensibility

Comments ( 26 )

September 10, 2003

4:02 PM On the fifth day of software devlopment, I received Five Cool Screensavers

"When people use a computer, they like to dress it up in a such a way to make it their own. This is why systems let you customize the desktop image, add a screensaver and change some fonts and colours. These customizations don't provide any useful value, except to make the user feel at home."

Read more about Customizability

Comments ( 76 )

September 9, 2003

1:30 PM On the fourth day of software devlopment, I received Four Blink Tags

"A well-designed command line interface is better than a poorly designed graphical interface."

Read more about Usability

Comments ( 37 )

September 8, 2003

101 Things Mozilla Can Do - Italian Version
Courtesy of Giovanni

6:14 PM On the third day of software devlopment, I received Three Blue Screens of Death

"Cold pasta is just a bug. It can be fixed."

Read more about Reliability

Comments ( 9 )

12:26 PM You can Contact Us again

I've fixed XULPlanet's broken Contact Us page.

Comments ( 0 )

September 7, 2003

5:34 PM On the second day of software devlopment, I received Two MB of RAM

"A great way to find out which features of an application are actually used by users is to not implement them."

Read more about Functionality

Comments ( 29 )

September 6, 2003

The other Neil gets confused with Segway inventor.
I'm pretty sure they are two different people though.

1:15 PM The Twelve Days of Software Development

One of the problems with building a software product is that you will generally have a particular kind of user that you are targeting your product to in mind, however, you won't generally have any control over what kind of users end up using your products. If you built your product for one kind of user, the others will complain that your product isn't adequate for their purposes. However, if you built your product to suit the second group, the first group will complain.

Some groups are more vocal than others, such that it often skews real overall opinion. For instance, technical end users are very vocal on newsgroups and weblogs such that their opinions may seem more important than others, despite that they may -- for a particular product -- be in the minority of users.

Thus, when building a product, you need to choose the right parts to focus on so that you'll satisfy your target users and the users you think you might end up with. There are a number of things that your application can choose to focus on. Here are twelve possibilities:

  • Efficiency
  • Functionality
  • Reliability
  • Usability
  • Customizability
  • Extensibility
  • Localizability
  • Accessibility
  • Portability
  • Compatibility
  • Security
  • Marketability

Pick two. That's all you'll be able to implement well enough for your first version. For each subsequent version, you might be able to add one more.

Unfortunately, different target groups of users will desire different items from the list above. Technical users often wish to have efficiency and perhaps customizability. Developers would like extensibility. Macintosh users tend to like usability. Your company would like marketability.

One possibilty is to do a bit of each. That's possible, but rarely happens. If you try, you'll fall on your face, since your application will be really good at nothing.

I'm going to duscuss each of the above in more detail over the next twelve days (or probably a little bit longer than that).


When Opera decided to create a browser, they focused very heavily on efficiency. Mozilla decided instead to focus on portability and customizability. For Mozilla Firebird, those features were already implemented, so the developers began to focus on efficiency and usability instead. (Note that they sacrificed some customizabilty and portability to some degree.)

Web browsers have this unfortunate reputation of being slow. This likely stems from people having dialup connections and having to spend significant amounts of time waiting for content to download. This leads to many people believing that browsers need to be faster and so they spend time discussing the speed of one browser over another. When a new browser is released, one of the main topics mentioned on the various news sites is how fast or slow it is compared to competitors, often having a chart showing various simple tests they did. This only perpetuates the problem and makes more people believe that efficiency is of critical importance to the usage of a browser. Many people will choose one over another, simply becuase of a 10% speed benefit, despite that the faster product is worse in all of the other eleven categories listed above.

In reality, performance doesn't really matter in many cases. The difference between a task taking three seconds or four seconds is of trivial importance for many tasks. For instance, let's say application takes seven seconds to start up over a competitor which takes only two. A user that launches the application once a day, five days a week, will end up saving just over 20 minutes of waiting time per year with the second application. Hardly worth fretting over.

For a developer though, you'll likely end up with users who do fret over such things, so you may wish to focus on improving performance. However, each improvement you do costs more time to implement incrementally. The first few changes are simple, but as more performance tuning is done, you'll find that it requires much more effort to implement. At some point, it will just not be worth the effort.

One problem with making performance improvements, is that some systems simply can't be improved. Architectural decisions made in the first version or in later versions simply pervent significant improvements from being made. Much of this is programmer style. Some styles simply aren't designed for performance but for other benefits, for example modularization.

An interpreted language versus a compiled langauge is a common issue, since an interpreted language requires time to parse the code before being run. In many cases, the extra need of a compile step and extra tools may not be worth using a compiled language for simple tasks. In the case of using JavaScript for some aspects of the UI, as Mozilla does, isn't a problem as people can't interact with the UI fast enough for it to matter.

So deciding on whether to focus on efficiency is dependant on what your application does and whether you think your users will demand it.

There are two kinds of performance, actual performance and perceived performance. The former is the speed at which something actually runs, which is easily measured by various tools, while perceived performance is how fast the user thinks something is working, which is much harder to measure. The kind to focus on depends on what's happening. If you're creating a database, actual performance is more important, since often nobody is actually looking at it. If you're creating a end user application, perceived performance is key.

Improving perceived performance can be difficult. You have to trick the user into thinking that they are getting a benefit without necessarily giving them one. A common method is to make sure that it always looks like something is happening. Many applications that take a while to start use a splash screen to disguise the real time it takes. The part of the user's brain that controls their patience resets when something happens such a an image appearing, or a window changing. For greater effect, PhotoShop and other products stream off a list of components they are loading in the splash screen, such that the user has something to look at.

Another trick is to preload some components when the operating system starts up, thus improving the speed at which the application starts later. Unfortunately, one group of users sees right though this and complains about the time and extra memory it requires. This group of people are what I'll discuss tomorrow, the 'Too Much Bloat' people.

Comments ( 9 )

September 5, 2003

Mozilla Preferences Documentation
Haven't seen this one before

Pondering RDF Path
Some thoughts on a node and arc retrieving syntax

Architectural Patterns in the Face of Client-Side Uncertainty
There is only XUL...

11:04 PM Building good examples

I've been trying to come up with a good example to demonstrate Topicalla, since I'm not sure if people know exactly what it's supposed to do. There are some screenshots I've made, but I don't think they do a great job of showing what it does. Part of the problem lies in requiring other pieces that just aren't there yet. For instance, a server or set of servers for handling general search queries, and gathering info that is related to a resource, and the framework for editing things.

So far, I've been using RSS and FOAF as simple examples, as well as a simple movie/actor example. The former two I used because many people are familiar with them and there is a large pool of existing RSS and FOAF ready to use. Unfortunately, RSS files aren't very graph-like by themselves so the added value of RDF isn't demonstrated, and I'm not too fond of showing a demo that makes Topicalla look just like another RSS reader. The movie data can be more graph-like, as actors are associated with different movies in various ways. One issue is getting some public domain movie information and pictures, since I think images will make the screenshots look more interesting.

I've been thinking of a number of other ideas though. Family trees are one possibility, which could build upon FOAF. One could start with a list of people, and drag between people to create relationships. Then I could make a query to ask for how many of my enemies have cousins. In fact, with an RDF Schema, only three properties are really needed, gender, childOf and spouseOf (perhaps variants of the last also). The RDF system could determine a cousin by going up two childOf arcs and then down two childOf arcs, ensuring the middle node wasn't the same. They don't have to be familial relationships though, they could be friends, employees or enemies.

I also thought about extending the animals datasource from the XUL tutorial, since animals are already classified into groups such that RDF types and subclassing can be used, despite that the classifications tend to change as new research is done. But I'm sure it's easier to get publicly available photos of various animals to make the screenshots prettier. I could even go to the zoo and take pictures myself. Actually, I went last week which is what inspired the animals example possibility.

I should point out that Topicalla doesn't really have any built-in support for any kind of data. I've written some samples for RSS, FOAF and so on, but the application doesn't have any special handling for them -- the end user can easily replace the samples with a more powerful UI that views RSS.

Comments ( 4 )

September 4, 2003

1:33 PM Topicalla 0.1.1

OK, I posted a new build of Topicalla. It's better in some ways and worse in others. It's better in that it has a better template parser. It's worse in that listboxes often get messed up and the search fields don't work. This version works on Mozilla 1.5b and the latest nightly builds of Mozilla Firebird. There seems to be some string library incompatibility for Mozilla 1.4 and earlier so it only works there for 1.6 seconds before crashing. I'll work on that issue next.

The main point of this release is that I've also included a command line ReoPath interpreter. It still uses Mozilla libraries though but you can load datasources and execute expressions from the command line. It doesn't currently work for remote RDF, so you'll need to file or chrome URLs.


Comments ( 23 )

September 1, 2003

My greatest contribution to Mozilla ever
Checked in!