Gemini 3 critiques Leo's Preface (and home page)

[Edward K. Ream]

Here is my prompt to gemini3:

> Please suggest improvements to Leo's "preface" at https://leo-editor.github.io/leo-editor/preface.html

Everything that follows is the response. Looks like I flunked marketing 101:

Based on an analysis of the text at the provided URL, the "preface" (titled "A Brief Summary of Leo") exhibits several rhetorical weaknesses that undermine its effectiveness for a technical audience.

The current text relies on subjective claims, dated comparisons, and insider jargon ("Leonine way"). A skeptical reader will likely view the broad listing of features (IDE, PIM, Outliner) as a sign of a tool lacking a defined scope, rather than a versatile one.

The following improvements address these issues, focusing on precision and verifiable value propositions.

1. Remove the Dated Comparison

Current: “Word outlines are very useful. But Leo makes Word look like a clunky toy.”—Joe Orr

Critique: Comparing a developer tool to Microsoft Word is a category error. It lowers the ceiling of expectations. Most developers do not use Word for code or serious data organization; they use VS Code, Vim, Emacs, or Obsidian. Acknowledging Word implies the tool is aimed at non-technical office users, which contradicts the later claim that it is a "fully-featured IDE."

Recommendation: Remove the quote entirely. Start with a direct definition of the tool's primary differentiator: the integration of outlining with codebase logic.

2. Clarify the "Directed Acyclic Graph" (DAG) Claim

Current: “Leo's underlying data is a Directed Acyclic Graphs. As a result, Leo organizes data in completely new ways.”

Critique: Stating the data structure is a DAG is a factual statement about implementation, not a benefit. The statement "organizes data in completely new ways" is vague marketing fluff. The user needs to know why a DAG matters (i.e., zero-cost aliasing/cloning of nodes).

Recommendation: Replace the implementation detail with the functional consequence.

• Proposed Revision: "Unlike standard tree-based editors, Leo allows a single node to appear in multiple places simultaneously (clones). Editing a node in one location updates it everywhere, allowing for multidimensional organization of source code."

3. Define "The Leonine Way" or Remove It

Current: “Leo's clone find commands enable the Leonine way to refactor programs.”

Critique: This is circular terminology. A new user does not know what "Leonine" means. Using proper nouns to describe a methodology often signals an insular community rather than a standard tool.

Recommendation: Describe the methodology strictly in operational terms.

• Proposed Revision: "Leo enables refactoring by treating code structure as a manipulatable [sic] outline, allowing you to reorganize large codebases via drag-and-drop operations rather than text cutting and pasting."

4. Address the "Jack-of-All-Trades" Risk

Current: The list claims Leo is an IDE, an Outliner, a Data Manager, a Scripting Environment, and a study tool.

Critique: Tools that claim to do everything often trigger skepticism regarding their depth in any single area. A developer will question how a single tool can compete with IntelliJ (IDE) and Obsidian (PIM) simultaneously.

Recommendation: Hierarchy is needed. Define the tool primarily as one thing (likely a Literate Programming Editor or Scriptable Outliner) and list the others as secondary capabilities derived from that core.

5. Reframe the "Steep Learning Curve" Warning

Current: “You won't learn all about Leo in a day or two... Please ask for help immediately if you get stuck.”

Critique: While honest, this frames the complexity as a liability rather than an investment. "Ask for help immediately" suggests the UI is non-intuitive.

Recommendation: Focus on progressive disclosure.

• Proposed Revision: "While Leo's advanced scripting features offer depth that takes time to master, the basic outlining features provide immediate utility for navigating complex files."

6. Verify the "100% Pure Python" Claim

Assumption: The claim "Written in 100% pure Python" assumes the user values interpretability over performance.

Critique: For a modern IDE, "100% Python" may raise concerns about latency and UI responsiveness compared to Rust or C++ based editors (like Zed or VS Code).

Recommendation: If performance is a concern, qualify this claim by explaining why it is Python (e.g., "ensuring the entire editor is hackable [sic] and scriptable by the user at runtime").

Summary of Proposed Structural Changes

1. Headline: Change from "A Brief Summary" to "Technical Overview".

2. Lead: Delete the Word quote. State clearly that Leo is a scriptable outline editor for code and data.

3. Features: Group features by workflow (e.g., "For Coding," "For Scripting," "For Knowledge Management") rather than a flat list.

4. Technical differentiation: explicitly link "Clones" to the DAG structure to explain the mechanism of action.

Edward

P.S. Here is the initial link to this conversation.

EKR