Forem: Griffin

What is WHEP? – Intro to WebRTC Streaming Part 2

Griffin — Mon, 01 May 2023 18:51:30 +0000

In the previous article, we discussed WebRTC and the new standard developed to help us ingest data with it, known as WHIP. However, for data that is ingested, that same data will likely need to be egressed, or distributed at some point. Bring in WebRTC-HTTP egress protocol, or WHEP. Abstractly, the ingestion is the part that covers the uploading of data to a server, and the egress handles the downloading to an end user. The benefits we gained from WHIP, such as the low latency and end-to-end encryption apply here as well: WHEP enables WebRTC communication on the other end of the content delivery pipeline; WHEP assists with serving content to the viewer.

In this post, we will take a look at WHEP, an IETF protocol developed to let us use WebRTC to egress content to other destinations as a way to modernize content delivery over the web from previous standards.

Why is WHEP useful?

As mentioned above, WHIP only solves half of the equation when working with WebRTC-based content delivery. While you could read the official IETF documentation, we will summarize it more simply here. WHEP aims to solve the distribution aspect of WebRTC-based content, See the below diagram for a visual aid of how this works together using Dolby.io Real Time Streaming APIs as an example:

The benefit of having WHEP supplement the egress of broadcast WebRTC infrastructure is similar to the benefits of WHIP, namely the standardization. The same way WHIP allows broadcasters to focus on their infrastructure and the scaling of it without needing to worry about logistics, WHEP allows the distributors to focus on end-user experience, as they know exactly how the data will be received and handled. The end goal is optimization of time and resources across all parties with standardization.

WHIP and WHEP do for real-time video what RTMP did for flash video or what SRT does for transport streams. It standardizes the way (protocol) that the media servers speak to each other, like a language, so that any WHIP encoder can talk to any WHIP server and any WHEP service can talk to any WHEP player, without any other setup. Using the WHIP/WHEP URL should simply work no matter which environment is being used.

There are many situations where a standard protocol for streaming media consumption over WebRTC would be helpful. Some options or examples include:

Interoperability between WebRTC services, media servers, publishers, and players
Playing WebRTC streams on TVs and other smart devices that do not support custom JavaScript scripts
Creating modular, reusable software for media players
Integrating with DASH, a current popular standard for adaptive bitrate streaming

Where it differs from just being “the WHIP spec but in reverse” is in the specifics of the protocol. While for the most part it does behave the same as WHIP, using HTTP requests with Bearer Tokens for authentication, it is more flexible with SDP communication. WHEP allows for an SDP offer to be delivered immediately in the same HTTP request, or to send a POST request with intent to receive an offer back. This offers more flexibility depending on use case and environment, which can be learned more about in the white paper provided above. RTSP, an older standard used in the industry, does not support this model for example.

Dolby.io + WHEP

Dolby.io is a leader in the definition and research of WHEP, which is an open standard. Like WHIP, our researchers have developed this standard, offer support for it into our Streaming Platform, and are working directly with software and hardware partners to integrate WHEP directly into their ecosystems. To learn more, see this Kranky Geek recording of Dolby.io Senior Director of Engineering Sergio Garcia Murillo, the head researcher working on developing WHIP and WHEP:

https://youtu.be/rIQVVJOjR0U

We believe WHEP is the future of WebRTC egress, and we want to support the community and projects around it. WHEP is only useful if it gains wide adoption. We encourage you to try out WHEP for your next streaming project and let us know your experience. One way to do this is with our sample app using Node, our sample using Video.js, or using another community implementation such as this one by Lorenzo Miniero. We’d love to hear your thoughts on our Twitter or LinkedIn.

What is WHIP? Intro to WebRTC Streaming Part 1

Griffin — Thu, 20 Apr 2023 18:03:23 +0000

When considering which tool to use for your real-time streaming platform, WebRTC is one of the hot concepts brought into the forefront. While WebRTC has been around since 2011 and has since been successful at being used in many scenarios, optimizing WebRTC for live generated content, such as in the broadcasting industry, as opposed to pre-existing files is where things get more complex. WHIP and WHEP are two new standards designed to assist in ingesting and egressing this media into WebRTC instead of having to rely on using older standards like RTMP to do that.

