Initial Capabilities

 

The user actions the very first incarnation of a Time Browser must support:

 

Vocabulary

 

Room is a dimension/tag used to collect participants recordings,

Event is defined by a start time and an end time

Session is any recording made in a Room during an Event

 

Conference

 

The way someone joins a Room is through

 

Recording Audio

 

Limitations

 

 

Recording Set-Up: Room ID & Event

 

A participant will share a Room ID - which will be used again and again if preferred. This ID will be the name of the Room plus the ID of the host.

 

 

Server

 

 

 

 

Interaction

 

The resulting event record will be presented as a text document with rich controls:

 

 

Query the record for an utterance or a response

how to choose what is presented on the screen – a search

 

In this scenario we expect the user to be able to query the system via voice. The results should be shown as a text document with deep interactions:

 

 

 

Select text to interact with it and change the view

how to interact with what is on the screen

 

The primary view is that of a text document. The user should be able to select text and:

 

 

Note: As the user continues this interaction, the amount of data on the screen changes, these are only view changes, but the views will be tracked so the views can be saved and shared:

 

 

Create ‘Saved Views’

views are as important as documents

 

The user will be able to apply control over what it shown and store this view and share it with others.

 

 

Share Real-Time Coded Documents

emergence of a new way to handle real-world time in documents

 

Another key feature is the ability to share a stream document and have the real-world time encoded so that anyone can open it and go to not just a specified amount of time in the record but to a specific real-world time, such as 2:37pm. This would entail matching real-world time to the record internal timecode and leaving it in the document itself, maybe in the EXIF data, though this should not stop the record to be opened in a regular media browser.

 

We could use the same .zip wrapper as the client application uses to send the initial recording to the server, but this would not allow for other applications to use the audio without being made aware/updated to allow for this format.

 

•  User emails a document, which looks like a normal media document and someone who is not using any Time Browser software can still open it and play it as normal.

•  User emails a document, which looks like a normal media document and someone who is using Time Browser software can point to specific real-world time in the player timeline.