We’re still going at it! Replayable v0.4 includes some huge updates focusing on privacy, security, and performance. Check it out, and while you’re at it, take a look at our fancy new documentation site!

As usual, we’ve gathered all of this feedback from your conversations! If you want to help influence the future of Replayable, reach out to us and let us know what you’d like to see.

Pause Recording

Want to pause recording while you do something sensitive? The much requested pause button is here!

It tooks us a long time to come up with this (surprising, I know), but we wanted to emphasize that Replayable is a desktop buffer and not just your average screen recorder. If we added a “start” and “stop” button, it would have completely changed the product.

Instead, we opted for a toggle which, while functionally similar, clearly shows that you’re disabling something meant to be enabled. And to that effect, the toggle will reset itself to enabled at every app launch.

Oh! And there’s a handy pause/unpause keyboard shortcut.

Delete the local buffer

Looking for quick way to erase any history Replayable might have? Inspired by the “Clear Browing History” shortcut in Chrome, Replayable now inlcudes a “Delete buffer” button that will obliterate all recorded video.

Just hit this shortcut and Replayable will delete everything and start fresh.

New Onboarding Page

We’ve found that a lot of our users love to send Replayable to their team. Now, it’s easier than ever to get everyone onboard. Our new beauty of an onboarding page quickly explains how everyone can get started with Replayable.

Upgrades

Along with creating new features, we’ve spent some time improving the performance, reliability, and design of the app:

• Upgraded to Electron version 21
• Prevented Windows smart screen from showing
• New and updated projects are reflected in edit window
• Improved the replay feed interactions and made the time larger
• Added support for plugging and unplugging in “record all displays”
• Moved authentication to web rather than in-app

Bugs

And, of course, there’s a bundle of bugfixes:

• Fixed a bug where “choose a display” would show upon returning from navigation or disconnecting a display
• Fixed a bug where app would get stuck in unresponsive state
• Fixed a bug where unlocking the mac would fail to create a clip
• Fixed a bug where first app would fail to create a recording on first launch
• Fixed a bug where replay video was sometimes corrupt.
• Fixed a bug where buffer would not be deleted
• Fixed a bug where long recent videos were incorrectly deleted
• Fixed a bug where recording would be corrupt upon saving
• Fixed a race condition when cropping
• Fixed a bug where app may orphan child processes
• Set the default replay buffer duration to one day

Get the Latest Updates

What are you waiting for? Download the latest version of Replayable below. If you’ve already got v0.3.13 or higher, your app will auto-update itself.

How often have you encountered a bug while testing an app you’re building? How often are those bugs completely unrelated? Do you stop what you’re doing and go after them? Or just let them slide and move on?

If you stop what you’re doing to capture it, you need to remember what happened. You then need to launch a screen recorder and hope that you can reproduce the issue. If the reproduction takes multiple steps, you might waste time trying to get the application in a state for it to happen again. It’s extremely frustrating.

You might choose to save troubleshooting for later so that you don’t kill your developer flow. Who wants to stop what they’re doing to write steps to reproduce something unrelated? You know that you need to fix the bug, but it interrupts your current focus and workflow.

As a part of the “shift left” movement, developers now play a larger role in QA and testing. QA is no longer the responsibility of another team. It’s a combination of automation and development. Developers are responsible for finding and documenting bugs, and that competes with their ability (and love) for coding.

Once a bug is found, the developer needs to support it. It needs to be documented, then you need to tell the product team about it, and maybe there’s a meeting (or three). It’s a huge PITA. With the rise of remote work, developers can’t just grab their coworkers and say “hey, take a look at this.” Instead, they say that “it works on my machine.”

Wouldn’t it be great if you could just capture the bug when it happened in the first place? No more meetings, video capture, descriptions, reproducing steps, follow-ups, 🤮.

That’s why we’re building Replayable. Replayable is a dashcam for developers that helps you upgrade your bug reports with clips from local development. Rather than taking the time to reproduce and explain, you can simply grab footage of bugs when they happen. It’s like a black box on an airplane. Anyone who reads the bug report won’t need to follow ambiguous instructions, ask follow-up questions, or the dreaded “what version are you on.” It’ll be in the clip.

