From Scroll to Structure: Rethinking Academic Reading with TreeReader

TL;DR for operators

TreeReader is not interesting because it uses an LLM to summarise papers. That part is now table stakes, which is a polite way of saying everyone has already built the demo.

It is interesting because it treats a paper as a hierarchy rather than a scroll. Sections, subsections, paragraphs, figures, and tables become nodes in an interactive tree. Each node gets a concise LLM-generated summary, and the user can expand downward when detail is needed or move upward when context matters. Crucially, summaries are linked back to source text, so the system does not ask the reader to trust the model’s charming little hallucination engine on vibes alone.¹

The paper’s direct evidence is modest but useful. A formative study with six graduate researchers identifies three recurring problems: finding the actual contribution inside long papers, getting summaries at the right level of detail, and trusting LLM-generated claims. TreeReader then addresses those problems through hierarchical navigation, multi-level summaries, and source-linked evidence. A small within-subject evaluation with five Computer Science graduate researchers suggests better perceived support for skimming, finding information, sensing structure, and reducing cognitive load. Deep reading is more mixed.

The operator takeaway is simple: for high-stakes knowledge work, the next useful AI interface may look less like a chat window and more like a document operating system. The commercial value is not “AI reads for you.” That is the fantasy brochure. The real value is faster triage, cheaper orientation, better traceability, and less cognitive waste when experts move through dense material.

The boundary is equally important. This is not a productivity proof. The study is small, uses two review papers, excludes everyday features such as Ctrl+F, and tests participants in a controlled session rather than a real research workflow. Treat TreeReader as a strong design signal, not a completed ROI case.

Papers are trees trapped inside scrolls

Most academic papers already have structure. They have sections, subsections, paragraphs, figures, captions, tables, citations, and rhetorical roles. The tragedy is that the dominant reading formats pretend otherwise. PDF and standard HTML usually turn that structure into a long linear surface. Scroll, skim, lose place, search, scroll again, regret life choices, repeat.

That matters because academic reading is rarely linear. Researchers do not usually begin at the abstract, serenely proceed through every sentence, and arrive at the conclusion spiritually improved. They jump. They test relevance. They look for novelty. They inspect methods. They compare figures against claims. They decide whether a paragraph deserves attention before reading it in full.

The TreeReader paper starts from this mismatch: documents are hierarchical, but readers are often forced to consume them as streams. The interface problem is not only that papers are long. It is that the reader must mentally reconstruct the paper’s hierarchy while also deciding what matters. That reconstruction is unpaid cognitive labour. Academia, naturally, has found a way to make even reading feel like administrative work.

The authors position TreeReader against two imperfect baselines. Traditional PDFs preserve the canonical document but flatten navigation. LLM chatbots can produce quick summaries but often detach claims from the paper’s structure and source locations. TreeReader’s move is to combine the document’s existing hierarchy with LLM-generated summaries, while keeping verification close to the claim.

That mechanism-first view is the important one. TreeReader is not merely “ChatGPT for papers.” It is closer to a collapsible map of a paper, where the model labels the map but the reader still controls the route.

The mechanism: summarise the node, not the whole paper

TreeReader’s core design is a section tree. Each node represents a unit of the paper: a section, subsection, paragraph, figure, or table. When the user opens a section, TreeReader does not immediately dump the entire text. It displays summaries of child nodes, allowing the reader to decide which branch deserves expansion.

That changes the reading loop.

A PDF reading loop looks like this:

1. Encounter too much text.
2. Scroll until something seems relevant.
3. Use headings, figures, or Ctrl+F as crude steering.
4. Read more than necessary because the cost of locating the right detail is high.

TreeReader’s loop is different:

1. View summaries of the current section’s child nodes.
2. Identify the branch that appears relevant.
3. Expand only that branch.
4. Check source evidence when the summary matters.

The interface uses three columns. The left column is the navigation tree, helping users see where they are inside the document. The middle column shows the active content as cards, with summaries and navigation buttons for moving into child nodes or back to the parent. The right column provides contextual information such as figures from the current subtree and original text or subsection previews.

That layout matters because it separates three cognitive jobs that PDFs often merge into one visual swamp.

