uberconcept.com

This chapter is all about goals. His major point is that you should work to establish good goals. Goals are things that the user wants, an they might not spring to mind immediately. An example of a goal is to make sure that people don’t get humiliated by your software.

He then goes into a big spiel about the need for software to be polite.

page 161

If the software is stingy with information… the user will dislike the software and have an unpleasant experience.

If software is generous with its information people will not read it. Software should be stingy with information but should provide the right information.

page 163

Every bit of my PC’s personal software should work hard to remember my work habits, and particularly, everything I say to it

Fantastic. So software will now collect this information and make bad guesses based on it. Microsoft makes some seriously bad software because it is not able to identify why people are doing what they are doing. The end result of this approach would be a lot of code would be written and interaction is likely to worse.

page 165

Why can’t it [browser] use that idle time to preload links that are visible?

There are extensions to firefox to do this (eg fasterox). Most pages have a lot of links (hundreds) but only a few will be visited. However the general opinion of this is that it is a waste of bandwidth and it is frowned on by many webmasters and I believe many work to actively block this kind of access.

page 166

Software is always whining at me with confirmation dialog boxes and bragging to me with unnecessary little status bars

I thought you liked software to be generous with information.

page 166

I’ll click on the URL of something I’d like to see, only to get a nasty “404 link no found” error message. Why can’t the search engine periodically check each link to see if it still exists?

They do, you should try using google. However there will always be a difference between the time it last spidered the page and the time you click on the link. It would also be computationally prohibitive to check each link as it is displayed on the page.

page 167

When I use an application, I always maximize it to use the entire available screen. I then use the windows taskbar to change from one program to another. But the applications I run don’t seem to notice this fact, especially the new ones. I frequently tell them to maximize themselves even thought they should be able to see my preference is clear an unequivocal. Other users keep their applications in smaller windows so they can see their desktop.

The problem with this is that Alan is imposing his preferences for computing on other people. I personally prefer some windows to be maximised and others not to be maximised. For example I maximise browsers, editors and IDEs. I open Explorer, MMC tools, putty and winSCP in smaller windows.

In addition it would seem Alan does not know the software he is using. Almost all applications remember what size the window was when you last used the application and open to that size. So Alan’s requirements (since he only works maximised) and mine (mixed) are already met.

Alan then moves on to a case study about a product called Drumbeat. Drumbeat was an automatic code generation tool (using ASP or apparently other options) which also lets you edit the HTML visually.
page 177

The product has been successful, despite the fact that many other Web-site-building programs preceded it to market.

Well gosh golly darn Alan: The product doesn’t really exist any more. The domain now redirects to adobe and from some quick googling around, it would seem that drumbeat was bought by Macromedia, rolled into dreamweaver ultradev and in turn macromedia was bought by Adobe. So I guess it kinda still exists.

As it turns out I actually used the descendant of this product in Dreamweaver Ultradev days. The code generation side of things was horrible. You see this product highlights the problems that occur when you move too far a from technical grounding. Using this kind of product is making a rod for your own back. You get up and running quickly but you soon run into limitations with the tools to generate the code. When you look at the code your discover that it is difficult to modify, verbose and poorly performing. Put simply product like this do not scale well and anything worth much at all will need to scale.

This chapter is all about how usability testing should fit into the development process. He suggests that it should be integrated into the process from the beginning right through to the end.

He also makes some very valid point about interfaces that are visually attractive.
page 211

One of the top prize winners was … decidedly non-graphic, showing only a textual display that was singularly stiff, rectilinear, and aesthetically primitive. Yet the program was a clear winner because the design paid close attention to the peculiar needs of the all-volunteer sales staff.

All too often people confuse good UI design with aesthetically pleasing. While there can be overlap these two are by not linked.

However, finally at the end of the chapter he describes that process that Microsoft went through to release a decent version of windows (4 years and 3 released versions). He then suggests that Microsoft could have saved a lot of time and money getting it right the first time. The problem with this is that is assumes it was possible for Microsoft to build a decent version without those attempts. All software involves a significant amount of iteration. The reality is that most first versions of software are terrible, deal with it. Software is an iterative process.

Chapter 11 is all about designing for people. Some good suggestions are included here also, including a description of the different types of users you get. He makes the point that people tend to transition out of beginner very quickly but transition more slowly from intermediate. In contrast software is written concentrating more in expert users, instead of a bell curve with most users in intermediate.