In this post, we will focus on WHIP, or WebRTC-HTTP ingestion protocol, an IETF protocol developed to let us use WebRTC to ingest content into our platforms over these old protocols.

Why WHIP?

For those of you who are overwhelmed with the official IETF document, WHIP (sometimes known as WISH) is an open standard that you can use right now for your WebRTC based ingestion. You can use it today with open source software such as GStreamer or OBS (fork) as a way to publish your content with WebRTC.

A benefit to using WebRTC based content is it’s extremely low latency and security with end-to-end encryption. However, initial versions of WebRTC based streaming were associated with poor quality and limited viewer numbers. WHIP solves this by removing the translation layers needed to use WebRTC before that cause many of the previously mentioned flaws, giving us all of the benefits of WebRTC without the downsides. WHIP provides a standard signaling protocol for WebRTC to make it easy to support and integrate into software and hardware.

WHIP provides support for important standards, such as HTTP POST based requests for SDP O/A, HTTP redirections for load balancing, and authentication and authorization done by the Auth HTTP header and Bearer Tokens.

Think of this like a train station. Without any rail signalers, the trains will behave sporadically, causing potential slowdowns if too many trains are on the same track, tracks that are unused, and possible crashes and collisions. With a signaler, the trains will be directed more orderly, optimizing the system to keep things moving quickly and efficiently. WHIP acts as this signaler, handling things like creating or deleting endpoints if needed and performing operations like Trickle ICE.

How Does Dolby.io fit in?
As mentioned before, WHIP is an open standard. Dolby.io supports WHIP not only by providing integrations, but also by leading the definition and research into the standard. Our researchers have developed this standard, and our engineers have implemented it into our Streaming Platform, as well as having worked directly with software and hardware partners to integrate this standard directly into their platforms, such as FlowCaster and Osprey for both software and hardware encoding.

We believe WHIP is the future of WebRTC ingestion, and we want to support the development and community around it. As a standard is nothing without wide adoption. We encourage you to try our WHIP today with one of the priorly mentioned integrations for your next streaming project and let us know your experience. We’d love to hear your thoughts on our Twitter or LinkedIn. Or try out our sample app using Node, and leave some feedback on GitHub.

Stay tuned for Part 2 where we will talk about the other end of the process, WHEP, or WebRTC-HTTP egress protocol, and see how WebRTC will define the future of all streaming and broadcasting communications.

Automating Your Stream Start, Intro, and Ending Processes with OBS Macros

Griffin — Wed, 16 Nov 2022 22:04:39 +0000

As you begin developing a brand and a streaming presence, it is often desirable to define and establish your branding with digital assets that are used at the beginning and ends of each of your stream. Often times we see this as an intro video that will broadcast to your audience that your stream is beginning, giving them time to settle in and get excited for the show, whether it be an auction, sports broadcast, gaming event, or something else. While entirely possible to do this manually every time, it can add to the growing complexity of tasks to do when beginning your broadcast. Sometimes you might even forget to play the video at all, human error and all. In this article, we will showcase a few different ways we can automate the media playback to occur whenever you begin your stream, taking an extra step away so you can focus on the broadcast while keeping your brand intact.

Starting Stream

Before thinking about what the intro video is going to look like, first think about what the very beginning of a stream looks like. Most viewers who show up early will see a “Broadcast is not Live” page by default, which isn’t ideal. We want to ensure that users know that you are about to go live soon to keep them on the page instead of closing the window. Though if we start too early, not enough users will be around to see the intro video in the first place, both losing brand awareness, and letting people feel like they missed out. The solution to this is to still start the stream ahead of schedule, but with a static image or video that simply lets the audience know that stream is starting soon.

We can automate the process of beginning this video with an OBS plugin called Advanced Scene Switcher. Once downloaded and installed with the appropriate installer for your system, this plugin will create a new option on the “Tools” menu of OBS with the same name.

