ウェブは素晴らしいプラットフォームです。ほぼすべてのデバイスで、世界中のユーザーにリーチしています。使いやすく、共有も簡単です。インストールは不要です最も重要なのは誰もが使用または構築できる オープンエコシステムであることです
現在、オープンウェブで構築して配信することが不可能なアプリもあります。これをアプリのギャップといいます。ウェブでできることとネイティブでできることの ギャップですGoogle は、このギャップを埋めたいと考えています。Google は、ウェブアプリはネイティブ アプリであれば何でもできるべきだと考えています。
これらの新機能をどのように設計、実装するか？
このプロセスは、デベロッパーのニーズを迅速かつオープンに、そして最も重要な点として既存の標準プロセス内で作業できる新しいウェブ プラットフォーム機能を設計、開発することを可能にするために開発されました。他のウェブ プラットフォーム機能の開発方法と同様ですが、デベロッパーからのフィードバックに重点を置いています。
デベロッパーからのフィードバックは、Google が適切な機能を提供できるようにするうえで非常に重要ですが、手続きの後半で入手した場合、方向性を変更するのは困難な場合があります。そのため、早めにフィードバックの提供をお願いしています。実用的な技術的フィードバックやユースケース フィードバックが早期に得られた場合、考え抜かれた機能や実装が不適切な機能をリリースすることなく、軌道修正や開発の中止が容易になります。WICG で開発中の機能は確定したものではなく、ユーザーの入力によって機能が進化する可能性があります。
多くのアイデアが説明中やオリジン トライアルの段階を通らない点は注意が必要です。このプロセスの目的は、適切な対象物を提供することです。つまり、迅速に学習して反復処理する必要があります。デベロッパーのニーズを解決できないため、機能をリリースしなくても問題ありません。この学習を可能にするために、次のプロセスを使用するようになりました（ただし、フィードバックにより後のステップの順序を変更することがよくあります）。
デベロッパーのニーズを特定する
最初のステップは、デベロッパーのニーズを特定して理解することです。デベロッパーが達成しようとしていることは何か？誰が使うのでしょうか？現在の状況はどうなっているか？ また、この新機能によってどのような問題や不満が解消するか。これらは通常、デベロッパーからの機能リクエストとして受け取り、多くの場合、bug.chromium.org に提出されたバグを通じて受け取ります。
説明動画を作成する
新しい機能の必要性を特定したら、説明を作成します。これは基本的に、問題を説明するための設計ドキュメントと、API の仕組みを示すサンプルコードを作成します。この説明書は動的な設計ドキュメントであり、新しい機能が進化するにつれて何度もイテレーションが行われます。
フィードバックを得て説明内容を繰り返し行う
説明が妥当なレベルに達したら、公開してフィードバックを求め、設計を繰り返します。これは、新しい機能がデベロッパーのニーズを満たし、想定どおりに動作することを確認する機会です。一般の人々から支持を集め、この機能の必要性を確認する機会でもあります。
設計の仕様を導入して反復処理を行う
説明文が良好な状態になると、設計作業は正式な仕様に移行し、デベロッパーや他のブラウザ ベンダーと協力して、設計のイテレーションと改善を行います。
設計が安定し始めたら、通常はオリジン トライアルを使用して実装をテストします。オリジン トライアルでは、実際のユーザーに新機能を試し、実装に関するフィードバックを送信できます。この実社会からのフィードバックは、設計の形成と検証に役立ち、標準になる前に Google が正しいことを確認します。
発送する
最後に、オリジン トライアルが完了し、仕様が確定し、他のすべてのリリース ステップが完了したら、安定版をリリースします。
ユーザーのセキュリティ、プライバシー、信頼性を考慮した設計
これらの機能の一部は、最初は不安に思えるかもしれません。特にネイティブでの実装方法を考えると、しかしウェブは本質的にネイティブよりも安全です ウェブページを開くことはそれほど難しくありません
デフォルトでアクセス権を付与すべきものはありません。代わりに、ユーザーが完全に制御でき、簡単に取り消し可能な権限モデルに依存してください。これらの API がいつ、どのように使用されるのかを明確にする必要があります。Google の思考プロセスの一部については、強力なウェブ プラットフォームの機能へのアクセスの制御で概説しています。