… this message of course coming from a Windows running in a completely cable-less virtual machine. Thus suggesting that not only the software is overly talkative but it also uses dumbed-down simplifications to annoy me with. The art is to write human understandable technical messages that are actually correct.

Sometimes Windows is even more talkative and gives a few more details about what problem it ist concerned with, it may be concerned with or it might be concerned with. If even the expert-created software can’t tell for sure where or not I can access the capital-I internet, what’s the chance that the button-less more information can help me?

Seriously: does anybody at Microsoft even read the messages their own software spits out? Is any of the presumable information in there intelligible to people who don’t share brainwaves with Microsoft HQ?

Uh, and when you’re lucky, Windows will automatically update and restart itself. Let’s just say I find that extremely irritating when an application that’s running in the background changes without any command of mine. And I assume that’s even more true when Windows is all that your computer runs rather than just a window in a virtual machine…

I sense a lack of ‘undo’ button there.

Now the great thing is of course that I am pretty sure there’s a nifty setting or workaround for each of these ‘problems’. Quite likely people will be able to point out that it’s my own fault I’m seeing these messages.

More Windows bubble snobbery.

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.

As I am helping Karelia out with their CSS, I had the ‘opportunity’ to test pretty much every single version of Sandvox since the betas. [So, yeah, take care kids, don’t trust a single word of what I’m saying, I am totally biased on the topic - although people at Karelia HQ usually don’t consider my feedback on their product to be too lenient.]

Being the horrible person that I am I thought I should occasionally use Sandvox myself to get a better idea about it - all that while its general approach to web site making is rather useless to me. After all I already have home-made websites for everything I want. I found a sweet spot with photo albums which are always a hassle to make manually and which Sandvox automatically provides navigation for - along with a wide choice of colourful designs. Fun.

That used to be rather frustrating and in the beginning took me straight to the hell of all bad things that can happen in software. From stalling for ages (after adding a few dozen images in one go) to obscene memory consumption (before version 1.2, my biggest site managed to run Sandvox into the address space exhausted FAIL situation with around 3,4GB ‘virtual’ and well over 1GB of ‘real’ memory - a situation from which OS X’s feeble memory management doesn’t recover reasonably when you have ‘just’ 2GB of RAM) to slow uploads (in part due to the slowness of handling many files via FTP and SFTP and the failure to upload small and large files at the same time get the time consuming stuff done while also using bandwidth) to crashes.

Probably people with small sites didn’t see any of that. But without even trying hard, I quickly found myself pushing all those boundaries. Over time, particularly with the 1.2 release, many of these situations were improved. But from what I can tell achieving that wasn’t an easy task. I started wondering whether Sandvox’ design was perhaps too optimistic about using relatively new (i.e. hardly documented and buggy) Apple frameworks.

Sandvox uses Core Data to store information, Web Kit for editing and even Quartz Composer in some designs. That is we have not just one but a whole bunch of (then) brand-new Apple frameworks in a single application. And they’re not just there but they’re doing the heavy lifting, quite likely interacting in some complex way, and use the more advanced features of those technologies. (How many other applications use Core Data in a non-trivial way? How many other applications use Web Kit editing? In a way that is more complex than what Mail does? How many applications actually use Quartz Composer?) Throw in a bit of multithreading and the mystery becomes even bigger. I really wonder whether any of the Karelians had a full understanding of Sandvox’ inner state at the time (or now?) with all the magic underdocumented Apple frameworks doing their work in there.

One could say, that this was a risky project to begin with. And for the 1.5 release Karelia knew they had to improve the back-end magic - as their other users probably started hitting the walls I ran in earlier as well (sad fact: no-one will ever improve software just to keep me happy). And, to my surprise, the current version looks like the many months of work and the introduction of a new file format paid off.

To a large extent this will be due to invisible improvements of the internal architecture but in a few places even seemingly trivial GUI improvements make a big difference. Using Sandvox mainly for photos and frequently dragging a few dozen photos to the application used to give you ages of the spinning beachball of death. Of course Sandvox has to do a lot of work in that situation, create new pages and load the large image files to create thumbnails and appropriately scaled image files for the site. My impression is that this was sped up for the new version, but more significantly we got this:

A little sheet indicating the progress of page creation. That’s extremely good for my nerves. As all of a sudden I don’t get a spinning cursor but a clear indication that things are progressing along with an intuition about how long this will take. That relaxes me a lot.

Another excellent improvement is the new ability to batch edit properties of pages in the Inspector by selecting a bunch of pages at the same time. Again, this may seem like a trivial detail but it makes the experience a lot smoother. Instead of cursing the programmers for leaving out this convenience when having to click through a dozen (or even just three) pages one-by-one for changing one of their properties, now you can cheer, do a single click and waste the time you just saved on YouTube (something that happens to be easy as Sandvox ships with a YouTube page type now - ah the modern times).

Another structural improvement is that Sandvox 1.5 lets you have links to the previous and next page in a weblog collection. Previously these links would only be arrows and only exist on photo pages. Now they also work on text pages and appear as text in weblog collections. I imagine this should be great for many uses. In fact one of my own non-image sites greatly benefits from that (using some additional tweaks of my own).

As I like fiddling with pages and modifying designs a bit further, I end up using Sandvox (Pro)’s Code Injection feature quite a bit. The 1.5 release not only made Code Injection more powerful, it also added sweet little syringe icons to the source list letting you easily see which pages enjoy code injection. It’d be quite useful if those icons became clickable at some stage, though, to open the code injection window right away.

Design-wise, the new version includes a few new designs, giving an insane choice of 50 different styles before looking at third party offerings. Many of the designs have been upgraded to support user customisable banner images. If I’m not mistaken those are very popular (possibly even more popular than the rather questionable option to let users change their text font to Comic Sans) because they make pages more unique and personal. That option certainly increases the perceived variety of designs as well.

