An amazing number of my friends have DropBox accounts already [if you don’t, consider using this referral link, so both you and me get some bonus extra storage] and rightly so, because it ‘just works’ for many things. The service is reasonably reliable, its speed is all right, its available not just on the Mac but also on Windows and Linux and it’s essentially effortless. Many others tried and failed at achieving the same.

Yes, there are shortcomings of DropBox such as a potential lack of privacy and its disrespect for metadata like extended attributes (to be solved with their currently-in-development 0.8 release, it seems), so you may have to be a little careful, but in general it just works.

An interesting question we asked ourselves is how DropBox handles file system peculiarities. The HFS+ file system in its usual incarnation is case insensitive and case preserving, normalising its file names to a decomposed forms [thus, somewhat confusingly, if you name a file with a composed name, e.g. ‘ü’ (U+FC) in the Finder and copy its name afterwards or have its name in a folder listing by the web server, you get a decomposed result ‘ü’ (U+75 U+308)], whereas the file systems on Linux (Ext-something?) seem to be case sensitive and normalisation agnostic. How will DropBox reconcile these worlds?

Like this, it seems:

Here we see DropBox syncing the file with the composed umlaut and refusing to sync the one with the decomposed umlaut. It appears that they are working in normalisation form C. DropBox does sync both the lowercase and the uppercase umlaut. Of course I won’t be able to get both of those file on my HFS+ volume and a ‘case conflict’ is created by DropBox. In addition to that it seemed that trying to edit the case conflicted files leads to things becoming a bit messy. E.g. after editing on the Linux side which could in principle handle the case difference, I ended up with four files for some reason, all of which had lowercase names:

It doesn’t look like you may lose data because of this, but it does look like things may become a bit messy. Luckily one doesn’t work with files whose names differ just in capitalisation outside geeky tests like this.

One such point – which apparently has been changed on the more spacious iPad – is the positioning of the default ‘OK’ button on the virtual keyboard. It is quite close to all the other keys and easily hit by accident when you made a typo and want to hit the backspace key right above it.

This may seem trivial when the button creates a new line in a text editor, but it becomes a small nuisance when you’re in the Google field of your web browser and inadvertently trigger the Google search this way, forcing you through extra waits and taps as a consequence. And sometimes it becomes a mis-design which can cost you money and make you look like an idiot. For example in Skype for iPhone, which includes an otherwise nice SMS service that places the ‘Send’ button in this dangerous position:

Other applications, like Apple’s SMS application or Twitterific put the ‘Send’ button to a separate location. At least for the SMS application this looks like a deliberate design choice, for Twitterrific it could still be owed to the fact that ‘tweets’ may contain line breaks, hence require the Return key on the keyboard.

Price

The update to iPhone OS 3 was free for iPhone users and €8 for iPod users. Not a big deal, I suppose. But perhaps charging people for the OS update that implements copy and paste could make Apple look like greedy bastards. And, thanks Apple apologists, please STFU about weird American tax laws which are your favourite excuse for Apple being forced to do this. It’s all about what they want to do.

Copy & Paste

The biggest deficiency of early iPhone OS versions was their lack of copy and paste. It has always been a huge feature for GUI computers because it lets you split your work (on iPhone OS I’d rather say ‘tasks’ because its apps are toys) between several applications, which are dedicated the specific task. Hence one should think that the clipboard is particularly important on a ‘platform’ full of feeble applications like the iPhone which made people so upset that it didn’t exist from day one.

iPhone OS 3’s copy and paste interface is reasonably nice: You tap and hold and the interface elements for changing the selection as well as performing copy, paste and cut commands (the lack of clear may be due to the lack of space but it keeps irritating me that I have to use cut instead) appear. That’s not particularly easy to discover – but who expected things to be easy when all you have to interact with the device is a finger?

I saw two main problems with the copy and paste interface. One is that the tap-and-hold gesture is easily used by accident when you hold the iPod and touch the screen while doing so. As a result you end up with a bunch of buttons you didn’t want. A conceptual problem that I don’t see going away. Another initial shortcoming was that the copy button, once visible, would not scroll along with the view it belonged to, giving some dislocated mess. It seems that by now Apple fixed this issue in their own apps at least, but it doesn’t seem to be solved on a general level, say for WebKit, as third party applications like Wikipanion still exhibit that behaviour.

Bluetooth

One big promise of iPhone OS 3 was that it would enable Bluetooth support on second generation iPod touches. Actually this was the main reason why I wanted to have iPhone OS 3 right away. However, a big disappointment was waiting for me: the Bluetooth support is crap. It only seems to work for games. Audio profiles are not supported. Meaning that I cannot use my Bluetooth headset to use Skype on the iPod which would have been rather neat, particularly as wired iPod headsets with a microphone only seem to exist in expensive and breaking within months (Apple) or semi-expensive and crap (non-Apple) varieties.

Quite naturally, no kind of file or image transfer via Bluetooth is supported either. That would be too convenient for Apple’s brave new world of computing, I suppose.

Languages

iPhone OS 3 comes with plenty of extra language support. You get right-to-left languages like Arabic (but shouldn’t the Springboard’s orientation be reversed for those as well? And how fine-tuned is it? I assume that only one of 23°and °23 makes a correct writing of 23° in an Arabic weather forecast…)