The LLM is not used as a general oracle. It is constrained to summarisation. For paragraphs, the appendix prompt asks the model to produce two to five key points, capped at roughly 70 words in total, and to include evidence copied from the original text. For section summaries, TreeReader recursively summarises the summaries of child nodes rather than feeding the whole document into one large prompt.

This is not a minor implementation detail. It is the central safety and usability move. Long-context summarisation can bury details, blur source boundaries, and produce a pleasant abstract that is not useful for navigation. Recursive node-level summarisation preserves the document’s local structure. It lets the system say, in effect: here is what this branch appears to contain; go deeper if it matters.

Reliability is treated as a workflow feature, not a model virtue

The common mistake with AI reading tools is to treat reliability as a property of the model alone. Use a better model, get a better answer, declare victory, update the pricing page. This is the usual ritual.

TreeReader’s design is more sensible. It assumes LLMs are useful but not inherently trustworthy. The authors explicitly motivate the design around two model weaknesses: LLMs may lack current or specialised knowledge, and they can overlook details when processing long inputs. Their response is not to make the LLM sound more confident. It is to narrow the model’s job and expose the evidence.

This is the right pattern for knowledge work. A system used by researchers, analysts, lawyers, consultants, or engineers does not need a theatrical answer machine. It needs a way to compress navigation while preserving auditability.

The formative study explains why. The authors interviewed six graduate researchers across areas including chemistry, artificial intelligence, and human-computer interaction. The participants reported three recurring pain points.

First, information targeting. All six interviewees described frustration with locating the relevant and novel parts of a paper. The useful content may be sparse, distributed, and mixed with familiar background.

Second, information summary. Five participants reported using LLM-based tools for concise summaries, and some mentioned audio-based comprehension tools such as NotebookLM. But participants also said generated summaries could be too verbose, especially for familiar topics where they did not need a beginner-friendly tour.

Third, reliability in high-stakes contexts. Participants used LLMs for comprehension, but they were more sceptical when asked about peer review. Most thought LLMs might help with surface issues such as formatting or grammar. Four raised concerns that LLM use could degrade review quality. Two saw potential for LLMs to complement human reviewers.

TreeReader’s design goals map directly onto those findings: hierarchical information exploration, summaries at multiple levels, and mechanisms for verifying LLM output. That makes the formative study a design-motivation component, not efficacy evidence. It tells us what problem the system is trying to solve. It does not prove the system solves it.

What the study actually tests

The evaluation is small but structured. Five graduate-level Computer Science researchers participated in an 80-minute within-subject study. None had participated in the formative study. Each participant used both a standard PDF reader and TreeReader, across two different scientific review papers, with the order counterbalanced.

For each paper, participants had up to 30 minutes: five minutes for skimming and up to 25 minutes for deeper reading. The skimming activity targeted quick orientation and central contributions. The deep-reading activity involved eight open-ended questions designed to require closer reading and information retrieval. Participants also completed self-report questionnaires and NASA-TLX workload questions.

It is useful to separate the paper’s evidence types before interpreting the results.

That last point matters. The paper says accuracy and completion time were recorded for deep reading, and the appendix provides raw participant answers. But the published discussion leans more heavily on self-report, qualitative feedback, and average ratings than on a full statistical performance analysis. So the right interpretation is cautious: TreeReader appears promising for orientation and perceived navigation, while deep-reading gains are not yet cleanly established.

The evidence is strongest for skimming and structural orientation

The clearest signal appears in skimming and structural sensemaking.

After five minutes of skimming, TreeReader scored higher than the PDF reader on every self-reported dimension. The differences were not dramatic, but they were directionally consistent: understanding the review objective rose from 3.60 to 3.80, organisation from 4.00 to 4.20, key messages from 3.40 to 3.80, strengths and weaknesses from 2.20 to 2.80, and field challenges from 3.20 to 3.40 on a five-point scale.

The largest skimming gain was for understanding strengths and weaknesses, though even TreeReader’s average there remained only 2.80. That is a useful detail. TreeReader may help readers locate the shape of a paper, but judging strengths and weaknesses still requires expertise, context, and careful reading. Apparently the machine does not instantly turn a five-minute skim into peer review. Tragic, but survivable.

