Senior Project Requirements Document

1.1. Purpose

This document specifies the functional requirements of the Suteki Suteiki (tentative title) software. It is a live document that will change as stakeholders add, remove or alter demands on the software and the development process. The document is meant to serve as a guideline for the implementation of the software. During sprints the developers will select some requirements to implement; these requirements will be considered to be frozen for the period of the sprint.

1.2. Intended Audience

1.2.1. Developers of the software (The Science Ninja Team)

Developers may use the document as a guide for the design and construction of the software.

1.2.2. Stakeholders in the project

Including Dr. Beck, Japanese Professors at Villanova University, and the members of the Fall 2008 CSC Senior Projects class.

1.2.3. Those interested in investing either time or money in the project.

1.3. Project Scope

The software is a tool for the creation and perusal of interactive multimedia presentations. These presentations are, for the moment, limited to instruction in Japanese language and culture. The software will run on a web browser; it will be useable over the internet or on a local machine.

The software is designed to create an immersive learning experience, based on the theory that increasing the scope of a lesson and allowing the user to control instruction will increase interest and performance in the skill. The design team believes that culture and language are inextricably tied together, and that to learn one is to learn the other. The ability of the tool to tie related data together to form arbitrarily large interactive learning environments will enhance a student's understanding and foster an enjoyable and effective educational experience.

As the software is an application creation tool, the scope of created applications can be quite large. However, the software used to create these applications will itself be only simple tool.

1.4. References

---

2.1. Product Perspective

Typical use of this product will be through a web browser. The software will feature a Player tool and an Editor tool.

2.2. Product Features

Suteki Suteiki is a tool used for the creation of interactive multimedia applications. The primary purpose of these applications, for the purpose of this project, will be the teaching of Japanese language and culture. Applications will consist of a video which is overlaid with dynamic content, including clickable text, objects, and regions. These objects will be linked to the video, activating or appearing at certain prescribed times during the video and changing according to the specification of the designer. For example, as the video progresses text may appear at the bottom of the video display as subtitles. The user may click on these subtitles to activate links to further information, such as definitions or notes on usage of words. As another example, during the video an object may appear onscreen that the user is not familiar with. Creators may create a region over this object that, when clicked, will link to an explanation of the object and its significance in the context of the video or in the culture as a whole.

The software consists of a Player component and an Editor component.

2.2.1. Player

The Player is used to view interactive movies. It will include precise controls for playback of videos, and ability to display dynamic information that the user may interact with.

2.2.2. Editor

The Editor is used by Owners and Moderators to create and link dynamic content to videos.

2.3. User Classes and Characteristics

User roles are spelled out in greater definition in the System Features section.

2.3.1. Viewers

Viewers are users that interact with the software through the Player. These users will have the ability to use all content Moderators have added.

The ability of Viewers to add content to videos is conditional on Viewer rights assigned by Moderators and Owners:

• If a video is designated as Creator-Content only, then Viewers may not add content to a video at all.
• If a video is designated as Creator-Approved, then Viewers may add content, but it will not appear unless it is approved by a Moderator or an Owner.
• If a video is designated as Any-Content, then Viewers may freely add content.

2.3.2. Owners

Users who create an interactive application with the software will be known as Owners. Owners are Moderators with additional administrative control, including:

• Ability to promote and demote Owners.

2.3.3. Moderators

Moderators are those users who are authorized to create, modify, and delete interactive presentations. This includes:

• designing and writing the interactive content that Viewers will use
• approving modifications that others have made
• promoting other users to Moderators, and demoting current Moderators.

2.3.4. Guests

Guests are users who are not logged in to the system. They may view and interact with any content that has not been restricted by Moderators or Owners.

Guests may not add, modify, or delete interactive content.

2.4. Operating Environment

2.4.1. Operating Systems

Supported operating systems will include those that can run the browsers listed below. Focus will initially be on Microsoft Windows XP Professional. Other operating systems will be ignored for the purposes of the project.

2.4.2. Web Browsers

2.4.2.1. Google Chrome

Chrome will be the main target browser due to its light weight, speed, adherence to standards, and somewhat revolutionary treatment of web applications as actual desktop applications.

2.4.2.2. Mozilla Firefox

2.4.2.3. Macintosh Safari