Note: If you are experiencing issues seeing this plugin in the Tools menu, ensure you are not installing OBS from Homebrew on MacOS or similar package managers, but from the official install site. We have experienced issues with the package managed versions.

Adding Advanced Scene Switcher to OBS-WebRTC

For use with Dolby.io Streaming, we will want to add the plugin to our installation of OBS-WebRTC. Thankfully, the plugin is compatible, however the installer will only look for OBS-Studio. To add the plugin manually to OBS-WebRTC, do as follows:

MacOS:

In ~/Library/Application Support/obs-studio there will be a folder titled “plugins”

Copy this folder with the installed plugin(s) and paste it into ~/Library/Application Support/obs-webrtc. Restart OBS-WebRTC and it should appear as normal.

Windows:

Follow the above instructions, but replacing the MacOS path with the Windows path for plugins:

C:\Program Files\OBS-Studio\obs-plugins\64bit

C:\Program Files\OBS-WebRTC\obs-plugins\64bit

Using Advanced Scene Switcher

Upon opening Advanced Scene Switcher, we should see a few options. The most important of which is determining if it is on. You can customize how you want OBS to auto-start the plugin, though ensure that the status is Active before using it.

Then, switch to the “Macro” tab.

Here we can begin adding macros for our stream to automate multiple different actions. Let’s begin with the “Stream is about to begin” automation.

Starting the Stream

Inside the Macro tab, we have a few different panels to work with. To begin, lets add a new macro by clicking the “+” under the left “Macros” panel and name it what you want. In this case, I named it “Starting stream”

Now, under the “Edit macro” panel, we have two sections, the macro conditions on top and the macro actions on the bottom. First, lets click the “+” under macro conditions to create a new condition. This will then generate a conditional statement builder for us to define what will begin our macro. In this case, we want it to read “If Streaming Stream starting”. This will trigger the macro whenever we start the stream.

Next, we want to create a new macro action by clicking the “+” under the bottom panel. There are a couple of things we want to do here, the first of which being to switch to our Starting stream scene. This can be one with an action with the following information: Switch scene → Switch to scene using “Cut”, which will automatically set the stream to that scene upon starting the broadcast.

If you haven’t already yet, we suggest creating a scene with a placeholder image or looping video to direct to.

We can also add in some audio as a part of this automation. First, lets add a media source into our scene with some royalty free music we want to play as people join the stream. This could also be a looping video if you are not using a static image in the scene. Ensure that “Loop” and “Restart playback when source becomes active” are checked to ensure that the music doesn’t fully stop until you tell it to.

Then, back in Advanced Scene Switcher, we can add a new macro action to our Starting stream macro to read “Media Music Play ”. This will then ensure that the audio file starts upon starting your stream!

Now, upon starting your stream, OBS will automatically switch to your “Starting stream” scene, and play the audio/video file for a greeting page for all early viewers to be welcomed by as you start amassing viewers.

Creating a Stream Intro

Now that we have created our “Starting soon” macro, we will want to add in a macro for an intro video that will play before switching to the live video feed. This can be done very much in a similar way to what we did above, but with a different macro condition. With a new macro we will title “Intro”, we want to create a condition this time with the “Hotkey” option. Name it whatever seems best to you.

We can then modify the hotkey within the OBS Settings menu under “Hotkeys” to whichever key command seems best, which can be found under the name submitted in the previous step.

Back in Advance Scene Switcher, we can now add in the actions as we did before. Let’s add in another Switch scene:

Another Media action:

This time, we want to switch the scene one more time after the video finishes. To do this, we first need to add a “Wait” action equal to the length of the intro video. This will keep the actions from triggering before the video is finished.

Then after the wait, we can Switch scene one last time:

And now upon hitting the assigned hotkey, the Getting Started scene will swap to your intro video, play it, then switch to the live feed when complete!

Ending Stream Macro

Before ending your stream, you may want to give your viewers another “Stream is ending” screen to let them know the broadcast is completed if tuning in. This will be build very similarly to the previous macro. To begin, we start with another Hotkey condition:

Next, we switch the scene to “Stream Ending”:

Play our exit music or video