Replayable helps you show your team what you’re talking about instead of constantly trying to explain and describe the situation. It gives your team all your information – your perspective when shit hits the fan. You get to stay focused and feel peace of mind as you know that when anything goes wrong, you’ve got footage of it – just like a dash cam.

It works just like a dashcam too. Replayable records your screen LOCALLY in the background while you work (and yes, it’s performant). Whenever you encounter a bug, just hit the hotkey or press the “create clip” button and you’ll get a video of whatever happened in the last 30 minutes.

You have a chance to trim, crop, and censor the replay before publishing. Once you publish, you’ll be presented with a quick sharing link for markdown, Jira, etc. In fact, you can even do this all in one line with the CLI. But more on that later.

Not quick enough? The Replayable buffer records up to 3 days of footage, so you can upload Friday’s bug during the Tuesday standup. Replayable keeps its replay buffer on disk so your RAM doesn’t fill up, and it records at a low FPS, so things take up less space.

So how does it work? Imagine I’m playing 2048, and a bug pops up. Oh no! I hit the “Create Clip” button and capture it. I trim only to show me encountering the error (and the time leading up to it), then I crop and upload. I can then use the sharing dropdown to embed the replay within GitHub, Jira, or wherever your bugs go. I can go into the console.log and attach the logs to the replay as well.

In fact, you can even do most of this automatically by triggering a capture when the browser hits an error, but more on that later. For more, check out our CLI, Jira integration, and docs. Follow us on Twitter and join our beta!

The guide below will demonstrate how you can make a readme easier to follow by embedding Replayable replays. For the full demo, take a look at the before and after.

While your readme might make sense to you, chances are you’ve probably left out some important information that other developers would appreciate. Just think about all the readmes you’ve followed. Have you ever had one where you wish the author provided better information such as:

• Shows commands, but not their output
• Only a documentation reference, but no examples of usage
• Broken or missing demos
• Need to clone and install just to run the demos
• Detailed contribution guidelines, but nothing about usage

These problems negatively impact the DX (developer experience) for devs who want to get started with your product. Every time developers get confused, encounter a bug, or have a question, it costs them time, and they’re more likely to give up using your tool.

Unsurprisingly, it’s hard to empathize with newbies who haven’t used your repository before. You already know how everything works, and it’s hard to guess what a newbie would need to know.

That’s why we made Replayable. Replayable helps developers upgrade their readmes, bug reports, and pull requests with video so other developers can understand the context behind their contributions.

Rather than jotting instructions down in text format, Replayable simply captures your screen as you work so you can easily attach video clips that contain an exact record of what actually happened.

Replayable captures all of the context, the running demos, the CLI output, usage, and how you – the creator – use the product. A demo is worth a thousand words, and Replayable transforms your everyday work into demos you can share with your audience.

Replayable vs Video Tutorials

Why video? While your code, examples, and prose may be enough to give developers an overview, videos capture your entire point of view. Rather than trying to explain your process manually (lossy), videos tell a complete story to your reader. In fact, 60% of developers report using videos to learn how to code.

Now if you’re not in that 60% you may be thinking, “I hate learning from videos!” Traditional videos for developers are long, boring, and unsearchable. Replayable allows you to create short clips to embed in readmes rather than long unbearable videos.

The unique thing about Replayable is that it makes adding video as easy as setting up your own project!

Rather than stopping what you’re doing, turning on your webcam, microphone, and trying to nail the perfect demo, Replayable keeps you in the flow by making it easy to add short clips along the way. Just hit the hotkey, trim, crop, and embed.

Not only that, but tutorials created with Replayable are easier to maintain. When they go out of date, all you need to do is update a single part rather than re-render the entire video clip.

Walkthrough

Get Replayable

Let’s get started! To start, you’ll need the Replayable desktop client.

Replayable runs in the background so you don’t need to start or stop recording while you work.

Instead, you’ll simply hit Create Clip or use the hotkey to capture whatever just happened on your screen. Replayable keeps a rolling buffer locally on your computer, which you’ll be able to review and edit before uploading.

Make a new Replayable project

Replayable projects are like folders. Every time you change repositories or local projects, you’ll probably want to make a new Replayable project as well.

Use the existing guide as a baseline