Safari shares a rendering core with Chrome, which will likely make support easy.

2.4.2.4. Unsupported Browsers

• Microsoft Internet Explorer will not be officially supported due to its loose adherence to web standards and insecure operation.
• Opera
• Any others not explicitly stated in this document.

2.5. Design and Implementation Constraints

2.5.1. Development tools

The project is currently slated to be developed using Adobe/Macromedia Flash. DHTML and AJAX may be required as well.

2.5.2. Content formats?

Content stored as flat files on web server, or in database?

2.5.3. Deadlines

A working product must be delivered and presented to stakeholders on Dec. 15th, 2008.

2.6. User Documentation

All design, help, and related documentation will be stored as live documents on the Science Ninja Team website.

2.7. Assumptions and Dependencies

2.7.1. Target systems

The software will be developed on and targeted to relatively high-performance systems. This is to ensure the best quality of delivered content with the least amount of development fuss in the limited timeframe available. The software may undergo additional modifications in the future to make it more accessible to less powerful systems.

2.7.2. Forward compatibility

It will be assumed that no dramatic changes will be made to future revisions of technologies this software depends on, including operating systems, browsers, and delivery mechanisms, which may hinder, change or completely destroy the software's funcionality.

---

Available features depend on user class. User classes that may use a feature are noted in square brackets after the feature name. All features available to Viewers are also available to Moderators. All features available to Moderators are also available to Owners. Features available to Owners are available to Owners only.

This section describes system features only. Interfaces to the system for accessing these features is described in the Interface Requirements section.

3.1. Video Playback

[Guests]

3.1.1. Description

Users may play a video that has been created with the system. Interactive Content that has been defined for the video will appear in the video at prescribed times.

3.1.2. Functional Requirements

• PLA-REQ-1:
  Video must play in the Video Player.
• PLA-REQ-2:
  Video must begin playing, after sufficient caching, automatically upon page load.
• PLA-REQ-3:
  Video playback must halt upon reaching the end of the video.
• PLA-REQ-4:
  Interactive Content must appear at the times that have been prescribed by the creator of the content.
• PLA-REQ-5:
  Interactive Content must not appear at times that have not been prescribed by the creator of the content.
• PLA-REQ-6:
  Interactive Content must move and change properties as prescribed by the creator of the content, and not otherwise.
• PLA-REQ-7:
  Interactive Content must remain available even when video playback is paused.
• PLA-REQ-8:
  Elements that appear onscreen as a result of user interaction must remain onscreen until they are dismissed by the user. This includes when the video is playing, when it is paused, when it is stopped, and when video transport control is in progress.

3.2. Interactive Content

[Guests]

3.2.1. Description

Various devices will be made available to video creators to place on interactive videos. Viewers of the video will be able to interact with these pieces of Interactive Content as the creators of said content specify. Interaction with each component will be described in the Interface Requirements section.

3.2.2. Functional Requirements

• Interactive Content:
• IC-REQ-1:
  Interactive Content must be interactive. IC must support: left-clicking, double-clicking, right-clicking.
• IC-REQ-2:
  IC must support quasimodal modifier keys. That is, holding the shift, control, or alt keys while single L-Clicking may perform different actions than simply L-Clicking.
• IC-REQ-3:
  Single L-Clicking on IC must perform a default action prescribed by the content creator.
• IC-REQ-4:
  Single L-Clicking on IC with modifier keys held down must perform an action prescribed by the content creator, which may or may not be the same as for single L-clicking that IC.
• IC-REQ-5:
  Modifier key combinations will not be supported. When the user performs modifier key combinations, a single modifier key will be selected based on these preferences: Shift takes precedence over control, Control takes recedence over Alt. For example, if Control and Alt are held down while clicking, Control will be the only modifier key recognized. If Shift, Control, and Alt are all held down, only Shift will be recognized.
• IC-REQ-6:
  Double L-Clicking on IC must perform a secondary action prescribed by the content creator.
• IC-REQ-7:
  Single R-CLicking on IC must open a menu listing all available actions for that IC.
• IC-REQ-8:
  Interactive Content will have an order, such that when two pieces of IC spatially intersect, one will be considered "on top" for the purposes of interaction. Content that is on top will be the content that the user interacts with when they Left-click.