He also goes on to talk about the design process, suggesting that people being by suspending reality and start brainstorming. This is something that engineers tend not to be good at as they are more grounded in reality. What he is describing seems to be a concrete example of Steve Jobs’ Reality Distortion Field (RDF).

Finally Alan goes on to describe the process of designing a product, logitech’s scanman scanner. One problem with this is that the type of product (a rolled up newspaper type scanner) seems to have disappeared off the market. There are a number of problems with this kind of scanner (prone to jams, requires flat and clean paper, requires even edges) and it seems that they are no longer produced. However most of Alan’s work seemed to be on the software itself rather than the scanner.

Vic and I just got back from a lovely long weekend in the Blue Mountains. I took a few photos while we were away.

Thursday

We left a little late and got to Leura for lunch. After pottering around Leura for a couple of hours (Leura has some lovely shops), we checked into the place we were staying. This was Secrets Hideaway, a number of small studio apartments set is beautiful gardens. The couple running the place were lovely, great for advice for what was happening in the region. It was set in a gorgeous garden. There was quite a good kitchenette too, which was great for self-catering.

When we checked in a number of walks were recommended, so we charged out to get some fresh mountain air. At this point Vic’s memory and mine diverge: I remember being told that the walk would take 3 hours, Vic remembers 1 hour. We parked our car at Neates Glen lookout and walked down the road to the Grand Canyon lookout. From there we started down on the loop back to the car through the grand canyon.

By the time we had parked the car it was 4:25, with sunset at about 6pm. The walk was lovely, until about an hour into the walk. At this point Vic pointed out it would get dark in about half an hour. You don’t want to get stuck in a canyon (dark and cold) in the blue mountains after dark. Fortunately it was just starting to get really dark by the time we got back to the car. I was about half an hour away from calling emergency services.

Friday

We went for a walk in the morning to Anvil lookout, Perry’s lookdown and Dockers lookout. Some of the tracks there were closed as a result of the fires last summer. One of the problems with the fires is that trees continue to drop long after the fires, hence the closed tracks.

The fires had gone right through this area last summer and it was amazing to see the new growth. Fires are just part of the cycle of bush life in Australia. Some plants (eg the banksia) will only release their seeds in a fire.

We went to Leura to have lunch at Solitary Kiosk. There is a lovely view, the food was excellent and it has a great atmosphere. Originally we were going to try to have lunch at the restaurant but there was a wedding booked on the day we wanted to go.

After lunch we went back to the cottage and curled up with a book, in my case On War - Carl von Clausewitz.

Saturday

On Saturday we went to the Three sisters at Katoomba. In a moment of rash enthusiasm we started walking down the grand staircase to the bottom of the cliffs. Half way down we realised we would need to walk back to the top, so we turned around and came back.

Once again after lunch we went for the boring option of staying back and reading.

For dinner we went out to a local Indian restaurant.

Sunday

After checking out we went out to Jenolan Caves. There are quite a few different tours you can go on, we went on a self guided tour and the River Cave tour. The place is just awesome. The scale is just beyond what you imagine, even driving through the grand archway is amazing.

It was really hard to take anything close to good photos. I’m sure that with the right equipment you could get better pictures, even so I imagine it would be hard. If I used the flash, it tended to light things unevenly and also made things look reddish. Without the flash the aperture needed to stay open for quite a while, which tended to result in shaky photographs.

I broke my mail server.. twice. Sorry if you were trying to email me and had some problems.

During the changes to improve spam filtering, I made a mistake in the configuration. I didn’t notice the problem for a couple of days.

Having fixed that I updated my backup script. Unfortunately I stopped the postfix daemon and didn’t restart it (copy and paste error).

Sorry if you have been trying to get in touch.

I get quite a lot of spam on my work email account. One of the email addresses for the account is part of the whois records for a couple of domains and was also used to post to a list. Whatever the reasons I get something like 100 spam emails a day.

To try to cut down the amount of spam that hits my inbox I’ve been using thunderbird’s bayesian spam filter, which cut down the messages to hit my inbox to around 10. I also set up spam assassin (bayesian) on our mail server a little while ago, which dropped the emails to about 5. While this was better, it was still pretty annoying.

Around a year ago a came across an article on spam filtering with postfix (which is what we use as an MTA). I had the time to actually look at it and set up a modified version on our mail server.

For the first week after setting this up I did not recieve a single spam email. Two weeks on I’ve recieved under 10 spam emails. Why does is work?

Real Time Blacklists (RBL)

