{"path":"research/graph-visualization.md","content":"# Graph Visualization for Argumentation at Scale\n\n**Research date**: March 27, 2026\n**Context**: Deliberus collaborative deliberation platform — exploring how to visualize argument structures that may grow to thousands of interconnected claims, premises, and conclusions.\n\n---\n\n## Table of Contents\n\n1. [The Spaghetti Problem](#1-the-spaghetti-problem)\n2. [Visualization Libraries](#2-visualization-libraries)\n3. [Semantic Zoom](#3-semantic-zoom)\n4. [Focus+Context](#4-focuscontext)\n5. [Hierarchical Layouts](#5-hierarchical-layouts)\n6. [Filtering and Navigation](#6-filtering-and-navigation)\n7. [Real-Time Collaboration](#7-real-time-collaboration)\n8. [Mobile](#8-mobile)\n9. [What Kialo, DebateGraph, and Argdown Actually Do](#9-what-kialo-debategraph-and-argdown-actually-do)\n10. [3D / VR](#10-3d--vr)\n11. [Cross-Reference with Lins](#11-cross-reference-with-lins)\n\n---\n\n## 1. The Spaghetti Problem\n\n**Source**: Scheuer, Loll, Pinkwart & McLaren (2010) surveyed 50+ computational argument-mapping tools. The core finding: as argument structures grow beyond a few dozen nodes, visual representations degenerate into unnavigable \"hair-ball\" or \"spaghetti\" plots.\n\n### Why It Happens\n\n- **Dense connectivity**: Argument graphs are not sparse trees. A single claim can be attacked by multiple counterarguments, which themselves may share premises. Cross-cutting rebuttals create many non-hierarchical edges.\n- **Force-directed layouts fail**: The default visualization strategy (ForceAtlas2, spring-electric models) tries to minimize edge crossings but converges on a dense blob for graphs with high edge-to-node ratios.\n- **Opinion graph density**: Betz, Hamann et al. (2018) confirmed that opinion graphs are \"relatively dense\" — force-directed layouts yield \"mere hair-ball plots.\"\n\n### Known Solutions\n\n| Technique | How It Helps | Trade-off |\n|-----------|-------------|-----------|\n| **Hierarchical aggregation** | Cluster related arguments into \"metanodes,\" show summary at zoomed-out level | Requires meaningful clustering criteria (topic, stance, author) |\n| **Semantic zoom** (ZMLT algorithm) | Show different detail levels at different zoom scales | Complex to implement; needs stable mental-map preservation |\n| **Overview+detail** | Minimap showing full graph alongside focused detail view | Screen real estate; two views to maintain |\n| **Focus+context** (fisheye/hyperbolic) | Magnify area of interest, compress periphery | Distortion can confuse spatial memory |\n| **Progressive disclosure** | Start with thesis, expand branches on demand | Users may miss important counterarguments they haven't expanded |\n| **Filtering by attribute** | Show only nodes matching criteria (topic, score, controversy level) | Risk of confirmation bias if users filter out opposing views |\n| **Edge bundling** | Group parallel edges into bundled curves | Reduces clutter but obscures individual relationships |\n\n### LSAV Research (2016)\n\nThe Large-scale Argument Visualization (LSAV) project at Edinburgh Napier specifically addresses argument mining output visualization. Key insight: argument mining tools are producing datasets far larger than any hand-crafted argument map. The gap between what mining produces and what visualization tools can render is the central unsolved problem. Their approach combines hierarchical node clustering (turning the graph into a multi-scale structure), fisheye tree views, and composite lenses for integrated overview+detail.\n\n**Deliberus relevance**: This is exactly the problem Deliberus will face. If LLM-based claim extraction (Claimify) is used on large text corpora, the resulting argument graphs will be orders of magnitude larger than hand-crafted maps. The visualization must be designed for this scale from day one.\n\n### Sources\n\n- [Argument map - Wikipedia](https://en.wikipedia.org/wiki/Argument_map)\n- [Large-scale Argument Visualization (LSAV)](https://diglib.eg.org/handle/10.2312/eurp20161143)\n- [Betz et al. - Applying argumentation to structure and visualize multi-dimensional opinion spaces](https://content.iospress.com/articles/argument-and-computation/aac181004)\n- [Hierarchical Aggregation for Information Visualization](https://dl.acm.org/doi/10.1109/TVCG.2009.84)\n\n---\n\n## 2. Visualization Libraries\n\n### Comparison Matrix\n\n| Library | Renderer | Scale (nodes) | Layout | License | Ecosystem | Best For |\n|---------|----------|---------------|--------|---------|-----------|----------|\n| **Sigma.js** | WebGL | 100K+ | External (graphology) | MIT | graphology algorithms | High-performance graph rendering, custom UX |\n| **Cytoscape.js** | Canvas/WebGL | ~10K practical | 20+ built-in | MIT | Huge plugin ecosystem | Data analysis, biology/network science |\n| **D3.js** | SVG/Canvas | ~5K practical | Manual (force simulation) | ISC | The gold standard | Complete creative control, custom everything |\n| **vis.js (vis-network)** | Canvas | ~5K | Built-in physics | Apache 2.0/MIT | Simple API | Quick prototypes, timeline integration |\n| **G6 (AntV)** | Canvas/SVG/WebGL | Medium-large | 15+ built-in | MIT | AntV ecosystem | Enterprise dashboards, opinionated framework |\n| **React Flow** | SVG (DOM) | ~1K practical | Manual/yFiles plugin | MIT | React ecosystem | Node-based editors, workflow builders |\n| **yFiles** | SVG/Canvas/WebGL | 100K+ | 50+ algorithms | Commercial ($$$) | Enterprise | Enterprise graph apps, advanced layouts |\n| **Cosmos.gl** | WebGL (GPU) | 1M+ | GPU force-directed | CC-BY-NC | Minimal | Massive graphs (incompatible with MIT) |\n\n### Performance at 1000+ Nodes\n\n**Sigma.js** is the clear winner for raw rendering performance in the open-source space. It was designed from the ground up for WebGL and handles 100K+ nodes with stable frame rates. Layout computation is the bottleneck, not rendering.\n\n**Cytoscape.js** handles medium-large graphs well but its Canvas renderer shows frame drops above ~10K nodes. The ecosystem of algorithms (centrality, community detection, shortest path) is the most complete of any JS graph library.\n\n**D3.js** is not really a graph library — it is a visualization toolkit. You build everything yourself. For argument visualization, this means maximum control but maximum effort. The force simulation is single-threaded and struggles above 5K nodes without optimization (web workers, quadtree).\n\n**G6 v5** is moving toward WebGL but is primarily Canvas-based. Its strength is the 15+ built-in layout algorithms and opinionated component system. The trade-off is that custom UX is harder — you work within G6's abstractions rather than building on top of a thin renderer.\n\n**React Flow** is designed for node-based editors (think visual programming), not graph visualization at scale. It renders each node as a DOM element, which limits performance to ~1K nodes. yFiles now offers layout algorithms as a React Flow plugin, which is an interesting hybrid.\n\n**yFiles** is the Rolls-Royce — 50+ layout algorithms, edge routing, grouping, hierarchical structuring, swimlanes. Performance at scale. But it is commercial software (pricing on request, typically $$$$/year) and closed-source.\n\n### Recommendation for Deliberus\n\nSigma.js + graphology (Lins's current stack) is well-suited. The key question is whether Deliberus needs different layout algorithms than what graphology provides. For argument structures, hierarchical/tree layouts matter more than force-directed — and graphology's layout ecosystem is thinner on hierarchical layouts than Cytoscape.js or yFiles. Options:\n\n1. **Stay with Sigma.js + graphology**, implement custom hierarchical argument layout\n2. **Sigma.js for rendering + dagre/elkjs for layout** — use a dedicated DAG layout library\n3. **Cytoscape.js** if the algorithm ecosystem matters more than rendering scale\n\n### Sources\n\n- [Memgraph - Fast, Easy, Popular Graph Visualization: Pick Two](https://memgraph.com/blog/you-want-a-fast-easy-to-use-and-popular-graph-visualization-tool)\n- [Best Libraries for Large Force-Directed Graphs](https://weber-stephen.medium.com/the-best-libraries-and-methods-to-render-large-network-graphs-on-the-web-d122ece2f4dc)\n- [Cylynx - Comparison of JS Graph Libraries](https://www.cylynx.io/blog/a-comparison-of-javascript-graph-network-visualisation-libraries/)\n- [Top 8 JavaScript Diagramming Libraries 2026](https://www.jointjs.com/blog/javascript-diagramming-libraries)\n- [React Flow](https://reactflow.dev)\n- [yFiles React Graph Components](https://www.yfiles.com/the-yfiles-sdk/technologies/react)\n\n---\n\n## 3. Semantic Zoom\n\nSemantic zoom changes what information is displayed at different zoom levels — not just the size of elements, but their very nature. This is fundamentally different from geometric zoom (just scaling).\n\n### How It Works\n\nAt the highest (most zoomed-out) level, you see topic clusters or thesis-level summaries. As you zoom in, these decompose into individual arguments, then into premises, then into evidence and citations. The key constraint: **items introduced at a given level must persist at all deeper levels** (semantic consistency).\n\n### Key Algorithms\n\n**ZMLT (Zoomable Multi-Level Tree)**: Proposed by Borner et al. (2019), this algorithm guarantees six properties:\n1. Abstract and embedded trees represent the graph appropriately at different detail levels\n2. Real vertices and paths visible at every level\n3. Nodes and edges persist across deeper levels\n4. No label overlaps\n5. No edge crossings\n6. Drawing area proportional to label area\n\n**Three-layer approach** (Dudas et al., 2018): Separates information into three discrete levels of detail, applied to force-directed layouts. Uses \"smart expanding and ordering\" to preserve the mental map when transitioning between levels.\n\n### Application to Argument Structures\n\nSemantic zoom maps naturally onto argument structure:\n\n| Zoom Level | What You See | Example |\n|------------|-------------|---------|\n| **Galaxy** | Topic clusters, thesis nodes only | \"Climate policy,\" \"Immigration,\" \"AI safety\" |\n| **Constellation** | Key contentions with pro/con balance indicators | \"Carbon tax is effective\" (65% support, 12 arguments) |\n| **Star system** | Individual arguments with premise chains | Premise 1 + Premise 2 => Conclusion, with attack/support edges |\n| **Planet** | Full argument detail: evidence, citations, author, timestamp, quality scores | The specific study cited, methodology critique, replication status |\n\n### User Study Evidence\n\nResearch confirms that semantic zoom **measurably increases readability, visual clarity, and information clarity** of ontology graph visualizations. Users navigate more efficiently and report less cognitive overload compared to flat visualizations.\n\n### Deliberus Relevance\n\nSemantic zoom is likely the single most important technique for Deliberus. Argument structures are inherently hierarchical (thesis -> contention -> argument -> premise -> evidence), and different users need different levels of engagement. A policy analyst wants the galaxy view; a domain expert wants the planet view. The same graph serves both.\n\n### Sources\n\n- [Semantic Zoom - Emergent Mind](https://www.emergentmind.com/topics/semantic-zoom)\n- [Multi-level tree based approach for interactive graph visualization with semantic zoom (arXiv)](https://arxiv.org/abs/1906.05996)\n- [Semantic Zooming for Ontology Graph Visualizations (ACM)](https://dl.acm.org/doi/10.1145/3148011.3148015)\n- [map4sci - ZMLT implementation (GitHub)](https://github.com/cns-iu/map4sci)\n\n---\n\n## 4. Focus+Context\n\nThe focus+context paradigm shows detailed information about the user's area of interest while maintaining a compressed view of surrounding context. This prevents the \"lost in the graph\" problem.\n\n### UX Patterns\n\n**Hyperbolic browser**: The focused node is rendered large and central; surrounding nodes progressively shrink toward the periphery. Smooth animated transitions when focus shifts. Used by DebateGraph.\n\n**Fisheye distortion**: A continuous distortion function magnifies the focus area and compresses the periphery. Preserves topology but distorts spatial relationships. Works well for exploration but can confuse users who rely on spatial memory.\n\n**Neighborhood highlighting** (Lins's current approach): On hover/click, highlight the selected node and its direct connections; dim everything else. Simple, effective, preserves spatial layout. The implementation in Lins's `GraphCanvas.svelte` already does this via `nodeReducer`/`edgeReducer`.\n\n**Lens metaphor**: A movable \"lens\" over the graph that shows more detail within its circular area. Can be combined with semantic zoom — the lens shows one zoom level deeper than the background.\n\n### DebateGraph's Approach\n\nDebateGraph uses a radial focus+context layout where:\n- The focused argument is at the center\n- Supporting arguments radiate outward in one direction\n- Opposing arguments radiate in another\n- Related arguments in other debate trees are linked\n- Users navigate by clicking any node to re-center the view\n\nThis creates a \"debate map\" experience where you are always oriented relative to a focal argument, with the full context visible but compressed.\n\n### Design Guidance (Cambridge Intelligence)\n\nKey principles for focus+context in graph UX:\n- Use color, size, and contrast to differentiate focus from context\n- Animate transitions smoothly when focus shifts (users need to track where they came from)\n- Let users control what constitutes \"context\" (1-hop neighbors, 2-hop, same topic cluster)\n- Provide a minimap for global orientation\n\n### Deliberus Relevance\n\nFocus+context is essential for Deliberus. When a user is reading a specific argument, they need to see:\n- What this argument supports or attacks (upward context)\n- What premises support this argument (downward detail)\n- What counterarguments exist (lateral context)\n- Where this fits in the broader debate (global context)\n\nThis maps to a multi-ring layout: focal argument at center, premises one ring out, parent contention one ring in, counterarguments shown as a contrasting ring.\n\n### Sources\n\n- [UXtweak - Focus+Context](https://www.uxtweak.com/ux-glossary/focus-context/)\n- [Cambridge Intelligence - Graph visualization UX](https://cambridge-intelligence.com/graph-visualization-ux-how-to-avoid-wrecking-your-graph-visualization/)\n- [DebateGraph](https://debategraph.org/Stream.aspx?nid=65031&vt=bubble&dc=focus)\n\n---\n\n## 5. Hierarchical Layouts\n\n### Layout Types for Argument Structures\n\n**Top-down tree (Sugiyama/layered)**: Root thesis at top, arguments flow downward. Natural for reading order. Shows depth of reasoning clearly. **Best for**: Linear argument chains, simple pro/con structures.\n\n**Radial tree**: Thesis at center, arguments radiate outward in concentric rings. Efficient use of space when one node has many children. Kialo uses this as an alternative view (\"Sunburst Navigation\"). **Best for**: Wide argument structures where a thesis has many direct responses.\n\n**Force-directed**: Nodes repel, edges attract. Reveals clusters and community structure. **Best for**: Discovering implicit groupings, seeing which arguments are tightly interconnected. **Worst for**: Preserving argument hierarchy — parent-child relationships get lost in the physics.\n\n**Dagre / ELK (layered DAG)**: Directed acyclic graph layout with ranks. Arguments at the same logical level appear on the same horizontal band. Edges route cleanly. **Best for**: Complex argument structures that are not strict trees (shared premises, cross-cutting attacks).\n\n### The Fundamental Tension\n\nArgument structures are NOT clean trees. They are DAGs at best (shared premises), and often contain cycles (mutual attacks, dialectical loops). This means:\n\n- Pure tree layouts distort the actual structure (forcing shared premises to appear in multiple places or arbitrarily choosing one parent)\n- Force-directed layouts show the real topology but lose the logical hierarchy\n- DAG layouts (dagre, ELK) are the best compromise but can still produce visual clutter for dense attack networks\n\n### Recommendation for Deliberus\n\nA **hybrid approach**:\n1. **Primary view**: DAG layout (dagre or ELK) showing arguments in ranked layers, with the thesis at top. Color-code pro (green) vs con (red) vs neutral (gray) edges.\n2. **Exploration view**: Force-directed for discovering clusters and implicit groupings\n3. **Presentation view**: Radial/sunburst for showing the scope of a debate at a glance\n4. **Let users switch** between layouts — different layouts reveal different structural properties\n\n### Sources\n\n- [Cambridge Intelligence - Automatic Graph Layouts](https://cambridge-intelligence.com/automatic-graph-layouts/)\n- [Layered graph drawing - Wikipedia](https://en.wikipedia.org/wiki/Layered_graph_drawing)\n- [Radial tree - Wikipedia](https://en.wikipedia.org/wiki/Radial_tree)\n- [G6 Layout algorithms](https://cynkra.github.io/g6R/articles/layouts.html)\n\n---\n\n## 6. Filtering and Navigation\n\n### Navigating a 5000-Argument Graph\n\nAt scale, no single visualization can show everything meaningfully. Navigation becomes the primary UX challenge.\n\n**Search-first exploration** (Bloom pattern): The default view is empty or shows only top-level theses. Users search for topics, and the graph builds outward from search results. This is the pattern Lins already implements and it scales well.\n\n**Progressive disclosure**: Start with thesis nodes. Click to expand pro/con arguments. Click an argument to expand its premises. Each expansion adds nodes to the view. Users build their own focused subgraph.\n\n**Filtering dimensions for argumentation**:\n\n| Filter | What It Shows | Use Case |\n|--------|--------------|----------|\n| **By topic/tag** | Arguments related to a specific aspect | \"Show me only economic arguments\" |\n| **By controversy** | Arguments where pro/con are nearly balanced | Finding the crux of a disagreement |\n| **By quality score** | Only well-supported arguments | Serious analysis, ignoring weak claims |\n| **By recency** | Most recently added/modified | Following an evolving debate |\n| **By author/group** | Arguments from a specific perspective | Understanding a stakeholder's position |\n| **By logical role** | Only premises, or only rebuttals | Structural analysis |\n| **By depth** | Arguments within N hops of a thesis | Controlling complexity |\n\n**Breadcrumb trails**: When users navigate deep into an argument chain, show the path from the thesis: `Thesis > Contention A > Argument 3 > Premise 2`. Click any breadcrumb to zoom out to that level. This provides constant orientation.\n\n**Minimap**: A compressed view of the entire graph showing the user's current viewport as a highlighted rectangle. Kialo implements this as both tree navigation and sunburst navigation views.\n\n### Key Design Principles (Cambridge Intelligence)\n\n- Visualizing huge graphs in one screen is \"rarely useful or successful\"\n- Use **progressive rendering** — load incrementally, keep the interface responsive\n- **Level-of-detail rendering** changes visual complexity based on zoom level\n- Provide lens tools for focus without losing context\n- Search and navigation are more important than the initial visualization\n\n### Sources\n\n- [Cambridge Intelligence - Visualize Large Networks](https://cambridge-intelligence.com/visualize-large-networks/)\n- [Scalable Graph Exploration and Visualization (PoloCLub)](https://poloclub.github.io/papers/15-bigcomp-sensemaking.pdf)\n- [yFiles - Guide to Visualizing Knowledge Graphs](https://www.yfiles.com/resources/how-to/guide-to-visualizing-knowledge-graphs)\n\n---\n\n## 7. Real-Time Collaboration\n\n### CRDT Approaches for Graph Structures\n\nDeliberus is inherently collaborative — multiple users contribute arguments simultaneously. This requires real-time synchronization of graph data.\n\n**Yjs** is the leading open-source CRDT framework for collaborative applications. Synergy Codes has specifically built CRDT-based sync for diagramming and graph tools using Yjs. It handles concurrent edits without conflicts.\n\n**graph-crdt** (GitHub) implements a delta graph CvRDT using Lamport timestamps. Designed specifically for graph structures where nodes and edges can be concurrently added, modified, or (soft-)deleted.\n\n**Figma's approach** (relevant precedent): Uses CRDTs with a server-side canonical state. Each client applies operations locally (optimistic updates), then syncs with the server. Conflicts are resolved deterministically. This gives real-time feel with eventual consistency.\n\n### Challenges Specific to Argument Graphs\n\n| Challenge | Why It's Hard | Approach |\n|-----------|--------------|----------|\n| **Concurrent argument addition** | Two users add conflicting rebuttals to the same claim | Both rebuttals appear; community evaluates |\n| **Concurrent editing of same argument** | Two users edit the same premise text | Last-write-wins or merge (CRDT text types like Yjs Y.Text) |\n| **Structural conflicts** | User A deletes an argument; User B adds a child to it | \"Tombstone\" pattern — mark as deleted but preserve children |\n| **Vote/score conflicts** | Multiple users rate the same argument | CRDTs handle counters natively (G-Counter, PN-Counter) |\n| **Cycle creation** | User A argues X supports Y; User B argues Y supports X | Validation layer must detect and flag cycles |\n\n### Recommendation for Deliberus\n\n- Use **Yjs** for real-time collaborative text editing within argument nodes\n- Use a **server-authoritative model** for structural graph operations (add/remove/link arguments) — the server validates structural constraints (no cycles, valid logical relationships) before broadcasting\n- Show **presence indicators** (colored cursors, \"User X is viewing Argument Y\") for awareness\n- **Operational history** is valuable — who added what argument, when, as a response to what — this is intrinsic to the argumentation model\n\n### Sources\n\n- [Yjs (GitHub)](https://github.com/yjs/yjs)\n- [graph-crdt (GitHub)](https://github.com/PsychoLlama/graph-crdt)\n- [How Figma's multiplayer technology works](https://www.figma.com/blog/how-figmas-multiplayer-technology-works/)\n- [Synergy Codes - Yjs live collaboration](https://www.synergycodes.com/yjs)\n\n---\n\n## 8. Mobile\n\n### The Core Challenge\n\nArgument graphs on mobile face compounding problems:\n- Small screen area (375-430px wide)\n- Touch targets need to be larger (44x44pt minimum)\n- Complex graph structures don't simplify linearly with screen reduction\n- Pinch-zoom + pan is natural for maps but less natural for logical structures\n\n### Strategies\n\n**Responsive visualization design** (Horak et al., 2021) identifies 76 strategies for adapting visualizations to smaller screens. For graphs specifically:\n\n1. **Linearize the tree**: On mobile, convert the argument tree to a collapsible list/outline view. Each argument is a card that can be expanded to show premises and counterarguments. This is what Kialo does on mobile — it is essentially a nested comment thread, not a graph.\n\n2. **Card-based navigation**: Show one argument at a time as a full-screen card. Swipe to see counterarguments. Tap to drill into premises. Breadcrumbs at top for orientation. Think \"Tinder for arguments.\"\n\n3. **Simplified graph with semantic zoom**: Show only thesis + top-level contentions as a simple graph. Tap any node to focus and see its children. Two levels visible at most.\n\n4. **Dual-mode**: Graph on desktop, list on mobile. Same data, different representation optimized for the device.\n\n### What Works in Practice\n\nNo successful mobile implementation of argument graph visualization exists. Kialo on mobile degrades to a list view. DebateGraph is not optimized for mobile at all. This is an unsolved problem in the space.\n\nThe pragmatic approach: **design mobile-first as a list/card UX**, with the graph view as a desktop/tablet enhancement. The mobile experience focuses on reading and contributing arguments; the graph view focuses on analysis and navigation.\n\n### Sources\n\n- [Horak - Responsive Visualization Design for Mobile Devices](https://www.imld.de/cnt/uploads/Horak2021_MobileDataVisBook_Chap02_Responsive.pdf)\n- [Visual Cinnamon - Mobile vs Desktop DataViz](https://www.visualcinnamon.com/2019/04/mobile-vs-desktop-dataviz/)\n- [Responsive Visualization Design Patterns (arXiv)](https://arxiv.org/pdf/2104.07724)\n\n---\n\n## 9. What Kialo, DebateGraph, and Argdown Actually Do\n\n### Kialo\n\n**Model**: Discussion tree. Central thesis at root, pro and con claims branch outward. Each claim can have its own pro/con children. Voting on individual claims produces \"impact\" scores.\n\n**Visualization**:\n- **Default (Tree Navigation)**: Thesis at top, vertical layers descending. Shows path from current claim to thesis. Only claims in the direct ancestry and immediate children are fully visible — others are compressed.\n- **Sunburst Navigation**: Thesis in center, levels radiate outward as concentric rings. All claims visible but tiny at outer rings.\n- **Minimap**: Always-visible compressed view showing current position in the tree.\n- **Mobile**: Degrades to list view.\n\n**What works**: Clean, opinionated UX. Forced structure (pro/con binary) prevents spaghetti. Voting provides signal.\n**What doesn't**: Binary pro/con is reductive — many arguments are \"yes, but\" or \"it depends on context.\" No support for shared premises or cross-cutting relationships. Does not scale to truly large debates (thousands of claims) because the tree structure fragments into unmanageable depth.\n\n**Deliberus takeaway**: Kialo's tree navigation and sunburst are worth studying as navigation patterns. But the binary pro/con model is too simplistic for Deliberus's epistemological ambitions. Deliberus needs richer relationship types (supports, attacks, undermines, qualifies, provides evidence for, contradicts...).\n\n### DebateGraph\n\n**Model**: Graph of interconnected \"idea maps.\" Each map has a central thesis and radiating arguments. Maps can link to each other, creating a graph of graphs.\n\n**Visualization**: Radial focus+context. Selected node at center, connections radiate outward. Clicking any node re-centers the view. Color indicates relationship type.\n\n**What works**: Cross-linking between debate maps enables seeing connections across topics. Radial layout is spatially intuitive.\n**What doesn't**: The tool is visually dated (circa 2010 UX). Navigation feels disorienting — re-centering on every click destroys spatial memory. No semantic zoom. Limited adoption despite being referenced in academic literature.\n\n**Deliberus takeaway**: The concept of linked debate maps is powerful — Deliberus should support cross-debate connections. But the UX needs modernizing: smooth animated transitions, minimap for orientation, optional layout stability.\n\n### Argdown\n\n**Model**: Markdown-like markup language for argument structures. You write plain text with conventions for premises, conclusions, attacks, supports. The text compiles to argument maps.\n\n**Visualization**: Generated from markup. Produces static argument maps (SVG/PNG) and interactive web views. The graph is an output, not the primary interface.\n\n**What works**: Brilliant for individual analysts and writers. The \"stay in your text editor\" philosophy removes all visual distractions. Exports to multiple formats. Open source.\n**What doesn't**: Not collaborative (single-author text files). Not interactive for exploration. No real-time rendering. No semantic zoom or progressive disclosure.\n\n**Deliberus takeaway**: Argdown's text-first approach is valuable for power users and could be supported as an import/export format. The idea that argument structure can be expressed as text that compiles to graphs is fundamentally sound and may work well for LLM integration (have an LLM generate Argdown, which compiles to the graph representation).\n\n### Sources\n\n- [Kialo - Wikipedia](https://en.wikipedia.org/wiki/Kialo)\n- [Kialo Minimap](https://support.kialo-edu.com/en/hc/discussion-minimap/)\n- [Argdown](https://argdown.org/)\n- [Argdown on HN](https://news.ycombinator.com/item?id=41186310)\n- [Kialo Edu - Research](https://www.kialo-edu.com/research)\n\n---\n\n## 10. 3D / VR\n\n### Current State\n\n**Research findings**: User studies show 3D graph visualizations can outperform 2D for network comparison tasks and spatial grouping recognition. The extra dimension helps when graph structure is inherently 3D (clusters at different \"depths\").\n\n**Tools**:\n- **yEd Live** (yWorks) demonstrates 3D/VR graph exploration via browser\n- **Flow Immersive** specializes in VR data storytelling (more presentation than analysis)\n- Multiple academic prototypes using Unity/Unreal for immersive graph exploration\n\n**Potential benefits for argumentation**:\n- Z-axis could represent argument depth (premises deeper than conclusions)\n- Spatial metaphor: \"standing inside a debate\" and looking around at different argument clusters\n- Collaborative VR: multiple people exploring the same argument space simultaneously, seeing each other's avatars and focus areas\n\n### Verdict: Not Yet, But Watch\n\nFor Deliberus in 2026, VR/3D is premature:\n- **Hardware penetration** is still low (Quest 3 growing but niche)\n- **Text-heavy content** (arguments are fundamentally textual) renders poorly in VR — reading in VR headsets is fatiguing\n- **Development effort** is 5-10x compared to 2D web\n- **Accessibility**: VR excludes users with motion sensitivity, visual impairments, or no headset\n\n**However**: The Apple Vision Pro and Quest ecosystems are maturing. If Deliberus achieves product-market fit, a VR experience could be a powerful differentiator for immersive deliberation sessions. Worth prototyping in 2027-2028 as hardware improves.\n\n**Near-term alternative**: 2.5D — use parallax, depth cues, and layered rendering to create the perception of depth without requiring VR hardware. CSS 3D transforms + perspective can achieve this in a browser.\n\n### Sources\n\n- [VR Data Visualization Systematic Review (arXiv)](https://arxiv.org/pdf/2203.07616)\n- [yWorks - Graphs in AR/VR](https://www.yworks.com/blog/graphs-in-ar-vr)\n- [Transforming graph data from 2D to AR 3D (Frontiers)](https://www.frontiersin.org/journals/virtual-reality/articles/10.3389/frvir.2023.1155628/full)\n- [Flow Immersive](https://flowimmersive.com/)\n- [yFiles AR/VR Graph Visualization](https://www.yfiles.com/solutions/use-cases/ar-vr-graph-visualization)\n\n---\n\n## 11. Cross-Reference with Lins\n\n### What Lins Already Has\n\nLins is Fredrik's FalkorDB graph explorer. Current state (March 2026):\n\n| Capability | Lins Implementation | Deliberus Relevance |\n|-----------|---------------------|---------------------|\n| **Graph rendering** | Sigma.js + graphology (WebGL) | Direct reuse — same rendering engine |\n| **Layout** | ForceAtlas2 in web worker, 3-second settle | Needs augmentation with hierarchical/DAG layouts for argument trees |\n| **Node interaction** | Hover highlights neighbors, click selects, property panel | Good foundation; needs argument-specific interactions (expand premises, show counterarguments) |\n| **Schema introspection** | Auto-discovers FalkorDB labels, relationships, properties | Reusable for discovering argument graph schema |\n| **Search** | Vocabulary-based typeahead from schema cache | Good start; Deliberus needs argument-aware search (by claim text, by logical role) |\n| **Config system** | `lins.toml` with plugin overlays | Excellent — a Deliberus plugin could define argument-specific styling and layout rules |\n| **Multi-graph** | Supports multiple FalkorDB graphs | Useful for separate debates stored in separate graphs |\n| **Tech stack** | Rust backend (Axum), SvelteKit frontend | Strong foundation; Rust performance for query handling, Svelte for UI |\n\n### What Lins Lacks That Deliberus Needs\n\n| Gap | What's Needed | Effort |\n|-----|--------------|--------|\n| **Hierarchical layout** | DAG layout (dagre/ELK) for argument trees | Medium — integrate layout library, add layout switching |\n| **Semantic zoom** | Show different detail levels at different zoom scales | High — fundamental UX change, needs content aggregation logic |\n| **Argument-aware styling** | Pro/con coloring, strength indicators, controversy markers | Low — plugin overlay system already supports this |\n| **Focus+context** | Re-center on argument, show context rings | Medium — extend neighborhood highlighting to multi-ring |\n| **Breadcrumb navigation** | Show path from thesis to current argument | Low — UI component + path tracking |\n| **Filtering panel** | Filter by topic, score, role, author, depth | Medium — UI + query builder extension |\n| **Collaborative editing** | Multi-user real-time with presence | High — new subsystem (Yjs integration) |\n| **Mobile view** | Card/list alternative to graph view | Medium — new Svelte components |\n| **Minimap** | Compressed overview showing current position | Low-Medium — Sigma.js has minimap plugins |\n\n### Reuse Strategy\n\nLins can serve Deliberus in two ways:\n\n**Option A: Lins as embedded component**\nDeliberus embeds `lins-web` (or a shared Svelte component library extracted from it) as its graph visualization layer. The Deliberus backend feeds argument data through Lins's API format. A Deliberus plugin (`lins-deliberus.toml`) configures argument-specific styling, layouts, and interactions.\n\n**Option B: Shared rendering core, separate apps**\nExtract the Sigma.js + graphology rendering logic into a shared Svelte component library. Both Lins and Deliberus import it. Deliberus adds its own argument-specific components (contention diagram, scoring axes, claim cards) on top.\n\n**Recommendation**: Option B is cleaner long-term. Lins is a generic graph explorer; Deliberus needs argument-specific UX that goes well beyond graph exploration. Extracting the shared rendering core avoids coupling Deliberus's UX decisions to Lins's generic exploration model.\n\n### Rendering Library Decision Impact\n\nLins has an open decision: Sigma.js/SvelteKit vs egui/wgpu (Rust-native, WASM for browser). If Lins moves to egui:\n- Deliberus can still use the Rust rendering crate (`lins-render`) via WASM\n- But the web component model changes (no more Svelte components to reuse)\n- egui's limitations (no color emoji, high memory for images, IME issues) matter more for Deliberus than for Lins, since argument visualization is text-heavy\n\n**For Deliberus specifically**, the SvelteKit + Sigma.js path is safer. Text rendering, accessibility, and web-native interaction patterns matter more for a collaborative argumentation platform than the pixel-perfect control that egui offers.\n\n### The FalkorDB Connection\n\nBoth Lins and Deliberus connect to FalkorDB on Darwin (darwin.home:6380). Lins's schema introspection, query builder, and connection handling (`lins-core`) are directly reusable. If Deliberus stores its argument graph in FalkorDB (via Graphiti or directly), Lins becomes a debugging and exploration tool for the same data Deliberus operates on.\n\n---\n\n## Summary: Key Decisions for Deliberus\n\n1. **Semantic zoom is the highest-priority visualization feature** — it solves the spaghetti problem, scales to large graphs, and maps naturally onto argument hierarchy.\n\n2. **DAG layout (dagre or ELK) for primary argument view**, force-directed for exploration, radial/sunburst for overview. Let users switch.\n\n3. **Search-first exploration** (already proven in Lins) combined with progressive disclosure — do not show the full graph by default.\n\n4. **Sigma.js + graphology remains a strong choice** for the rendering layer, but needs augmentation with hierarchical layout algorithms.\n\n5. **Focus+context with animated transitions** for navigating within a debate. Breadcrumbs for orientation.\n\n6. **Mobile: list/card view**, not a shrunk graph. Design this UX independently.\n\n7. **Yjs for real-time text collaboration** within argument nodes; server-authoritative for structural graph operations.\n\n8. **Extract a shared rendering core from Lins** rather than embedding Lins directly. Deliberus needs its own argument-specific UX layer.\n\n9. **3D/VR: defer to 2027-2028.** Consider 2.5D depth cues in the near term.\n\n10. **Argdown as import/export format** — enables LLM-generated argument structures and power-user text-first workflows.\n"}