Among the possible projects are:

• HVP ported to the phone
• InReferenceTo.me – all about my day – who i talked to, what I listened to, etc.
• SilentHere – preset the places I want the phone to be very quiet (movie theaters, schools etc.) and have it automatically go quiet there
• AudioNoteToMe – one button press to start an audio note, one button press to save it and email it to me.
• LocatonTag – uses location services to know where you and other players are.  If I take your picture before you take mine then I “got” you and you can no longer get me.  He who gets the most players wins.   Can be massively multi-player and international, over an extended period of time. 
• What’s That? – point your camera at a building, and get back information on the building, architecture, etc.  Point it at a tree, find out what kind of tree it is.  Point it at a bird…
• Location Based Todo Reminder – Read todos from an on line service (Toodledo?) and pick out the ones that are location dependent.  When you come within x meters of that location, hear a reminder.

  The project is scheduled to begin November 1. If you intend to participate in the open source project, please leave comments as to which of these projects seems most promising to you.

The application that we’ll be developing in the next phase of the HVP will allow the user to record and then look up everything that happened from day to day.

With this application, each day you can record:

• Music you listen to
• Pictures you take
• Who you sent and received email from
• Who you chatted with
• Where you were and where you went
• Notes you make about the day
• Accomplishments
• Insights and ideas
• People you meet…

you get the idea.

Some of this is recorded automatically for you while the application is running. Some you enter. Some will be manual today with a goal of making it automated in future versions.  The data you record will be local to your phone unless you choose to upload it to the (to be created) web site.

Plus ça change…

Yes, this is a change in the vision for the next phase, but I think it will better illustrate

• The phone functionality
• Transmedia Storytelling
• Coding for WP7

Development Schedule

NB: due to scheduling conflicts, this is a 1 month delay in the project.

The Fate of the HVP

Phase I of the HyperVideoPlayer project was completed in March. Phase II had been delayed while   The conclusion is that I’ll be working with the program managers who own the MSDN and *.net site players to integrate HyperVideo over the next few months. This will be a branch from the open source project.

