Timeline

A reference guide to help you effectively plan, build, and launch a successful new media project. Each section contains a quick-read guide and includes case studies from seasoned veterans.

The Cascading Timeline

Based on the work executed in the scoping phase a timeline can then be developed. Your digital partner will create an initial timeline based upon the various tasks that need to be executed. These generally will lead toward milestones.

Sample Project Timeline

Technical Requirements - finalizing what technology will be used

  • Timeframe: 1 Week
  • Milestone: Technical Requirements Document

Information Architecture - finalizing the information structure and user flow

  • Timeframe: 1 Week
  • Milestone: Wireframes

Paper Prototyping / Testing - getting a rough paper prototype of the core aspects of your project in front of users

  • Timeframe: 1 Week
  • Milestone: Paper Prototype

Design - establishing the look and feel of the project

  • Timeframe: 2 Weeks
  • Milestone: Photoshop PSD/Flat JPEG page designs

Prototyping / Testing - creating a clickable prototype based on the finalized designs and testing it with real users

  • Timeframe: 2 Weeks
  • Milestone: Clickable prototype

Build - programming the functionality and implementing the design

  • Timeframe: 2 Weeks
  • Milestone: Alpha Version

Testing / Quality Assurance - testing the project and making revisions to eliminate bugs

  • Timeframe: 1 Weeks
  • Milestone: Beta Version

Beta Testing - observing real users on the Beta application, revising accordingly

  • Timeframe: 2 Weeks
  • Milestone: Launch

This timeline example is 12 weeks. We typically recommend trying to keep a project to roughly 3 months. Momentum is crucial, and longer timeframes can lead to moments of inactivity and gaining momentum again can be a challenge. It is best when every team member is intensely focused on the work at hand.

The above timeline is considered “cascading” and follows a traditional approach to software development. It includes periods of user feedback and testing to validate assumptions. However, there are some inherent challenges to a cascading development approach.

This approach builds upon the work executed in previous phases. But what happens if the work executed in an initial phase is flawed? Perhaps there are incorrect assumptions about user behavior. Periods for user feedback and getting your work in front of real users is vital to avoid this.

Another approach is to focus on developing a working prototype as soon as possible, then focusing cycles on revising that prototype repeatedly via direct user feedback. This often referred to as Agile Development. As the revisions continue, refinements are made and eventually the prototype becomes the application.

This approach provides many more opportunities for user feedback and rapid iteration. One important drawback is that this non-cascading approach can take more time and will certainly be more expensive. This is due to the fact the developers are spending more programming time revising and refining the application throughout the entire project’s timeframe. For this reason it is only used by seasoned professionals for projects with significant budgets.

By Mike Knowlton, Partner at Murmurco
@murmurco
More from Mike Knowlton - Build: Scoping, Build: Three Types of Implementation Options, Particpate: TFI Interactive 2014

Creating by Doing

While many of our projects vary in terms of size, scope of work, and levels of engagement, Local Projects always takes a visitor-centered approach that puts the final users at the core of our development process. In order to deliver the most satisfying end use experience, we introduce prototyping into the timeline of the project as soon as possible, allowing the client and users the opportunity to interact with actual working models. We want to see the technology work, observe how visitors are engaging with it, and get a feel for the experience overall. Introducing this into our process early on allows us to be able to make changes to software, experiment with technology and interfaces, and realize possibilities we may have yet to uncover. With early prototyping we can test results, assess usability features and it allows us to think creatively while actually making. It also allows us to engage key stakeholders in the process much earlier rather than waiting for approval of final deliverables. This approach directly impacts and is crucial to our production timeline. By the time we are entering the production phase we have clear understanding of software and functionality implication, and can limit any unexpected bugs or fixes. Alongside this process we are also evolving designs and getting feedback while prototyping, streamlining the process in order to be able to move smoothly into production and ultimately final product.

By David Carofano, Production Associate at Local Projects
@localprojects
More from David Carofano - Build: Technology vs. Experience, Discover: 9/11 Memorial Museum: We Remember, Discover: Cleveland Museum of Art: Gallery One
More from Local Projects - Participate:TFI Interactive 2012

Immersive Storytelling Timelines: Don’t Forget To Fail

Return To Elwha River

Telling immersive stories online allows documentary filmmakers to re-imagine how audiences interact with our work. It’s an equally energizing and daunting task that permeates the project timeline and workflow. Over the course of building a prototype for Border Dispatches and the Return to Elwha interactive documentary, I’ve discovered that the linchpin in making full use of the Internet as a mechanism for immersive storytelling is allowing ample time to fail. At the beginning of a new project, I sketch a rough timeline that invariably falls into this pattern:

  • Dream/Brainstorm
  • Report/Shoot
  • Build
  • Test
  • Repeat!

The first couple steps look familiar; it’s the process digital storytellers brought to the field from other mediums. But the time spent on the front end Brainstorming, and after production is done Building, and Testing is crucial. Keep in mind Brainstorming, Building and Testing take as long or longer than production.

Successful interactive documentary projects are often conceived as such and allow for time upfront to consider questions such as “how will the end user navigate this story” and “will the interactions change by device”? Much of that early creative work informs every process thereafter. For instance, during my trips to the Elwha River I intentionally shot a lot of atmospheric b-roll that I knew I could later use as looping clips or background design elements. The Timeline should reflect the importance of prototyping ideas in the beginning. Before I pick up a camera or write a line of code, I spend time experimenting about how these two forms will work together within the project.

Digital storytelling in the Internet Age allows us to quickly test our assumptions about how we structure and design our stories. Through the web, we have a direct line to our audiences, which we can utilize to create better work. Analytics and user feedback provide an incredible toolset for us as storytellers, but it takes a significant amount of time to use well. The most important parts of the Timeline are Build, Test, Repeat. Whether it’s a two-week short project or a two-year documentary transmedia extravaganza, creating a Timeline with Build, Test, Repeat in mind helps make the project a success.

Showing people working prototypes or near-finished products – and building in time to process all that feedback – seemed like unnecessary risk to me as a filmmaker. It can be a painstaking and aggravating part of the process (hence building in extra time to briefly step away), but the feedback that I have received is incredibly helpful. When I’ve built a Timline that allows for me to user test, I have been able to fail fast, fail often and fail forward. Ultimately, that process makes the project much, much stronger.

www.returntoelwha.com

By Jason Jaacks, Founder of Split Frame Media, Director of Silent River Film, Return to Elwha & Border Dispatch
@jasonjaacks