I was floored. For however brief a second you can see it in the latest iPhone commercial titled ‘Read‘ or the one that featues the sweet book app Classics (also from tap tap tap). The Babelingo icon shows up at the very begining of the commercial as the hand swipes through the second screen of iPhone apps.

Update

Babelingo also makes a brief cameo appearance in the commercials ‘Fix’ and ‘Check’.

“However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software.”

Since I have been mainly focusing on iPhone development for the past few months my posts of Cocoa related development have fallen off. Now that it appears that we can write about released portions of the iPhone SDK I hope to be writing more about Cocoa Touch and of course Cocoa. I truly hope that the lifting of the NDA will help to build the iPhone developer community along a path parallel to that of the Mac developer community. I think that a golden opportunity has been missed to create the same sort of Mac developer goodwill and attitude in the iPhone developer community because of the NDA. Hopefully, now that developers are free to discuss the platform a rich and vibrant developer community will form with the same dedication to helping each other out.

I have always promoted open communication and discussion and I am no stranger to feedback. Yet, the one-way, anonymous, and often eviscerating nature of AppStore reviews shut down open communication and further degrade any sense of community. Both positive, negative, and often misguided reviews suffer from this affliction. I guess I could chalk it up to human nature in an anonymous environment, competitor “App Rolling”, or even immaturity. But, I think the system itself could be tweaked in order to increase the quality of reviews without compromising users ability to express themselves.

First, identify users in the reviews that have purchased the product from those who have not. I don’t necessarily agree with the often bandied about idea of blocking out anyone who has not purchased a product. Users may see a feature that they need or some interface peculiarity that they would like resolved prior to purchasing. While the best way to communicate this type of information is to contact a products support team directly folks seem reluctant to do so, whether for time and effort of for other reasons. Clearly identifying users who have purchased a product from those who have not would allow review readers to mentally place a weighting on the validity of a review. All of the information is in the system to make something like this work it just needs to be made a priority.

Second, make reviews semi-anonymous. Allow the public facing nickname of a review to stay in place and remain anonymous. However, give access to reviewer email addresses to the owner of a product. In this way, a developer can directly encourage or rebut reviews by directly communicating with the reviewer. Alternatively, in order to address privacy concerns in this area a form could be enabled for developers which would send an email or message to a reviewer by keeping their direct contact info private.

Finally, encourage reviews to be revisited from time-to-time. This could be handled in several ways from deleting old reviews to notifying a reviewer when a new version of an app has been released. In addition, reviews could be removed, hidden, or the user notified when a certain threshold of ‘No’ responses has been obtained to the “Was this review helpful?” question. Currently it seems that a review made in the AppStore is immortal but even bad credit will roll off of a credit report in seven years.

As a developer I like to communicate directly with my users as anyone who has emailed Babelingo’s support well knows. A lot of that communication can and does happen via email and a products blog. However, AppStore reviews are by far the most direct and most read form of product communication. Software is not like most songs or movies. The best stuff comes from community involvement by feeding back constructively into the work itself. The AppStore review system short-circuits the needed feedback loop by being both anonymous and one-way. While the list of improvements that I’ve outlined here is by no means exhaustive I think it would provide a good start at helping us all to both create and purchase quality software on the AppStore.

This year for the keynote I stepped into line outside of Moscone at 5:30 am. As fortune or fate would have it I was just barely ahead of the same place in line last year when I had arrived at around 7:00 am. So, maybe that could be used as some sort of judgment on the size and enthusiasm of the crowd this year.

Why get in line so early and would I do that again? Yep, I think I would. Just being able to get up somewhat close to the stage for the big event makes it that much more exciting. Even more than that though you have some fun and make some friends as the line compresses and expands exposing you to different groups of people. If none of that matters to you though you can show up an hour or less prior to the keynote and watch it from one of the overflow rooms.

Unfortunately I can’t talk about the content of any of the WWDC sessions that I attended. However, I will say that, for me at least, most of the content seemed to be either way too high level (getting started) or way too low level (audio API’s). In any case, good info is there to be had and I picked up a lot of tips and got exposure to parts of the platform that I haven’t touched yet. Amazingly at every WWDC I have attended the speakers are first rate. They’re developers, managers, evangelists, and the like and I must say they all do an excellent job at presenting.

I spent a lot more time this year taking advantage of the labs that were available. The labs were divided out into major platform components and each had a dedicated area of the conference floor. Within each lab experts on a particular topic would be scheduled to be on hand during a particular time slot and all that you needed to do, in most cases, was just drop by and talk with them. Bring questions, code, or design ideas and it’s a good bet that you can talk with the guy or gal who actually wrote the code for some part of the system that your interested in. That in itself is worth the price of the conference ticket in my opinion.