• IC-REQ-9:
  IC that is not on top must still be available for interaction via Right-clicking.
• IC-REQ-10:
  IC is not required to be interactive. Some text, for example, may be simply for description or comentary and will not necessarily perform and actions when clicked on.
• IC-REQ-11:
  IC may be visible or invisible.
• IC-REQ-12:
  When IC is invisible, it may either be interactive or not interactive as prescribed by the content creator.
• IC-REQ-13:
  IR may be collected into groups for the purposes of visibility. The viewer of a video must be able to make all groups of IC visible or invisible. The options of visibilty and invisibility must be visible to the user at all times.

• Interactive Text:
• IC-REQ-14:
  The system must support Interactive Text. Interactive Text is text that will appear over the video for an interval specified by the content creator.
• IC-REQ-15:
  IT appearing to viewers must support fonts and text styles available to content creators.
• IC-REQ-16:
  IT may be "Static" - fixed in one location for the duration of its appearance - or "Scrolling" - appearing from offscreen at the right and moving to the left until it disappears offscreen again.
• IC-REQ-17:
  Users must be able to interact with IT on a character level. That is, each character of text must have its own independent creator-specified interactions.
• IC-REQ-18:
  Characters will act as though they are inside a rectangular IR. Clicking inside the IR will produce effects as described in IC-REQ-1 through IC-REQ-9. The mouse pointer need not be over a pixel filled by a character. For example, clicking the center of an O will be sufficient for interaction.

• Interactive Regions:
• IC-REQ-19:
  The system must support Interactive Regions. Interactive Regions are user-defined closed shapes that appear over the video for an interval specified by the content creator.
• IC-REQ-20:
  Clicking anywhere inside an IR will produce the effects as described in IC-REQ-1 through IC-REQ-9.
• IC-REQ-21:
  IRs may move onscreen and offscreen as prescribed by the content creator.
• IC-REQ-22:
  The system must support rectangular IR.
• IC-REQ-23:
  The system must support circular IR.
• IC-REQ-24:
  The system must support arbitrary polygonal IR. That is, connected polygons with any number of sides of any length.
• IC-REQ-25:
  The system must support free-drawn arbitrary filled shapes.

3.3. Interactive Content Actions

[Guests]

3.3.1. Description

This section describes the interactions the user may perform with Interactive Content. These include opening links in a web browser and the creation and management of interactive elements inside the video player.

3.3.2. Functional Requirements

• Pop-up elements
• ICA-REQ-:
  Interacting with IC can produce a semi-transparent pop-up window inside the video player. This pop-up will be considered an Interactive Element.
• ICA-REQ-:
  An interactive pop-up element may contain a creator-specified web page.
• ICA-REQ-:
  An interactive pop-up element must have visible controls allowing the content inside the pop-up to be opened in a web browser.
• ICA-REQ-:
  Links found in the web page housed by the pop-up element must open in a web browser.
• ICA-REQ-:
  The pop-up must not cover more than half of the video player.
• ICA-REQ-:
  The pop-up must remain onscreen until the user dismisses it.
• ICA-REQ-:
  Controls to dismiss the pop-up must be visible at all times.

• Links
• ICA-REQ-:
  Interacting with IC can cause a web browser to follow a URL. This will be referred to as Opening a Link.
• ICA-REQ-:
  Opening a link must not cause the web browser housing the video player to dismiss the video player.
• ICA-REQ-:
  Opening a link may cause the URL to be opened in the Content Area of the housing web page, or in a new browser window.

• Property Changes
• ICA-REQ-:
  Interacting with IC can cause the properties of the currently viewed video to change. For example, it may cause groups of IC to become visible or invisible.
• ICA-REQ-:
  Property changes must take place immediately.
• ICA-REQ-:
  The user must be made aware of property changes.

3.4. Video Navigation Controls

[Guests]

3.4.1. Description

The user may control the playback of the video in various ways. The user may pause playing video, or play paused video. The user may go to any point in the video; that is, they may specify the next frame to be played by the video player, provided that frame is in the video. The current position in the video will be called the Tape Head. Playing a video can be thought of as moving the Tape Head to the sequentially next frame and outputting the content found there. Moving the Tape Head will be referred to as Seeking. For example, Seeking to 3:45 will cause the video to play back starting from the frame 3 minutes and 45 seconds into the video.

