While a user may understand that such a lovingly written report may be extremely helpful to the developer, the user may also have a bunch of good reasons to not write a report in such detail. I will highlight a number of those reasons below and also try to see how different bug handling styles go with them.

Reason 1: Your software is full of bugs

All developers know their software has bugs or weaknesses. And most reasonable ones (i.e. most people outside PR drone dominated corporations) will admit that. These bugs cover the whole range from kernel panics for system level stuff, to application crashes, to data destruction, to details like odd behaviour during drag and drop situations, to preference loss, to poorly done localisations.

Perfect software will not exist once a certain level of complexity is passed and people seem to have accepted that. If one reported all bugs seen in everyday software use and did so in full detail, one wouldn’t be able to do anything else. For the rest of one’s life. Hence only the most annoying problems will be reported. Each report costs the submitter time. Thus he or she cannot give all the details the developer may want to have.

Reason 2: It is your software

I probably started using your software because I didn’t want to write my own or get involved in some open source project. Instead I wanted a black box that I need to neither understand nor care about. It’s supposed to be magic and just do the right thing. You provide that magic and get the credit for it. Likewise, the problems are yours as well.

Reason 3: The effect of a bug report is unclear

With bug reports it is completely unclear how much effect they will have. In my experience the range goes from detailed bug reports which were not acted on or even acknoweledged after years to quickie bug reports for which I received an updated beta version within hours. Unless you have confidence in the developer who receives the bug report, it seems silly to put a lot of effort into an initial submission.

Reason 4: It is not easy to make bug reports

I will submit a bug report because I ran into a problem. If actually submitting the report is more work than tolerating the bug is, the reporting won’t happen. Bug reporting systems come in a wide range of qualities. Most of them are horrible and totally inconvenient and manage to put up so much red tape that the bad mood your bug put me in has become much worse by the time I managed to report it.

These are a few obvious reasons. And it’s entirely within the power of developers to reduce their impact. Unfortunately very few developers use that opportunity.

Solution 1: Ship less buggy software

Haha, obvious one! While I want to naïvely believe that most developers are not BOFH types who intentionally code bugs into their software, this belief is obviously wrong. Effectively many software registration and all DRM schemes are just huge and intentional bugs which have the ‘collateral damage’ of keeping paying users from using the software (this covers the whole range, just speaking to anybody in charge of a room of machines running Adobe products usually provides examples but even on the small end I have seen self-destructing NewsFire licenses which required an internet connection to be revived).

In addition to those intentionally implemented bugs it also seems like people will consider shipping software with accidental bugs they know of to meet schedules and so on. I guess that this is pretty much standard practice and in part crucial to getting the software out of the door.

More bug fixing, better testing and more realistic schedules will certainly improve the software in that respect. In all cases it might be advisable to simply document the known problems in a way that is obvious to the user. That will save the user the agony of running into the problem. Many buggy areas of software are less problematic if you know how to avoid them. People who want to meet their deadline with a non-trivial Word document won’t change their printer settings at the last minute; people needing reliable FTP connections won’t use the Mac OS X Finder for that, and so on.

Devlopers will have a list of known bugs and problems. Making that list available has two advantages: It will save people the effort of submitting a bug report. And it will show that the developer is admitting there is a problem which can be seen as a commitment to solving it in a reasonable time frame. Both things can leave a good impression with users.

Solution 2: Decommercialise

Go open source. If you want to be able to tell your users to go, read, and fix the source code to remove the problem themselves, that’s totally the way to go.

You probably didn’t want to go that route but rather use software as a way to pay for mortgages and college funds, so now all those bug reports are yours to enjoy as well… If you want to pretend you’re an actual software developer who likes helping people, you’ll have to do a bit better than open source and let your users to be just users with no huge time commitment to improving your software.

Solution 3: Be transparent

Here you can earn the trust of your users by sharing the information you have. Make it easy for users to find known issues in a human readable form (i.e. Bugzilla &c do not count). Make sure the people who report issues will know their report has been received and make sure they can follow up to that in case further details emerge.

Also let bug reporters know about unclarities in their reports or, in case you do not intend to change the reported behaviour, just tell them. It’s always better to know what not to expect than to be disappointed release after release (Just imagine Apple had publicly stated that they intended the Finder to remain a mess when releasing Mac OS  X.1, nobody would have been surprised since and there might even be a good replacement by now).

Solution 4: Make reporting bugs easy

This cannot be reiterated frequently enough: Most bug reporting processes are a royal pain. Instead they should be a pleasure. Frequently seen failures are:

• Systems requiring a login
• Systems not accepting submissions by e-mail (i.e. being web-only and thus requiring me to have a working internet connection when typing the report and making it difficult to attach files)
• Systems not sending you a copy of the report you filed together with the case number (in case there are case numbers) for future reference and easy searching
• Systems not giving you a case number immediately (meaning you can’t send along further attachments right away)
• Web components of the system running on slow servers
• Web forms with ‘required’ fields that prevent submissions from succeeding (I doubt that filling out ‘EXPECTED: no crash … ACTUAL: application crashed’ helps anybody).
• Systems requiring you to refer to attached screenshots by name rather than letting you drag them in the position where they are needed while writing the report.

Many of these problems come from the fact that bug reporting software is apparently a genre which isn’t designed for usablity or convenience. And many developers - people who may actually appreciate receiving nice reports - don’t seem to see this as a problem. If you think people should include some information about their system in bug reports, give them a one-click menu item to create an e-mail with that information. If you need crash reports or screenshots, tell people about it and prepare as much of the information as you can without user intervention.

Expecting users to manually collect all the relevant information which a machine can easily generate for them automatically while also expecting them to send convenient and well formed reports seems wrong to me. Completely wrong. Cognitive dissonance.

Of course many of these issues merit further and more detailed discussion: Which information can be sent? how should the users’ right for privacy be handled (stuff like X.5 hang logs or system profiles seem to contain a load of information which leaves you with a bad feeling; your bug reporter has to make clear who can read the cases mentioned there along with the log messages or other data users upload)? Who will write the ‘Sparkle for bug reports’ framework? And who’ll lobby Apple into making capturing films of the screen (something I consider a huge time saver for bug reports because you can demonstrate the problem) easy - complete with a reflection of mouse movements, clicks and keypresses?

Who’s reading it

Another qeustion is who reads the bug reports. The larger the software company, the lesser their competence at getting the right people to see those reports. Be it because they don’t read them at all or because the reports are first inspected in some way by support staff who don’t necessarily know what they are doing. Occasionally one gets the impression that the people reading a report have no clue. Such formalised systems also have the disadvantage that you may actually have a better understanding of the problem and of troubleshooting techniques than the person processing it. Which is exactly the frustrating telephone hotline situation you alienate people with. This may be non-trivial for a greedy company, but getting qualified staff in those positions will help.

I’ll finish with a few examples of how bugs are handled by Mac developers. Perhaps people can find a good idea or two in there and steal it.

Apple

The corporate monolith in the Mac universe. There are many ways of getting bugs towards them. The operating system itself offers to send crash, hang and kernel panic logs straight to Apple. As that is a no-effort proposision, it is probably a good idea to do that (at least for crashes, those hang log files seems to contain a load of information that goes far beyond the application which is hanging; it’s also unclear to which extent sending in crash logs for non-Apple applications will make any difference - quite certainly the developer who should see it will never even learn about it). The general guess seems to be that those logs - just as the well hidden but in some sense public bug reporter on Apple’s web site are mainly a source of statistical entertainment for the company. Putting any effort into such reports is quite likely a waste of time.

Apple have other bug reporting systems as well - for example with their developer site - and at least the serious reports like kernel panics seem to be looked at there. Less ‘serious’ issues are a mixed bag. Some are ignored for years, a few are fixed, others are classified ‘behaves as specified’ while most end up being duplicates. With those duplicates obviously marking another unattractiveness of closed bug reporting systems as they mean that more than one person wasted their time pointing out the problem.

The Mac universe seems to think that filing duplicate reports of the same bug somehow improves the situation. I consider that to be wrong. Even if filing the same thing many times gave better results, it’d ultimately be a waste of time, both for the users and for the people processing the reports. It’d also hint that Apple’s bug processing is very poorly managed and that any e-mail from them calling you a ‘valued’ customer is a farce.

Karelia

Karelia put quite a bit of effort into their bug reporting system by now. Sandvox comes with its own feedback reporter window which lets you do the things you typically need to do:

• submit anonymous or named feedback,
• receive a copy of your feedback by e-mail,
• not give you dozens of red-tape fields,
• automatically include the version/plugin information of Sandvox in the submission,
• provide a reminder of the preferred format for feedback,
• read a promise that your report is kept private,
• offer to send along console messages, screenshots and settings and
• follow up on previously submitted problems.

