Hi Yixiu,
Thank you for the detailed feedback. I’ll respond to each point by August 5th, along with updates that will have been made to the project by then.
Hi Yixiu,
Thank you for the detailed feedback. I’ll respond to each point by August 5th, along with updates that will have been made to the project by then.
Hi Yixiu,
Thank you for the detailed review. Your criticism was fair for the version you tested. In particular, the interface still exposed too much implementation detail too early, and I should not have treated functional test results as evidence of usability.
I have now pushed a ground-up redesign rather than another visual polish pass: commit 7e49599.
The previous Learn page has been replaced with a guided Journey. It begins with a welcoming explanation and a 3D Cell lifecycle showing that a Cell is validated, consumed, and replaced by new output Cells.
The Journey introduces one concept per screen:
There are no editable raw fields in this learning flow. Editing is reserved for the separate Cell Lab, while transaction inspection and building are also distinct workflows. The primary navigation is now Journey / Cell Lab / Transaction Explorer / Build & Test, with substantially different information density and purpose in each area.
The duplicated implementations you identified have been replaced:
ccc.KnownScript, CCC clients, and ccc.ScriptInfo. The remaining curated metadata only provides educational names, descriptions, and lock/type categorization; code hashes and network deployments are no longer independently hardcoded.CellAny.occupiedSize and capacityFree instead of a custom occupancy formula.Transaction.from, completeInputsByCapacity, and completeFeeBy.This makes CCC the source of truth for protocol-related behavior while the sandbox focuses on explanation and visualization.
I agree that the tool should not make a three-line CCC workflow harder to understand. The redesigned experience therefore ends by showing those three operations directly. The visual interface is intended to explain what those calls do, not replace them with another abstraction learners must memorize.
The Build workflow is also staged around defining outputs, completing funding and fees, reviewing the resulting transaction, and signing, rather than presenting every field simultaneously.
This point remains valid. TypeScript, lint, unit tests, and browser checks establish implementation correctness, but they do not demonstrate that a newcomer understands the Cell model.
I will treat usability validation as a separate requirement: sessions with developers unfamiliar with CKB, measuring onboarding time, whether they can explain the Cell lifecycle afterward, whether they can identify lock/type responsibilities, and where they hesitate while constructing a transaction. The findings and resulting changes should be reported explicitly rather than summarized as subjective self-assessment.
Thank you again for identifying these gaps. The new version addresses the structural UI and CCC-integration issues, while novice usability testing remains the next piece that must be demonstrated with evidence.
Hi everyone,
Following the redesign in commit 7e49599, this week I’ll focus on testing the new flow with people who are unfamiliar with CKB.
I want to see whether newcomers can move through Journey, Cell Lab, Transaction Explorer, and Build & Test without extra guidance. I’ll note where they get stuck, which terms are unclear, and whether they understand how transaction inputs and outputs are handled.
Anyone new to CKB is welcome to try the live demo and share feedback in this thread.
I would also like to ask the committee to process my previous funding request for the work completed so far.
Hi Zynor, thanks for your ongoing building within the community.
However, after careful review and consideration, the committee has decided to discontinue the project. The reasons are as follows:
Therefore, we regretfully have to terminate the project. We do, of course, encourage you to continue refining your application and to keep engaging with the community.
Best,
Hongzhou
On Behalf of Spark Committee
Hi @zz_tovarishch, and the committee,
Thank you for the feedback on the project termination. I understand the committee’s concerns about factual accuracy in educational content, and I take that seriously.
I want to respectfully address three points:
1. Work Completed and Deliverables
The approved milestones through July 4 have been fully delivered and verified:
Milestone 1 (Guided sandbox flow): Completed
Milestone 2 (Transaction inspector): Completed
Milestone 3 (partial) (Wallet integration and Build Tx): Completed
The 20% initial payment was disbursed and received. The 60% request covered work on these completed milestones. This work is live, testable, and represents significant development effort over six weeks.
The remaining 20% was appropriately held pending the final report with usability validation — a deliverable I was actively working on when the termination notice was received.
2. Factual Error Identification
I’ve conducted an audit of the educational content against CKB’s official documentation and identified terminology issues:
“Dead cell” language (non-standard terminology) — being corrected to “spent cell” to align with CKB spec
I’ve prepared fixes for these issues .
However, you mentioned “factual errors within the educational project” without specifying which ones. I would genuinely appreciate if the committee could share the specific errors you identified. This would allow me to:
Address them accurately rather than guessing
Understand where the educational content diverged from spec
Ensure all corrections are technically sound
3. Request for Fair Compensation
I’ve invested significant time in this project — from the initial MVP, through the committee feedback cycles, redesign, implementation of all three milestones, and now error correction. The work completed is substantial and was approved as delivered.
I respectfully request:
Payment for completed work (the 60% request): This represents honest effort on deliverables the committee approved on July 4
Specific error details from the committee: So I can fix them correctly
Opportunity to resubmit after corrections: The project has real educational value, and the errors are fixable
I’m committed to making Cell Sandbox a rigorous educational tool. Fair compensation for the work already done would be a meaningful way to support that continued effort.
The project is valuable. The errors are addressable. I’d like the chance to fix them properly.
Thank you for considering this respectfully.
Hi @zynor, thank you for your response and for outlining your perspective.
After further discussion within the committee, we would like to clarify our decision and the underlying core principles:
Nature of the Spark Program: As discussed in the Spark 不是什么,Spark 想做什么, Spark Program is designed to empower experimental ideas and community exploration—it is not a bounty platform or task-based employment model. Funding is provided to support viable milestones rather than compensating for accumulated development hours.
Funding Request & Decision: Because the overall deliverables and educational contents failed to meet the required standards and expectations for the target audience, the committee decided to terminate the project. We will not be approving any further funding requests for work retroactively or following a project termination, as doing so contradicts the fund’s operation framework.
As part of our standard procedure, this thread will now be closed.
We appreciate the effort you have invested in the CKB ecosystem and encourage you to take these insights forward into your future proposals and community engagement.
Best,
Spark Committee