Quarter Life Crisis

The Craft of Scientific Presentations¶

The web is full of advice on making presentations. Most of that advice seems focused on the business world - that is a situation where the information content of presentations is very low and the intellectual content is even lower. Situations where it is more important to persuade - or sell - than to make an argument and make people understand. It’s more about being sexy and memorable than about presenting complex information.

Looking at sites like Presentation Zen gives you the impression that in those business presentations you’ll get away with some gradients, some stock photos and some tangential but clever quotes on your subject. And - giving the benefit of the doubt - I’ll assume these techniques actually work. In a more scientific context many of those methods seem to fail though. Basing a presentiation on stock photos and witty quotes will probably get you laughed out of the room or at least not be taken seriously. And, much more significantly, people usually have non-trivial information to tell.

At least in areas like science, mathematics or engineering that information already requires visual aids so the audience can see the measurement results, follow the deduction of the formula or visualise the constructions. After all that has been incorporated into the presentation there is little space left of the pretty or witty. But still bad presentations are very common in these areas and it was cool to discover that there’s a book on the topic: MIchael Alley’s The Craft of Scientific Presentations. It’s a book with a promising title and - even more promisingly - with Mr Feynman on the cover. While it is a bit repetitive at times and I am not sure it contains great concrete advice, it has a very helpful list of things that can go wrong, have gone wrong and do regularly go wrong in presentations:

• Giving the wrong speech (audience? purpose? occasion?)
• Drawing words from the wrong well (speaking from points, memory, paper, of the cuff)
• Leaving the audience at the dock (anticipating questions and bias)
• Losing the audience at sea (make changes in course clear, don’t drown people in detail)
• Projecting slides that no one reads (typography, colour, layout)
• Projecting slides that no one remembers (show images, results and the presentation’s organisation)
• Ignoring Murphy’s Law (rehearsing, arriving early, accounting for the worst)
• Not preparing enough (preparing visual aids, yourself to speak, talks in another language)
• Not paying attention (to the room, yourself, the audience, time)
• Losing composure (controlling nervousness, handling questions)

Most presentations will most likely improve by simply taking into account a few of those points before holding them. In fact, I’d wager that most people could nod to every single point in the list and think yeah, I’ve seen that or even yeah, colossal FAIL on that one in talk XY.

Of course the various points apply to different degrees in different subject areas. Both because of the differences in topics but just as well due to the differences in culture. In mathematics, say, the danger for technical FAIL is much lower because people frequently use blackboards which at the same time is good for reducing the presenter’s speed to a reasonable level (i.e. slide based talks are frequently incomprehensibly fast as it’s damn easy to flick through a bunch of slides with a complex argument in a minute but it will take time to write it out) and bad for his face time to the audience (not that mathematicians would notice that, anyway). On the other hand it’s really hard to adjust a talk well to an audience as being familiar with the intricacies of the topic makes many things look ‘obvious’ when in fact they are not to people hearing them for the first time.

The list will be helpful to keep in mind, both when making and when consuming presentations.

Nagnagnag: I had to sigh about the book’s typographic attitudes though. It’s set in the lovely Palatino but somehow they managed to make the font size a bit too large and the line spacing a bit too tight which makes it look like a school book. The author also likes Arial (headings in Arial Narrow Bold and recommendations to use it for slides all over the book) which makes it particularly amusing to see that the Regular version of the font was replaced by proper Helvetica. Now that’s a refreshing turn of things.

[Buy at amazon .com, .uk, .de]

9:37 • Feedback (0+0)

It wasn’t me¶

… but that car still parked right behind me. Thought it looked cool, though.

11:17 • Feedback (0+0)

Tastes like Chicken¶

I developed a taste for grilling chicken last winter and did so pretty much every single weekend, learning about little details like brushing salt water on the chicken’s skin over time. On the warmer days of summer enthusiasm for oven made food ebbed away and only this weekend - in dark and cloudy July - it came back. I went to chicken shop, filled the oven, grilled some carrot slices along with it (herbs are nice and butter is essential for that) and had a nice meal.

This one came out extremely crisp which I enjoyed. And the next day I learned that a fully home-made chicken mayonnaise sandwich can be quite a joy as well.

0:03 • Feedback (0+0)

Macintosh or Windows¶

After I discovered a while ago that my EyeTV’s analogue input wasn’t broken but its failure of getting any pictures to me was another case of SCART FAIL; And after discovering that plugging the SCART plug in sort-of half at a slight angle would give me an image, I started going through my trusty video collection to see which of the films - lovingly recorded from telly back in the 1990s - I wanted to keep. Luckily I’m not a big re-watcher, which kept the number reasonable and only made me go for the stuff I don’t expect to be easily available in the future.

One of those ‘out-of-print’ videos is called Macintosh or Windows? It was made in 1996 and I received it after finding some Apple evangelism web site - and happily telling them about the enthusiasm I had for the platform at the time. Which probably came from me not having become as cynic as I am today and Apple’s products being much more amazing at the time. Amazing in that they could do plenty of cool stuff which other machines couldn’t do. I also hadn’t seen a Mac break down at the time. Neither in hardware, nor in software - which was quite remarkable compared to the self-destructive habits of DOS and Windows seen on the machines of the few remaining non Mac-using friends in those days.

