Gossip organises a presentation as an outline, not a pile of slides

Authoring as four stages: generating, organizing, composing, revising

Gossip is an online user interface to author and deliver presentations, and the design follows a stated model of how text gets written. Past research on models of authoring text identified four common components: generating, organizing, composing and revising. Gossip is designed around those four, and the panels map onto them one for one.

The generating stage collects ideas, and the Idea panel is where that happens. The README is direct about the gap it fills: traditional presentation software gives the presenter nowhere to collect and record ideas, so they use other software for that. In Gossip, ideas can be text, images or code.

The organizing stage makes decisions about abstraction and ordering that produce hierarchical and linear structures. The Outline panel is where the hierarchy lives, and the Thumbnail panel previews the whole deck. Most tools let you order slides linearly, which hides the relations between them. Some, such as Keynote and Prezi, allow hierarchical ordering, and the README's judgement is that they are still not good enough. In the Outline panel, creating a new point node automatically creates a slide for it, and dragging one node changes the linear order and the hierarchy rather than requiring you to drag many nodes for a small edit.

The composing stage turns that structure into slides, and the Element panel handles it. Revising is covered by the Style and Variable panels, where a variable holds a shared value such as a font colour or a title size and changing it updates every element assigned to it.

Flexbox containers replace dragging and aligning

The composing stage is where most slide tools waste your time, and Gossip's answer is specific. Without constraints between elements, you lay out every text box and image manually, which the README calls time-consuming and annoying.

Gossip adds constraints. The Element panel lets you organize elements in a hierarchical structure, and changes there are reflected in the Main panel. The mechanism is CSS Flexible Box Layout: Gossip provides a container element that manages other elements, including text, images and nested containers, and you can add elements to a container and specify their arrangement, horizontal or vertical, and their proportion, such as 1:1 or 1:3.

Two things follow from using Flexbox. Position and size are computed for you: for each element, Gossip sets the proper position or size according to its container's styles, including padding and direction, and the other elements in that container. And you can operate on a group of elements rather than one at a time, which is what makes a constraint change worth making.

The trade is real. Flexbox gives you flow, alignment and proportional sizing, and it does not give you free absolute placement. A deck built on this model will look different from one built by dragging, and the difference is a constraint rather than a bug. Whether that suits a technical talk with diagrams, or hurts a deck with a deliberately off-grid layout, is the question to answer before you commit to it.

The delivery side: showing structure, not just slides

The second half of the argument for Gossip is about the audience rather than the author. The README's complaint is that existing tools struggle to give the audience context while a talk is being delivered, such as how individual slides relate to one another or how they fit into the larger structure, and that they are often inadequate at communicating structure to the audience.

That is why the tool has a delivery view with a word cloud, shown in the screening mode screenshot, rather than only an editing view. The idea is that the audience can see the shape of the argument, not just the slide currently in front of them. The project name comes from the same instinct. The README tells the story of the claim in Sapiens that the ability to tell and share stories makes humans far stronger than animals, because stories let us trust strangers, which led to large scale cooperation, and that presentation is an excellent way of telling and sharing stories.

The tool is hosted online. The README points to a mirror for users in China and a second one elsewhere, and asks for Chrome, Firefox or Safari for a better experience. There is no desktop application and no offline mode described anywhere in what is written down, so authoring happens in the browser, and the example decks live in the repository as JSON files under `examples/`, including an English and a Chinese intro and a file called `snake.json`.

A stack pinned to React 16, umi 2 and antd 3

The dependency list is the most informative thing in the repository, and it is old. The manifest names the package gossip, marks it private, pins the package manager at pnpm 9.10.0, and sets the Node engine to 16 or newer.

The runtime dependencies are React at 16.14.0, antd at 3.26.20, dva at 2.4.1, react-use, d3-array and d3-scale, file-saver and react-color. The dev dependencies are umi at 2.13.18 with umi-plugin-react, and gh-pages. The build tool is umi, and the configuration file at the root is `.umirc.js`.