Another very neat feature is the support for Chinese text input by drawing the character on the iPod. (This is also available in Mac OS X.6 on machines with multi-touch trackpads, but strangely not when using a graphics tablet.) Using the feature isn’t overly easy, particularly if you aren’t really a writer of Chinese or Kanji. But if you happen to see a Chinese or Kanji character and wonder what it means without being familiar of the sort order of the relevant dictionaries (which are needed to have a chance of finding it in your Mac’s character palette), this can be a great tool: You draw the glyph on your iPod, manage to do so well enough in the second or third attempt to get the correct character match from the iPod and then you can Google it or look up its kDefinition Unihan property to get a rough idea of what it could mean.

iPhone OS 3 also lets you turn off the system’s auto-correction feature. Particularly if you’re switching the language you are writing in, that is very important as otherwise you’ll get your perfectly correct words “auto-corrected” to foreign garbage. As typing on the iPhone OS’s software keyboard remains a mess you’d of course rather use the auto-correction. However, unfortunately, the whole system is rather poorly designed.

Apple’s current approach is the following: You pick a keyboard layout and the spell-checking language will follow. Which may sound logical to people who only use a single language, but is terrible if you really want to use it. Usually people are ‘hard-wired’ to the keyboard layout they learned typing on. I learned on a German ‘QWERTZ’ keyboard and type everything on that. Forcing me to use a ‘QWERTY’ keyboard for English and an ‘AZERTY’ keyboard for French is absolutely not helpful.

In fact, I have an English keyboard layout activated on my iPod, just so I can write stuff in English using the auto correction. But that clutters up my keyboard switching loop [said loop is particularly terrible, btw, as I also have the Chinese input method in that loop and iPhone OS always prefer to stall for a long time when trying to switch past that], it also feels stupid and regularly forces me to check which keyboard I am currently using and adjust the setting as needed.

Of course the right, or at least much better and more practical, way of doing this would be the one used in Mac OS X where you can switch the spell-checking language independently from the keyboard layout or – if that’s too much UI hassle – just go for the ‘Multilingual’ spell checker which seems like a reasonably good compromise.

‘Spotlight’

iPhone OS 3 comes with a ‘Spotlight’ screen that presents a universal search field. It appears as the left-most page in the row of application pages and I thought it is a rather neat feature that gives you quick access to a specific contact, song or very recent e-mail.

That said, in practice I find that I very rarely use this universal search. Normally I find it more natural to just go to the application in question and look up the information there without further ado.

Speed

Some parts of the iPhone OS have been carefully optimised for speed. Animations usually happen smoothly and scrolling lists can be refreshingly quick. Yet, Apple decided to leave certain parts of the user interface non-optimised. I am not quite sure why they did that and neither am I sure why it is considered acceptable. The top three annoying delays I frequently notice in iPhone OS 3 are:

• Unresponsive Keyboard: Sometimes the keyboards presented by the OS can be very unresponsive. Meaning that a second or more can pass before the screen reflects which key you pressed. Given the nature of an on-screen keyboard without any tactile feedback this is as FAIL as it can get as it means you effectively cannot type until iPhone OS 3 decides it is ready to accept your input. If the problem becomes too prominent, the good old Windows trick of restarting the iPod usually resolves the issue. But surely, it shouldn’t happen to begin with. Even less explicable: I frequently see those delays on the numeric keypad used to unlock the iPod. As entering the code is almost the only thing you can do with the iPod in that situation I see no reason whatsoever, why things shouldn’t be loaded and ready to use the moment I touch the device.
• Unresponsive Music Player: A very nice feature of the iPod is that double-pressing the home button while the screen is locked will bring up a minimal music player interface (a feature that only seems to work on the locked screen these days, which I think worked everywhere in iPhone OS 2…). This gives you a very quick and easy way to resume playing the current playlist when picking up the iPod and leaving. It makes up for the iPod’s lack of dedicated ‘Play’ button. Unfortunately pressing that Play button frequently doesn’t have any immediate effect as far as music playback is concerned. It can easily take a few seconds for that to happen. Which is irritating and seemingly unnecessary when there’s no hard drive to spin up.
• Lock Sound: Admittedly this may not be the third-worst speed issue in iPhone OS 3, but it regularly drives me nuts, so I have to list it here. When locking the iPod it plays a really nice metallic ‘lock’ sound. I enjoy hearing that every single time. But to work well, it has to start playing the very moment the screen is turned off. Unfortunately that’s not the case and often the sound is only played a moment later which spoils the whole effect.

I suspect that all these issues may have to do with Apple’s notoriously poor memory management and loading performance which may come from where the Unix smell in that company comes from. You see similar issues of non-smooth interaction because the relevant software has to be loaded first on the Mac as well – as any action that requires an authentication dialogue will remind you of.

Other Notes

While iPhone OS 3 was in no way revolutionary, there are many other little details which have been discussed all over the internet when it was released. I will use the rest of the page to list the points I found interesting or irritating.