Now, it’s time to make a tutorial. Your tutorial will probably mix existing setup guides and some with your own spin. After all, a lot of development is implied. It’s our job to document every nook and cranny that a newbie might not infer.

This tutorial will work on improving the getting started guide for reveal.js, a JS framework for making presentations. We’re going to follow their install guide as a base:

## Full Setup <span class="text-gray-500 font-normal">- Recommended</span>{id="full-setup"}

Some reveal.js features, like external Markdown, require that presentations run from a local web server. The following instructions will set up such a server as well as all of the development tasks needed to make edits to the reveal.js source code.

1. Install [Node.js](https://nodejs.org/) (10.0.0 or later)
1. Clone the reveal.js repository   
    ```shell   
    $ git clone https://github.com/hakimel/reveal.js.git   
    ```
1. Move to the reveal.js folder and install dependencies   
    ```shell   
    $ cd reveal.js && npm install
    ```

1. Serve the presentation and monitor source files for changes   
    ```shell   
    $ npm start
    ```
1. Open <http://localhost:8000> to view your presentation

Upgrade the tutorial with replays

Using the existing readme as a guide, follow the steps yourself in a clean environment . The first step is to install Node.js. As this is not unique to this repository and is likely well documented, it can be skipped.

Looking at the readme, the first step is to clone the repo. So do that on your machine. When you’re done, hit the Replayable hotkey to create a replay.

You can then crop the terminal and relevant browser page, then click the upload button. This will publish the replay to http://replayable.io and make it ready for sharing!

Readmes on GitHub are created using the markdown format. To embed your replay within your readme, select Share and Markdown from the replay page. This will copy the markdown embed code to my clipboard. The markdown code includes a looping gif and a link to the replay.

You may also choose to turn the list into paragraphs to fit the embedded replays better. After every heading, paste the markdown code right after. Check out the final setup step below and the full result here.

# Getting Started with Reveal.js

Some reveal.js features, like external Markdown, require that presentations run from a local web server. The following instructions will set up such a server as well as all of the development tasks needed to make edits to the reveal.js source code.

## Download and Install

[![Downloading and Installing Reveal.js](https://replayable-api-production.herokuapp.com/replay/630402cadf25a7006524c669/gif?shareKey=AfkCnX717yYvNbX3juCDUQ)](https://replayable.io/replay/630402cadf25a7006524c669/?share=AfkCnX717yYvNbX3juCDUQ)

Make sure you have [Node.js](https://nodejs.org/) (10.0.0 or later) installed. Then, clone the reveal.js repository:

```shell
git clone https://github.com/hakimel/reveal.js.git
```

Next, move to the reveal.js folder and install dependencies:

```shell
cd reveal.js
npm install
```

Then, do it again for the demo step!

Launch the app, view the presentation, and make changes. In the replay below, I wanted to understand how to modify my slides, so I launched VS Code and edited the first slide.

This is the kind of instruction where a video can be extremely helpful. While the text may make sense to you, a newbie might make errors when running npm start. They might not understand the relationship between the browser and the terminal in regards to “localhost,” and they probably don’t know what “monitor source files for changes” means.

Not to mention, they probably can’t infer what will pop up once the demo runs. In fact, you probably don’t even know yet! So as you get the demo running for yourself, creating clips helps explain to others what the resulting output of these instructions is and provides context for how you got there.

## Run the Demo

[![Setting up and running the Reveal.js Demo](https://replayable-api-production.herokuapp.com/replay/63040495973b2c0062e9239f/gif?shareKey=tbbKqBecjPCoLBmb0QfCXw)](https://replayable.io/replay/63040495973b2c0062e9239f/?share=tbbKqBecjPCoLBmb0QfCXw)

Serve the presentation and monitor source files for changes:

```shell
npm start
```

Then, open http://localhost:8000 to view your presentation!

Any changes you make to the source files will automatically be reflected in the presentation.

Publish the Tutorial

That’s it! You’re ready to publish. If you’re contributing to a repository, now you can open pull requests. Replayable embeds are supported everywhere, GitHub, Jira, WordPress, Dev.to, and more!

If you want to try Replayable out for yourself, join our beta and come hang out with us in Discord!

Even before I moved to Austin, I met the folks from ATX Hackerspace (now Asmbly) at SXSW. When I made the move down here for good, I joined their community and co-working space. 

One day, I noticed Natalie wearing a t-shirt from a startup where my roommate worked, Synesthesia. I asked her if she knew my roommate, and since the company was only five people at the time, she did.

Recognizing each other’s talents, we quickly became friends. Years later, Natalie ended up moving into our hacker house in Hyde Park (Think project room, pool, jam room, and pounds of steel in the backyard.).

We both spent time in different startup ventures; Natalie moved on to work at Senseye and I left my job at PubNub to start Haxor. At Haxor, I was conducting UX research on developers to better understand why every developer complained about docs and what we could do about it.

I noticed a similar theme in the problems that came to light. Developers struggled with communicating their issues when they needed help. There’s too much information required to provide context, and developers have too little time–and patience. 

I started to prototype screen recording tools that developers could use to provide feedback to the teams responsible for managing APIs and SDKs. Eventually, I found that the most valuable thing we could do for those teams was to provide them with a short “instant replay” every time they had bugs or wanted to submit feedback. The teams didn’t have time to watch hour(s)-long screen recordings, but instant replay provided just enough context about what the developers were doing.

After testing this software with more than 250 developers, and getting positive feedback from pretty much everyone, I knew there had to be a better application than UX testing. That’s when I asked Nat to come aboard.

And since we had already lived together and worked on a dozen projects together, we knew we’d make a great team. Nat had also been there through the first years of Haxor, and she’d frequently been the only person I’d talk to IRL the entire day. Natalie was a free agent, though now in Portland, and was looking for the next thing.

When I made the pitch to Natalie, she immediately understood the problem. “Both of us believe in the core tenant of documentation as the lynchpin of development,” is something I grabbed from an early call.

With everyone going remote, there was much higher interest in documentation and remote communication. 

“We’re being forced to move into this async remote mindset as a culture. And that is the mindset in which this product is the most useful” she said.

Together we want to bring the benefits of Replayable to every developers’ desktop as part of their everyday workflow regardless of where–and when–they work. Developers hate repeating themselves, and they hate breaking their flow. Replayable lets developers open bugs, close pulls, and create documentation faster by capturing video of their workday. We think that Replayable can help developers become more productive, learn, and empathize with one another.

After three years of working to understand developers with the help of fantastic clients like AWS, Mailchimp, and SAP as part of Haxor, we found a clear pattern pointing to the root of poor developer experience.

Developers don’t have time to share knowledge.

There’s too much information required to provide context, and developers have too little time–and patience. Understandably, they don’t want to break their flow to explain things.

In fact, sharing knowledge was rated as the #1 challenge for software developers¹. In second, was “capacity,” meaning developers just don’t have enough time to write docs.

In open source, 93% of developers list lack of good documentation as the #1 problem, yet 60% of developers report rarely or never contribute to improving it². Developers agree that their resources are not strong enough, yet they are not contributing to fixing the problem.

So what did we do about it?

We solved the problem! While conducting developer tests, we found that developers were more likely to submit feedback and bug reports when they could attach a screen recording.

This worked out well for everyone. The developers could write less, code more, and our clients, API companies who wanted feedback, could review the screen recordings to learn everything they needed to know.

After testing this software with more than 250 developers, we isolated the one power feature that everybody loved. Developer instant replay.

Introducing Replayable!

Our new tool, Replayable, has officially been launched in private beta! It records passively in the background as developers work and catches crashes, one-time errors, and things that can’t–and now don’t need to be–repeated when asking for assistance.

Developers no longer need to type “Steps to Reproduce.” All they have to do is send a replay! We think Replayable has the potential to increase developer productivity on a global scale.

It can save you and your team tons of time, and it’s not just for research studies with big companies. We want to bring Replayable to every developers’ desktop as part of their everyday workflow. They spend an incredible amount of time explaining their work. Think of all the writing, meetings, miscommunication, and headaches saved with this tool.

If you’re as excited about this as we are, join our beta! Right now, we’re looking for front-end developers who are building products with a team to try out our app

We know gifs are all the rage. What’s better than a static image, gif! We’re happy to announce the ability to generate gifs.

Improvements & bug fixes

• Fixed an issue that showed videos in the desktop feed that were older than 3 days.
• New Zendesk help center
• Fixed an issue in the edit window preview that was causing a black window