Excellent comment, thanks.
We would require location and touch functionality.
The core use case is really quite simple: users provide both text and numerical feedback based on their location - that's basically it. Nothing fancy.
It needs to quick and easy to use, work on as many platforms as possible, and - given the nature of the application - is unlikely to be downloaded prior to when it's needed. People are more likely to use it "on impulse" and that's another reason we like the idea of accessing the service as you would a web site.
Yes, but it implies the user anticipating the use case...
Would you download an app which talks you through fixing a car engine before you actually needed it, for example?
Without describing what phones/operating systems you're expecting to target it's difficult to get specific. You will absolutely run into rendering issues between different mobile browsers, this will likely never go away, but the good news is the majority of the more recent mobile browsers are based off of, or will be, WebKit. If you go the Mobile Web application route and don't limit your scope to more recent phone OSes you're going to have to deal with the challenges of cross-browser development which could involve just as much time and effort as going a native application route with a helper framework like PhoneGap.
Well, we'd basically want to target them all!
Given that people change their phones more often than their PCs, one would expect the installed mobile browser base to 'fresher' than the PC one.
In other words, over the medium term (say 2 years) the rendering issue should hopefully fade away.
It's just a question of timing - when is it going to be OK to go 100% HTML5? (assuming, of course, the app is not particularly complex)
Ahh, I had assumed you were talking about a brand new application/service. If, as you mentioned in a reply to another comment, you're just exposing an existing web service to mobile phones then simply providing a mobile alternative to that service gets you a large percentage of your likely user base for a minimal effort.
If you're asking when 100% of the phones in your possible market will have browsers on them that are HTML5 aware/capable, I couldn't begin to guess. I don't think that will happen soon, but it's certainly happening at a faster rate than I ever thought it would be. This is the kind of question that can have a paralyzing effect however. If you want to provide a mobile gateway to your existing service you should go for it and you should implement to target the phones you expect the majority of your users to be using.
It was pointed out earlier, but it bears repeating, plan for what's out there right now. HTML5 has a lot of momentum in the browser space, but that doesn't mean it will be adopted in a uniform manner. Limit your scope if you have to, something is better than nothing, but right now the state of mobile browsers is in flux and I wouldn't recommend depending on 3rd parties to create a desirable environment for you.
I agree it's all about trade-off. Cleaner, faster, cheaper development vs risk of alienating some percentage of users with older mobile browsers. I was trying to get a feel for what people are currently thinking - but there doesn't seem to be an overriding consensus yet.
As regards focusing on what the stack looks like now rather than making an educated guess as to the not-too-distant future, here I have to disagree. Our business is all about well-reasoned gambles, and it seems pretty clear HTML5 will win the day for all but the most complex / intensive apps, so it really only boils down to timing.
Good point. I should have mentioned monetization is not an issue. In other words, if what we aim to build were in an app store it would be free anyway.
Basically I'm asking whether HTML5 will be mature enough both in terms of functionality and browser market share in around 6 months time.
Never mind six months from now - if you're thinking native app, then you've got a particular set of phones in mind. Take a look at the state of the browser on them now.
andrewf is completely right. You should plan for what capabilities exist today on the platforms you're targeting. Taking advantage of upcoming synergy is a lofty goal, but expecting it and making your plans depend on it would be a mistake.
Hi Joel, ex stock analyst here. What you say re minority trades is correct in so far as that is the way market valuations are calculated. However, what David says is also correct: just because someone pays X for a tiny fraction of the company doesn't mean someone else will pay the same for all of it.
Wily investors always look for meaningful volumes before taking big jumps/declines in share prices seriously.
One of the easiest ways to ramp a stock (apart from getting your journalist buddy to write a puff piece) is to continually lift the offer for small volumes.
As Joel points out, it's tautological. How many companies would buy up Google for it's current market valuation? Apple? Since no buyers have tried to do that, are they ipso facto no actually worth that market cap?
Yes, but Google's valuation is confirmed by trading volumes.
In the early days of computerized trading it was quite common for even quite liquid stocks to be suspended limit up/down because of programming bugs.
But by Joel's logic, the market has 'spoken' and these companies are now worth 10% more/less than 30 seconds prior, when in fact all that has happened is some faulty code just ripped through the book on minimal volumes.
The point is that 'true' valuations are validated by significant volumes. Hence Google's valuation is real. Depending on your viewpoint, the size of the recent transactions in FB may or may not be material - and I think this is the point that David was making.
It was true then, is true now, and will always be true.