wiki:MEDIA_FRAME_CONTROLS_R0

Version 1 (modified by sriggins, 16 years ago) (diff)

--

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=MEDIA_FRAME_CONTROLS_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed
current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

When playing audio or video, the user needs the ability to control the media. This can be though simple controllers that start or stop the media, slider controllers that allow the user to control where in time the media is playing, or any other kind of controller we can imagine.

As defined in the WBS, this task is related to media content and also affects the image if no content is available, or an image to use if the media is not playing. I disagree with this pre-analysis, because the controllers simply manipulate the content. Each content should be able to determine how to render itself based on it's state. I am not sure which task that feature set should fall into, but we should make note of it here so we don't forget about it.

Frames need a mechanism for handling adornments in general, of which controllers are one type of adornment. Adornments can either render themselves on top of the frame, or extend the size of the frame *without affecting the content of the frame*.

For example, a slider controller with a play/stop button, rewind, fast forward and a slider with a thumb, may live below the content in a frame. This controller would live below video. So if a video is 320x160, and the controller is 16 pixels tall, the actual frame size is 320x176. This is necessary because when the author flows text around the frame, they don't want the text flowing under a video controller.

However, other controllers may not need to extend the frame. One can imagine a controller that shows translucent controls on top of the media as the cursor passes over the media, and then fade out when the user stops moving the mouse.

So, adornments, be them controllers or some other use of adornments, need to be able to specify where they are to be rendered in the frame. They should be able to specify bottom, top, left, right, what their size should be (fixed, expanding in either vertical or horizontal dimensions) and whether or not they live inside or outside of the content.

When adornments are added or removed from a frame, the system needs to adjust the frame if necessary to contain the adornment.

Adornments are properties of a frame, not the content. The same content can be rendered in 3 different frames, some with adornments, some without.

Users will determine which type of controller they want to use via a media properties HUD. This hud will contain settings specific to frames with media content, such as audio and video. Users should be able to toggle controllers on and off, as well as choose which controller they would like to use.

Controllers will need to be able to interface with the content of the frame, so there will need to be a clean way to notify the controller that the content has changed state (someone may use a script to stop the media, and the controller needs to reflect this change of state),

Task requirements

  • Add the ability for frames to have adornments
  • Create a module for controllers, which are a type of adornment
  • Allow controller to register through an extension point
  • Add a media halo/hud allowing the choice of which controller to use
  • Add the ability for controllers to be informed of frame content changes
  • Allow controllers to communicate with a frame's content
  • Think about how controllers can be skinned

Task result

The result of this task is code

Implementation idea

  • Remember to not consider controllers as part of the content per se, they are part of a frame's adornments
  • Keep the connection between controllers and media as simple as possible
  • Remember that every frame can have the same content in different states
  • Adornments might have other uses we have not considered, so they should not be considered as controllers necessarily

How to demo

(Provide instructions for demonstration of the task.)

Design

(Describe your design here.)

Implementation

(Describe and link the implementation results here (from the wiki or the repository).)

Testing

(Place the testing results here.)

Comments

Steve doesn't feel that "including the ability to set image for not-available" and "and image for not playing" are not part of this task.

desc("related to frame contents") desc("should allow customization of how media appear (play button, slider, etc)") desc("including the ability to set image for not-available, ") desc("and image for not playing")