The post-activity results are more striking for structure. After skimming plus deep reading, participants rated TreeReader higher on “helps understand papers” (3.60 versus 2.60), “easy to find information” (3.20 versus 2.40), and especially “easy to sense paper structure” (4.20 versus 2.60). Confidence ratings improved only slightly, from 3.20 to 3.40 for both early and later question groups. Perceived reliability also improved from 3.00 to 3.40.

The pattern is coherent. TreeReader’s biggest advantage is not that it magically makes users more certain about every answer. It helps them orient, find, and sense structure. That is exactly what the mechanism predicts.

The NASA-TLX results point in the same direction. Lower scores indicate lower workload for all categories except performance. TreeReader had lower average mental demand (3.40 versus 3.60), physical demand (2.00 versus 3.33), temporal demand (2.60 versus 3.75), effort (2.60 versus 3.80), and frustration (2.60 versus 3.00). Performance was basically unchanged, with TreeReader at 3.40 and the PDF reader at 3.33, a difference too small to treat as meaningful.

So the evidence does not say: “TreeReader makes people better scholars.” It says something narrower and more commercially useful: a hierarchical, source-linked reading interface may reduce the felt cost of moving through dense papers, particularly during early triage and orientation.

That is a valuable result precisely because it is not grandiose.

Deep reading exposes the tension between maps and details

The paper’s deep-reading findings are mixed, and that is where the design becomes interesting.

A tree interface helps users move through structure. But detailed question answering can require the opposite behaviour: keyword search, exact phrase retrieval, and rapid jumps to specific lines. The authors note that some participants found TreeReader helpful for sensemaking and navigation, while others had difficulty retrieving specific details. Several suggested improvements such as keyword search and dynamic subtree generation.

That feedback is not a failure of the concept. It reveals the boundary of the current interface. Hierarchy is excellent for orientation. It is less obviously sufficient for exact lookup. A useful AI reader therefore needs at least two modes:

TreeReader currently does well on the first and gestures toward the third. The second needs stronger support. The fourth is a natural extension but not directly tested.

For business users, this distinction is important. A due-diligence analyst, legal associate, product researcher, or R&D manager does not only need “summaries.” They need to change gears between orientation and forensic retrieval. A beautiful hierarchy without search is a museum map with no room numbers. Helpful, but eventually someone needs to find the bathroom.

The business value is reduced cognitive waste, not automated expertise

The obvious enterprise pitch would be: TreeReader helps employees read faster. That is probably true in some contexts, but it is still too blunt.

The sharper interpretation is that TreeReader reduces cognitive waste at the beginning of a knowledge task. It helps users answer four operational questions quickly:

1. What is this document about?
2. Where are the important parts?
3. Which branches can I safely ignore for now?
4. Can I verify the summary before relying on it?

Those questions appear constantly outside academia. A consultant reviews a technical appendix. A lawyer inspects a contract bundle. A product team studies a standards document. A pharmaceutical team reads a trial report. A finance team checks filings. A public-sector analyst reviews policy submissions. In each case, the expensive human is not merely reading. They are triaging attention.

TreeReader’s mechanism suggests a broader design principle for AI knowledge systems:

Preserve the structure of the source, compress each unit locally, and keep verification one click away.

That principle is more useful than “add a chatbot to the document.” Chatbots collapse everything into a conversational stream. Sometimes that is convenient. Often it destroys the very structure that experts rely on to decide whether an answer is trustworthy.

For operators building AI tools, the lesson is architectural. Do not start with a blank chat box. Start with the information object. What is its native structure? Sections, clauses, exhibits, tables, figures, tickets, code files, meeting threads, transactions? Then design the AI layer to expose that structure, not replace it with synthetic prose.

Where TreeReader-like interfaces fit in the enterprise stack

TreeReader is built for academic papers, but the pattern generalises. The most plausible business applications are not casual reading tools. They are high-density review workflows where document structure already exists but is painful to traverse.

The common factor is not “LLM summarisation.” It is expert navigation under time pressure. TreeReader-like systems are useful when the user already has judgement but needs a better map.