The HVP Open Source project (http://slhvp.com) itself, however will move forward with a Windows Phone 7 component.   Rather than port the existing player, we will follow the ideas of Transmedia Storytelling and create a stand-alone application that, ideally, when combined with the HVP will make for an enhanced experience.

A full spec will follow,but for now, here is a top level outline of what we will design and build. You are very much encouraged to sign up on http://slhvp.com to participate.  (Create an account and then add yourself under People – if you run into difficulty, please send me an email)

The Vision

The application allows you to take fast notes, by text, image, potentially video, and email it with one touch to one of a set of known locations.

Working Title: OneTouchIt

Modes

The application is divided into two modes

• Setup/ Configuration
• Usage

Setup/Configuration

Setup/ Configuration has forms for filling in one or more email addresses, one or more subjects and other user-specific information

Usage

The typical use case is for there to be a large blue button that says “Record”  (and in the corner, a much smaller i in a circle for more information and to reach the configuration.

Pressing Record opens a recorder, with a large green  button that both is clickable and that also shows a volume meter.

Pressing the button once turns it yellow and the meter disappears and the word PAUSED appears.  Click again to resume.

Double clicking turns the button blue (ready for the next recording) and opens email. Email is prefilled with the first name in your list from configuration and with the first subject in your list from subjects. The body of your message is your recorded note.

In version HVP WP7 1  you can, on the first page (blue button) select Voice, Note or Image, and the configuration screen allows you to set one as default.

Development Schedule

NB: I am on vacation or traveling for work the weeks of October 26, November 8, 22 29, December 20, 27 and January 3

 

This is a quick update on the next steps for the HyperVideo Project that will touch on the following three sub-projects scheduled to be completed in the next six months:

and how you can follow and/or participate in these projects.

HVP Version 2 – Updating the video player

This goal of this short project is to upgrade the HVP to incorporate the SMF v2, integrate user feedback, and to enable the HVP to serve as the media player for Silverlight.net and potentially many other Microsoft sites. 

The overview of the plan is posted in the Silverlight HyperVideo Platform Codeplex site (http://slhvp.com) as is the release schedule.

While this update will incorporate much of the open source work (and some of the new work will be open source as well) most of the update will be proprietary to Microsoft as it will involve supporting internal meta-data that would not be of interest to other programmers.

While this project is underway, however, the main thrust of the open source work will be on:

HVP/WP7 Version 1 – Porting The HyperVideo Player to Windows Phone 7

The very first version of the Windows Phone 7 HVP application will be a port of much of the functionality available on the web. 

The overview of the plan is posted in the Silverlight HyperVideo Platform Codeplex site (http://slhvp.com) as is the release schedule.

This project will be open-source and I’m hoping to have significant community involvement. Even while this is being completed, however, we’ll launch its successor:

HVP/WP7 Version 2 – A Transmedia-inspired application

Following through on the ideas presented in my recent post, Silverlight As A Transmedia Platform, we will design and implement a stand-alone Windows Phone 7 application that, when coupled with the web-based HVP is mutually enhancing

The overview of the plan is posted in the Silverlight HyperVideo Platform Codeplex site (http://slhvp.com) as is the release schedule.

[ NB: Depending on the level of community involvement, these timelines are very much subject to revision ]

• What features and changes are needed to bring the HVP up to the point that we can offer it for use by Silverlight.net and related sites (version 1.1)
• How do we involve volunteer developers from the community more successfully?
• What is in the next release (version 2)

I’m pleased to announce that we’re ready to resume development. The features for version 1.1 are now listed as ready for development in our Kanban board, however I no longer have an accurate picture of which developers would like to be involved.

If you are already listed as a developer/contributor and wish to continue, please send me an email.  I’ll be purging that list in a week.

If you are interested in participating and are not yet signed up, please go to the developer page, follow the directions in the How Do I Contribute link, and read through the rest of the developer page and then as much as you can of the rest of the documentation.

The key tasks & features for version 1.1 include

• Making the application more self-revealing
• Showing the scrubber and its movement when changing topics
• Breadcrumbs so that you can follow a link and find your way back
• Topics light up as they are reached while the video plays

The key tasks and features for version 2 are divided among feature additions for the existing HVP (e.g., upgrading to version 2 of the player, adding additional modules) and creating (first) a port of the application to Windows Phone 7.

I have a number of ideas about how to smooth the path for contributing community members, but the first step is finding out who is interested.

The Silverlight HyperVideo Player has met with strong support and interest. This mini-tutorial is the first in a series that will walk through the design and delivery of this project.

Understanding the Silverlight HVP

If a picture is worth a thousand words, a video must be worth an order of magnitude more. This video, created as part of the HVP sample set, explains the concepts behind the HVP.

Design Guidelines

I’m a big believer in diving right into the code, but I did want to mention just a few of the design/coding guidelines I imposed on myself when writing this, and we can explore their motivation, implications and outcome as we go:

Overarching message of the code: Silverlight is an application development framework: treat it like one.

• Write Clean Code
• Use Test Driven Development
• Let the Design Emerge
• Understand that the first version is just the launching point for subsequent versions
• Community involvement (including design and coding) should grow over time
• When possible, illustrate “best practices”

Getting Started

The premise of agile programming dove-tails neatly with the approach I’ve been advocating for two decades: get it working and keep it working.  I can’t claim any high minded values behind this; it is just what works for me. Worse, it is what I end up doing, even when I’m supposed to be doing design-first.  I simply can’t design in a vacuum and I get very tired and crabby when I do try to design in advance because it doesn’t work. It never works because

• I learn more about how I want the design to be as I write code
• Requirements change
• The bigger the design, the more likely I am to get it wrong
• Requirements change
• The bigger the design, the more reluctant I am to change it
• And requirements change

The old argument was “don’t paint yourself into a corner.”  On reflection, what I found was I was always painting myself into corners, but if I only painted for a few minutes before fixing the problem I was a lot better off than if I’d spent all day at it.

Emerging Design

I love the term emerging design because it sounds so much better than “figure it out as you go.”

We’ll come back to the most effective technique I know of for making all this work in large complex applications when we talk later about Test Driven Design, but let’s get started.  Here is what I know:

• I want the program to be created from independent components, and MEF will provide a great solution to that.  MEF is non-trivial, however and I don’t want to deal with anything that complex until I have something working.
• Creating a media player is lots of fun, lots of folks have done it, most of the implementations suck. There are Microsoft folks working on an open source solution (The Silverlight Media Framework that they, for some bizarre reason, refer to as the “Smurf”) that not only doesn’t suck (except its acronym) but is really good.  Let’s use that.
• MVVM is hot stuff.  Moreover, it’s hot stuff for all the right reasons. Let’s use that.

The First Thing To Get Working

One of the premises of “Emerging Design” that I like  a lot is this: don’t design anything until you’re going to implement it.  Do not say to yourself “I know I’m going to need this, so let me put in all the hooks I’ll need.”  Reason: when you predict what you’ll need, you are usually wrong. Work done today does not save you work later, but work not done today may never need to be done at all.

In that spirit, the first thing to do is to create an application that has the Silverlight Media Framework player in it, and get that working in a very simple page.

Since adding a SMF is a well documented and short set of steps, I’ll just take my lead from the SMF documentation and create a simple Silverlight Application named HVPT1 (Tutorial 1). That will create two projects: HVPT1 and HVPT1.web.  The startup project will be HVPT1.web, the startup page will be HVPT1TestPage.aspx and the first Silverlight page will be in the HVPT1 (client side) project, the file mainpage.xaml

Getting the SMurF Libraries

For the SMF to work, we need the four SMF libraries, which can be downloaded from here, as well as the IIS Smooth Streaming Player Development Kit which is available here.  The Smooth Streaming Player Development Kit (SSPDK) is unpacked by double clicking on the downloaded .exe.  Place all five DLLs (the four from the SMF and the unpacked SSPDK into the same directory.

In HVPT1 add a reference to all the DLLs except SilverlightMediaFramework.data.dll and then replace the header of HVPT1.MainPage.xaml with the following:

<UserControl x:Class="HVPT1.MainPage"
    xmlns:p="clr-namespace:Microsoft.SilverlightMediaFramework.Player;assembly=Microsoft.SilverlightMediaFramework.Player"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignWidth="640"
    d:DesignHeight="480">

Note that the second line declares a namespace alias “p” that refers to the Microsoft.SilvelrightMediaFramework.Player.  You can now declare the player and its source, which must be a streaming media file. Here’s the entire .xaml file:

<UserControl x:Class="HVPT1.MainPage"
    xmlns:p="clr-namespace:Microsoft.SilverlightMediaFramework.Player;assembly=Microsoft.SilverlightMediaFramework.Player"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignWidth="640"
    d:DesignHeight="480">

    <Grid
        x:Name="LayoutRoot">
        <p:Player>
            <p:CoreSmoothStreamingMediaElement
                AutoPlay="True"
                SmoothStreamingSource="http://video3.smoothhd.com.edgesuite.net/ondemand/Big%20Buck%20Bunny%20Adaptive.ism/Manifest" />
        </p:Player>
    </Grid>

</UserControl>

Build the application and watch the streaming movie. There is nothing more satisfying than getting something (anything) working!

Download the source code

The Silverlight HyperVideo Project has made two guest appearances on Silverlight TV. 

In the first, I talk with John Papa about the project itself and how it has evolved.

Then, during Mix, Tim Heuer and I sat down with John to discuss What’s New In Silverlight 4, and I managed to sneak in a few comments about the HVP as well.

Silverlight TV has numerous great interviews, and is quickly becoming a valued asset throughout the Silverlight community. 

Tens of thousands of people view each episode. Check it out here.

Then take a look at John Papa’s site as well.

Then come back here, because the last thing I want is for you to decide you like JP so much you stop visiting. Next thing you know, I’m sitting in the dark.

Two architectural demands for the Silverlight HVP, which are common to many larger applications, came together this week and crystallized into a design that looks to solve a couple other, unanticipated requirements.   Specifically, we knew that (1) we wanted to have configuration files and that (2) we wanted each module to be created independently of all the other modules. After some discussion, thrashing, input from some great folks at CodeMash, and further review, the design that has emerged allows us to implement two other less thought-through requirements: (3) the ability to restore the state of the application to an earlier condition and (4) the ability to save the state of the application when it is shut down.

The New Design For Configuration

All of this is much easier to understand by diving into the design that has emerged.  While the UI has not been determined, the core modules have been identified, and it is easier to conceptualize them with images; even if they don’t necessarily reflect how the modules will be presented to the user.

Function Vs. UI

Below are two sketches of potential User Interfaces for the same four objects; neither of these represents a considered UI design, but rather are here to make concrete the underlying structure that would support such disparate designs. (Click on images to enlarge)

In the standard mock-up (which may well represent the standard UI), the HVPItemsControl contains a list of all the items (videos, animations, etc.) that will be viewed in this HVPSet.

The Current Item selected (or defaulted to)   determines the topics to be listed in the HVPLocationsControl and the hyperlinks listed in the HVPLinksControl.

Selecting a location causes the HVPPlayer Module to jump to the corresponding location. Selecting a new Item causes the HVPLocationsControl and the HVPLinks Module to fetch their new data

Selecting a link causes a new HVPSet to be created, potentially with its own Items, each of which has its own locations and links.

Distinguishing the Module from its UI

Before discussing configuration, event and state management, let’s look at a quick mock-up of another UI for these four primary modules (excluding the speculated Cloud Module)

The goal of creating this second mock-up, again, is to help wrap our heads around the difference between the functionality of the various modules, and their appearance (UI).

It should be quite easy to create a UI like this just with with templates, though no one is suggesting that this amalgam of different approaches is a serious design.

(Though, I must admit, I like the links appearing in bubbles, perhaps with a soft popping sound as they animate into existence from a point, expanding outwards).

Configuration

The requirement is that each module can be created in any order, and that no module is required, nor does any module know about any other. There are a number of ways to architect for this; though the problem is both constrained and (therefore?) simplified by the decision to create a composite application using MEF.

My strong inclination is to treat design of anything you are not about to code as a form of optimization: best left until you know what is needed. I’m a firm believer in Emerging Design, which, for me comes down to the recognition that you cannot know, in advance, what your architecture should be, because both the requirements and the design will evolve in response to the very act of building the application.

You can, and should,  however, distinguish between a flexible architecture and a brittle one. One great way to do so is to throw ideas at the architecture and see if it has to change significantly every time you add a feature or a new way of approaching the problem. If the architecture nimbly adjusts and, better, expands on the requirement to reveal new possibilities, you are in great shape. (If it creaks and threatens to break with every new idea, then it is time to rethink!)

We have made the following decisions, to be implemented in the next three weeks:

• MEF will be used to compose the application
• An Event Manager (HVPEvents) will be created, and each module will register with HVPEvents when created by MEF
• Events will signal a change in state of the current HVPSet   [footnote 1]
  • Modules will check the state object to determine what their current configuration should be
• Configuration will be created first as objects, then persisted with Xaml   [footnote 2]

The rest of this posting will focus on two key ideas:

1. Configuration and state persistence will be captured in objects and persisted with Xaml
2. Modules announce only that their state has changed; interested modules then chek the current state.

Configuration, Objects, Xaml and Persistance

The state of a module is represented by a corresponding state object (e.g., HVPLocationState). The state of the application at any given moment is held by an ApplicationState object and represented as an HVPSet. The ApplicationState is, in turn, composed of the module state objects. Thus, the state of the application illustrated above would be represented by an HVPSet object that contains an HVPLocationState object, an HVPItemsState object and an HVPLinksState object. Note that there is no state object for the player as the player’s state is determined by the other objects (at least at this moment).

[Note, the state objects are not implemented in the current release, and are really mental placeholders for a final design. The goal, however, is to have objects that correspond to the information stored in the Xaml configuration file]

The ApplicationState object will initially only exist in memory. In time, it will be persisted either locally (local storage) or on a server, and accessed via a URL.

I’ll walk through this below, but note that this design will be implemented in stages, roughly:

• First stage: we only know about configuration state, and that is hard-wired
• Stage 2: we know about configuration state by reading a Xaml file and creating the objects
• Stage 3: we know about configuration state by reading Xaml files (plural) identified by the Modules and assembling the configuration state
• Stage 4: we can return to a previous state by storing a collection of HVPSet objects in memory, each of which consists of state objects for each module
• Stage 5: we can persist state by writing the members of all the HVPSet objects to Xaml files.
• Stage 6: The state of the application can be persisted by a service which returns a URL to that state. The user can then store that URL (to resume later) or send it to someone else (“Check out this very cool video and note the links to our site!”) that will allow another user to restore to the exact state that was saved, including the location in the video, the other items enqueued, the links displayed, etc.

Configuring Each Module

When a module is added to the application by MEF it will register itself with the HVPEvents class. [footnote 2]

Initial Configuration

The module will ask the HVPState for its own state object (e.g., the HVPLocation module will ask for the HVPLocationState object). If that object is not null, the module will use the state object to configure itself.

When an object wishes to raise an event, it will send a message to HVPEvents which will, in turn, raise the appropriate event. The event will signal modules that subscribe to that event that they need to obtain their State object and their use of the state object will be identical to their actions in the initial configuration.

Let’s walk through a couple scenarios:

Bootstrapping when the user selects a video or set of videos

In this scenario the application has not started on the user’s machine, and the user makes a gesture (e.g., clicks on a link) to “watch” a video or an animation, or more likely an entire “experience.” In any case, the URL resolves to an HVPSet which is passed to the application on start up.

As the Application bootstraps it creates the  ApplicationState (a Singleton). The ApplicationState is given the Uri of the selected HVPSet, which returns a Xaml file. The ApplicationState asks the ConfigurationParser to convert the Xaml into an HVPSet. In version 1, the HVPSet that is created has the Uri of the HVPItemsState.xaml file.

When MEF adds the HVPItemsModule, the HVPItemsModule requests the HVPItemsState object from ApplicationState. The AppliationState requests the HVPItemsState from the HVPState, which in turn asks the ConfigurationParser to read the HVPItemsState.xaml file and to return an HVPItemsState object which it then holds a reference to. The HVPState object also returns a copy of the HVPItemsState to the HVPItemsModule(by way of the ApplicationState object.) The HVPItemsModule then sends a message to HVPEvents which in turn raises the ApplicationStateChanged event.

The HVPLocationModule / HVPLocationState objects and the HVPLinksModule / HVPLinksState objects are created in much the same way.

When the HVPViewer is initialized, it obtains the current HVPItem from the ApplicationState which it uses to determine what type of HVPFrame to create. The HVPFrame in turn creates the appropriate HVPPlayer which, in its turn, obtains the item using the same mechanisms.  The HVPViewer registers to obtain StateChange notifications so that if a different HVPItem is requested the correct Frame and Player can be created.

Handling User Generated Events

While an item is displaying the user can take any of the following actions:

• Click on an item in the ItemModule
• Click on a topic in the LocationModule
• Click on a link in the LinksModule
• Stop the application
• Request a snapshot of the current state of the application
• Request a new set from the server (by whatever gesture the user began the application)

Clicking on an Item causes the HVPItemsModule to send a message to HVPEvents which raises the ApplicationStateChanged, which in turn causes the HVPLocation module and the HVPLinks module to re-set their state based on the current item.

Clicking on a topic causes the LocationsModule to send a message to HVPEvents which raises the ApplicationStateChanged, which in turn causes the the HVPLinks module to re-set its state and the HVPPlayer to seek to the requested location.

Clicking on a link causes the HVPLinksModule to send a message to HVPEvents which raises the ApplicationStateChanged, which in turn causes all the modules to set their state based on the new HVPSet. (Each link is tied to an HVPSet with its own set of Items).

In a version after V1, Stopping or closing the application or requesting a snapshot will (probably) cause a dialog box to open to ask the user if state should be saved, which is accomplished by having the ApplicationState save its current  HVPSet either locally or on a server, with a Uri returned which is then saved locally.

Design Simplification

In the current design the only event is the ApplicationStateChangedevent. For now, therefore, we will collapse HVPEvents into the ApplicationState object, and modules will not need to register, they will obtain the ApplicationState Instance and request that it fire the ApplicationStateChanged event.

Marker Reached, TimeObject Created, TimeReached

An earlier iteration of this design designated a number of other events that are now subsumed under the ApplicationStateChanged event, including the events needed to signal the HVPPlayer that the HVPLinks module has created a WatchedTime collection (for elapsed times at which it needs to be notified) and the ability for the HVPPlayer to notify any interested modules that a WatchedTime has arrived or that a Marker has been reached.

All of these are now handled as described above; that is, e.g., when the HVPPlayer reaches a Marker or a WatchedTime it updates the ApplicationState which in turn fires off an ApplicationStateChanged event, and the interested modules reset their own state accordingly (e.g., the HVPLinks module might add a link to its list).

———-

[1] Particular thanks to Jeremy D. Miller for helping me think this through at an Open Spaces at CodeMash.
[2] Special thanks to Rob Relyea and to Glenn Block

I’m incredibly proud to say that we were able to release the Silverlight HVP proof of concept alpha release on time, at 12:05 am Wednesday January 6, 2010 (GMT-5).  As noted in our release schedule this is the first of a series of releases scheduled for every second Wednesday.

While this first release exceeds what we promised for the Proof of Concept, it is still very much a hard-coded representation of what we plan to release in the  coming weeks. Our first major release will be in two weeks, on January 20, when we swap out the hard-coded modules and swap in the mef-based dynamic modules that show the true colors of our emerging design.

Key Features in the Proof Of Concept

• Silverlight Media Framework player subclassed and placed in a view
• Table of contents with hard-coded but live links that seek to the appropriate spot in the streaming video
• Table of links with hard-coded but clickable links that appear at designated times as the movie progresses

Thanks to all for your continuing support.

This mini-tutorial is part of the Silverlight HyperVideo Project documentation.

Taking Risks

One of the great pleasures, and total terrors of documenting this open-source application is that occasionally I have to offer up some half-baked ideas that risk displaying how little I know about a particular topic, but which are necessary to generate discussion. Caveat: this is such an entry.  I could have put this into the project documentation but I saw an opportunity to widen the audience on a topic that is important to Silverlight Programmers, even if not part of Silverlight itself.

Goal

We want the modules in the Silverlight HVP to be as flexible as possible. Towards that end we’ve adopted two strategies:

• Using the Managed Extensibility Framework (MEF) to make every module composable and extensible.
• Using XML files to provide Just In Time configuration for each module.

XML Schemas

It will greatly simplify everyone’s work if we have agreed upon schemas, at least for the configuration files we know about:

• slhvpInit.xml – initialize the application
• slhvpTOC.xml – create a table of contents for a video
• slhvpLinks.xml – establish which links will appear while a video runs and what to do when the user clicks on each

As a necessary first step, I’ve sketched out examples of slhvpTOC.xml and slhvpLinks.xml – these are not intended to be complete, but to generate discussion. They are posted here as a way to invite more folks into that discussion.

slhvpTOC.xml (draft example)

<?xml version="1.0" encoding="utf-8"?>
<ConfigFile Name="TOC Configuration File"
            Guid="687DA074-8F94-43a9-AC23-46DF823F8A65"
            xmlns=http://slhvp.com/TOC>
  <ConfigurationMetaData>
    <Version>0.0.1</Version>
    <Purpose Summary="Create a Table of Contents for a video" />
    <![CDATA[
    This configuration file is used to create the table of contents. The topics are listed as links, which cause
   the video to seek forward or backward to the designated topic.
     ]]>
     <Module Name="slHVP Standard TOC Module version 0.1"
             Guid="D3E2AC2B-FD34-40b4-BC42-308F7956C7D9" />
     <CreatedDate Format="AmericanShort" Date="01/01/2001" />
     <Conditions>
       <Condition Name="Advanced"
                  Value="True" />
     </Conditions>
   </ConfigurationMetaData>

   <ConfigurationData>
   <TOCEntries>
     <TOC>
       <Type> TOC </Type>
       <SeekTo>
         <SeekToTime>00:00:10:000</SeekToTime>
       </SeekTo>
       <Text> Introduction </Text>
     </TOC>
     <TOC>
       <Type> TOC </Type>
       <SeekTo>
         <!-- Seek directly to an injected or existing marker -->
         <SeekToMarker ID="LINQ" />
       </SeekTo>
       <Text> Introduction to LinQ </Text>
     </TOC>
     <TOC>
       <Type> TOC </Type>
       <SeekTo>
         <SeekToTime>00:20:10:010</SeekToTime>
       </SeekTo>
       <Text> MVVM </Text>
       <!-- Designate that this entry in toc is only idsplayed if
       the Advanced condition has been set to true -->
       <Visibility Condition="Advanced" RequiredValue="True" />
     </TOC>
   </TOCEntries>
   </ConfigurationData>
 </ConfigFile>
  

The file consists of a header (lines 2-4) and two major sections – the meta-data (lines 5-19) and the listing of the (abridged) Table of Contents entries (lines 22 – 48). Notice that the final TOC entry (lines 38-47) is visible only if the condition “Advanced” is set to true, which it is in the Conditions section int eh meta-data (lines 15-18.

slhvpLinks.xml (draft)

<?xml version="1.0" encoding="utf-8"?>
<ConfigFile Name="Links Configuration File"
            Guid="83ca650e-25ff-414d-adef-7aa790f9d858"
            xmlns="http://slhvp.com/Links">
  <ConfigurationMetaData>
    <Version>0.0.1</Version>
    <Purpose Summary="Link time to hyperlink to action" />
    <![CDATA[
    This configuration file is used to create linkage among an elapsed time in a How Do I video with
     the text of a new link to display at that time and then with the action to take based on the new link being clicked
     ]]>
     <Module Name="slHVP Standard Link Module version 0.1"
             Guid="FB252D52-A603-4bf4-89C8-AA64E52D0343" />
     <CreatedDate Format="AmericanShort" Date="01/01/2001" />
     <Conditions />
   </ConfigurationMetaData>

   <ConfigurationData>
   <Links>
     <Link>
       <Type> Hyperlink </Type>
       <Time>
         <!--Time format is hh:mm:ss:msmsms-->
         <StartTime>00:00:00:000</StartTime>
         <!--Undefined end time - visible to end of video-->
         <EndTime>0</EndTime>
       </Time>
       <Text> About this video </Text>
       <Action> WebPage </Action>
       <URL> http://jliberty.com/aboutHyperlink.htm </URL>
     </Link>
     <Link>
       <Type> Hyperlink </Type>
       <Time>
         <StartTime>00:05:11:010</StartTime>
         <!--End time of 0 or missing end time both mean no end time, run to end-->
       </Time>
       <Text> What is Linq </Text>
       <Action> Video </Action>
       <URL> http://silverlight.net/learn/video#103 </URL>
     </Link>
     <Link>
       <Type> Hyperlink </Type>
       <Time>
         <StartTime>00:12:00:110</StartTime>
       </Time>
       <Text> Linq Programming Animation </Text>
       <!-- video pauses and is replaced by animation frame -->
       <Action> Animation </Action>
       <!--Required either a URL or a guid to a frame-->
       <GUID>
         E40D045A-4AC4-4ea9-8501-58F0E0407F61
       </GUID>
     </Link>
   </Links>
    </ConfigurationData>
  </ConfigFile>
   

You can see that this format is quite similar to the TOC format, and one open question is whether we need an inclusive schema.

In this file, each Link has a type, where some of the possible values are

• HyperLink (link to a URL)
• Animation (link to a frame that supports animation
• Text (link to a frame that displays non-html text)

Purpose of this posting

To reiterate, briefly, I have two goals with this posting:

1. Generate discussion about what needs to be in the configuration files and whether this is a reasonable starting point and
2. Follow through on the implications of my thinking about markers, links, etc.

Note that this topic is also under discussion here which is a great place to continue the discussion.