• Helvetica in Calculator: the proportional font irriates me as the 1 is too narrow in the calculator which can lead to digits moving around in subsequent results.
• Poor sorting in Address Book: This has been in the iPod’s Address Book from day 1, it simply FAILs to correctly sort entries which contain a ‘maiden name’ entry. It appears as if the person in question is sorted in the section of the correct letter of the alphabet but within that section is sorted by their ‘maiden name’, i.e. usually at the very top or the very bottom of that section rather than along with their spouse. Compared to that, the fact that umlauts are sorted non-phone book style with ‘ö’ being treated as ‘oe’ in German rather than as ‘o’ looks like a minor incompetence. If people from different departments were allowed to talk to each other at Apple, perhaps the iPhone Address Book people could just check how the Mac OS X Address Book sorts entries…
• Nice location tracking in Maps: A sweet feature which may slip the attention of ‘always-online’ iPhone users is in the Maps application: While it is far from perfect when used without an internet connection and could do with a bit more cacheing, it seems to do a rather good job of caching the location information for WLAN base stations it seems to download from Skyhook Wireless: This means you may be able to track your current location in a surprisingly large radius of your starting point without needing to have an internet connection at that time. That’s pretty neat.
• Timer without Seconds: The iPod’s Clock remains one of my favourite applications. Yet, whenever I want to cook a 6 minute 20 second egg, I’d appreciate its timer having minutes and seconds instead of hours and minutes.
• Quiet Alarm Clock: While I do understand the conceptual idea of having a global volume for a whole computer, this can be really problematic when it is applied to Alarms as well. The point of the Alarms used by the Clock’s Timer or Alarm Clock feature is to get noticed or even to wake you. But when the iPod’s system volume is set to a low level you simply will not notice them. This already caused a number of such alarm moments to go by unnoticed for me. I’d be more than happy to give up the strict conceptual idea there and let the iPod adjust the volume to the highest level for the alarm. Or to at least warn me clearly when starting an alarm-action while the volume is very low and when reducing the volume too far while waiting for an alarm. Alarms need to be reliable. This keeps the iPod’s alarms from being that.
• No timer on login screen: While I support the idea of having a ‘clean’ login screen on the iPod without extra gadgets on it, I’d frequently find it useful if a timer I’m running in the Clock application would be displayed just there. I tend to use the timer quite frequently when cooking. And when wanting to know how much time is left to go, I currently always have to turn on the iPod, unlock it and look at the timer. It’d be much more convenient if the time remaining for the timer would be displayed right there on the login screen. Just as push notifications are.

• Variable Speed Podcasts: The iPod offers to play Podcasts at half and double their original speed (naturally without smurf voices) which is pretty neat on shows that are spoken very slowly (or very quickly). I thought that perhaps some intermediate speeds may be very useful, though, as doubling the speed often seems to overdo it. [I have no clue what the envelope icon in that screenshot is for, though, it seems to be inactive on my iPod, I couldn’t mail anything.]

  

• Calendar notifications not live: I enjoy the iPod’s ability to give me an alarm sound for calendar events. That’s useful when I’m away from the computer. The iPod displays those alarms like push notifications on the login screen. Unfortunately said display is rather lame and static. I.e. when I am not using the iPod for a day and an alarm comes up for a current event, it will still be on the login screen with a note claiming the event is ‘Today’, even though the event was ‘Yesterday’.
• Calendar Editing FAIL: Whoever came up with the idea that subscribed calendars shouldn’t be editable and neither update themselves in the iPod when synced over from iCal should be told that it was a bad one. And no, hiding some way to subscribe to calendars far down in iPhone OS’ Settings app doesn’t really improve this.
• Non-deletable crap: A bunch of applications on the iPod are useless to me and my device. The voice memo app, for example, or the video, iTunes and stock exchange ones. I don’t use them, and I don’t want them to litter my precious screen real estate. Yet, Apple don’t let me remove them from the screen. Hence – and it turns out this seems to be common practice between iPhone OS users – the last screen of applications is a dedicated junkyard for the stuff I don’t want to use.
• Mail doesn’t support encryption: Mail on my Mac supports encryption with the certificates I have installed; presumably everything syncs back and forth ‘just so’ in the magic Apple universe, so I fail to understand why I cannot read my encrypted Mail on my iPod (insert conspiracy theories here). Even worse, iPhone Mail will wrongly claim the e-mail doesn’t have any content.
• WLAN Password sync is lacking: If you ever had to enter some 30 character junk WPA password you will really prefer doing that on your Mac with its sane keyboard and sane user interface which includes the ability to display the whole password while typing. And then you want it to sync over to your iPod automagically. But Apple decided you prefer to enter the password once again on a wannabe on-screen keyboard without really seeing what you’re doing. Not so brilliant.
• ‘Smart’ WLAN logins: iPhone OS 3 comes with the presumably smart feature of recognising login pages for WLANs and automatically presenting them to you when a connection to such a WLAN is made. Our university WLAN offers the ability to log via both Cisco VPN and to also use a Web interface. It seems that iPhone OS 3 effectively prevents this from using the proper VPN connection as you need to press the Cancel button on the unwanted login page that pops up and the iPod then decides to just disconnect from the wireless network. This sucks and is far from reasonable or easy to use. It seems that our network people had to set up a separate SSID so iPhone OS devices can use the network at all. FAIL.

