Loading
The version tree records the evolution path of a design proposal from the base version through structured reviews and forked improvements. This guide explains how to read the version tree, compare branches, understand change rationales and risks, and why you shouldn't judge versions by renders alone.
The version tree is suitable for: - You want to understand what discussions and iterations a design project went through. - You want to compare different design directions and understand their respective pros and cons. - You want to participate in collaboration and need to understand the project's historical context. - You're learning design and want to understand the reasoning behind design decisions. The version tree is not a leaderboard — it's not about which version "looks best". Its core value is preserving the design reasoning process, making every design decision traceable.
Node types in the version tree differ by content type. The project version tree shows: - Base project: the client's published spatial goals, constraints, and aesthetic preferences — the starting point for all subsequent work. - Forked improvement: an improvement branch based on a project that branches off to form a new branch. - Structured review: review comments on a version, including strengths, issues, suggestions, and risk reminders, connected to the reviewed node. The request version tree shows: - Base request: the spatial problem and constraints published by the requester — the starting point for proposals. - Proposal: a complete design solution submitted for the request. - Adoption: a record that the requester adopted a proposal. On the project detail page and request detail page, you can see these nodes arranged chronologically, with indentation indicating branch relationships.
When reading the version tree, follow these steps: 1. Start from the base version: first understand the client's core needs, constraints, and preferences. This is the baseline for judging whether all subsequent proposals are reasonable. 2. Read down the main line: look at each proposal or fork's design strategy and layout approach. Note the differences between proposals. 3. Read review nodes: see the community's evaluation of each proposal. Focus on the strengths, issues, and suggestions pointed out in reviews. 4. Look at forked improvements: understand the fork's goal, specific changes, and rationale. Compare the differences between the fork and the original. When comparing different branches, don't just look at renders. Compare: differences in design strategy, differences in layout logic, differences in budget allocation, differences in risk handling. A good version isn't necessarily the prettiest, but the most reasonable under the given constraints. Click the "View version tree" button on the project detail page to enter the full version tree page.
The core value of the version tree isn't showing "who made which version", but showing "why it was done this way" and "what the trade-offs are". Each forked improvement node includes the rationale and new risks. The rationale explains why the designer made these changes and what judgment they were based on. The new risks explain the potential costs of the changes. For example, a fork might improve circulation by adjusting the kitchen layout, but at the cost of reducing dining area. If you only look at renders, you might think "the new version is better", but if you read the risk notes, you'll understand this change also has trade-offs. This is the meaning of the version tree: making the design decision process transparent, making every choice traceable, and enabling collaborators to make judgments with full context.
Here are the most common mistakes when reading the version tree: 1. Judging versions by renders alone: renders are just one dimension of design and cannot reflect circulation, storage, budget, construction feasibility, and other key factors. 2. Ignoring the base version's constraints: when evaluating proposals, forgetting that the client has budget limits, must-keep structures, and specific usage needs. Evaluating proposals without considering constraints is meaningless. 3. Ignoring review content: review nodes contain the community's professional judgment. Skipping reviews and going straight to proposals misses important context. 4. Treating the version tree as a leaderboard: the version tree records an evolution process, not rankings. A fork isn't necessarily "better" than the original — just "different".
The version tree page (accessed via the "View version tree" button on the project detail page) displays: - Project info summary: space type, area, style, budget. - Version tree body: nodes arranged chronologically, each showing name, status tag, description, contributor, and date. Node indentation indicates branch hierarchy. - Version tree explanation: explanatory text at the bottom of the page explaining the meaning and reading method of the version tree. A "Back to project" button at the bottom returns to the project detail page. Note: the version tree shows the evolution process of design proposals, not construction progress or project status.