A technical and mostly invisible change to the designs which I am particularly happy about is that most of them now use inline - rather than floated - menu items. Not only does that remove a bunch of horrible line break problems people were seeing in the Internet Explorers, it also gives one the fuzzy feeling that things will work reasonably in RTL writing systems now. I guess pages over pages could be filled on the way Internet Explorer handles floats and how not using floats isn’t as good as it should be because inline-block isn’t supported as well as it should be - cough, Firefox, cough.

If you are looking for an easy-to-use web site creation application and previously dismissed Sandvox because you ran into some problems, this may be the point to give it another try.

Google’s hype for their new idea is ‘communicated’ by a comic book. It reads like marketing drivel and I find it hard to see why people think it’s great. Apparently there’s some big name comic drawer involved, but who’d give a fuck in promo material?

The interesting question is, however, where this will lead us. In a way it’s freaky. Google already own pretty much all parts of the web that are not on your computer and now they want to come over and own the rest. Seeing that so far Google managed to create services that are far better than their competitors’ - thanks to both their ad billions and keeping their staff in a good mood, I guess - there’s a chance that this could actually work. On the other hand we have seen Google’s other offerings for local applications like their Google Desktop software which mostly suck. This is definitely uncharted territory for them. No risk, no fun, I guess.

With their cartoon thingy making a big deal about each browser tab being a process of its own (who’d care about such gritty details?) - and it apparently even bringing along something as idiotic as a process manager of its own - this sounds as if the whole thing may end up being an ‘interesting’ UI challenge as well. Is it possible to get a whole bunch of processes to present a smooth single application GUI to a user? Intuitively I would have doubted that. But I guess we’ll get an opportunity to check out the magic skills of Google’s coding wizards on this issue at some stage.

There is no doubt Google have done a lot for developing interactivity on the web. They had the balls to do big scale JavaScript stuff (Maps, Spreadsheets, …) with all the power, non-linkability and non webbish UI coming with that. And having those certainly gave an incentive for browser makers to improve their DOM scripting support and performance.

In my usual browsing experience the most common problems at this time are ads and embedded Flash thingies. And I am tempted to think that being able to rid web pages of those easily would considerably improve my experience of the web. Unfortunately Google don’t seem to be interested in those obvious and low-profile improvements.

Instead they make a big deal about ‘open source’ (whatever the advantage of that may be - let’s hope their assumed improvements to WebKit actually make it back into Safari), and about their fairly good knowledge of the web and popular sites to streamline testing (can other browser developer use those data as well?)

It will be interesting to watch this, but personally I am sceptical about putting the tabs outside the window. I am sceptical about browser windows opening with a lot of distractions in them when they are empty and I fear that its advantages in efficiency may be minimal on systems with their menu bar at the top of the screen. I like clever completion of things I type as well as instant searches. I am also amused by Porn Mode making it to to other browsers.

Also: official PR post • Lukas Mathis stating that this solves the wrong problem • No font embedding in there yet as well as lesser shadows and rounded corners. The maker of that last picture also notes that the user agent string of Google’s browser is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 which makes you wonder whether by 2020 user agent strings will consist of the entire version history of a browser along with a copy of your DNA… • John Siracusa admires the boldness - the benefits of which I still fail to see.

You are invited to add your pet loves and hates at the end.

XCode

XCode has become faster and more powerful in its third incarnation. The slowness of Cocoa’s text engine is pretty much forgotten and XCode can now open and syntax-colour large source files quickly enough that an onlooking Linux person doesn’t have enough time to recite the benefits of emacs along with a full list of key bindings. That is an extremely welcome improvement.

Just like code folding is. Having it invalidates excuses for not having lengthy comments, say, and it can simplify understanding structures and problems on a global level. Unfortunately XCode 3 seems to have shipped so immaturely that code folding is wildly incomplete and buggy. A rather obvious problem is that red or black markers in the editor’s scroll bar, which indicate compilation problems, appear in the wrong position when lines have been folded above the error. Another is that the foldings aren’t reliably persistent which they certainly should be if they are to be useful.

A neat new feature of XCode’s editor is its ability to ‘refactor’. In a way I am a bit disappointed by this because I used to think that ‘refactoring’ is a big computer sciency thing where you re-think your application and re-design its data structures for a new version to make things better, more efficient and fantastically future-proof. In XCode’s terminology (and quite possibly in reality - my respect for all programmers who spent a hard night ‘refactoring’ just dropped!) refactoring means that you re-name some variables. Probably all for the sake of consistency, beauty and future-proofing as well - but somewhat less spectacular than what I had in mind.

That said, it is a wonderful feature. You click a variable in your code, it will become underlined and an arrow button appears to its right (most of the times, anyway). That button will contain a menu which activates ‘refactoring’ and after selecting it, any change you make to the variable’s name will be copied to all other occurrences of that variable name as well. In effect this means that you are much more likely to end up with good variable names simply because replacing the bad ones you initially put there is easy.

Just be warned that XCode’s interpretation of the Edit all in scope command is a bit - ahem - idiosyncratic: When I define a variable inside an if branch, I (and my debugger) consider the scope of that variable to be that branch only, XCode’s refactoring, however, will happily rename all other variables with the same name inside your method but outside that branch as well. I rate this somewhere between ‘not helpful’ and ‘dangerous’.

The new XCode version also cleaned up a few other things to make your work more streamlined. Compilation errors will now show up amidst your code, the Run and Debug modes work more similarly and the debug mode has generally been improved. Most notably you just need to hover over variables in your code while debugging to see their value and inspect them. Thousands of clicks and sighs will be saved this way.

XCode’s breakpoints gained a GUI for things like playing a sound or logging some string or backtrace as well as the ability to have Global, that is cross-project, breakpoints. That’s great for those of us who program occasionally and forget whatever little they know about the gritty gdb commands in between. That said, the GUI implemented here is far from perfect once again:

After just a few uses I noticed that: (a) you cannot use the scroll wheel in the breakpoint list when there are expanded items with text fields in them, (b) switching between the different actions like Log, [Play] Sound &c deletes the settings you made in your previous choice; that’s very inconvenient and bad for experimentation, (c) no Undo (but at least Copy and Paste work, so it’s still better than an iPhone…), (d) no Duplicate command, (e) after expanding a breakpoint by clicking the triangle at the left of the breakpoint you always have to click the ⊕ button at its far right side; that’s annoying; relocating the buttons or simply letting a double click in the area have the same effect would be handy.