• Unfortunately Matt Gemmell had fallen ill and couldn’t give his talk on Tuesday morning. A Get Well Soon card made the rounds instead.
• Jeff LaMarche had to take over the early session instead, running it with a lack of sleep and fresh clothes thanks to the less fortunate sides of air travel. He spoke about fiddling with the Cocoa runtime to dynamically analyse classes or to add methods to your own classes while running. I keep thinking this stuff sounds very clever and neat but that I just don’t need it. And - as Jeff pointed out as well - it’s probably bad to use such techniques just because they’re cool. You need to get real benefits from them.
• I tried out Tom and my Flame iPhone Bonjour Browser during the talks. With dozens of Macs and iPhones full of geeky software on the network, it was a great opportunity to see how well the application works there. While doing so, I discovered numerous service names which we had never seen before and which are not in the list at the DNS-SD website (yet). I tried to note all of them and hoped to figure out whet they are about. In case you can offer a description or link indicating what any of the following types is for, do me a favour and leave a comment: qmp4, swblic, rsagent (could this be a Windows virus?), todogwa, istatrmt, aicheck, scan-target, timelog, friedegg.
• In the next talk, Andy Finnell. spoke about Core Image, going into the details of creating a watercolour brush. The physics modelling of the liquid and pigments in this was quite involved, possibly distracting from the Core Image aspects. OpenCL was touched in the talk which I found particularly interesting.
• I tried to figure out more about OpenCL [Wikipedia] and its capabilities. Andy pointed me to Drew who apparently touched the topic in his workshop on parallel processing on Sunday. And both of them pointed me to the Mac Research site and the tutorials there. A colleague of mine is doing some insane number crunching and was trying to figure out whether it can be sped up by going beyond straight C. Using SSE seemed a bit crazy as it will mainly make the code very incompatible. OpenCL, being both ‘open’ and abstracted from the actual hardware could fit the bill perfectly there. It just seems that it’s so new that people don’t have much experience using it yet.
• In the next session two somewhat ad-hoc talks came on to step in for Matt Gemmell. Dave Dribin tried to earn some more bashing on twitter by speaking about version control systems and pointing out that Subversion is still king because it’s very widely supported while git is the king of hearts, in part thanks to github, but it can still be confusing as hell [I agree, but to be honest I have the impression that git makes a surprisingly big effort to help the user at times - for a tool coming from Linux-land anyway - and even with next to no understanding of git I managed to do much more with it than with Subversion; the Pro Git book is an invaluable resource for that] while Mercurial/hg [Hint: it’s stupid to not name your application and executable the same, no matter how ‘clever’ it seemed at the time] is supposedly cleaner but nobody gives a damn. I think I had seen the slides for this talk before, so I didn’t find it particularly interesting.
• Next, Graham Lee spoke about code signing. I went through the pain of figuring that out for myself when it was new (and there was no neat popup menu in the build settings to do it). But Graham also showed a little demo app (nominate it for an ADA if you can! - Mac software these days needs to be ‘focused’.) illustrating how you can check the consistency of your application’s in-memory code at runtime thanks to code signing. Ultimately code signing is a double edged sword (you may appreciate knowing that an unaltered application is running when processing sensitive data, you’ll hate it if you need to modify someone else’s application to do its job in a way that suits your needs).
• Graham’s talk also came with friendly piss-takes at the name of ‘Jon’ ‘Wolf’ ‘Wrench’, or whatever. The ‘Wolf’ part keeps reminding me of people calling Mozart ‘Wolferl’ (in Amadeus I think), so I’m not a big fan of it.
• Incidentally I went on to discuss some clicktoflash stuff with Jon during lunch. As time was running fairly quickly and the network hated us we didn’t manage to cover everything and perhaps we’ll need to discuss things a bit more until everybody’s on the same page. Which preferably should be my cutting-edge page, that still comes with a problem or two at the moment but could be a reasonable way to go forward. Things we could do with help for are running on X.4 (I don’t really care, but I suspect this might be easy to fix if one is able to run the project there in a debugger) and for figuring out how/why the sIFR code seems to have broken in refactoring.
• Next on stage was Aaron Hillegass who’s known for giving great courses and really does wear a ‘cowboy’ hat on stage. He started off with iPad references and saying that local data is a dead concept and the future is in the cloud with local drives just being caches and pointing out the obvious benefits [no fear of data loss] without going into nasty details [how screwed will you be on network FAIL? what about privacy? (you’ll get over it) or encryption?] while mentioning others [like vendor lock-in, that’s an obvious problem in the Apple universe but frequently ignored my Mac developers]. Aaron then went on to present a persistence framework he has just written which could be superior to CoreData in some way and is designed for both the Mac and the iPhone as well as for being simple and fast. To be honest I didn’t quite get how both parts of his talk matched up apart from being about data. If his framework included things like synchronisation and conflict management, I could see how it’d fit into the ‘cloud’ picture but at the moment it seems to do local persistence only.
• The final session was mysteriously titled Cocoa Rumble which one could enter for beforehand. It turned out Scotty drew our names from a hat and assigned one attendee to each speaker, ultimately creating three groups of six people each. Then he put a bunch of ‘Core’ frameworks in the hat, handing one to each group with the task of using 30 minutes to create a presentation making the point why that framework is the framework of the year. The drawn frameworks were CoreText, CoreAudio and CoreAnimation. Let’s say that was a rather uneven choice as in terms of flashy results and ease of use CoreAnimation should be the default winner. While CoreText will neither be known nor explicitly needed by most even if may play an important role for the Mac’s appearance. Similarly CoreAudio is unpleasant to work with and I remember it as painful - most likely for the good reason of the low-latency they try to achieve.

