Boss of the Year Entry Form
Now that we've thrown 'em off the trail, use the form below to get in touch with the people at Engadget. Please fill in all of the required fields because they're required.
Many people call HTML5 an Adobe Flash replacement and I agree. Adobe already discontinued Flash on mobile devices. So HTML5 Video is a must for video on mobile phones and tablets. On the desktop Flash Video players are used more than HTML5 Video players but HTML5 video will work with a current web browser on a site that supports HTML5 video. Commercial video sites like YouTube will play partnered content in Flash even if you turned on HTML5 video at http://www.youtube.com/html5. I assume the reason for this is HTML5 video doesn’t really support DRM. The HTML5 video tag just tells the web browser where the video is and other info it needs to know, then the browser handles the video playback using a supported codec and other features like controls.
So DRM could be implemented in all the major browsers and play DRM video back if everyone is using an up-to-date browser that supports video files with DRM. Also I think Firefox would object to supporting DRM as it’s a closed technology. Plus since its open source you could read the code, and then “crack” the DRM. So I doubt all the browsers would even support DRM videos. So that’s why video sites still use Flash or Silverlight on the desktop. Then on mobile devices you install a native app(Example: Hulu Plus and Netflix) I assume it’s for DRM also.
Now I think DRM is pretty stupid. DRM is pretty much cracked all the time. Sadly major entertainment companies still prefer to use this type of technology. It’s basically security through obscurity and seems like a waste of resources to create and use. So I think the entertainment industry being ignorant is going to hold back HTML5 Video for commercial video sites.
The plan for Viewashi(Video Startup I’m part of) is to do HTML5 Video with a flash fallback. Then also prevent hot linking via a token based system. This clearly seems like an innovative approach to me as a HTML5 video seems to use less CPU than a Flash video. I’m not sure if this would hurt the content selection. What do you think? Do you think the entertainment industry would want to get on board? Do you think Indie content would get on board? Or should we just stay with dying technology like Flash or Silverlight that supports DRM?
Normally I like to be in a stealth mode and not talk much about any of these types of details relating to a startup but before we really start on our player, I’m just curious as what others think on this topic.
I think supporting HTML5 video is great and I prefer it over flash. HTML5 Video just seems all fragmented. IE and Safari needs MP4, Chrome needs WebM or OGV, etc. So DRM on top of that would complicate things even more. I know HTML5 isn’t done till 2014. Some of the elements seems done already and is in use. Do you think the state of HTML5 video will be better in 2014 or even 2013? I personally would prefer DRM to never be implemented as it seems like a waste as it will most likely be cracked by someone and different browsers will disagree on it. Do you think not having DRM is going to be a big problem for HTML5 video adoption or will it get it later on? What are your opinions on this topic?
PS: I’m not trying to promote DRM. Just talking about how it could be implemented and wondering if not having DRM on HTML5 Video will limit the use of HTML5 video for full television episodes and movies by the studios.
The mobile technology landscape is incredibly confusing. There are numerous choices, ranging from new HTML5 technologies, native app development methods, and all sorts of content management systems.
At CBS Interactive, we have numerous mobile solutions, including native apps for CBS.com, CNET, and "60 Minutes," along with mobile-optimized Web sites for GameFaqs and global properties like ZDnet.
At first blush, it seems problematic that various properties have picked completely different architectures for mobile delivery. A technologist's initial inclination is to have everyone run a consistent architecture across all of our properties. Yet it actually makes sense to run a variety of architectures to support mobile delivery.
The biggest issue to address is the ongoing tension between HTML5 and native. Most of the debate between the two is focused on different technical features that very quickly delve into minutia. However, the actual decision between the two should be made based on the type of traffic a site has.
Where's the traffic coming from?
If the majority of a site's traffic is side door traffic from Google, Facebook, and Twitter, the site should embrace mobile web and HTML5. Since most of the site's users are arriving via links, the content must quickly load in the mobile browser. Such sites include music lyrics sites such as our site MetroLyrics and other types of information look up sites.If a majority of a site's traffic is direct but intermittent traffic--meaning users come directly to the site, but only once in a while--the site should implement HTML5 mobile Web. These types of sites are "tourist sites" that are not visited regularly by people and therefore users are very unlikely to download an app. Such sites include corporate websites such as my company's CBSi.com homepage.
If the majority of a site's traffic is direct traffic where people are regularly going straight to the site's home page from a bookmark or typing in the URL, the site should use native apps. Such sites include CBS.com, CNET Reviews, and other types of highly branded destination sites.
Sites with direct traffic that is intermittent--meaning people drop by every now and then--should still use HTML5 rather than native. For sites with a lot of direct traffic, native apps also provide useful additional features such as push notifications and offline storage, which are not relevant to sites with intermittent or side door traffic.
Sites that have an even mix of direct and side door traffic should also implement both native apps and an HTML 5 mobile view. A word of caution, however: there is always an inclination to heavily promote your native app to everyone going to your mobile Web site by forcing users to click through a native app promotion. This is a way to piss people off. Most of those visitors are clicking on a link in Google or Facebook and expect to see the content. They don't want to download your app.
What can you spend?
Once you determine whether to build an HTML5 mobile Web site or a native app, the next big question is how much you are willing to spend. Really, there are only two choices: complete and cheap or custom and expensive.Sites should generally start with a turnkey and cheap solution. For turnkey mobile Web HTML5, vendors like Pressly and Mobify will take your content and make it sport a sexy, Flipboard-stye tablet interface. Wordpress includes mobile plugins that work great on iPhone and Android. Be sure to add a "view full site" option so that your users can opt out of the mobile experience and access functionality that the turnkey HTML5 solutions do not yet support.
To deliver turnkey native apps, services like MobileRoadie will consume your content, social feeds, and more and let you style good iPhone and Android native apps, with iPad soon to come. The apps are gorgeous and responsive and provide extensive options.
For the sites that need to support both mobile web and native apps, it is likely that the turnkey vendors will soon begin to support both distribution channels, and one vendor will be able to deliver best-of-breed solutions for both mobile HTML5 and native apps. For now, however, I suggest using a different vendor for each.
Once you have a baseline mobile presence, you can consider adding a custom experience that will support numerous features and user interface enhancements. Unfortunately, custom means expensive, both for HTML5 and native apps.
There are numerous systems integrators such as that deliver elegant, iPhone, iPad and Android native apps. Be aware that these integrators are going to need to be able to integrate with your registration, user profile, and content systems and that will likely require engineering and IT work. Some integrators such as FreeRange360 have an underlying platform that makes this type of customization relatively straightforward.While HTML5 has come a long way, it is still not up to par with the native app experience. Some publishers, such as the Financial Times and Playboy, have come close to native app functionality by investing heavily in HTML5 in order to bypass Apple's 30 percent app store subscription fee. However, there are no turnkey JavaScript libraries that provide functionality such as efficient swiping and offline reading.
That said, it is relatively straightforward to efficiently deliver an excellent mobile Web experience. Libraries like jQuery mobile and Sencha mobile provide excellent HTML5 iPhone-style user interface controls, and it is easy enough in modern web frameworks such as PHP and Ruby to detect what type of device is requesting content and delivering a customized page for particular screen sizes, known as the "if viewport then" technique. It is tedious and cumbersome work, but can be done, and provides an excellent level of control and flexibility.
For properties that contain primarily text and images, you could consider a hybrid HTML5-native approach, where a mobile-optimized HTML5 site is wrapped with a native wrapper like PhoneGap. While this sounds like an ideal solution, consider that this approach is quite nascent, and that it takes quite a bit of work to make HTML5 work and look like a native app.
In summary, when discussing your mobile strategy, use the type of traffic your site has to determine whether to use HTML5 mobile Web or native apps, and then use your level of budget to decide whether to go turnkey or custom. And have some fun with your apps and please let me now what's worked for you.
Introduction
Mobile apps and HTML5 are two of the hottest technologies right now, and there's plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a "write one, run many" solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route. This article is a debate on native versus the web.
Feature Richness
Point: Native can do more
We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device's ecosystem, e.g. for Android, this would be features like widgets and notifications. Native excels in both dimensions.
In terms of app experience, native apps can do more. They can easily get hold of swipe events, mutlitouch even, for those platforms which support it. They can typically act on hard keys being pressed, like Android's search button and volume controls. They can access hardware too, like GPS and camera. And with the user's permission, some platforms provide unfettered access to the operating system. Just try detecting how much battery remains with HTML5!
It's more than the in-app experience though. An operating system like Android provides different ways for apps to interact with users, and indeed, with other apps. You have active widgets on the homepage. You have notifications, which show up in the device's status bar. And you have intents, which allow your app to announce itself as providing a general service which other apps might require on occasion.
Counterpoint: Native features can be augmented, and the web is catching up anyway
It's true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web-fu skills are, if your app is stuck in a sandbox with no camera API, it won't be taking snaps anytime soon! Fortunately, you don't have to be in that sandbox. If you really need your web app to take a photo, you can create a native app, one with an embedded web view which provides the bulk of the user interface. This is how the open-source PhoneGap framework operates: it fills the gap by exposing native features as web services, which the web view calls using a standard networking API. When you build a hybrid app like this, you're also able to hook into those platform features like widgets, notifications, and intents.
Making a hybrid - native plus web - app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn't be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it's possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.
Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it's not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.
Native is a fast-moving target, but the web is closing the gap.
Performance
Point: Native runs faster
Native apps don't have the web runtime barrier to deal with. They run close to the metal and can take advantage of performance boosters like GPU acceleration and multithreading.
Counterpoint: Web runtimes are much faster today, and most apps don't need the speed anyway
It would be an understatement to say the web has gotten faster in recent years. V8, the JavaScript engine that ships with Chrome, was a major development in web performance when it launched, and since then, it has only gotten faster:
Graphic rendering engines has also sped up the web, and now hardware acceleration is starting to happen. Have a look at the speed bump provided by hardware accelerated-canvas:
In addition, the new Web Workers API makes multithreading a possibility, and modern web developers can also call on a range of performance-optimized libraries, and well-researched performance optimizion techniques. While most of those started life on the desktop web, they are still relevant to mobile, and there's increased attention paid to mobile, e.g. performance guru Steve Souders has a page dedicated to mobile performance tools.
Not all desktop advances have made their way to every mobile platform yet, but the trends indicate they are on their way. It's also important to note that the majority of mobile apps aren't bleeding-edge 3D games, but fundamentally information-based: news, mail, timetables, social networks, etc. Visit a few sites from your mobile, e.g. GMail, Amazon, Twitter, and you can confirm mobile web performance is more than adequate. As for games, basic ones are already feasible with 2D canvas, and WebGL is starting to appear on mobiles - see Firefox 4. Until it's widespread, there is a growing family of frameworks which compile WebGL apps to native apps that can take advantage of OpenGL, e.g. ImpactJS.
Developer Experience
Point: Native is easier to develop
Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.
What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it's no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation.
Counterpoint: Web is often easier to develop, especially if targeting multiple devices
Let's tackle core technology first. It's true that web standards were originally conceived in an era when the web was fundamentally about documents, not apps, with JavaScript built and deployed in just 10 days! But they've turned out to be much more capable than imagined - web developers have learned to leverage the good parts and tame the bad parts, with patterns now understood for scaleable design. Furthermore, the standards are not standing still, and efforts like HTML5, CSS3, and EcmaScript Harmony are all improving the developer experience. Whether you prefer C++ or Java or JavaScript is a matter of religious debate, and also depends on your legacy code base. But we can certainly include JavaScript as a serious contender these days.
The flipside to browser/runtime fragmentation is the fact that all these environments exist in the first place. Develop an Android app in Java, and you're faced with a full port to Objective C to support iOS. Develop a web app once and it will run in Android and iOS, not to mention WebOS, BlackBerry, Windows Mobile and ... well, that's the theory anyway. In practice, you'll need to tweak things for each platform if you really want to get the experience right. But you'd have to do that in native too, for most mobile operating systems - there are different versions and different devices.
The good news is "fragmentation" has always been this way on the web, and there are well-known techniques to deal with it. Most importantly, the principle of progressive enhancement urges developers to target a basic device first, and add layers of platform-specific awesomeness where it's available. The mantra of feature detection also helps and these days, we have library support from the likes of Modernizr to support responsive web design. With judicious use of these techniques, you can expand your reach to the vast majority of devices, even old-school "feature phones", even form factors like watches and TVs, regardless of make and OS. Witness our multi-UI demonstration at Google IO 2011, where we targeted distinct form factors (feature phone, smartphone, tablet, desktop, TV) with a common code base of logic and markup.
Look-And-Feel
Point: Native fits platform look-and-feel
One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipiulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a "long hold" (keep touching an element for several seconds)? Plaforms have standard idioms for such things, and you can't satisfy them all with a single HTML5 app.
Furthermore, platform look-and-feel is orchestrated by the platform's native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel "for free" just by using the native toolkit.
Counterpoint: The web has its own look-and-feel, and you can also customize web interface for those platforms you care about the most
As explained in the previous section, the way of web development is to write a basic "one size fits all" version, and then progressively enhance it. While the enhancement is typically based on features, you can also enhance it by targeting those platforms you care the most about. This is a kind of "browser detection", which is sometimes frowned upon by the web community, mostly because there are so many possible browsers out there. But if you do view two or three platforms with a very high priority, and you're willing to make the extra effort in order to stack up against native alternatives, this may be the way to go.
As far as the baseline version, the web has its own look-and-feel, and we can even say each mobile platform has its own "web look-and-feel" established by the default browser and web runtime. "Web look-and-feel" may be fine for your users, and in fact, allows you to achieve a greater degree of consistency with the desktop browsing experience, as well as those on other devices the user might be working with. Furthermore, there are many successful apps which don't much support native look and feel anyway. This is certainly true of games (does your favorite mobile game follow your mobile OS's look and feel?), and even true of more conventional apps, e.g. check out the more popular native Twitter clients on your platform of choice, and you'll see a wide range of user-interface mechanisms at work.
Discoverability
Point: Native apps are easier to discover
App distribution mechanisms, like Android's Market and Apple's App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you've done your job right, the glowing ratings and comments will convince users to hit the all-important install button.
Counterpoint: Actually, web apps are easier to discover
The web is arguably the most discoverable medium ever created. In the humble URL, we have (in theory, at least) a unique identifier for everything ever published on the web, which includes any apps published on standard websites. Search engines make it easy to discover that content and other websites can link to it, including catalogues of web apps similar to mobile marketplaces. Indeed, any individual can share web apps with their friends by just linking to it in emails and social network messages. Links can be sent in SMS too, where mobile users will be able to click on the link and launch the app in their device's browser.
We don't yet have the same marketplaces where users can rate and comment on apps, but that's changing too. Read on ...
Monetization
Point: Native can be monetized
"6 year-old makes app during lunch hour, sells a zillion copies at $3 each". You see that headline a lot these days, so it's no wonder developers big and small are looking to the mobile marketplaces for monetization. Mobile platforms offer several avenues for developers to directly charge for their apps. Simplest is the one-time payment, to unlock the app for all eternity. There are also in-app payment and subscription mechanisms on offer in some platforms, and they are tightly integrated in a consistent, secure, mechanism. These newer forms of payment allow developers to convert a smash-hit app into a long-term revenue stream.
In addition to app payments, you can monetize with traditional web models, such as advertising and sponsorship.
Counterpoint: It's always been possible to monetize on the web, and the opportunities are growing
The web would not be the engine of modern industry if there weren't ample opportunities to cash in. Although direct "pay-per-use" mechanisms haven't yet flourished, there are various niches where subscription-based "software as a service" solutions have indeed become viable. Examples include Google Apps, 37Signals' range of products, and premium versions of various email services. Furthermore, direct payments aren't the only way to profit from web apps. There's online advertising, affiliate links, sponsorships, cross-promotion to other products and services.
Having said that, it's perfectly reasonable for a web developer to read the headlines and experience a dash of payment envy. You can't submit a web URL to the native marketplaces, so what's a web developer to do? What you do is create a native "wrapper app" - for each platform you want to target, create an empty native app that simply contains a web view. The web view is where you embed the real app. Then you just submit these apps to the various marketplaces (and hopefully watch the money roll in!). There are probably hundreds, if not thousands, of web-powered apps in the main marketplaces today, some of them so cunningly assimilated that we don't even know their web apps at all.
The downside is the onus of cross-compiling to each platform. Here's where an existing framework like PhoneGap can help. Even better, there are web services like PhoneGap Build and Apparatio under development. Point these websites to your code repository, and out pops an Android app, an iOS app, and so on...ready for you to submit to the respective stores. No installing native SDKs on your machine; all you needed to build all these native apps was a a code editor and a web browser.
Will the marketplaces ever support web apps directly, without all the overhead of wrapping them natively? It's not yet clear. We do know that Google introduced the Chrome Web Store last year, and although it applies only to the desktop, the store has triggered interest from other browser vendors, and is overall part of a trend towards web app catalogues, including some mobile-specific attempts. It's early days for the concept of a web store, but the signs are promising.
Conclusions
It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.
One technique mentioned in this article is hybrid apps, and this may be the best compromise for some developers: web view where it's possible and platform-specific native components where it's not.
If you do choose the web path, be mindful of web standards and the principle of progressive enhancement. The web is a technology that knows how to target the multitudes of devices and operating systems around. Whether you choose to call it "fragmentation" or "diversity", the web embraces it and you developers can benefit from all the prior art out there.
video by GoogleDevelopers
Reto Meier, Michael Mahemoff Native apps or mobile web? It's often a hard choice when deciding where to invest your mobile development resources. While the mobile web continues to grow, native apps and App Stores are incredibly popular. We will present both perspectives in an app development smackdown.
Native apps on various mobile platforms deliver web content on the go. But the frequent updates and fragmentation issues associated with the hardware and software to outreach consumers, a developer needs to target different mobile devices to create separate apps for iPhone, Android, Blackberry and Windows Phone 7. This results in a time-consuming process and makes it costly as the operating systems are constantly upgraded.
HTML5, the 5th version of HTML, is the latest web technology with rich multimedia features and interoperability features for smartphones and tablets makes it compelling and formidable. HTML5 web apps can be accessed on mobile browsers and runs on different mobile platforms just like native apps. HTML5 provides offline support via local data and application caching without the need for internet connection.
Developers are adopting HTML5 to build cross-platform mobile apps as a "Build Once, Run Many" solution to make mobile web better with device-neutral mobile app development. Developers can build mobile apps for HTML5 or Native apps for iPhone, Android, BlackBerry on different operating systems.HTML5 is fast becoming a new standard for mass adoption among developers to create web-based applications which isn’t stuck in one mobile platform like iPhone or Android.
HTML5 Features
- Dynamic scrolling banners for online promotions of products
- Improved navigation, menus and pop-up windows allows more content integration
- Games with advanced graphics support, image galleries with scroll, swipe and zoom features
- Cross-platform mobile application development
- Advanced GPS, IP address, RFID data integrated
- Rapid search results
- Mini-Carts integration on mobile sites allows users to stay in the page
Features
HTML5
Native Applications
Security
In a browser environment, users can manipulate native code which leads to possible hacking; debugging tool can be abused; Local database can be manipulated;
Native apps require updates; While accessing internet for sending information, it should be made secure with SSL.
Synchronization
Offline storage capabilities; If a Web app is connected to the Internet, it can continually save data to the cloud. When it's offline, changes aren't always stored in the cloud. While changing browsers problems of data synchronization occurs which makes it difficult to find the latest saved data.
Problems in synchronization can be found by tracking file names and change dates
Storage
Local data storage is limited as compared to desktop apps;
For syncing local data on device, data should be encrypted
Capabilities
Unique and engaging features not available in Mobile web apps; In-app features not within scope of HTML5 app. Developers can build a hybrid app through PhoneGap and get platform features; Evolving standards and adding features.
Better in-app experience and integrates well into the device eco-system with widgets and notificiations. Interact with device’s hardware using GPS, Accelerometer, Camera
Marketing/Distribution
Apps published in websites. SEO-friendly; Share web apps with friends by linking with email and social media
Submit native apps on App Store or Android Market; Users can browse, search and get recommendation from the market.
Monetization
Possible to monetize on the web through a viable SaaS solution; Online advertising, affiliate links, sponsorships, cross-promotion to other products and services are the other ways; Build cross-platform apps through PhoneGap or Titanium, wrap them as native apps and distribute via various market places
Mobile platforms offer developers to directly charge for their apps with one-time payment option. In-app payment and subscription mechanisms are also available in some platforms which help developers to convert a successful app into a long-term revenue stream.
Advertising and sponsorship are the other web models for easy monetization
Performance
Today web apps run faster with advanced functionality, multimedia, games optimized for improved performance
Faster and better; Taking advantage of GPU acceleration and multithreading
User experience
More control over look and feel; Custom UI build according to needs
Native look and feel
Development
Cross-platform and cross-browser support to develop apps for various mobile platforms using HTML5, CSS3, Javascript; HTML5 will be fully ready by 2014;
HTML5 examples: Yahoo, Amazon, YouTube, Amazon’s Cloud Reader
Easier to develop using Objective C, C++
As the debate is heating on the advantages of HTML5 mobile web vs the mobile app, these mobile tools should be positioned as strategic perspectives and complimentary. HTML5 web apps will not kill native apps. Some apps are best suited for native experience in terms of its speed, performance and execution, and some others for the web. Hybrid apps are a compromise for developers where web view is possible. Recently the mobile industry is hit by fragmentation, standards and protocols. If the developers are targeting cross-platform apps for fragmentation and diversity, whichoptimized to web technology, then the expertise should be more HTML5-centric. Overall, enterprises can engage with consumers by leveraging both these brands.
Check this video:
Don't worry, we won't post anything.
5
6