One of the things recommended by the article is configuring one or more RBLs. A RBL is a list of IP addresses or IP address blocks that are thought/known to send spam. The mail server queries the RBL with IP address of an email it has received. If the IP address is in the list, it drops the email. There are a lot of advantages to this, one being that is saves your bandwidth as the email can be rejected before it is recieved.

The problems come with how that list is assembled. People’s views on RBLs are rather polarised. Some RBLs blackhole a whole IP block segment if a single IP address is used to send spam, the thinking being that you punish all the users so that they complain to the ISP/Colo/Host to discourage them from hosting spammers. The issue is selecting a good RBL. The article suggests a few good RBLs.

Greylisting

Greylisting was new to me. The theory behind greylisting is that most spammers do not correctly follow the specifications for email, which most legitimate mail servers do. When an email arrives the mail server checks to see if an email from the same sender, to the same recipient, from the same IP address matches any that have been sent in the past. If a match is found the email goes through immediately. However if the email does not match, it sends a message back to the mail server that sent the email asking for the server to retry after a specified interval. The email is delivered if sending the email is re-attempted.

This is probably the single best addition to spam filtering I’ve ever come across. It means that sending spam become more expensive and difficult to the spammer. Most of the time when spam is sent the cost is often borne by person recieving it. Greylisting means the spammer must run a decent MTA and most emails will need to be sent twice. This can make it just hard enough for spammers to ignore you as target, particularly when there are pleny of mail servers out there that don’t use greylisting.

In my case after reading the article and doing some searching around I decided on postgrey.

Greylisting + RBL

However the real beaty of this setup comes with the combination of the greylisting and RBLs. The reason is that many RBLs run honeypots to attract spam. That means in the time between the first email being sent and the second email being sent, the honeypots may have picked up emails from the same spam run. By the time the second spam emailhas been sent, the IP address has been added to the RBL and the email will be rejected.

Chapter 9 makes some excellent points.

One is that you cannot design for all users. You need to select a subset of users to design and build for otherwise you will end up with a contradictory and bloated product.

He also goes on to describe some concrete ways to you can help design better applications. One of these is to develop personas who describe your typical users. This helps to personalise the users. Thinking about how the application would be used from their perspective does a lot for usability.

page 146

The Sony programmers fell into the three-number trap of 0, 1, and infinity… From a programmers point of view, 36 - being greater than either 0 or 1 - is the same as infinity.

This is an excellent point and comes up in a lot of applications. Programmers need to have an idea how many items are likely to be displayed and use an appropriate techniques for handling that number of items.

This chapter is a diatribe against re-using code. Once again it is fascinating that Alan has quoted Fred Brooks earlier but seems to have missed many of his points. In his essay No Silver Bullet Brooks talks about re-use as one of the areas that has the most potential to improve software development.

He complains about the effect of re-use on usability, ignoring many of the benefits re-use brings to usability. Re-use ensures a common look and feel to application.

page 107

The programmer will begin construction by copying the source code from some other - already working - part of the program.

This is not re-use. This is copy and paste and is generally frowned on in programming circles.

Having dealt with re-use, he also goes on to talk about the development environment at Microsoft, the implication being that this is the kind of environment programmers build for themselves, resulting in the “Project From Hell” and “how we made this mistake and this mistake … here we are making it again”. The actual problem is that Microsoft fosters an environment that is both macho (pressure to work long hours) and cowboy (build don’t design). That doesn’t mean that all environments run by programmers are like this.

I read an interesting article basically said something I have said for some time: hard drives have a large impact on performance.

Why is hard drive performance so important in normal desktop use (not gaming)? Lets look at a couple of other major factors: RAM and CPU.

While faster RAM (both latency and bus speed) can improve performance, the biggest issue for RAM is ensuring you have enough. If you run out of physical memory it starts using the hard drive as RAM. The hard drive is much slower than your system memory. Ensuring you have enough RAM is relatively easy these days as it is rather cheap.

The reality with the CPU is that most activity is not CPU bound. How often do you see your CPU peg 100% for any extended period of time? The only time for me is when I am running a long script. For almost all normal desktop use the CPU is not a limiting factor.

So why does the hard drive make a difference? Every program you execute must be read from the hard drive into memory. The process of booting your computer is largely one of reading a lot of data from the hard drive into memory. You can expect both of these to get a lot faster with faster hard drives. With faster hard drives you can expect everything to feel more snappy.

The one thing I really hate about my laptop is the 5400 RPM hard drive. My main deskop at work has double the RAM (and faster bus speed) and a pretty fast dual core chip, but the major difference in performance from a user perspective comes from the 10,000 RPM drive.