Mobile Strategy Best Practices

Recently I had the opportunity to discuss mobile strategies with Vidya Drego of Forrester Research. We chatted about how businesses are looking at the emerging mobile market and how they are approaching application development. We quickly got to the subject of mobile app development best practices. Our conversation motivated me to look at what we are hearing from our clients and potential clients, and to discuss some of the things we have learned over the last couple of years.

Most businesses are discussing mobile best practices in the terms of design and development tactics.  Most of which can be found on sites like w3.org, or uxmagazine.com. For example:

• Optimize for application start-up time
• Use cookies sparingly
• Make telephone numbers “Click to Call”
• Replicate Local Data
• Use clear and consistent labels
• Avoid using specific font point sizes
• Icons should not save space at the expense of user understanding
• … you get the picture

Another thing many marketers are thinking about is the mobile marketplace. “How do we monetize the application” or “How do we make sure our application is findable” or “What is the right go-to-market strategy”. These are all important questions that need to be asked. But not yet. Not until we understand one very important thing, “why”…

After reviewing hundreds of application ideas, reading user research reports from our research team, and checking out multiple consumer surveys that have been conducted on mobile, I decided to take a stab at developing a best practices for mobile strategy…

There’s an app for that… why?

Seriously – “why” is the most important question you can ask. It is also the question that talks us out of a bit of application work too. We ask “Why are you building this?”, “What is the compelling business case for a mobile application?”, “Can this be accomplished through a well designed mobile site?” or “What are your customers demanding from you in a mobile application?”

Once you understand “why”, you need to make sure it is well documented. It can be a simple sentence, or a paragraph, but not much longer than that. I call this getting to the “reason for being” or the “Raison d’être” of the application. Defining the Raison d’être of the application will ensure the team is pointed in the right direction. It is something that should be referred back to when making decisions as to what to build and what not to build.

True story. We were talking to a small organization a while back. We were discussing the value of user research, to understand what their users would wanted in a mobile experience. We received a significant amount of push-back from the client on the time and energy of the research (which was only a few days worth of work). For us, research is a critical ingredient in designing and building an application that users will want to adopt. After several frustrating conversations, the client finally came out with the reason why they didn’t want to do any research. “If you ask our customers what they want in a mobile application, they will tell you they don’t want one.”  Do me a favor and pause on that thought for a second. The client was funding an initiative they already knew was currently unnecessary. They didn’t really contemplate the business case and the user case – they were just blindly following their CEO’s direction.  The “why” will also help guide your team and direct design decisions. That brings me to my next point…

Ask your customers what they want

Don’t guess, know. A little research goes a heck of a long way. In fact, research may show you that you don’t need to do anything right now. You may find out that your customers are perfectly fine without a mobile application from you. This research needs to be contextual (ie: in person and in the field) to make sure you get accurate responses. But be warned, don’t try to do the research internally or hire a pure-play research firm to do it. You need an agency that understands how to design and build the application to do the research. It is surprising how different the questions are when you are asking from the perspective of having to apply the research and turn it into a solution. Joy, our director of research, and her team of researchers work closely with our design and dev teams to make sure there is no fidelity loss between research and the final product. Even outside of a mobile context, for any application, the right user research and design collaboration will drastically reduce maintenance costs and increase initial and sustained user adoption.

Your mom has a smart phone

Just a few years ago, most of the people we designed for were technology savvy and understood how software and applications should work. User interfaces were intuitive because users have seen something similar in another program or device. The metaphors I use to navigate an application were learned over years of being a geek. But my mom has none of that – she has no frame of reference on how an application should work based on intuition learned over years of software experience.  And this community of late adopters is growing. In fact, the fastest growing market of web related services and devices are people over the age of 70, according to one study. That means you need to care about how they perceive the device – many designers talk about using more physical metaphors when designing UIs – largely because they understand that novice users need their connection to the physical world to map to their digital interactions. Long story short, it is not only important to ask “why?”, but also to ask “who?”

The mobile app market is not the web of yesterday

I wrote about this last year claiming “the iPhone is not an ad platform” – perhaps I could have chosen a better title given Apple’s iAd platform. My point was you shouldn’t treat an application initiative the same way you would treat a microsite, email campaign, or television spot.  Do not think of the creation of an application as a “campaign”. User’s look for utility from an application. Sometimes that utility is entertainment, but if you are not an entertainment company, don’t try to entertain your consumers in an attempt to drive traffic. What is worse, many companies are trying to create throw-away applications for the sole purpose of brand awareness. Driving traffic, find-ability, clicks, impressions, are typically the wrong metrics to use when measuring the success of a mobile application initiative.