Wait for the media to finish:

Then stop the stream with a final action of “Streaming → Stop Streaming”

And that’s it! One hotkey will transition to an ending slide, play music, and end the stream for you. No more fiddling around with multiple applications and buttons to finish that task.

Wrapping Up

In this article, we outlined a few different things:

Installing Advanced Scene Switcher to OBS (and OBS-WebRTC)
Configuring macros for
- Starting a stream
- Playing an intro video
- Ending a stream
Adding custom hotkey support
Managing autoplayed media for streams

This is an extremely useful tool for turning your live streams into a more professional, broadcast quality operation, with use cases expanding to many different industries needing to live stream their content and events.

Read more about the Advanced Scene Switcher on the OBS Forum, or read this blog post on getting started with OBS-WebRTC to enable your live streams to broadcast in real time for maximum interactivity with your viewers.

Happy streaming!

Transcribing Dolby.io Communications Recordings with Deepgram

Griffin — Mon, 11 Apr 2022 16:43:28 +0000

In this digital age where virtual conferences are a dime a dozen, we see a large number of them recorded for future records. There are many uses for these records, including sharing with people who were unable to attend live, distributing for use as training, and keeping backups for future reference. One aspect of these recordings that is taken for granted, however, is accessibility. In this blog, we will demonstrate how to take recordings from your Dolby.io Communications conferences, and use Deepgram to transcribe them to text.

Having text copies of your conference recordings is a good way to offer alternative ways to digest the information. Some people read faster than they listen to spoken words. Some people might not speak the same first language as the one in the conference, and are more comfortable reading it. Others might be hearing impaired, and prefer to read for the most amount of comfort. Whatever reason one might have, we want to make it simple to automate the transcription generation process. Here, we will be using the Dolby.io Communications REST APIs in tandem with Deepgram’s Pre-recorded Audio API in Python as an example of how to generate this process.

Installing Libraries

Before we begin coding, we need to ensure we have all the proper libraries for calling these APIs. We can do this with a simple pip command (use the appropriate pip command for your operating system):

pip3 install asyncio deepgram-sdk dolbyio-rest-apis

This will install both the Dolby.io and Deepgram SDKs, as well as Python’s native asynchronous function library to aid us in calling the async requests the two SDKs use.

It is also a good idea to sign up for a free Dolby.io and Deepgram account if you haven’t already, to get your API credentials.

Obtaining an API Token

In order to use the Dolby.io Communications REST APIs, we need to first generate a temporary access token. This is to help prevent your permanent account credentials from being accidentally leaked, as the token will expire automatically. To learn more about this, read the documentation. In this case, we want to fill in the consumer key and secret with our credentials from our Communications APIs (not Media). We then call the get_api_access_token endpoint within a function so we can generate a fresh token every time we make another call. This is not the most secure way to handle this, but will ensure we don’t run into any expired credentials down the road. To learn more, see our security best practices guide.

from dolbyio_rest_apis.communications import authentication
import asyncio

# Input your Dolby.io Communications Credentials here
CONSUMER_KEY = "<DOLBYIO_CONSUMER_KEY>"
CONSUMER_SECRET = "<DOLBYIO_CONSUMER_SECRET>"

# Create a function that will generate a new api access token when needed
async def gen_token():
    response = await authentication.get_api_access_token(CONSUMER_KEY, CONSUMER_SECRET)
    return response['access_token']

print(f"Access Token: {await gen_token()}")

Getting the Conference ID

Now that we can call the Dolby.io APIs, we first want to get the internal conference ID of the recording we want to transcribe. We can do this by simply calling the get_conferences endpoint with our token.

from dolbyio_rest_apis.communications.monitor import conferences

response = await conferences.get_conferences(await gen_token())
# Save the most recent conference. Change '-1' to whichever conference you want.
confId = response['conferences'][-1]['confId']
print(confId)

Note that in this code sample, we are using the parameter: ['conferences'][-1]['confId']. This will pull only the most recent conference in the list as noted by the "-1" array value. If you are automating this to work with every newly generated conference, this likely will not be an issue. However if you are looking to do this with a specific conference, we suggest using the optional parameters in the get_conferences endpoint to obtain the desired conference ID.