The mechanisms of video navigation will be referred to as the Transport. Fine control of the Transport will be possible. In other words, the user will have a large proportion of possible locations to Seek to per second of video.

The user will be able to specify Markers, which will indicate frames that may be easily Seeked to. The user will be able to Loop video segments.

3.4.2. Functional Requirements

• NAV-REQ-1:
  The user must be able to pause video which is playing back at any time. This will cause the Transport to halt at the current frame.
• NAV-REQ-2:
  Video must remain visible during a pause. That is, the current frame must be displayed onscreen.
• NAV-REQ-3:
  Sound playback must halt during pause.
• NAV-REQ-4:
  Interactive Content that is available at the time of pausing must remain available while the video is paused.
• NAV-REQ-5:
  Elements that have appeared as a result of interaction with the video must remain onscreen during video pauses.
• NAV-REQ-6:
  The user must be able to interact with Interactive Content while the video is paused.
• NAV-REQ-7:
  The video will pause after displaying the final frame in the video. The Tape Head will remain at the final frame of the video.

• NAV-REQ-8:
  The user must be able to resume playback of the video after pausing. Video will play from the next sequential frame. The exception is when the video has paused after reaching the end of the video. The final frame of video will treated as a normal frame with no frame following it sequentially. Thus, attempting to resume playback from the final frame will do nothing.

• NAV-REQ-9:
  The user may Seek to any frame in the video. Seeking to a frame will transport the Tape Head to the specified frame.
• NAV-REQ-10:
  If the video is paused at the time the user performs a Seek operation, the video will remain paused until the user chooses to resume playback. At that time, the video will resume playback as described in NAV-REQ-8.
• NAV-REQ-11:
  Immediately upon user performance of a Seek the frame specified by the user must be displayed in the video player. The video player must not play any sound in that frame.

• NAV-REQ-12:
  The user may Scrub through the video. Scrubbing is a way of rapidly Seeking through frames of video in order to find a specific frame to seek to.
• NAV-REQ-13:
  Video will temporarily pause during Scrubbing.
• NAV-REQ-14:
  Sound will not play during Scrubbing.
• NAV-REQ-15:
  Upon completion of Scrubbing, the Transport will Seek to the user-specified frame. Playback from that point will be governed by the requirements for seeking found in NAV-REQ-10 and NAV-REQ-11.

• NAV-REQ-16:
  The interface must allow fine control of the Transport. This means users must be able to find any frame of video they desire using only the controls made available to them. THIS IS NOT REALLY A FUNCTIONAL REQUIREMENT, EH?

• NAV-REQ-17:
  The software must allow for the creation of Markers. Markers refer to (or "point to") frames of video. They may be thought of as bookmarks in a video.
• NAV-REQ-18:
  The starting frame of video and the ending frame of video will each be automatically considered Markers.
• NAV-REQ-19:
  Markers will remain visible in the interface.
• NAV-REQ-20:
  The user may instantly Seek to the frame specified by a Marker. Seeking to a Marker will be treated as seeking to a frame, and thus will be governed by the requirements for Seeking in general found in NAV-REQ-10 and NAV-REQ-11.
• NAV-REQ-21:
  The user must be able to change the frame a Marker refers to, with the exception of the starting and ending Markers.
• NAV-REQ-22:
  The user must be able to create a Marker at the Tape Head.
• NAV-REQ-23:
  The user must be able to set a Marker to point to the frame at the Tape Head.
• NAV-REQ-24:
  The user must be able to delete Markers, with the exception of the starting and ending Markers.
• NAV-REQ-25:
  The user must be able to set up to 16 Markers in a video, not including the starting and ending frames.
• NAV-REQ-26:
  Markers must be stored on a per-user basis, so that when a user returns to the video the Markers they have specified will still be there.

• NAV-REQ-27:
  The user must be able to specify a Loop in the video. A Loop is a segment of video that repeats. When the Tape Head reaches the last frame in a Loop, instead of moving to the next sequential frame it will Seek to the first frame in the Loop.
• NAV-REQ-28:
  The system will allow for only one Loop in a video.