Focus on what your business does

If you are a credit card company, you don’t need to build a game. If you are a Shipping company, you should not build a social network. Stick with the primary purpose of your business. Consumers know one thing for sure: if you build an application that does not have direct utility related to your business, it is probably an application designed to market to them. A quote from a review on an app that tried to build something outside of their core business:

“This app is an advertisement. It features cute bubbles that contain useless information about deals. I expect quite a few Fortune 500 companies are going to do this. The iPhone will turn into the Internet soon, just an ad machine. Don’t waste your time with this and don’t encourage this.”

Most consumers do not want you taking up space on their device and data away from their data plan for the sole purpose of delivering advertisements. There are very few brands with enough consumer brand equity to successfully pull off their own adware application. There are plenty of options for you from a mobile advertisement perspective if that is what you want to do, stay away from trying to build your own advertising channel.

Design for mobile use cases only

73% of mobile app users say they expect a company’s mobile app to be easier to use than its website (link to study). If your website or customer portal has 50 things a customer can do, your mobile application should do 10. In almost all circumstances you should never consider a “port” of all your website’s features to a mobile application (or even a mobile website for that matter). Ask these questions once you have identified all the requirements of an application:

• Will they need to access this feature more than once a month (or, even better, once a week)?
• What is the compelling reason for  using this feature on their mobile device?
• Will this feature be easy to use on a small screen?
• Can we get this feature perform well?
• Could this feature deplete the battery too much?
• Is there a ton of data to transmit to make this feature work? Will it require high bandwidth?

Most good mobile applications offer a fraction of what their website offers. And some great ones add a feature or two that takes practical advantage of the device’s GPS chip, accelerometer, compass, or multi-touch display.

Cross-Channel is not just a buzzword

You have a digital product ecosystem. Your marketing website and campaigns, your automated customer service call-center, your customer self-service portal, kiosks, and perhaps a tablet or desktop application. If your organization is like most large organizations, these experiences are probably disparate initiatives that have no connective tissue. Don’t make the mistake of creating yet another skunk-works initiative that further fragments your digital ecosystem. Take the time to think about the entire customer journey and map a mobile experience to their overall user experience with your company.

Every smart phone has a browser

In other words, ask yourself: “do we really need to build an application or can you simply design a smart-phone specific website?” All new smart phones render HTML very well in their modern, mobile browsers. If there is not a compelling reason to download an app, they won’t. One major side benefit to creating a mobile website is that you have something that will work across devices. In most circumstances you need to build an application specific to a device – where a mobile website is much more ubiquitous. There is a great post written by mobiThinking if you are struggling with the decision to build an app or build for the mobile browser.

Plan for frequent updates

Most successful applications have an avid audience because they created a great experience first, and then continued by following up on that great application with updates and improvements. You build great fans and and evangelists if you show a responsiveness to customer feedback once the application is launched.

Focus on outcomes, not features

Actually, this is good advice when discussing any application initiative. Quite often teams focus on the tactics of creating the application before they figure out what the user and business goals are. Focus on the outcomes. In other words, focus on the things the user will accomplish with the application – figure out the details of the features later.

Examples of features:

• Secure log in screen that does not save the user password
• Recent transactions with access to scanned checks
• Connect to existing web services
• Allow customers to view accounts in list form, click on an account, and transfer money to another account

Examples of Outcomes:

• Our customers will have access to relevant account information (balances and pending transactions)
• Our customers will be able to find a branch closest to them quickly
• Our customers will be able to process transfers while on the go

The data is very important, but…

When asking for input on this list from our team, a common theme emerged: “Before you invest in a mobile app, invest in an API”. It is 100% true that you need to care about the services and data that will drive a mobile application. Without a well architected API, a mobile application is just a Hollywood set. However, do not make the mistake of allowing your IT department to build your API layer before you understand user needs. If you already have an API, great! But your IT department needs to be willing to work with you on iterations and modifications so you can adapt to user needs quickly. Many times we find ourselves developing to APIs that were defined before user needs were, and many interactions and data requirements were just not architected in the API. The best case is to define Outcomes, map the experience, sketch wireframes, architect and build the APIs, and then continue with building the mobile application. This sounds linear but it does not have to be. In circumstances where a release date is critical, we can develop a mobile application to a set of what we call “mock services” while IT builds true services in parallel. It is not optimal, but it can work if planned correctly.

