In addition to the native categories you listed, I'm interested in the idea of my smart phone as an internet gateway for "dumb", cheap, bluetooth-enabled sensors and devices. The Nike+ iPhone app is an early example of this. It doesn't make sense today for your running shoes to be fully-featured, internet connected gadgets on their own. Instead, you have a cheap, dumb sensor in your shoe that simply transmits data to your phone, then your phone does the more complex work of getting that data onto the web and providing an interface for the experience. I can picture a ton of other businesses emerging from this idea of dumb sensors plus smart phones. I might wear a wristwatch that transmits my heart rate to the web. My car might send maintenance updates to the web via my phone's internet connection. Retail merchants might transmit data and offers to / from my phone when I walk into their stores. I see lots of business opportunities in this area.
Peter Cranstone
· 5 months ago
Joe,
That's exactly what our solution was designed for. It essentially a mobile app with an Open API. You can attach a sensor to the phone via Bluetooth, transmit that data to our app and then we send that data (you have complete privacy controls) to any web server. The way we do this is to take the meta data and add it to the outgoing HTTP headers. So now all you have to do is read the incoming data at the server. We even have a windows mobile version that you can now access any device side data using JavaScript all from within the mobile browser.
Works like a champ.
albert
· 5 months ago
That's a great point. Zipcar's iPhone app is another example of where this can go.
There is every indication that the App Store doesn't contribute very much to the bottom line of many developers, either. If there are 65,000 apps and 1.5 billion downloads, the average number of downloads is about 23,000. If you subtract some of the irresistible free applications like Facebook and Yelp that are just fancy Web pages, it becomes clear that selling even 1,000 copies of your application is a pretty big accomplishment.
&
Any enterprise shop would be insane to try to bet their company's livelihood on the iPhone. Oh sure, you've got to dabble in it now because the boss and the boss's boss have snorted all of the hype about the 1.5 billion downloads, but the random approval process is a real disaster for anyone trying to innovate in the simplest way. You've got to be willing to add an extra two or three months of salary for your team after development in order to get approval. Testing is a pain, and if you miss something, your users will be stuck with the old code until you can get a new version past the Iron Curtain.
Vic @ Google is right - the future is Web services on Mobile
cranstone
· 5 months ago
Which points to the Enterprise where the money will be made. After chatting with potential prospects you can see what they want...
1. One platform - the Web 2. One interface - the Browser 3. Access to multiple data sets - the Context
HTML5 is not going to cut it for the Enterprise because it doesn't scale to device side API's and privacy/encryption is an issue. They will look for an alternative solution that leverages their current infrastructure and removes the friction in building and maintaining mobile applications across multiple platforms. It points to a browser based solution.
The next question is what does this solution look like?
isfan
· 5 months ago
I believe one of the key difference of the mobile web is context which can drive impulse behaviour. It is not necessarily a technical difference via fixed web ... but a mental one.
For example, you're at a concert and you want to share the moment with people that aren't there through twitter, pictures and video. Much less interesting the next day through your PC. You want to find your friends at the concert so you use location. You decide to buy a shirt and text a payment so you can just pick up your shirt after the show or have it delivered.
The point is context + impulse is a really big deal and if done right, can be a significant opportunity. At favequest, we're applying these concepts to the events market and are adding such capabilities to our platform.
@isfan
Peter Cranstone
· 5 months ago
Totally agree. All you have to do is remove the friction in the transaction. You have to get the customers "Me" data (Who, What and Where) information without requiring them to type in any data.
You're also right on the whole fixed web vs. mobile web. There is only one web. TBL is correct when he said you should not segment it. The technical issue/challenge to solve is how you extend the current HTTP protocol so that it can accept more contextual data.
The simple way to do that is to add it to the headers coming to your web service i.e. http_x_name "" Then all you have to do is read it at the other end.
Cheers,
Peter
Mark Essel
· 4 months ago
I see this as a great space for businesses to provide value- connecting me data aggregated from different sources (social, location, etc) without requiring manual input.
cranstone
· 4 months ago
Absolutely. And no mobile programming is required. The browser sends the data to the server and all the Web programmer needs to do is read it and the apply it to whatever service they want to deliver.
albert
· 5 months ago
That's a great observation. Also puts a real premium on billing/payments integration.
nelking
· 5 months ago
To get to that spur of the moment decision to buy, all merchants have to begin to accept mobile payments. I have a couple of mobile payment clients, one using the SMS system, the other using RFID in what's is a sticker to put on your phone now, but may be a chip in the handset at some point. Both are partnered with larger players or focused on niches to break down those barriers.
It's very ripe for someone to disrupt, but tough because of the entrenched players.
I'm convinced that smart phone/apps will replace quite a few things in the future, including our wallets.
So those that hold the merchants hold the key.
albert
· 5 months ago
Would love to get rid of my wallet!
markslater
· 4 months ago
aghh - very interesting.
the opportunity is to create a system that allows the SMB to compete. it is reasonably simple. But i am not convinced that it will reside in the APP ecosystem for some time - there are just too many gating items.
Using the SMS platform (present on every device, every carrier and ever country) to build CLI based micro apps is an opportunity that this discussion has missed. SMS has the biggest reach, the programability, the largest user familiarity, the economics, and so on. Its ripe for innovation.
fredwilson
· 5 months ago
so true. i was on a bike ride today and was going to tweet about it when i got off the bike. but i forgot to and by the time i was in front of my computer, the impulse/urge was long gone. so it never saw the light of day
ShanaC
· 4 months ago
Me too,and I am glad to join this party.
markslater
· 4 months ago
this is correct. the opportunity is juxtaposed to the twitter line "what are you doing" and is "what do you need" in real-time. The mobile is the perfect platform for impulse actions - not curration. I struggle with alot of the Apps in this context as they just require too many steps and too much time.
if you combine, context, proximity, and impulse in to a 'what do you need' paradigm, and make it really really simple - as few a steps, as possible, then you have your mobile personal assistant.
Danny Moon
· 5 months ago
With location and proximity being two of the key features for mobile, there is an opportunity for mapping itself to be revolutionized for the mobile experience. Consider that gmaps is essentially the same on the web as mobile yet the needs are very different. Tile maps do not take advantage of touch screens or the processing power of smart phones. Innovative developers can be limited in creating unique location based apps by the base mapping platform they are building upon.
Another area that has a lot of potential is hardware add ons combined with apps built around it. We saw some of this at WWDC and your portfolio company, Bug Labs, seems to be doing this on their own hardware.
Full Disclosure, my company, UpNext (www.upnext.com/iphone) is working on creating better mobile maps.
Peter Cranstone
· 5 months ago
Danny,
Totally agree. Here's the technical challenge - how do I get real time location information INSIDE the browser (the reason you use the browser is so that you don't have to write a mobile app, instead you use one set of business logic that scales across all browsers).
Cheers,
Peter
fredwilson
· 5 months ago
danny - i didn't realize you were working on mobile maps. i have your company in my mind in a different place. i'd love to see what you are working on.
millarm
· 5 months ago
Danny - very true, tile maps are very limiting.
To do mobile map rendering really well you need to render the vector data - in interesting ways.
Another company doing some interesting work in this area is:
Will be interesting to see how active the hardware add-on category will be. Will check out upnext!
Peter Cranstone
· 5 months ago
We're releasing (next 30 days) a Mobile app for the Enterprise that wants to mitigate the cost and risk of extending Web services to mobile. It supports user, device and real time location information, is fully integrated into the native browser on multiple platforms, and the full Enterprise version ($$$) supports encryption and other capabilities. No mobile programming is required to use/deploy this app. It leverages all current Internet standards and integrates into the Enterprise using all standard web app programming techniques.
We're the guys that invented mod_gzip (content acceleration for the web)
Cheers,
Peter 5o9 Inc.
paulhart
· 5 months ago
Quick comment regarding the "real time route guidance" provision... based on the comments made at the OS 3.0 launch announcement, the issue was not with the applications themselves, but with the licensing of the tiles that Google provides.
Indeed, if you search the app store for "G-Map" you'll find a pretty good navigation app (though my wife calls it the "Oops, Sorry!" app thanks to one of its messages).
albert
· 5 months ago
Thanks for clarifying - this is probably due to google's own licensing conditions with their data suppliers.
Jonathan Deamer
· 5 months ago
So many really useless / "me too" apps (especially for music/entertainment brands who know they need to do "something mobile", but don't know what) just seem to duplicate website content or provide a portal for podcasts and videos that are available elsewhere on the web, desktop etc. Music companies (plus bands etc) are some of the worst culprits here.
There's nothing exciting about these apps, so the concept of "native" is really important for some people to get their head round!
markslater
· 4 months ago
agree - i just finally got my iphone. i still text on the thing way more than using apps. its like there is a massive ecosystem of 'nice to have's' not 'must have's' - a great deal of them are cost prohibitive to the average user.
millarm
· 5 months ago
The real-time route restriction was removed in 3.0.
However the mobile opportunity might not be as obviously mobile as the name suggests.
Over 50% of mobile data usage in Europe is actually in the user's own home - where there is a perfectly working laptop! Mobile is as much about "convenience" as it is about super, clever, out and about mobile usage.
This convenience has driven voice revenues for mobile phone operators - as people choose to make calls from mobiles in home - because it's easier as mobile phones have had address books integrated.
The breakout opportunities for mobile applications come from those applications that you choose to use on mobile - even if you are sat in front of your PC. In europe there are great examples of these in voice & SMS.
great point about using a mobile in your home. i got an iTouch to run my sonos and boxee remotes on and now i use it for web browsing, twitter, and a few other things that i could easily do from my laptop which is generally laying around nearby
David Harper
· 5 months ago
@ millarm @albert @fredwilson "Re: Over 50% of mobile data usage in Europe is actually in the user's own home - where there is a perfectly working laptop!"
Some US numbers...
...looking at the last 100 million pages tracked at percentmobile.com we're seeing that 45.7% of the US mobile traffic is via a WiFi-enabled device -- with half of those folks using the WiFi at any given moment. Blackberry and Apple own practically all of that.
albert
· 5 months ago
Wow - that's higher than I would have thought. Thanks!
David Harper
· 5 months ago
sure thing.
albert
· 5 months ago
That is a great point. Have started to do that a lot more myself recently. Among other things makes for the best remote ever!
marc
· 5 months ago
what's the average length of usage of a new mobapp? hardly 6 months. the vast majority of these belong to advanced personalization of handset, that is a more sophisticated ringtone/screen. not a lot to care about so far but they surely plant in the consumer's mind that apps are all "download & forget". too bad for ones like Peter that want to establish themselves durably on the users screens. my take is that what makes an exceptional mobapp is not what additional feature it can provide on top of the PC, but what degree of fun it can provide in the first few days after download. that's the challenge.
albert
· 5 months ago
Don't you think that is more true for game apps? And there no different from PC based games?
ShanaC
· 4 months ago
SO basicly what you are saying that a lot of these apps are in some way "personalization of the phone" and "flash"- They express who we are?
cranstone
· 4 months ago
Yep. It's all about "Me" (whomever you are)
nelking
· 5 months ago
So where do mobile payments fall? Most who live by their cell phone would use it, but until the carriers, phone manufacturers and merchant network make the adoption difficult. I'm curious what USV's current thoughts are on the prospects of mobile payment start up here in the US.
Peter Cranstone
· 5 months ago
I'd use the browser. Simply extend the current web services/app paradigm to Mobile. That way it scales across all devices, can use one set of business logic and reduces risk and costs of deploying standalone mobile apps.
fredwilson
· 5 months ago
I'm a big fan of the mobile browser too but it does seem like the prevailing delivery package today is the mobile app, not the browser
Peter Cranstone
· 5 months ago
Hi Fred,
We're focused on the Enterprise ($$). We wanted a way that an enterprise could reduce their risk regarding mobile app development, and yet take advantage of GPS etc inside a smartphone while still retaining control/privacy over their data.
Let me give you an example using a large engineering/services company. They have 3,000 employees who are all using Blackberry's. These BB's have GPS in them and they want to access that data and use it for their SmartStatus portal which is browser based. They install a simple mobile app that access the GPS data and then makes it available to the smartstatus web portal whenever their employees login using the browser.
Now they've also decided that they want to incorporate Windows Mobile smartphones into the mix to reduce their dependencies on BB's and the BES server. They want to leverage everything they've done and want an identical solution on another platform.
Using this browser approach you can deploy in less than 30 days. The mobile app is cross platform - the interface is the browser so there is nothing new to learn, and there are no programming changes on the portal server.
If we had to build a mobile app with a full UI and make it identical across multiple mobile platforms the cost would huge (100k or more) and may take 6 - 9 months. The alternative approach is web services and a single set of business logic that can be controlled by their existing programming staff.
For more background on why I think the future of mobile is web services here is a great read http://communities-dominate.blogs.com/brands/20... (it's really long). The key section is titled "Software" followed by "Web based services, not apps". Now I usually disagree with the author, however not this time.
Mobile apps might be fine for the consumer (iPhone) but the Enterprise is a more complex beast. All they want is to leverage what they have and reduce the risk. The way to do that and ensure consistency across everything is the browser and web services.
The problem is simple - get the data off the phone and into the browser. Harder to solve than most think.
Peter Semmelhack
· 5 months ago
Peter - I totally agree with you. Everyone forgets that before Windows, ISVs had the same problem with microcomputers. And until there is a similar situation in mobile (which I sincerely hope does *not* happen) the browser/web services/etc represent the only sane way to develop cross device/cross network mobile applications. Otherwise you choose a platform and pray.
Peter Cranstone
· 5 months ago
Exactly.
The ISV is part of our go to market strategy. Why? They already have our end customer (the Enterprise) as a customer. However they have a problem... their margins are getting squeezed because Web 2.0 is a commodity item. Therefore they need to go back to their customers with a differentiator - mobile. Unfortunately they have another problem - where do the find the mobile programming expertise? (they're web 2.0 guys). So we built a Mobile Application Generator (MAGGIE) that works across platform. You can meet with the customer and define the "meta data" they need from the device for their particular service. You enter the data in Excel and then export it as a CSV file. You drop this into Maggie (online SaaS service) and it generates cross platform code for both BB (Java) and Windows Mobile (C++) the other platforms will come later. Now all they have to do is take this code and hook in the api's and you're mobile development is done (bar some final tweaking).
We're just getting ready to release a public domain version of our software. We built both Windows Mobile and BB versions with Maggie. It generates about 75,000 lines of code with debug in about 4-5 seconds.
But I digress. The core problem is extend web services to mobile in the most cost effective manner possible AND reduce the friction in obtaining device side meta data.
Or as you say - pick a platform and pray and that's not a good investment (IMO) unless you're Apple and make your money on everything but the app.
Chris Hamoen
· 5 months ago
Agreed - it is enormously frustrating that there isn't a good native Gmail app for the iPhone. For quick emails via Gmail, the BlackBerry app is still much faster (not incl the keyboard).
albert
· 5 months ago
Mobile payments will definitely be important. It will be interesting to see if Apple can maintain a hold on charging on the iPhone - one click purchasing is clearly an important success factor. That's why folks like Zong are also interesting as they have integrated with carrier billing.
Barry Engel
· 5 months ago
What about the mobile concept of mobile - travel & trip planning, commute - trains, ferries (not driving)? Our take (trainlogic.net) on this is laptops are not convenient when rushing to a train, nor are paper schedules as they get lost, outdated. Then the app can use the phone's GPS to calculate current position vs. scheduled arrival time (am I late?).
Peter Cranstone
· 5 months ago
Barry,
Do you have a web based (browser) version of your train logic? If so our mobile app can send you real time GPS and or Cell Tower information and they you can display the results in the browser.
Cheers,
Peter
Barry Engel
· 5 months ago
Peter, our mobile app already uses the native GPS and mapping from the phone - combined with schedules. Please tell me if you see something else. Thanks! Barry
ruchit
· 5 months ago
Exploring unchartered territories is what startups should focus, mobile or no-mobile.
Vladimir Vukicevic
· 5 months ago
Great discussion. I've been working in this field for a few years now and it's refreshing to see capital sources re-interested in this space.
I believe that a true mobile renaissance will come once the established corporations (healthcare, technology, etc.) really realize what mobile can offer and how mobile is different from the current Internet web-browsing model - i.e. finally view mobile as not just an additional channel but instead a platform for completely new business models.
A good example of this is security on mobile. Up until now security on mobile has been tackled by using established Internet paradigms - boosting encryption, preventing phishing and other scams, etc. Only with the proliferation of iPhone supported LBS applications are companies waking-up to the fact that mobile security requires new dimensions of consideration - such as incorporating LBS capabilities (like enabling location-aware mobile access) with inherent biometric-reading capabilities (e.g. voice recognition or fingerprint photographing). These native capabilities offer great opportunities for greater security and will eventually make mobile security stronger than traditional Internet-based methods.
fredwilson
· 5 months ago
when mobile devices are regularly left in cabs and trains, the concept of security takes on a whole new level of importance.
i like what apple has done with the "locate my phone remotely" feature.
i think "lock down my phone remotely" may be even more important
Peter Cranstone
· 5 months ago
Totally agree. Multi-factor authentication is really important. Our solution supports that. It can access ANY device side api and then share that data in real time (via the browser) with any backend web service that needs is.
David
· 5 months ago
Um, TomTom may have announced at WWDC, but NAVIGON is already delivering a turn-by-turn navigation application for iPhone in Europe. Its already in the appstore.
Peter Cranstone
· 5 months ago
Our mobile app sends device side data (e.g Who I am, Where I am, What device I'm using, What my personal interests are) to any web server. It would be interesting to see if you can deliver train schedules in the mobile browser.
Cheers,
Peter
Peter Semmelhack
· 5 months ago
Food for thought - it's important to keep in mind that mobile apps do not always require human involvement. The amount of interest in machine-2-machine applications is set to explode. These apps do not need a GUI/browser at all and can be based on net-connected CPUs running from within mobile assets such as trucks, ships, golf carts, etc etc. I expect to see some very interesting apps emerge from this space.
christmasgorilla
· 5 months ago
Peter, I think you bring up a really interesting point here that carries over to user apps as well.
A friend (marco @ tumblr) recently commented: "If your location isn’t interesting enough for you to manually write a post about it for some reason, why should your audience spend their time reading about it?"
But the really tough thing about location (particularly for individuals) is when to share and when not to share. Always on location sounds like a nightmare. Which makes me think that your prediction about business and things being the first to make serious use of passive location based services seem spot on.
Ennis
· 5 months ago
I think there will be a greater need for rapid application development and targeted delivery. As a smart phone user I'm checking out the top app downloads to look for cool new apps. The issue here is the apps at the top have nothing to do with native - ie. nothing to do with me, my location, what is happening around me, etc.
Example: I'm a student taking a new university class. The prof. mentions that the class app is ready for use. Students check out the app store, and based on several "native" factors like location or proximity to other students using the same app, the appstore would show the Prof's course application as the top app. Maybe a graphing calculator app that most other students also have is number 2.
I really feel this is how education is going to evolve in academic institutions. This is applicable to conferences or even events like the protests in Iran. Mobile apps are a great way to target how certain data is consumed. Right now though we are using mobile apps like web browsers that only show one website.
The challenge is two fold. Making the development process accessible and easy for the Prof to build an app specific for the course is a tough one. Prof's can barely put together decent one page course websites now.
The second part is distribution. How do you get the appstore to be native and location aware? It's challenging because you need support from the gatekeepers once again. This time it's not AT&T or Vodfone but Apple and Google. Fewer gatekeepers but still the same controlling behaviour.
albert
· 5 months ago
Discoverability of apps is definitely key. Wonder whether educational content like this isn't more likely to be delivered through a broader app provided by the university?
ShanaC
· 4 months ago
Students preregister and do add/drop- it would need to be there before the course started. And be a feel good item for administration, not the students, who have totally different needs. It is one of the reasons why the Kindle Textbook utterly failed in test markets. Really didn't suit student needs at all, because they didn't take a look at the fact that students want ultra portable but very shareable textbooks for studying around. With highlighting and quizzes. Admin tents to be very rigid and have these applications that are bizarre and come from very politicized vendors that allow them to join other consortium,s of schools, etc. Just Bizarre. And Badly done. It is so Bizarre that I actually once got recommended by career to use Indeed because their own out of state listings were so badly disorganized that they didn't know how they fully worked. :-)
Ronan
· 5 months ago
Reasonably accurate location-awareness (and proximity detection) is indeed one of the main differentiators that mobile apps can have over laptops and desktop PC apps.
However the cell phone (mobile phone) is also notable as a notification and billing platform. Mobile platforms have been able to charge for content, where the web has failed miserably (pics, vids, music). Customers don't blink at the idea of paying to send a 140 character message, when email is free for almost unlimited characters.
Put it all together and you have viable business models in paid proximity notification.
Yes - one-click payment and monthly billing are both key capabilities. Does Locle plan to charge that way?
Ronan
· 5 months ago
Yes, Albert, we plan to charge in-app. We're testing user one-click activity, frequency and churn metrics before going live with mobile billing (which has complexities when rolling out in multiple countries, compared to credit card billing).
Call us offline if you'd like to discuss in more detail.
I'm a believer in the intersection of touch & ubiquitous connectivity as the combined killer-feature. It's not just about content consumption- you can do really amazing (rich, detailed, structured, intuitive) human-powered data capture on these devices.
At GameChanger we use the term "User Collected Data" to distinguish that from unstructured UGC. Things that used to require paper input, laptop tabulation, or heavy/expensive/complex recording equipment can now be accomplished on-location with one hand free.
EricFriedman
· 5 months ago
As people get more comfortable with devices as data input, I believe we will see many more use cases of UCD in the field. Any in your case Kiril, the baseball field :)
rohun
· 5 months ago
Great post. One key "native" functionality I think you forgot to mention was the fact that our mobile devices have access to our contact list. I know in my case my BlackBerry often times contains the most current set of contacts I have (I can't wait until they put Xobni on BB--should be similar to how Palm's WebOS can auto-detect details from Exchange, Facebook and LinkedIN).
It's the intersection of your media assets, location data, contacts list, audio/video/touch inputs and data connectivity that make the mobile device the ultimate "social tool".
albert
· 5 months ago
Maybe some day we can even figure out how to finally do away with business cards ...
rohun
· 5 months ago
Absolutely! I generally don't keep them as is. If I end up doing business with someone, I tend to add them to my LinkedIn or Outlook Contacts. After that if they change jobs I am usually covered on finding their new contact info via LinkedIn/Xobni.
ShanaC
· 4 months ago
I think you underestimate the power of touch, which is inherent to the power of giving and receiving a business card. Placing an item in someone's hand is important, and a very hard concept to duplicate on via the web. One of the most interesting thing about touch devices is how much further can they push the idea of "my native touch"- where it is locked to my biometric. Only then could something like a business card be replaced- but I would be giving you my identification with my touch.
cranstone
· 4 months ago
BINGO!
Right on the money - it's all about Trust... the phone will soon have a biometric sensor (the banks will want it for multi-factor authentication). It's "My" Touch - so how do you transmit my touch over the web?
Here's the header that does it - http_x_biosensor="..." That's it. The beauty of this approach is that anyone with a web server can read it - (it makes the web smarter)... in addition you only send your touch to those you trust. (Controlled by a whitelist in your browser)
ShanaC
· 4 months ago
Very Exciting and very nerve-wracking. It reminds me of why I wanted to learn the Tango, and why I ended up learning to Salsa.
Just Biometrics are not enough. We tend to ritualize touch and the mediums surrounding it in order to feel secure. fter all, the body is our more personal space. Beyond creating a mthod of sending and recieving biosensory metric, is the backend powerful enough to handle the sheer amount of data embedded in one fingertip, let alone the data that comes with ritualization that would come with sharing touch and biometrics (pressure sensitivity that is unique to each person, ect)
cranstone
· 4 months ago
I've always been an advocate for using the back end to do the heavy lifting (mobile processors are always going to be limited due to battery life). That's where all the processing power is (and will be). Your Me data is not very big when digitized and compressed, it's measured in bytes. You'd be surprised what you can send in as little as 16k. To give you some idea - this page with all the comments and graphics etc is over 1/2MB - that's way too much to send to a mobile device. The goal is around 10k and then if the user wants more already have it compressed and cached ready to go. (Remember the 2 second download rule - which equates to about 10k)
ShanaC
· 4 months ago
Very exciting and very nerve wrecking. It reminds me of why I want to learn to Tango. Just biometrics are not enough. We ritualize touch on the front end to make ourselves feel secure. Can your work handle those lovely nuances of human behavior that make life so exciting.
Sakthi
· 5 months ago
How about Mobile Apps leveraging Cloud? Does anyone see this opening up new use cases?
For example - your mobile application can "burst" into the cloud to access compute / content that was not there two years back (thanks Amazon).
The missing link between a PC and a phone is the spreed of the internet connection. Mobile connection is still patchy and the speeds don't come close to 1GB LAN / 10MB WAN connection that we are used to. And economics and technology for the Carriers to upgrade their networks is just not there.
EricFriedman
· 5 months ago
I agree this is an opportunity, but I see the mobile web as the regular web as devices catch up to the power of a desktop browser. As ubiquity of these devices grows I think you will see less sites that have to have a specific mobile solution - just mobile browser solutions. Bandwidth will play a large role in this process as well as the US rolls out 3G widely and plays catch up to the rest of the world.
Vladimir Vukicevic
· 5 months ago
Although you are correct that some Mobile Network Operators in the U.S. and the world have lost their role as gatekeepers (particularly the GSM carriers) application development and rollout on mobile is still much more difficult than web development.
This is due to a few important and evolving factors: - In the U.S., half of the mobile market is still dominated by CDMA technology (Verizon, Sprint, and a few other minor carriers) - most CDMA phones (not including the new Palm Pre) still run on the old BREW operating platform which is horrendously difficult to develop for due to Qualcomm's control of it and a few other limiting factors. Also, CDMA phones don't have SIM cards so unlocking is more difficult. - Mobile phone operating systems are still highly fragmented in the U.S. and globally - although the world is still dominated by Nokia phones and thus Symbian. - Smartphone handsets and hardware are still highly fragmented as well - from actual phones to added features like NFC chips. - Smartphone penetration is growing but still only represents 10-20% of all phones in the world (depending on the market that range fluctuates) - Consumer habits are a little wacky when it comes to mobile adoption - i.e. it took a decade for U.S. consumers to embrace SMS communication
There are some other minor barriers as well. I list these not to be negative but instead to highlight challenges that if a start up is able to overcome, would then give that start up a major advantage in the marketplace.
Peter Cranstone
· 5 months ago
Very well stated. A mobile app per se is not a sustainable business model. You have to dig much deeper to uncover the real customer problem. And even when you figure that out, marketing, distribution and price sensitivity all play a big role. Finally don't forget integration - that's a far harder problem to solve the fragmentation.
Vladimir Vukicevic
· 5 months ago
What do you mean by integration in this context?
Peter Cranstone
· 5 months ago
Vladimir,
We faced a unique set of challenges when we built our solution. We use the mobile browser to communicate user, device and location information from the Smartphone. We add the meta data to the outgoing HTTP headers. Our issue was twofold - how do we protect the privacy of this new data and how do we integrate it into the Enterprise back end without requiring Admins to learn anything new. (We solved the problem by creating generic headers which can be read by any script and then you use CGI to pass the data to any back end service that needs it (mash out). This is different from device fragmentation. Which requires that you test on lots of different devices. We don't have that issue because we're "inside" the browser.
Vladimir Vukicevic
· 5 months ago
But even though you're inside the browser isn't fragmentation still an important issue? How did you manage to optimize the look-and-feel of the interface (whatever that might be) for all the different screen-sizes and form-factors (touchscreen, the BlackBerry ball, etc.)?
Peter Cranstone
· 5 months ago
That's the best part. Our mobile app tells everything we need to know about the device in real time. We know the carrier, the os, the browser height, the browser width, we know the screen dimensions, the number of pixels supported etc. All we do is aggregate that data and then send it to the web server as part of the web page request. Once it arrives there we can determine exactly what the page needs to look like. We also came up with a way to add "custom menus" to the browser using simple HTML. Go to this page (www.5o9mm.com) and do a view source in your browser. Looks near the top for the new meta statements. Whatever you see there now shows up in the mobile browser menu. This improves navigation and frees up the browser screen for more useful information. In essence the browser starts to act as a Rich Internet Application without the need to invent a new UI (user interface).
deancollins
· 5 months ago
My Question for you Vladimir...... why develop only for the USA? it's such a small market globally.
oh snap i hear all the Apple fan boys getting excited already.
My point being that there are lots of mobile os's and lots of countries.
Now that China Mobile has opened up their app store to their 500m users are any of you going to be submitting your apps for international consumption?
I agree with you completely. The US is very limited. But tell that to VCs that have invested $100 Million in iPhone startups.
It also depends what type of company is developing the app - if it's a bank only located in the US then it might not make sense to think internationally. I used the US example since it's the easiest to outline.
If someone can figure out a killer app for Nokia's Ovi then they could reach 10x the market that the iPhone has.
deancollins
· 5 months ago
$100m isn't that much relatively considering smartphones is a prevalent device most people use (eg should be in comparison to a device like television) + I really doubt most VC's have spent their 'load' yet (ha ha 5 companies in 12 months what a joke http://deancollinsblog.blogspot.com/2009/03/kle...).
Also you thinking is flawed
"A killer app on the iphone is likely to be a killer app on an Android device and vice versa".
Also
"A killer banking app for Bank of America is likely to also be a killer app for Allianz Dresdner bank".
Expand your mind.... think globally - can you imagine if the Australian CSIRO scientists who invented wi-fi thought "Australian Only"?
IMHO the killer app has already been invented. It's the browser. It connects to any web service AND is device and OS agnostic. It removes the fragmentation issue and allows a single set of business logic to be extended across the three screens of the future - the PC, the TV and the MC (mobile computer). Building an app into a measurable sustainable, revenue from volume business is incredibly difficult. In fact no one has done it. Extending current and future web services to mobile and allowing then to access all the current and planned capabilities of the device is a scalable business model. The critical aspect is to remember to ensure that you protect the privacy of the end user (be it the mobile employee or the mobile customer)
Here's the key section... “Mobile application developers today face the challenge of multiple mobile operating systems,” says senior analyst Mark Beccue. “Either they must write for just one OS, or create many versions of the same application. More sophisticated apps require significant processing power and memory in the handset. Using Web development, applications can run on servers instead of locally, so handset requirements can be greatly reduced and developers can create just one version of an application.
Exactly on point. One set of business logic, one display/UI interface and device and OS agnostic. This is the future of mobile.
Now all that remains is to remove the friction point of what's known in the trade as "Device and Terminal Capabilities" in real time.
Here's an example. My BB has a browser and an on board GPS. So why can I NOT access that GPS data and send it to any web server of my choice?
The problem is harder to solve than you think. (And no the current W3C Geolocation API is not the correct answer - it's only a partial answer as it does NOT address other device side capabilities e.g. bio-metric sensors)
Here's the key section... All that would be needed are some Javascript extensions to give access to the phone capabilities, in particular location, the camera, making calls and cross-app communication (including access to built-in apps such as the address book).
Now let me pose a question to everyone who is following this thread... "What if the above happened for every mobile device?"
The web service would emerge the winner over the mobile app overnight. Why? One set of logic and millions of JavaScript programmers out there who can no access mobile device data without knowing (or needing to know) how to program a mobile phone. The other killer app here is that JavaScript is "Open Source" so that everyone can see the calls that are being made. It becomes like HTML.
fredwilson
· 5 months ago
I agree. But you knew that
albert
· 5 months ago
Agree - well maybe due to Chrome OS we will get there faster!
cranstone
· 5 months ago
Not so sure... Let's put a VC hat on for a moment. What problem does Chrome OS solve for whom? What's the revenue model, what's the distribution strategy, (you're going to need an OEM because of all the driver issues and you definitely want it pre-installed). What about the competition? Windows/Mac/Linux - all are so well entrenched that it's going to be almost impossible to change "consumer behavior" unless the value proposition is off the charts. The only one I can think of is "Free" and if that's to work then it has to perform light years ahead of anything else.
I'm sorry I just don't see Google putting that kind of effort into something that has already been done.
I never forget something Steve Balmer said... there are four stages of a company, think it up, scale it, milk it, think it up.
Google is now at the think it up stage - they have done it once with search and adsense... now they are literally in "search" of the next big thing. I can't imagine a VC anywhere in the US investing in a general purpose operating system. So personally I think it's a head fake - Schmidt just wants to go up against his old foe (he will lose). In the meantime we have to pay attention to what they are not telling us. Therein lies the next big thing (maybe)
fredwilson
· 5 months ago
I love the "think it up" line. Great stuff
I don't understand why apps are not the next big thing for goog. I've moved myself off all the msft apps onto goog apps and I am so much happier
Web apps rock
cranstone
· 5 months ago
Welcome to the Paradox of the Middle Market. In the middle market people (customers) want tried, tested and boring. The only thing tried tested and boring about Google is search. It works, and works and works. No behavioral changes are required and there is a consistent user interface (a search box) for everyone to use. Their core DNA (IMO) will always be web apps... the issue is stability and a consistent user interface. So what they've done with the desktop apps is a great first step (although I think Microsoft will beat them) simply because designing UI's that work is really hard. Now lets jump back in the mobile pool for a moment. I don't believe Mobile apps scale. Simply because of the UI issues and the ability to make money across all platforms. Personally I think web services are the future of mobile (partly because of security issues and the ability to keep sensitive data OFF the device and in the cloud). The problem is that nobody (think middle market here) needs to write a document or do excel spreadsheets on mobile. Mobile is about finding (not searching or browsing). You have to remember the 0-1-2-3 rule
0 behavioral changes 1 login 2 second response time 3 clicks to relevant content
The browser can fulfill this - a mobile app can't.
So I believe Google is doing lots of head fakes while they remain focused on their core DNA... web apps (like we use on the desktop browsers) are too cumbersome for mobile - so they will come scaled down for mobile.
It all boils down to three things...
One platform - the web, One interface - the browser Multiple data sets - the context.
What I believe you will see happen is that the mobile browser will become more of a rich internet application. Browser menus will change "in real time" based off the context of the user and of the web service they are accessing.
Right now all you see in the browser menu is the standard fare - imagine going to www.starbucks.com and the second you hit the page the browser menus now change to ... find closest location, get driving directions, top up your loyalty card. It's all about 3 clicks to relevant content.
A web app can deliver that - it just has to become more aware of the users context.
Vladimir Vukicevic
· 5 months ago
I think the simple answer to this question is - because mobile adoption didn't evolve like it did for the PC.
The PC established both formal and informal global standards before personal PC penetration was significant. Mobile penetration has grown to a much higher percentage without any real standards - protective gatekeepers, different core technologies (GSM vs CDMA), different hardware, and different operating systems - on top of that, complicated data plans and a confused consumer base.
You're looking for a technological solution for an ecosystem-problem.
fredwilson
· 5 months ago
This is the point albert made about android beeing too app centric. He has a follow up post today on his blog about android and chrome OS and the competing visions they represent inside of google
cranstone
· 5 months ago
Good old Google is playing both sides of the fence (because they can). They are copying the others and delivering an app centric model (for the moment). The problem with apps is that they don't scale past Android (who wants to build apps cross platform - it's really hard work and fraught with risk). Google at it's core is a cloud company aka Web services. They know that the future is the browser because it's device and OS agnostic. So ultimately the app approach will fade as new web services come on line and people gravitate to the browser.
Now here's something to think about - what if every mobile browser had the capability to send real time location information and some personal keywords and or preferences to Google every time someone did a mobile search. The value of their ads would jump overnight and the second revenue stream would start to kick in. Right now (just have to wait a few more weeks) there is no way to easily share additional mobile meta-data with Google from within a browser AND also be able to share that data with any other web service. (Google's Mobile Maps app can access location data and do search - but it can't share that location data with any other app or service - hence it doesn't scale).
IMO it all ends up in the browser - because it's what the middle market (not the techies) understand. And that's where the real money is. (And the Enterprise)
fredwilson
· 5 months ago
Word. Chrome OS baby
Vladimir Vukicevic
· 5 months ago
And the plot thickens...
David Semeria
· 4 months ago
I disagree that Chrome OS will move the market for browser-based apps forward. All innovation must come from inside the browser, not outside.
I think the main logic for Chrome is to dent Microsoft's war chest.
I think the issue for Google is that they want control over the end to end points in their ecosystem. They don't want to wake up tomorrow and find out that IE doesn't support something they need. The world doesn't need another browser - Google wants an insurance card against someone doing to them as what Microsoft did to Netscape.
As for the innovation coming from inside the browser - yep. HTML 5 is a start in the right direction - but it's not enough. The browser should be able to read the entire device side api... only when it does that can you really innovate.
fredwilson
· 4 months ago
I totally agree with that last point. Its a big issue
Vladimir Vukicevic
· 5 months ago
$100 Million is a lot more than VCs have invested in Ovi or BlackBerry app world applications. Either way, my point wasn't that this justifies the focus on the iPhone (and thus the U.S.) but instead that there IS a focus on the iPhone (and thus the U.S.). That's a big difference since I agree with your point, a global perspective gives much greater opportunity.
Also, I never tried to make either of the two points you outlined. My point was that since a lot of us sit in the U.S. that is the marketplace we know best and thus can analyze the best. This is true for companies who primarily target customers in the U.S.
I agree with you that global sources should be leveraged to foster innovation. I don't agree that a global rollout of a new mobile application is possible without taking into account extreme local differences (in technology, customer preference, etc.). "Think globally" might be a catchy motto but it's not an easily attainable strategy.
Peter Cranstone
· 5 months ago
Agreed on the global roll out. VC's will want to see you conquer a market vertical in the US before they fund international expansion.
As a mobile developer we've focused on both local and global capabilities. We leverage the browser which is already global and then designed the app so that it could be easily "ported" to other languages. It wouldn't take more than 30 days for any country and the cost would for a translator to figure out how to say "Location Information" (and a few other menus) in whatever language is required.
The rest is all about web services. Much less risk that way.
deancollins
· 5 months ago
> "Think globally" might be a catchy motto but > it's not an easily attainable strategy"
I guess when you are not looking for the opportunities thats a 100% correct statement.
Guess Apple should stop trying to export their iPhones and Nokia better stick to selling phones in Finland.
Vladimir Vukicevic
· 5 months ago
Some do it better than others. Although Nokia has a significant market share in Europe, it has a tiny footprint in the U.S. The same is true for the iPhone in the U.S. vs certain Asian countries.
It's possible, and if done right could be very lucrative - but it's not easy to do right.
deancollins
· 5 months ago
ha ha, you dont know your mobile market very well, nokia ships more handsets in a quarter than apple does in a year. they have a massive share in europe, india, asia etc etc.
yes iphone is 'neat' but it's very usa centric and globally still a small percentage.
stop reading admod reports....it's all BS. start researching handset shipping numbers if you want a more accurate picture.
Vladimir Vukicevic
· 5 months ago
Dean, please read my comment a bit more carefully before looking to jump all over it: "Although Nokia has a significant market share in Europe, it has a tiny footprint in the U.S." No need to get defensive about Nokia - they're a big company, I know that :)
Never did I say that the iPhone outsells Nokia just that they face an inverse position - i.e. the iPhone is powerful in the US but not elsewhere, like Nokia is powerful outside the US but in the US. This was to strengthen my point that global dominance is difficult.
Listening (in this case, careful reading) is very important if you want to make a strong counterpoint... "it's a good practise."
Peter Cranstone
· 5 months ago
Vladimir,
You're point is well taken. There really are 4 main horsemen - Nokia/Symbian, Microsoft/WM, RIM/Blackberry, & Apple/iPhone (in that order). The late comer to the party is Google/Android (not sure where that is going to end up).
IMO successful mobile "app" companies will have to run on all 4-5 platforms to scale. but hey - the market is huge and is growing faster than the PC marketplace. Good times (if you understand how to code on a mobile device)
fredwilson
· 5 months ago
And palm is hosed? I'm curious what you think because you left them out
cranstone
· 5 months ago
Nope - Palm is not hosed (yet). IMO it's all about "Risk". WM & BB are in the Enterprise (where the real money is). So those are safe bets. Get some traction there and then think about the alternatives. Symbian is a no brainer because they have 50% + of the market. What remains is Palm and Apple. Apple controls everything and if your app gets a NO then you're out of business. Too much risk there (and no money). Which leaves Palm and Android. Motorola (3rd largest handset Manufacturer) has placed it's bet on Android but hedged with WM (Enterprise). So the next play comes down to two things - distribution and market share with "YOUR" target customer. As we have developed a browser solution we can afford to wait and see who wins - if the Enterprise adopt Palm we simply port there before Android or vice-versa.
deancollins
· 5 months ago
I did a quick search on my pc for some facts to back up my statement - yes it's out of date being 4th quarter 2008 and i could go and research 1st quarter 2009 but you get the point.....
Company 4Q08 Sales (1,000s) - MarketShare (%) Nokia 118,791.0 - 37.7 Samsung 57,517.9 - 18.3 LG 28,140.9 - 8.9 SonyEricsson 23,554.1 - 7.5 Motorola 21,700.1 - 6.9 Others 65,003.8 - 20.7 TOTAL 314,707.8 100.0 http://www.gartner.com/it/page.jsp?id=904729
See that section for 'Others' at 65m handsets in Q4 2008....thats where Apple and the iPhone go, but they are also sharing it with HTC, etc etc
lol so Nokia ships 118 million handsets in Q4 2008 and you think 'they are just in europe'.
iPhone is a blip on the mobile timeline, heck i remember when the Motorola startac was 'it'.
Stop living in an echo chamber..... it's a good practise.
Cheers, Dean
fredwilson
· 5 months ago
That's one reason that we've started in invest in europe. The VC industry is moving international. Many firms have operations in asia, india, and israel
VC is a local business. But it should happen on a global scale and that is happpening
chucksacco
· 5 months ago
Let's not forget that very common feature on these data devices: the ability to make a phone call to a person (or machine in the case of many customer service operations these days).
So integrating native or web apps to the device's calling feature may seem pretty basic, but is also very easily overlooked. Note how few mobile apps display a phone number in a "prominently clickable" fashion.
Lots of businesses out there still want your phone call ahead of your anonymous data click. There will be some breakthrough apps that make the calling process integrate really well with the data features.
albert
· 5 months ago
Great point. We listed audio, but just as you said "overlooked" the ability to place a call right out of an app.
eliafreedman
· 5 months ago
I'm a little late to the discussion, but it strikes me that this post is completely focused on the technologies. I'm not certain mobile has to always solve new problems for them to be huge, but instead we can use a smattering of new and old technologies to focus on problems of primarily mobile people, to solve their problems in new and unique ways.
albert
· 5 months ago
Completely agree that targeting primarily mobile people is a big opportunity, but this still comes back to figuring out what can be done now that could not be done before. So not saying new problems need to be solved can be old problems but using new ways.
Peter Cranstone
· 5 months ago
I think everyone is missing the really big opportunity - the Enterprise. They all have mobile devices - who is developing solutions for them?
cranstone
· 5 months ago
Some food for thought can be found at this link: http://www.edgellcommunications.com/main/index.... - you have to fill out a form to get the document titled: Embracing Next Generation Mobile Platforms. The paper is sponsored by Sybase. They almost get it right, but stop at mobile only. What is really needed by IT is a single development platform for all devices – not just mobile. In my opinion this is where Web services can excel. They just need a cost effective way to extend to mobile devices (cross platform). Pay close attention to Fig 3 which talks about the challenges of developing and deploying mobile applications. What if they (the Enterprise) didn't have to build a mobile app? What if they could simply extend their current web services to support real time meta data coming from the device via the browser. The risk of moving to mobile would be greatly mitigated.
fredwilson
· 5 months ago
Thanks for the link. I'll read it
cranstone
· 5 months ago
Hi Fred,
Some more reading for you if you’re interested. This link http://communities-dominate.blogs.com/brands/20... talks about Why Location-based spam ads will fail, but also LBS-based event ads will succeed.
Personally I don’t believe he’s totally correct but if you read between the lines you can determine the core technical problem. It’s all about context. LBS based event ads are based on the context around you wanting to be at the event i.e. that’s information about you. Location based ads on the other hand have no context about you other than you’re somewhere. In plain speak “insufficient data”.
Next check out this link: http://www.seobythesea.com/?p=540 which talks about all the patents that JumpTap has recently filed related to Mobile search. What’s interesting here (as you scan the abstracts) is that context is the “key” that unlocks relevance. (JumpTap shares revenue with the Telco’s in exchange for context around the user).
If you’re still in the mood to read go to this link: http://www.ietf.org/rfc/rfc2616.txt - it’s the Hypertext Transfer Protocol (the protocol that runs the Internet - don’t worry you don’t have to read all of it) just scan down to “12.1 Server-driven Negotiation”. The good stuff starts here:
Server-driven negotiation has disadvantages:
1. It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?).
2. Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential violation of the user's privacy.
3. It complicates the implementation of an origin server and the algorithms for generating responses to a request.
Now think about this…
What if it was possible to determine “what might be best” for any given user in real time?
What if you could solve the privacy problem (this is Albert’s dilemma when he talks about Google/Android opening up JavaScript access to the Mobile device)?
What if the origin server didn’t have to add anything to generate the response other than a simple script?
What if you could do this for the 225 million Web servers that are out there and not require any changes to the current HTTP protocol (rfc2616)?
What if worked across every Mobile device?
ShanaC
· 4 months ago
Something very simple that Never is discussed here- Effectively, at some point, the phones delieve what computers do, at a much smaller scale. Yet we feel about them and treat them much different, so we want much more dynamic data on them.
It isn't so clear to me that as the actual phone (the item) develops, that individuals won't understand that effectively they hold a mini computer that makes phonecalls, making this discussion a bit moot- or that the reverse is true as well. This is very much a wait and see game. That is very high stakes. A lot of this plays out on how we choose to physically design the next generation of computers as well.
cranstone
· 4 months ago
Dynamic data is critical to the customer experience - for instance as my location changes so should my search results. The phone is the marriage of content and contact in a mobile computer. Attach it to the ultimate platform - the web and let the innovation begin.
It used to be the World Wide Web (www) - as the data becomes more dynamic it becomes Who am I, What am I, Where am I.
fredwilson
· 4 months ago
The funny thing about the iPhone is its an amazing computer but a horrible phone
David Semeria
· 4 months ago
I agree completely with Peter Cranstone when he says the browser will become the de-facto platform on mobile. Deep down, even APPL knows this. I also agree that before browser based apps can really take-off, they need access to the additional hardware available on phones.
However, whilst I agree that app-specific plug-ins are a barrier to adoption, general-purpose plugins (eg Flash) have faired a lot better. I would therefore suggest someone write a general-purpose plug-in which exposes this type of functionality to the browser execution environment (js).
One point that was not really touched on in the discussion is the limited bandwidth available to mobile phones. Even with the advances made in network throughput, there is still the problem that the limited spectrum must be shared with other users in the same cell. Basically, mobile phones will always have slower connections than hardwired devices (unless something really radical happens).
This has big implications on the delivery of complex browser-based applications, because the entire code base must be delivered to the phone even if only part of it is used. A better solution is to inteliigently deliver the relevant pieces of code and content in a pre-emptive manner to the mobile browser. This makes applications boot faster, and run with siginficantly reduced latency. Since people are none too shy when it comes to talking up their own book in this thread, I could add that my company has developed pat-pending technology to do just that.
This issue is connected to the wider problem of intelligent bandwidth usage and caching. As far as mobile is concerned, one of the most interesting parts of the HTML 5 spec regards native support for a local database. If I were a VC, I would be actively seeking out companies developing technology to leverage this functionality to create a smart mobile cache. It is the missing piece of the jigsaw. The smart cache would silently sync both code and data on the mobile device with that on the relevant remote servers - and would have an unbelievable impact on the power, complexity and performance of mobile browser-based apps.
fredwilson
· 4 months ago
Great comment. Lots to chew on in it
cranstone
· 4 months ago
David,
Have you been reading my emails ;-)
>> I would therefore suggest someone write a general-purpose plug-in which exposes this type of functionality to the browser execution environment (js).
Done. Just going through the last stages of testing. You will be able to write simple javascript that can do exactly what you want above.
With regard to bandwidth. This I do know a little about as my partner and I are the inventors of Mod_Gzip which is the standard for content acceleration for Apache web servers.
Our new mobile solution (Mod_Mobile) supports even more advanced content acceleration techniques and is also designed for something which you hint above... the ability for the server to stop the transmission in real time and request additional information from the device.
This is critical and up until now has never been done before. But it all goes to exactly what you are talking about. You (the web server) should send as little data as is required to deliver a great customer experience and if you need more data for instance to complete a mobile ecommerce transaction then you should be able to request.
In addition you should have to wait until HTML5 comes along (which by the way cannot do this) it should work seamlessly with everything that is already out there.
David Semeria
· 4 months ago
The plug-in sounds interesting. What platforms does it support?
Re mod_mobile, I don't quite understand how it works, but in my view the only real solution to fast booting and pre-emption is via program architecture.
Also, whilst I don't know too much about mobile browsers, many parts of the HTML 5 spec are already implemented in the 'quality' (big web) browsers.
cranstone
· 4 months ago
It's designed to support all of them. It will be released on Blackberry and Windows Mobile with Android to follow. After that will come Symbian and hopefully iPhone if Apple ever allows an app to run in the background. If not we'll focus on the other 95% of the marketplace.
>> but in my view the only real solution to fast booting and pre-emption is via program architecture
Totally agree - Mod_Mobile is on the server. Think of it as a grown up version of Mod_Gzip which currently runs on millions of servers.
On the client side we're part of the browser and sit on top of the OS. We're live all the time, there's virtually zero latency as we collect the data and send it.
RE: HTML5 - it's coming to the big desktop browsers - it will be several years before you see it on a mobile device. Even then I hope we will be able to fill in the gaps it doesn't serve.
Ian Hickson
· 4 months ago
Some features of HTML5, e.g. the offline application cache, and some features of contemporary specs sometimes referred to as "HTML5", e.g. geolocation, were actually implemented and shipped on mobile browsers _before_ any desktop browsers shipped with that feature.
cranstone
· 4 months ago
Only on the iPhone - and the geolocation can't access "other" device side api's such as sim card, browser height, carrier network etc.
cranstone
· 4 months ago
One other follow up item - our approach is to support phones with older OS's and older browsers hence the need for a mobile client. Over time as HTML5 becomes more prevalent it will be interesting to see what other API's they allow - they being the W3C. We didn't want to wait for them so we've implimented an approach that allows access to any device capability - which also scales to future phones that add bio-metrics and also the ability to read blood pressure via a bluetooth sensor. Our solution is already compatible with that.
srw
· 4 months ago
Some more rants:
1. Audio Web Navigation: Many times, while I am walking listening to music, I prefer to navigate Internet hearing the web pages instead of looking to the screen. There are many scenarios where you are doing something else and don't want to be 'attached' to the screen and touch interaction. Text to Speech is really good right now (just look at AT&T Natural Voice), while Speech to Text is far from perfect, but for simple navigation can be fine. I see it as a native mobile application since when you're in front of your computer a visual browser is the obvious solution.
2. Retrieving/Storing/Controlling other devices: iPhone did a good think to incorporate a Hardware API for their connector. I think putting your mobile phone in your car, robots, and in other equipment to store/retrieve/control.
3. Portable media machine, including downloading torrents and playing them anywhere. I found using a notebook on a hotel for this purpose is overkill.
4. Automatically converting your mobile phone on an extension number when you're in the office. Currently it's very difficult to do on many platforms (it's possible on Windows Mobile, Android). I want to receive calls from Asterisk PBX to my mobile phone without depending on another device.
5. Digital Security and Payments: Want to use the mobile phone as a smart card to log into different places and pay stuff.
8/ Portable Surveillance for your baby (and other uses)
9. Proyector: There are some companies working on this, every hotel has a TV but proyecting a movie from your mobile phone can work.
10. Mixing with other elements like that Microsoft Table (surface). You can play your [cards] game showing your cards on the table (or on a TV)
but right now, I need the (1).
fredwilson
· 4 months ago
Those are some good ones. Thanks for sharing them with us
srw
· 4 months ago
I forgot 11!
11. Need to quickly scan the office's whiteboard and convert its diagrams plus ocr. Obviously going further than evernote. Ala Xerox Parc et al research.
fredwilson
· 4 months ago
I've done this with my blackberry's camera. It doesn't work too well
srw
· 4 months ago
I think the 'trick' is to have an application to automatically merge some few photos into one. I've used my iPhone camera (2mp) with success taking 3 pictures of our whiteboard.
Jeff Johnson
· 1 month ago
This Convo is a bit over my head, but I have been working on a Mobile Fitness Web App since 2006. I'm not a developer but I came up with the concept for use on the iPod. When Apple wouldn't let me use the iPod I had to come up with another solution and that was a web app. We have recently went Closed Beta with ongoing development. Our plan is to incorporate external devices to be used with the app (i.e. Heart rate, pedometer). This discussion has given me some confidence in my business plan. Thanks everyone!
albert
· 1 month ago
Glad to hear that that the discussion is helpful to an entrepreneur - that's one of the reasons for us to write these posts!
All Comments
That's exactly what our solution was designed for. It essentially a mobile app with an Open API. You can attach a sensor to the phone via Bluetooth, transmit that data to our app and then we send that data (you have complete privacy controls) to any web server. The way we do this is to take the meta data and add it to the outgoing HTTP headers. So now all you have to do is read the incoming data at the server. We even have a windows mobile version that you can now access any device side data using JavaScript all from within the mobile browser.
Works like a champ.
A couple of key paragraphs:
There is every indication that the App Store doesn't contribute very much to the bottom line of many developers, either. If there are 65,000 apps and 1.5 billion downloads, the average number of downloads is about 23,000. If you subtract some of the irresistible free applications like Facebook and Yelp that are just fancy Web pages, it becomes clear that selling even 1,000 copies of your application is a pretty big accomplishment.
&
Any enterprise shop would be insane to try to bet their company's livelihood on the iPhone. Oh sure, you've got to dabble in it now because the boss and the boss's boss have snorted all of the hype about the 1.5 billion downloads, but the random approval process is a real disaster for anyone trying to innovate in the simplest way. You've got to be willing to add an extra two or three months of salary for your team after development in order to get approval. Testing is a pain, and if you miss something, your users will be stuck with the old code until you can get a new version past the Iron Curtain.
Vic @ Google is right - the future is Web services on Mobile
1. One platform - the Web
2. One interface - the Browser
3. Access to multiple data sets - the Context
HTML5 is not going to cut it for the Enterprise because it doesn't scale to device side API's and privacy/encryption is an issue. They will look for an alternative solution that leverages their current infrastructure and removes the friction in building and maintaining mobile applications across multiple platforms. It points to a browser based solution.
The next question is what does this solution look like?
For example, you're at a concert and you want to share the moment with people that aren't there through twitter, pictures and video. Much less interesting the next day through your PC. You want to find your friends at the concert so you use location. You decide to buy a shirt and text a payment so you can just pick up your shirt after the show or have it delivered.
The point is context + impulse is a really big deal and if done right, can be a significant opportunity. At favequest, we're applying these concepts to the events market and are adding such capabilities to our platform.
@isfan
You're also right on the whole fixed web vs. mobile web. There is only one web. TBL is correct when he said you should not segment it. The technical issue/challenge to solve is how you extend the current HTTP protocol so that it can accept more contextual data.
The simple way to do that is to add it to the headers coming to your web service i.e. http_x_name "" Then all you have to do is read it at the other end.
Cheers,
Peter
It's very ripe for someone to disrupt, but tough because of the entrenched players.
I'm convinced that smart phone/apps will replace quite a few things in the future, including our wallets.
So those that hold the merchants hold the key.
the opportunity is to create a system that allows the SMB to compete. it is reasonably simple. But i am not convinced that it will reside in the APP ecosystem for some time - there are just too many gating items.
Using the SMS platform (present on every device, every carrier and ever country) to build CLI based micro apps is an opportunity that this discussion has missed. SMS has the biggest reach, the programability, the largest user familiarity, the economics, and so on. Its ripe for innovation.
if you combine, context, proximity, and impulse in to a 'what do you need' paradigm, and make it really really simple - as few a steps, as possible, then you have your mobile personal assistant.
Another area that has a lot of potential is hardware add ons combined with apps built around it. We saw some of this at WWDC and your portfolio company, Bug Labs, seems to be doing this on their own hardware.
Full Disclosure, my company, UpNext (www.upnext.com/iphone) is working on creating better mobile maps.
Totally agree. Here's the technical challenge - how do I get real time location information INSIDE the browser (the reason you use the browser is so that you don't have to write a mobile app, instead you use one set of business logic that scales across all browsers).
Cheers,
Peter
To do mobile map rendering really well you need to render the vector data - in interesting ways.
Another company doing some interesting work in this area is:
http://www.cartotype.com/
We're the guys that invented mod_gzip (content acceleration for the web)
Cheers,
Peter
5o9 Inc.
Indeed, if you search the app store for "G-Map" you'll find a pretty good navigation app (though my wife calls it the "Oops, Sorry!" app thanks to one of its messages).
There's nothing exciting about these apps, so the concept of "native" is really important for some people to get their head round!
However the mobile opportunity might not be as obviously mobile as the name suggests.
Over 50% of mobile data usage in Europe is actually in the user's own home - where there is a perfectly working laptop! Mobile is as much about "convenience" as it is about super, clever, out and about mobile usage.
This convenience has driven voice revenues for mobile phone operators - as people choose to make calls from mobiles in home - because it's easier as mobile phones have had address books integrated.
The breakout opportunities for mobile applications come from those applications that you choose to use on mobile - even if you are sat in front of your PC. In europe there are great examples of these in voice & SMS.
There is space for innovation in applications here - I've got some thoughts (http://www.livetalkback.com) and I discuss these issues regularly on my blog http://www.viewfromlondon.com
Some US numbers...
...looking at the last 100 million pages tracked at percentmobile.com we're seeing that 45.7% of the US mobile traffic is via a WiFi-enabled device -- with half of those folks using the WiFi at any given moment. Blackberry and Apple own practically all of that.
my take is that what makes an exceptional mobapp is not what additional feature it can provide on top of the PC, but what degree of fun it can provide in the first few days after download. that's the challenge.
We're focused on the Enterprise ($$). We wanted a way that an enterprise could reduce their risk regarding mobile app development, and yet take advantage of GPS etc inside a smartphone while still retaining control/privacy over their data.
Let me give you an example using a large engineering/services company. They have 3,000 employees who are all using Blackberry's. These BB's have GPS in them and they want to access that data and use it for their SmartStatus portal which is browser based. They install a simple mobile app that access the GPS data and then makes it available to the smartstatus web portal whenever their employees login using the browser.
Now they've also decided that they want to incorporate Windows Mobile smartphones into the mix to reduce their dependencies on BB's and the BES server. They want to leverage everything they've done and want an identical solution on another platform.
Using this browser approach you can deploy in less than 30 days. The mobile app is cross platform - the interface is the browser so there is nothing new to learn, and there are no programming changes on the portal server.
If we had to build a mobile app with a full UI and make it identical across multiple mobile platforms the cost would huge (100k or more) and may take 6 - 9 months. The alternative approach is web services and a single set of business logic that can be controlled by their existing programming staff.
For more background on why I think the future of mobile is web services here is a great read http://communities-dominate.blogs.com/brands/20... (it's really long). The key section is titled "Software" followed by "Web based services, not apps". Now I usually disagree with the author, however not this time.
Mobile apps might be fine for the consumer (iPhone) but the Enterprise is a more complex beast. All they want is to leverage what they have and reduce the risk. The way to do that and ensure consistency across everything is the browser and web services.
The problem is simple - get the data off the phone and into the browser. Harder to solve than most think.
The ISV is part of our go to market strategy. Why? They already have our end customer (the Enterprise) as a customer. However they have a problem... their margins are getting squeezed because Web 2.0 is a commodity item. Therefore they need to go back to their customers with a differentiator - mobile. Unfortunately they have another problem - where do the find the mobile programming expertise? (they're web 2.0 guys). So we built a Mobile Application Generator (MAGGIE) that works across platform. You can meet with the customer and define the "meta data" they need from the device for their particular service. You enter the data in Excel and then export it as a CSV file. You drop this into Maggie (online SaaS service) and it generates cross platform code for both BB (Java) and Windows Mobile (C++) the other platforms will come later. Now all they have to do is take this code and hook in the api's and you're mobile development is done (bar some final tweaking).
We're just getting ready to release a public domain version of our software. We built both Windows Mobile and BB versions with Maggie. It generates about 75,000 lines of code with debug in about 4-5 seconds.
But I digress. The core problem is extend web services to mobile in the most cost effective manner possible AND reduce the friction in obtaining device side meta data.
Or as you say - pick a platform and pray and that's not a good investment (IMO) unless you're Apple and make your money on everything but the app.
Do you have a web based (browser) version of your train logic? If so our mobile app can send you real time GPS and or Cell Tower information and they you can display the results in the browser.
Cheers,
Peter
I believe that a true mobile renaissance will come once the established corporations (healthcare, technology, etc.) really realize what mobile can offer and how mobile is different from the current Internet web-browsing model - i.e. finally view mobile as not just an additional channel but instead a platform for completely new business models.
A good example of this is security on mobile. Up until now security on mobile has been tackled by using established Internet paradigms - boosting encryption, preventing phishing and other scams, etc. Only with the proliferation of iPhone supported LBS applications are companies waking-up to the fact that mobile security requires new dimensions of consideration - such as incorporating LBS capabilities (like enabling location-aware mobile access) with inherent biometric-reading capabilities (e.g. voice recognition or fingerprint photographing). These native capabilities offer great opportunities for greater security and will eventually make mobile security stronger than traditional Internet-based methods.
i like what apple has done with the "locate my phone remotely" feature.
i think "lock down my phone remotely" may be even more important
Cheers,
Peter
A friend (marco @ tumblr) recently commented: "If your location isn’t interesting enough for you to manually write a post about it for some reason, why should your audience spend their time reading about it?"
But the really tough thing about location (particularly for individuals) is when to share and when not to share. Always on location sounds like a nightmare. Which makes me think that your prediction about business and things being the first to make serious use of passive location based services seem spot on.
Example:
I'm a student taking a new university class. The prof. mentions that the class app is ready for use. Students check out the app store, and based on several "native" factors like location or proximity to other students using the same app, the appstore would show the Prof's course application as the top app. Maybe a graphing calculator app that most other students also have is number 2.
I really feel this is how education is going to evolve in academic institutions. This is applicable to conferences or even events like the protests in Iran. Mobile apps are a great way to target how certain data is consumed. Right now though we are using mobile apps like web browsers that only show one website.
The challenge is two fold. Making the development process accessible and easy for the Prof to build an app specific for the course is a tough one. Prof's can barely put together decent one page course websites now.
The second part is distribution. How do you get the appstore to be native and location aware? It's challenging because you need support from the gatekeepers once again. This time it's not AT&T or Vodfone but Apple and Google. Fewer gatekeepers but still the same controlling behaviour.
Really didn't suit student needs at all, because they didn't take a look at the fact that students want ultra portable but very shareable textbooks for studying around. With highlighting and quizzes.
Admin tents to be very rigid and have these applications that are bizarre and come from very politicized vendors that allow them to join other consortium,s of schools, etc. Just Bizarre. And Badly done. It is so Bizarre that I actually once got recommended by career to use Indeed because their own out of state listings were so badly disorganized that they didn't know how they fully worked.
:-)
However the cell phone (mobile phone) is also notable as a notification and billing platform. Mobile platforms have been able to charge for content, where the web has failed miserably (pics, vids, music). Customers don't blink at the idea of paying to send a 140 character message, when email is free for almost unlimited characters.
Put it all together and you have viable business models in paid proximity notification.
Ronan
Locle.com
Call us offline if you'd like to discuss in more detail.
Ronan
Locle.com
I'll be presenting Locle Platform at GigaOM's Mobilize 09 in San Francisco this Thurs if you're there:
http://events.gigaom.com/mobilize/09/launchpad/
At GameChanger we use the term "User Collected Data" to distinguish that from unstructured UGC. Things that used to require paper input, laptop tabulation, or heavy/expensive/complex recording equipment can now be accomplished on-location with one hand free.
It's the intersection of your media assets, location data, contacts list, audio/video/touch inputs and data connectivity that make the mobile device the ultimate "social tool".
with someone, I tend to add them to my LinkedIn or Outlook Contacts. After
that if they change jobs I am usually covered on finding their new contact
info via LinkedIn/Xobni.
Right on the money - it's all about Trust... the phone will soon have a biometric sensor (the banks will want it for multi-factor authentication). It's "My" Touch - so how do you transmit my touch over the web?
Here's the header that does it - http_x_biosensor="..." That's it. The beauty of this approach is that anyone with a web server can read it - (it makes the web smarter)... in addition you only send your touch to those you trust. (Controlled by a whitelist in your browser)
Just Biometrics are not enough. We tend to ritualize touch and the mediums surrounding it in order to feel secure. fter all, the body is our more personal space. Beyond creating a mthod of sending and recieving biosensory metric, is the backend powerful enough to handle the sheer amount of data embedded in one fingertip, let alone the data that comes with ritualization that would come with sharing touch and biometrics (pressure sensitivity that is unique to each person, ect)
For example - your mobile application can "burst" into the cloud to access compute / content that was not there two years back (thanks Amazon).
The missing link between a PC and a phone is the spreed of the internet connection. Mobile connection is still patchy and the speeds don't come close to 1GB LAN / 10MB WAN connection that we are used to. And economics and technology for the Carriers to upgrade their networks is just not there.
This is due to a few important and evolving factors:
- In the U.S., half of the mobile market is still dominated by CDMA technology (Verizon, Sprint, and a few other minor carriers) - most CDMA phones (not including the new Palm Pre) still run on the old BREW operating platform which is horrendously difficult to develop for due to Qualcomm's control of it and a few other limiting factors. Also, CDMA phones don't have SIM cards so unlocking is more difficult.
- Mobile phone operating systems are still highly fragmented in the U.S. and globally - although the world is still dominated by Nokia phones and thus Symbian.
- Smartphone handsets and hardware are still highly fragmented as well - from actual phones to added features like NFC chips.
- Smartphone penetration is growing but still only represents 10-20% of all phones in the world (depending on the market that range fluctuates)
- Consumer habits are a little wacky when it comes to mobile adoption - i.e. it took a decade for U.S. consumers to embrace SMS communication
There are some other minor barriers as well. I list these not to be negative but instead to highlight challenges that if a start up is able to overcome, would then give that start up a major advantage in the marketplace.
We faced a unique set of challenges when we built our solution. We use the mobile browser to communicate user, device and location information from the Smartphone. We add the meta data to the outgoing HTTP headers. Our issue was twofold - how do we protect the privacy of this new data and how do we integrate it into the Enterprise back end without requiring Admins to learn anything new. (We solved the problem by creating generic headers which can be read by any script and then you use CGI to pass the data to any back end service that needs it (mash out). This is different from device fragmentation. Which requires that you test on lots of different devices. We don't have that issue because we're "inside" the browser.
oh snap i hear all the Apple fan boys getting excited already.
My point being that there are lots of mobile os's and lots of countries.
Now that China Mobile has opened up their app store to their 500m users are any of you going to be submitting your apps for international consumption?
http://www.mmarket.com/
More comments here http://deancollinsblog.blogspot.com/2009/07/www...
Cheers,
Dean Collins
www.Cognation.net
It also depends what type of company is developing the app - if it's a bank only located in the US then it might not make sense to think internationally. I used the US example since it's the easiest to outline.
If someone can figure out a killer app for Nokia's Ovi then they could reach 10x the market that the iPhone has.
Also you thinking is flawed
"A killer app on the iphone is likely to be a killer app on an Android device and vice versa".
Also
"A killer banking app for Bank of America is likely to also be a killer app for Allianz Dresdner bank".
Expand your mind.... think globally - can you imagine if the Australian CSIRO scientists who invented wi-fi thought "Australian Only"?
Cheers,
Dean Collins
www.Cognation.net
Here's the key section... “Mobile application developers today face the challenge of multiple mobile operating systems,” says senior analyst Mark Beccue. “Either they must write for just one OS, or create many versions of the same application. More sophisticated apps require significant processing power and memory in the handset. Using Web development, applications can run on servers instead of locally, so handset requirements can be greatly reduced and developers can create just one version of an application.
Exactly on point. One set of business logic, one display/UI interface and device and OS agnostic. This is the future of mobile.
Now all that remains is to remove the friction point of what's known in the trade as "Device and Terminal Capabilities" in real time.
Here's an example. My BB has a browser and an on board GPS. So why can I NOT access that GPS data and send it to any web server of my choice?
The problem is harder to solve than you think. (And no the current W3C Geolocation API is not the correct answer - it's only a partial answer as it does NOT address other device side capabilities e.g. bio-metric sensors)
Brilliant!
Here's the key section... All that would be needed are some Javascript extensions to give access to the phone capabilities, in particular location, the camera, making calls and cross-app communication (including access to built-in apps such as the address book).
Now let me pose a question to everyone who is following this thread... "What if the above happened for every mobile device?"
The web service would emerge the winner over the mobile app overnight. Why? One set of logic and millions of JavaScript programmers out there who can no access mobile device data without knowing (or needing to know) how to program a mobile phone. The other killer app here is that JavaScript is "Open Source" so that everyone can see the calls that are being made. It becomes like HTML.
I'm sorry I just don't see Google putting that kind of effort into something that has already been done.
I never forget something Steve Balmer said... there are four stages of a company, think it up, scale it, milk it, think it up.
Google is now at the think it up stage - they have done it once with search and adsense... now they are literally in "search" of the next big thing. I can't imagine a VC anywhere in the US investing in a general purpose operating system. So personally I think it's a head fake - Schmidt just wants to go up against his old foe (he will lose). In the meantime we have to pay attention to what they are not telling us. Therein lies the next big thing (maybe)
I don't understand why apps are not the next big thing for goog. I've moved myself off all the msft apps onto goog apps and I am so much happier
Web apps rock
0 behavioral changes
1 login
2 second response time
3 clicks to relevant content
The browser can fulfill this - a mobile app can't.
So I believe Google is doing lots of head fakes while they remain focused on their core DNA... web apps (like we use on the desktop browsers) are too cumbersome for mobile - so they will come scaled down for mobile.
It all boils down to three things...
One platform - the web,
One interface - the browser
Multiple data sets - the context.
What I believe you will see happen is that the mobile browser will become more of a rich internet application. Browser menus will change "in real time" based off the context of the user and of the web service they are accessing.
Right now all you see in the browser menu is the standard fare - imagine going to www.starbucks.com and the second you hit the page the browser menus now change to ... find closest location, get driving directions, top up your loyalty card. It's all about 3 clicks to relevant content.
A web app can deliver that - it just has to become more aware of the users context.
The PC established both formal and informal global standards before personal PC penetration was significant. Mobile penetration has grown to a much higher percentage without any real standards - protective gatekeepers, different core technologies (GSM vs CDMA), different hardware, and different operating systems - on top of that, complicated data plans and a confused consumer base.
You're looking for a technological solution for an ecosystem-problem.
Now here's something to think about - what if every mobile browser had the capability to send real time location information and some personal keywords and or preferences to Google every time someone did a mobile search. The value of their ads would jump overnight and the second revenue stream would start to kick in. Right now (just have to wait a few more weeks) there is no way to easily share additional mobile meta-data with Google from within a browser AND also be able to share that data with any other web service. (Google's Mobile Maps app can access location data and do search - but it can't share that location data with any other app or service - hence it doesn't scale).
IMO it all ends up in the browser - because it's what the middle market (not the techies) understand. And that's where the real money is. (And the Enterprise)
I think the main logic for Chrome is to dent Microsoft's war chest.
More here
I think the issue for Google is that they want control over the end to end points in their ecosystem. They don't want to wake up tomorrow and find out that IE doesn't support something they need. The world doesn't need another browser - Google wants an insurance card against someone doing to them as what Microsoft did to Netscape.
As for the innovation coming from inside the browser - yep. HTML 5 is a start in the right direction - but it's not enough. The browser should be able to read the entire device side api... only when it does that can you really innovate.
Also, I never tried to make either of the two points you outlined. My point was that since a lot of us sit in the U.S. that is the marketplace we know best and thus can analyze the best. This is true for companies who primarily target customers in the U.S.
I agree with you that global sources should be leveraged to foster innovation. I don't agree that a global rollout of a new mobile application is possible without taking into account extreme local differences (in technology, customer preference, etc.). "Think globally" might be a catchy motto but it's not an easily attainable strategy.
As a mobile developer we've focused on both local and global capabilities. We leverage the browser which is already global and then designed the app so that it could be easily "ported" to other languages. It wouldn't take more than 30 days for any country and the cost would for a translator to figure out how to say "Location Information" (and a few other menus) in whatever language is required.
The rest is all about web services. Much less risk that way.
> it's not an easily attainable strategy"
I guess when you are not looking for the opportunities thats a 100% correct statement.
Guess Apple should stop trying to export their iPhones and Nokia better stick to selling phones in Finland.
It's possible, and if done right could be very lucrative - but it's not easy to do right.
yes iphone is 'neat' but it's very usa centric and globally still a small percentage.
stop reading admod reports....it's all BS. start researching handset shipping numbers if you want a more accurate picture.
Never did I mention their global market share - which is still large but falling fast. But their current US market share is 10% at most (http://www.informationweek.com/blog/main/archiv...).
Never did I say that the iPhone outsells Nokia just that they face an inverse position - i.e. the iPhone is powerful in the US but not elsewhere, like Nokia is powerful outside the US but in the US. This was to strengthen my point that global dominance is difficult.
Listening (in this case, careful reading) is very important if you want to make a strong counterpoint... "it's a good practise."
You're point is well taken. There really are 4 main horsemen - Nokia/Symbian, Microsoft/WM, RIM/Blackberry, & Apple/iPhone (in that order). The late comer to the party is Google/Android (not sure where that is going to end up).
IMO successful mobile "app" companies will have to run on all 4-5 platforms to scale. but hey - the market is huge and is growing faster than the PC marketplace. Good times (if you understand how to code on a mobile device)
Company 4Q08 Sales (1,000s) - MarketShare (%)
Nokia 118,791.0 - 37.7
Samsung 57,517.9 - 18.3
LG 28,140.9 - 8.9
SonyEricsson 23,554.1 - 7.5
Motorola 21,700.1 - 6.9
Others 65,003.8 - 20.7
TOTAL 314,707.8 100.0
http://www.gartner.com/it/page.jsp?id=904729
See that section for 'Others' at 65m handsets in Q4 2008....thats where Apple and the iPhone go, but they are also sharing it with HTC, etc etc
lol so Nokia ships 118 million handsets in Q4 2008 and you think 'they are just in europe'.
iPhone is a blip on the mobile timeline, heck i remember when the Motorola startac was 'it'.
Stop living in an echo chamber..... it's a good practise.
Cheers,
Dean
VC is a local business. But it should happen on a global scale and that is happpening
So integrating native or web apps to the device's calling feature may seem pretty basic, but is also very easily overlooked. Note how few mobile apps display a phone number in a "prominently clickable" fashion.
Lots of businesses out there still want your phone call ahead of your anonymous data click. There will be some breakthrough apps that make the calling process integrate really well with the data features.
Some more reading for you if you’re interested. This link http://communities-dominate.blogs.com/brands/20... talks about Why Location-based spam ads will fail, but also LBS-based event ads will succeed.
Personally I don’t believe he’s totally correct but if you read between the lines you can determine the core technical problem. It’s all about context. LBS based event ads are based on the context around you wanting to be at the event i.e. that’s information about you. Location based ads on the other hand have no context about you other than you’re somewhere. In plain speak “insufficient data”.
Next check out this link: http://www.seobythesea.com/?p=540 which talks about all the patents that JumpTap has recently filed related to Mobile search. What’s interesting here (as you scan the abstracts) is that context is the “key” that unlocks relevance. (JumpTap shares revenue with the Telco’s in exchange for context around the user).
If you’re still in the mood to read go to this link: http://www.ietf.org/rfc/rfc2616.txt - it’s the Hypertext Transfer Protocol (the protocol that runs the Internet - don’t worry you don’t have to read all of it) just scan down to “12.1 Server-driven Negotiation”. The good stuff starts here:
Server-driven negotiation has disadvantages:
1. It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?).
2. Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential violation of the user's privacy.
3. It complicates the implementation of an origin server and the algorithms for generating responses to a request.
Now think about this…
What if it was possible to determine “what might be best” for any given user in real time?
What if you could solve the privacy problem (this is Albert’s dilemma when he talks about Google/Android opening up JavaScript access to the Mobile device)?
What if the origin server didn’t have to add anything to generate the response other than a simple script?
What if you could do this for the 225 million Web servers that are out there and not require any changes to the current HTTP protocol (rfc2616)?
What if worked across every Mobile device?
Effectively, at some point, the phones delieve what computers do, at a much smaller scale. Yet we feel about them and treat them much different, so we want much more dynamic data on them.
It isn't so clear to me that as the actual phone (the item) develops, that individuals won't understand that effectively they hold a mini computer that makes phonecalls, making this discussion a bit moot- or that the reverse is true as well. This is very much a wait and see game. That is very high stakes. A lot of this plays out on how we choose to physically design the next generation of computers as well.
It used to be the World Wide Web (www) - as the data becomes more dynamic it becomes Who am I, What am I, Where am I.
However, whilst I agree that app-specific plug-ins are a barrier to adoption, general-purpose plugins (eg Flash) have faired a lot better. I would therefore suggest someone write a general-purpose plug-in which exposes this type of functionality to the browser execution environment (js).
One point that was not really touched on in the discussion is the limited bandwidth available to mobile phones. Even with the advances made in network throughput, there is still the problem that the limited spectrum must be shared with other users in the same cell. Basically, mobile phones will always have slower connections than hardwired devices (unless something really radical happens).
This has big implications on the delivery of complex browser-based applications, because the entire code base must be delivered to the phone even if only part of it is used. A better solution is to inteliigently deliver the relevant pieces of code and content in a pre-emptive manner to the mobile browser. This makes applications boot faster, and run with siginficantly reduced latency. Since people are none too shy when it comes to talking up their own book in this thread, I could add that my company has developed pat-pending technology to do just that.
This issue is connected to the wider problem of intelligent bandwidth usage and caching. As far as mobile is concerned, one of the most interesting parts of the HTML 5 spec regards native support for a local database. If I were a VC, I would be actively seeking out companies developing technology to leverage this functionality to create a smart mobile cache. It is the missing piece of the jigsaw. The smart cache would silently sync both code and data on the mobile device with that on the relevant remote servers - and would have an unbelievable impact on the power, complexity and performance of mobile browser-based apps.
Have you been reading my emails ;-)
>> I would therefore suggest someone write a general-purpose plug-in which exposes this type of functionality to the browser execution environment (js).
Done. Just going through the last stages of testing. You will be able to write simple javascript that can do exactly what you want above.
With regard to bandwidth. This I do know a little about as my partner and I are the inventors of Mod_Gzip which is the standard for content acceleration for Apache web servers.
Our new mobile solution (Mod_Mobile) supports even more advanced content acceleration techniques and is also designed for something which you hint above... the ability for the server to stop the transmission in real time and request additional information from the device.
This is critical and up until now has never been done before. But it all goes to exactly what you are talking about. You (the web server) should send as little data as is required to deliver a great customer experience and if you need more data for instance to complete a mobile ecommerce transaction then you should be able to request.
In addition you should have to wait until HTML5 comes along (which by the way cannot do this) it should work seamlessly with everything that is already out there.
Re mod_mobile, I don't quite understand how it works, but in my view the only real solution to fast booting and pre-emption is via program architecture.
Also, whilst I don't know too much about mobile browsers, many parts of the HTML 5 spec are already implemented in the 'quality' (big web) browsers.
>> but in my view the only real solution to fast booting and pre-emption is via program architecture
Totally agree - Mod_Mobile is on the server. Think of it as a grown up version of Mod_Gzip which currently runs on millions of servers.
On the client side we're part of the browser and sit on top of the OS. We're live all the time, there's virtually zero latency as we collect the data and send it.
RE: HTML5 - it's coming to the big desktop browsers - it will be several years before you see it on a mobile device. Even then I hope we will be able to fill in the gaps it doesn't serve.
1. Audio Web Navigation: Many times, while I am walking listening to music, I prefer to navigate Internet hearing the web pages instead of looking to the screen. There are many scenarios where you are doing something else and don't want to be 'attached' to the screen and touch interaction. Text to Speech is really good right now (just look at AT&T Natural Voice), while Speech to Text is far from perfect, but for simple navigation can be fine. I see it as a native mobile application since when you're in front of your computer a visual browser is the obvious solution.
2. Retrieving/Storing/Controlling other devices: iPhone did a good think to incorporate a Hardware API for their connector. I think putting your mobile phone in your car, robots, and in other equipment to store/retrieve/control.
3. Portable media machine, including downloading torrents and playing them anywhere. I found using a notebook on a hotel for this purpose is overkill.
4. Automatically converting your mobile phone on an extension number when you're in the office. Currently it's very difficult to do on many platforms (it's possible on Windows Mobile, Android). I want to receive calls from Asterisk PBX to my mobile phone without depending on another device.
5. Digital Security and Payments: Want to use the mobile phone as a smart card to log into different places and pay stuff.
6. Broadcast: like Qik and others.
7. Universal Remote Control (and see http://www.openremote.org/display/HOME/OpenRemote)
8/ Portable Surveillance for your baby (and other uses)
9. Proyector: There are some companies working on this, every hotel has a TV but proyecting a movie from your mobile phone can work.
10. Mixing with other elements like that Microsoft Table (surface). You can play your [cards] game showing your cards on the table (or on a TV)
but right now, I need the (1).
11. Need to quickly scan the office's whiteboard and convert its diagrams plus ocr. Obviously going further than evernote. Ala Xerox Parc et al research.