• It turned out I ended up on the CoreAudio group with Rentzsch, Jeff Lamarche (who had recovered his luggage by then!), Drew, Daniel Tull and Daniel Kennett. We were working frantically to whip up a kick-ass presentation:

  

  … with a great slogan CoreAudio is the API of Rock Stars [Alex Rozanski has a good photo of rentzsch presenting that], proving how it kicks ass because it’s essential for iTunes (of course we knew iTunes existed before CoreAudio as Uli was keen to point out, yet I doubt it’s playing a tone on my machine without CoreAudio), which is essential for Podcasts, which are essential for MDN which is essential for NSConference. A great argument I think. Bashing the other APIs was a good idea as well, even though I still think that the slide saying that CoreText is an API for girly men with Zapfino used to illustrate it is an insult both in terms of sexism and to the typeface. Probably another good indicator that having more than 2% female attendees wouldn’t be the worst of ideas.

  Our presentation finished with all of us waving our MacBooks to create a bunch of sinewaves using SkipChecker. I wouldn’t have guessed that this painful excursion into the world of CoreAudio would make it to the ‘big stage’ one day… incredibly dorky, I suppose, but fun.

• And, yeah, needless to say that the CoreAnimation people won: an originally sealed set of WWDC DVDs from 2002 or so. Congratulations! More generally I thought their presentation was fun, but a bit too long. And I was rather disappointed by the CoreText team because their technology totally has the potential to outdo CoreAudio in terms of on-screen sexiness.
• While we were preparing the presentations, people were invited to share their favourite little ‘tricks’ with the audience. Unfortunately we were too busy pondering our own presentation to follow what was going on and the hints were said to be quite helpful. Notes on this didn’t seem to make it to the SubEthaEdit file, so I’m hoping videos will be available one day. — Uh, and someone please tell rentzsch that there is a difference between giving a short hint and a ten minute presentation of one’s pet project…
• With all those sessions ‘done’, the drinking could begin. I happened to speak to the guys from Shiny Frog who are doing the delicious client delibar. As I contributed code to the much more limited delimport application (actually I have a 64bit capable version of it running here already) which creates a backup copy of your delicious bookmarks and adds them to your Spotlight index, it was cool to talk to them. They’ve put an incredible amount of work into their user interface and, unfortunately, had to report that Yahoo ‘upgraded’ delicious’ API to something using OAuth and being horribly complicated. To make things more fun, it seems that Yahoo preferred not to tell anybody about this and randomly allow use of the ‘old’ API for old accounts. To make things even less worthwhile it sounds like the ‘new’ API can’t actually do more than the old one could (with a particular and very bandwidth-intensive shortcoming of the old API being that it won’t let you do requests like send me all changed bookmarks since a given date but always forces you to download all bookmarks, which can amount to a couple of megabytes if you’ve been using delicious for a while, to achieve that).
• Later we had dinner at the ‘nearby’ Horse & Groom pub (Scotty even claimed one could walk there and lived up to that claim) with some local beers and nice pieces of steak. To the delight of the assembled geeks the landlord brought up some little logic games on the height of coins, turning around glasses and toothpicks which kept people busy throughout the evening. I even remember winning a game of ‘table-rugby’ shortly before we left. I must have been 20 years younger and 10000km away when I last did that.

Thanks

Many thanks go to Scotty and Tim for making NSConference happen. Without doubt they put in some great effort there. Let’s see how quickly they recover from NSConference US to switch from ‘I’ll never do this again’ to ‘When can I do this again?’ mode.

Many thanks also to Mike for being my host in Reading.

Further thanks go to Chris Walters who had done the pub reconnaissance and generously offered countless lifts to us and many other participants in his big car while seeming to survive on glasses of Tabasco (with tomato juice) night after night.