To top things off it also doesn’t fail and die when you don’t have a network connection at the moment you use it, but it saves the report and sends it the next time that’s possible. In addition to that Sandvox automatically discovers crash logs when the application launches and offers to send them in.

More trusting users can turn on automatic submissions of such reports - as well as of exception reports which are only sent once in case the same exception appears several times - which, particularly when using betas, can relax the situation significantly as you know the application will file whichever information is needed without any effort of yours. And if you want to track things or submit additional information you’ll find the relevant case number in your console log.

This system still has a few rough edges but it’s certainly a very good step towards making filing problem reports as painless as possible. In addition to this, you can still submit reports to Karelia via e-mail as they seem to be using FogBugz which appears to provide a reasonable e-mail interface (we better don’t start talking about their table infested web pages which quickly reassure you of their Microsoft DNA).

Panic

The beauty of Panic’s problem reporting system is that it’s completely informal and works via e-mail. That’s step 1 and it is very convenient. The second - and I believe equally crucial - step is that their bug reports are processed by intelligent human beings like Les who do a great job at pulling whatever formal strings need to be pulled in the background and keeping the reporter informed. All this is done completely informally without any numbers or other red tape attached which gives it a very good ‘feel’ even though it may not completely satisfy your inner control freak.

Personally I rather like that style of bug processing because I really don’t want to track the problem I submitted. I observe the problem and if it annoys me enough, I’ll submit it. Then my job is done and the recipients have to figure out what I mean, whether they want to fix it and when they are going to do that. Only afterwards I need to learn about the outcome of this as I can’t influence the rest anyway. And if one can trust the developers to be reasonably good at not losing or ignoring cases just because they didn’t give you a tracking number for them, that’s probably even better than giving you a tracking number.

For beta testing Panic also tried out more formal bug tracking system (Redmine). It is web-based, open source and thus - unsurprisingly - inconvenient and sucky.

Lemkesoft

Many people sneer at GraphicConverter because it never quite made it to OS X UI-wise. That’s a justified critique, but at the end of the day GraphicConverter gets the job done and - unlike many younger and hipper applications - still supports technologies like Mac OS 8 and 68K processors. So I am tempted to think that this is more about having a different focus than about a lack of effort.

In fact, Lemkesoft’s bug report and support system is all about making an effort. For many small problems which I reported over the years - using the e-mail link provided in the application -, I frequently received replies, requests for further details or even beta versions for testing the fix within short time spans; Sometimes within hours. All without case numbers or formalities.

I suppose this way of working doesn’t really scale to larger companies, but it’s still the best experience you can get.

But as technology ‘develops’ I have a machine now whose Airport connection routinely fails and, since the X.5.3 update whose Ethernet connection fails as well when there’s a high load on the machine. Fan-friggin-tastic. My inner conspiracy theorist assumes it’s a scheme by Apple to move the whole internet onto iPhones. Haha.

Another point where the Mac ruled pretty much forever was support for multiple screens. No matter what you hooked up, the computer would generally make reasonable sense of it and options to adjust the multi-screen desktop to your liking were never far off. And I have never seen a Mac cause significant problems when trying to hook up an external screen. — Until last week that is. The crappy CRT in the office started flickering. Which meant I got a different crappy CRT as a replacement which looks just the same from the outside. And it worked just fine with the MacBook the first time I used it. When attaching it the second time with Apple’s ridiculously overpriced ‘MacBook to VGA adaptor’ the screen just gave me an OVERRIDE SYNC ERROR message. All capital letter FAIL, that is.

I first hoped, I had just destroyed the crappy screen. But the fact that the crappy X-Terminal in my office could use the screen just fine, hinted that the carefully ‘crafted’ combination of a MacBook and Mac OS X was to blame. Some combinatin of deleting all preference files remotely looking like they are WindowServer or Monitor related, restarting the machine and replugging the screen at the right moment, solved the problem. Temporarily. Attaching it the next time gave an OVERRIDE SYNC ERROR once more. Now that sucks. It’s exactly the reason why I’m not using Linux or Windows. I want this to ‘just work’.