Obtaining the Recording

With the conference ID in hand, we can now call an endpoint to generate a URL that contains the audio file of our conference. For this code sample, we are using a Dolby Voice conference, so we will use the endpoint to Get the Dolby Voice audio recording. If you know you are not using Dolby Voice, you can use this endpoint instead. Note that we are only obtaining the audio track of the conference instead of both the audio and the video. This is for maximum file compatibility with the transcription software. Note that the URL produced is also temporary, and will expire after some time.

from dolbyio_rest_apis.communications.monitor import recordings

# Save only the mp3 file and return as a URL.
# If your conference does not use Dolby Voice, use 'download_mp3_recording' instead.
# https://github.com/dolbyio-samples/dolbyio-rest-apis-client-python/blob/main/client/src/dolbyio_rest_apis/communications/monitor/recordings.py
response = await recordings.get_dolby_voice_recordings(await gen_token(), confId)
recording_url = response['url']
print(recording_url)

To help illustrate, here is an example conference recording made for transcription generated from the above code.

Transcoding it with Deepgram

While Deepgram does work with local files, the presigned recording url saves us many steps avoiding the hassle of needing to download and upload a file to a secure server. With the URL, we can skip those steps and directly insert the URL into the code below adapted from their Python Getting Started Guide. The code provided only uses the Punctuation feature, but could easily expanded with an assortment of the many features Deepgram provides.

from deepgram import Deepgram

# Your Deepgram API Key
DEEPGRAM_API_KEY = '<DEEPGRAM_API_KEY>'

# Location of the file you want to transcribe. Should include filename and extension.
FILE = recording_url

async def main():

  # Initialize the Deepgram SDK
  deepgram = Deepgram(DEEPGRAM_API_KEY)

  # file is remote
  # Set the source
  source = {
    'url': FILE
  }

  # Send the audio to Deepgram and get the response
  response = await asyncio.create_task(
    deepgram.transcription.prerecorded(
      source,
      {
        'punctuate': True
      }
    )
  )

  # Write only the transcript to the console
  print(response['results']['channels'][0]['alternatives'][0]['transcript'])

try:
  await main()
  # If not running in a Jupyter notebook, run main with this line instead:
  # asyncio.run(main())
except Exception as e:
  exception_type, exception_object, exception_traceback = sys.exc_info()
  line_number = exception_traceback.tb_lineno
  print(f'line {line_number}: {exception_type} - {e}')

The Deepgram response provides many datapoints related to our speech, but to pull only the transcription of the file, we are calling ['results']['channels'][0]['alternatives'][0]['transcript']. Feel free to modify the response to generate whatever is most relevant to your needs. For the above sample provided, the result of the transcription is as follows:

Following text is a transcription of the s en of the parchment declaration of independence. The document on display in the rot the national archives Museum. The spelling and punctuation reflects the originals.

Next Steps

This is a very basic foray in how to get started with transcribing your conference recordings. We heavily suggest you invest some time into expanding this to fit your specific use case to maximize the benefit you get from using these tools.

As mentioned before, we suggest taking a look at what Deepgram has to offer in terms of additional features you could add on to the transcription process. For example:

Diarization can help differentiate who is saying what when there are multiple people in a conference.
Named Entity Recognition and/or Keywords to help increase accuracy by providing prior information of things like names and proper nouns.

The transcription of the example recording was not perfect. There are many reasons for this, including imperfect recording environments, confusing speech patterns, and compression as examples. To help give the transcription algorithms a better chance, one option could be to use the Dolby.io Media Enhance API to attempt to clean up the audio before sending it to transcription.

If you want to automatically generate a transcription after every recording is over, we can take advantage of webhooks to remove the manual intervention for you. In fact, the Recording.Audio.Available event provides the recording URL within the event body itself, reducing the number of steps needed to obtain it.

One final idea is if you do only have the video file ready for whatever reason, you can use the Dolby.io Media Transcode API to convert the video file into a format accepted by the transcription service.

