Neil's Place

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 )