All resourcesGuidesCoursesTips

10 min read

Handling "work in progress" content

Coda docs evolve. Learn best practices for keeping updates under wraps until you're ready for prime time.

There may come a time when you need to add to or change to an active team doc, but the content will take time to create. This will result in some rows or pages being “under construction”, and not ready to be considered along side completed content. For smooth rollouts and to prevent confusion, its important to think through how you will prevent users from thinking WIP content is finished, reviewed and live before it actually is!
What you'll learn:
  • Three options for approaching rows in tables that works-in-progress.
  • Three options for approaching pages that contain work-in-progress content.
buttons
What you'll need:

Handling WIP rows

Watch a walkthrough of all your options

Option 1: Build content in a separate doc

 In this option, you create your content in a separate document and then copy the completed row content into the live team table when it is ready.

Pros

  • No risk of teammates mistaking WIP content as live content. If it’s in the team doc, it’s live.
  • A separate WIP doc can have different sharing settings than the team doc, allowing you to grant access to WIP content to a smaller subset of users. This is optimal for sensitive content.

Cons

  • The WIP doc will not have access to team doc tables or data. This means you will not be able to create connected views to team tables, or @ reference pages/rows in the team doc.
  • Relation column values may not map over correctly.


Option 2: Filter out incomplete rows

 Here, you create a status column to designate whether a row is complete. On your main tables, apply a filter to only show rows that have been marked complete. Then, make a separate building view (you can put it on a hidden page) where you filter for only WIP content. Team members would be instructed that entries not listed on the "complete" table are to be considered WIP.

Pros

  • Changing a status when content is complete is quick and easy.
  • Because you are building in the team doc, you will be able to create connected tables, use @ references.
  • Rows that do not appear on a "live" view are very obviously not ready for consumption.

Cons

  • Although they are hidden from view, rows marked WIP will still appear in search. This means that users can still stumble upon unfinished content. If they are not looking to see what the completion status is, they may not notice it's not yet live.
  • If users seeing WIP rows is unacceptable under any circumstances, this option is not for you.


Option 3: Add a “Work in progress” label to the row

 This is the simplest option. Just putting a “-WIP” tag in a row title or in a callout a the top a canvas column can be enough to signal to a viewer that content is not finished.

Pros

  • Deleting the “WIP” tag when content is complete is quick and easy
  • Because you are building in the team doc, you will be able to create connected tables and use @ references.

Cons

  • Lots of WIP content can become clutter. If a large percentage of your table is under construction, it can be hard for a viewer to focus on content that is actually live.
  • It looks less polished. If this is a client facing doc, you may not want people to see the creative process.

Handling WIP pages

Watch a walkthrough of all your options

Option 1: Hide unfinished pages

 Here you create your pages directly in the team doc, but hide them until they are completed. Team members understand that hidden pages should be considered incomplete.

  • Pros
    • Unhiding pages when content is complete is quick and easy.
    • Because you are building in the team doc, you will be able to create connected tables and use @ references.
    • Hiding pages is a very clear signal to users that content is not live. Its is actually quite uncommon for uses to think to unhide pages in a doc and go looking for things. Hidden pages are usually out of sight, out of mind.

  • Cons
    • Hidden pages are not private pages. Any user with view access to the doc can find hidden pages, and hidden pages do appear in doc searches. If you absolutely cannot have unauthorized people seeing unfinished content, this is not the option for you.

Option 2: Build content in a separate document

 In this option, you create your content in a separate document and then copy the completed pages into the live team doc when they are ready.

Pros

  • No risk of teammates mistaking WIP content as live content. If it’s in the team doc, it’s live.
  • A separate WIP doc can have different sharing settings than the team doc, allowing you to grant access to WIP content to a smaller subset of users. This is optimal for sensitive content.

Cons

  • The WIP doc will not have access to team doc tables or data. This means you will not be able to create connected views to team tables, or @ reference pages or rows in the team doc.

Option 3: Label pages as “Work in progress”

 This is the simplest option. Just putting a “-WIP” tag in a page title or in a callout at the top of the page can be enough to signal to a viewer that content is not finished.

Pros

  • Deleting the “WIP” tag when content is complete is quick and easy.
  • Because you are building in the team doc, you will be able to create connected tables and use @ references.

Cons

  • Lots of WIP content can clutter up a team doc. If a large percentage of your doc is under construction, it can be hard for a viewer to find content that is actually live.
  • It looks less polished. If this is a client facing doc, you may not want people to see the creative process.

Was this helpful?

YesNo