The video is rather amusing. A guy stands in front of a Mac and a Windows machine and illustrates how the Mac is a superior machine. The film is made with a bit of humour as the guy keeps tapping the ‘other’ machine in a friendly but ever so condescending way. And in how they show all the hardware and installation horror people had to (still have to ?) suffer through on Windows machines.

Of course the comparisons are grossly unfair as well. For example attaching an external hard drive was mentioned. On the Mac one could simply attach it via SCSI. And the Windows machine didn’t have a SCSI connector, so it was about opening the machine, installing some card, getting it to work and so on. I am fairly sure DOS machines with built in SCSI cards existed as well in those days.

Obviously price isn’t mentioned in the film and the fact that the presumably generic ‘Mac’ in the comparison was a not-exactly-cheap PowerMac 8500 may have played a role there. The machine happened to have built-in video capturing logic. And thus a further test was to compare videoconferencing. Hilarity ensued as the DOS machine needed to have a bunch of cards (networking, sound, video) installed to match the features.

Another inadequate test won, hooray. Then came speech recognition. Which I even considered a somewhat risky topic back in the days. Because the Mac’s built-in speech recognition always sucked for anything you tried to do with it beyond the wonderful Knock, knock script. Actually it frequently failed on that as well. I guess we don’t speak the right American accents…

While there is some humour in the film, I felt a bit disappointed that they elaborated so much on the hardware aspect - i.e. more expensive hardware having more features and requiring less fiddling. Then - and all the more today - the main value is the OS. Its advantages are more subtle and probably difficult to express in such an advertorial film, so they get left out. The only such subtlety the film features is the Finder’s ability to just let you drop control panels and system extensions on the System Folder and file them away appropriately. A feature so nice that it was killed when the Unix overlords took over the Mac platform a few years later. Now we’ve got installers, yay!

More than a decade later the focus on rather superficial advantages also makes the claims in the film look extra silly. Even in software - rather than focusing on a clean and consistent design - they went for the latest and greatest features. And thus we see stuff like AppleTalk printer sharing, QuickDraw 3D and even the wonderful Cyberdog in that film. Those actually were great technologies and at least AppleTalk and Cyberdog haven’t been outdone by their successors yet.

Ugh, and the architecture. A diagram - made back in the System 8 days! - which I found highly amusing and quite possibly correct.

0:09 • Feedback (14+0)

Serviceweltmeister¶

I had to choke / chuckle over breakfast when I saw this full-page ad in the paper:

Deutsche Telekom putting an ironic (or ironic-ironic? or pseudo-ironic? It’s hard to tell in these times of ironic post-irony.) heading Serviceweltmeister (service world champion) with their name along with some small print that they haven’t managed to be that yet.

That sounds like sufficiently many people must have suffered from Telekom’s ‘service’ that even their higher echelons and marketing zombies felt they need to address it. Wonderful. Somehow putting ads in the paper must be better for shareholder value than firing the useless consultant who fuck up their processes and hiring people with brains. Sometimes the first steps really aren’t that hard…

While we have working internet again now and Deutsche Telekom, after just a few weeks (which is presumably less time than they’d need to find out what’s wrong with a DSL line), even promised to refund us €20 for not being able to use the DSL line we paid for, the story isn’t quite out yet.

As their fantastic administrative processes these days mean that changing the name on your phone contract implies that your line will be cancelled and reconnected (this was no problem a year or two ago), our ‘new’ phone line isn’t quite back in the state the old one was for (i.e. the state we signed up for). By now we had managed to turn off the annoying network asnwering machine they ‘include’ with new lines, we still send our caller ID (i.e. Telekom inflicting with our privacy rights without even telling us) and, most annoyingly our phone bill isn’t itemised anymore.

As the bill is to be split up fairly - hence the existence of Rechnungs Checker - we require that information. And we need it in electronic form. But now we had to re-apply for all of this again - which is quite of a hassle because you need signatures of all people owning the phone line for data protection reasons. And of course I want the itemised phone bill I missed in digital form as well. (Or they should supply me someone who takes the hour to parse my Rechnungs Checker preference file and split it up for me.) Judging from their past incompetence, I highly doubt that they’ll be able (or even try) to do that. Although that’s exactly what I signed up for. But any argument along those lines is completely ignored by their staff. It really seems like you need to be a complete jerk, get a lawyer and sue them or something just to wear off the blaséness (sounds a bit like Apple, to be honest).

Speaking about Telekom staff. People in their shops are as friendly as they are clueless. When I handed in the signed forms (which they actually fax somewhere else for processing), they still managed to bring up our old (pre name-change) account in their computer system, leading to an uh, you don’t even have a phone line comment. Free advice to Deutsche Telekom and everybody else: If your customers are able to explain the shortcomings of your internal systems to your staff, you have a problems.

