WWDC 2012 – Day 4 Impressions

By the forth day I found a certain sorrow creep into my consciousness. Only one more day to go after this one I kept thinking. And even more I am beating up myself not having heeded my own advice: prepare better for the labs. There are a couple of things that I found are beneficial when going to the labs, so I want to write them up here so that I might keep them in mind.

Bashing the Design

Right after the building opened at 8 am we queued for a slot on a design lab. Those are incredibly valuable and I wanted my app iWoman to be looked at by an expert designer. There were some very hard truths that he shared with us, as well as some really nice words that he had for it.

Those Apple Designers are emotional people (an occupational hazard) and will hit you without holding back if they hat something. At the same time they also will give compliments on items that they really like.  Most of the problems he pointed out I am already aware of, as the current 3 screen interface is a bad workaround.

I took good notes and as time permits I hope to be restructuring the app’s UI as per the given specifications. There is great potential in this app and it performs a valuable function. The point of these design reviews is that you can tap into the first hand experience of some app design experts that would cost you orders of magnitude more in real life.

Laborious

Most of my time today I spend in the labs, most of the time talking to guys with questions revolving around CoreText and some image decompression performance. Did you know that all the images get decompressed in software without any hardware acceleration? Neither did I. The only way to get hardware acceleration in iOS 5 is to use CoreImage. This might or might not change in iOS 6.

I found that several factors contribute to a successful labs experience:

• have your Radars handy that you filed for a certain subject. I had one issue where my Radar had been closed as a duplicate where the actual reason for the bug was a slightly different one than I had thought. The Apple Engineer can whip out his notebook, fire up their Radar client and tell you exactly what the problem was and in which iOS version it was fixed.
• have sample projects with you and building. It is frustrating when you want to walk through your code with the guy but are not able to get it running because earlier to had updated your development environment with a new OS X and Xcode version.
• I personally found it also very useful to be able to show the research I had done on certain issues and then had blogged about it. This kind of information structuring and documentation provides far greater value than you can provide in a Radar which is text only with a few attachments.
• Few Apple engineers are willing to share contact details with you and most will insist in limiting your interactions to the lab. For some that is because they feel they have enough friends, or might be too old to make new ones. I found however some rare individuals who – if they like you and if they feel that interacting with you benefits them in their job – are willing to give you their business card. Especially so if you can give them an intriguing challenge that is directly related to their tasks. It almost never pays to be pushy and hunt for these cards like trophies. But being courteous and letting them feel a bit of the admiration you have for their work goes a long way.
• Collect interesting topics throughout the year that you don’t quite understand. This way you have sufficient material to go through at the next WWDC.
• In some distant past Apple would release a BETA SDK before WWDC and this would allow attendees to have collected lots of questions. The recent WWDCs are a bad departure of this strategy. Currently the only way to formulate good questions is to write down the questions that pop up while watching talks covering new technologies.

I only visited 2 talks today, in line of what I had written earlier: you get the talks on video, but you get no chance for quality time with Apple Engineers.

I vowed to myself that I will file more and better Radars in the coming year. Radars are the currency that Apple Engineers deal in. The more Radars related to a given problem or feature request, the higher it will rank in the Radar poker that must be going on in Cupertino. I’ve heard of issues that where deliberately not addressed before a release if they didn’t have a high enough number of Radars filed against them.

The other thing is to make a sample app to demonstrate the problem when filing a Radar. There are some things where this is not possible, for example if you are requesting a new feature. But I’ve gotten so good at making Radars that often my bugs are really bugs (as opposed to human error, committed by myself) and then I am getting the famous request for sample project instead of notice that a bug is a duplicate of an earlier one.

No Bash, Thanks!

I don’t like loud environments and to stand around with a beer in hand. Apple always does a Beer Bash at the Yerba Buena courtyard on Thursdays. Guess what, loud music, standing masses of people and lots of hands filled with beer. So the following is the only bash I went to:

Fortunately somebody who didn’t get a WWDC ticket asked for company and so we (group of 5) went to Mel’s diner, having a very enjoyable dinner. I didn’t miss the official bash even once.

PS: Stump the Experts

Besides of the Beer Bash there is another event that I had forgotten to report about: Stump the Experts. The idea of this gameshow type evening event was in the past for audience members writing down some questions and very large team of Apple people would try to find the answer. If you stumped them then you’ll get a T-Shirt.

I was pretty sure that the questions I had entered would be a tough nut to crack. But it didn’t get to the question being asked. And neither did the questions of anybody else. This was a major letdown, I would have expected to see at least a couple of questions enlighten us. Instead they had prepared a so called “Lightnig Round” which always paired up a member of the audience with an Apple engineer.

The only bad thing though was, there was so much unnecessary discussion going on that nobody got a chance to ask their – no doubt – brilliant questions.

Categories: Apple