Show, Don't Tell: Guidelines for Information Visualization Presentation

Core Principles

1. Structured information must be visualized

2. Choose the right format, don't overuse

3. Present the structure first, then add explanations

Six Scenario Comparison Table

Comparison Demonstrations

Demo 1: Comparison Scenario — Text accumulation vs Table

Redis supports multiple data structures including strings, lists, hashes, sets, and sorted sets, while Memcached only supports simple key-value pairs. Redis supports data persistence and can save data to disk, while Memcached does not support persistence and data is lost after restart. Redis uses a single-threaded model, while Memcached uses a multi-threaded model. Redis supports advanced features like publish-subscribe, Lua scripts, and transactions, while Memcached has relatively simple functions. In terms of memory management, Redis uses its own memory allocator, while Memcached uses slab allocation.

Demo 2: Step Scenario — Mixed in paragraphs vs Numbered list

First you need to update the system's package list using the apt update command. Then install Nginx with apt install nginx. After installation, start the Nginx service with systemctl start nginx. You can also set it to start on boot with systemctl enable nginx. Finally, verify success by accessing the server IP in a browser.

1. Update package list
   bash

   sudo apt update

2. Install Nginx
   bash

   sudo apt install nginx

3. Start and enable auto-start on boot
   bash

   sudo systemctl start nginx
   sudo systemctl enable nginx

4. Verification: Visit

   http://<Server IP>

   in a browser, success if you see the Nginx welcome page

Demo 3: Architecture Scenario — Paragraph description vs Tree structure

The src directory has four subdirectories: components, pages, utils, and styles. Components stores public components, pages stores page components, utils stores utility functions, and styles stores global styles. The project root directory also has a public directory for static resources, as well as configuration files.

project/
├── src/
│   ├── components/    # Public components
│   ├── pages/         # Page components
│   ├── utils/         # Utility functions
│   └── styles/        # Global styles
├── public/            # Static resources
├── package.json
└── tsconfig.json

Demo 4: Process/Architecture Scenario — Pure text pseudo-diagram vs Mermaid

User input
→ Entry Layer (CLI / Telegram / Slack)
→ AIAgent
  → Assemble prompt
  → Initiate model call
  → If tool call is returned
    → Execute tool
    → Continue next round
  → Generate final response
→ Write to database
→ Return to user

flowchart TD
    A[User Input] --> B[Entry Layer<br/>CLI / Telegram / Slack]
    B --> C[AIAgent]
    C --> D[Assemble Prompt]
    D --> E[Initiate Model Call]
    E --> F{Tool Call Returned?}
    F -- Yes --> G[Execute Tool]
    G --> E
    F -- No --> H[Generate Final Response]
    H --> I[Write to Database]
    I --> J[Return to User]

Demo 5: Pros and Cons Comparison — Continuous paragraphs vs Side-by-side comparison

async/await looks more like synchronous code and is more readable. .then chains can easily become callback hell when nested multiple times. For error handling, async/await uses try/catch, while .then uses .catch.

// ❌ .then chain — deep nesting, hard to read
fetch('/api/user')
  .then(res => res.json())
  .then(user => fetch(`/api/posts/${user.id}`))
  .then(res => res.json())
  .then(posts => console.log(posts))
  .catch(err => console.error(err));

// ✅ async/await — flat structure, easy to read
try {
  const res = await fetch('/api/user');
  const user = await res.json();
  const postsRes = await fetch(`/api/posts/${user.id}`);
  const posts = await postsRes.json();
  console.log(posts);
} catch (err) {
  console.error(err);
}

Pre-output Self-check

1. Comparison Check: Is the response comparing two or more things? Yes → Use a table.
2. Enumeration Check: Is the response listing multiple attributes/parameters/features? Yes → Use a table or list.
3. Step Check: Is the response describing step-by-step operations? Yes → Use numbered lists + code blocks.
4. Code Check: Does the response mention specific commands/code/configurations? Yes → Use code blocks, don't describe inline.
5. Structure Check: Is the response describing hierarchies/directories? Yes → Use tree structures.
6. Process/Architecture Check: Is the response describing processes, architectures, call chains, state transitions? Yes → Use Mermaid code blocks, don't use pure text arrow indentation.

Boundary Notes

• Pure opinions/explanations: Discursive answers like "Why is React better than jQuery" are better presented in natural paragraphs
• Very short answers: No need for tables if it can be explained in 1-2 sentences
• User explicitly requests format: Such as "Answer in pure text"
• Dialogue/chat scenarios: Non-technical daily conversations