• Too much death and too little beef in Mike Lee’s keynote. While making valid points, I think I’m not American enough to really appreciate this ‘emotional’ address, even in a keynote that’s supposed to set the mood.
• Debugging fun with Wolf Rentzsch, pointing out all (?) the ways to poke a non-running and a running application on the Mac. Probably starting out a bit too basic and thus missing out on some of the good stuff which must be out there but which I don’t know. Including respect for the awesome / magic HexFiend, disassembly using otool -tV, the otool postprocessor otx and the various techniques for getting your own code into other applications.
• People’s notetaking of that in SubEthaEdit is awesome and will be useful to find / use the examples shown in the talks. Thanks to Uli Kusterer for setting all that up.
• It’s probably a given: The hotel’s Wifi with a weird login page that seems super-slow on the iPod and loves forcing you to frequently re-enter of all info to use the network was a bit annoying. As were the common losses of signal. On the other hand, I had expected much worse for the catastrophic scenario of well over a hundred people with at least one wirelessly networked device descending on a venue at the same time.
• Dave Dribin on clean code: Good to be reminded of many of the things there. Again, nothing overly non-obvious but it’s always good to be reminded of a clean style and pointing at the easily made mistakes. Not all of his points were equally good and one has the impression he may be teased about his ‘KVO is evil’ stance and singleton hate, which became a bit of a running gag, for a while.
• I was too busy watching the little lunch-time talks to manage to get a dessert, bummer!
• Drew McCormack about data presentation: Goes through many styles and points out how they’re all lists. Points to the core-plot graphing framework project he helps run. Interesting stuff, even though I currently have no use for it. Having a way to draw graphs and do it performantly will be cool. The talk also pointed out the existence of NSCollectionView to me, but it sounded like it’s not better than a table view if you have a really long table.
• Final talk was by Marcus Zarra on CoreAnimation. Interesting but not overly exciting if you’ve used CoreAnimation before, which he has bunch of posts on on his site. I had to laugh when he said most of the code in his demo app was for drawing the path he’s drawing and that he had to program it from a sketch he made. Totally reminded me of my efforts when creating ESCursors.
• Dinner was fine with special kudos to Tim for having gone through the effort of making sure we actually get good wines with it.
• Now if only I could remember the names of all the people I spoke to…
• Notes with photos by Alex Rozanski.
• There seemed to be many iPhone people at the conference and many who are relatively new to Cocoa.
• One thing I find hard when speaking with iPhone people is figuring out how to speak to them. I have a fairly low opinion of most iPhone applications, a sentiment which doesn’t seem too far off the general perception. And creating them probably is where the money is because people with bad taste and money will hire iPhone developers to create them. That’s certainly not my style of doing things and it’s hard to talk about people (after all they seem reasonable and probably don’t think they’re creating the greatest thing in the world when making some junk advertising app) about this topic.
• Of course the missing semicolon in [[NSConference alloc] init] on the smart banners that decorated the stage made people talk. For my part, I welcome our new semicolon-less-C-overlords. Certainly makes things less painful. [I really recommend compiling with LLVM by the way, because its error messages for this stuff are just much more human-comprehensible].

Read on for notes on the second day…

I think the site giving the best results back then was called Audiogalaxy - and has duly been destroyed by capitalism since. As far as I can tell, the focus in file sharing then shifted to services/protocols like Gnutella or aMule. It also seemed to shift from the wonderful world of being able to find just that obscure song from the mix tape your friend gave you a decade ago to a world which focused on providing a gazillion copies of the latest Britney Spears album and shitty quality Star Wars recording from a cinema screen. (Plus porn, of course. I think file sharing clients are the first software in which I understood why ‘childsafe’ features may be useful: pretty much any term you can think of seems to have a kinky double-entendre that can be used for a porn title.)

And not only did the content become lame, the software was even worse. There seemed to be an unwritten rule that file sharing clients need to be horrible to use, sport huge windows full of incomprehensible/useless buttons and be obviously ‘cross platform’ in the worst way possible. And that’s before one mentions the cross-platform horror known as Java which successfully mixes mis-sized GUIs with humongous memory consumption. I was not impressed. It wasn’t fun. It wasn’t useful.

It was a shame because file sharing generally is a good thing. For some reason (giving them the benefit of the doubt I’ll assume that computer and business people are not smart enough to make this FAIL intentionally but that we’re simply seeing technical incompetence here…) file sharing software has always sucked horribly. Try transferring a 10GB video recording to a friend and unless you have a very good network connection as well as a fair bit of technical knowledge, you’ll find this supposedly simple technical task very difficult. Try transferring a 30MB file to a thousand people and you may need to think a bit about your web server’s speed and bandwidth limitations first. It’s a mess, it’s a lot of effort, it’s potentially expensive.

BitTorrent is one of the technological answers to these kinds of problems, I think. It uses file sharing technology to distribute files while avoiding the shenanigans about searching or hosting the actual materials which may be illegal in a serious or less serious way. I’ve been fascinated by that idea for a while, particularly the community aspect, the idea that many people cooperate and give their upload bandwidth, so other people can get a file quickly without needing an expensive server. And then people who have downloaded the file ‘giving back’ by providing the file to others who want it as well later on. It seems like a smart way to solve the problem.

But the software situation isn’t great either. I think the first BitTorrent client I saw was Azureus (apparently called Vuze these days) which I can only describe as a huge slow Java mess. Someone pointed me to the Bits on Wheels client on the Mac for downloading one of those SXSW torrents (another nice idea which might just be impossible/too expensive without torrent technology) and it had a funky (but I guess mostly useless) 3D display of the files transferred. But development of that stopped.

When looking for another client later on, I discovered Transmission. And I was impressed (which, as regular readers will know, is rare) because it’s a refreshingly no-nonsense piece of software. First and foremost it puts no crap between that torrent-file you’ve got and the download starting. It has a simple user interface focusing on the important points and even containing a ‘simplified’ way of displaying things without all the nasty details, making a torrent download look just like a download from the web. I liked it a lot because it did away with the pain and suffering I connected with GUIs for file sharing clients. Even more amazing: Transmission actually is an open source cross-platform project. Unlike many others, however, it does make the effort of using the native GUI technologies for the platform in question, thus enabling themselves to provide a good user experience.

