Neil's Place

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 )