You can find the source code file stored in a Jupyter notebook at this GitHub repository. If you run into any issues, don’t hesitate to contact our support team for help, and good luck coding!

Exploring Content Collaboration Solutions for Content Production

Griffin — Tue, 02 Nov 2021 01:59:41 +0000

As a Developer Relations professional, I spend a pretty large amount of my time writing, organizing, and collecting content for publication to our blog. This is at a degree where it is necessary to have a solid project management system to keep everything in order. Having recently been a student as well, I know first hand how important it is to allow for easy collaboration in drafting content, making edits, suggestions, and sharing simple to make it less of a chore to contribute.

It all broke one day where I was getting fed up with the solution I was working on, thinking to myself, there must be something better. We live in a extremely innovative time of technology, surely there must be a startup that solves my needs. So I went on a hunt to trial and test out a bunch of different content collaboration solutions I found from sources like Google, Quora, AlternativeTo, the DevRel community, and more to see if I could find that perfect solution, and maybe help some other people decide at the same time.

The Requirements

At Dolby.io we collect content from a variety of people in multiple different media, but at the end of the day we want to keep everything centralized and consistent when possible. Our blog is handled in the backend using Wordpress, so when considering options for content management it was critical that it played well enough with Wordpress, to avoid as much manual intervention as possible. Because of this, there were a few "must haves" for the platforms to consider:

1. Exceptional handling of code blocks and inline code

This is a developer blog after all, so there needs to be proper ways to share code. Ideally this will contain proper syntax highlighting for languages used, and has good copy-paste ability.

2. Commenting and editing is simple

As this is a collaboration platform, we want the collaboration tools to be robust. Being able to comment on sections of text or the whole document should be easy, with a bonus for tools like "Suggest Edits" for inline changes.

3. Intuitive project management tools

With the scale of posts written over time and the large number of contributors, keeping track of the status and metadata of posts within the same system they are written in is a huge benefit. This helps managers figure out the status of the content, and see what is missing from a glance, and automatically populates based on the original edit.

4. Able to handle multiple users editing at the same time

We don't want collisions to happen if two people are editing at the same time, as that can result in a lot of lost work and wasted time. Ideally this will be a living document that updates automatically.

5. Image and other media handling not tied to their servers

As the content will all be copied into Wordpress, we want to ensure media doesn't copy the internal reference instead of the base file. Otherwise it can look fine for people connected to the company network, but not to the public, which is a tricky thing to troubleshoot when not anticipating it.

6. Cross-platform

We have team members on multiple different platforms who should all be able to contribute. The best solution for this is a web app, where it can easily be connected to a SSO solution.

Nice to Haves

There are a few other bonus points that can help separate the good from the great that I considered:

Low price or a free tier that fits our needs
Version history management
Markdown based editor as either a default or an option alongside a rich-text editor
Have a free trial so I can test it without needing to pay

Immediate Outs

With these rules, some popular tools were immediately thrown out and will not be discussed in further length.

Google Docs, Office 365, and Box Notes all do not have great code block handling, and were taken out of consideration.

Tools like GitHub are enticing for purely technical teams, especially with their Projects feature, but we work with a mixture of backgrounds that make these products too high a barrier of entry. This doesn't stop GitHub of being a good part of the workflow for linking code samples and Gists.

Similarly, cloud based Markdown editors such as HedgeDoc, StackEdit, HackMD and Draft among others are not great choices for those who don't have Markdown experience, plus are a bit more barebones than desired for project management. The same applies for LaTex collaboration software like Overleaf.

Apps like Slick are MacOS only, which doesn't work for team members on Windows or other platforms.

Products I trialed

In no particular order, here are the products I tried out, and my thoughts on how they worked for us. Keep in mind that just because something might not be a good fit for our workflows doesn't mean it isn't perfect for yours.

1. Confluence

Confluence is a tool that a vast majority of people who have worked in tech in the last 15 years are familiar with, due to it being a part of the Atlassian ecosystem, where Jira has been a centerpiece of modern tech workflows. I've used Confluence in every single job I've worked at for this reason, and I tend to have a love/hate relationship with it. It's an extremely powerful tool that allows massive customization of the spaces it has, links very well with itself and Jira, and provides third party extension support for workflows that it doesn't support out of the box.

