• 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.

It’s rare that you run into such features. But when you do, you can breifly smile during the agony of machine usage. I had such an experience a while ago when using Sandvox which I use for a bunch of photo websites with plenty of photos in them. And what would the absolute nightmare in this situation be? Right: The application not being able to locate the photos I am using in the site.

And exactly that happened. I have no idea why this happened as Sandvox seems to use proper Mac aliases internally which take into account both the path and file number, but it did happen. After having been through the hell of manually having to tell iTunes about the location of dozens of song files (which had not been moved in any way) at some stage, you can imagine how I sighed when a sheet came up informing me that hundreds of images could not be found after opening a photo site in Sandvox.

After the sighing and a bit of cursing I set off to serve the software once more. But after locating the first file a good thing happened: Sandvox used the location I had pointed it to for that file to check whether it could find the remaining files at the same location. And it could. Which made my preventive cursing somewhat superfluous as the the application had just solved the problem for me.

While I imagine that the situations in which this code is needed are quite rare, its existence turned a potential disaster into a good experience - that of just having escaped doing a repetitive perfectly automatable task which programmers so frequently love to let their users do.

Bling

The more critical points about Safari 4 are the changes to its user interface though. Some of them, like ‘Top Sites’ are vacuous pieces of crap (enquire within to make me argue that it’s visual overload, much less effective than typing the first letter of the address and may waste your time by reminding you of the existence of websites you shouldn’t visit so often), but unlike many other types of crap Apple introduced in the past years, these can be easily and turned off and ignored without any problem.

Cover Flow and lost opportunities