Outside of the conference sessions, labs, and lunchtime speakers there are still plenty of Apple and non-Apple sponsored events. As for non-Apple events this is where your networking comes into play. Keep your ear to the ground because every night after the normal WWDC hours the real party begins. This year I made it to the VMWare party at ‘The Thirsty Bear’, the Cocoa Heads meeting at the Apple store (awesome), the Austin area Cocoa Coders get together at the ‘W’ (hi Jim!), and the Big Nerd Ranch party. Each and everyone was a lot of fun and I didn’t even scratch the surface of the events that I could have attended.

On the Apple sponsored events side of the coin you’ve got the ADA awards (not to be missed), Stump the Experts (which I did miss this year in preference to sleep), and of course the Thursday night beer bash. Apple’s beer bash is the ‘must do’ event of the week. The food and drink selection is a couple of notches above what you’ve had all week and, prior to the entertainment coming on stage, is a decent networking opportunity. I mean when you’re standing shoulder to shoulder its kinda hard not to meet the person next to you. This year the entertainment blew me away. I’ve always been a Barenaked Ladies fan and guess who stepped on stage? Yep, BNL! I was right down front just about center stage and managed to take this shot with my iPhone:

… tons of fun and the Barenaked Ladies were a blast as they talked and jibed about Apple.

All in all it was a great conference. I’ll definitely be back next year. Now to sleep for a few days and dream of that new code I’ll be writing.

I’ll be at WWDC again this year and I can’t wait. It should be a blast assuming that the sold out conference doesn’t take away from the overall experience. June is going to be one hectic month. I’ll be flying from Mexico back to Austin and then hopping on a plane 3 hours later for WWDC. A late arrival in San Fran will be followed by an early rise to sit in line for check-in and wait for the SteveNote. I’m a bit bummed that I’ll have to miss some Sunday night get togethers but c’est la vie. Post WWDC holds more travel as well but it’ll be more of a local nature.

If you’re going to be at WWDC drop me a line and maybe we can hook up for a beer or three.

Update

The latest Mac Developer Roundtable covers some really great tips if you’re attending WWDC for the first time (or even if you’re a veteran). Marcus Zarra,  Bill Dudney, John Chaffee and of course Scotty all provide some excellent insight into WWDC from an attendee perspective. Highly recommended.

The Good,

When I think of that quote I imagine what kind of feedback the exec was talking about. For me it meant feedback from peers and end users. Depending on the crowd that you hang out with it can actually be quite difficult to get good constructive criticism. I know, I know, what you’re thinking. This guy is asking for it? Yea, as long as it contains that operative word constructive and is meant with sincerity. Feedback is often the only way for you to see beyond your own narrow view of the world. Think of the Truman Show. Here you have this guy who has known nothing else but a little island for his entire life. Then little by little he starts to notice inconsistencies which make him think about the world around him. Had those quirks never happened or had he failed to notice them he would still be sitting there on his TV show. Feedback is the express train to realization.

Constructive criticism coming from your peers can take you to new levels of your craft. Of course, it’s up to you to decide if any one piece of feedback takes you in the direction you want to go as a developer, individual, astronaut, or whatever. This requires some introspection on your part. Developing a bit of a rhinoceros skin and a good humor about yourself also helps to digest the horse pill that can be peer feedback. However, the best peer feedback is often of the positive persuasion. A simple, “Good job” or “Man, that’s great” can do wonders to spur someone on in their current direction.

Assuming that you’re a software developer/publisher, you can have feedback from end users. Feedback of this sort can put greenbacks in your pocket book. When a user emails to notify you that there is a UI bug or that they don’t understand the usage of some feature it is your clue that something may be up. The same or similar item coming from two, three, or even more people should start to perk up your spider senses to a potential improvement in a design or work flow. Again, introspection is the order of the day when deciding if a request or issue falls along the direction and intent of your particular flavor of software.

the Bad,

Being the bearer of feedback can be just as tough as receiving it. That is, if your intent is to be constructive (and I hope that it is). Simply blurting out your observation of flaws comes across as strictly criticism and that’s bad. Instead, hold back the thought for a bit and think of ways to improve on the subject at hand. I mean, you see a flaw so you must have an idea of how things could be better. Right? Reverse roles with the person and think about how you would want to hear the news that you are about to deliver. Finally, provide your critique along with a suggestion on how to improve. Running through this sequence becomes second nature once practiced for a while. Some people will do it naturally and don’t even think about it. Others need a process to follow. Some characteristics of good feedback include:

• Transfer of information rather than the giving of advise
• Covers a specific issue rather than a general one
• Focuses on the content rather than the person
• Offered with empathy

Just as bad as not being able to take feedback is never giving it. Floating merrily along accepting the status quo lies in a direct line towards failure. Yours or someone else’s. It could take years or even decades to materialize but sooner or later such a static nature will break down. Often an unwillingness to provide feedback is really masking a desire to avoid receiving it. If that’s you then start small. Give yourself time to develop the skills of giving and receiving feedback. I think you’ll be better for it in the long run.