• NAV-REQ-29:
  The user will be able to specify a Marker as the starting frame for the Loop.
• NAV-REQ-30:
  The user will be able to specify a Marker as the ending frame for the Loop.
• NAV-REQ-31:
  A Marker that is specified as the ending frame for the Loop may not be also specified as the starting frame.
• NAV-REQ-32:
  A Marker that is specified as the starting frame for the Loop may not be also specified as the ending frame.
• NAV-REQ-33:
  If there are no Markers specified for the video, the starting frame of the video will be considered the Loop start.
• NAV-REQ-34:
  If there are no Markers specified for the video, the ending frame of the video will be considered the Loop end.
• NAV-REQ-35:
  If there is only one Marker specified, and it is specified as the Loop start, the Ending Marker will automatically be considered the Loop end. This must be visible to the user.
• NAV-REQ-36:
  If there is only one Marker specified, and it is specified as the Loop end, the Starting Marker will automatically be considered the Loop start. This must be visible to the user.
• NAV-REQ-37:
  Looping functionality may be turned on and off. If Looping is turned on, the specified video segment will loop as described in NAV-REQ-27. If Looping is turned off, the video will playback normally as described in PLA-REQ.
• NAV-REQ-38:
  If the user has no Markers specified, or has not specified a Loop, the Loop will be considered to be a Loop starting at the Start Marker and ending at the End Marker.
• NAV-REQ-39:
  The status of a Loop, that is, if Loop is turned on or off, must be visible to the user at all times.

• NAV-REQ-40:
  All Transport controls will remain visible in the video player at all times.

3.5. Proposed Content

[Moderators]

3.5.1. Description

Viewers may propose content for inclusion in an interactive video which is specified as Creator-Approved. Such Proposed Content will appear in the Editor for Moderators only. Moderators may choose to view the video with or without Proposed Content: each piece of Proposed Content may be turned on or off by the Moderator. Moderators may choose to approve, reject, or delete each piece of Proposed Content.

3.5.2. Functional Requirements

TODO

3.6. Interaction Inside Video

[Viewers]

3.6.1. Description

3.6.2. Functional Requirements

• IIV-REQ-1:
  description
• IIV-REQ-2:
  description

3.7. Interaction Outside Video

[Viewers]

3.7.1. Description

3.7.2. Functional Requirements

• IOV-REQ-1:
  description
• IOV-REQ-2:
  description

3.8. User Promotion

[Moderators]

3.8.1. Description

As described in the user classes section, different user classes have different privileges for managing video content. These user classes are assigned by Owners and Moderators. The creator of an interactive video is automatically deemed an Owner. Owners may promote other users to Owner or Moderator status. Moderators may promote others to Moderator status. For the purposes of this section, Owners or Moderators promoting other users will be referred to as Promoters, while users being promoted will be referred to as Promotees.

3.8.2. Functional Requirements

• PRO-REQ-1:
  Owners must be able to promote users to Moderator or Owner status.
• PRO-REQ-2:
  Owners must not be made available for promotion to Owner status.
• PRO-REQ-3:
  Moderators must be able to promote users to Moderator status. Moderators must not be able to promote users to Owner status.
• PRO-REQ-4:
  Moderators must not be made available for promotion to Moderator status.
• PRO-REQ-5:
  Promotions must take place immediately.
• PRO-REQ-6:
  Promotees must be informed of their promotion as soon as possible. If the the Promotee has designated an email address for contact purposes, an email must be sent to the Promotee indicating the promotion. The user must also be notified of this promotion at the time of their next login to the system.

3.9. Demotion

[Owners]

3.9.1. Description

Owners and Moderators may also take privileges away from other users. Owners may demote other Owners to Moderator or Viewer status. Moderators may demote other Moderators to Viewer status. Owners or Moderators performing a demotion will be referred to here as Demoters; users being demoted will be referred to as Demotees.

3.9.2. Functional Requirements

• DEM-REQ-1:
  Owners must be able to demote other users to any status.
• DEM-REQ-2:
  Owners must not be able to demote themselves.
• DEM-REQ-3:
  Moderators must be able to demote other Moderators to Viewer status.
• DEM-REQ-4:
  Moderators must not be able to demote themselves.