The scripts are short enough to read in one go:

  "scripts": {
    "start": "NODE_OPTIONS=--openssl-legacy-provider umi dev",
    "build": "NODE_OPTIONS=--openssl-legacy-provider umi build",
    "deploy": "pnpm run build && gh-pages -d dist && gh-pages -d dist -b master -o gitee"
  }

Two details there are worth noting. Both the dev server and the build set `NODE_OPTIONS=--openssl-legacy-provider`, which is the usual workaround for the OpenSSL 3 change that broke webpack 4 hashing, and umi 2 is built on webpack 4. And the deploy script publishes to GitHub Pages, then publishes the same `dist` directory to Gitee with the master branch, which is the mirror arrangement the README describes for users in China.

The practical implication is that this codebase will not build on a current Node release without friction, and the React 16 and antd 3 era means the component APIs you would find in current documentation do not apply. Nothing here is broken, but it is a codebase from a specific period, and anyone extending it inherits that.

What is missing: an English tutorial, and a documented data format

The documentation gap is the honest weakness of this project. There is a tutorial in Chinese, at `docs/tutorials.zh-CN.md`, described as covering all the techniques you need to know to create and deliver presentations with Gossip. The English version is announced as coming soon. There is a separate `README.zh-CN.md` at the root, and the top-level `docs/` directory holds the tutorials.

That means an English-speaking user has the README, which explains the concepts and the philosophy well, and the screenshots, but not the walkthrough. The README says that an introduction to the workflow of Gossip comes later in the text.

The second gap is the file format. The examples directory contains `intro.en.json`, `intro.zh.json` and `snake.json`, so a deck is a JSON document. But the repository does not document that schema: how a slide's content, its position in the outline and its element tree are represented, whether the format is stable, and whether a deck written by hand would load correctly. If you plan to generate decks programmatically, or to migrate between Gossip and another tool, you will be reverse-engineering the JSON.

There is also no test suite, no CI configuration and no issue tracker policy described in the repository. The repository is not archived, but the last push was on 2026-06-04 and there are no GitHub releases, so the commit history is your only version record. The project is MIT licensed, which removes the main obstacle to forking and adapting it.

The alternative: author in a document, present in a deck tool

The most common way to produce a structured talk is not a presentation tool at all. You write an outline in a document, usually a hierarchical list, and you present from slides generated from that outline, or you present from the outline directly in a tool that renders markdown as you scroll. The difference in approach is that the outline becomes the source of truth rather than the deck.

Gossip moves a step further than that in one specific way, and it is the reason to care. Its outline is not a separate artefact that generates slides; it is the same structure the slides are built from, and the element tree of each slide is itself hierarchical and driven by Flexbox constraints. A change to the outline or to a variable propagates. In the outline-plus-slides approach, a change to the outline usually means regenerating slides, and a change to a shared visual property means editing every slide that uses it unless the tool has a theme model.

The counter-argument is real too. A document-first approach has almost no lock-in: your outline is text you own, readable in any tool, and the slides are disposable. Gossip's coupling is tighter, and the cost of leaving is the JSON format, which is undocumented.

There is a third path worth naming. impress.js, which Gossip cites as its inspiration, is also browser based and has the same spatial freedom, but the README's objection to it is that you must code. Gossip's bet is that the same freedom without coding is worth having, and the panels are the argument for that bet.

Editorial conclusion

Adopt Gossip if you author decks repeatedly and your main problem is structure rather than pixel design, since the outline, element and variable panels are what make a change propagate instead of being repeated. Do not adopt it if you need an English tutorial, offline editing, or a stack you can build on current Node, because the only tutorial is in Chinese, the tool runs in the browser, and the manifest pins React 16, umi 2 and antd 3 with Node 16 as the floor. Before you commit, read `docs/tutorials.zh-CN.md` yourself, run the dev server and check the layout in Chrome, Firefox or Safari, and confirm that the examples in `examples/` open and edit as you expect.

Frequently asked questions

Official sources

1. gossip-ink/gossip on GitHub
2. Issues
3. License: MIT
4. Project website
5. README