That also means the ROI case should be measured carefully. The right metrics are not only answer accuracy. They include time-to-orientation, number of source checks, missed critical sections, confidence calibration, rework rate, and expert satisfaction after repeated use. A one-session novelty bump is not enough. Even the paper recognises this; participants may have been affected by novelty, unfamiliarity, and the artificial study environment.

The missing product layer: search, memory, and repeated use

TreeReader’s current design leaves several product questions open.

First, search. The evaluation excluded common interaction features such as Ctrl+F. That makes the comparison cleaner in one sense but less realistic in another. Real readers use search constantly. A future TreeReader needs search that works across raw text, summaries, figures, citations, and tree nodes.

Second, parsing. The implementation uses GPT-4o to process HTML extracted from Springer Nature publications. That is a reasonable prototype path, but enterprise deployment would require robust parsing across messy PDFs, publisher formats, scanned documents, tables, formulas, appendices, and versioned files. The interface is only as reliable as the document structure it extracts.

Third, summary quality. The appendix prompt asks the model to produce key points and evidence. That is good design, but it does not eliminate summary error. Evidence snippets can be incomplete, subtly mismatched, or too narrow. A production system would need evaluation pipelines for summary faithfulness, coverage, and source alignment.

Fourth, repeated use. Participants reported that TreeReader could feel less cognitively demanding once they became accustomed to its structure. That is plausible. It is also unproven. Tools with unfamiliar interfaces often show two competing effects: a short-term novelty penalty and a short-term novelty boost. Only longitudinal field studies can separate durable productivity from “new toy syndrome,” the most overfunded research method in software.

What not to conclude

The tempting conclusion is that TreeReader proves LLMs can replace careful reading. It does not. It almost argues the opposite.

TreeReader’s design keeps the reader in control. The LLM labels and compresses. The human navigates, expands, checks, and interprets. Source references are not decoration; they are the mechanism that prevents summarisation from becoming unsupported authority.

That distinction matters because knowledge-work automation often fails by removing too much context. A system that gives an answer without preserving the path to evidence may feel efficient until the first serious mistake. Then the saved minutes become a very expensive afternoon.

The more defensible conclusion is that LLMs can improve reading interfaces when their role is constrained and their output is embedded into navigable structure. That is a quieter claim than “AI reads papers now.” It is also much more likely to survive contact with reality.

The boundary: promising interface, thin evidence

The paper’s limitations materially affect interpretation.

The evaluation includes only five participants, all graduate-level Computer Science researchers. That is not enough to generalise across disciplines, seniority levels, reading styles, or document types. The study uses two review papers, not a broad corpus of empirical papers, mathematical papers, clinical papers, legal documents, or business reports. The authors also note possible novelty effects, Hawthorne effects, and the omission of everyday functionality.

The deep-reading evidence is especially bounded. The raw answers in the appendix are useful for seeing participant behaviour, but they do not amount to a decisive accuracy analysis in the article’s main results. The strongest claims should therefore remain about perceived structure, navigation, skimming, and workload.

For business adoption, the missing evidence is field durability. Do users still prefer the tree after two weeks? Does it reduce missed issues? Does it improve expert review quality or merely make users feel more organised? Does source-linking reduce hallucination risk in practice? Does the interface scale to multi-document work? Those are the questions that matter once the demo is over and procurement begins its majestic crawl.

The better AI reader is a map, not a mouth

TreeReader’s contribution is structural. It takes the hierarchy already present in academic papers and makes it operational. The LLM does not sit above the document as an all-knowing narrator. It works inside the document, summarising nodes, pointing to evidence, and helping the reader decide where to go next.

That is why the paper is more important than its small evaluation alone. It points toward a better design philosophy for AI knowledge tools. Instead of asking models to replace expert reading, use them to expose structure, compress local content, and preserve verification.

The future of AI reading may not be a chatbot that answers every question. It may be an interface that makes documents navigable enough that experts can ask better questions in the first place.

Less scroll. More structure. Fewer heroic acts of PDF archaeology.

Cognaptus: Automate the Present, Incubate the Future.