However, it feels dated with the implementation of a lot of these benefits, where just because the option is there doesn't mean that the option was elegantly designed. For example, code blocks are supported, but require you specifically use a code block macro that is its own container instead of living with the other in line text. It also uses its own markup syntax, which makes taking existing Markdown that you may already have not as simple as copy-pasting it into the platform. Other small quirks like it needing to host every file you upload to it, having a functional, yet quirky way of dealing with simultaneous edits, and the typical Atlassian sentiments many tech workers know make it a compromise.

We use Confluence already at Dolby.io, and I imagine many of you reading this are also using this tool right now, so the price is already right. The best way to sum up my feelings of Confluence are "if it ain't broke, don't fix it", which fits some team's philosophies better than others, make of that as you will.

2. Notion

Notion is the relative new big hitter coming to the block with a recent surge in users that has slowly started taking up the startup scene. Notion is what I would describe as the Atlassian suite if it was made with modern tech design, and it shows from the visual aesthetic to the technical decisions made. However, instead of separating the company into multiple products, it is all grouped in one workspace, where you can link tables, docs, kanban boards, and more together seamlessly and it frankly feels elegant.

Notion uses Markdown as its text processor, though instead of keeping the raw text, it automatically interprets it to make the lives of writers a bit easier, though not as intuitive as a traditional rich-text editor. If text is highlighted, it brings up the command palette, though this isn't the most intuitive behavior for new users. I would say it is similar to Slack's editor, which makes sense due to the high user base.

Overall I was a big fan of Notion, and its growth tends to support my sentiment, as I see more and more companies start using Notion as their main platform for nearly everything. There were issues in image copying to Wordpress, but this was unfortunately fairly standard across most platforms. I will note that I have had server issues in the past with Notion with issues like slowness to not being able to access my documents, though I have not experienced it in recent tests of the platform, and can likely attribute this to its growing pains.

3. Quip

Quip is Salesforce's option in the content collaboration space with a heavy focus on live discussions, with chat, edits, and its integration with Salesforce being its key marketing points. I've used Quip outside of this test in reviewing content from third parties, and found it to be fine, but nothing out of the ordinary in terms of capabilities.

While it was able to do match these claims in experience, overall it really does seem like this is built for sales teams, not content creation, where a lot of the project management assumes heavy Salesforce use, whom I imagine are the target customers for this product.

4. Dropbox Paper

Unlike its major competitors in Google Docs and Box Notes, Dropbox Paper has native support for code blocks, which was a huge boon in its usability for technical content. It's another Markdown based editor with rich-text interpretation, not unlike Notion's offering. It still has commenting support and version history built in (including comment history) which makes it great as a living document solution.

This is where the benefits dwindle though, as its project management capabilities are virtually non-existent, being a cloud-storage solution first. Additionally it played strangely with Wordpress, where linespaces were not kept and code blocks weren't recognized properly. If your team is already using Dropbox as the storage provider, this is an option for consideration, though I wouldn't suggest it except for the most basic of needs.

5. Coda

Upon asking my fellow DevRel community which tools they enjoyed using, Coda was one that was brought up a few times, but with the caveat that it was "highly technical" and more like a Smartsheet or Airtable than a collaboration document solution. I agree with this take, where instead of the previous couple feeling more like a document centric solution, this one felt like more of a project management solution, where content wasn't managed as well as Notion or Confluence.

To be fair, this is not Coda's intent with the platform, instead directly making the statement Docs are the new blogs, where they encourage you to use Coda as the publishing platform. Coda itself looks like a super promising and interesting tool for an alternative blogging process.

6. Slab

With Slab we return back to the "content-first" sub-category of solutions where we have another Markdown based editor with a few bells and whistles added for ease of use. Some of these include a content map that helps visualize the assortment of categories your documents live in, templating, and robust commenting solutions.

