Feeds:
Posts
Comments

Posts Tagged ‘HTML5’

A few months ago I was speaking with a reporter and was asked which development model the industry was gravitating toward for Windows 8 apps. My impression was that Xaml + C# appeared to be strongest out of the gate but only time would tell if JavaScript+HTML would slowly close the gap.

So far, this hasn’t happened. C# (and VB) + Xaml development has held its ground as by far the most popular development model for Windows 8 Metro Store apps. In fact, preference is now over 3 to 1 over JavaScript + HTML.

Since early April, I’ve been taking random snapshots of the number of posts on the MSDN Windows 8 development forums and here are the results…

UPDATE for Oct 28: C#/VB gains even more ground…

image

image

Raw data:

Model 9-Apr 14-Jun 31-Jul 22-Aug 28-Oct
JavaScript 3645 5926 7831 8573
10631

C++ 2779 4494 5647 6263
7914

C#/VB 10030 16337 21921 24798
34562

What is the trend? If anything C# is gaining share…

imageimage

imageimage

I have numerous opinions about why this is the way it is, but I’ll leave this speculation for another day. Why do you think C# and Xaml are more popular for Windows 8 development? Or is counting forum post a poor way to measure?

Advertisement

Read Full Post »

Need to build an app that plays video? This week we released a new version of the MMP: Player Framework (formerly the Silverlight Media Framework) made for Windows 8 Metro style applications.

With guidance the Windows 8 and IIS teams, we (Microsoft Media Platform team & Vertigo Software) created an open source media player framework that you can use for both HTML-based and XAML-based Metro style applications.

image

Support for HTML and XAML

The player framework supports both HTML/JavaScript and XAML/C#/VB based Metro style applications. Technically, there are two different components (one for HTML and one for XAML based apps), but they share very similar APIs, feature sets, and in some cases even share the same source code. Under the hood, the XAML version is built on top of the MediaElement that ships with .NET and similarly, the HTML version is built on top of the HTML5 <video> tag.

Our primary goal was to ensure both flavors felt natural and familiar to both HTML and XAML developers. If you are an HTML/JavaScript developer, using the JavaScript version will be very similar to using the other JavaScript controls that ship with Windows 8 as well as those already familiar with the HTML5 <video> tag. If you are a XAML/managed code developer, you can expect the XAML version to adhere to the practices and patterns of .NET & Silverlight controls.

Extensibility

The framework: We refer to the player framework as a framework as opposed to a control or component because it is intended to be a mini-platform in it’s own right. While these details will be hidden to the majority of developers using it as is out of the box media player, the player framework is built on a plugin style architecture that enables the feature set to be expanded and evolve after the fact without touching the core code base. In fact, many of the features currently in the framework are implemented as plugins. For example: the main control bar that the user interacts with is technically a plugin that could be swapped in our out for a radically different implementation.

Styling: One of the most common requirements in building a media player is to be able to skin the UI to match your brand. By default, the player framework ships with a Metro style skin, but you can easily modify the look and feel of the player from CSS or XAML without having to build a custom player.

Open source: the player frameworks ships with full source code under the liberal Ms-Pl license. Crack it open and see how it ticks or make changes to suite your needs.

How similar is it to the existing HTML5 or Silverlight versions of the player framework?

You may already be familiar with the existing HTML5 for the web or Silverlight for the web/desktop and phone versions of the player framework. The Windows 8 version of the framework should feel familiar and is in fact based on much of the same code. However, you should not expect full compatibility. We wanted to make sure the player framework felt like it was made for Windows 8 Metro style apps and it’s respective development model (HTML vs. XAML). We also wanted to meld the two versions and their APIs when it made sense. Lastly, we used this opportunities to make architectural improvements that would better position the framework for a long and bright future.

Features

You’ll find that the player framework has an extensive API chocked full of many useful hooks and features. From 30,000 feet, here is a sampling of features you will find in v1 of the player framework.

  • VOD
  • Progressive video
  • Smooth streaming
  • Rich DVR (Play, pause, stop, fast forward, rewind, skip next & back, seek-able timeline, volume, slow motion, instant replay)
  • Full screen
  • Closed captions (plain text for Xaml and WebVTT for js)
  • Styling support
  • Buffering and error/retry visual states.
  • Poster image
  • Click-to-play UI to let the user choose to start watching.
  • All features already included with the MediaElement and <Video/>
  • Playlist
  • Chapters
  • Timeline markers
  • Support for localization
  • Compact UI for snapped view
  • Support for DRM (e.g. PlayReady)

What’s next?

The fun doesn’t stop here. We’re already hard at work on more features. Here are some prominent ones in the cards.

  • Adaptive streaming APIs
  • Advertising
  • Audio player
  • TTML closed captions
  • Audio track selection (multi-language audio)
  • Live video

Got feedback?

We’d love to hear your feedback and make sure the player framework offers the features and functionality you need in your apps. We encourage developers to check out the player framework on CodePlex and post feedback on the CodePlex forum.

Hope you enjoy!

Read Full Post »

In case you haven’t heard, Google just debuted Google Chrome Frame; allowing developers to run the Google Chrome rendering engine inside IE as a plugin and thereby trumping IE.

Reading blogs like this one, I distinctly get the feeling that most of the tech journalists out there don’t understand what this is really all about. This is not about Google being annoyed with old versions of IE, it’s about HTML5 vs. Silverlight vs. Flash. Right now HTML5 has 3 big disadvantages over their plugin counterparts…

  1. Different browsers will implement HTML5 differently. Even if it is standards based. 
  2. Most browsers don’t support HTML5 and getting a user to switch browsers is a lot harder than getting them to install a plugin.
  3. Standards based innovation is slow. HTML5 in its entirety should be ready for browsers to implement in 2012; just in time to be as far behind Flash and Silverlight as HTML4 is today.

In the end, there are only 2 ways around all of these disadvantages:

  1. Either get everyone to use your browser or
  2. Run everything thru a plugin.

Google Chrome (the browser) and Google Chrome Frame together make it possible for developers to write and test code in an IE-less world, thereby getting more developers to care about Chrome, less to care about IE, and more to choose HTML5 as a framework to develop apps on.

Right now the plugin is an ActiveX plugin and therefore only works on IE, but give Google some time and I’m sure they’ll have a Netscape plugin too that will work in Safari and Firefox. It’s only a matter of time before you Google will be nearly in complete control over how HTML5 will be rendered (if the developer chooses so) and thereby won’t need to wait on a standards committe to approve further innovation to HTML.

Of course, the picture is even bigger than that… whoever owns the developers will own the dominant OS. In my opinion, this is all a tactic in the Android/Chrome OS vs. iApple vs. Windows war and the reason Google built Chrome in the first place.

Read Full Post »