To give something back to the project, I thought I could provide a German localisation. I thought that’d be interesting, both because the project isn’t tiny and also because file sharing is a strange area with a lot of odd terminology which could be a challenge to localise. As I see Transmission as a BitTorrent client for the technically uninclined, I wanted to create a localisation that’s as un-technical as possible. I wanted to avoid odd file sharing terms and try to find reasonable German expressions for what’s going on.

Doing so proved a bit tricky in some places. Both because I had to read up on some of the technical details that hide in the more advanced areas of the application. And because some terms needed a bit of pondering to find a reasonable solution for them. The most visible one of those is the ‘upload’/’download’ pair. It’s really tricky because it seems that it’s considered all right on the Mac platform to simply use the noun ‘Download’ in German these days. However, the same doesn’t seem to be true for ‘Upload’, nor for using ‘download’ as a verb, as that would end up being a rather strange ‘downloaden’. Hence other terms were needed, and I settled for ‘Laden’/’Senden’, the standard terminology Apple use for network transfers. However I wasn’t sure whether the short form of ‘L’ and ‘S’ for those would have been comprehensible.

My German localisation is part of the Transmission since version 1.80. While I checked and double checked everything there may still be some glitches or perhaps ideas how some terms could be localised more appropriately.

While I found it hard to get in touch with the Transmission people (I’m an e-mail person and they seem to be into that IRC thing which I completely fail to ‘get’ - it seems like twitter with the additional downside that you can miss messages and the upside that it worked in the 1980s), I ended up with a reasonably good impression localisation-wise. Most projects’ efforts on localisation seem rather half-assed, particularly in the open source area (hello Sparkle…). There may be downright mistakes or careless changes of localisation keys and typically there is a real lack of comments for the strings used in the .strings files of the localisation which can make it really hard to figure out where the string in question appears and what it will be used for. The comments in Transmission’s .strings, however, files were very complete and helpful and only a few details needed to be tweaked otherwise, making work very smooth.

While trying to figure out a thing or two about GraphViz, some search results told me that OmniGraffle can import the GraphViz file format. OmniGraffle is one of those applications which has earned a rather high reputation in the Mac software world for being a tool that makes it easy to create good looking diagrams. So far I only had a single excuse to actually try and use OmniGraffle and this seemed like a good opportunity for digging in a bit more deeply.

Two things made OmniGraffle stand out in my opinion: First, the fact that it makes it easy to create reasonable diagrams by defaulting to all sorts of smart ‘magnetic’ behaviour when joining up graphs and thus letting you focus on the the graph you want to draw rather than forcing you to put all your attention towards getting the lines in it ‘just right’. Second, the fact that OmniGraffle is also tuned for a reasonable amount of ‘pretty’. Not the bling-bling style ‘pretty’ one would find in magazines, but the pretty of having shadows where you need them.

I was quite surprised to learn that OmniGraffle reads GraphViz files and contains GraphViz’ automatic layout algorithms as I consider both these approaches to graphing as somewhat orthogonal. It’s all the better that one application tries to handle both. Trying to use the ‘best of both worlds’ I could turn a mess of a graph into something reasonably looking.

What’s particularly nice about OmniGraffle is that it doesn’t just import the GraphViz files but it also lets you edit them in the application, re-applying the GraphViz algorithms as you go. Particularly when using the ‘force-based’ layout mode it gives you a few extra abilities to adjust line lengths. These can be used to tweak the graph a little.

While this is already a great improvement on ‘pure’ GraphViz, particularly once you take into account in the better looks OmniGraffle gives your graphs as well, it still leaves plenty of room for improvement. One issue is that you may have machine-generated GraphViz files. You can easily add a few nodes to those. But OmniGraffle cannot ‘update’ its current graph based on an updated GraphViz file. While this seems quite natural in the GraphViz view of things, it means that you must be really really really sure your graph is final before starting to make it pretty. Of course that’s not how things work and you may end up having to do things several times. Given how dynamic the layout of thes graphs is, it’s very likely that you will not be able to reproduce your previous work when doing this.

The next problem (again coming from GraphViz, I suppose) is that it’s really hard to ‘pin down’ objects. Sometimes you really need some node to be right in the middle or you may want to move one node up a centimetre to make its edges not cross other nodes in a bad way. It’d be really handy to just fix a node at its desired location for that.

The same goes for the order of some nodes grouped around another one. It seems like the GraphViz algorithm just finds a local optimum for the layout. Meaning that other, much better layouts may exist which are just ‘out of reach’. I have often seen examples for this where a number of nodes are grouped around bigger nodes and a change of the order of those nodes would have given a much better layout with less edge-crossings. Unfortunately this kind of rearranging is mostly impossible (I have a theory that one may be able to adjust it by rearranging the lines in the GraphViz file, but that’s not really feasible if said file is automatically generated).

A further limitation of OmniGraffle is that the ranges for its adjustment sliders seem to be wrong as soon as you’re working with graphs that aren’t tiny. The usable part of the ‘repulsion’ slider seems to be in the first 5% of its range, i.e. pretty much impossible to control. That’s particularly problematic as OmniGraffle can end up stalling for a long time when the setting is picked too large (as I assume the layout process is started with rather unreasonable parameters then).