(If you want to trigger extra bugs in OS X, start playing with the ‘Rotate Screen’ options OS X offers for the secondary screen. I ended up with my secondary screen being all blue and completely unusable after having used that while trying to explore this problem. More Suck.

This screenshot comes from the Cyberduck web site and the CSS drawing the little red 'version 3' badge is this:

.version3 {
	background:url(./img/badge.png) no-repeat 100% 50%; 
	padding-right:25px;
}

Which makes this look pretty much like a padding problem once more. And even if WebKit's behaviour were according to the CSS spec, I'd say it needs changing because it'd be an example of the spec being bad or wrong…

I’ve been reporting bugs and requesting features for years. And I’ve done so with many different developers. The bug reporting mechanisms have varied considerably: From freeform e-mails straight to the developer to filling complicated forms. And from that I’ve had many different experiences: From my report apparently being ignored to a pre-release copy of an upcoming version in my mailbox for testing within a few hours.

In what follows I’d like to reverse Brent’s perspective and make a few – mostly obvious – notes on how sending bug reports or feature requests can be a better experience for the user.

The Game

Most people will agree that getting feedback from users to developers is a good thing. Bugs will be found, possibilities for improvement will be pointed out and completely new ideas can be discovered. The downside is that dealing with all those requests can take considerable time and effort which a developer may not be able or willing to take and make.

I will assume you agree with the statement that getting feedback from users is a good thing™ in what follows. If you don’t agree with that point of view, you may as well stop reading here. Starting with that assumption, it will be good for the developer to encourage users to submit their feedback. The communication should be smooth and easy.

Make sending feedback easy

To me that is a key point. At the end of the day sending feedback is an effort. And if it is a big effort with many hoops to jump through for the user, sending feedback may just not be done. If the user has to go to a web site, complete a complicated registration process, find the correct button in the midst of technical lists and then enter a bug report split up in a number of text fields on a web form that will refuse accepting what he entered and lose half of the information on clicking the back button to correct that ‘error’, the user isn’t encouraged.

Compare this with a feedback approach where you find a menu item to send feedback right in an application’s Help menu. This will be perfect for the task in many situations. It can direct you right to a relevant web page for sending feedback or create an e-mail message to the correct address. [In my opinion e-mail is the better option as it doesn’t rely on the user being on-line and allows a more free form and illustrative expression with the easy inclusion of screenshots.] Even better, the application can automatically gather information like its own version number or that of the system it is running on and include them into the feedback report it prepares for the user.

And, best of all, this is rather simple to do for programmers! So there’s hardly any excuse not to do it if you’re serious about gathering feedback from your users. [And I told you to not read on if you aren’t…].

Guide the user

If you want or absolutely need some information from your users, let them know! Usually users have a hard time guessing which information will be essential for the developer to understand the problem. If you want crash reports or a particular form or report – well, the users won’t just guess that either, you better tell them as well. Ideally, your application can gather all the relevant information and then prepare the bug report for the user.

Respect the user’s privacy

Many may shrug at this issue, but I think it’s important: Only request the information from the user which you absolutely need and – if possible – give the user a hint why you need that information if it is beyond the usual. Don’t request excessive information. Like the popular Apple System Profiler report, say.

While the information in the saved profiles many help, it is just too much. With many software developers being in the U.S.A, a country that gives a rat’s ass about foreigners or data protection, I am extremely reluctant to send those reports around.

What’s even more problematic is that the reports are so large that actually checking whether you’re prepared to share their content with others cannot be considered a reasonable effort. Did some application dump one of your passwords into console.log in the past days? Do you really want everybody to know about your network setup? Do you trust Apple enough to be sure they don’t dump any private information in those logs – particularly with the system profiler modules being updated from time to time? Do you participate in some pre-release software tests where sending around version numbers could mean you’re violating some NDA?

Read the feedback

Another point that is obvious but unfortunately needs to be mentioned: Actually look at the feedback you receive. Even if it could be considered malformed and imprecise. Even with whatever little feedback we get for our software, we have received a number of requests that were downright inintelligible. But usually any report which isn’t just an insult has a some valid point to it. So even if it looks like it has been written by an analphabet imbecile, it may well be worth to ask people to elaborate their point because you didn’t get it the first time around.

And guess what? It may suddenly make sense and you can understand the issue that led to those reports once people make a greater effort to write them down.

When reading feedback, try to actually understand it. Again, this sounds obvious, but I have experienced the weirdest things in that respect… the oddest probably being that whoever read the feedback not knowing what a Mac SE is and just assuming I referred to an iMac SE.

While this point sounds so trivial, I assume that it is the hardest for software makers to stick to. Once their enterprises grow beyond the size of a few people all of whom know most things, there may be intermediaries handling the user feedback. It seems essential that those are much more competent and trained than their supposedly minor role suggests.

Keep the user in the loop

While this isn’t an advantage for developers right away, it’s a very good communication strategy to keep the user in the loop as far as their feedback is concerned. While improvements can be made upon that feedback without telling the person who reported it about the progress, getting that acknowledgement of their input makes users who gave feedback feel that their effort was worth it. This, in turn, may make it more likely that users who are happy with the feedback handling by the developer will give further and possibly even better feedback in the future.

Ideally I think developers should acknowledge they received the feedback right away. Frequently some system for handling the feedback is involved in this and each item in there gets a unique number which can be used in future communication. Just to make things easier for later reference, I’d suggest that the acknowledgement should include both the original feedback as given by the user and the relevant reference number. This has the advantage that the user can easily look up what he reported earlier on and have the reference number right with it.

Having those references ready, enables users to add further notes to whatever they first remarked later on. For things like problems which aren’t easy to reproduce for the developer, the user may get a better idea about what is involved in reproducing the problem reliably. Those notes will be helpful. And even more so if the original report can be easily amended.

Give honest feedback on feedback but don’t insult the user

Sounds a bit convoluted, right? Basically it gives users a good feeling to know their feedback has been seen and to have an idea on whether it will cause any changes. And, guess what! Even ‘No’ is an acceptable answer in that game. And giving it is much better than not answering at all. It will let the user know that his suggestion has been thought about and that it has been deemed too complicated to realise or otherwise not fitting in the the scheme of the tool in question. For bonus points, give a hint of why you can’t / don’t want to follow the suggestion.

Or, if the the user wanted a feature for something an application can already do just fine, just let the user know how to achieve this goal and make a mental note that your way of implementing or exhibiting that feature may not be quite as obvious as you thought it is.

Finally, don’t insult the user. Unfortunately that needs saying. But replies on feedback which have the undertone of ‘you’re just too stupid to use the application properly’ don’t cut it. And, yup, the infamous Behaves as specified falls in that category as well.

Conclusion

Most of what I’ve written is completely trivial. Be polite and helpful and your users will love you.

Caveats

Of course not all of the points I describe above hold in all situations. For bigger enterprises the whole area of bug tracking and handling may be very complex and I don’t expect them to deliver the same speed and attention to issues as smaller developers do. That is, I don’t expect their communication skills to match those of their smaller competitors. I don’t think that’s a good thing, but I assume it just can’t be avoided.

Similarly, there may be other situations where the feedback on applications may be handled differently due to the author’s interest or disinterest in it. In all of those cases it may help to be upfront and clear about the status of the tool you’re offering for download. People who eagerly submit feedback or bug reports deserve to know beforehand that their effort will be fruitless because you’ve given up maintaining that tool.

Examples

I’ve left examples out of the preceding sections because I realised that I’d end up using the same ones over and over again. So I’ll just gather the examples here. An example that fails to follow most of the points I made is feedback with Apple computer. Their ‘normal’ feedback process is well hidden and word in the street is that it is mostly of statistical significance to the company – to be pointed to problems that many people are seeing. I’d guess that giving detailed reports there is a waste of time. (And it may be worth thinking a while about how most of the software feedback that people give may end up at large companies and how people may be discouraged from following Brent’s advice by a complete lack of acknowledgement of their feedback in schemes like this one.)

Then there is the Apple Developer Connection bug reporter. You’ll need a (free) developer account with Apple to use it, so it can be considered to be not accessible to most people. It’s probably better than the ‘general’ bug reporter as you can see a list of the problems you have filed previously (and only those) and – in case your report isn’t marked Duplicate right away – it may give you a very rough idea of what people at Apple think about the problem you reported. That said, the bug reporter is mostly a source of frustration.

Yet I am torn whether it is the worst bug reporting process. Because there’s still the wonderful world of open source software which comes with bugzilla or some similar web based software of gazillion form fields and that wonderful open source attitude of user hostility. Those systems may work wonderfully for developers but they are also the places where users first have to make an effort to file a bug at all and then may have some geek come up and tell them how they’re all wrong and stupid. That’s not very encouraging. But apart from people stopping to make snide remarks there’s probably not much that can be done within the open source scene, a scene where even developer friendly acts like writing documented code aren’t particularly common.

To finish on a high note, let me say that I find most small Mac developers to be rather good at dealing with feedback. Often you’ll receive a reply very quickly and chances to see your problem solved usually aren’t too bad. And while I’m at it I feel that particular kudos should go to Thorsten Lemke and Panic who consistently manage to be friendly and helpful in reaction to your feedback. And all that while having products with a non-trivial user base and feature set.

I see both problems I refer to when dealing with the digital version of German weekly Die Zeit. If you subscribe to their paper version, that subscription includes access to a full text and image PDF of the paper. Those are enormous files: slightly less than hundred 40cm×60cm pages each week, usually giving you a PDF file of about a hundred megabytes. It’s quite cool to have this as you can easily archive or copy articles you like this way without having to store huge amounts of paper. Spotlight’s indexing capabilities could be tremendously useful in this context to let you quickly find an article you’re looking for. But Spotlight fails in two ways here.

It’s first failure is that it’s extremely wasteful with your resources. Whenever any metadata of the file are changed, the file’s content which remains the same is re-indexed. Indexing such a 100MB file takes about half a minute on my machine with mdimport using about 100MB of physical memory in the process. While this is an acceptable performance for indexing such a large file, it’s nothing you want the computer to do over and over again whenever you happen to rename or move the file. Spotlight’s indexing needs to be more selective here. Even more so as Spotlight also runs on portable machines where the use of the hard drive and processor uses valuable energy and potentially burns the user’s lap. (#4308769)

The second failure I see is the PDF importer itself. It doesn’t provide all of the file’s text for the index. At least with those long and complex files it’s a problem I see regularly. And a problem that renders Spotlight’s indexing quasi-useless. And while those PDF files are a bit strange in places, I don’t think they are to blame here as Preview will find the desired strings in the file without problems. What’s really odd is that I can’t predict which words will be found and which won’t be. (#4309806)

I think both these bugs are a shame. For such specific searches, Spotlight’s lack of speed isn’t a big problem. It’s really an area where Spotlight could shine, even on today’s hardware. But due to these strange software quirks, dealing with big files is troublesome and doesn’t give the desired results.

Well, I’ll stick to it this week once more. And touch the topic of Mail again. Indeed, I’m pretty sure a whole bug reporter could be filled with Mail bugs. It’s not that the application is all that bad. But there are terribly many glitches. And Apple hardly ever fixed one of them. Instead they kept doing new stuff, from giving us demented unique keyboard equivalents in German, to a new input/rendering setup to scrapping the nice mailbox drawer to completely changing the way messages are stored. And at least in my opinion only the very last of these changes was an improvement.

Anyway – today I have another bug which is related to Mail’s cryptography features. You’ll only be able to see it if you have a certificate installed for one of your e-mail accounts. If you have a certificate for your account, Mail will give you two extra buttons in the message composition window. One for signing your message and the other for encrypting it if you happen to have a public certificate for the messages recipients.

And your choice of whether or not your want to sign and encrypt messages is stored as a preference. While that’s a good idea, it’s not good enough. Signing a message technically means that an attachment with the signature will be added to the message. While applications that can deal with signed messages will interpret this as intended all other e-mail clients or web mail services will just display it as an attachment. An attachment with a strange file name, an attachment that makes the more ‘careful’ Windows users think you might be sending viruses and so on.

So at the end of the day, rather than having to answer ‘dumb’ questions of those who don’t know better, you’d rather not send them signed messages to begin with to avoid confusion. And that’s where having the global preferences isn’t good enough. As things are you have to keep an eye on the signature button for each message you write as it will always have the status you set for the previous message you wrote. And when you’re sending a many messages to many different people, things tend to go wrong occasionally, so you might be inclined to just stop using the signing feature at all to avoid those troubles. Which in turn means that having global preferences potentially spoils the whole feature. And from discussions with other users I have learned that I’m not alone with thinking that this shortcoming of Mail

But as I just outlined, whether you want to add the signature or not isn’t a global choice but depends on the recipient. So it’d make a lot of sense to save the preference for whether you want to sign a message or not on a per-e-mail address or per contact basis rather than globally. (#4300959)

Reporting problems with localisations always feels strange as the whole developer community seems to be run in English by Apple. So it’s not really clear whether these issues will even be perceived as being important by whoever gets to process them. That’s particularly true after the recent experiences others had even on more technical problems. And while OS X is sold as being localised for fifteen languages, support for English usually is better than for other languages. That’s particularly true for areas such as the Dashboard which downright ignore localisation and contain parts like the weather widget which have been done by people who didn’t even want to think about localisation.

But the problem I want to report this week is a much less specialised one. It’s been bugging for years now. But as localisation problems go, you often don’t report them as, well, they mostly cause nothing but a raised eyebrow or a shrug but don’t really keep you from doing whatever you want to do. And it’s the localisation, to German, of the system’s standard dialogue for entering an administrator password to allow certain actions. In English it looks like this:

While it may be considered slightly too rude, it’s a very clear dialogue telling you what you need to do and who’s asking you to do it. But now compare that to the German version of the same dialogue:

The text in there translates back to English: Enter your password to make changes to “System Preferences”. Now that doesn’t make sense. Why would I change System Preferences themselves? Why do I have to enter my password to change the Finder when all I want to do is move a file? It’s completely mysterious to me and confuses me every time I see that dialogue. So there we go… another bug report (#4289717) on an issue that looks small. But I think it’s big. Because it’s exactly those dialogues that don’t make sense which the Mac OS managed to widely avoid in the past. And I think it are dialogues like this which make Windows so horrible. Because they train the user to just assume that the computer speaks gibberish which doesn’t make sense. And thus the user just clicks OK everywhere without even reading the messages. Of course the Mac isn’t free of similar messages (see Safari’s new download warnings which pretend to be for your safety to see a similar problem on the Mac).

The first one isn’t really a bug but a way to score another ‘Behaves Correctly’ classification on the bug reporter. Following Mike’s idea, there’s even a shirt for it. It is simply the fact that the iPod doesn’t carry a full set of Unicode characters. There are probably good reasons for that decision as fully fledged Unicode support on a tiny machine as an iPod may be more than we can expect. Yet, the iPod’s Unicode support is a mixed bag. If Japanese, Chinese, Korean or European languages are good enough for you, you won’t have problems anyway. But other alphabets, such as Thai, Tamil or Hebrew are missing.

In fact the lack of characters has a tiny advantage for the user who doesn’t use those alphabets. As iTunes and the iPod sort all playlists strictly alphabetically, you can –and have to – use ‘exotic’ Unicode characters to prefix the names of playlists which are supposed to be at the end of the list. Personally I like prefixing the names of the very last playlists with ℵ because from a geeky maths perspective it seems appropriate for their position. With the ℵ not appearing on the iPod this has the advantage of no space being wasted by this on the iPod’s little display while the order is maintained. But that advantage will obviously be lost for people who actually use Hebrew on their computer.

I doubt that much can be done about the situation of the missing characters. But in other places, things can be done. For example, in the iPod’s Contacts feature. That feature has always been quite buggy as it is. I assume that anybody who actually tried to use it with non-trivial contact data will have experienced that the iPod refuses to display addresses which are marked with a custom label in Address Book (problem 4279111). They seem to be synced into the relevant file by iSync but the iPod just ignores them. And there are few things which suck more than having written a postcard in your holidays and not being able to send it because you iPod chose to display all the data you copied onto it.

Another flaw of the iPod’s Contacts feature is what I like to call dumb sorting (problem 4279104). Which is probably sorting by Unicode code point or something. It will sort accented characters after the ‘z’ and as anybody who ever dealt with accented characters or phone books knows, that’s just silly and makes names hard to find. And it’s even worse on a device that can only display five or six names at the same time as that greatly reduces the chance of ‘accidentally’ seeing the name you’re looking for once you have dozens or even hundreds of contacts in the Contacts list.

To see how this can be done properly, you need to look no further than Mac OS X’s Address Book. (Mostly properly at least. as I couldn’t find a way to make surnamed like ‘van Rensburg’ or ‘de la Fontaine’ be sorted as if they started with R and F respectively – Address Book only seems to know about name prefixes and suffixes but not about the ‘von Part’ that programs around BibTeX seem to be aware of.) While it remains a painfully slow piece of software, the sorting is done correctly. Even better, a possibly underused but brilliant feature of the Address Book is that you can add ‘pronunciation forms’ for the names of your friends. That means you can keep their proper, say Asian, names in the address book but add a note on how it transcribes to your own alphabet. And the Address Book will use the pronunciation form for sorting purposes. And with that infrastructure at hand, it should be easy to devise a partial workaround for the lack of a full Unicode range of characters on the iPod: Whenever a name consists of characters from a range that isn’t available on the iPod, the pronunciation form could be used if it exists and doesn’t consist of characters that the iPod can’t display as well. That wouldn’t be perfect but it could remove a number of those Contacts on the iPod which are just blank lines (~ problem 4276122).

A final suggestion for the iPod’s contacts section would be for it to include people’s birth dates. Those are easily available from the Address Book and information that you occasionally wonder about (enhancement suggestion 4279220). And unlike phone numbers, those are informations which many other devices capable of storing contact information seem to omit as well.

The problem itself is a problem of Mail. It could be thought of a problem of localisation, but it can also be thought of as a problem of bad design. Probably anyone who is using Mail and the ‘threading’ feature that was introduced in X.3 will have seen related effects: Namely, that the ‘threading’ feature sucks. On the one hand it seems to match subject lines and/or authors, thus potentially grouping together messages which don’t belong together. On the other hand it doesn’t even make an effort to group things together which are clearly in the same thread of conversation by the IDs of their In-Reply-To headers.

In many cases you won’t see these problems as subject lines tend to stay the same but in non-English situations and the not-quite-uncommon situation that you communicate with people who have to use Outlook for their e-mail, you’ll get in trouble. The German version of Outlook, for example, likes to change a subject ‘X’ of a message to ‘AW: X’ when you’re replying to it. Just like any other mail program would change it to ‘Re: X’. And the short story here is that this causes Mail to not recognise that these messages are related because of the unusual string.

The long story is more complex. I could tell that the Mail team actually seems to be clueful enough to have localisable versions of these strings but consciously decided to not replace the ‘Re’ by anything localised exactly to avoid such problems. Nice one… but it still fails in the situation where this problem is caused by another common product. Together this brings me a situation where Mail utterly fails to do what it claims to do but where it’s difficult to be upset as the Mail team has shown (to those who are looking) partial cluefulness and the main blame, i.e. using ‘AW’ in the first place, is with Microsoft anyway. On the other hand: If Mail did a proper analysis of the message headers which follows references for more than a single step, the junk in the subject line wouldn’t matter anyway.

So what kind of bug / problem / feature is this? How should it be filed? There are so many facts, known and unknown, in this that I have no idea.

On the other hand, there are bugs which aren’t really technical bugs and often fail to have a proper classification in bug-tracking mechanisms. They might be referred to as ‘UI-quirks’ or in other diminutive ways which may give programmers an excuse to look over them. But those problems can be problems which you run into every day and for which you know no escape route to avoid them. And the problem I want to present this week is one of these.

Safari has a nice auto-fill feature which tries to fill the forms it finds on web pages automatically with values from previous visits. Particularly the user names and passwords from login-forms will be saved and automatically entered. With all the different accounts you need to have these days, this feature is vital for me. I wouldn’t need it if every site in the internet let me have the username ‘ssp’ and if each of them at least had the same requirements for the length and allowed/required characters in a password. But that isn’t the case. So I just leave it to the auto-fill feature. Indeed, I don’t even bother to change the password to something I can remember for accounts I use rarely but just stick with the one they give me when I sign up. The auto-fill feature takes care of it for me. In short: the auto-fill feature working smoothly is important for me as I use it frequently.

But there’s a little problem with it. The automatic filling of the user name and password fields only takes place after a page has been completely loaded. And by ‘completely loaded’ I mean that all of the page’s elements such as images have been loaded – not just the HTML. And, you know, sometimes web sites are quirky. One of those little images gets stuck somewhere on the way; an ad-server is slow; you’re on a slow internet connection; the site is on an encrypted connection – which often means it is generally slow, particularly when all of those little spacer-gifs are also served using the encrypted connection. Any of these reasons can cause the time until the page is completely loaded to be rather long, much longer than the time it takes to download the HTML and much longer than it takes Safari / WebKit to display a preliminary version of the page. So you end up seeing those empty login fields and expect them to be automatically filled with your user name and password but nothing happens … nothing happens … nothing happens … ahhh, there it is.

Those are just seconds but seconds spent unnecessarily waiting for a computer can be very long seconds. And, yes, there is a workaround: you can just invoke auto-filling manually, but why should that be necessary? So here we go, my bug of the week, number 4258676 [Hmmm, I keep thinking that it’s rude to add a link to those numbers as the inconvenience/confusion to people who don’t happen to work at Apple might be bigger than the use of them to the 0.02 people who might benefit from them] is about Safari triggering the auto-fill feature only after a page has been completely loaded rather than at an earlier stage.

And it’s not classified as a ‘proper’ bug of some sort but with the mysterious ‘Enhancement’ tag. So possibly it went straight to the round filing cabinet. Of course it’s not the only bad thing about Safari. Even after years it’s handling of pages with frames remains poor as far as scrolling and back/forward navigation are concerned. And I keep thinking that you should be able to drag and ‘poof’ bookmarks out of opened bookmark bar menus as I keep thinking that it’s too slow / complicated to go to the bookmarks section and locate them just to delete a bookmark that stopped working. I might file those at some other time… or not.