Diagram relationships and time records
ManYue pictured flowcharts: distinguish branches, merges and loops from page order
Trace two original inputs through arrows and decisions, distinguishing alternative branches, merges and any unspecified parallel behaviour.
On this page
A higher box does not necessarily execute first, and merged lines do not necessarily mean both branches run. Read a fictional card-sorting flowchart in ManYue by tracing arrows and decisions. This is not a procedure for hazardous equipment or a promise that the app executes diagrams or verifies algorithms. Missing conventions remain unknown.
Fix the legend and process scope
Record work, edition, chapter/page and title, then read the meanings of start/end, action boxes, decision boxes and arrows rather than assuming them from familiar shapes. Our self-made process starts with taking one paper card and ends with putting it in a sorted box, not operating a real machine. If the source omits a start or end, record the gap instead of making the highest box the start. Numbers may be explanatory labels rather than execution order; arrows still matter. Retain the full diagram and legend so a crop is not mistaken for the complete process.
Record arrows as directed connections
The original path is start→take card→decision “has a number?”. The yes branch goes to register; the no branch first assigns a temporary number, then reaches register. Register leads to put in box, then end. Give boxes external identifiers and record source box, destination box and condition for every arrow. Yes/no are explicitly exclusive alternatives here; two lines do not universally imply exclusivity. An unmarked line crossing is not a merge. Obscured arrows remain unresolved rather than being supplied from reading habits, and there is no assumed ManYue node-dragging validator.
Trace numbered and unnumbered inputs separately
Input A is a card already numbered 7: it skips assignment, registers 7 and enters the box. Input B is unnumbered; this example stipulates available temporary number 99, so assign 99, register that same number and box it. The number is original sample data, not an app-generated field. Record entering and leaving state at each box, checking that B registers its new number rather than remaining “unnumbered.” List paths separately so B’s assignment is not also assigned to A. If the actual diagram omits number-allocation rules, mark them unknown instead of generalising this sample to real archive management.
A merge continues paths without necessarily running both
Two incoming arrows at register mean either candidate path can reach it; this process does not execute the numbered branch followed by the unnumbered branch. Take one card, decide once, follow one satisfied condition and register once. Do not interpret the merge as waiting for both branches or infer order from left/right placement. A different diagram with explicit parallel and synchronisation notation requires that diagram’s own legend; this simple decision convention cannot replace it. Alternative selection and parallelism are distinct, and arrow count alone cannot decide between them.
Read the return point and stop condition of a loop
In a separately labelled loop control, add “cards remaining?” after boxing: yes returns to take card, no ends. Returning to take card rather than register ensures the new card is checked for numbering. Returning incorrectly to register skips taking a card and testing it again. It may register the previous card twice or leave its state unclear; the diagram does not establish that a new card has been taken. Trace A then B: take twice, register twice, then end only after the post-B check finds none left. This verifies the finite sample, not termination of every possible process. An absent stop condition remains a documented gap rather than a condition you silently insert.
Use diagram evidence rather than plot to fill arrows
A character saying “I finished quickly” does not prove every branch is correct or every exception handled. Keep dialogue, diagram path and your trace separate, allowing narrative exaggeration and process gaps to coexist. If decision exits lack labels, mark their conditions uncertain instead of assuming left means yes. Follow an off-page connector only after finding its matching identifier; otherwise stop at the known scope. A single story action is not a general legend, and real-device knowledge must not supply omitted procedural or safety steps in the picture.
Troubleshoot crossing return lines and small labels
Inspect all line routes in the complete diagram, then enlarge arrowheads and condition text instead of following only the thickest downward line. If zoom or source quality hides an arrowhead, mark direction unresolved rather than guessing from a darkened end. An external connection table can aid review, but every row must point to the diagram rather than be generated from an expected process. If two traces disagree, check missed exit labels, identically named boxes and off-page connectors before alleging a source error. Keep original and rewritten versions distinctly named; overwriting it is not an author-approved repair.
Exit and return to retrace both paths and the loop
Exit the reader and return to the title and start box. Cover your earlier record and trace the card numbered 7 and the unnumbered card again, checking registration count, number state and whether boxing ends the process. Run the two-card loop control separately. Retain six items: diagram identity, connections, decision conditions, input state, step results and unspecified rules. Completion means paths follow reproducible arrows and conditions, not that tidy appearance certifies an algorithm. Uncertain directions and exception scope remain unresolved; a comic flowchart is not automatically an operational procedure for a real business.
Related guides and sources
ManYue instructional-comic reading: audit step states and missing conditions; ManYue branching comics: manually log nodes, choices and return routes.
Checked on November 10, 2026: Apple public version information lists ManYue 2.0.5, requiring iOS / iPadOS 15.0 or later. See the official App Store for feature descriptions; specific controls must still be checked in the installed version.
Method reference: American Society for Quality: flowcharts and flow direction. Numbers, short passages and controls are original exercises. Sources explain concepts rather than prove automatic recognition or grading in the app. Manual notes may be kept externally. This article does not claim step-by-step testing on a physical device or private server; unresolved content should remain marked for review.