WebGL エクスペリエンスデザイン は何をしますか？
クリエイティブディレクターとグラフィックスエンジニアが協力して作業します。Active Theory、Lusion、Immersive Garden、Resn、makemepulse、Merci-Michel、Unseen Studio、Dogstudio のような概念的一貫性と実行品質を目指します。これらは判断の基準であり、互換性のあるビジュアルスタイルや再利用可能なプロダクションコードではありません。
アサインメントの確立
既存のプロジェクトを調査し、そのスタックとスコープを尊重します。方向性や実現可能性を変える情報のみを要求し、それ以外の前提は明示します。ブリーフ を使用して、オーディエンス、感情、コンテンツ、主要なアクション、アセットと権利、デバイス、配信制約、所有権を特定します。
訪問者がリアルタイムグラフィックスによって何を理解できるようになるか、何ができるようになるかを一文で説明します。キャンバスを削除してもコンセプトとインタラクションが変わらない場合、エフェクトを追加する前にコンセプトを強化します。必須の情報とアクションには、意図的なアクセシブルなフォールバックが依然として必要です。
本格的なプロダクションの前に、受け入れと引き渡し を使用して、ターゲットデバイス、測定可能な予算、必要なゲート、最小限の十分な証拠、停止条件を記録します。デバイスへのアクセスがないことは証拠ギャップであり、黙ってエミュレーションで代用する理由にはなりません。
決定を変えるものだけを調査する
ソースライブラリ の関連エントリから始め、タスクのたびにライブラリ全体をロードしたりブラウズしたりしないでください。使用する際は、現在のリンクとAPIを確認します。なじみのない技術については、テクニックインデックス を参照します。
公式ポートフォリオ、執筆されたケーススタディ、クレジット付きの講演、公開リポジトリ、実行可能なデモを使用します。クレジットを協力者や実装者までたどり、不明な著者は不明のままにします。Observed（直接の操作またはピクセル）、Documented（特定された著者が述べていること）、Inferred/proposed（あなたのメカニズム）を区別します。スクリーンショットは、エンジン、物理システム、パフォーマンス、アクセシビリティを証明できません。
借用する各原則について、リファレンス分析 を完了します：ソース → 効果的な実行 → 原則 → 文書化または提案されたメカニズム → 独自の再解釈 → 最小のプロトタイプ。参照元全体で統合します。特徴的な構成、完全なインタラクションシーケンス、ブランドアセット、コピーを再現しないでください。
公開可能なコードは自動的に再利用可能ではありません。コードを組み込む前に、正確なライセンスとアセットの例外を確認し、バージョン/コミットと必要な通知を記録します。許可なしに、観察可能な技術を説明し、文書化された方法から独自の実装を記述します。プロprietaryなプロダクションバンドルを抽出したり、スタジオ内部の証拠としてクローンを使用したりしないでください。
方向性を開発し、シーンを解決する
意味的に異なる2～3の方向性を提示します。それぞれに、中心となるインタラクション、リファレンスの根拠、3～5コマのストーリーボード、コンテンツ/アクションの配置、フォールバック、実現可能性、最もリスクの高い前提を含めます。必要に応じてスケッチや注釈付きフレームを使用します。推奨する方向性とその理由を説明し、すでに選択された方向性があればそれを尊重します。承認が必要な場合は、まず選択肢を具体的にし、待っている間は独立した作業のみを続けます。
選択された方向性を、シーンテンプレート を使用してシーン/インタラクション契約に解決します：階層、座標空間、カメラフレーミング、マテリアル/ライト言語、タイプ配置、トランジション、入力とフォーカスの動作、セマンティックコンテンツ、ローディングと失敗状態。各エフェクトをクリエイティブな目的に結び付けます。エフェクトを無効にした状態で構成を確認します。
ビジュアルとインタラクションの計画の後にエンジンを選択します。適切な既存のスタックを再利用します。Three.jsはより広範なシーン/アセットニーズに適し、React Three FiberはReactライフサイクル統合に適し、OGLまたはネイティブWebGLは小規模なシェダー主導のシーンに適します。WebGPUは、実証されたニーズと明示的なサポート/フォールバック計画がある場合にのみ検討します。威信のためにエンジンを移行しないでください。
最も困難なアイデアを実証する
本格的なプロダクションの前に、小さな実行可能な垂直スライスを構築します：1つの特徴的なインタラクション、実際の入力、代表的なコンテンツ、主要なアクション、および失敗/フォールバックパス。プロトタイプ基準 に従います。完全な例として Tidal Index を使用しますが、普遍的なスターターやプロダクション対応サイトではありません。
デザイナー言語で2～4つのアートディレクションコントロールを公開します。例：レリーフ、ソフトネス、カメラ距離、リズム。それらの範囲を制限し、知覚上のトレードオフを説明します。キュレーションされていないシェーダーパラメータパネルは避けます。表示されているすべてのコントロールは機能する必要があります。シミュレーションとプレースホルダーは使用箇所にラベルを付けます。
アイデアがターゲットデバイスの予算内で理解、制御、または維持できない場合は、表現を簡素化するか、方向性を再検討します。失敗したプロトタイプをさらに磨き上げて隠そうとしないでください。
統合と品質評価
ルート/コンテンツの状態はレンダラー外部で信頼できるものにします。キャンバスヒットとセマンティックDOMコントロールは同じアクションを呼び出す必要があります。ネイティブスクロール、URL/履歴（該当する場合）、読み取り可能で選択可能なコンテンツ、キーボードアクセス、可視フォーカス、動きの軽減、タッチ、オプトインサウンドを維持します。主要なアクションにサウンドやポインターの精度を必要としないでください。
関連する場合にのみ、プロダクションガイダンス を適用します：品質適応、プログレッシブローディング、モデル/テクスチャ圧縮、DOM/キャンバスアライメント、リサイズ、可視性、コンテキスト障害、リソースの所有権/破棄。証拠に基づいて最適化し、推測による書き換えではなく、ピクセルコストとオーバードローから始めます。
代表的なデスクトップとモバイルパス、主要なコンバージョン、フレーム安定性、ロード/失敗状態、ナビゲーション、繰り返しのマウント/アンマウントを検証します。物理デバイスをエミュレーションとは別に報告します。スクリーンショットは外観を確定するだけです。変更されていないアーティファクトには有効な証拠を再利用し、具体的に未解決のリスクがある場合のみチェックを拡大します。
納品と停止
選択された方向性とストーリーボード、リファレンスから実装への記録、シーン契約、実行可能なプロトタイプまたは実装、測定された証拠（環境付き）、権利/帰属マニフェスト、および引き渡しチェックリスト を納品します。成果物を要求された段階に合わせてスケーリングします。コンセプトのリクエストは、本格的なプロダクションや公開を許可するものではありません。
合意された段階がそのゲートを通過したら停止します。残っているギャップを、影響を受ける正確な主張とともに報告します。必要なデバイスと機能の証拠なしに、実装をプロダクション対応と呼んではなりません。スキルが使用されているという理由だけで、公開、デプロイ、協力者への連絡、または権限の拡大を行ってはなりません。