Two extra annoying things I noticed when handing in the forms: First, the chick working there (I guess the fact that they are almost exclusively staffed by smiling little girls, makes a sexist comment fully adequate) tried selling me a DSL connection while I was their to fix a problem they caused. She firmly claimed that their offer would be better. And asking the standard question which of their DSL contracts can be cancelled monthly (answer: none) led to the blaséness mentioned above. It’s still better. We just like it the way it is.

The other thing I saw is that they seem to peddle some set top boxes now. A unit of that was being demoed at the store. And not only did they have Prekariatsfernsehen running, the image quality was hilariously bad with sharp edges being a showcase of compression artifacts and even the sound not synchronised with the image. Doesn’t that drive the people working there nuts? Who in their right mind would sign up for such a service? Can they at least make an effort to lie to people when trying to push it?

10:23 • Feedback (0+0)

Keyboard Equivalents¶

Lukas commented on yesterday’s localisation post that keyboard equivalents are a sore point for him in a lot of today’s software. And I can totally relate to that.

I seem to remember that some HIG revisions hinted that you shouldn’t use non-alphanumeric characters for keyboard equivalents. But that’s a thing of the past now and many applications love using non-alphanumeric characters like [ or \ for keyboard equivalents. As a consequence we have user interfaces whose keyboard equivalents make implicit assumptions about the keyboard layout you are using.

What’s particularly frustrating is not just that Apple do this nonsense themselves - but that other developers, mostly American, copy that without further thoughts. A consequence of that are keyboard equivalents which are somewhere between inconvenient and broken.

The most common case of this are keyboard equivalents for Back / Forward commands. When using the System in German, I get:

• in the Finder: ⌘Ö and ⌘Ä,
• in Safari: ⌘Ö and ⌘Ä and ⇧⌘← and ⇧⌘→ work as well when you are not in a text field,
• in Address Book: ⇧Ö and ⇧Ä (not kidding!) which seem to be dysfunctional
• in Preview: ⌘← and ⌘→

Problematic along the same lines are:

• Mail’s equivalents for decreasing/increasing the quote level: ⌥⇧⌘Ö and ⌥⇧⌘Ä
• Safari’s previous/next tab commands listed as: ⌥⌘Ö and ⌥⌘Ä with the ⌥⌘← and ⌥⌘→ working as well
• iChat’s previous/next tab commands: ⌥⌘Ö and ⌥⌘Ä
• Terminal’s previous/next tab commands: ⌥⌘Ö and ⌥⌘Ä

Most of these keyboard equivalents leave you screwed if you want to use the German localisation with an English keyboard layout (say for programming) where the Umlauts aren’t accessible.

Of course the problem also exists the other way round. While characters like [, ] or \ are easily accessible on English keyboards they are ⌥5, ⌥6 and ⌥⇧7 on a German keyboard for example. And thus mostly inaccessible. Different, but similarly awkward, finger gymnastics result from using most other non-English keyboard layouts.

If the basic examples weren’t enough, here are some more: Panic’s Coda, presumably a professional text editor, i.e. something where you may be more likely to use keyboard equivalents than elsewhere gives you

• ⌘[ and ⌘] for indentation (a pain familiar from XCode)
• ⌥⌘← and ⌥⌘→ for back/forward navigation in the file listing (thus mostly inactive when keyboard focus is on the text editor)
• ⌘{ and ⌘} for previous/next tab (which aren’t just a pain to type on a German keyboard but ⌘{ never works)

Panic’s Transmit - which unlike Coda has been localised (rather well) -, in comparison, uses

• ⌘← and ⌘→ to shift focus between the left and right file listings
• ⌘Ö and ⌘Ä to go back/forth in the folder history
• ⇧⌘← and ⇧⌘→ to switch between tabs

This list can go on and on, for example by looking at text justification

• in TextEdit: ⌘{, ⌘|, ⌘}
• in Mail: ⌥⌘Ö, ⌥⌘Ü, ⌥⌘Ä

or at the trend to use keyboard equivalents including ⌘\ or ⌘Ü for showing/hiding status or progress bars.

I consider this situation a royal mess. And it makes it pretty much impossible to build ‘muscle memory’ for certain commands, you always have to think ‘what do I want to do’, ‘which application am I using’, ‘is the application localised’, ‘which quirky behaviour did they choose’ - making things rather impractical.

To improve this, I again suggest that developers use varying languages and keyboard layouts with their applications. And whenever I choke on such keyboard equivalents I am tempted to start using accented letters, just so English speakers can enjoy the same inconenience.

Even better: What about a ⌘☃ keyboard equivalent?

1:45 • Feedback (0+0)

Localisations are a hassle¶

Dan Wood shares his experiences with localising software. While I detailed a few of the difficulties of the localisation process right on a language and ‘social’ level, yesterday, Dan focuses on the technical difficulties of doing it. Even with the tools we get for that task in Mac OS X and additional tools like iLocalize which are considered to be above average in the software world at large, the whole process is a rather huge effort and it’s easy to see why people don’t like going through it.

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.

0:10 • Feedback (3+0)

Localisations are hard¶

As a matter of principle I am a big fan of localised software. With the exception of many localised applications, that is.

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…

23:52 • Feedback (0+0)