Finally, OmniGraffle does not support the full range of GraphViz options (say node shapes or images in the nodes as used in my UTI graph), meaning that it’s difficult to communicate layout intent through your GraphViz file from the script creating it. A workaround for that is setting different colours and sizes for the element and using OmniGraffle’s cool selection features to select all objects with the same style.

My conclusion is that the automatic layout / GraphViz support makes OmniGraffle a very interesting tool for creating graphs. I am particularly surprised that they managed (dared to attempt) including some GraphViz algorithms into their application. But now that I’ve seen this I want more. As usual, none of what I want will be particularly easy to implement but it improve graph making.

Let me close with an illustration of what can be achieved. Taking a moderately elaborate GraphViz file which already makes an attempt to style things a little one could get a result like this:

Tinkering a with OmniGraffle on this can clarify the result quite a bit:

Thus, in theory, GraphViz is a fantastic tool to magically create meaningful graphs from simple relations between objects. Being open source and able to export into many file formats from bitmaps to PDF to SVG makes it also score high in buzzword bingo. There’s also a pretty abandoned looking, Design Award winning and not exactly easy to use graphical Mac application for the dot tool as well as a cool looking but presumably useless iPhone version for the same people.

There are, however, problems with GraphViz. One of them is documentation. As is par for the course for open source software, there is a formal specification for the language used and an alphabetical list of all the parameters you can use. Of course that’s pretty close to useless as it totally hides the fact that writing a dot file is quite easy. And once you figured that out, by looking at the pages of examples, it still remains frustrating to use the software because not all of the options work in all of the tools and generally the outcomes seem quite random in the sense that it often seems gratuitously hard to figure out or achieve simple graphical effects.

Particularly so, once you start creating slightly complex graphs. Positioning nodes ‘just right’ in those is pretty hard because the positions one node potentially affects all others. This makes it pretty much impossible to turn a graph which may represent the structure correctly into a graph that represents the structure correctly and looks good. Where ‘looking good’ also means that the graph can become clearer as a consequence of that because you have fewer crossing lines or the order of the nodes is more adequate for your current application. To a certain extent you can tinker with some of these aspects, but in my experience it quickly ends up being a lot of effort while still not giving the results I want.

In addition GraphViz, in true Unix style, is a one-shot-wonder - meaning that it simply processes the file you throw at it without any knowledge of previous runs. Hence even adding a single node to the graph can significantly change the layout the algorithm comes up with. This makes it pretty futile to try and ‘optimise’ the graph in any way unless you are 100% sure its nodes and edges will not change. It also keeps you from doing something like a development of the graph over time as adding a node will quite likely create a discrete jump in the graph rather than lead to a continuous change. As far as I understand the readmes of GraphViz, the way it optimises graphs actually is continuous in nature, so it’s likely that all the necessary algorithms are pretty much in place already and a shame that no interface to them is exposed.

Finally, there is the difficulty of the middle ground. Looking through the GraphViz examples page you will find mostly graphs which are small or structurally simple. Those tend to look all right. There are also a few examples which are very large and complex and in which the graph is seen as a global picture rather than revealing the details of its nodes. Of course the graphs I wanted to create are in the middle ground. They are too big and complex to fit in the first category but I am still interested in the detail information.

An example for many of these issues may be my UTI graph:

Once you start looking at it in detail to learn the exact information it contains, you will start noticing how the layout of the graph is far from perfect in many places. Improving on that seems quite hard. And getting everything ‘just right’ could very much end up being impossible.

My idea would be that Safari lets you ‘share’ the pages you are currently viewing and those bookmarks then appear in the iPod’s Safari via Bonjour. But things don’t work this way. As Safari on the Mac lacks such a sharing feature, the URLs of the currently open pages have to be advertised by an additional application. As Safari on the iPod lacks Bonjour support, you can’t possibly see any advertised services in the application itself anyway (and implementing the bookmark sharing in such a way would require a bit of cleverness and background work because the standard advertising of web servers via Bonjour only works for services with addresses on your own machine).

So the hackish workaround is the following: You launch the Bookmark Advertiser application, it grabs the addresses of the web pages you are currently viewing in Safari and advertises them via Bonjour as a service of type ‘urlbookmark’. Flame then just happens to recognise that service type and display it as an openable service which will display the web page in Safari on the iPod.

This is very lightweight, only supports Safari, doesn’t automatically refresh and fails for URLs which are too long. Yet it does the trick for the applications I had in mind.

The application does the simple job of displaying all the Bonjour Services on your network. Either grouped by Server or by Service Type. You can look at the Services’ details and open those for which you have matching applications installed. Interestingly Mobile Safari can handle FTP (for small values of ‘handle’) and unfortunately the VNC clients I looked at don’t seem to register protocol handlers. If the iPhone software ‘ecosystem’ didn’t suck so badly, one could even send the authors of those applications an e-mail and let them know.

‘Naturally’ the application works on Wi-Fi only. It does its job in English, German and French (many thanks to Ronald, once again) and we hope it does it reasonably well. Let us know if it doesn’t; There’s a feedback link in the about box.

While it’s nice to see some software you contributed to out in the public, I have to say that the whole App-store crap makes it feel dirty. It’s essentially supporting the bad guys.

Be sure to also look at the Bookmark Advertiser Mac application which advertises your open Safari pages via Bonjour and which Flame supports.