Once again, project management is limited, though they have built in integrations with Jira and Miro among others that imply that it isn't meant to be that and you should be using tools dedicated to that workflow for that purpose.

7. Walling

Walling is another project management based solutions which takes advantage of a "grid-like" workspace for organizing content between "walls" while using Markdown as the editor. This makes keeping information like publishing metadata and checklists very pleasant to work with, as they have their own dedicated space instead of needing to format your document in a way that has them live inline with the actual content.

Despite these features, there isn't a great tabling solution, and there isn't a great way to link to other posts in the workspace. It also didn't really feel like it was built for collaboration, as commenting isn't a super intuitive process at all.

8. Whimsical

Whimsical is all about keeping all content in an organized, central place. They center around five main types of content: docs, flowcharts, wireframes, mind maps, and sticky notes that can all be embedded within another. However, it felt more catered towards a creative organization rather than a robust project management feature, as I couldn't find a distinct way to properly create a workflow that autopopulated content when a new document was made.

The benefits of small things like live cursors and linking content within content were useful. It also had the added benefit of working well with Wordpress, where images were not directly copied, but an image upload object was created in its stead, ensuring that you uploaded a proper copy of the image.

9. ClickUp

ClickUp have been advertising heavily lately, with banners all over San Francisco, and when I tried it there was a lot going for it. ClickUp has spaces dedicated for both "Spaces", or your tables of project management based content, and "Docs", which uses a Markdown based editor and organizes and shares your content.

The spaces section reminded me a lot of Airtable with a bit more stuff going on, letting you expand each entry to see the editing history, to do list, attachments, and all, really solidifying itself as a proper "entry" of work to be done. The docs had useful tools like attributing authors and having ample version history. As a major bonus, content copied itself super well into Wordpress, which is a major time save in not needing to reformat every piece of content posted.

Issues however started to appear once I tried mixing the spaces with the docs. Oddly, they didn't play super well together, where there was no great way to link a new doc as an entry into a specific space the same way you can with Notion and Confluence. You can paste the docs content into a space entry, or link a doc to an entry as an attachment that links to the doc, but I found no way to automate this process. This meant every single new doc I wanted to make also required me to make a new entry in the space I was recording the status on, and manually modify the metadata in the space each time the doc was updated.

I was close to being satisfied with ClickUp as my "Goldilocks" solution for my issues, but it just barely missed the mark for being something worth migrating to. It feels like they were trying so hard to replace a large number of competitors that they missed some of the nuances that made their competitors stand out. I am optimistic that as they grow, some of these missing features are implemented into the platform.

Final thoughts

After my time trialing with all of these platforms (and unsubscribing from all of their mailing lists...), it helped me sort out what exactly was best for me in a content collaboration app, and where my biases landed. Clearly these solutions have their own strengths and weaknesses, and all have a very solid number of customers that use them daily.

If I had to choose my favorite today (October 2021), Notion was my overall winner, where if I was starting completely from scratch, Notion filled the majority of my needs and had a good user experience that I was excited to work in. It was easy to organize, edit, collaborate, and more in a way that facilitated as many automated processes as possible.

However, I am not starting from scratch, and there are tradeoffs to migrating interfaces. So for that reason, we have decided to stick with Confluence, as all of our content is already there, we already pay for it, and it doesn't require our team members to sign up for a new account anywhere. A bit anti-climactic, but none of the solutions we found offered enough more than Confluence to be worth the resource investment to migrate.

As a reminder, these solutions were only tested on how well they played with Wordpress. While Wordpress is still extremely popular, there are so many other growing and popular CMS solutions out there like Sanity, Strapi, and Contentful that might play better with some of these applications than others. Especially given Wordpress' tendency to be a bit dated on how it plays with more modern content solutions.

I suggest taking advantage of the free trials these platforms provide, though I hope this rundown provided some good context of what pros and cons each have to see if there is a good fit for your team. Remember that what my teams needs are might not be reflected in yours, and these products are all actively being worked on. Missing features can be added, and beloved features can be sunset. I'd love to hear what solutions you are using in the comments and see if there are any promising contenders I may have missed!