The same uselessness statement could me made about Cover Flow bookmarks, I suppose, but to be honest I hardly ever use my bookmarks at all, so to me it seems mainly a waste of effort (and judging from what I heard others say, a rather unreliable one at that as Safari doesn’t seem to be good at actually fetching those images. Personally I also consider that feature a missed opportunity. Not only did Apple decide to litter our hard drives with hundreds of megabytes of web page screenshots (opening the folder of which may be a good way to visualise the privacy implications of web bugs - particularly Google), they also missed out on the opportunity to create a good solution for this that offers search and offline access as well.

To me the current implementation of Safari seems ridiculous. For each page you visit it stores a reference in your browsing history, it saves a file with the page’s text for Spotlight searches and it saves a screenshot of the page for its Cover Flow bookmarks. Yet, there seems to be no way to actually look at the screenshots Safari stores for you. They are not displayed by Quick Look when invoked on browsing history items and they are neither used to give you an impression of one of those history items when you are offline. To me, saving a web archive with the actual page in it (plus a screenshot, possibly, for performance) would seem much more logical. And it would make those situations when you discover a page you visited in a Spotlight search while you don’t have internet access much less frustrating.

Tabs

Another big debate among browser users was Apple’s re-location of the tab bar into the window’s title bar which existed in some beta versions of Safari 4. While I could appreciate the space savings of that, I thought it was more irritating than useful in the end. Simply because it made the window’s title bar look extremely busy and made things hard to click. In addition, that idea also ruined other subtle display methods in Safari: The unique lock icon location for encrypted sites and the full window width page title. Without the latter it’s quite hard to see the page’s name at a glance.

Surprisingly Apple listened to the loads of the feedback they must have received on this issue and the released version of the browser come with traditional style tabs. Those aren’t perfect either, but apparently they’re the best you can do when working with the ‘tab’ metaphor. In particular, they still suffer from horizontal overflow problems, as tabs to everywhere. And Apple’s insistence on only giving you an overflow chevron with no way to actually move between the tabs doesn’t make that any better. In fact, they added some fancy background colouring to the menu coming out of the overflow chevron, presumably to give you a better idea about the context you’re looking at. But I am not really sure it helps me figure out anything.

The following two screenshots are an example of that. I opened six tabs in a narrow Safari window which could only fit four of them in. In the beginning, with the fourth tab selected, it looked like this:

This makes sense to me, assuming that the light colour indicates the visible tabs and the dark colour indicates the hidden tabs. Then I paniced and switched to the last tab:

Now, with the same window width and tab arrangement, seeing three of both the light and the dark items suggests that my initial idea about the meaning of the colours was wrong. I guess I’ll just have to avoid looking at this. Tabs aren’t good for you anyway.

Progress

Another contentious issue was that of the progress indicator. Safari used to have a progress indicator which coloured in the address field according to the page’s progress at being loaded. While a progress indicator that gives quantitative information may be extremely problematic on a conceptual level for loading web pages - you have to display some progress immediately after the request is sent to let the user know something is happening but you have no clue at that stage how long it will take to complete everything - I think that Safari used to fake it reasonably well.

Nobody wants to read precise information from the progress indicator. Usually people just want to see that (a) their request is being processed and that (b) some progress is happening. That is, you want a bit of the progress bar to appear as soon as a click is made and then you wa old nt the progress bar to move at a reasonable speed as long as data are coming in. That way a stalled progress indicator may give you a hint that something isn’t working properly and that a reload may be in order. Particularly in low-bandwidth situations, which web sites and browsers don’t seem to be particularly good with, this is a useful feature.

Apple decided to remove the progress indicator in the betas, replacing it by a tiny spinning progress indicator at the very right hand side of the address bar in beta versions. This was very irritating as the visual impact of that tiny graphic was so low that you always had to consciously look at that tiny bit of screen space to see whether or not the progress indicator appeared. Definitely a change for worse, big enough to penetrate Apple’s bug reporters (perhaps people at Apple are even using Safari themselves…).

Their ‘solution’ to the problem was to not just display the progress indicator but provide an easily visible dark background around it which you’ll immediately notice without having to make an effort to look for it. That certainly solves the biggest problem with the new progress indicator seen in the betas. The other problem, however, of seeing whether there is actual progress in the file transfers or whether they have stalled, remains.

I’d certainly like to read the reasoning that went into putting engineering resources into making the progress indicator worse than it was before. Seems illogical to me, particularly as Apple missed out on what looks like the only potential advantage of an indeterminate progress indicator to me: The ability to let it spin when further resources are loaded after the page finished loading, like many of those fancy web 2 pages like to do.

Reload button

Another problem with Safari 4 is that Apple moved the Reload button to the right hand side of the address bar. Web browsers were born with the reload button at the left hand side of the window. More importantly, they were born with the Reload button close to the Back and Forward buttons, which not only makes sense but also keeps distances short when navigating with the mouse. Internet Explorer 7 broke that tradition and its wrongly placed Reload buttons remains the second most annoying thing about it (the first item in the list, naturally, being the rendering mistakes which make me need the reload button and non-trivially test in that browser in the first place).

Safari is keen to follow in Internet Explorer 7’s steps in this respect and moves its combined Reload and Stop button far away from the other navigation buttons. That irriates the hell out of me - and apparently a few other people as well. As there seems to be no point in holding one’s breath (and Apple’s software regime on the Mac hasn’t reached iPhone level fascism yet), a little bit of clicking yielded this:

It’s not as good as the Safari 3 original as it doesn’t reflect the state change from Stop to Reload but it may be a reasonable approximation until somebody discovers a better fix. You can grab a copy of the files here and use them at your own risk.

Beneath the hood

It seems that Safari 4 will bring quite a few improvements under the hood. Faster JavaScript, fancy new CSS effects, local storage and improved scores on random standards tests. I suppose that those are good things. Things that are worth implementing and refining early so - for a change - browsers are ready once the web designers get their act together.

Those changes are as unnoticeable as they are amazing. None of the sites I am using seems to behave differently today in Safari 4b than it behaved last week in Safari 3. Which probably is a good thing or simply proves that I just don’t surf enough.

And who’s going to bitch about such technicalities anyway?

Zooming

Web browsers could zoom into pages from day one. Pressing ⌘-+ simply increased the base font size, thus making text larger and potentially more legible. This has always been problematic to a certain extent as web designs which use images have a tendency to break down after a step or two of this: The graphics are included as fixed size bitmaps and (due to both bad / lazy designers and the limitations of HTML / CSS) they don’t scale along with the text. Hence, the font sizes may end up being blown out of proportion to the size of the decorative banner ads or so…

At some stage the strategy of re-interpreting web page zooming as a zoom into the page - increasing the size of everything on the page proportionally - was introduced (many years ago by Opera, I think). This strategy neatly avoids the problem of layouts breaking and Safari 4b both implements it and uses it by default. The setting for it are easily accessible in the View Menu.

Personally I prefer ‘old-school’ HTML resizing. Both because I’m an old fart and because I prefer narrow browser windows and despise web ‘designers’ who think they should have a say about the size and shape of my browser window. Having the new resizing option feels like it gives more power to them as increasing a page’s text size will likely blow said page out of the window size I want to use.

Visual Bookmarks: Cover Flow

Safari 4b1 offers two ways of visualising bookmarks. The first is having a Cover Flow view mode when browsing bookmarks. I think this is a ‘nice’ idea because it’s sometimes easier to recognise pages visually than remembering their name. On the other hand: When did you last browse your bookmarks?

I realised I never browse my bookmarks. The links I need frequently are in my bookmarks bar and I know where they are because I use them frequently. The other links are in my bookmarks for (a) sentimental value, (b) because I forgot to delete them or (c) autocompletion.

Autocompletion is important. Even more so if you have a device with a crappy keyboard like an iPod touch or an iPhone. Once you have a link in your bookmarks, it’s much more accessible on these devices. Hence bookmarks need to be there, but they hardly ever need to be seen.

In fact I used these graphical bookmarks as an opportunity to quickly go through all of them. The screenshots usually let you see easily when a bookmark has stopped working and points to an error page. There were plenty of such broken bookmarks in my collection - particularly on music and computer related sites. Presumably because they are run by the most technically illiterate people. Even more embarrassingly, most of the music sites still exist, just the links broke because the moron who ‘designed’ the Flash-atrocity site in 2004 thought entering the domain name should immediately redirect you to the ‘/index.php’ path while the douchebag who re-‘designed’ the even worse Flash+Web-2-atrocity site in 2007 considered a redirect to ‘/index.asp’ more appropriate. Both being morons of course meant that nobody thought about creating redirects beforehand and nobody checks the 404 logs either. Tada, job well done and ‘designer’ paid with the money from my CDs! And as Safari - optimistically - doesn’t show you the URL you are about to bookmar thus not giving you the opportunity to scrutinise and fix it easily, you end up having that worthless crap in your bookmarks.

Visual Bookmarks: Top Sites

The other 3D novelty in Safari 4b1 is the Top Sites view. It displays a gratuitously 3D view of thumbnails of the pages Safari considers your favourite ones:

It seems that Apple still love the feature at this stage as they added a non-removable button for accessing it (which for some incomprehensible reason works differently from the Bookmarks button right next to it) to Safari’s Bookmarks Bar and make Safari open any new tab or window displaying it despite you having told Safari that you always want it to open new tabs and windows with a ‘blank’ page years ago. Let’s say I was not impressed. And even less so was my boss when I wanted to ‘quickly look something up on the web’ and the screen seen above appeared…

Ah well, I am not sure I’ll like this feature. It needs to download loads of stuff in the background through a helper process, it seems impossible to add specific pages to it at the moment and it furthermore includes the horrifying trend of being so poorly designed that it needs an ‘Edit’ button (this may be excusable on a simplistic device like the iPod touch or iPhone on which editing will be the exception and interaction is coarse but I find this just embarrassing in everyday editing applications like Safari or the Address Book, this being the 21st century and all). So, no, I’m not convinced. But if I could remove the button for it from my Bookmarks Bar, it would just be some useless code in my Safari binary rather than a constant annoyance.

Comment: Archiving

Let me take a moment to comment on the features above. Obviously the developments for Safari 4 established quite a bit of infrastructure for saving and updating thumbnail graphics of the pages you view. To me that seems to be solving the wrong problem and at best an intermediate performance-enhancing step one may need to do when doing The Right Thing™.

At the moment Safari saves three kinds of web page related items: your bookmarks, a log of the pages you recently visited and thumbnail images. Both the bookmarks and the log of the pages you visited are indexed by Spotlight and thus somewhat accessible. Unfortunately neither of these is Quick Look enabled, meaning that you will know something in the page you visited yesterday contains the text you are interested in, but you cannot immediately access it ‘see’ the page in question.

It seems that the ‘right’ thing would be storing proper webarchives of the visited pages. That may be a bit more effort than the current approach but it would have the advantage that even web history items would not only be findable via Spotlight - they’d also be viewable right away, even without an internet connection.

I’ve been in that situation a number of times and I can tell you the following: it’s nice that you can search the content of your web browsing history using Spotlight. But finding something in there while you don’t have an internet connection is incredibly frustrating - much more so than not finding it at all. Of course only unworthy sub-humans will come into situations without internet access in Apple’s mindset, but I take the liberty of thinking it’s something worth keeping in mind - even more so as it enables you to see the page the way it looked yesterday when you thought it was interesting, an aspect that can play a role when having in mind the large number of blog-style sites with frequently changing content we have today.

Address Field

Safari 4b1 comes with a redesigned address field. It appears they’re generously stealing from the improvements Firefox users have been enjoying for a while there. And it’s a welcome change. Safari’s URL autocompletion becomes much more competent by this, offering a somewhat reasonably ordered selection of completions from your bookmarks and history items. I welcome these improvements.

This isn’t quite perfect yet. One thing they still haven’t fixed is Safari’s unwillingness to invoke autocompletion after hitting the backspace key: Say you want to go to Google and accidentally type ‘gog’, then you realise you missed an ‘o’ and hit the backspace key. In all likelyhood ‘go’ would autocomplete to ‘google.com’ already, so Safari should try that. But it doesn’t. Seems like a trivial oversight to me and I couldn’t yet figure out why Safari doesn’t do it.

Another, even more significant omission is that the address field only completes addresses. I totally expect it to complete bookmark names as well.

But that isn’t all there is to Safari’s new address field. It comes with the Add Bookmark +-button affixed to its left side. Yes, that does look neat and may be another hat-tip to Firefox and its even more elegant / lazy solution to bookmarking, but it annoys the hell out of people like myself who don’t want a button for creating bookmarks in their toolbar. In fact, I prefer thinking about said ‘toolbar’ as the ‘navigation’ bar, and creating bookmarks has nothing to do with navigation, so it doesn’t appear there. I am perfectly capable of using a menu, hitting ⌘-D or using drag and drop (for which spring loaded elements in the Bookmarks Bar would have been nice) when I want to create a new bookmark.

Going on, on the right hand side of the location field, we now see the Cancel / Reload button in there. It doesn’t really look like a button. but it looks like what you see on the iPod. That’s rubbish. 15 years of web browsing taught my muscle memory where a reload button is supposed to be. And that location is left of the address field and not inside it on the right. In fact I still find the location of the reload button the single most irritating ‘feature’ of IE7 whenever having descend into those fields.

Whenever you visit a site whose connection isn’t only encrypted but also deemed particularly secure by Safari, the right hand side of the address field will also host the name of the SSL-certificate holder. Potentially shortened, with a funky fadeout and - strangely far away from the lock icon which remains in the page title. This is no dealbreaker but I find it a bit irritating. Wouldn’t the lock icon be better accommodated next to the address and the certificate owner’s name?

Another point is progress indication. Safari used to indicate its progress of loading a page by colouring in the address field with a blue bar. That scheme of progress indication was pretty much a sham because with a browser’s progress indicator you need ‘instant gratification’ to assure users the click they just made has been registered but you have no clue whatsoever how long the page will take to load at that moment. Hence, at that point, you have to display some amount of progress which is completely independent of what’s going on for real.

From that point of view, the indeterminate ‘spinning wheel’ progress indicator used by Safari 4b1 is technically more correct. But it’s simply too hard to see. That large and blue bit of progress indicator appearing on the screen was very obvious, a small and grey progress indicator appearing at the far end of the address field is pretty much invisible. You - or at least I - don’t just see it but have to consciously look for it, which is by far too much effort for me.

Arguments have been made that people are more hesitant to actually use a page before loading has ‘completed’ and that the less visible progress indicator encourages them to use the page before that. That’s an interesting point, but I can’t remember the last time Apple cared for pensioners or people with slow internet connections…

Finding

Safari 4b1’s Find field has been pimped as well. Using Google’s instant search completion recommendations you can now be even lazier and share your partial thoughts with Google as well. It’s a nice convenience. The menu popping up while you type in the Find field also contains a ‘Find’ command which will search for the typed text in the current page.

As this command is at the very far end of the menu, 20 items in or so, I find it highly inaccessible, particularly when navigating with the keyboard, which I am likely to do as I have just been typing in a search term. This needs extra fine tuning, say in the form of making the up-arrow go to the last menu item when you’re in the find field or highlighting the matches for the search term on the current page (which implies other problems, though).

Strangely, the popup menu that goes with the (empty) Find field lacks both a Clear Recent Searches command and that plain Find command which is attached to the bottom of the popup menu while you are typing. Those aspects could be more friendly, useful and consistent.

Tabs

Let’s move on to the big elephant in the web browser. Safari 4b1 comes with twisted tabs. Instead of being just above the page, the tabs live in the browser window’s title bar now. That’s just odd but my current stance is to give it a few days to see how much of the ‘odd’ impression comes from the look being new and differing from the standard Mac GUI (which of course itself is a bad thing in my book).

One thing this change has going for it is that it tries to be more logical. Lukas Mathis discusses the hierarchy of the browser UI in detail, making that point clear (and explaining why Coda keeps feeling odd even after long usage). So, in the Safari 4b1 image of the world, each tab is a browser and comes with its own address bar and Google field inside it (at the moment these fields’ behaviours are slightly different when you change tabs while typing in there, the Google field lovingly carries whatever you typed to the new tab, while the address field doesn’t do that) which makes more sense conceptually.

On the other hand you now have a Bookmarks Bar conceptually ‘within’ each tab and it can contain folders which offer to open all their items in tabs. That ends up being a bit mind boggling or even destructive as you might expect that command to just replace the current tab by many new tabs and may be shocked that it destroyed the content you had in other tabs. Perhaps this will be improved as further builds emerge, but I see a conceptual problem here: you want a Bookmarks Bar, you want it close to the browser display, yet it doesn’t really belong inside each tab but it belongs to the whole application. Tricky one. To me the only logical conclusion seems to be to not use the Bookmarks Bar at all and hope that URL autocompletion will fit the bill. That would solve the problem with the Top Sites icon, save vertical space and get the browsing done nonetheless: Win-win-win.

After discussing things somewhat neutrally so far, let’s get to the bile. Those in-titlebar tabs just irritate the hell out of me. I assume that Apple will come up with better close and move icons for them, and the web has been full of (correct) remarks on how irritating and unclear the tabbed title bar’s behaviour is: what will come to the front when I click? the window? the tab? Where can I click to move the window? Where can I click to move a tab? Can I recognise a window as a window among other windows of the OS? To me neither of these questions has a clear or satisfactory answer.

I guess getting used to them might improve that situation a little and Apple improving the design a bit by using better icons and colours (e.g. currently I simply don’t see at all that there are tabs when only two are open as there is so much blank space in the title bar that I don’t perceive the window as tabbed) may fix things a bit more. But I’d be cautious here: There’s a reason why all windows should look and work the same. These Safari windows don’t and that makes them difficult to use.

However, the argument that can be made here is vertical space. On today’s wide computer screens we have horizontal space without end but we can only read 80 characters in a row in that direction. Which makes the vertical space much more precious when it comes to reading as any scrolling action is an extra effort. And from that point of view I can appreciate the effort, even though I am not convinced the space savings are great enough to justify all those strange visuals in the Safari tabs.

Vertical

As the preciousness of vertical space is one of my favourite topics, let’s make a rest here and take this a bit further. Apple saved some space by unifying the window’s title bar with the Tab Bar and I already eliminated the Bookmarks Bar for good a few paragraphs ago. So what’s left? The address field, a.k.a. the Toolbar in Apple’s terminology. That bar takes up further vertical space and is not used most of the time as only the back button is needed regularly.

Indeed, Safari can hide the address field and you can temporarily unhide it using ⌘-L. You can enter an URL then and after hitting return, the bar will be hidden again. That’s quite efficient, leaves you with a clear screen and in case you do a fair bit of your browser navigation by keyboard, this looks like a feasibly option which maximises the browsing space at first.

Unfortunately Safari’s implementation of the auto-hiding is somewhat buggy and after a while of browsing and URL editing the address field will cease being hidden and become permanently visible again. Hence such a browsing strategy never really works out in Safari as it existed so far (and Apple’s stupid non-A-Z keyboard equivalents for those commands make trying to hide / unhide the ‘bars’ by keyboard equivalents an exercise in frustration).

In my opinion it’d be cool if Safari could just show the most relevant buttons on the side of the window - as horizontal space is cheap, that’d be revolutionarily cool and useful. - Uh, wait, I may just be a closet-fan of IE5/Mac:

Fin

OK, that’s it. Safari 4b1 is a bigger step UI-wise than I would have expected. Yet, many of its changes seem gimmicky and not fully thought through. Be it for offline-viewing of my surfing history or for the fact that they tried to nick the best browser features left and right without visibly demonstrating that they’re also convinced by the underlying ideas (say, Google Chrome’s multi-process architecture is completely missing).

Even though Apple is becoming quite Microsoftish in the way that they ship WebKit with their OS and you practically can’t remove it from the machine without breaking loads of things, Safari remains just a browser. It’s a µ between it or Mozilla’s or Google’s or Opera’s browsers and switching is not a big deal if one starts disliking one’s current browser. Let’s see where this takes us.

Safari 4 has been released since. Why not read the post on it and on working around its shortcomings as well?