• DEM-REQ-5:
  Moderators must not be able to demote Owners.
• DEM-REQ-6:
  Demotion must take place immediately. Any privileged actions in process by the affected user must not be allowed. For example, if the Demotee is on a page approving content when they are demoted, that Demotee must not be able to complete approving the content in question.
• DEM-REQ-7:
  Demoters may specify a reason for the demotion if they desire. Specifying reasons is not required.
• DEM-REQ-8:
  Demotees must be notified of their demotion as soon as possible, including any reason specified by the Demoter.

3.10. Video Restriction

[Moderators]

3.10.1. Description

Videos may be restricted such that Guests are not allowed to view them. Content may be so restricted as well. Such videos will be referred to as Restricted Videos. Videos available to all users will be referred to as Unrestricted.

3.10.2. Functional Requirements

• RES-REQ-1:
  Moderators must be able to specify that a video may not be viewed by Guests.
• RES-REQ-2:
  Restricted videos must not be visible to Guests in any way.
• RES-REQ-3:
  Moderators must be able to unrestrict Restricted videos.
• RES-REQ-4:
  Users with a access levels below Moderator must not be able to restrict or unrestrict videos.
• RES-REQ-5:
  Restriction or Unrestriction of videos must take place immediately. THIS MAY NOT BE FEASIBLE DUE TO TECHNOLOGY LIMITATIONS. IN THAT CASE: Restriction or unrestriction of videos must take place as soon as possible, such that a Guest will not be able to initiate viewing of the affected video from the moment it becomes restricted.
• RES-REQ-6:
  Moderators and Owners only must be able to restrict and unrestrict content pages.
• RES-REQ-7:
  Changes to content restriction must take place immediately. For example, if a Guest iniated viewing a video before some of its embedded content became restricted, that Guest will not be able to view the content from the moment it becomes restricted.

3.11. Content Approval

[Moderators]

3.11.1. Description

Owners of a video may specify that all content for that video must be approved by Moderators before it is displayed in the video. If this is the case, content that Viewers add will not be applied to the video in question until Moderators approve it. A Moderator may reject content addition, with the option of alerting the Viewer with a reason for the rejection. Rejection will not explicitly delete the proposed content; it will remain for a time so that the user may modify the content and resubmit it. Moderators may also delete proposed content outright.

3.11.2. Functional Requirements

TODO

---

4.1. Player

The Player will be divided into sections. There will be an area in which to view videos, an area to specify viewing preferences, and an area to display linked content.

4.1.1. Video Player

The video Player will contain a video and controls for the user to manipulate playback.

4.1.1.1. Video area

Video will playback in this area. Additionally, the user may interact with content which the Moderators of a video have created in this area. "Content" includes text as well as visible and invisible regions.

• Left-Clicking on a pop-up region will yield a pop-up bubble inside the video area with Moderator-specified content.
• Left-Clicking on link content in a pop-up bubble will open a link in the Linked Content area of the Player.
• Left-Clicking a link region will open a link in the Linked Content area of the Player.

Objects can be a part of groups, and groups can be a part of families. The user may choose to interact with the object, its group, or its family.

• Left-Clicking a linked character in a text object will open a link for that character in the Linked Content area.
• Shift-Left-Clicking an object in a linked group will open a link for that group in the Linked Content area.
• Ctrl-Left-Clicking an object in a linked family will open a link for that family in the Linked Content area.

For example, clicking on a character may open character information in the LC area. Shift-clicking that character may open the definition of the word in the LC area. Ctrl-clicking the character may open information for the grammar pattern of the clause or sentence in the LC area.

• Left-Clicking in any area not specified as a region will produce no action.
• Right-Clicking in any area will produce a context menu with user-selectable actions as menu items.
  • Areas that do not have regions will produce a context menu with basic actions applicable to the whole player.
  • Areas that have regions will have the basic menu items as well as any items the Moderators specify.
  • Left-Clicking OR Right-Clicking a menu item in a context menu will perform its associated action.

4.1.1.2. Control Bar

The Control Bar will be the central interface for navigation within a video.

• The CB will be located at the bottom of the video viewing area.
• The CB must not obscure any content of the video.

The CB will have a number of user controls for controlling the video:

• Play/Pause button:
  • Clicking the play button causes the video to begin playback from the current Tape Head position and changes the Play button to a Pause button.
  • Clicking the pause button causes the video to halt playback at the current Tape Head position and changes the Pause button to a Play button.
  • The combination of these two buttons is for the purpose of space economy. A better, modeless design may be warranted.

• Coarse Line: The Coarse Line is a control for seeking to an approximate location in the video. It will be composed of a Left and Right button, a Timeline, a Tape Head, and multiple Markers.
  • The Timeline represents the time of the video. The far left corresponds to the first frame, and the far right corresponds to the last frame. The Tape Head moves to the location corresponding to the current frame shown in the video area. For example, as a video plays from beginning to end, the Tape Head will move from the far left to the far right of the Coarse Line.
  • Left-Clicking and holding down the Left arrow rewinds the video at a moderate pace until the user releases the mouse button. The video will be visible to the user as it is rewinding.
  • L-Clicking the Left arrow will instantly rewind the video by 2 seconds.
  • L-Click-Holding the Right arrow fast-forwards the video at a moderate pace until the user releases the mouse button. The video will be visible to the user as it is fast forwarding.
  • L-Clicking the Right arrow will instantly fast forward the video by 2 seconds.
  • L-Clicking any location in the Coarse Line will cause the Tape Head to move to that location and the video to move to the corresponding frame. If the video is paused it will remain paused; if playing it will remain playing.
  • The user may also L-Click-Drag the Tape Head to a desired location to produce the same effect.
  • L-Clicking on a Marker will move the Tape Head to the location stored with that Marker, also changing the current frame of video as described above.
  • L-Click-Dragging a Marker changes its set location. The Tape Head will not move in this case.

• Fine Line: The Fine Line is a more sensitive widget for controlling playback. It consists of a Timeline and a Grab Bar.
  • The FineTimeLine is a relative time control. It can be used to advance or rewind video by up to 10 seconds.
  • Seek values will be distributed across the FineTimeLine in a continuous manner, from -10 seconds at the left to +seconds at the right.
  • The Timeline will be labeled. At the left extreme will be "-10"; the right extreme will be "+10". At the first quarter will be "-5"; at the third quarter will be "+5". These are not buttons, per se, but do correspond to the times that will be added to the video's current location if clicked.
  • L-Clicking anywhere in the FineTimeLine will add the value selected on the FTL to the current video time. For example, if the video is at 3:47 and the user selects -4, the video will seek to 3:43.
  • L-Click-Holding anywhere will bring the Grab Bar underneath the cursor. The Grab Bar will stick to the cursor when the button remains held and the mouse is over the line.
  • Releasing the L mouse button in this situation will seek as described above, using the location of the last intersection of the mouse with the FTL as a value.
  • The Grab Bar may be "thrown," by L-Click-Dragging and releasing the button before halting the mouse. In this case the Grab Bar will continue in the direction of motion with a momentum proportional to the last measured speed of the mouse. It will decelerate and return to the center. The farthest value from the center the Grab Bar reaches will be used in the seeking calculation.

• Marker Control
  • Markers are a way for the user to store video time codes. If there is a segment of video of particular interest to a user, the user may specify a marker at the beginning of the segment, effectively "bookmarking" it for later return.
  • Markers appear at their respective locations on the Coarse Line.
  • Each Marker will have a unique color, for identification purposes.
  • Markers may be assigned "names" by the user. Marker names will appear in a consistent location in the display when the mouse rolls over them.
    • Marker names must not block video.
    • Marker names must not interfere with operation of video controls.
  • Markers must not interfere with normal Coarse Line operation.
  • Left-Clicking a Marker seeks the video to the location specified in that Marker.
  • Right-Clicking a Marker opens a context sensitive menu for that Marker, including the following options:
    • Rename Marker
    • Delete Marker

• Loop Control
  • The user may choose to loop video between two established Markers.
  • Visual indicators:
    • The Loop Control must visually indicate when it is active.
    • The Markers involved in the loop must visually indicate their involvement.
  • Left-Clicking the Loop Control button turns looping on if it is currently off; Left-Clicking the Loop Control button turns looping off if it is currently off.
    • Would this be better to do with a radio button or some control that gives more visual information? But that also takes more space and we're already kind of compact.