Spark Program | Cell Sandbox — A Visual Playground for the CKB Cell Model

DAOs & Funding Spark Program
, ,
21

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.

1 Like
22

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.

  1. UI/UX and progressive disclosure

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:

  • What a Cell contains
  • What lock and type scripts do
  • How Cells are consumed and created
  • How that model maps to CCC code

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.

  1. Reusing CCC

The duplicated implementations you identified have been replaced:

  • Script deployment data is resolved through 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.
  • Capacity calculations now use CCC’s CellAny.occupiedSize and capacityFree instead of a custom occupancy formula.
  • The Journey explicitly connects the visual model to Transaction.from, completeInputsByCapacity, and completeFeeBy.

This makes CCC the source of truth for protocol-related behavior while the sandbox focuses on explanation and visualization.

  1. Reducing cognitive burden

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.

  1. Usability validation

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.

1 Like