A good API also has a potential alternative benefit. Although many (if not most) organizations would never consider releasing their APIs for public consumption – there may be a way to get other developers to build when you don’t have the time or resources (or even the great ideas). Tony Hillerson reminded me of the story behind the twitter iPhone application – Twitter simply enabled third parties to access their API and let the developer community at large build multiple Twitter clients (then they bought the best one and branded it with their name) – Further, even if you don’t ever release your API to a developer community,  a great API provides you with a platform in which you can leverage across other channels in the future, like a tablet application, a desktop application, or even an Apple or Google TV app.

Be careful with “Social”

Just because a mobile device has social features doesn’t mean your application needs to. I personally have always been a little skeptical anyhow of social strategies that go beyond listening to your customers feedback through social channels. First, not every organization needs a facebook strategy – second, your customers may not want to include you in their social sphere (in fact, they probably think negatively of  your brand for even asking to be included in it). If there is a compelling reason for the user to be connected to facebook through your app, then by all means, go with it. But it MUST be compelling enough for them to invite you there.

Don’t just “Dip Your Toe In”

Many companies are wanting to get an application in the market quickly. There are a couple reasons for this. First, they have very limited budgets for mobile as the market is still relatively small. Second, the market is very new and largely misunderstood – companies treat a mobile app the same way they would a web microsite or a flash banner ad. But, consider this, do microsites or banner ads receive consumer ratings? Can your brand afford a “two star” application? If your customers download an application and have a bad experience with it, will they ever trust your brand in the mobile market again? A recent study conducted by EffectiveUI and Harris Interactive showed that 13% of all mobile app users already don’t trust a brand because of a bad mobile application experience they had with that brand and 69% say that a bad experience with a brand’s mobile app results in a negative perception about that brand

A fresh, clean canvas for innovation

I’ll end where we began – with a conversation I had with Vidya. The most poignant thing she said was that new channels like smart phones give organizations a chance to innovate on user experience. Your website is wrought with legacy issues, probably a Frankenstein of multiple initiatives over the course of many years. But a mobile initiative gives you the opportunity to look at your customer’s digital experience with fresh eyes. This is a blank canvas where you can really focus on user experience the way you always wanted to. Vidya reminded me of our work with eBay, where they viewed the desktop as an opportunity to innovate. eBay’s goal was to create a better shopping experience for their customers without the constraints of their main website. Not only was the application itself was a success, but many of the new features created for the desktop application bubbled up into their website.

Operating without the weight of legacy decisions and many of the nuances of interdepartmental silos can be quite liberating – and a huge opportunity to shine a bright light on user experience for  your entire organization…

………..

We are releasing the results of an in-depth study this week confirming that a bad mobile experience can have negative consequences for your brand.  A good strategy and a focus on the user will ensure that your mobile initiatives are well worth the time and resources your company will spend to capitalize on this new frontier.

Mass Confusion: The hysteria over Flash, Silverlight, HTML 5, Java FX, and Objective C

I’ve been working on a whitepaper titled “Choosing The Appropriate Web User Interface Technology” for more than a year now, with input from Sun, Adobe, Microsoft and everyone here at EffectiveUI. I’ve rewritten the damn thing four times now and have decided to abandon the effort. The blunt truth is that there is no credible way to articulate, in a simple whitepaper, the complexity of making a platform decision. I could write a book on the subject, but the problem is the book would be out-of-date by the time I wrote the outline.

If today EffectiveUI’s clients  were to ask, “Should we look at Flash, Silverlight, HTML5, Objective C, Java FX or some other platform?” my answer would be, “Now, more than ever, it depends.”

What’s worse, many bloggers are adding to the confusion by forecasting the death of some platforms or drawing the wrong comparisons from one to another. So to help clear up some of the confusion (or, perhaps add to it a bit), I thought it would be helpful to review some of the things our clients are thinking about.

Enterprise-Grade Considerations

There are a matrix of considerations that go into deciding what platform is right for your particular organization. These considerations should be weighed uniquely every time you decide to take on a new software project. They include:

Existing Technology Skills

Choosing the right user interface (UI) platform should start with a simple question: What can my development team execute and maintain?