and the Ugly

Trolls and flame warriors need not apply. We all know the type of inflammatory feedback that a supposedly anonymous internet can elicit. There is something about the feeling of anonymity that can draw out some of the more basal aspects of human nature. In short, there is little you can do but surround yourself with as many upstanding people as possible and simply ignore the occasional flame. Responding to outright deleterious comments or feedback usually only fans the flames and invites more of the same. Use that rhinoceros skin and good humor to the best of your ability and ignore it.

That’s a wrap

There you have it. The good, the bad, and the ugly of feedback. Sometimes it takes stepping outside of yourself in order to see the larger picture but feedback is a great way to grow an idea, a product, or yourself.

Feedback. It’s not just for breakfast anymore.

There is a way out of this quandary and its called peer review. The mere mention of “peer review” can strike fear and foreboding into the hearts of developers. But, like it or not, this egoless programming practice has the power to deliver.

Outside input can lead to an increase in production quality and ultimately product appeal. Here’s a few ways to get outside input and ideas if you’re flying solo:

• Direct communication with friends. Friends that you’ve made through previous jobs, ventures, or virtual contacts made real are great sources of input. When in the same industry they can provide a unique perspective. If it has been a longtime since you’ve touched base then invite them out for lunch, or better yet a beer, in order to reconnect.
• End Users. The end users of your product are an extremely valuable source of feedback. While a user may not be privy to the nitty gritty code details they will have an opinion about what is good or bad about your interface. Running a public or private beta will give you the chance to gather valuable feedback and roll it into a product before going live with it.
• User groups. There is a good chance that there is a Cocoa developer group that meets regularly in your area. A few places to start would be CocoaHeads, NSCoder Night, and if you’re in Austin CocoaCoder. Getting out and mingling with other developers is a great way to cultivate ideas, get feedback and make a few friends. Try giving a short presentation to the group on some code or a technique that you’ve been working on. Not only will this give the group a chance to discuss a topic but it can help you validate ideas or to open up new avenues of thought.
• Virtual community. Participation in online forums, email lists, IRC channels, and of course blogs can be another source of outside input. While readily available the quality of this sort of feedback can tend towards the inflammatory. Be sure to research your questions and always interact per the guidelines of your chosen group. Oh, and be sure to don your flame retardant suit before dipping your toes in.

Whatever avenue you pursue to gain outside input it has the ability to not only improve on your own designs but to also increase your creativity. New ideas yield more new ideas and so on. So, if you’re feeling like you’ve hit a brick wall or that you need a second opinion try getting some outside input.

Yikes! No way. Did Google screw up and display somebody else’s stats to me? I know, it’s one of those famed Google April Fools day hoaxes… after all yesterday was April 1st. If it was one of their hoaxes then it’s not very funny, I mean that’s actionable data, Right? (although I doubt any lives where in jeopardy).

The stat that was blown out of the water was a direct link to my last blog post “CoreData’s default date value”, everything else was a tad higher but not by much. So where did all of this traffic come from? Checking out the visitor data it seems to have come from just about everywhere:

Baffled I decided to Google for the title of the blog post which turned up DZone as the first result. Aha, it seems that I have been the unwitting beneficiary of a link submission by bloid (much love). Wow, that’s great and thanks!

So, to all the new readers and feed subscribers, Welcome! I’m a long time Java developer who has turned his sights recently towards Mac development (Cocoa/obj-c). Normally, I tend to focus on Mac software development around here with the occasional foray back to Java, an opinion piece, or a favorite photo from Flickr. Towards the second half of this year I plan to add in lots of content about iPhone development (after Apple opens up the NDA on the beta iPhone SDK). Until then stick around for Mac dev articles and other fun stuff. Happy coding.

After wrestling with the initial Netgear configuration I was back on the excitement train as I moved back to my Mac for the initial setup. Unfortunately, disappointment set in again since it was impossible to get the Netgear configured through the standard Mac Printer preferences pane in Leopard (believe me I tried again and again). Luckily after some googling I came up this article. Netgear, it seems, has not been without issue in this realm.

In essence this article points out that there is a CUPS web interface on each and every Mac, this is one I had not yet discovered, that can be used to directly access CUPS. Simply navigate your Mac hosted web browser to http://localhost:631/. Here is what you are greeted with:

(Click for full size)

Cool, huh?

From here setting up the Netgear WGPS606 is basically a matter of adding a new printer via this CUPS web interface. Be sure to use an lpd:// url to refer to your printer when asked – something like lpd://192.168.1.100/L1 where 192.168.1.100 is the IP address that the Netgear has been configured for. When all is said and done the printer will show up in the Macs System Preferences and can be used just like any other printer.

By the way, this Brother 5250DN laser printer has been an excellent little workhorse and works perfectly with Macs.