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.

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.

So, does Java on the iPhone make sense to anyone other than a pre-supernova Sun? Mmmm… well, I’m sure that the thousands of J2ME application developers out there would be pumping for it. There might also be a few users who rely on some mission critical application. Anyone else? None spring to mind, certainly not Apple.

A post-apocalyptic JVM enabled iPhone would soon become a litter ground for the multitude of J2ME apps. Some of these apps, such as the ones developed by Google, are indeed beneficial and well done. They are, however, far from the norm. With Apple’s tight control over the platform any J2ME apps would surely need to be provisioned directly from the iPhone AppStore which might help to eliminate some of the cruft. But, a free for all iPhone application bonanza is not likely to happen in this universe and that includes J2ME apps.

As a fledgling iPhone developer I must also say that a massive influx of J2ME apps to the iPhone would severly dampen my enthusiasm for the platform. All those J2ME apps would immediately have first mover advantage in a lot of important application categories – thus castrating many native iPhone applications. One of the draws to iPhone development is that it is a green field… there are thousands upon thousands of apps that need developing and for the uninitiated that spells “opportunity”.

Java on the iPhone proponents see the iPhone as another smart phone market for J2ME applications. However, the iPhone is much more than just a smart phone. It’s a completely new platform and more than any other device that has come before it is a powerful computer in your pocket. In order to make full use of all that the device offers only native code can deliver. Witness this quote from Eric Klein, vice president of Java marketing at Sun (source ars technica),

“We’re going to make sure that the JVM offers the Java applications as much access to the native functionality of the iPhone as possible,” he said.

Why would we even settle for anything less than complete access to the native iPhone functionality? Do some J2ME apps not need all that the iPhone has to offer? Well, then they aren’t iPhone apps and users will know the difference.

So, why throw my vote towards native Objective-C iPhone apps rather than building on my already deep Java knowledge and J2ME? It’s simple. Hands down the best user experience will be had by witting applications which make use of the unique and powerful native iPhone API’s. As a developer with a user experience mindset I only want the best and adding J2ME to the mix only waters it down.