Although answering this question is critical to the success of a project, you must also consider what platform is best suited to meet the business and end-user requirements. Sometimes it actually makes sense to choose a platform your team is not familiar with because its business and end-users’ needs have outgrown your team’s current skill set.

Longevity

How long do you believe your platform of choice will be around? In essence, this is a bet you are placing on the platform. This is also one of the most volatile considerations because of new announcements happening every day that change the game and disrupt the playing field.

Integration

Legacy systems, data structures, client machines and business processes will all inform the choice of a UI technology. Some platforms integrate better with specific legacy systems than others.

Scalability

In any software system, scalability must always be a consideration. However, when creating a UI, a scalability discussion can become complicated. This is primarily due to the inherent distributed nature of UIs. In browser-based software, much of the computing and processing can be done either on the client machine or on a server.

An example of this distinction can be seen in the creation of a simple calculator. Developers can write a Web page that takes in user input, sends data back to the server to do the calculations then sends the results back to the client machine. Alternatively, developers can simply create code to run on the client machine, removing the requirement for the extra processing on the server.

If this simple calculator example is applied to more complex tasks, such as sorting a set of data alphabetically, drawing a line chart or validating data entry, one can begin to understand that offloading processes to the client machine will inherently make the system more scalable. Careful architectural planning is extremely important when making decisions between client and server processing.

Maintainability

Software typically needs regular maintenance. Changes in legacy systems, increasing user demands, additional business requirements, bug fixes and improvements in scalability are all reasons for maintenance. The more difficult it is to maintain a software project, the longer it takes to make changes, and the more apt those changes are to break something else in the system.

Security

Security also can pose a challenge. As with scalability, you must decide early on in a project what data clients will see and what data the server will maintain.. Typically, if architected correctly, all UI platforms are equally secure. As long as the application programming interface (API) infrastructure is not exposed to provide unauthenticated data, the site should be reasonably secure.

THERE IS NO COMPLETELY SECURE UI PLATFORM. This is because each may require integration with a back-end service. The UI is only as secure as the API that supports it.

UI security can be broken down into two primary buckets. The first is described above, in what we call “system security.” The second is client security, or the ability for the UI to hack into a client’s machine and run malicious code.

Performance

How well does the platform perform under sever-data crunching, multitasking or other CPU intensive operations?

Platform Capabilities

The UI platform needs to be robust enough to handle more sophisticated processes as end-users engage in more complex tasks. In our simple calculator example earlier, any platform would be perfectly fine. Some online systems, however, have higher demands for social interaction, real-time data, video, collaboration, charting, etc. This level of sophistication requires a UI platform that can handle more integrated online interactions.

Strength of the Development Community

How easy will it be to find developers for your project?

Platform Maturity

You must mitigate the risk of running into platform bugs. There is no way to eliminate the risk of software development issues, but addressing the maturity of the platform will help reduce some of these risks.

Ubiquity/Compatibility

Simply put, will the end user have to install something to get the system to work? Every platform, project and line of code has some level of balance that will need to be achieved between system sophistication and system compatibility.

Tooling

Are the tools used to develop and design your UI sophisticated enough to alleviate frustration among your teams?

User Experience

We define user experience as a means of driving better user adoption. User experience can be somewhat subjective, but most will agree that software that is pleasurable to use will have a much higher user adoption. Certain UI platforms give design and development teams more flexibility to create better software.

Religious Conversion

There is a major shift happening in software development — the shift toward user centricity. Most IT projects today are started because of a user adoption pain-point. Building software that focuses on user adoption first and enterprise maintainability second requires nothing short of a religious awakening for most CTOs (and many CIOs and CFOs, too). The platform that is right for your organization may be the one you can actually get adopted companywide. You must consider the religious and political nature of the developers and dev. managers before trumpeting adoption of any technology. By the way — this is where startups have a major advantage over larger enterprises; they get to adopt newer techniques and platforms without religion or legacy issues.

Platform Philosophies

Philosophically, each provider views his or her platforms as uniquely positioned to do things a bit better. But what does “better” mean for you? After considering 20 different ways to slice the data, I decided to look at each from what I believe is its long-term vision.

Adobe Flash

Flash’s philosophy:

Write once, deploy anywhere.

Flash’s advantage:

Its ubiquity, active developer community and the maturity of the flash player itself

It also has the best designer tools and a great designer/developer workflow model.

Flash’s challenge:

One word: Apple. You can view Flash content on almost every device on the planet produced in the last five years with two glaring exceptions: The iPhone/iPod Touch, and now, the iPad. This alone has caused every one of our Flash developers to pick up either an HTML5 book or an Objective C book. Additionally, Apple’s and Adobe’s relationship is strained at best. Neither company is showing a lot of maturity when discussing the other. Watching them fight is a lot like watching two parents squabble in front of their children during a divorce. I wish, for the sake of developers and consumers, they could find a way to get along.

Who will choose the Adobe platform?:

Companies that want the best, cross-platform user experience for browser and desktop applications

Those same companies will see development on the iPhone and iPad as either not relevant or so relevant that they believe they need to develop custom experiences for those devices.

Microsoft Silverlight

Silverlight’s philosophy:

Write everything from the database to the client using the same skills and developers.

Silverlight’s advantage:

The story plays. If I am the CTO of an organization that has invested heavily in Microsoft technology, Silverlight needs to be looked at seriously.

Silverlight’s challenge:

Ubiquity. I know that Silverlight is seeing some great traction, but it still pales in comparison to the Flash player. Additionally, to believe Silverlight would ever appear on the iPhone or iPad is like believing Daisy, our COO, will give me the company credit card and tell me “go have fun in the Apple store” … never gonna happen.

Who will choose the Microsoft platform?:

Silverlight does make a ton of sense for companies that control the whole technology stack. Many organizations have the luxury to enforce a Silverlight download to their sales team so they can view the new sales  portal they built in Silverlight (for example).

Sun’s Java FX:

See everything under Microsoft Silverlight and replace “Silverlight” with “Java FX” and “Microsoft” with “Sun.”

Microsoft and Sun are basically competing against Adobe for the client side of computing. I believe they are betting enterprises will want to stick with their Java or .Net developers and deploy on their proprietary runtime. In other words, they are betting that Flash will not be taken seriously by large enterprise IT departments that already have huge Microsoft or Sun investments.

Apple, Objective C and HTML5

All right — I know Apple does not own HTML5, but it is placing huge bets there. Apple’s development model is very clear: Control as much as it can on its own, and rely on a fully open standard for “the rest for the developers out there.” You may also ask “Does Apple even belong in this list?” – Well, they do because of the disruptive impact they are having in our industry right now. You can not have a conversation anymore about software and the web without also talking about the iPhone.

Apple’s philosophy:

The user always comes first.

Apple’s advantage:

A huge headstart on mobile and similar bets on mass consumer computing with the iPad. It Apple values user experience over developer experience which is clearly resonating with the late adopters of technology.

Apple’s challenge:

Its challenge is maintaining its leadership position in such a crowded and coveted marketplace. It also is going to be challenged by when its customers realize Club Penguin, NeoPets, Mint, Hulu, Disney or Farmville do not work on the self-proclaimed “Best Way to Experience the Web.”

Who will choose Apple’s platform?:

Simple — those companies that want to reach Apple’s customers.

A little note about HTML 5

HTML 5 is still in its infancy. It is certainly not a Flash or Silverlight Killer. However, it will be a viable option in many circumstances, but will not answer the call for more sophisticated, complex and richer web experiences.

What about Google and Android?

Who? Sorry, but we are rarely asked to participate in building software for the Android. Of course our eyes are on it, and we are building a few interesting things on the platform, but Google has yet to figure out what Apple has down, and that is the unified user experience. From iTunes to the App Store to eBooks to the devices.

Worth a mention, Unity

Unity3D is an interesting provider in the this mix. You probably have not even heard of them, but they provide an alternative to Adobe’s philosophy of “write once, deploy anywhere”. Unity’s philosophy is “write once, deploy native”. You can create an application, and compile for all kinds of deployments. Currently included:  iPhone/iPod Touch (and almost certainly the iPad), Mac Desktop, PC Desktop, Nintendo Wii, and a proprietary, Unity3D browser plugin. What makes this platform so compelling is the right device support, the ability to develop in C#, Python, Javascript, and their focus on 3D. 3D is an area where most other platforms really struggle, and an area of opportunity to differentiate. We are very intrigued by Unity, and you should keep an eye on them as well.

Where does this leave us?

I asked Brook, our chief software architect, about where he is steering our development team. He put it simply and concisely: “Dexterity.”  Right now, all of our clients are realizing how unique their situations are compared to other organizations building online software. Where we have seen the most success is when we help articulate the end-user’s needs, the business challenges, and craft a strategy for each of our clients, specific to their organization’s individuality.