XCode’s help now seemingly gained the ability to automatically subscribe to documentation updates, download and install them (in what seems to be universally considered the most resource hogging background process Apple gave us so far) and thus save you the hassle of that login, download and install process.

Another addition -  which may well end up being a star of XCode -  is the Research Assistant, an inspector window that displays information and documentation about the method, variable type or function your cursor is currently on. It’s a wonderful idea which could be tremendously useful if it were well implemented. But it’s still quite far from that.

Even in my shallow experience the Research Assistant is one of the main factors making XCode 3 terribly sluggish - waiting a full second before seeing what you typed appear on screen sluggish, that is. This needs major improvement. Allegedly there are cutting edge technologies like multi-tasking or multi-threading which let applications look up one thing without stalling your typing while doing that. Let’s hope Apple catch up with those technologies at some stage. The Research Assistant also isn’t terribly good at displaying information for many things it should know about. Specifically it doesn’t display information when you click into a child part of a struct or Objective-C 2 property statement or when you click into one of the methods of your own classes. - Nice idea, but not really there yet.

XCode’s autocompletion improved as well. But it remains ridiculously bad. I don’t think I ever used an autocompletion feature which so consistently managed to suggest the most useless autocompletion when several possible completions are available. Making this perfect should be hard but a bit of work might lead to considerable improvements already: XCode has a lot of information at hand, it knows about Apple’s data types and the functions/methods belonging to them, it knows about your classes and it knows the code you use close to where you are typing. Humans and even dull logic will probably manage to complete [bezierPath moveToPoint: NSMak in a useful way - a task which is already too hard for XCode’s autocompletion. And this is just a random example I had on screen at the moment. There are many many others you will come across.

I am lazy, so I really want to use autocompletion, but with XCode’s - as it is today - I frequently think that it would have been quicker to type things myself than to wait for the autocompletion suggestion to appear or to fight XCode to provide me the correct autocompletion. This is even harder and frustrating because even after using it for a while I am unable to predict what hitting the tab key will do. You cannot develop ‘muscle memory’ for the autocompletion for (at least) two reasons: The first is that you cannot simply type a few letters and hit tab. You have to wait for a moment before hitting tab until XCode has caught up with you. That costs time and ‘flow’. And then, XCode seems to try to be ‘clever’ about the default completion it suggests. Which could be a good thing. But somehow I found that in most cases it’s just not clever enough and hands me the wrong completion.

Objective C 2

Objective-C - the best programming language since Basic or Pascal - got a version bump as well. And it surely resolves the single thing Objective-C lacked in comparison with RealBasic: Garbage collection. While, personally, I think that Objective-C’s retain-release concept really isn’t so bad once you got the idea, leaving out all those explicit retain, release or autorelease calls will certainly make programming more fun and less of a hassle.

I’m sure there will also be situations where having proper garbage collection will solve real memory management problems. Just as there will be situations where it will hurt performance. In fact, I am fairly sure that I already observed such a situation in a fun little project where I ended up using 60MB of extra RAM while displaying an animation. Probably just being able to release the images in question as soon as you don’t need them anymore rather than waiting for the garbage collector to feel like doing the job could avoid this generous waste of precious RAM.

Properties look great as well because - as big as my love for brackets may be - it’s quicker to type than accessor or Key-Value-Coding methods. I’m lazy in that way. XCode’s autocompletion still mostly sucks when you are using properties and I am not sure whether I fully grasped the concept and its consequences yet. (What’s the cost of using a property? Does it really make sense to access a class’ instance variable via self.myInteger? I keep thinking that it may be the ‘cleaner’ version of doing things but that in many cases it’s probably just an absurd waste of CPU cycles - i.e. global warming. So what’s the responsible thing to do?) My lazy self is also a bit disappointed that setting up a property requires three lines of code in three different locations. I was thinking more about a single magic statement in a single place. As XCode’s ‘refactoring’ also fails to make renaming properties easy by offering to change both the source and header file and listing all other places where the property is used by files (code and nibs) in the project, this isn’t entirely convenient.

Objective-C 2’s new looping techniques are very welcome as well. I doubt that anybody will miss having to type NSEnumerator all over the place. I certainly won’t.

Interface Builder

One of the more problematic parts of X.5’s developer tools is the completely reworked Interface Builder. While re-engineering and re-writing the ancient Interface Builder application to better match today’s Cocoa environment with things like Bindings and the iPhone runtime environment around is most likely a good idea, the application itself seems terribly under-engineered and prematurely released to me.

Somehow the new Interface Builder seems to require a lot more screen real estate than its predecessors with its huge, overly animated and split viewed Library palette being the most obvious problem. Just try creating a medium sized window on a MacBook screen. It will end up being frustrating because you’ll either have the Library palette covering your window or you’ll have to fight the battle between the Library and Inspector palettes about who is on top. That’s not very convincing.

Interface Builder’s - just like XCode’s - New File window is a matter of bad design as well. Rather than carefully using the space in that huge window to make all relevant items that can be created clearly visible, you’ll easily find yourself in a situation where you see scrolling views and many subitems which makes things look much more complicated than they really are.

Other things that regularly drive my nuts in the new Interface Builder are that it seems even worse at dealing with localisations than its predecessors (easy switching between different language versions of the same UI element would seem like an obvious thing to do), that it makes it ridiculously non-obvious how to instantiate one of your own classes in a nib file and that its bindings editor still sucks full time (no good preservation of what you enter, no help autocompleting key paths and no friggin’ way to make the Inspector window wide enough to even see your full key path, FAIL, FAIL, FAIL) which makes other points like the new icons for nib and xib files that simply don’t stand out in your XCode file list and thus needlessly hard to find seem minor in comparison.

Uh, and Interface Builder’s pseudo HUD, small, overly auto-scrolling action method selection window is probably something for which you want a copy of the HIG engraved in some hard material just so you can slap the people who implemented this with it.

Documentation

Apple have a proud history of shipping all that nice Cocoa stuff and giving us sub-standard documentation and examples along with it. My impression is that this situation has improved a little but hasn’t changed fundamentally yet.

The problem with this is that it can waste a lot of time or create sufficient frustration to simply discourage people - particularly those of us who’re only in this for the fun - from trying things. In many places of Cocoa the behaviour of the framework is un(der)-defined by the documentation. Be it because Apple are too stingy to have more exhausting documentation written as they don’t care about their developers or because they don’t know themselves. Giving Apple the benefit of the doubt one could hope that the people working there and making the frameworks actually know those details and can explain them. Then please make them share that knowledge, it will save time over and over again around the world!

Then there are small things in XCode’s documentation browser which could be smoother. Say, when I’m entering NSMenuItem into the search field I keep getting the legacy NSMenuItem protocol as the first result. I am even warned about this being a deprecated way of doing things and (after scrolling) I’ll get a link to the new class, but wouldn’t things be, um, useful if the Help gave me the thing I’m looking for right away?

Another aspect of documentation - which is quite ‘in character’ for Apple, though - is that it’s not very candid about what doesn’t work. This kind of information can be tremendously helpful as it keeps people from wasting time trying things that are hopeless. What about a comprehensive guide to all Cocoa controls indicating which of them can realistically be used with Bindings, say?

The final point are examples. Many people, including myself, find examples a very valuable form of documentation as they don’t just theorise about the frameworks but show you how things are done. With a bit of luck you can even nick some code from them. In some areas (Quartz Composer, Audio?) the examples seem to be quite comprehensive and give you a good starting point for not just using those technologies in a simple way but really digging into them. In other areas, however (CoreData and Bindings come to mind), the examples are far from covering the whole problem space. I think that having more of them could make learning the underlying technologies much easier (particularly for ‘magic’ technologies like CoreData which you are not going to understand fully).

Code Signing

MacOS X.5 is full of technology for code signing. It has good and bad sides. Let me discuss what it does first.

The essential idea for code signing is to authenticate an application. A developer can create a certificate and sign his application. While - just as with encryption certificates - it takes quite a bit of extra effort to make sure such a signature really authenticates the developer, this at least gives you a way to determine whether two different versions of an application originated from the same developer (modulo the developer’s incompetence at handling his certificate, that is).

Mac OS X.5 already uses this in a number of ways. The best one of them is the keychain. If an application has been signed by the developer and you allow that application to access your keychain, the keychain will now remember not just the application and its version but the developer’s certificate. If you download an update for the application, the keychain will recognise that it has been signed by the same developer and the application will be granted access to the keys without further ado. This means there is one less annoying dialogue asking the user for permission to access the keychain. Which makes it more likely that users will take those requests seriously when they do appear. It’s a good thing.

Other areas where Mac OS X.5 uses code signing is for its firewall and its nanny mode. In the latter, code signing is used more destructively: Rather than letting people execute any code, only certain ‘trusted’ applications which are pinned down by the signatures of their developers (or the signatures OS X.5 adds if there is none) are allowed to accept network connections or to be used by the kids.

Obviously things easily become a bit creepy once we venture in this direction. For example because of the automated code signing by the OS, applications can be modified without you really knowing about it. And obviously once you have these technologies in place for the good intentions they are also easily available for bad ones.

I suppose the iPhone is a prominent example for this. Essentially it’s Apple’s decision whose code can run on the iPhone. That toy is not a computer at all but a highly controlled environment. Apple dictates its rules and it will be interesting to see when the first applications are found to be against Apple’s arbitrary terms and conditions and will be banned from iPhones. Would instant messaging be fine? Would route planning be OK for third party software on the iPhone or did Apple make an ‘exclusive’ contract with some software company for that already? Is porn in or out? And if it’s out, who gets to decide what porn is? Is VoIP OK? Or an application displaying The Guardian? Or one displaying Fox News for that matter? Do we really want someone else deciding which software may run and which doesn’t?

Well, the iPhone and Mac OS X.5 have the technology to censor away. Currently it’s a mere possibility but what will happen in X.6, .7, .8? We don’t know. The code signing doesn’t seem to be fully documented yet (another aspect which makes this a bit creepy) so the full power isn’t entirely clear at the moment. But it appears that using the codesign utility you can sign pretty much everything from a Unix command line tool to a OS X bundle. And the detailed settings appear to give finely levelled control about which parts of a bundle are covered by the signature. When will applications start trying to refuse running when their signature isn’t matched? When will frameworks which Apple ship but don’t want other applications to use simply fail to initialise when the application using them hasn’t been signed by Apple?

We’ll have to see how this plays out. If I am not mistaken they have done a similar thing on Windows for ages with drivers. Whenever a hardware company doesn’t cough up the money for Microsoft’s certification and a driver is installed some dialogue box comes up asking people whether they really want to continue installing an unsigned driver. I haven’t watched many Windows users but none of those I saw seemed to even register that warning, they just dismissed it because that’s the natural thing to do. Which to me means that if signing technology is to have any practical effect it has to be drastic. Things need to not work when they are not signed. And that’s a bit of a scary prospect as it makes a completely walled in computing experience - one that one wouldn’t consider a computing experience at all in some classical sense - seem quite realistic.

Interesting question: Does XCode support convenient code signing yet? There is a field for entering the key to use for singing in the build target inspectors. But entering something there never did much for me. When compiling the project with the xcodebuild command, however, it looked like a signature was created.

The musical notes remained but everything else seems to have gone off track. Not even because the features that were added (playback of last.fm streams, keeping a local history, loving/banning tracks - all stuff which should be part of iTunes, but which Apple is too blasé to put in there because their music player application needs to support phones or something), but because the priorities in doing so seem backwards.

In my opinion such a utility should be small and lean. iScrobbler isn’t. Quite frequently I found it using 200MB of ‘real’ RAM and 100% of CPU time for - hm, I don’t really know what for. But I can speculate. Part of the problem seems to be the local database iScrobbler keeps of the tracks you played. From what I can tell it must have kept several copies of that in RAM and worked intensively on it for some reason. At least removing the associated files - which were slightly over 10MB - from the system reduced the RAM consumption to ‘just’ 20MB of ‘real’ memory. The next step was of course to turn the local history keeping off, to make sure the problem won’t return. A shame.

And then there’s the 64bit problem. My computer may have a 64bit processor but the fact is that I don’t need that feature. As far as I can tell, of the processes I use, at most 3 are 64bit. One is httpd, the other is Chess - and I don’t actually use that - and the third is iScrobbler. Which effectively means that for what should be a harmless utility application the system probably has to load a whole new copies of its libraries just so the application can run in 64 bit mode. Because we are still firmly in the 32 bit age on the Mac these days, no matter what other people suggest.

A quick run of lipo (argh, I want a -strip-crap option for that which automatically overwrites the original rather than having to know the obnoxious ‘names’ the different architecture types have) later, the 64bit problem was solved. And amusingly the application is now down to using only 10MB of memory which sounds like a reasonable amount to me.

The question here is of course why all this crap happens in the out of the box situation…

The issue Dan focuses on is that the current Interface Builder model of doing localisations puts a very high price on GUI changes. Changing things like positioning may require you to go through each localisation of the NIB files and adjust the positioning there. The same for establishing new Connections or Actions. And - with InterfaceBuilder’s rather sucky editor for editing Bindings, I’d say changing the key path for the bindings of something like an NSSlider in eight languages should be enough to drive you nuts in terms of the clicks that need to be done and the possibility for failure you get. (Will you really test each of these localisations to see that all bindings do work as intended?)

I think that Dan’s idea to clearly separate the text, layout and application logic in a nib file from one another sounds like a good one (and like an opportunity Apple missed with Interface Builder 3). This way one might hope that at least the application logic part - which is the most error prone one - could be edited in one go for all localisations. While the wording and positioning would still be handled on a per-language basis.

I do not think that fully automating the other steps will be a good idea. Translating words automatically has plenty of pitfalls because errors happen there easily. My classic example being Apple’s handling of the word ‘extensions’ which can be used for for ‘system extensions’ and the asinine ‘file name extension’. In German they call one of them ‘Erweiterungen’, while using the word ‘Suffix’ for the other. Automatic translation FAIL ensued and was only fixed years later. Of course one can have better dictionaries that take all these cases into account, but it appears to be a bad idea to use dictionaries only. They can give you a headstart but you will need (a qualified person) to proofread things for whether they make sense.

The same is true for GUI layout. Often you can ‘feel’ that a window or dialogue box has been laid out automatically. Things frequently have a rougher look when being done in that way. The positioning isn’t quite right, there may be excessive white space, text may not be fully visible, elements can overlap. While I guess that one could find a formal language that describes the UI elements precisely enough to give a decent layout automatically, I suspect that this language would need to be so complex that using it wouldn’t actually simplify things.

Dan’s Sandvox web site making application gives another example for that. It has an inspector window which contains a load of settings that you can make to your site, each page and elements within the page. As inspectors go, this one is annoying. Because it is too large and even a MacBook screen can be too narrow to show the Sandvox window and the Inspector without overlap if you have your Dock at the side of the screen (and who wouldn’t). With German words and user interfaces running a bit wider than the English ones, the inspector is a bit wider in German. And here literally every pixel counts and every single manual tweak to reduce the inspector’s width is highly appreciated.

English speakers - and thus most software developers - may not care about these differences, but they do exist and it’s hard to understand why user interfaces shouldn’t be good in other languages as well. I am always tempted to suggest that English speaking software developers should learn another language and use their machine in that language, simply so they can appreciate the second class treatment and become aware of more of the pitfalls. Of course they’d need to learn the other language really well for this to be constructive which makes it rather unlikely that we see this happening. But perhaps setting up non-standard number and date formats may be a first step towards immediately spotting problems that would otherwise not even raise an eyebrow for potentially requiring care.

Just to illustrate typical problems of automated (or coded) user interface localisation, look at Delicious Library 2 which immediately struck me as half-assedly localised (confirmed by Dan’s statement that they do so automatically) and which sports UI elements like this:

Another coded localisation FAIL which annoys me pretty much every day can be seen in Apple’s Mail. It appears that the minimum distance of the search progress indicator from the right edge of the window is coded in a fixed amount of pixels there (rather than using the width of the Save button which has to fit into the space). As I like my Mail window narrow (how many e-mails have content that cannot be displayed in 80 characters of Monaco 10pt per line?), overlap happens:

The thing is that both these failures are blatantly obvious if you actually use the application. And in a way that is the real problem: Once you automate more of your UI work, you reduce the number of eyes seeing it before being shipped. As a consequence bad UI experiences will increase as users get to use an absolutely virgin UI. As long as you have to edit each NIB file, you are at least forced to look at it (minus programmatically inserted strings which can be problematic enough) and you can easily spot the obvious problems. Interface Builder 3’s info window will even try helping you do that.

I am a fan because, obviously, not everybody can use applications in English, German, Chinese or whatever language they were created for. As an application should help the person using it - rather than creating another language or cultural burden - presenting itself in a properly localised version helps a lot in that respect: The user will feel more welcome and comfortable about it.

That’s the theory anyway. In practice, it is hard to get localisations right and very hard to do them in a spot-on way. If people are aiming for quality localisations, creating them is a huge amount of work and maintaining them across updates will add to that.

The first thing that is needed for having localisations is awareness by the developer. The programming has to be free of assumptions about the language used which means that none of the strings appearing the user interface should be in code but they should reside in external resources. When dealing with Cocoa, nib/xib files are your friends as is NSLocalizedString. I’m sure other APIs have similar techniques in place. Furthermore you’ll want to make sure that things as date or number formats use the user’s preferred localisation and the corresponding formats (hello NSFormatter). Even more involved aspects of this such as the sort order of strings aren’t a big deal in environments like Cocoa. All that isn’t really hard to do but it can be a pain to retrofit an application, so it’s worth having it in mind from the beginning.

The next aspect is the GUI. Usually you shouldn’t make assumptions about the size and position of strings on screen. If you are designing your GUI in English, you need to keep in mind that nasty languages like German can need significantly more space for the same labels and messages. This has led to ugliness and usability problems (say, checkboxes with two-line labels or inspector windows becoming so wide that they cover too much on the main window on a medium size screen) in many places.

In a way these preparations on the side of the main developer are obvious and trivial. The hard part comes for the localiser. Ideally you want the localiser to be

• native speaker of the target language
• familiar with the UI terminology and style of the OS in that language
• fully aware of all of the application’s features
• using the application himself

It’s hard to find such people. There are plenty of native speakers and some may even use your application. But then things start being difficult. Very few people are actually familiar, or intimately familiar, with the terminology of the OS in question. And that’s not just about the terminology right (say, by using Sichern for Save in German on the Mac rather than Speichern) but it’s also about knowing which styles of phrases and senteces are adequate and fit in with the rest of the OS.

This is hard to formalise, but if you look at the preferences window of VLC in German it’s mostly an incomprehensible mess that doesn’t fit in at all. Compare that to the preferences window of Transmit in German which seems to be done by someone with just the right skills, awareness and care for detail.

The next crucial issue is the awareness and full understanding of what an application does and what the localised strings are used for by the localiser. Many applications come with localisations clearly lacking that. And it’s a difficult thing to get right! Most applications do have somewhat obscure features and bunches of strings that are used very rarely (error messages for when an initial import of data goes wrong, say). The context when those come up may not be clear at all from the string resource files the localiser uses. And even if it is reasonably clear, the localiser may still have the wrong impression of the situation the string is used in.

While NSLocalizedString helps a lot when doing localisations, the next question is how good the descriptions are which developers put along with their strings. Cocoa developers: Do a count of No comment provided by engineer. lines in your .strings files. Now! And even when there is a comment, will it be a useful one? I find that it often requires quite a detailed explanation to pin the usage of a string down precisely. Imagine that the person translating this doesn’t have your code to go by and may have never seen the UI part in question in the original language. For an extra challenge consider that you may be using the same strings in menus (NIB files), in code (Localized.strings files) and in your help. As you can’t pin down cross references between these, changing terminology a bit requires great care to catch all the places that need updating.

Wich hints at the last point that the localiser should really use and test the application and its localisation to see all the localised strings used. With complex applications and even slightly non-trivial applications that can be hard to achieve and it requires a lot of time. And it’d also require a clearly described testing plan of which situations to check. Which applications have that? In a way that covers all possible UI constellations?

Getting these finer points right can be exhausting for both the localiser and the developer because they first need to agree on how close a localisation needs to be to the original (I tend to think that localised versions feel more natural if the localiser has a bit of freedom to change expressions away from literal translations, but if such changes go too far it may be very hard to talk about an application and its features across language barriers) and then invariably there will be terms in the original language which can be interpreted in different ways each of which would get a different translation. Often it’s necessary to check back with the developer what the intent of the command is to find the most adequate translation.

Altogether that’s not a huge amount of fun (and that’s before even looking at the laborious process of translating things like read me files, help books and release notes) and it has many places in which it can go wrong.

This also explains why there are so many bad localisations around. Only very few people can do the job and only a few of those have the patience to do it well. Now imagine there’s an open source project and an enthusiastic user contributes a home-made localisation. To make things easy let’s assume that it’s a good localisation. The problem with that is what happens when the next update ships. Will that user still be around to contribute any strings that were added and update the read me and help accordingly? How long will he need to provide those changes? You certainly can’t expect him to do all that quickly and for free, so you’re stuck in a difficult situation there.

Now assume the more realistic situation of someone contributing a localisation that’s not perfect. There are many ways in which a localisation can be imperfect: From poor alignment of UI elements, to some strings not being localised (tooltips or accessibility strings in nib files are easily overlooked when working in Interface Builder which probably is why more ‘pro’ localisers prefer tools like iLocalize), to problems with the language (how can I know whether the localiser uses terminology that fits in with the OS and uses ‘good’ translations of the original terminology when I don’t know the target language very well?) to simple typos. Many things can and will go wrong in that process. And it will require a lot of extra testing, particularly if you don’t know the localiser long and well enough to trust them on doing a good job and all the necessary testing on their side already.

Perhaps a bad localisation will help some users, but I usually consider it ‘half-assed’ and find working in a poorly done German version which still has the stink of English terminology all over it much worse than working in the properly done English original (early localisations of Sandvox always made me deactivate the German localisation and loads of open source software trigger the same reflex).

What makes this situation particularly difficult is when people offer to do localisations for you. Even if they do all the translation work, just including the localisation will leave a chunk of extra work with you of which you won’t a priori know whether it actually improves the application and whether you’ll be able to co-operate on future versions as well.

As localisations are a good thing and some users just like your application enough to want to have a localisation for themselves, that’s a really nice thing of them to do and you don’t want to turn them down. But at the same time it’s hard to be enthusiastic about including such a third party localisation when you know all the ‘buts’ I listed above. Which is a little dilemma.

Read on about these administrative hassles…

I quite like VHS.

OK, now shut up technophiles: I know that there’s better video quality than VHS will give you and there’s better audio quality than VHS will give you and rewinding kind of sucks as well. Allegedly even the tapes wear out. Yet, whenever I have to use a DVD player I realise in how many respects my modest VCR is much better than they are. In terms of user experience at least.

This starts when inserting the tape. You can only insert it in one direction, it will be promptly swallowed by the machine and despite the somewhat elaborate mechanics in the machine it will start playing within a second or so. Very few DVD players can match that speed. And even fewer will pick up playback at the same location you stopped it at before ejecting the DVD (out of a different player).

Once you play the video it just plays, no silly menus nothing. You can forward and rewind whenever you want as well. My machine even does the dual channel or stereo thing, meaning that you can even watch bilingual versions of films and switch between two languages there. That was quite rare even in the mid-1990s when I got the device and only became common shortly before the demise of VHS shortly afterwards.

But however much I appreciate VHS, its time is pretty much over. While my VCR is one of the few technical devices I own which hasn’t FAILed me in the many years I had it, it won’t last forever. And those video tapes take up a lot of space as well - with many of them containing stuff I won’t ever look at again anyway. And hence the plan was made to figure out the few recorded films that I really want to keep and copy them over to the computer using an EyeTV hybrid stick [Buy at amazon .com, .uk, .de].

That USB stick doesn’t come with analogue and DVB-T tuners alone, it also has a little socket into which you can insert a tiny plug that extends into the typical red, white and yellow plugs as well as a S-Video one. Now I just had to feed the signal from the VCR into those. Luckily we have a little SCART to coloured plugs box thingy sitting around. I tried that ages ago - and it didn’t work. To be honest I just thought one of the little contacts in the eyeTV was broken, leaving me looking stupid.

But when I realised that I could feed an anlogue signal in there (doing silly self-referential things with the computer’s video output…), it was clear to me that the problem was SCART once again. Really, I can’t remember a single setup in which it was possible to connect various devices to a VCR or telly using SCART. Often one device would work perfect, while another wouldn’t. Or one would be black and white while the other appeared in colour as it should.

Those problems could usually be ‘fixed’ by resoldering some of the wires in the sockets to different contacts, but that’s hardly the Just Works™ approach I prefer. In fact, it’s just horrible. But there I was again, trying to clumsily ‘re-wire’ some of the contacts in the hope of finally getting my videos into a digital format (I tried copying via an antenna cable using the VCR’s tuner output but the quality of that is just horrible). And - by sheer coincidence - I realised that the VCR’s output made it into the computer just fine when I semi-unplugged the SCART cable. Not that that makes any sense to me but technology isn’t supposed to make any sense. Frequently things working at all are Good Enough™.

And there I went… running into hard drive space problems shortly after because those gigabytes are filled rather quickly with the MPEG2 files EyeTV writes. Now I have to recompress the stuff. Which in itsself is a complete PITA. While the EyeTV folks made an effort to give you a nice program guide, they still use QuickTime for exporting.

And QuickTime’s settings dialogues are - and have always been - straight from GUI hell. As well as buggy. Previews won’t work, the format settings you choose will be ignored, or at least sometimes randomly ignored - which you will only see after the multi-hour exporting process has finished. There are plenty of settings you can make for image cropping or de-interlacing or encoder settings. Each of those settings can have a huge effect on the result and as a non-expert on these issues it’s hard to find a reasonable compromise between the quality of the result, the size of the file created and the time needed to compress it.

Tasks like recording stuff from VHS look like they are pretty common tasks for a software like EyeTV. Why not ship it with a export preset for the common 4:3 and 16:9 aspect ratios and compression settings that don’t degrade the quality but don’t waste too many bits on what ultimately comes from VHS? I’m simply not that good at remembering things like 704×396 and entering them into the friggin’ QuickTime window over and over again. (The same shortcoming exists for ‘modern’ DVB-T recordings, btw. And I cry when the incapabilities of EyeTV and the bugs of QuickTime become one, say when wanting to use thrid party plugins like x264 which is supposedly better than QuickTimes H.264 importer - and more significantly quite a bit faster as well. That can completly fuck things up, so it’s argh all over again.

My latest idea on this was to use the magical HandBrake (I can’t help it - it’s pineapple icon always makes me think of Spongebob) for the task. It has yet differently strangely quirky cropping options and - unfortunately it seems to have a taste for crashing when handling them. My final question for all of these cases is how much of a difference muti-pass encoding makes quality-wise.

Another surprising thing you can discover when doing these things is that it’s hideously complicated, if not impossible, on a multimedia savvy computer like a Mac to separate the two audio channels of a stereo recording with the software shipping with it. [And it’s similarly non-obvious why EyeTV doesn’t export films with dual sound tracks.] I’ll leave that as a little exercise for the reader to figure out: Given a film with a single stereo sound track, turn it into a film with two mono sound tracks which you can easily switch between… Shouldn’t separating audio channels be the most trivial of audio tasks?

My big problem is that I’m not an emacs person. Yeah that thing is powerful and will probably give all the modifier keys you have a good workout. But I never wanted to deeply learn a text editor, I just wanted to type stuff. I’m not usually fussy when it comes to this and I am perfectly capable of typing an e-mail in Apple’s Mail or a simple text in TextEdit. I won’t need any fancypants features for doing that, so those applications will do. In uncomfortable situations and simple edits I can even deal with pico or vi in the terminal. The latter may be the most user-hostile piece of software ever because it has no quit button but once someone explains you how its two modes work and how to save files and quit, it does the job just fine.

While I haven’t used computers long enough to consider manual work with magnets on metal platters or punching holes text editing, I once had to use edlin on MS-DOS. Which probably was the most horrific text editing experience I ever had.

At some stage, of course, you realise that simple editors may be nice but when you do something like write TeX, HTML or programming languages, a slightly more powerful editor is helpful. First and foremost syntax highlighting helps – and has been around for a long time (on the Mac even with bold face and IIRC non-monospaced fonts in applications like Think Pascal). In a next step there’s highlighting of brackets while you are typing to see whether you balanced things correctly. And, finally, an editor can know more about the language you are typing in and it can offer commands to insert commonly used structures for your convenience. Soon after that people will want to start customising those commands because everybody has a different understanding of ‘commonly used’.

Although I have been a user of the rather extensible Alpha editor on the classic Mac, I never grew quite comfortable with the vast customisability and extensibility. And when switching to OS X I settled for using TeXShop instead. Apple’s developer tools come with their own editor that wasn’t brilliant but did the job (and had a convenient ‘compile’ button right there…) and I can’t even remember what I used for HTML editing right after switching to OS X.

As time went on I stuck to TeXShop – learning to love its lack of progress as well as bugs – but discovered SubEthaEdit (né Hydra) and was rather happy with that (all the Cocoa goodness + command line tool + syntax highlighting + change highlighting + document sharing). Then Coda came along and I started to use that for remote file editing because it’s nice for that and has quite good autocompletion (but with its huge windows and lack of Mac support or command line tool isn’t that great for local editing). Which means that I ended up being a bit screwed because there are just too many text editors on my system – each with its own set of strengths and weaknesses –  which I find confusing.

After seeing TextMate’s creator Allan Odgaard speak about TextMate on the C4 video, I at least wanted to know what the fuss is about and thought I’d try TextMate as an editor. From a distance I suspected that TextMate is ‘too emacsish’ to please me. Too many options, too well hidden, too powerful for little Sven. And too much DIY required to get things working ‘just right’.

The suspicion turned out to be essentially right. I don’t think TextMate is a particularly good Mac citizen. Not just because it doesn’t display Finder labels in its file listings (Coda doesn’t do that either, what’s wrong with those text editor makers?), but mainly because it is very keyboard focused. In fact so keyboard focused that I found it rather hard to even find the commands it had. Which to me is a bit like subverting the whole idea of discoverability that gave us graphical user interfaces to begin with.

In my initial struggle several people pointed me to the somewhat amusing – and to the non-initiated non-self-descriptive – ‘Select Bundle Item…’ command. It lets you search through all the commands provided to TextMate by plugins (in a way that’s a bit better than that provided by X.5’s Help Menu). That may be brilliant for long term users but it was rather useless for novices like myself as I didn’t know which commands existed and how they were named. And that menu item is the top-most-, most important-one in the ‘Bundles’ menu (what a name?!).

I also failed to understand why, when editing a TeX document, for example, I always had to navigate into a submenu – of either the ‘Bundles’ menu or a submenu of a menu that appears when clicking a tiny button (about a third as important as setting the ‘Tab Size’ if size is anything to go by) at the bottom of the editor window – just to use a command directly relevant to the mode I am currently working in. For such an essential action this seems overly complicated and inforced the ‘emacsish’ and ‘too keyboard-focused’ impression I had.

I didn’t take notes, so I’m sure I missed a few more points which I sighed about while trying to use the editor, but a few of them stuck anyway: Be it that using italic styling in small font sizes generally is a bad idea if you like things to remain legible. Be it because I thought that the syntax highlighting was a bit slow at times. Be it the inability to mark my changes in a file, the lack of split views, the inability to drag tabs out of a window (or simply the skill to hide those abilities from me). The separate window for the find feature drove me nuts as well as I got addicted to ISIM crack many years ago and Coda luckily went with a similar idea. At the end of the day there are too many things I didn’t like in the editor.

But in a way that’s a shame because TextMate comes with a number of very cool and useful features. While I don’t really approve of it, the customisation certainly is one of them. Particularly because it is reasonably easy to add your own commands to those already defined by the application and its plugins – even I could do it. Neither the process nor result were particularly pretty but it did the job.

Then, the code folding is certainly a nice thing to have. I don’t think I would use it frequently but sometimes it’s very handy. The same holds for the editor’s ability to keep a clipboard history for you. The lack of speed in syntax highlighting I perceived certainly came with the advantage of giving good results. A particularly good use of that is the highlighting of wrong quote usage in LaTeX mode:

Nanny-text editor, perhaps, but useful nonetheless and quite precise as well. The next thing worth mentioning is autocompletion which has a few nifty tricks up its sleeve. One is mapping the autocompletion keystroke to the escape key (rather than option-escape or F5, the two usual combinations which are pretty inconvenient on a laptop keyboard). While not as fancy as Coda’s autocompletions which pop up in a menu, TextMate just cycles through the available options and provides the shift-escape key combination for cycling backwards. In practice I found or at least perceived this as faster and more convenient than using a menu. The autocompletion seems to work based on the context you are in and it worked quite well for me as long as I wanted to complete terms without a hyphen or so in them.

But there are also more advanced things which I’d call ‘completions’ in some sense. At a basic level, typing something like a { will automatically insert a } for you. Many editors do that these days which is sometimes great and at other times infuriating. But TextMate has some extra smarts up its sleeves. For example when starting to write a CSS selector and hitting return after that { after which the matching } was automatically inserted, TextMate does just the right thing™, by moving the closing } two lines down and putting the cursor in an indented position in the blank line in the middle. Excellent:

Along with that it’s worth mentioning that many of the TextMate modes also come with commands to just re-style a document. Meaning that if you receive (or wrote!) a shoddy CSS or TeX file which is hard to read, using a single command can improve the situation dramatically.

Another neat feature is the ability to insert something you type several times for a single keystroke. That’s useful when typing LaTeX environments, for example. You’ll type ‘begin’ and then the tab key and TextMate will convert it into a pair of \begin{} and \end{} commands with the genius being that you can then type the environment’s name and it will appear inside both brackets simultaneously.

Speaking about TeX, TextMate also comes with a very interesting (but not particularly practical) way of running TeX: Rather than displaying the full ugly TeX log output to you, the LaTeX Mode makes the brave attempt of parsing the output and filtering out the relevant information. The implementation isn’t perfect, but it illustrates that TeX output doesn’t need to be ugly and hard to read and that the front end you are using can try to get just the relevant information to you. [Compare with the dedicated TeX front end TeXShop for which people have to hack things to get semi-ugly output.]

Despite those features, I am left with the feeling that TextMate just isn’t made for people like myself but more for people who only dislike emacs because it runs in a terminal window rather than disliking it more profoundly.

So I’ll just sit back and hope that the editors I am using will improve over time and pick up a few of the neat tricks. So, hello Coding Monkeys, what about some of these niceties? And hello Panic people, what about giving the monkeys some bananas to make sure you’ll get their improvements as well? KTHXBYE.

[Waiting for people to tell me that emacs did all this and more since ca 1789 already…]