2 Replies Latest reply on Jul 31, 2009 7:12 AM by jayp_user

    Player skins - How can we best share them, what is the preferred method?

    jayp_user

      MXML provides a format for interchangeability but am I right in assuming we need Flex to author/modify UI Look and Feel? Can we use Flash with MXML or Fireworks and import to OSMF, what is best practice please?

        • 1. Re: Player skins - How can we best share them, what is the preferred method?
          Edwin van Rijkom Level 2

          Right now, the framework does not include a skinnable player, so all player chrome is custom, and can be made in any way the author sees fit:

           

          As a starting point, we provide a MediaPlayer class that exposes all required media element playback logic. Additionally, there's a MediaElementSprite class that caters for putting a viewable media element on the display list. Last, there's MediaPlayerSprite, that combines the MediaPlayer and MediaElementSprite components into one. The idea is that player authors can these components as the basis for their player, hooking up their own chrome implementations.

           

          If I may turn the question around a little, would you like to have OSMF include a skinnable player, and if so, how would you like the skinning to work?

           

          Thanks,

          Edwin

          • 2. Re: Player skins - How can we best share them, what is the preferred method?
            jayp_user Level 1

            Many thanks,

                 In answer to your question, I would like to see true (2.5D (including a basic Z dimension feature for stacking elements)) multi-layer layouts exported straight from fireworks, this would allow the positions of elements to be shifted/tweaked after the initial player startup without the 'flattening' and de-objectifying the elements that simple 'cake cutter' bitmap exports will have.

             

                 It will also allow fancy branding and a future for possible animation of elements such as visual skewing or zooming to suit different screen dimensions, this would give a "1 set of player gui elements" fits all screens/handsets feature and allow for 'inplay screen flips' for handheld users without loading 2 layouts.

             

                 Rich media presentations, as opposed to simple video, will need everchanging player layouts and branding while playing the mixed media.

             

            HTH