Apple’s iPhone dominance is going to be hard to topple

Interesting article today on Flurry (and also summarized on MacRumors.com)

We’ve been internally debating about Apple’s continued dominance in the smart-phone market. I’ve taken the position that Apple will be the leader for at least 4 years, it appears I may have been understating it bit.

Looking at the chart above, it becomes clear that Apple is leading the iPhone/Android usage metrics by 3 fold. But what what the report also goes on to suppose is that iPod touch users (assumed to be mostly kids that do not have a cell phone yet)  will eventually migrate to iPhone users. To me this seems like pretty sound logic.

The article also goes on to theorize that since most iPod touch users are also very heavy social networkers, they will help influence the entire market…

I’d love to hear your thoughts on where you think the mobile market is going… who do you think is going to be the dominant force in 2015 ?

Amazon VS Google – digital books are coming to a device near you

At almost exactly the same time today, Google and Amazon release details of their digital book strategy.

Google announced they are putting 1.5 million books, all who’s copyrights have expired, on Android and iPhone applications:

http://www.nbr.co.nz/article/google-puts-15-million-books-reach-your-iphone-44332

“Coincidentally”, photos were leaked on the new Amazon Kindle, due to launch tomorrow:

http://www.nbr.co.nz/article/kindle-2-photos-leak-ahead-tomorrow-s-launch-44328

I have a friend with a first generation Kindle – I will tell you that the pictures do not do the device justice. The electronic ink technology they use is stellar, great readability even in bright light situations – In contrast, I don’t see myself reading novels on my iPhone or on any devise that fits in the palm of my hand – its just simply not usable…

That said,  John Blanco (a developer I work with at EffectiveUI) noted an undeniable truth about the new Kindle:

Much, much sleeker…but, in the end, it’s still lacking the soul of a book. I just can’t do it.

 

 

iPhone App Store – The Differentiation Paradox (update)

We have been building iPhone applications for the last 10 months now and we’ve made it on the Apple “short list” of partners for iPhone development. Occasionally someone calls that got ahold of that list to get a proposal from us. A common issue we are seeing right now is the same issue we saw in the early days of RIA development. Budgets for adequate design and development of these applications are no where close to deliver the types of experiences iPhone customers have come to expect.

What the app store market has done is create an interesting issue for companies considering an iPhone effort – do you build something quick and get it out there for a little, or do you wait for the market to mature and budgets to increase – if you go for the smaller budgets, the applications will not be up to your standards (and you will almost certainly be disappointed)… if you wait for budgets to increase, will the opportunity pass you by?

To answer the question, we needed to look at the app store as it exist today, and try to pull some useful numbers from it. The first thing that struck us is the sheer volume of applications in the store – roughly 12,000 at the time of the writing of this post, less than 6 months from the launch of the store. The second most surprising item was the number of downloads, 300 million and counting. 

App Store Growth is Absolutely Amazing

If the above trend continues, by the middle of next year there will be 100,000+ applications and 3 Billion (yes, with a B) downloads of those apps. That means if you start building your iPhone application today, by the time it is released you will most likely be competing with 100,000 other apps for an average of 34,000 downloads per. This presents a HUGE opportunity for some, while an even larger dilemma for others – The upside is obvious: if you create an application for the app store and its even a mild success: cha-ching! The downside is that it will be easy to get lost in the 100,000+ applications.  For a little more inight,we looked at the individual app store categories: we noticed, even today, it would be difficult to create something truly differentiating for a low budget… there are 2800+ games, 1000+ educational apps,  1000+ productivity, 1800+ “utilities”… heck, there are even 100 “weather” category apps and over 800 in the “books” category.

 

Our advice: For those that are considering an iPhone experience next year, you need to make a hard choice. If you decide to go forward, you will need to look at creating something that is truly differentiating – this means respecting the power of the iPhone platform and taking the proper time (and resources) to craft an engaging application. If you believe you will fall short, save your money and and use the built in Safari Browser on the iPhone along with some internal web developers to create a website presence specifically designed for the iPhone.

It is too late to be a “first mover” in this market – it is time to do it right or not at all —

 

update: it appears that I’m not the only one commnenting on the status of the app store application market:
http://www.macrumors.com/2008/12/10/app-store-developers-debate-pricing-and-marketing/