JP2023169320A - 階層流動コンポーネントおよび動的レイアウトを統合した応答編集および表示を提供するシステムおよび方法 - Google Patents

Abstract

【課題】ウェブサイト構築システムを提供する。【解決手段】プロセッサと、流動コンポーネント、複数のビューポートサイズ用のブレークポイント範囲、動的レイアウトルール、流動コンポーネントを編集するための応答編集ルールを含むウェブサイトページのレイアウトを格納するデータベースと、応答編集モジュールと、を有するウェブサイト構築システムにおいて、応答編集モジュールは、入力トリガに関連付けられた、動的レイアウトルール及び応答編集ルールに応じて構築されるウェブサイトのレイアウト決定を提供するルールエンジンと、入力トリガ及び現在のビューポートの大きさを受信し、レイアウト決定に応じて現在のビューポート用の更新流動応答デザインレイアウトを生成する応答エディタと、更新流動応答デザインレイアウトのデザインの特徴を現在のビューポート用のスマートＣＳＳにマッピングするＣＳＳジェネレータと、を含む。【選択図】図４

Description

本出願は、２０１９年５月２０日に出願された米国仮特許出願第６２／８５０，２４４号、および２０２０年２月４日に出願された米国仮特許出願第６２／９７０，０３４号からの優先権を主張し、これらは両方とも参照により本明細書に組み込まれる。

本発明は、ウェブサイト構築システムに関し、特に、応答編集に関する。

ウェブサイト構築システム（ＷＢＳ：Website Building System）は、インタラクティブウェブサイトを作成するために、初心者および専門家の両方によって使用される。既存のＷＢＳはビジュアル編集モデルに基づいており、ほとんどのＷＢＳは一般に複数のテンプレートを提供し、テンプレートには完全なサンプルウェブサイト、ウェブサイトセクション、単一ページまたはページのセクションが含まれる可能性がある。

ＷＢＳユーザ（デザイナ、加入者、加入ユーザまたはサイトエディタとも呼ばれる）はウェブサイトをデザインすることができ、ウェブサイトのエンドユーザ（「ユーザのユーザ」）は、ユーザが作成したウェブサイトにアクセスすることができる。エンドユーザは、通常、読み取り専用モードでシステムにアクセスするが、ＷＢＳ（およびウェブサイト）は、エンドユーザが、データレコードの追加または編集、ニュース記事へのトークバックの追加、ブログへのブログエントリの追加など、ウェブサイトに対する変更を実行することを可能にすることができる。ＷＢＳは、実際には、複数のレベルのユーザ（すなわち、３つ以上のレベル）を許可し、各レベルに異なるパーミッションとケーパビリティを割り当てる可能性がある。ＷＢＳのユーザ（特に、以下に述べる完全または部分的なオンライン構成）は、ユーザ、そのウェブサイト、およびエンドユーザによるアクセスを管理するＷＢＳサーバに登録することができる。

ＷＢＳは、スタンドアロンシステムであってもよいし、より大きな編集システムの内部に埋め込まれていてもよい。また、オンライン（すなわち、アプリケーションは、編集され、サーバ上に記憶される）、オフラインまたは部分的にオンライン（ウェブサイトは、ローカルで編集されるが、公開のために中央サーバにアップロードされる）であってもよい。ＷＢＳは、内部データアーキテクチャを使用して、ＷＢＳベースのサイトを記憶することができ、このアーキテクチャは、処理されるサイトの内部データおよびシステム内の要素を編成することができる。このアーキテクチャは、サイトの外部ビューとは異なる場合がある（エンドユーザなどから見た場合）。また、通常は、ブラウザに送信されるＨＴＭＬページの編成方法とは異なる。

例えば、内部データアーキテクチャは、ページ内の各要素（作成者、作成時間、アクセス許可、テンプレートへのリンク、ＳＥＯ（Search Engine Organization）関連情報など）の追加プロパティを含むことができ、これらはＷＢＳ内のサイトの編集およびメンテナンスに関連するが、エンドユーザ（または一部の編集ユーザ）には外部から見えない。ＷＢＳは、その機能の一部（編集とランタイム機能の両方を含む）をサーバまたはサーバ設定に実装し、その機能の一部をクライアント要素に実装する場合がある。ＷＢＳは、サーバ上で何らかの機能を実行するか、クライアントプラットフォーム上で実行するか否かを動的に決定することもできる。

ＷＢＳは、通常、ページ、コンテナ、およびコンポーネントで構成される、視覚的に設計されたアプリケーション（ウェブサイトなど）の作成および編集を処理する。ページは別々に表示され、コンポーネントを含んでいてもよい。コンポーネントは、アトミックコンポーネントだけでなくコンテナも含むことができる。図１を参照する。図１は、本発明のいくつかの実証的な実施形態に従った、ウェブサイト３の構築に使用され得るウェブサイト構築システム（ＷＢＳ）２の概略ブロック図である。ＷＢＳ２は、コンポーネント５（例えば、テキスト、イメージ、ビデオ）を含むことができるページ４を含むことができるウェブサイト３を構築、作成、編集、生成の少なくとも１つを行うために使用することができる。

ＷＢＳはまた、アトミックコンポーネント（テキスト、イメージ、形状、ビデオなど）、ならびに他のコンポーネントを含む様々なタイプのコンテナコンポーネント（例えば、通常のコンテナ、シングルページコンテナ、マルチページコンテナ、ギャラリコンテナなど）を使用するコンポーネントの階層配置をサポートすることができる。コンテナコンポーネント内に含まれるサブページは、ミニページと呼ばれ、その各々は、複数のコンポーネントを含むことができる。コンテナコンポーネントによっては、ミニページを一度に１つだけ表示するものもあれば、複数のミニページを同時に表示するものもある。

これらのコンポーネントは、コンテンツが少なくてもよいし、内部コンテンツを有していてもよい。第１のカテゴリの例は、星形コンポーネントであり、（色、サイズ、位置、属性、および他のパラメータを有するが）内部コンテンツを有さない。第２のカテゴリの例は、テキストパラグラフコンポーネントである。その内部コンテンツには、フォント、書式設定、およびレイアウト情報（コンポーネントの属性ではなく、コンテンツの一部でもある）だけでなく、内部テキストも含まれる。もちろん、このコンテンツは、テキストパラグラフコンポーネントのあるインスタンスから別のインスタンスに変わり得る。コンテンツを有するコンポーネントは、しばしばフィールド（例えば、「テキストフィールド」）と呼ばれる。

ページでは、テンプレート、一般的なページテンプレート、またはコンポーネントテンプレートを使用できる。テンプレートの具体例としては、他のすべての通常のページで複製されたコンポーネントを含むアプリケーションマスターページの使用、アプリケーションヘッダーまたはフッター（すべてのページで繰り返される）の使用などがある。テンプレートは、ページ全体またはページセクションに使用できる。ＷＢＳは、テンプレート間、ページ間、またはコンポーネント間の継承を提供することができ、多重レベル継承、多重継承、およびダイヤモンド継承（すなわち、ＡはＢおよびＣから継承し、ＢおよびＣはＤから継承する）を含むことができる。

ページ内のコンポーネントの視覚的な配置は、レイアウトと呼ばれる。ＷＢＳはまた、動的レイアウト処理をサポートすることができる。この処理は、所与のコンポーネントの編集（または外部駆動コンテンツ変更など、それに影響を及ぼす他の変更）が他のコンポーネントに影響を及ぼすことができ、これは、出願人によって共有され、参照によって本明細書に組み込まれる、２０１９年１月２２日に付与された「Ｗｅｂｓｉｔｅ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｎｇ Ｄｙｎａｍｉｃ Ｌａｙｏｕｔ ａｎｄ Ｄｙｎａｍｉｃ Ｃｏｎｔｅｎｔ」という名称の米国特許第１０，１８５，７０３号にさらに記載されている。

ＷＢＳは、サードパーティアプリケーションおよびそのコンポーネントのようなアドオンアプリケーション、リストアプリケーション（出願人によって共有され、参照によって本明細書に組み込まれる、２０１４年９月１８日に公開された「ＷＢＳ Ｉｎｔｅｇｒａｔｉｎｇ Ｄａｔａ Ｌｉｓｔｓ ｗｉｔｈ Ｄｙｎａｍｉｃ Ｃｕｓｔｏｍｉｚａｔｉｏｎ ａｎｄ Ａｄａｐｔａｔｉｏｎ」と題する米国特許公開第２０１４／０２８２２１８号に論じられる）、ならびにＷＢＳ構成可能アプリケーション（出願人によって共有され、参照によって本明細書に組み込まれる、２０１９年１１月１４日に出願された「Ｓｙｓｔｅｍ Ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｃｒｅａｔｉｏｎ ａｎｄ Ｈａｎｄｌｉｎｇ ｏｆ Ｃｏｎｆｉｇｕｒａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｗｅｂｓｉｔｅ Ｂｕｉｌｄｉｎｇ Ｓｙｓｔｅｍｓ」と題する米国特許公開第１６／６８３３８号に論じられる）、を用いて拡張され得る。これらのサードパーティアプリケーションおよびリストアプリケーションは、設計されたウェブサイトに追加および統合することができる。

そのようなサードパーティアプリケーションおよびリストアプリケーションは、アプリケーションストア（ＷＢＳのマーケットストアに統合されるか、または外部にある）から、またはサードパーティアプリケーションベンダから直接、ＷＢＳ設計環境に事前に含まれるなど、いくつかの配布メカニズムを介して購入（または取得）され得る。

サードパーティアプリケーションは、ＷＢＳベンダ独自のサーバ、サードパーティアプリケーションベンダのサーバ、またはフォースパーティのサーバインフラストラクチャでホストされる場合がある。

ＷＢＳはまた、手続きコードをシステムのエンティティの一部または全部に追加することを可能にしてもよい。このようなコードは、標準言語（ＪａｖａＳｃｒｉｐｔなど）、標準言語の拡張バージョン、または特定のＷＢＳ専用の言語で記述できる。実行されたコードは、ＷＢＳ自体または外部プロバイダによって提供されたＡＰＩを参照する場合がある。コードは、ページ、コンポーネント、その属性など、ＷＢＳの内部構造とオブジェクトを参照することもできる。

手続きコード要素は、イベントトリガを介してアクティブ化することができる。イベントトリガは、ユーザアクティビティ（マウスの移動やクリック、ページ遷移など）、他のユーザに関連するアクティビティ（基盤となるデータベースや、他のユーザによって更新される特定のデータベースレコードなど）、システムイベント、または他のタイプの条件に関連付けることができる。

アクティブ化されたコードは、ＷＢＳのクライアント要素内、サーバプラットフォーム上、または２つまたは動的に決定された実行プラットフォームの組み合わせを使用して実行することができる。そのようなシステムは、本出願人によって共有され、参照によって本明細書に組み込まれる、２０１８年１０月１１日に公開された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｓｍａｒｔ Ｉｎｔｅｒａｃｔｉｏｎ Ｂｅｔｗｅｅｎ Ｗｅｂｓｉｔｅ Ｃｏｍｐｏｎｅｎｔｓ」という名称の米国特許出願公開第２０１８／０２９３３２３号に記載されている。

典型的なサイトの作成は、視覚編集モデル（ユーザが以前に作成されたサイトを編集する）、自動サイト生成モデル、または図２に示されるそれらの組み合わせを含む、いくつかのモデルに基づくことができ、ここで参照され、出願人によって共有され、参照によって本明細書に組み込まれる、２０１８年９月１１日に付与された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ｔｈｅ Ｃｒｅａｔｉｏｎ ａｎｄ Ｕｐｄａｔｅ ｏｆ Ｈｉｅｒａｒｃｈｉｃａｌ Ｗｅｂｓｉｔｅｓ Ｂａｓｅｄ ｏｎ Ｃｏｌｌｅｃｔｅｄ Ｂｕｓｉｎｅｓｓ Ｋｎｏｗｌｅｄｇｅ」という名称の米国特許第１０，０７３，９２３号に記載されている。

本明細書全体を通して、頭字語におけるＷＢＳ（Website Building System）は、ウェブサイト構築システムを表すために使用されてもよいことが理解されるであろう。図２は、ＷＢＳベンダスタッフ６１、サイトデザイナ６２（すなわち、ユーザ）、サイトユーザ６３（すなわち、ユーザのユーザ）、および外部システム７０によって操作されるクライアントシステムと通信する典型的なＷＢＳ２を備えるシステム１００を示す。ＷＢＳ２は、ＷＢＳサイトマネージャ１０、オブジェクトマーケットプレイス１５、ＷＢＳ ＲＴ（Runtime）サーバ２０、ＷＢＳエディタ３０、サイトジェネレータシステム４０、およびＷＢＳコンテンツ管理システム（ＣＭＳ：Content Manegement System）５０をさらに備えることができる。図２の要素は、米国特許第１０，０７３，９２３号に記載されているように機能し得ることが理解されるであろう。

ビジュアル編集モデルでは、ユーザ（デザイナ）は１つ以上のウェブサイトテンプレートに基づいてサイトを編集する。ＷＢＳプロバイダは、複数のサイト（または他の）テンプレートを提供することができ、各テンプレートは、完全なサンプルウェブサイト、ウェブサイトセクション、シングルページまたはページのセクションを含む可能性がある。ユーザは、空のサイト（基本的には「空白ページ」テンプレート）から開始するオプションを持つことができるが、通常は実際のサイトテンプレートから開始する。

ＷＢＳプロバイダは、非常に一般的なもの（例えば、モバイルサイト、ｅストア）から、より具体的なもの（例えば、法律事務所、レストラン、花屋）まで、非常に具体的なもの（例えば、商業用不動産法律事務所またはスペイン語タパスレストラン）までの範囲のサイトテンプレートを提供することができる。そのようなテンプレートは、典型的には、ＷＢＳのユーザがアクセス可能なリポジトリに格納され、典型的には、ビジネスタイプ、サブタイプ、または業界に従って分類される。テンプレートは、ビジネスタイプだけでなく、スタイル、色範囲、または他のパラメータに従って作成（および分類）することもできる。サイトテンプレートは、ＷＢＳと統合された本格的な垂直ソリューションになるために、追加の（典型的にはバックエンド）機能、サービス、およびコードで拡張されてもよい。

したがって、ＷＢＳビジュアルエディタを使用してサイトを作成するときのユーザの最初のエクスペリエンスは、典型的には、ユーザがテンプレートを選択し（例えば、スタイルまたは産業タイプ／サブタイプに従って）、場合によっては空白のテンプレートを選択し、次いで、コンテンツ、ロジック、レイアウト、および属性の編集を含むビジュアルエディタでテンプレートを編集することであり得る。そのような編集は、（特に）テンプレートおよびその要素をユーザのビジネスの詳細に適合させることを含むことができる。その後、ユーザは変更されたサイトを公開することができる。

サイト生成モデルの下で、ＷＢＳは、選択されたテンプレートに基づいて、ユーザのための初期サイトを生成し、選択されたテンプレートは、場合によっては、情報の共通要素を穴埋めすることによって修正され、場合によっては、生成されたサイトのフォローアップ編集を可能にする。この穴埋めは、テンプレートのページ内の複数の場所に、さまざまな情報（ビジネス名や管理チームの説明など）が含まれているので、必要とされる。したがって、ユーザは、テンプレート全体の複数の場所でビジネス名（例えば）を変更しなければならない場合がある。

さらに、いくつかのテンプレート要素（例えば、一般的な製品ページ）が複数回現れてもよく、各インスタンスは、基盤となるエンティティ（例えば、サイトで提供される異なる製品）の異なるインスタンスの詳細を表示する。そのような複数のインスタンスは、手動で指定されてもよいし（例えば、会社の管理チームにおける異なる人物の詳細）、または外部データベース（例えば、「販売中の製品」データベースからの製品詳細）から動的に導出されてもよい。このような準備は、しばしば「リピータ」として知られている。

テンプレートにはフィールドを含めることもできる。例えば、ＷＢＳは、テンプレートデザイナが、｛ＣｏｍｐａｎｙＮａｍｅ｝、｛ＰｒｏｄｕｃｔＮａｍｅ｝、｛ＰｒｏｄｕｃｔＰｒｉｃｅ｝などのテンプレート内に値を挿入するためのフィールド（「プレースホルダ」とも呼ばれる）を指定することを可能にしてもよい。ユーザは、ウェブサイト用に選択されたテンプレートで定義されたフィールドの値を指定することもできる。

ＷＢＳは、ユーザが単純な値または複雑な値（例:テキストおよび画像）だけでなく、含まれるページまたはウェブサイト領域の選択、色、スタイル情報、リンク、書式設定オプション、ウェブサイト表示オプション、装飾要素（境界線や背景など）などの追加（非フィールド）情報も入力できるようにすることができる。

また、ＷＢＳは、テンプレートを選択する前に、ユーザがこの追加情報のいくつかを入力することを可能にし、この情報をテンプレートの選択に役立てる（例えば、提案されたテンプレートのセットを絞り込むことによって）。例えば、ユーザは、ある汎用カラースキーム（例えば、パステルカラー）またはスタイル（例えば、ビジネス／フォーマル）を選択することができ、次いで、システムは、この選択を使用して、提案されたテンプレートのセットを絞り込むことができる。

システムはまた、一連のビューまたはアンケートを表示して、ユーザが（定義されたフィールドおよび上記の追加情報の両方について）値または選択を入力できるようにしてもよい。システムは、さらに、テンプレートの複数インスタンス要素（本明細書で先に説明した）と、表示されたインスタンスを生成するために使用されるデータインスタンスを提供する内部または外部データベースとの間の接続（またはバインド）を作成することができる。

テンプレートが選択され、そのフィールドと追加情報が指定されると（例えば、アンケートを通じて、またはデータソースへのバインドを通じて）、ＷＢＳは、結合された情報を含むウェブサイトを生成することができる。次いで、ユーザは、（ＷＢＳまたはその他を介して）サイトを公開することができる。

ＷＢＳは、米国特許第１０，０７３，９２３号に記載されている別のモデルを使用して半自動サイト作成を実行することができる。このモデルの下で、システムは、複数のソースから、ユーザおよびユーザのウェブサイト要件に関する情報を収集する。複数のソースは、例えば、ユーザ記入アンケート、既存のユーザプレゼンス（既存のウェブサイトまたはソーシャルメディアプレゼンスなど）、業界ソース（一般取引ウェブサイトなど）、オフライン情報、および、特定の業種（弁護士、レストラン、配管工、グラフィックデザイナなど）の基本テンプレート情報などの特定の業種に関する情報を提供する、内部システムリポジトリ（例えば、不動産弁護士と人身傷害弁護士とを区別する）を含むことができる。

システムはまた、システムの内部および外部の両方で、他のサイトから外部情報を収集してもよい。そのような情報は、例えば、提供されたアンケートおよびレイアウト要素の選択、提案されたデフォルトなどに影響を及ぼし得る。そのような情報はまた、典型的には、任意の単一のユーザに属する情報を公開せず、ユーザのプライバシー、匿名性、および法的権利（著作権など）を保護するために、統計または要約ベースで収集されてもよい。そのような情報は、直接的（例えば、既存のウェブサイトアドレス）または間接的（ビジネスに関する情報を見つけるために使用され得るビジネス名および地理的アドレス）であり得る、ユーザによって提供される情報に基づいて見つけられ得る。

収集された情報は、分析され、コンテンツ要素のリポジトリに配置される。コンテンツ要素のリポジトリは、コンテンツ要素からコンテンツを提示するレイアウト要素にマッピングされ、レイアウト要素を組み合わせてサイトを形成する。レイアウト要素マッピング、選択、および組み合わせの処理は、完全自動または半自動（すなわち、ユーザ対話を含む）とすることができる。

上記の機能をサポートするために、ＷＢＳは、通常、１つ以上のサーバまたはサーバファーム上に格納された一連のリポジトリを維持する。このようなリポジトリは、典型的には、ユーザ情報／プロファイルリポジトリ、ＷＢＳ（ＷＢＳ）コンポーネントリポジトリ、ＷＢＳサイトリポジトリ、ビジネスインテリジェンス（ＢＩ：Business Intelligence）リポジトリ、編集履歴リポジトリ、サードパーティアプリケーションストアリポジトリなどの様々な関連リポジトリを含むことができる。システムはまた、アンケートタイプリポジトリ、コンテンツ要素タイプリポジトリ、レイアウト要素タイプリポジトリ、デザインキットリポジトリ、記入済みアンケートリポジトリ、コンテンツ要素リポジトリ、レイアウト要素リポジトリ、ルールリポジトリ、ファミリー／産業リポジトリなどのサイト／コンテンツ作成関連のリポジトリを含むことができる。これらのリポジトリの説明は、米国特許第１０，０７３，９２３号に見出すことができる。

ウェブデザインのための応答編集は、当技術分野で知られている。パーソナルコンピュータ、タブレット、およびモバイル通信デバイス（すべてが、異なる表示寸法を有する異なるスクリーンディスプレイおよびウインドウを有する）などの異なるサイズのビューポート上にウェブサイトを作成し、閲覧する時代に、応答編集は、様々なデバイスおよびウインドウまたはスクリーンサイズ上に単一のウェブページをレンダリングすることを可能にする。ウェブサイトは応答性であってもよく、すなわち、閲覧時にそれらのデザインを変更してもよく、応答エディタによってサポートされてもよいことが理解され得る。あるいは、いくつかのシステムは、応答エディタを使用せずに応答サイトの機能をサポートすることができる。したがって、コンテンツ、デザイン、および性能は、すべてのデバイスおよびプラットフォームにわたって維持され、ユーザビリティおよび満足を保証する。

応答編集に準拠するように設計されたサイトは、典型的には、ピクセルまたは点のような絶対単位ではなく、パーセンテージのような相対単位でページ要素のサイジングを可能にする比例ベースのグリッドのようなメカニズムを使用することによって、レイアウトをビューイング環境に適合させる。要素はページ上にドッキングされてもよく、ブレークポイントは、ウェブサイトページのコンテンツとデザインを、異なるビューポートサイズに適合するように非連続的な方法で適合させる必要があるポイントを指定するように定義されてもよい。ブレークポイントは、ウェブページが（連続的に設計を修正するのではなく）それに応じて異なるレイアウトまたはコンポーネントの配置を使用すべき特定の幅ポイントを定義する。

応答性のあるウェブサイト（閲覧および編集の両方のため）を実施する多くの方法がある。例えば、応答サイト挙動を実施することができる:

サーバ側で、たとえば、ページ定義を所定のターゲットデバイスまたは幅に合わせて事前処理または調整する。

クライアント側で、ＪａｖａＳｃｒｉｐｔ（またはその他のブラウザベースの言語） を使用して、ページ幅やその他のターゲット特性パラメータまたは変更を処理する。

クライアント側では、ＣＳＳ（Cascading Style Sheets）、またはその他のマークアップ、プレゼンテーション、スタイル定義言語を使用する。これらの言語は、装置、プラットフォーム、または表示情報のクエリを提供し、ターゲットデバイスまたは表示の特性に基づいて宣言型スタイル定義を作成する機能を提供する。このような宣言型の定義は、実行する外部コード（ＪａｖａＳｃｒｉｐｔコードなど）のレンダリングを必要とせずに、ブラウザのレンダリングエンジン内で実行できる。

ユーザが（自分のデバイスやディスプレイウィンドウを変更することによって）ビューポートの表示を変更すると、ウェブサイトは、解像度、ビューポートサイズ、スクリプト機能に対応するように、上記のいずれかの方法（またはその組み合わせ）によって自動的に切り替わる必要がある。

したがって、本発明の好ましい実施形態によれば、ウェブサイト構築システム（ＷＢＳ）およびその上で実施される方法が提供される。ＷＢＳは、プロセッサと、流動コンポーネント、複数のビューポートサイズ用のブレークポイント範囲、動的レイアウトルールおよび、ブレークポイント範囲に応じて流動コンポーネントを編集するための応答編集ルールを含むウェブサイトページおよびレイアウトを格納する少なくとも１つのデータベースと、プロセッサ上で実行される応答編集モジュールと、を有し、応答編集モジュールは、少なくとも１つの入力トリガに関連付けられた、動的レイアウトルールおよび応答編集ルールに応じてＷＢＳにより構築されるウェブサイトのページ用のレイアウト決定を提供するルールエンジンと、少なくとも１つの入力トリガおよび現在のビューポートの大きさを受信し、レイアウト決定に応じて現在のビューポート用の更新流動応答デザインレイアウトを生成する応答エディタと、更新流動応答デザインレイアウトのデザインの特徴を現在のビューポート用のスマートＣＳＳ（カスケードスタイルシート）にマッピングするＣＳＳジェネレータと、をさらに含む。

さらに、本発明の好ましい実施形態によれば、少なくとも１つのデータベースは、非流動コンポーネントを含むウェブサイトページおよびレイアウトも格納する。

さらに、本発明の好ましい実施形態によれば、システムは、非流動コンポーネントを有する静的ウェブサイトデザインにメッシュグリッドを適用し、応答エディタに用いる応答デザインに変換するスマートメッシュアプライヤをさらに有する。

さらに、本発明の好ましい実施形態に従って、システムは、レイアウト決定およびスマートメッシュアプライヤの少なくとも１つのためにＭＬ／ＡＩサポートを提供するよう訓練された機械学習（ＭＬ：Machine Learning）／人工知能（ＡＩ：Artificial Intelligence）エンジンをさらに有する。

さらに、本発明の好ましい実施形態によれば、ＭＬ／ＡＩエンジンは、少なくとも１つの機械学習フィードバックモジュールを含む。

さらに、本発明の好ましい実施形態に従って、応答エディタは、少なくとも１つの入力トリガを受信する編集レシーバと、少なくとも１つの入力トリガおよび現在のビューポートの大きさに応じてコンポーネントに対するページの変更を定義する編集ハンドラと、現在のビューポート用のブレークポイント範囲内における異なるブレークポイントでユーザにレイアウトをプレビューすることを可能にするプレビューワと、をさらに含む。

さらに、本発明の好ましい実施形態によれば、応答エディタは、編集ハンドラによる所定のアクションにおいてユーザに説明を提供し、ＭＬ／ＡＩエンジンに応じた編集においてユーザに解決策または提案を提示するエクスプレーナおよびサジェスタをさらに有する。

さらに、本発明の好ましい実施形態によれば、編集ハンドラは、応答編集ルールと、少なくとも１つの入力トリガ用の前記動的レイアウトルールとの間のコンフリクトを処理するＤＬ（動的レイアウト）ハンドラと、現在のビューポイントの大きさに応じてコンポーネントのレイアウトを配置するレイアウトハンドラと、現在のビューポイントの大きさに応じた、最小所定値と最大所定値との間で、コンポーネントのテキストポイントサイズをスケールするテキストスケーラと、ブレークポイント範囲におけるコンポーネントの隠蔽および非隠蔽を管理する可視性ハンドラと、少なくとも１つの入力トリガに基づいてコンポーネント属性変更を処理し、それに応じてレイアウトデザインにコンポーネントを適用するコンポーネントハンドラと、与えられた幅の範囲または特定のブレークポイントにおけるコンポーネントのユーザセレクション用のアニメーションを生成するアニメータと、少なくとも１つの入力トリガに応じてページに、プリセットおよびパネルを追加する追加パネルハンドラと、コンポーネントを、少なくとも１つの入力トリガの結果として、これの包含コンポーネント内の応答編集グリッド配置にドッキングするコンポーネントドッカーと、少なくとも１つの入力トリガに応じたコンポーネントハンドラの出力に応じて包含コンポーネントの応答編集グリッドを調整するグリッドハンドラと、グループ定義の階層設定に応じてレイアウト決定におけるコンポーネントをグループ化するコンポーネントグルーパと、の少なくとも１つを含む。

さらに、本発明の好ましい実施形態によれば、ＭＬ／ＡＩエンジンは、編集および保存中の応答エディタにおける絶対的なレイアウト定義を解析し、ユーザの意図を検出し、ユーザの意図をルールの宣言設定に変換する。

さらに、本発明の好ましい実施形態によれば、エクスプレーナ（explainer）およびサジェスタ（suggester）は、ユーザの意図に応じて次の移動を提案するネクストムーブサジェスタ（ｎｅｘｔ ｍｏｖｅ ｓｕｇｇｅｓｔｅｒ）を有する。

さらに、本発明の好ましい実施形態によれば、入力トリガは、ユーザ編集、システム変更、デバイスタイプの変更、ユーザプロパティ、ユーザ／デバイス相互作用変更、第２のユーザによる同時編集、システムの手続き変更およびユーザ環境の変更の少なくとも１つである。

さらに、本発明の好ましい実施形態によれば、スマートメッシュアプライヤ（applier）は、非流動コンポーネントを有する入力ページを受信するページレシーバと、入力動的レイアウトトリガ用のクラスを認識するトリガハンドラと、入力ページのコンポーネントの構成および関係を解析するページアナライザと、解析およびクラスに応じて入力ページをメッシュグリッドに変換し、ＣＳＳジェネレータにおけるＣＳＳ定義を生成するページコンバータと、を有する。

加えて、本発明の好ましい実施形態によれば、ページコンバータは、水平スプリッタを使用して暗黙の動的レイアウトアンカーを置換するスプリッタプレイサ（placer）と、スプリッタプレイサの出力に従ってメッシュグリッドを生成するメッシュグリッドジェネレータとを含む。

更に、本発明の好ましい実施形態によれば、メッシュグリッドジェネレータは、必要に応じて、メッシュグリッド上のコンポーネントを支持するための追加のグリッド空間を作り出す追加の不可視行を加える追加行ジェネレータと、メッシュグリッド内にウェッジ（wedge）要素を実装するためのウェッジジェネレータとを含む。

さらに、本発明の好ましい実施形態によれば、現在のビューポートは、複数のディスプレイを含む。

さらに、本発明の好ましい実施形態によれば、クラスは、処理されたＪａｖａｓｃｒｉｐｔ、処理されたブラウザエンジンおよびベースとなるグリッド生成のうちの１つである。

さらに、本発明の好ましい実施形態によれば、応答エディタは、流動コンポーネント、ブレークポイントサポートおよびスマートメッシュを組み合わせるレイアウトデザインを編集するドラッグアンドドロップをサポートする。

さらに、本発明の好ましい実施形態によれば、解析は、動的レイアウトルール、コンポーネントプロパティ、コンテンツ、コンポーネントの編集履歴、関連ビジネス情報およびコンポーネントグループ認識の少なくとも１つに従う。

したがって、本発明の好ましい実施形態によれば、ウェブサイト構築システム（ＷＢＳ）およびその上で実施される方法が提供される。ＷＢＳは、プロセッサと、少なくとも１つのレイアウトを有し、非流動コンポーネントを含むウェブサイトページを格納するデータベースと、プロセッサ上で実行されるメッシュアプライヤとを含み、メッシュアプライヤは、入力ページを受信するページレシーバと、入力ページのコンポーネントの構成および関係を解析するページアナライザと、入力ページを解析に従ってスマートメッシュアーキテクチャに変換して、スマートカスケードスタイルシート（ＣＳＳ）定義を生成するページコンバータとを含み、スマートメッシュアーキテクチャは、入力ページのコンポーネントの応答ビューイングをサポートし、入力ページのコンポーネントは、他のコンポーネントおよび外部トリガによって影響を受ける。

本発明と見なされる主題事項は、本明細書の最後の部分において特に指摘され、明確に特許請求される。しかしながら、本発明は、その目的、特徴、および利点と共に、構成および動作方法の両方に関して、添付の図面と共に読まれるときに、以下の詳細な説明を参照することによって最も良く理解され得る。
ウェブサイトを構築するために使用され得るウェブサイト構築システムの構成の概略ブロック図である。 従来技術のウェブサイト構築システムの要素の概略図である。 本発明の一実施形態に従って構築され、動作する、応答エディタモジュールを使用するウェブサイトの作成、閲覧、および編集の概略図である。 本発明の一実施形態に従って構成され、動作する、図３の応答編集モジュールの要素の概略図である。 本発明の一実施形態に従って構成され、動作する、図４の応答エディタの要素の概略図である。 所与のソースブレークポイント定義を有するコンポーネントが、新しいターゲットブレークポイント定義を有するページまたはコンテナに適用され得る方法の概略図である。 所与のソースブレークポイント定義を有するコンポーネントが、新しいターゲットブレークポイント定義を有するページまたはコンテナに適用され得る方法の概略図である。 所与のソースブレークポイント定義を有するコンポーネントが、新しいターゲットブレークポイント定義を有するページまたはコンテナに適用され得る方法の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の実施形態に従って構築され、動作する、サイトレイアウト上のサイト幅変化の概略図である。 本発明の一実施形態に従って構成され動作する、図５の編集ハンドラの要素の概略図である。 テキストがスケーラブルでない場合のサイト幅の変化の概略図である。 テキストがスケーラブルでない場合のサイト幅の変化の概略図である。 テキストがスケーラブルでない場合のサイト幅の変化の概略図である。 テキストがスケーラブルでない場合のサイト幅の変化の概略図である。 テキストがスケーラブルでない場合のサイト幅の変化の概略図である。 本発明の実施形態に従って構成され、動作する、ブレッドクラムディスプレイのためのセクションの使用およびコンポーネントの選択の概略図である。 本発明の実施形態に従って構成され、動作する、ブレッドクラムディスプレイのためのセクションの使用およびコンポーネントの選択の概略図である。 本発明の一実施形態に従って構成され、動作する、様々な要素タイプのための追加メニューの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、様々な要素タイプのための追加メニューの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、様々な要素タイプのための追加メニューの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、ドラッグアンドドロップ編集のためのスペースの作成／クローズの使用の概略図である。 本発明の実施形態に従って構成され、動作する、複数のブレークポイント範囲にわたるデザイン統一のためのユーザインターフェースの概略図である。 本発明の実施形態に従って構成され、動作する、複数のブレークポイント範囲にわたるデザイン統一のためのユーザインターフェースの概略図である。 本発明の一実施形態に従って構成され、動作するスタックコンポーネントの概略図である。 本発明の一実施形態に従って構成され、動作するレイアウタコンポーネントおよびその可能な配置の概略図である。 本発明の一実施形態に従って構成され、動作するレイアウタコンポーネントおよびその可能な配置の概略図である。 本発明の一実施形態に従って構成され、動作する、リピータの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、リピータの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、リピータの使用の概略図である。 本発明の一実施形態に従って構成され動作する、応答編集グリッドの使用の概略図である。 本発明の一実施形態に従って構成され動作する、応答編集グリッドの使用の概略図である。 本発明の一実施形態に従って構成され動作する、応答編集グリッドの使用の概略図である。 本発明の一実施形態に従って構成され動作する、応答編集グリッドの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、応答編集グリッド背景を使用するクロッピングプロセスの概略図である。 本発明の一実施形態に従い、デザイン推奨を含んだシナリオの概略図である。 本発明の一実施形態に従い、デザイン推奨を含んだシナリオの概略図である。 本発明の実施形態に従って構成され、動作する、図４のＭＬ／ＡＩエンジンによって使用される複数の機械学習モデルの使用の概略図である。 本発明の実施形態に従って構成され、動作する、図４のＭＬ／ＡＩエンジンによって使用される複数の機械学習モデルの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、図４のメッシュアプライヤの要素の概略図である。 本発明の一実施形態に従って構成され、動作する、図２１のページコンバータの要素の概略図である。 本発明の実施形態に従って構成され、動作する、コンポーネントとスプリッタとの間の関係の概略図である。 本発明の実施形態に従って構成され、動作する、コンポーネント間のプッシング関係の隔離の概略図である。 本発明の実施形態に従って構成され、動作する、コンポーネント間のプッシング関係の隔離の概略図である。 本発明の実施形態に従って構成され、動作する、スプリッタおよびコンポーネントへのＣＳＳグリッドルールの出願の概略図である。 本発明の一実施形態に従って構成され、動作する、コンポーネント距離および結果として生じるドッキング効果の概略図である。 本発明の一実施形態に従って構築され、動作する、アンカーを使用するコンポーネント間のプッシングシナリオを取り扱う概略図である。 本発明の一実施形態に従って構築され、動作する、アンカーを使用するコンポーネント間のプッシングシナリオを取り扱う概略図である。 本発明の一実施形態に従って構成され、動作する、要素レイアウトを維持するための追加ラインの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、要素レイアウトを維持するための追加ラインの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、要素レイアウトを維持するための追加ラインの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、コンポーネントレイアウトを維持するためのウェッジの使用の概略図である。 本発明の一実施形態に従って構成され、動作する、離れたコンポーネント間の明示的コンポーネントの使用の概略図である。

説明を簡単かつ明確にするために、図に示される要素は必ずしも一定の縮尺で描かれていないことが理解されるであろう。例えば、いくつかの要素の寸法は、明確にするために、他の要素に対して誇張されていることがある。さらに、適切であると考えられる場合、参照番号は、対応するまたは類似の要素を示すために、図面の間で繰り返され得る。

以下の詳細な説明では、本発明の完全な理解を提供するために多くの具体的な詳細について述べる。しかしながら、当業者には、本発明がこれらの特定の詳細なしに実施され得ることが理解されるであろう。他の例では、周知の方法、手順、およびコンポーネントは、本発明を曖昧にしないように詳細には説明されていない。

従来技術の応答性編集システムは、通常、ウェブサイトまたはページレベルで作動し、ウェブサイトのサイズを調整するための予め定義された固定ブレークポイントを有し、限られた数のビューポート（画面、ディスプレイおよびウインドウを含む）で応答性の高い編集を可能にする。（サイズまたは位置を変更するコンポーネントのように）サイトが変更されるとき、その変更は、（単一のブレークポイント範囲内の）ブレークポイント間で連続的であることが理解され得る。ブレークポイントが交差すると、非連続的な変化が起こり、コンポーネントが１つの位置から別の位置にジャンプすることがある（例えば、スクリーン幅が収縮するとき、コンポーネントＡがコンポーネントＢの上を並べて移動することがある）。コンポーネントもまた、ブレークポイントが交差するときに現れ、消えることがある。

ウェブデザイナが自分のブレークポイントを完全に制御する、すなわち自分自身のレンジを定義することができる場合、ブレークポイント範囲のサイズを連続的に処理することができ、より広い範囲のビューポートにわたって自分のウェブサイトを表示するためにデザインを変更することによって処理されるという知識をもってウェブサイトを効果的にデザインすることができることに本出願人は見出した。これにより、ユーザは、複数サイズのサイトをより効果的に作成し、処理することができる。

さらに、階層コンポーネントベースのシステムに適した応答エディタ、すなわちコンポーネントレベルでのハンドル機能が、ブレークポイントが、任意の実装された階層とともに、ページレベルだけでなく、プリセットレベルおよびコンテナレベルでも（たとえば、そのサブ要素のドッキングのためにコンテナコンポーネントレベルで応答編集グリッドを使用して）処理され得ることを保証し得ることを本出願人は見出した。したがって、デザイナが自分自身のブレークポイント範囲を定義する能力は、画像の使用を「バックグラウンド」から「フローティング」に切り替えること、複数の焦点（各ブレークポイントごとに１つ）を適用する能力、およびブレークポイント範囲ごとに異なるクロッピングパラメータを提供する能力など、デザイナに自分のメディアに対する完全な制御を与えることができる。

応答編集コンポーネントが流動であると考えられ、したがって、ウェブサイト編集中に発生する可能性のある動的レイアウトトリガおよびイベントに応答することができることを、本出願人はさらに見出した。レイアウトは、そのサイズおよび属性が親によって（例えば、親の変更またはビューポート幅の変更によって）または追加のトリガによって影響され得る流動コンポーネントを組み込み得る。効果は、システムによって自動的に決定することができ、ユーザによって指定または編集することもできる（例えば、コンポーネント幅は、親コンポーネント幅の所与のパーセンテージまたは関数である）。

ユーザのレイアウトをすべてのブレークポイントに最も良く適合するように自動的に適合させるためにユーザがどのように機能するかを理解する等、ユーザ作業の態様を容易にするための機械学習（ＭＬ）および人工知能（ＡＩ）技術およびモデルの使用が、本明細書で上述した応答編集システムに統合されてもよいことを、本出願人はまた見出した。これは、ユーザの意図を理解し、検出することによってセクションおよびコンポーネントを提供するシステムを含むことができる。本システムは、ＷＢＳにおいて利用可能な情報、例えば、ウェブサイトコンポーネント情報、ビジネス情報、編集履歴、および他のサイト関連情報、ならびに、本出願人によって共有され、参照によって本明細書に組み込まれる、２０２０年５月２０日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｉｎｔｅｇｒａｔｉｎｇ Ｕｓｅｒ Ｆｅｅｄｂａｃｋ ｉｎｔｏ Ｗｅｂｓｉｔｅ Ｂｕｉｌｄｉｎｇ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅｓ」という名称の米国特許出願第１６／８７８，８３１号に記載されているようなＷＢＳベースのトレーニングフィードバックを使用して、いくつかのＭＬ／ＡＩエンジンを使用して、その目標を達成し得る。

本出願人はさらに、ルールベースおよびＭＬ／ＡＩエンジンのアプリケーションを使用して、システムがドラッグアンドドロップデザインをフルＣＳＳに変換し、ブレークポイントの最良適合位置を理解する完全なデザイン表現能力を提供することもできることを見出した。これは、応答デザインおよび流動コンポーネントをサポートし、ターゲットデザインのブレークポイントにさらに適応することができるパッケージ化されたレイアウトも含むことができる。

したがって、応答編集機能を、背景技術で説明したウェブサイト構築システムのプロセスと組み合わせることができ、説明したレイアウト要素を、応答サイトを構築するために適合させることができる。

さらに、出願人はまた、上述の機能性が、既存の応答しないウェブサイト（すなわち、ブレークポイントのないウェブサイト）が、ウェブブラウザおよび他のクライアントシステム上で効率的に実装され得るスマートメッシュ形式に変換またはレンダリングされる場合、それらにも適用され得ることを見出した。この能力は、既存のＷＢＳサイト、または他のシステムからインポートされたサイトに適用することができる。したがって、スマートメッシュ構造は、（応答性および流動性を有する）サイトを宣言的に定義するために使用することができる。このようにして、ブラウザは、（例として）ブラウザエンジン内部の幅の変化に応答してもよい（例えば、ＣＳＳ処理および表示レンダリングの一部として）。このプロセスは、グループ検出およびアンカー生成などのＷＢＳコンポーネントプロパティ（幾何学的／非幾何学的）および蓄積された情報（編集履歴および収集されたＢＩなど）タスクの解析に基づいて、効果的な動的レイアウト操作のための推論および解析を提供することができる。

図３を参照すると、本発明の実施形態に従って構成され、動作する応答エディタモジュールを使用して、ウェブサイトの作成、閲覧、および編集のためのシステム２００が示される。システム２００は、応答編集モジュール３００と共に、米国特許第１０，０７３，９２３号に記載されているようなシステム１００の要素（並びに任意のサブ要素）を含むことができる。代替実施形態では、システム２００は、ＷＢＳエディタ３０、サイト生成システム４０、および応答編集モジュール３００の機能を組み合わせる統合モジュール、またはＷＢＳエディタ３０の機能と応答編集モジュール３００のみを組み合わせるモジュールを提供することができる。

以下の議論は、システム２００が特定のクライアントソフトウェアを使用してアクセスされる他のカテゴリのオンライン・アプリケーションに完全に適用可能であるが、ＷＢＳによって作成され、エンドユーザによってウェブサイトとしてアクセスされるアプリケーションを指すことが理解され得る。このようなクライアントソフトウェアは、スタンドアロンで実行することも、ブラウザ（Ａｄｏｂｅ Ｆｌａｓｈプラグインなど）からアクティブ化することもできる。エンドユーザは、通常のＰＣ上のクライアントソフトウェア（図２に示したように、現在参照されている）だけでなく、スマートフォン、タブレットコンピュータ、その他のデスクトップ、モバイル、またはウェアラブルデバイス上でも、これらのウェブサイトにアクセスすることができる。あるいは、本明細書の記載は、２０１８年６月１２日に付与され、出願人が共有し、参照により本明細書に組み込まれる「コンポーネントの階層に基づく意味的構成に関連する視覚的データ構造を生成するための視覚的設計システム」と題する米国特許第９，９９６，５６６号に記載されているように、モバイルアプリケーション、ネイティブアプリケーション、または他のアプリケーションタイプを生成または編集するシステムに適用することができる。

さらに、以下の議論は、（システム２００を実施する）ウェブサイト構築システムプロバイダによってホストされるウェブサイトに焦点を当てる。しかしながら、システム２００は、追加タイプのウェブサイトおよび他の非ウェブデジタル作成物を用いて実装されてもよい。これらには、例えば、以下のもの（またはこれらの任意の組み合わせ）が含まれる。フルウェブサイトおよびウェブサイトセクション（例えば、ウェブサイトのページのサブセット）または１つ以上のウェブサイトページのセクション、通常のデスクトップコンピュータ閲覧用にデザインされたウェブサイト、モバイルウェブサイトおよびタブレット指向ウェブサイト、ならびにウェブサイト構築システムによって作成されたが外部でホストされたウェブサイト（すなわち、ウェブサイト構築システムベンダーによってではない）。それらはさらに、ユーザのマシン上にインストールされたローカルサーバ上でローカルに実行されるウェブサイト、ＵＩとして働き、他のシステム（埋め込みシステムおよび機器を含む）内でホストされるウェブサイト、ならびに他のタイプのウェブサイトおよび他の非ウェブデジタル作成物を含むことができ、それらはまた、（例えば）ソーシャルネットワーク（Ｆａｃｅｂｏｏｋ（登録商標）など）内でホストされるページ、ブログ、ポータル（ＹｏｕＴｕｂｅ（登録商標）チャネルなどのユーザカスタマイズ可能なページをサポートするビデオポータルおよびオーディオポータルを含む）などを含む、より大きなシステム内でホストされるウェブサイトまたは他の表示されたビジュアルコンポジションを含むことができる。これは、ウェブサイトとみなされない他のタイプの遠隔アクセス可能なオンラインプレゼンスを含むことができる。

他のタイプのウェブサイトおよび他の非ウェブデジタル作成物はまた、ハイブリッドアプリケーション（ローカルにインストールされた要素をリモートリーブされた要素と組み合わせる）、および電子メール、ニュースレター、および他のデジタルドキュメントなどの非対話型デジタル作成物を含む、対話型（モバイルまたは他の）アプリケーションを含み得る。

次に、応答編集モジュール３００の要素を示す図４を参照する。モジュール３００は、応答エディタ３１０と、ＣＳＳジェネレータ３２０と、メッシュアプライヤ３３０と、ルールエンジン３４０と、ＭＬ／ＡＩエンジン３５０とをさらに備えることができる。応答エディタ３１０は、ユーザが応答ウェブサイト（ブレークポイントの範囲を指定することを含む）を作成および編集することを可能にすることができ、ルールエンジン３４０およびＭＬ／ＡＩエンジン３５０からの機能を使用することができる。ＣＳＳジェネレータ３２０は、編集変更の結果としてスマートＣＳＳを生成することができ、メッシュアプライヤ３００を使用して、非応答ウェブサイトを、応答ターゲット表示変更であるグリッドを有する応答ウェブサイトに変換することができる。編集の結果として作成された更新されたＣＳＳは、ＣＳＳとして、またはそれを表すデータ構造としてＣＭＳ５０に保存することができることが理解され得る。ＣＳＳジェネレータ３２０は、この定義を採用し、それに応じてスマートＣＳＳを生成することができる。これらの要素の機能については、以下でより詳細に説明する。

非ブラウザベースのシステム上に実装される場合、システム２００は、下層のシステムレンダリングまたは表示フレームワークと統合されたシステムのいくつかの要素を有することを含めて、異なる方法で実装されてもよいことが理解され得る。これは、基盤となるシステムのサーバ、クライアント、その他の要素またはプラットフォームで行うことができる。

次に、応答エディタ３１０の要素を示す図５を参照する。応答エディタ３１０は、ユーザと対話するために標準編集ＵＩを提供する通常のエディタとして機能し得ることが理解され得る。応答エディタ３１０は、さらに、編集レシーバ３１０１、編集ハンドラ３１０２、プレビューワ３１０５、エクスプレーナおよびサジェスタ３１０４を含むことができる。これらの要素の機能は、以下でより詳細に説明される。エクスプレーナおよびサジェスタ３１０４は、ネクストムーブサジェスタ３１０４１をさらに含むことができる。

編集レシーバ３１０１は、（システムおよびユーザの両方から）入力イベントまたはトリガを受信することができる。編集ハンドラ３１０２は、編集の必要な取り扱いを決定してもよく、プレビューワ３１０５は、編集のアプリケーションのＷＹＳＩＷＹＧプレビューを提供してもよく、エクスプレーナおよびサジェスタ３１０４は、与えられたアクションのユーザに説明を提供し、ユーザに解決策または提案を提供してもよい。これらの要素の機能は、以下でより詳細に説明される。

本明細書で上述したように、システム２００は、１つ以上のサイト変数またはパラメータ（本明細書では「影響変数」）への変更に基づいて変更することができるレイアウトに基づいて応答サイトを実施する。一例は、サイトのウインドウ又は表示幅の変化に応じたレイアウト変更（例えば、レイアウトの伸張又は圧縮）である。

応答編集モジュール３００は、ユーザが、幅値ブレークポイントを定義し、異なるビューポートに関連付けられたディスプレイのブレークポイント範囲を一致させることを可能にすることができる（スマートフォン画面では３２０～７５０ピクセル、タブレット画面では７５０～１０００ピクセル、デスクトップ画面では１０００ピクセル以上など）。

また、システム２００は、電子掲示板システム（または以下でより詳細に説明するマルチスクリーンアプリケーション）で使用される非常に大型のディスプレイ、ならびに非常に小型のもの（スマートウォッチまたはウェアラブルデバイススクリーンなど）など、通常のデスクトップスクリーンよりも大きい追加のフォームファクタをサポートすることもできる。したがって、より低い解像度およびより高い解像度の両方に対する変形を有するデスクトップ解像度のためにウェブサイトまたはアプリケーションを構築することができる。

表示サイトの幅が単一のブレークポイント範囲内で変化する場合、レイアウトは連続的または半連続的に変化し得ることが理解され得る。ブレークポイントが交差すると、レイアウトは、（以下でさらに説明するように）非連続的に変化し、コンポーネントは、それらの位置、サイズ、可視性、または他の属性を変化させることができる。このプロセスは、カスケーディングとして知られている。

以下でより詳細に論じるように、システム２００は、追加の影響変数（サイトの表示高さの変化など）または複数のそのようなパラメータの組合せを実装することができる。変数には、プラットフォームタイプなど、サイズ以外のその他の情報も含めることができる。

さらに、影響変数は、単一のパラメータ（またはそれらの組み合わせ）ではなく、むしろ複数のパラメータの関数であってもよい。例えば、システム２００は、（ディスプレイの幅及び高さの関数である）ディスプレイのアスペクト比に基づいて異なるレイアウトを定義することを可能にすることができる。

本明細書で上述したように、レイアウトは、そのサイズおよび属性が、それらの親によって（例えば、親の変更またはビューポート幅の変更によって）、または本明細書で以下でより詳細に説明する追加のトリガによって影響され得る流動コンポーネントを組み込むことができる。これらの効果は、編集ハンドラ３１０２によって自動的に決定されるか、またはユーザによって指定または編集され得る（例えば、コンポーネント幅は、親コンポーネント幅の所定のパーセンテージまたは関数である）かのいずれかであることが理解され得る。そのような流動性は、全コンポーネントレベルであってもよいが、コンポーネントの特定のサブ要素（例えば、列の幅が全コンポーネントの幅に基づく公式として指定されてもよい多列レイアウトコンポーネント）にも適用されてもよい。

システム２００は、以下でさらに説明するように、サイト内またはサイトに発生する追加のイベントおよび応答トリガに応答して、動的レイアウト技法および他のレイアウト変更をさらに適用することができる。

本明細書で上述したように、モジュール３００は、ウェブサイトレベル、個々のページレベル、セクションレベル毎、および特定のコンテナレベル毎（スクリーンワイドコンテナまたは他のコンテナを含む）を含むいくつかのレベルでブレークポイント定義を行うことを可能にすることができる。

モジュール３００はまた、継承ベースのブレークポイント定義、例えば、サイトレベルのブレークポイントセットを定義し、ページおよび／またはセクションが独自のバリアントを作成することを可能にしてもよい。

本明細書で上述したようなコンポーネントの流動性は、サイズ変化または他の影響を及ぼす可変変化に応じて適応するそれらの能力に起因し得ることが理解され得る。各コンポーネントまたはレイアウトは、それに応じてルールエンジン３４０によって処理されるそれ自体の処理ルールを有することができる。これらのルールは、ＣＭＳ５０に記憶されてもよい。適応するこの能力は、メッシュアプライヤ３３０に関連して以下でより詳細に説明するように、コンポーネントがコンテナおよび階層内で移動することを可能にする、レイアウト、スプリッタ、およびウェッジなどの応答編集グリッドおよび要素の適用とともに、予め定義された処理ルールの適用によるものであってもよいことが理解され得る。

処理ルールは、自動ドッキング（ドラッグされたときのコンポーネントのアライメントおよびマージンを変更する）、再パレンティング（reparenting）時のサイズ変換、ユニットを変更するときのサイズ変換、要素のドラッグおよびサイズ変更（グリッド領域、サイズおよびマージンを更新する）、グリッドオーバコンテンツの適用（グリッド領域、サイズおよびマージンを更新する）、グリッド行または列の削除、グリッド全体の削除、最小値および最大値のサイズ変更、レイアウタ（layouter）またはリピータの表示の変更などの編集手順に影響を及ぼすことがあることが理解され得る。

他のルールは、コンポーネントを下位ブレークポイント上の存在しないセルにドラッグすること（そのグリッド領域をビューポート内に残るように更新すること）、スタックを作成すること、スタックをアンスタックすること、アライメントを変更すること、ドッキングおよびマージンを広げるおよび広げないこと、セクションを追加、除去およびフリップすること（ページおよびセクショングリッドを更新すること）、およびセクションを水平から垂直にフリップすること（コンポーネントのサイズおよび位置を更新すること）を含むことができる。

ここで、所与のソースブレークポイント定義を有するコンポーネントが、新しいターゲットブレークポイント定義を有するページまたはコンテナにどのように適用され得るかの例を示す図６Ａ～Ｃを参照する。これは、あるページから別のページにセクションをコピーする場合（ページのブレークポイント定義が異なる場合）、プリセットを使用する場合（プリセットに付属しているデフォルトのブレークポイント範囲とは異なるブレークポイント範囲をユーザが定義する場合）、共有部分（複数のページにわたって継承によって共有される共通要素）などのシナリオに関連することがある。これには、共有部分を切り離し、ページブレークポイントに戻り、要素をページから共有ブロックに、またはその逆に移動することが含まれる場合がある。図６Ａでは、ターゲットブレークポイントは、ソースブレークポイントよりも数が少ない。このシナリオでは、ソースブレークポイントの１つがドロップされる。図６Ｂでは、ターゲットは１つのブレークポイントのみを有する。したがって、最後のブレークポイントは無限大（最大値なし）に定義されるため、カバレッジはデスクトップ上で最高になる。図６Ｃでは、ターゲットは、ソースよりも多くのブレークポイントを有し、したがって、ターゲットブレークポイントは、ソースブレークポイントに含まれてもよいし、それらの間に含まれてもよい。マッピングを定義するために、最上位のオーバーラップを選択することができる。

応答編集モジュール３００はまた、応答デザイン、流動性、および動的レイアウトをサポートする生成されたサイトの編集、公開、および実行をサポートするために、ドラッグアンドドロップ編集、ならびに以下に記載されるような複数の他の能力を提供し得ることが理解される。

さらに、システム２００は、実行時（サイトの閲覧）の間、ならびに編集（サイトを編集するためにＷＹＳＩＷＹＧモードで作業するとき、またはエディタ３１０内のプレビューモードで作業するとき）の間に、応答性のあるデザイン、流動性、および動的レイアウト能力を提供時間ことが理解され得る。また、保存、プレビュー、公開の各段階で機能を提供することもできる。

システム２００は、応答デザイン、流動性、および動的レイアウトに特有のサイトテンプレートを提供することもできる。ユーザは、このようなテンプレートを用いてサイトを作成し、編集することができる。

モジュール３００はまた、後述するコンテキスト追加パネルおよび次の移動提案などの、標準的なウェブサイト構築システム手順に追加の機能を提供することができることを理解され得る。このような機能により、編集時間が短縮され、使いやすさが向上する可能性がある（ユーザが選択できるオプションが少なくなったり、フォーカスされたオプションが増えたりするため）。

モジュール３００はまた、既存のレイアウトのための異なるブレークポイント、ならびにサイトの探索および性能のための最適化のために、エクスプレーナおよびサジェスタ３１０４を介したレイアウト提案などの能力を提供し得る。これらにより、ユーザは、よりパフォーマンスが良く、より専門的にデザインされたサイトを作成することができる。

本明細書で上述したように、本説明は、ウェブサイトレイアウトが、表示されるサイト幅の変更によって影響を受けるシステム２００の実施形態に焦点を当てる。しかしながら、システム２００は、変更およびトリガを含む他の影響を受ける変数に起因して、サイトの属性およびレイアウトを修正するように適応されてもよい。これらには、幅、高さ、方向、表示ビューポートプロパティの変更（ビューポートの幅または高さが変更された場合）、エディタ内のサイト表示サブエリアの変更などのデバイスプロパティの変更が含まれるが、これらに限定されるわけではない。これは、例えば、応答エディタ３１０がエディタ領域の可変サブ領域であるサイト表示領域を有する場合に発生する。応答エディタ３１０は、この領域を編集ユーザがサイズ変更できるようにすることができ（図７Ａ～７Ｇに示されているように、現在参照されている）、このサイズ変更に基づいてサイトレイアウトを変更することができる。図７Ａ～７Ｇの詳細な説明は、以下でより詳細に提供される。

他のトリガおよび変更は、コンポーネントに対するユーザ編集および修正、それらの属性およびそれらのレイアウト、デバイスタイプに対する変更（例えば、異なる解像度を有するデバイス）、地理（位置）に対する変更などのユーザプロパティに対する変更、ユーザに関連するユーザアイデンティティまたは他の特定の属性、ならびに照明レベルに対する変更（昼／夜、屋内／屋外）などの環境プロパティに対する変更を含むことができる。

別のトリガは、対話プロパティに対する変更、例えば、ユーザと画面との間の距離の変更（ユーザが画面を見る方法に影響を及ぼす）であってもよい。したがって、サイトは、ユーザがそれをある距離から見ている（したがって、「事実上より小さい」スクリーン上でサイトを見ている）ときを検出し、そのサイトをその遠くの見ているものに適応させ、おそらくサイトレイアウトを変更し、より大きいフォントサイズを使用することができる。その後、ユーザが画面に近づくと、サイトが変わることがある。ユーザの距離は、システムに利用可能な任意のセンサによって（例えば）測定されてもよく、または、システムに利用可能なビデオカメラ出力の分析によってもよい。これはまた、複数のビューワを最もよく表す距離（例えば、平均距離）を最適化することによって、複数の閲覧ユーザ（例えば、公共設定）で機能することができる。

本明細書で上述した様々なトリガおよび変更は、いくつかの方法で行うことができることを理解され得る。トリガまたは変更が静的である場合、サイトは、所与のパラメータ（例えば、所与のデバイス、解像度、幅、または高さ）で開かれる。このようなシナリオでは、システム２００は、様々な影響を与える変数に基づいてサイトを構成することができ、この構成は、セッションの間、一定のままであってもよい。

トリガは別個のものであってもよく、例えば、サイトは（所与の幅を使用して）ポートレートモードで、モバイルデバイス上で開かれ、ユーザは（より大きな幅を有する）ランドスケープモードへ、およびランドスケープモードから切り替わる。

トリガは連続的であってもよく、例えば、サイトは所定の幅を有するウインドウで開かれ、ユーザはこのウインドウ幅を（編集中または表示中に）変化させる。モジュール３００は、これらの変化に連続的に応答し、現在の幅（または他の影響変数）に常に適応するようにサイトを修正することができる。

トリガは、非ユーザである可能性もある。すなわち、サイトは、システム手続きの変更のようなユーザの行動に直接基づかない変更の影響を受ける。これは、例えば、（本明細書で上述したようである）影響変数に対する任意の他の変更によるものであり得る。これはまた、ユーザが、サイトのこのような同時編集及び閲覧をサポートする実施形態において、異なるユーザによって編集されているサイトを閲覧する場合であってもよい。

これらのトリガおよび変更のすべては、サイトの編集時だけでなく、サイトへの実行時アクセス時にも適用可能であることが理解され得る。本明細書で上述したように、ＷＢＳ２は、ランタイム中に何らかの編集機能を提供することができる（例えば、ブログサイトのユーザによるデザインされたブログ投稿の作成を可能にする）。

上記のトリガのいくつか（例えば、環境または相互作用の変化）はまた、物理的環境、ならびに非物理的環境（例えば、仮想現実、拡張現実、または任意の他の非物理的環境内のサイトとの編集または相互作用中に生じる変化）内で関連し得る。

次に、編集ハンドラ３１０２の要素を図示する図８を参照する。編集ハンドラ３１０２は、動的レイアウト（ＤＬ）ハンドラ３１０２１、レイアウトハンドラ３１０２２、テキストスケーラ３１０２３、可視性ハンドラ３１０２４、コンポーネントハンドラ３１０２５、アニメータ３１０２７、コンポーネントドッカー３１０２８、グリッドハンドラ３１０２９、追加パネルハンドラ３１０３０、コンポーネントグルーパ（grouper）３１０３１およびイメージハンドラ３１０３２をさらに備えることができる。これらの要素の機能は、以下でより詳細に説明される。

上述したように、編集レシーバ３１０１は、現在のサイト、ページ、またはコンポーネントに対する編集、変更、またはトリガであり得る入力イベントを受信することができる。編集ハンドラ３１０２は、入力イベントの結果としてどのような変更を行う必要があるかを決定することができる。編集ハンドラ３１０２のサブ要素は、ルールエンジン３４０およびＭＬ／ＡＩエンジン３５０を使用して、以下でより詳細に説明するように、それらの機能性を改善することができることを理解され得る。

本明細書で上述したように、システム２００は、米国特許第１０，１８５，７０３号に記載されているように、トリガによって発生する動的レイアウト変更に応答デザイン能力を統合することもできる。

モジュール３００は、実行時だけでなく、編集中（例えば、ユーザによってなされた編集変更を反映する）に動的レイアウト処理を実装してもよい。システム２００は、必要条件がケース間で異なり得るので、いずれのケースでも異なるメカニズムを使用することができる。第３の使用シナリオは、プレビューまたはシミュレーションモード、編集環境内で機能するウェブページのランタイムビューであってもよく、これは、通常のランタイムビューとは異なる挙動をすることができる。

動的レイアウトは、動的レイアウトトリガに基づいて、画面上のコンポーネントの移動およびサイズ変更を含むことが理解され得る。これらの動的レイアウトトリガには、コンテンツの変更、コンテンツの書式設定の変更、複数の設定間でのコンポーネントの切り替え、複数のターゲットプラットフォームの使用（異なる表示プラットフォームで異なる技術を使用したアプリケーションの表示）、複数の画面または表示ビューポートサイズ（画面の回転やウインドウのサイズ変更など、サイズや解像度が異なる多数のディスプレイを使用したアプリケーションの表示）が含まれる場合がある。他の動的レイアウトトリガには、動的データ（時間の経過とともに変化する動的データを含むコンポーネントの使用）、エンドユーザが開始した変更、アプリケーションが開始したレイアウトの変更、エディタでのコンポーネントの移動とサイズ変更、およびページの同時編集（例えば、ユーザが編集したページの共有編集または即時更新を提供するシステム内の他のユーザによる）が含まれることがある。

また、コンポーネントは、以下のような様々な要因により、実行時にそのサイズ／位置を変更することができることも理解され得る。

ブログコンポーネント（コメントのユーザ投稿の投稿／編集を可能にする）などのランタイム編集を可能にするコンポーネントにおいて、ユーザによるコンテンツ変更。

外部ソースからインポートされたコンテンツを反映したコンテンツ変更。これは、（たとえば） 単一のフィールドコンテンツ、または外部データベースからの複数のレコードを示すリピータを表示する項目の場合がある。

同一ページの同時編集・閲覧を可能とするシステムにおいて、他のユーザによるコンテンツの同時編集、又は同一ページの複数のユーザによる同時編集を反映したコンテンツ変更。

サイトによって開始／プログラムされた効果（例：コンポーネントコンテンツ、フォーマット、属性またはレイアウトに影響を与えるサイトイベントに関連するコード）によるコンテンツまたはサイズの変更。

他のコンポーネントまたはサードパーティアプリケーション（または他の埋め込みコンポーネント）によって行われるリクエスト。

環境サイズの変更によるページサイズの変更。たとえば、異なるサイズのプラットフォームへの展開、ウインドウ／ビューポートのサイズ変更、フォームファクタの変更（縦／横表示）、画面サイズの変更など。

ギャラリースクロールによる変化、コンポーネントに影響を及ぼす（例えば、ズームインを引き起こす）マウス通過などの、コンポーネントに影響を及ぼす他の変化。

ページおよびレイアウトは、常に静的ではないことが理解され得る。特に、コンポーネントは、複数の状態の間で切り替わり、さらにアニメーション化されてもよい。状態変更およびアニメーションは、コンポーネントの位置、サイズ、レイアウト、回転、スタイル、形状、変換などに対する変更を含むことができる。モジュール３００は、カーソル移動、スクロール、他の要素との相互作用、プログラム、データベースベースなどを含む、このような状態変化およびアニメーションのための複数のトリガをサポートしてもよい。

編集される要素のレイアウトは、これらの変更およびアニメーションを、駆動動的レイアウト操作として、または様々なページ構成におけるそれらのための適切なスペースを計画することに関して考慮に入れることができる。また、特定のコンポーネントの状態定義とアニメーションは、個々のブレークポイント範囲で変更することもできる。

コンテンツ変更に関する上記のすべての参照には、コンテンツに対するフォーマット変更も含まれ得ることが理解され得る。

さらに、動的レイアウトのためにそれらのサイズを移動または変更するコンポーネントは、他のコンポーネントに影響を及ぼすことがあり、例えば、そのコンテナに影響を及ぼすコンポーネントの場合、それらを「押し下げる」か、または拡張することがある。そのような効果は、米国特許第１０，１８５，７０３号に記載されているように、暗黙的な（自動的に生成された）アンカーまたは明示的なアンカーに基づくことができる。

アンカー（米国特許第１０，１８５，７０３号に記載されているようである）は、ドッキング／ロッキングタイプ（エッジ、コーナー、中心）、明示的／暗黙的性質、最小または最大サイズ、一方向／双方向、一方向または双方向アンカー、ゲート／ブレーキング条件、移動またはサイズ変更効果などの複数の属性を有することができることが理解され得る。

さらに、応答デザインおよび動的レイアウトは、（本明細書で上述したように）編集中およびランタイム中の両方に適用可能であることが理解され得る。

典型的な実施形態では、動的レイアウトは、編集およびコンテンツ変更（典型的にはダウン）に起因して、他のコンポーネントをプッシュまたはサイズ変更するコンポーネントを扱う。応答デザインは、典型的には、幅変化（異なるブレークポイント範囲に対する複数の構成を含む）によるレイアウト変更を扱う。

ＤＬハンドラ３１０２１は、コンフリクトを防ぐために、応答性のある編集および動的レイアウトを調和させ、相互作用させて動作させることができる。例えば、レイアウト幅が変化するにつれて、包含コンポーネントへの固定に基づいて、コンポーネントがより広くなったり、より狭くなったりすることがある。テキストコンポーネントが狭くなると、コンテナテキストが再フォーマットされ、テキストコンポーネントが下方に大きくなる可能性がある。次に、コンポーネントは、コンポーネントをその下に押し下げるか、または収容コンテナを下方に伸張させることができる。これは、米国特許第１０，１８５，７０３号に記載されているような明示的または暗黙的なアンカー、または以下でより詳細に説明するようなスタック要素またはグリッドなどの編集要素の使用に基づくことができる。

次に、サイトレイアウトにおける幅の変更の影響を図７Ａ－Ｇに戻って参照する。図７Ａは、サイズ変更可能な編集ステージ［Ａ］、幅変更ハンドル［Ｂ］、可能なブレークポイント範囲の視覚的な表示［Ｃ］（現在選択されているサイズの下に下線を含む（デスクトップミニアイコン））、ユーザがブレークポイント（したがって範囲）を編集することを可能にするインターフェースをもつ現在のブレークポイント範囲のリストを示すカスタマイズダイアログ［Ｄ］を含むいくつかのＵＩ要素を示す。

編集段階はさらに、テキスト段落コンポーネント［Ｅ］およびコンテナコンポーネント［Ｆ］（丸められた角を有する長方形）を含む。これらのマークされた要素のいくつかは、図７Ｂ～７Ｇの追加図に現れ、同じラベルが関連することが理解され得る。

以下の議論および図７Ａ乃至７Ｇが所定のコンポーネント及びコンテナのセットおよび、この限定セットと関連して説明されるように、システム２００の応答性デザイン、流動性及び動的レイアウト能力を備えた例に焦点を当てることが理解され得る。しかしながら、システム２００はまた、コンポーネント及びコンテナの任意の階層に対する応答性デザイン、流動性及び動的レイアウト能力を実施し、包含階層全体にわたって応答性デザイン、流動性及び動的レイアウトを適用することができる。したがって、例えば、システム２００は、トップレベル（例えば、ページ表示ビューポート全体が変化するとき）および内部コンテナ（例えば、特定のコンテナの幅に応じてサブ要素のレイアウトを変化させる）の両方でレイアウト変化を適用することができる。

［Ｄ］（図７Ａ）から分かるように、デフォルト設定は、スマートフォン画面では３２０～７５０ピクセル、タブレット画面では７５０～１０００ピクセル、デスクトップ画面では１０００ピクセル以上の範囲である。図７Ｂは、ブレークポイント範囲にわたる適切な処理を提供するためのスタック（以下でより詳細に説明する）の使用を示す。これは、システム２００のユーザが、２つのコンポーネント（［Ｅ］および［Ｆ］）の間にアンカーを作成して、それらを一緒にリンクして、それらに影響を及ぼすために使用することができるメカニズムである。スタックコンテナ［Ｇ］は、［Ｅ］および［Ｆ］を含むことができ、それらの周りの間隔（例えば、このシナリオでは［Ｆ］の周り）を画定することもできることが理解され得る。

また、ＤＬハンドラ３１０２１は、同じコンテナ階層レベル内のオブジェクト間だけでなく、包含コンテナへの明示的／暗黙的アンカーおよびアンカーを含む、他のタイプの動的レイアウトアンカー（米国特許第１０，１８５，７０３号に記載されているようである）を実装することもできる。システム２００の別の実施形態は、さらに、クロスコンテナアンカー、例えば、２つのコンテナ間で要素の同様の順序を維持することを可能にする、異なるコンテナ内のコンポーネント間のアンカーを実装することができる。

次に、図７Ｃ～７Ｅを参照すると、サイト上の幅変更の影響が示されている。ＷＹＳＩＷＹＧ編集中の表示は、前に詳述した幅変更ハンドル［Ｂ］を使用して行われた変更で表示される。応答エディタ３１０は、編集中の幅変更のための複数の方法を提供することができ、デザイナが異なる幅の下でレイアウトを見ることを可能にする。例えば、応答エディタ３１０は、（現在のブレークポイントセットのために修正された図７Ａのデスクトップ／タブレット／モバイルメニュー［Ｃ］を使用して）離散的なブレークポイントごとの幅値が選択されることを可能にすることができる。応答エディタ３１０は、幅変更ハンドル［Ｂ］を使用して連続的な変更を可能にすることもできる。

応答エディタ３１０はまた、ユーザが所定のコマンド（ビジュアルボタン、キーボードショートカット、マウスイベントまたは他のシステム入力）に関連する１つ以上の幅のアニメーションを指定することを可能にしてもよい。そのような幅アニメーションは、ユーザが、複数の幅を繰り返し手動で超えることなく、特定の幅のセットまたは範囲の下でサイトを見ることを可能にする。

ここで、約１６００ピクセル幅のページを示す図７Ｃを参照する。

ここで、約１１００ピクセル幅のページを示す図７Ｄを参照する。この幅において、テキスト［Ｅ］のテキストフォントサイズが縮小され、リフロー（すなわち、単語を次の行に移動）されていることが理解され得る。コンテナ［Ｆ］は押しつぶされている（そのため、現在は図７Ｃと比較してほぼ円形になっている）。

図７Ｅは、約８００ピクセル幅のページを示す。ブレークポイントインジケータ［Ｃ］は、ページが「タブレット」モードであることを示していることに注意する。

本明細書において上記で論じたように、プレビューワ３１０５は、ユーザが様々なブレークポイント範囲内の特定のコンポーネント（コンテナおよびコンポーネントセットを含む）をプレビューすることを可能にしてもよい。図７Ｇに示すように、プレビューワ３１０５は、現在選択されているテキストコンポーネント［Ｂ］のプレビュー［Ａ］と、その即時コンテナ［Ｃ］を、すべてのブレークポイントで表示することができる。プレビューには、動的な状態（マウスをコンポーネントの上に置いたときなど）を含む複数の状態が含まれる場合もある。

ここで図７Ｆを参照すると、テキスト要素が、（［Ｈ］「ｓｃａｌｅ ｔｅｘｔ」ボタンおよび２つのテキストポイントサイズボックスによって定義されるようである）単一のポイントサイズではなく、ある範囲のポイントサイズを有するように定義され得るメカニズムが示されている。このシナリオでは、テキストスケーラ３１０２３は、ビューポートまたはテキストフィールド幅に基づいて、テキストポイントサイズを最小値と最大値の間で拡大縮小することができる。

テキストスケーラ３１０２３は、連続線形スケーリングを使用することができる（例えば、幅値およびその幅範囲に基づいて、所与の範囲内のフォントサイズの細粒度線形補間を使用する）。このような細粒度の補間は、任意の最小単位、例えば、１０分の１点によって、点サイズを変化させることができる。テキストスケーラ３１０２３は、非連続線形スケーリング（すなわち、フォントサイズの変更を所与の「ステップ」に制限すること、またはフォントサイズを所与の値のセットに制限すること）を使用することもできる。

ＣＳＳジェネレータ３２０は、次のようなＣＳＳ定義を使用して、このような動的フォントスケーリングを、生成されたＣＳＳと共に直接実装することができる:
ｃａｌｃ（［ｍｉｎ ｆｏｎｔ ｓｉｚｅ］＋（［ｍａｘ ｆｏｎｔ ｓｉｚｅ］－［ｍｉｎ ｆｏｎｔ ｓｉｚｅ］）＊（（１００ｖｗ － ［ｍｉｎ ｖｉｅｗｐｏｒｔ ｗｉｄｔｈ］）／ （［最大ビューポート幅］－［最小ビューポート幅］））

テキストスケーラ３１０２３は、常に線形スケーリングを使用するのではなく、テキストサイズ変更とリフローを組み合わせて、２つの間の最適なバランスをとるスマートスケーリングを実施することもできる。これには、通常、コンポーネントの幅の変更に起因する変更を解析し、線形補間から小さなバリエーションを作成して、最良の視覚的結果を得ることが含まれる。

ここで、テキストがスケーラブルではなく、したがって、より狭い構成において（比較的）より多くの空間を必要とする、同様の構成を示す図９Ａ～図９Ｅを参照する。図９Ａは、単一のポイントサイズが選択されていることを示している（この場合、テキストスケール／ポイント選択ＵＩ［Ｈ］に示すように２８ポイント）。

図９Ｂ（～１２６０画素幅）から分かるように、９Ｃ（～７５０画素幅）および９Ｄ（～３６０画素）は、スクリーン（したがって、レイアウト）が狭くなると、テキストがリフローされ、したがって、より高層になる。次に、テキストはコンテナ［Ｆ］を押し下げる。

上述したように、編集ハンドラ３１０２は、表示幅の変化（または他の影響を与える変数）に基づいて、レイアウト（および一般的にはページ）に対する変化を定義することができる。本明細書で上述したように、編集ハンドラ３１０２のサブ要素は、ルールエンジン３４０と共にルールベースの機能を使用することができる。そのようなルールは、以下でより詳細に説明するように、自動ドッキング、サイト変換、ドラッグおよびサイズ変更要素、グリッドの管理（行および列の追加、削除など）、ならびにレイアウトおよびリピータの表示の変更などの機能のための指示を含むことができる。

したがって、例えば、図９Ｅ（ここで参照する）では、丸められたコンテナおよびテキストは、図９Ｄのように一方が他方の上にあるのではなく、示された区切り点範囲内で並んで配置される。

編集ハンドラ３１０２は、ブレークポイントを通過するときに、そのような（および他の）変更を発生させることができる。これらは、各ブレークポイント範囲内の変化が連続的でなければならないので、非連続的な変化である。以下でさらに論じるように、コンポーネントの位置およびサイズは、封入コンテナ（例えば、「サイズは封入コンテナサイズの５０%である」）に対する絶対ピクセルサイズ、分数（ＣＳＳ「２ｆｒ」単位）などを含む様々な単位を使用して定義することができる。

典型的な実施形態では、ユーザは、レイアウトの主要パラメータ、すなわち、ブレークポイント間のコンポーネント位置およびサイズ（図９Ｂ～図９Ｅに示すようである）を変更することができる。したがって、各ページには、ブレークポイント範囲ごとに１つずつ、複数のコンポーネントレイアウトが含まれている場合がある。各ページは、複数のレイアウト（コンテナコンポーネント内のレイアウトを含む）を有してもよいが、特定の（単一の）コンポーネントもまた、複数の構成を有してもよいことが理解され得る。

レイアウトハンドラ３１０２２は、サイトの分解（本明細書で上述したグループ化など）と要素の分類との間のマッピングに基づいてレイアウトを理解することができることを、理解し得る。分類法は、「ＷＢＳワールド」概念（例えば、ピクチャ＋キャプションブロック）ならびに「現実世界」概念（例えば、「我々の製品」ページブロックまたはセクション）を含むことができるサイト要素概念のそれ自体の階層を提供する。このような分類法は、米国特許第１０，０７３，９２３号により詳細に記載されている。

識別は、自然言語処理（コンポーネントに含まれるテキスト用）、以前のラベル付きサイトに関する情報、コンピュータビジョン及びユーザフィードバックに基づくことができる。

表示幅が同じブレークポイント範囲内にある限り、レイアウトハンドラ３１０２２は、式（幅パラメータに応じて異なる結果を依然として提供することができる）に従ってレイアウト（位置およびサイズ）を計算することができる。この公式は、ユーザによって明示的に定義されるか、または、ＭＬ／ＡＩエンジン３５０によって定義されるレイアウト変更に基づいてもよく、これは、本明細書において以下でより詳細に説明されるように、代替設計を自動的に生成してもよい。

ブレークポイントが交差されると、レイアウトハンドラ３１０２２は新しいレイアウトに切り替わり、おそらく非連続的なサイト変更を引き起こす（すなわち、ボタンがある場所から別の場所にジャンプする）。

このような変更は、コンテナレベルで行うことができ、例えば、コンテナは、異なるブレークポイント範囲の間で移動することができ、一方、コンテナ内部のコンポーネントは、（コンテナに対して）異なるブレークポイント範囲のためのそれらの位置およびサイズを保持することが理解され得る。対照的に、コンテナは異なるブレークポイント範囲間で自身のサイズを変更することもあり、そのコンテナ内に含まれるコンポーネントは影響を受ける可能性がある（移動、サイズ変更、または必要に応じて変更）。

レイアウトハンドラ３１０２２はまた、異なるブレークポイント範囲に対して異なるレイアウトを有するコンテナの予め定義された配置を提供してもよい（例えば、デスクトップ版では並列、モバイル版では上位）。

編集ハンドラ３１０２は、以下でより詳細に説明するように、コンポーネントｚオーダー、可視性（隠蔽／非隠蔽）、および他の属性などの追加のコンポーネント属性および設定をブレークポイント交差時に変更することも可能にすることができる。

可視性ハンドラ３１０２４は、特定のブレークポイント範囲に対するコンポーネントの隠蔽および非隠蔽を管理することができる。これは、例えば、デスクトップ構成のためのサイトナビゲーションの１つの方法（例えば、サイドメニュー）と、モバイルバージョンのための別の方法（例えば、「ハンバーガー」メニュー）を使用することを可能にしてもよい。

また、ユーザは、所与のブレークポイント範囲内で消失するコンポーネントについて「空隙を閉じる」ために、または所与の範囲内に出現するコンポーネントについて「スペースを作る」ために、異なるブレークポイント範囲について異なるレイアウトを定義することもできる。したがって、ユーザ編集は、コンポーネント編集（コンポーネントが挿入または削除されると、コンポーネントの自動再配置を提供する）のコンテキストで、本明細書に記載する、スペースの作成／クローズ機能によって支援されてもよい。

可視性ハンドラ３１０２４は、動的レイアウト能力を用いてこれを自動的かつ動的に行う能力を提供してもよい。これは、例えば、（例えば、実行時間中に決定されるコンテンツの量が異なるために）可変サイズを有するコンポーネントの場合に、より適用可能であり得る。この場合、可視性ハンドラ３１０２４は、例えば、隠蔽コンポーネントがゼロにサイズ変更されたものとみなし（例えば、ゼロサイズの点またはゼロ幅の線）、隠蔽コンポーネントに対するアンカーに基づいて、他のコンポーネントに動的レイアウト処理を適用することができる（その新しい「形状」で）。

コンポーネントハンドラ３１０２５は、状態または設定情報を共有するように、複数のコンポーネントをリンクする能力を提供してもよい。例えば、ユーザがタブレット上で使用する応答ページを横向き（幅広）と縦向き（狭）の両方のモードでデザインし、横向きモードレイアウトがサイドメニューを使用するのに対し、縦向きモードレイアウトがハンバーガーメニューを使用する場合、コンポーネントハンドラ３１０２５は、初心者／エキスパートメニュー複雑度設定、最後に選択されたオプション（強調表示されている場合）などの特定の状態情報をユーザが共有するように、２つのコンポーネントをリンクすることを可能にしてもよい。

代替的に、システム２００は、以下でより詳細に説明するように、複数の変形を提供するメニューコンポーネントを介して同様の機能を提供することができる。

コンポーネントハンドラ３１０２５は、応答性の影響を与えるパラメータに基づいて、コンポーネント属性（スタイル情報を含む）を変更することができることが理解され得る。

例えば、コンポーネントハンドラ３１０２５は、異なるブレークポイント範囲内のコンポーネントに異なる色を適用することができる。これは、例えば、コンポーネントが所与のブレークポイント範囲から異なる背景色を有する領域内またはその近傍に再配置され、コンポーネントの色変化が必要とされる場合に必要とされ得る。

上述のフォントについて説明した能力と同様に、システム２００は、コンポーネント属性の一部またはすべてについて範囲定義を提供することもできる。そのような範囲定義は、最小／最大値ならびに関連する補間式を含むことができる（例えば、コンポーネントハンドラ３１０２５は、複数の色勾配法などの複数のそのような式を提供することができ、ユーザは、どの式を使用するかを選択することができる）。

区切り点ごとの範囲の変更は、コンポーネントの回転およびアニメーション詳細、他の属性に関連する変更を含むことができることが理解され得る。

さらに、コンポーネントは単一のコンポーネントのままであり、様々なブレークポイントごとの範囲の変更は、基本的に、各ブレークポイント範囲のコンポーネントの継承バージョンに対する変更子であることが理解され得る。したがって、例えば、（このブレークポイント範囲に対して単に隠蔽されるのではなく）所定のブレークポイント範囲を編集するときにコンポーネントが削除された場合、すべてのブレークポイント範囲に対して削除される（おそらく、本明細書に記載するように、動的レイアウト定義への変更または「スペースを閉じる」作用をトリガする）。同様に、コンポーネントの実際の内容が変更された場合（テキストが編集された場合など）、変更された内容がすべてのブレークポイント範囲に使用される。

コンポーネントが特定のブレークポイント範囲のために移動され得るとしても、モジュール３００の典型的な実施形態は、コンポーネントが同じ親コンテナ（スタック、レイアウタ、またはリピータのセルであってもよい）の下に留まることを必要とし得る。コンポーネントハンドラ３１０２５は、特定のブレークポイント範囲において、あるコンテナから別のコンテナへのコンポーネントの移動（「再親化」として知られる）を防止することができる。これはグリッド「セル」には適用されず、グリッド行はアンカー支持を提供するが、セルごとのコンテナのセットを形成しないことに留意されたい。

代替実施形態では、コンポーネントハンドラ３１０２５は、ユーザがこの制限を放棄し、ブレークポイント範囲間でコンポーネントを再親化することを可能にすることができる。しかしながら、これは、（ＨＴＭＬおよびＣＳＳにおいてそのような構造および挙動を表すことがより困難であるため）かなりのコストを有する可能性がある。コンポーネントハンドラ３１０２５は、（例えば）互いにリンクされ（本明細書で上述したように）、使用中のブレークポイント範囲に応じて隠蔽され、または可視である同じコンポーネントの複数のインスタンスを使用して、この構造を実装することができる。

いくつかのコンポーネントは、複数の事前レンダリング解像度を有することができるイメージなど、異なるサイズ、解像度、またはアスペクト比に適した複数のバージョン、変形形態、または構成を有することができることが理解され得る。

また、ギャラリは、異なるタイプ（スライダ、マトリクス、水平フリップギャラリ、垂直フリップギャラリ等）又は（ギャラリコンポーネントのための）割り当てられたサイズ及びアスペクト比に依存する異なるパラメータ（列の数等）を有することができる複数のバージョンを有することができる。例えば、リピータコンポーネントは、大画面デスクトップ構成のマトリックスギャラリからモバイル構成のスライダに変更することができる。

（ある限度未満にサイズ変更されたときに）モーダルダイアログを開くボタンとしてレンダリングすることができる、または代替として、初期セクションと拡張セクション（エンドユーザがボタンを押すときにのみ開く）に分割された、コンタクトフォームがある。

ビデオプレーヤはまた、複数のバージョンを有することができ、利用可能なスペースに応じて異なる組の制御ボタンをレンダリングすることができる（例えば、単に再生／停止する、開始／一時停止にスキップを追加する、早送り／早戻しボタンを追加するなど）。

コンポーネント定義は、離散的（すなわち、３つの利用可能な構成のうちの１つを選択する）であってもよく、または１つ以上のパラメータ（離散的または連続的であってもよい）に基づくものであってもよいことが理解され得る。例えば、マトリックスギャラリリピータコンポーネントは、異なるブレークポイントに対して異なる数の列を有することができる。

応答エディタ３１０は、各ブレークポイント範囲でどのコンポーネント構成を使用するかの手動選択をサポートすることができる。あるいは、コンポーネント定義は、異なる条件下でどのコンポーネントを選択するかについてのヒントをコンポーネントハンドラ３１０２５に提供することができる。したがって、コンポーネントは、それ自体のブレークポイントおよびルールを提供することができ、例えば、幅１００～３００ピクセルが利用可能である場合にはバージョンＡを使用し、３００ピクセルを超えるピクセルが利用可能である場合にはバージョンＢを使用することができる。

応答エディタ３１０で使用する典型的なページ構造は、ヘッダ領域とフッタ領域と同様に、ページセクションから構成されてもよいことが理解され得る。ページは、複数のセクションを含むことができ、各セクションは、レイアウト、リピータ、およびスタックなどのサポートコンテナタイプを含むコンポーネントおよびコンテナを含むことができる。典型的な実施形態では、セクションは、上下に垂直に配置され、コースト・ツー・コーストセクション（ｃｏａｓｔ－ｔｏ－ｃｏａｓｔ ｓｅｃｔｉｏｎｓ）であり、すなわち、ページの水平ストリップ全体を占める。そのようなセクションは、典型的には、表示ビューポート幅に応じてそれらの幅を変化させることができる。応答エディタ３１０は、コンポーネント回転、アニメーションなどの追加のレイアウト要素をサポートすることができる。

主サポートツール（レイアウタ、スタック、リピータ、またはグリッドなど）のそれぞれは、編集ステージ上に表示される視覚表現サブ要素と、ユーザがツールを使用するのを助ける編集サポートサブ要素（例えば、レイアウタ内に要素を配置する）と、実行時に適切な挙動を実装するために基礎となるＣＳＳを生成するのを助けるために実際のレイアウト計算を実行する（他のレイアウトエレメントと一緒に）実装サブ要素とを含む、複数のサブ要素を提供することができることが理解され得る。この最後のサブ要素は、その作業においてＣＳＳジェネレータ３２０をサポートする。

応答エディタ３１０は、ページのいくつかまたはすべてに現れることができる共有部分、コンポーネントの使用をサポートすることもできる。共有部分には、同じコンテンツが表示される。このコンテンツは、表示されるすべてのページにおいて、ページごとにまだパラメータ化されている可能性がある（ページヘッダーのページ番号など）。いくつかの実施形態では、共有部分は、マスターコンポーネントまたはマスターブロックとしても知られている。上述のヘッダおよびフッタは、このような共有部分の例である（他のコンポーネントを含むことができる共有部分コンテナとして）。

コンポーネントは、（通常のページ領域から）共有部分に出入りすることができることが理解され得る。共有部分のコンテンツは、マルチビューイング、すなわち、実際の同じコンポーネントが複数のページで単に見えるようにするなど、多くの方法で共有することができる。任意のページでの閲覧の変更は、他のすべてのページに影響する。

コンテンツは継承によって共有される場合もある。つまり、ページはマスターコピーから継承される。マスターコピーが変更された場合、これらの変更はすべてのページに反映される。特定のページコピーが変更された場合、これはローカル変更子を介して処理され、変更はこのページにのみ適用される。

コンテンツは、各ページコピーが別々であり、メインコピーや他のページに接続されないように、各ページにコピーすることによって共有することもできる。

応答エディタ３１０は、セクションが連続していることを必要とするか、またはセクション間にスペースを定義することを可能にすることができる。セクション高さは、いくつかの方法で決定することができ、例えば、固定／事前定義することができ、サイトを表示するために使用されるビューポートの全高に設定することができ、最大の含まれるオブジェクトに適合させることができる。

コンポーネントは、典型的には、単一のセクション内に完全に存在する。しかしながら、コンポーネントハンドラ３１０２５は、コンポーネントが所与のセクションから延在（すなわち突出）し、１つ以上の隣接するセクションに交差することを可能にすることができる。しかしながら、このシナリオでは、コンポーネントの領域の大部分は、典型的には、それが関連付けられているセクション内にある。

コンテナおよび他のコンポーネントは、固定サイズ、伸縮性、またはスクリーンサイズに関連するものとして定義されてもよい。これは、本明細書で後述する様々な特定のコンテナタイプ（セクション、スタック、レイアウト、リピータなど）に適用することができる。

ここで、ブレッドクラムディスプレイのためのセクションおよびコンポーネント選択の使用を示す図１０Ａおよび１０Ｂを参照する。図１０Ａは、２つのセクションを含むページを有するそのような構造を示す。応答エディタ３１０は、セクション（および他の要素）が選択され、移動され、除去されることなどを可能にするセクションハンドリングおよびナビゲーションツール［Ａ］を提供し得る。

深く埋め込まれたコンポーネントの選択を支援するために、応答エディタ３１０は、ブレッドクラム経路表示［Ｂ］を使用することもできる。コンポーネント（コンテナの場合もある）が選択されると、最上位コンテナから選択されたコンポーネントへのコンポーネントを含むパスを示すパス表示が表示される（表示例［Ｂ］のように、選択された内部テキストのパス“Ｓｅｃｔｉｏｎ＞Ｃｏｎｔａｉｎｅｒ＞Ｃｏｎｔａｉｎｅｒ＞ Ｔｅｘｔ”が表示される）。

図１０Ｂ（ここで参照する）は、（例えば）所与のブレークポイントに対してセクションを隠蔽することができるので、セクションとセクション操作に利用可能なオプションとの間の分離を示すページ構造をさらに示す。

「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ Ｆｏｒ Ｓｅｃｔｉｏｎ－Ｂａｓｅｄ Ｅｄｉｔｉｎｇ ｏｆ ａ Ｗｅｂｓｉｔｅ Ｐａｇｅ」という名称の米国特許第１０，１４６，４１９号（２０１８年１２月４日付）および「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ Ｆｏｒ Ｈａｎｄｌｉｎｇ Ｏｂｊｅｃｔｓ ｉｎ Ｖｉｓｕａｌ Ｅｄｉｔｉｎｇ Ｓｙｓｔｅｍｓ」という名称の米国特許出願公開第２０１９／０２４３８８２号（２０１９年８月８日公開）に記載されているような、セクション処理およびページオブジェクト選択のための追加のオプションが、本出願人によって共有され、参照によって本明細書に組み込まれる。

コンポーネントは、通常、追加パネルとして知られる利用可能なオブジェクト（コンポーネントタイプ）のセットのメニューからドラッグアンドドロップによって追加されることが理解され得る。追加パネルは、アトミックコンポーネント、コンテナ、デザイン要素（レイアウタおよびリピータなど）、ならびに事前作成されたセクションを含んでもよい。追加パネルは、ＷＢＳサービス、およびブログ、ストア、および予約などの垂直も含むことができる。ここで、このようなメニューを示す図１１Ａ～Ｃを参照する。追加パネルおよび図は、以下でより詳細に説明される。

応答エディタ３１０は、コンポーネントが幾何学的に互いに重なり合い、任意の位置に（ドラッグアンドドロップまたはサイズ変更を介して）配置されることを可能にすることができる。コンポーネントハンドラ３１０２５は、このような重なり合うオブジェクトを処理するために、ｚオーダーまたは層化能力をさらに実装してもよい。代替的に、コンポーネントハンドラ３１０２５は、以下でより詳細に説明するように、挿入されたコンポーネントのためのスペースを作るための機構を提供することができる。

したがって、応答エディタ３１０は、コンポーネントの挿入、削除、またはドラッグアンドドロップ中に、（正確なユーザ定義の配置と並行して）「スペースを作成／クローズ」能力を提供することができる。したがって、コンポーネントが所与の位置（おそらく１つの他のコンポーネントと重なる）にドロップされると、応答エディタ３１０は、ドロップされたコンポーネントのための場所を作るために、これらのコンポーネントのいくつかまたはすべてをサイズ変更または移動することができる。同様に、コンポーネントがコンポーネントの配置からドラッグアウトされると、応答エディタ３１０は、作成された空隙を閉じるように、残りのコンポーネントのサイズを変更または移動することができる。応答エディタ３１０は、同様の方法（すなわち、ドラッグ元と同様の削除、ドラッグ先と同様の挿入）でコンポーネントの挿入および削除を処理することができる。

ドラッグ元およびドロップ先の位置は、コンテナ、例えば、コンポーネントの垂直列を有するスタックコンテナ内にあってもよいことが理解され得る。次に、コンテナＡがドラッグダウンされたとき（シナリオＩ）、コンテナＢがＡの代わりに上に移動され、２つの場所が切り替わる（シナリオＩＩ）方法を示す図１２を参照する。

このようなスペースを作成／クローズの動作は、特定のユーザアクション（例えば、通常のマウスドラッグの代わりに制御ドラッグを使用する）、または、本出願人によって共有され、参照によって本明細書に組み込まれる、２０１９年１月２２日に付与された「Ｗｅｂ Ｓｉｔｅ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｎｇ Ｄｙｎａｍｉｃ Ｌａｙｏｕｔ ａｎｄ Ｄｙｎａｍｉｃ Ｃｏｎｔｅｎｔ」という名称の米国特許第１０，１８５，７０３号に記載されているような特定のハンドルまたは同様の機構を使用することに依存し得る。

あるいは、これは、ドラッグ元またはドロップ先が発生するコンテナのタイプに依存し得る。例えば、コンポーネントハンドラ３１０２５は、スペースを作成／クローズの挙動を、特定のコンテナタイプ（例えば、以下で説明するスタックコンテナ）、または特定の属性または設定でマークされた任意のコンテナに適用することができる。そのようなシナリオでは、スペースを作成／クローズの挙動は、ソースコンテナとターゲットコンテナとの間で異なることがある（例えば、ソースコンテナ内のスペースを閉じるが、ターゲットコンテナ内にスペースを作ることなく、ターゲットコンテナ内に重なり合うドロップ配置を可能にする）。

「スペースを作る」能力は、例えば、既存のアンカータイプおよび方向からの情報を使用して、各隣接するコンポーネントを修正するための最良の方法を決定する、ユーザのデザイン意図の解析に基づくことができることが理解され得る。コンポーネントハンドラ３１０２５はまた、以前のユーザアクティビティおよび編集履歴、このウェブサイト内の他の領域のレイアウト、ならびに以下でより詳細に説明するようにＭＬ／ＡＩエンジン３５０に関連してより詳細に説明するようなシステム内で入手可能な他の情報を使用することができる。

応答エディタ３１０は、複数のブレークポイントにわたるサイトの編集をサポートし、各ブレークポイント範囲についてデザインを最適化しながら、ブレークポイント範囲セットにわたるデザインおよびレイアウトを統一するための複数のメカニズムを提供することができることが理解され得る。これらの目標は、多くの場合、矛盾し得ることが理解され得る。

ここで、複数のブレークポイント範囲にわたるデザイン統一のためのインターフェースを示す図１３Ａおよび図１３Ｂを参照する。図１３Ａは、ユーザが、別のブレークポイント範囲内の同じコンポーネントのものから、所与のブレークポイント範囲内のコンポーネントの設定およびデザインをコピーすることを可能にし得るインターフェースを示す（図中の「プルデザイン」ＵＩ［Ａ］－「Ｃｏｐｙ Ｆｒｏｍ Ｂｒｅａｋｐｏｉｎｔ」）。同様のオプション（図１３Ｂに示す）は、ユーザが、現在のブレークポイント範囲内のコンポーネントの設定およびデザインを、図中のＵＩ［Ｂ］の「Ｍａｋｅ Ｅｖｅｒｙｏｎｅ Ｌｉｋｅ Ｍｅ」によって表されるような他のブレークポイント範囲（「プッシュデザイン」）にコピーすることを可能にする。

応答エディタ３１０の実施形態はまた、そのようなコピーが、同じサイトまたは別のサイトの他のページ内の同じまたは類似のコンポーネントタイプのインスタンスから行われることを可能にし得る。これは、本出願人により共有され、参照により本明細書に組み込まれる２０１９年１０月２９日に付与された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ｔｈｅ Ｇｅｎｅｒａｔｉｏｎ ｏｆ ａｎ Ａｄａｐｔｉｖｅ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ ｉｎ ａ Ｗｅｂｓｉｔｅ Ｂｕｉｌｄｉｎｇ Ｓｙｓｔｅｍ」と題する米国特許第１０，４５９，６９９号に記載されているように、クラスタリングアルゴリズムおよび代表的な設定およびデザイン値の選択を使用して実施することができる。

アニメータ３１０２７は、所与の範囲の幅または特定のブレークポイントについてのコンポーネントのユーザ選択のためのアニメーションを提供することができる。アニメーション３１０２７は、フルページ、特定のページセクション、特定のコンテナ、または特定のコンポーネントを表示することができる。ページの異なるバージョン（幅が異なる） では、選択されていないコンポーネントが考慮される場合がある。選択されていないコンポーネントはグレー表示になっているか、完全に非表示になっている可能性がある。これは、ブレークポイント間で特定のコンポーネントまたはコンポーネントセットにどのような変更が発生したかを直感的に表示するために実行できる。選択されていないコンポーネントは、表示アニメーションを簡素化するために削除される。

応答エディタ３１０は、このようなアニメーションを対話形式に見ることまたはエクスポートすることを可能にし、一時停止することを可能にしてもよい（与えられたグレー表示／非表示が適用されたサイトプレビューのバージョンに戻す）。

応答エディタ３１０はまた、編集中のオブジェクトドッキングおよびアンカーリングを単純化するために、ならびにレイアウト内にコンポーネントを配置するために、複数のツールを提供し得る。

コンポーネントドッカー３１２８は、自動ドッキングをサポートすることができ、コンポーネントをドッキングし、可能なドッキングオプションごとに距離を実施する最良の方法を示す。次いで、ドッカー３１２８は、可能なドッキングを提案し、適用することができる。例えば、ドッカー３１２８は、コンポーネントが、そのコンテナ内の任意の他の物体よりもはるかに近いそのコンテナのコーナーに閉じて配置されたときを検出し、特定のコーナーの２つの近いエッジにドッキングすることを推奨することができる。

応答エディタ３１０は、コンポーネント、コンテナ、およびプリセットが、それらのプライベートドッキングパラメータを指定することを可能にすることができる。したがって、所与のプリセットは、例えば、正規行列フォーマットに適合しない特殊なグリッド配列を有することができる。

ＭＬ／ＡＩエンジン３５０は、編集および保存（または他のサイト操作）中に絶対（ＷＹＳＩＷＹＧ）レイアウト定義を解析することができ、ユーザの意図を検出し、以下でより詳細に説明するように、この意図を実施するルールの宣言的セットに変換することができる。

上述のように、要素は、典型的には、（コンポーネントの移動、コピー、および複製に加えて）追加パネルインターフェースを介してページに追加される。

ここで、追加パネルがレイアウト支持要素（図１１ＡでＡとマークされた）、通常のコンポーネントおよびコンテナ（図１１ＢでＢとマークされた）、および完全に定義されたセクション（図１１ＣでＣとマークされた）をどのように含むかを示す図１１Ａ～Ｃを参照する。このような所定のセクションは、プリセットとしても知られている。

一般に提供される要素（コンテナ、コンポーネント、およびいくつかのセクションタイプなど）は、抽象的であり、コンポーネント、レイアウト、およびページの世界に関連するので、「ＷＢＳ世界」にあることが理解され得る。システム２００はまた、「現実世界」に対応するセクション、すなわちウェブサイトの外部の意味を有する人間の談話のセクション（ビジネス用語など）を提供することもできる。図１１Ｃから分かるように、応答エディタ３１０は、Ａｂｏｕｔ画面、Ｓｅｒｖｉｃｅｓリスト、Ｐｒｏｄｕｃｔｓリスト、Ｐｏｒｔｆｏｌｉｏなどの要素（プリセットＣ）を提供することができる。

そのような可能なセクションおよびコンポーネントの数は非常に多いので、応答エディタ３１０は、カスタマイズされ、パーソナライズされた追加パネルを提供することができる。そのような追加パネルは、以下でより詳細に説明するように、ユーザ入力ファンネル（funnel）、ユーザ属性（ビジネスタイプなど）、サイト属性、現在のサイト構造、過去のアクション、およびデザイン選好などに基づいて、ユーザ上で利用可能な情報に基づいて確立することができる。

応答エディタ３１０は、所定のソースブレークポイント設定を有するオブジェクト（例えば、３つのブレークポイント範囲を有する）が、異なるターゲットブレークポイント設定を有するページ（例えば、異なる値を有する４つのブレークポイントを有する）に挿入される複数の状況をサポートすることができる。コンポーネントハンドラ３１０２５は、挿入されたオブジェクトを、ターゲットページに対して定義されたブレークポイントに適合させてもよい。

これは、セクション（または別のコンポーネント）をページ間でコピーまたは移動する場合など、複数のシナリオで発生する可能性がある（ページのブレークポイント定義が異なると想定）。これは、１つのサイト内（ページごとに異なるブレークポイントが許可されている場合）にあっても、異なるサイト間にあってもかまわない。

また、別のサイトや別のレイアウト作成環境（例 ＷＢＳが採用している別のエディタ）から要素やセクションを含めたり（参照、継承、または他のメカニズムを介して）、ページに含めるためにユーザがプリセット（または別のコンポーネント）を選択し、ページに挿入されたオブジェクトに関連付けられたブレークポイント範囲がある場合にも発生する可能性がある。

また、共有部分（ページヘッダなどの共有領域）を切り離して通常のページ領域に戻したり、ページから共有部分に要素を移動したりする場合など、共有部分でも発生することがある。

次に、スタックを示す図１４を参照する。スタック［Ａ］は、互いに上下に押す、（他のコンテナ、スタック、または他の要素とすることができる）包含されたコンポーネントの垂直セットを含むコンテナである。スタック定義は、包含されたコンポーネント間のギャップ［Ｂ］を含む。スタックは、その包含されたコンポーネント間の空隙を維持し、それらが重なり合わないようにする。同様のコンポーネントは、垂直方向のものの代わりに水平方向の押しを提供することができる。

スタックは、編集中に含まれるコンポーネントの並べ替えだけでなく、包含されたコンポーネントの配置のためのドラッグアンドドロップを可能にすることができることが理解され得る。これは、本明細書で上述したように、スペースを作成／クローズを使用して行われる。

本明細書に記載するレイアウタと同様に、レイアウトハンドラ３１０２２は、スタックがオーバーフィルされた場合、それを異なる表示フォーマット（例えば、スライダまたはスライドショー）に変換してもよい。

システム２００は、ＨＴＭＬのＦｌｅｘＢｏｘ要素を用いて、このようなスタック要素を実装してもよい。

レイアウタは、サブコンテナのセットにレイアウトを提供するコンテナであることが理解され得る。これは、配置、リストまたは他のリピータを含むコンテナをデザインする容易な方法を提供する。レイアウタは、ユーザ定義の再配置およびシステム決定の再配置の両方を含む、幅変更時に再配置されるサブコンテナのセットを定義する容易な方法を提供する。

レイアウタは、様々な直接の兄弟関係となるもの（すなわち、直接含まれる要素）を支持することができる。しかし、一実施形態では、すべての直接の兄弟関係となるものがコンテナであること、または特定のタイプのコンテナであることさえも必要とすることがある。

レイアウタは、アイテムがその行／列の内側、レイアウタコンテナ自体の内側のどこに配置されるか、および利用可能なスペースがあるとき（左／右／中央／字間調整など）を決定する複数の位置合わせオプションを提供することができる。

次に、レイアウタコンポーネントおよびレイアウタ構成を示す図１５Ａおよび１５Ｂを参照する。図１５Ａは、５つのサブコンテナ（ａ～ｅ）を含むレイアウタ［Ａ］を示し、これらは、それ自体、追加のコンテンツ（５つのサブコンテナのそれぞれに１～２個のボタンまたはハンバーガーアイコン）を含む。サブコンテナは、伸縮可能であり、サイズ変更および移動が可能である。

サブコンテナをレイアウタから移動させることができ、外部コンテナをレイアウタ内に移動させることができるという意味で、レイアウタは通常のコンテナのように振る舞うことができることが理解され得る。

レイアウタは、ユーザが、編集中の並べ替え（「スペースを作成／クローズ」機能の有無にかかわらず）、コンテナをオンザフライで追加すること、外部からコンテナを追加すること、外部にコンテナを除去すること、およびレイアウトを変更することなどの動作を実行することを可能にすることができる。

当然のことながら、レイアウタは、静的配置（［Ｂ］の行（Ｒｏｗ）、列（Ｃｏｌｕｍｎ）、および行（Ｒｏｗｓ）など）および動的配置（［Ｂ］のスライダ（Ｓｌｉｄｅｒ）配置など）を含む複数のタイプの配置（図１５Ａの「Ｄｉｓｐｌａｙ ｔｙｐｅ」［Ｂ］など）をサポートすることができる。これは、サブコンテナのいくつかのみがいつでも見える他のタイプのギャラリを含むことができ、ユーザ（ならびにサイトビューワ）は、下にあるギャラリの異なる部分にナビゲートすることができる。

本明細書で上述したように、より多くの配置が利用可能であり、レイアウトハンドラ３１０２２は、（例えば、コンテンツの伸張のために）スペースが満たされた場合に、所与のレイアウタを異なる配置に自動的にさらに切り替えることができる。追加の配置には、カード、スライドショー、スライダ、リストおよび列が含まれ、レイアウタは、ユーザによる追加の編集なしに、それらのいずれかを適用することができる。

図１５Ａのレイアウト［Ａ］は、「Ｒｏｗｓ」配列を使用する。対照的に、図１５Ｂの同じレイアウタ［Ａ］は、図示のような「Ｃｏｌｕｍｎ」配置を使用する。

ユーザは、様々な配置の間で切り替えることができ、レイアウタは、所望の配置に従って、レイアウタ内のサブコンテナ（その内容物を有する）を再配置することができることが理解され得る。ユーザは、（図１５Ａのマージン（Ｍａｒｇｉｎ）［Ｃ］および主方向性（Ｌ２Ｒ／Ｒ２Ｌ）［Ｄ］などの）配置のための追加のパラメータを提供することができる。

レイアウタはまた、その可能な配置のそれぞれについてレイアウトコンテクストを保存することができる。ユーザは、各配置を修正した（例えば、所与の配置の位置、サイズ、および順序を変更した）ことがあるので、レイアウタは、これらの修正を保存することができ、したがって、レイアウタは、この配置に戻るときにそれらを再適用することができる。

したがって、ユーザは、ブレークポイントごとの範囲の変更を適用することができ、ブレークポイントごとの範囲ごとに異なる配置を使用すること、およびサブコンテナおよびそのコンテンツに他の変更を行うことを含む。

ユーザは、レイアウタのサブコンテナにオブジェクトを出し入れすることができることが理解され得る。オブジェクトが複数のサブコンテナを横切るようにレイアウタにオブジェクトをドロップするとき、レイアウタは、どのサブコンテナを使用するかを選択することができる。

そのような選択は、カーソル位置、最大のオーバーラップ領域を有するサブコンテナ、最大の結合された垂直及び水平オーバーラップ、又は他の基準のような多数のパラメータに基づくことができる。レイアウタは、ドロップされたオブジェクト（「ホットゾーン」と呼ばれる）を「受け取る」サブコンテナを強調表示することによって、ドラッグ中にユーザを助けることもできる。

レイアウタが（上述のように）すべての直接の兄弟関係となるものがコンテナであることを必要とする場合、レイアウタは、ドロップしたオブジェクトの周りにラッピングコンテナを自動的に作成する。

当然のことながら、ＭＬ／ＡＩエンジン３５０と共にレイアウタは、推奨される配置選択および同じ配置内での種々の変更を含む、より良いデザインオプションを提案し得る。これらは、一般化された提案または特定のブレークポイント範囲のコンテキスト内の提案であり得る。一般化された提案は、一般化されたレイアウトタイプのメニューの１つである（以下でより詳細に説明する）。具体的な提案は、特にレイアウタの現在の内容に基づくレイアウト提案のセットであり、本出願人によって共有され、参照によって本明細書に組み込まれる、２０１７年８月２９日に付与された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ｔｈｅ Ｃｒｅａｔｉｏｎ ａｎｄ Ｕｓｅ ｏｆ Ｖｉｓｕａｌｌｙ－Ｄｉｖｅｒｓｅ Ｈｉｇｈ－Ｑｕａｌｉｔｙ Ｄｙｎａｍｉｃ Ｌａｙｏｕｔｓ」という名称の米国特許第９，７４７，２５８号に記載されたレイアウト提案と同様である。

レイアウタは固定されてもよく、すなわち、レイアウタの幅が変化するとき、そのサブコンテナは同じ配置のままである（しかし、それらは動的レイアウトのために互いにサイズ変更または押すことができる）。ブレークポイント範囲間で発生する唯一の移動は、ユーザによる明示的な編集によるものである。

あるいは、レイアウタは変形性であってもよく、そのサブコンテナは、特定の条件下で特定の方法で移動する。１つの単純な例は、行レイアウタ（要素が並んでいる）であり、この行レイアウタは、利用可能な幅がある値を下回ったときに、列レイアウタ（要素が他方の上にある）に自動的に変換される。より複雑な変換を指定することができる（例えば、ワードプロセッサの幅が変化するときの段落内のワードのリフローに類似する）。システム２００は、そのような変換レイアウトを提供することができ、ユーザが自分自身の変換レイアウトをデザインすることを可能にすることができる。

応答エディタ３１０はまた、（異なる幅の下でのレイアウタ変更に関して）本明細書で上述したような追加の変換能力をサポートすることができる。応答エディタ３１０はまた、２０１９年１月８日に付与された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ａｕｔｏｍａｔｅｄ Ｃｏｎｖｅｒｓｉｏｎ ｏｆ Ｉｎｔｅｒａｃｔｉｖｅ Ｓｉｔｅｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ Ｔｏ Ｓｕｐｐｏｒｔ Ｍｏｂｉｌｅ ａｎｄ Ｏｔｈｅｒ Ｄｉｓｐｌａｙ Ｅｎｖｉｒｏｎｍｅｎｔｓ」と題された米国特許第１０，１７６，１５４号および出願人が共有し、参照により本明細書に組み込まれる出願第１６／８７８，８３１号に記載されているように、移動ディスプレイのためのコンポーネントを再配置するために使用されるような技術を使用して、アルゴリズムに基づく変換をサポートすることができる。

次に、リピータの使用を示す図１６Ａ～１６Ｃを参照する。リピータはレイアウトに類似しているが、サブコンテナ（アイテムとしても知られている）が単一のサブコンテナまたはサブコンテナのセットの複数のインスタンスである点が異なる。したがって、１つのサブコンテナに適用される変更（例えば、新しいコンポーネントを挿入すること）は、すべてのサブコンテナに適用することができ、すべてのサブコンテナに現れることになる。図１６Ａは、リピータ表示のためのいくつかのオプション［Ａ］を示す。

しかしながら、リピータ内部のコンポーネントは、ページ間で異なる特定のデータ（例えば、テキスト又は画像ソース）を依然として有することができる。このようなデータは、ユーザによって手動で、またはリピータをデータソース（インメモリテーブル、データベース、外部ＣＭＳなど）に関連付けることによって管理することができる。ユーザは、基礎となるデータベースまたはＣＭＳ５０によって提供されるインターフェースを介してデータを管理することができる。

リピータは、表示されたデータとは別個のアイテムを使用することができる。例えば、リピータは、一連のデータ要素（要素１／２／３／４、２／３／４／５などを示す）に「ウインドウ」を形成する４つのボックスのセットを表示することができる。

リピータは、（ここで参照される図１６Ｂに示されるように）「Ｍａｎａｇｅ Ｉｔｅｍｓ」のユーザインターフェース［Ｂ］を提供して、例えば、表示方法および配置、行当たりの最大数、ならびに表示の他の属性を選択するアイテムを管理することができる。

ここで参照される図１６Ｃに示されるように、アイテムがリピータに追加されるとき（例えば、ｉｔｅｍ１およびその複製を複製することによって）、モジュール３００は、リピータを拡張し、サブコンテナの追加の行を作成することができる。レイアウトハンドラ３１０２２は、グリッド表示をスライダに変換するなど、他のタイプの再配置（上記のレイアウトについて説明したようである）を実行することができる。

本明細書で上述したように、応答編集グリッドは、ほとんどのコンテナに適用して、コンテナに含まれるコンポーネントの整列を助けることができるグリッドレイアウトメカニズムである。したがって、応答編集グリッドは、コンポーネントを配置するためにそれを明示的に使用するユーザに見える。

応答エディタ３１０により、ユーザは、応答編集グリッドをセクションおよびすべての通常のコンテナタイプに手動で適用することができる（ただし、それ自体のレイアウトメカニズムを有するレイアウトおよびリピータには適用できない）ことが理解され得る。次に、コンテナ内の応答編集グリッドの実装および処理を示す図１７Ａ～図１７Ｄを参照する。（通常のコンテナに適用されるようである）サンプル３ｘ３グリッド［Ａ］が図１７Ａに示されている。

ここで参照する図１７Ｂおよび１７Ｃに示すように、ユーザは、行および列の数、行／列の測定単位およびサイズ、水平および垂直空隙などのグリッドのパラメータを指定することができる。行および列は、固定サイズまたはフレキシブルとすることができる。グリッドは、伸張、グリッド線または列の交換などを含む編集操作でさらに編集または除去することもできる。

グリッドは、（グリッドが適用された）コンテナのサブ要素のドッキングに使用することができる水平及び／又は垂直のラインを提供することが理解され得る。ドッキングは、負のマージンを使用することもでき、したがって、要素は、所与のグリッドセルエッジに固定されるが、実際には、そのエッジを部分的にグリッドセル（またはグリッド全体）の外側になるように横切る。

グリッドセルは、別個のサブコンテナではなく、したがって、コンポーネントは、異なるブレークポイント範囲についてそれらの間で移動され得ることが理解され得る。

グリッドハンドラ３１０２９は、コンテナのサイズとグリッドのパラメータとの間で一致することができ、必要に応じて（非％単位で作業する場合であっても）ラインパラメータを変更することができる。例えば、「ａｕｔｏ」を有するグリッド線は、（テキストのようである）大きな要素をドロップするときに伸張し得る。例えば、図１７Ａ（テキストオブジェクトをドロップする前）と図１７Ｄ（テキスト「Ｂｉｇ Ｔｉｔｌｅ」をドロップした後）との間のグリッドの１行目のＲ１の比較である。

システム２００は、ピクセル、％、ｆｒ（サイズ分数）、ｖｈ／ｖｗ（ビューポートのサイズに基づく）、ｅｍ、ｒｅｍ、計算ベースなど、様々な測定ユニットをサポートすることができることが理解され得る。

フラクションユニットは、１ｆｒおよび２ｆｒのサイズを有する２つの列を（例えば）指定することを可能にする。１つ目の列は幅の１／３ を使用し、２つ目の列は幅の２／３ を使用する。

グリッドハンドラ３１０２９は、グリッドサイズおよび測定ユニットを管理することができ、その結果、使用されるユニットに応じた変更、および、包含するコンテナ内のコンポーネントの変更が自動的に処理される。したがって、グリッドをコンテナに適用するとき、グリッドハンドラ３１０２９は、既存のデザインを維持し、それをユニット変更を含む新しいグリッドに再計算することができる。ユーザは、ユニットおよびサイズについて心配する必要はない。グリッドハンドラ３１０２９は、レイアウトハンドラ３１０２２と共に、グリッドサイズに適合するようにコンテナサイズをさらに更新し、グリッドを適所に保つことができる。

背景として（他のコンポーネントに対して）使用されるイメージコンポーネントおよびイメージは、表示される前に、しばしば実質的な処理を通過することが理解され得る。特に、ユーザは、典型的には、その最も関連する部分が示されるようにイメージをクロップ（crop）することを望むことがある。定義されたクロッピング（cropping）は、（特に）イメージのデフォルトサイズとアスペクト比を定義する。応答エディタ３１０は、形状マスクを使用することによって非矩形クロッピングをサポートすることもできる。

また、ユーザは、イメージ中の注目点（焦点）を指定したい場合がある。これは、いくつかのイメージ表示コンポーネント（いくつかのギャラリーなど）が、ユーザがクロップ領域を定義するのではなく、焦点に基づいてイメージ表示を決定するために必要とされる。

次に、所与のコンテナおよびグリッドの背景として働くように（視覚的クロッピングを使用して）クロップされるイメージを示す図１８を参照する。

システム２００は、イメージ属性がブレークポイント範囲ごとに定義されることを可能にし得ることが理解され得る。したがって、ユーザは、自分のサイトにイメージの単一のコピーを埋め込むことができるが、異なるクロップ（および結果として生じるアスペクト比）と、各ブレークポイント範囲についての異なる焦点とを定義することができる。したがって、ページは、単一のイメージコンポーネントを有するが、この単一のコンポーネントから複数の生成された出力を有する。

イメージハンドラ３１０３２は、（例えば）イメージが異なるブレークポイント範囲に適合するように既に調整されている（例えば、縮小されている）ので、この能力を応答エディタ３１０によって行われた他の変更と統合することができる。イメージハンドラ３１０３２は、ズーム、フォーカス、カラー処理などの他のイメージ変更を処理することもできる。

上記の議論は、それらの出力を表示し、それらの対話を単一の画面上で処理するアプリケーションの構築に焦点を当てており、単一の画面は、非常に小さいもの（例えば、スマートウォッチディスプレイ）から非常に大きいもの（例えば、ビルボードディスプレイ）まであってもよいことが理解され得る。

異なる実施形態では、システム２００は、（必ずしも連続した「ディスプレイ表面」を形成しない）複数のスクリーンにわたって分割されるアプリケーションのデザインをサポートすることができる。これは、多数の場合、例えば、複数のスクリーンとしてアクセスされる非常に大きな物理的スクリーン（例えば、ディスプレイ管理の制限のため）、マルチモニタシステム、一次ディスプレイ及び補助ディスプレイを有するシステム（例えば、システムのための「仮想リモートコントロール」としてアプリケーションの一部を実行するスマートフォン）、又はアプリケーションを実行する実際の複数の別個のモニタを有するシステムにおいて発生し得る。

このシナリオでは、アプリケーションは、複数のディスプレイ（メインディスプレイおよびリモートコントロールディスプレイなど）上に表示するように区分されてもよい。各パーティションには独自のブレークポイントのセットがあり、異なる表示サイズに個別に適応させることができる。さらに、ブレークポイントモデルは、異なる幅を有する複数のスクリーン、例えば、単一スクリーンのための１つのレイアウト定義（異なるブレークポイント範囲への細分化を伴う）、２つのスクリーンのための１つのレイアウト定義などをサポートするように拡張されてもよい。

異なるモニタは、単一のシステム２００または複数のシステム２００に接続することができる。これらの複数のシステムは、アプリケーションを実行する際にそれらの間で調整することができる。さらに、ディスプレイ／モニタ構成は、アプリケーション動作中に（例えば、上述のような補助ディスプレイがシステムに係合またはシステムから係合解除されるときに）変化し得る。

したがって、システム２００は、そのような環境に適合された応答デザイン、流動性、および動的レイアウト編集および表示能力を提供することもでき、アプリケーションを一度デザインし、異なる数のモニタを有するシステムで（たとえば）動作させることができる。

上記で論じたように、ＭＬ／ＡＩエンジン３５０は、以下でより詳細に論じるように、システム２００の目標を達成するために利用することができる。ＭＬ／ＡＩエンジン３５０は、米国特許出願第１６／８７８，８３１号に記載されているように、ＷＢＳ２で利用可能な情報、ならびにＷＢＳベースのトレーニングフィードバックを使用することができ、本明細書で以下でより詳細に説明するように、いくつかの機械学習モデルまたはそれらの組合せを利用することができる。

本明細書で上述したように（また、ここで再び参照する図１１Ｃに示すように）、システム２００は、ウェブサイトの外部の意味（ビジネス用語など）を有する人間の会話（discourse）の「現実世界」に対応するセクションおよびコンポーネントを提供することができる。

そのような可能なセクションおよびコンポーネントの数は非常に多いので、応答エディタ３１０は、カスタマイズされ、パーソナライズされた追加パネルセクションを提供することができる。追加パネルハンドラ３１０３０は、ユーザが最も使用または追加する可能性の高いコンポーネント選択およびプリセットを用いて、追加パネルを動的に更新することができ、それらをユーザにさらに推奨することができる。追加パネルはユーザごとだけでなく、サイトごとや追加情報ごとにカスタマイズされるため、同じユーザに異なるサイトや異なるコンテキストで異なる追加パネルが表示される場合がある。

このカスタマイズは、サイトを構築する際にユーザの使用パターンを学習するためにＭＬ／ＡＩ技法を適用することができるＭＬ／ＡＩエンジン３５０を使用することによって決定することができることが理解され得る。ＭＬ／ＡＩエンジン３５０は、ページ、セクション、コンテナ、およびコンポーネントを含む、サイト上の要素の作成につながる新しい順次ステップから連続的に学習することができる。

さらに、この機能は、ホームページであるか、特定の意図をもつページであるかにかかわらず、サイト内のページと共に、サイトのパレット、ユーザが作成したレイアウト、ページ内に構築されている部分に基づくコンテキストデータと組み合わせることができることが理解され得る。これは、ユーザのデザイン及び意図に最も適した推奨を決定する。ＭＬ／ＡＩエンジン３５０はまた、モデルを使用して、ユーザが保持する熟練度のレベル、サイトのビジネス目標、およびユーザ自身および他の同様のユーザの過去の行動によって結果を最適化することができる。

また、コンテキスト情報は、ユーザ入力ファンネルに基づく情報（例えば、入力時にユーザが回答した質問）、ユーザ属性（ビジネスおよび産業のタイプなど）、ユーザ選好（保存されたデザイン、保存されたプリセット、好き、嫌い、コレクションなど）、およびサイト属性（例えば、ユーザがどのアドオンをインストールし、どのアドオンがアクティブであるか）など、ユーザおよびサイト上で入手可能な追加情報を含むことができる。

コンテキスト情報は、さらに、現在のサイト構造、過去のアクション、ユーザデザインの選好、および現在の編集状態（選択されたコンポーネント、開いているフローティングダイアログなど）を含むことができる。編集履歴およびビジネスインテリジェンスを含むすべての情報が、本明細書で上述したＣＭＳ５０の異なるリポジトリから利用可能であり得ることが理解され得る。

システム２００はまた、特定のアドオン購入（サードパーティアプリケーション、ＷＢＳ構成可能アプリケーション、垂直及び他のアドオン）、ならびに上記のような解析に基づく特定のコンテンツ、メディア、プリセット及び他の要素を推奨することができる。

ネクストムーブサジェスタ３１０４１は、ＭＬ／ＡＩエンジン３５０を使用し、特に、ユーザに次に何をするかを提案するために、ユーザがこれまでに行ったことに基づいて、本質的に生成的であるモデルを使用することができる。アクションは、コンポーネント提案（「ここで、第３のボタンを配置する時間である」）、及び配置提案（「次のイメージにとって最良の場所である」）、編集変更（「スタックでこれら３つのコンポーネントをより良くラップする」）、又は他のＷＢＳ動作提案とすることができる。したがって、ネクストムーブサジェスタ３１０４１は、レコメンダ（recomender）として、または編集アシスタント（たとえば、「自分のためにそれをする」アシスタント）として機能し、エクスプレーナおよびサジェスタ３１０４を介してユーザとインターフェースすることができる。

ネクストムーブサジェスタ３１０４１は、ユーザに複数の代替案を提供することができる（選択と同時に、またはエクスプレーナおよびサジェスタ３１０４を通じた「何か他のものを提案する」オプションを介して）。また、既存のコンポーネントに対して異なる構成を提供することもできる。

ここで、シナリオ推奨を含むシーンを示す図１９Ａおよび１９Ｂを参照する。図１９Ａは、テキストボックス［Ａ］を狭くし、その下のボタン［Ｂ］と重なるテキスト「ＨＵＧＥ ＴＩＴＬＥ」を２行に分けた場合を示している。そのような場合、ネクストムーブサジェスタ３１０４１（ＭＬ／ＡＩエンジン３５０を使用する）は、図１９Ｂに示すように、２つのフィールド（テキストフィールド［Ａ］およびボタン［Ｂ］）をスタックコンテナ［Ｃ］で囲むようにユーザに提案することができる。

ネクストムーブサジェスタ３１０４１は、これをユーザへの提案として行うか、またはユーザからの提案および要求確認を直接実装することができる。これは、ユーザが通常の「取り消し」機能を使用して提案された変更を取り消せるようにするのと同じくらい簡単である可能性がある。このようなフィードバックは、追加の訓練材料としてＭＬ／ＡＩエンジン３５０によって使用されるネクストムーブサジェスタモデルに直接供給することができる。

ネクストムーブサジェスタモデルは、ユーザのアクションおよび編集履歴の解析、環境、コンテキスト（本明細書で上述したようである）、所望の目的、ユーザが配置しようとしているコンポーネント、および他の入手可能な情報など、複数の情報ソースの解析に基づいてその予測を行うことができることを理解されたい。

特に、ネクストムーブサジェスタモデルは、（例えば、同じ基礎となるテンプレートファミリまたは他の基準を用いて）類似のサイト上で、または類似の編集シーケンスを用いて、現在のユーザおよび他のユーザによって実行されたアクションを用いて訓練され得る。

ネクストムーブサジェスタ３１０４１は、関連するユーザクラスタ（例えば、類似のサイト編集特性を有するユーザ）を検出するために、（例えば、ユーザおよびサイトに基づく）セグメンテーション解析をさらに使用することができる。

ネクストムーブサジェスタ３１０４１は、「デザインセンター」としても機能し、サイトデザインの一般的なレビューを実行し、このデザインに使用するための最良のレイアウト要素を予測する（それらを提案または自動作成する）。

「ネクストムーブ」モードおよび「デザインセンター」モードの両方について、ネクストムーブサジェスタ３１０４１は、スタック、自動ドッキング（要素ごとに、レイアウトごとに、ブレークポイントごとに、再計算グリッド領域を含む）、グリッド線の追加、フレックスボックス（スタンドアロン要素として、またはスタックの一部として追加される）、およびピン留めされた要素など、通常のコンポーネントではない追加のレイアウトおよびフォーマット要素を推奨（または自動適用／作成）することができる。

さらに、上記とは異なる技法または技法の組合せセットを使用して、（特定の所望の結果について）同様の視覚的結果を達成することが可能であり得る。ネクストムーブサジェスタ３１０４１は、生成されたレイアウト／ページの品質（変更後）を考慮して、所与のタスクを実行する複数の方法（「次のタスク」またはその他）を考慮することができる。これは、全てのブレークポイント範囲にわたるレイアウトの異なる変形の品質（様々なブレークポイント範囲間の均一性を含む）を含むことができる。

また、異なるデザインは、それらの性能及び効率が異なることがあるので、性能及び効率を考慮に入れることができる。例えば、システム２００は、通常、ブラウザのレンダリングエンジンで直接実行される宣言的ＣＳＳの使用を最大化する（これは、ＪａｖａＳｃｒｉｐｔコード実行よりも高速で効率的である）。したがって、ネクストムーブサジェスタ３１０４１は、可能な解の格付けの一部としてＣＳＳ使用を最適化する解を選択することができる。

したがって、ネクストムーブサジェスタ３１０４１は、単一のフォローアップ作用、フォローアップ作用のセット、または次に何をするかの検索または生成された説明（テキスト、ビデオ、ゲームまたはゲーム設定、アニメーション、提案されたアクション結果のシミュレーション、または音声説明を介することができる）を提供する（推奨または自動実行する）ことができる。それはまた、そのような動作または説明の任意の組み合わせを提供することができ、または他の手段を介してユーザにフィードバックを提供することができる。

本明細書で上述した処理は、ユーザが初期レイアウト（典型的には、最も広い構成、例えば、デスクトップ構成）を作成し、次いで、異なるブレークポイント範囲のための様々なより狭い構成のためにレイアウトおよびコンポーネントを手動で調整することに基づく。

代替実施形態では、応答エディタ３１０は、処理中のユーザをサポートすることができる。ユーザは、デスクトップバージョン（例えば）をデザインし、ネクストムーブサジェスタ３１０４１は、それ自体で他のブレークポイント範囲にレイアウトを提案または再配置する。

これは、ルールエンジン３４０（米国特許第１０，１７６，１５４号に記載されているものなど）を使用して、またはＭＬ／ＡＩエンジン３５０を介した機械学習ベースのモデル（以下でより詳細に説明するように、ルールベースのシステム、明示的に生成されたデータ、およびユーザフィードバックを使用して訓練される）を使用して行うことができる。ネクストムーブサジェスタ３１０４１はまた、一般に、応答エディタの複数のユーザ、すなわち、ユーザが所定のレイアウトを所定のブレークポイント範囲に適合させる方法について、収集された編集履歴に基づいて訓練され得る。

複数のブレークポイント範囲に対するサイトアダプテーションは、いくつかのコンポーネントをこれらのコンポーネントの流動バージョンで置き換えること（含まれるデータの転送およびレギュラーから流動コンポーネントへの設定を含む）を含み得ることが理解され得る。

さらに、レイアウトの理解およびコンポーネントのグループ化は、サイト解析およびサイト変換（例えば、静的に応答し、静的に移動する）に関連する複数のタスクで使用されるので、システム２００の基本的な構築ブロックであることが理解され得る。

コンポーネントグルーパ３１０３１は、サイト記述（例えば、ＸＭＬまたはＪＳＯＮのようなデータ記述言語における）を、グループ定義の階層セットに変換することができる。コンポーネントグルーパ３１０３１は、特許出願第１６／８７８，８３１号に記載されているようなコンポーネントグルーピングモデルを利用することができることが理解され得る。

コンポーネントグルーピングモデルは、典型的には、ＲＮＮベース、コンピュータビジョンベース、トリプレットベース、およびトリプレットとコンピュータビジョンとの組み合わせを含む、図２０Ａに示されているような１つ以上の基礎モデルを使用することができる。ＭＬ／ＡＩエンジン３５０は、複数のそのようなモデルを組み合わせることができ、複数の基準（手動グループ化解析、一貫性、およびユーザフィードバックからの既知のグランドトゥルース（ground truth）結果との比較を含む）に従ってそれらを格付けして、それが動作しているサイトの所与の母集団またはカテゴリに対して使用すべき最良のものを決定することができる。ここで参照される図２０Ｂは、手動でラベル付けされたページ（Ｉ）、グランドトゥルース情報に対するモデル（ＩＩ）の結果の例を示す。

この情報は、レイアウトハンドラ３１０２２だけでなく、システムのＷＢＳワールド要素（例えば、レイアウト提案）によって直接使用されてもよい。

さらに、システム２００の要素は、ページ、ページサブセット（セクションおよび他の要素コレクション）、およびレイアウトを、それらの品質に基づいて評価する能力を必要とすることが理解され得る。レイアウト品質評価は、ネクストムーブサジェスタ３１０４１のようなシステム２００の複数の要素によって使用されてもよい。

当然のことながら、米国特許第９，７４７，２５８号に記載されているようなレイアウト品質評価器４７への説明に記載されているような品質評価のための多くの技術が当技術分野で知られている。ＭＬ／ＡＩエンジン３５０は、品質評定を提供するためにモデルを訓練するために、ＭＬ技法およびフィードバックを使用してもよい。レイアウト品質は、個人の好みおよび好みの問題であり得ることが理解され得る。したがって、システム２００の一実施形態は、（すべてのユーザについて訓練された）汎用モデルからの結果を、特定のユーザについて訓練されたモデルと組み合わせることができる。

編集プロセスが終了すると、応答エディタ３１０は、ＣＭＳ５０内の任意の変更を保存することができる。

本明細書で上述したように、応答編集モジュール３００は、完全なＷＹＳＩＷＹＧ編集を提供し、プレビューワ３１０５は、図７Ａ～７Ｆに戻って参照されるように、任意の幅について連続的にサイトをプレビューする能力を提供する。応答エディタ３１０はまた、編集プロセスの間、ページ全体に対する一般的なプレビューを提供してもよいことが理解され得る。したがって、プレビューワ３１０５は、ユーザが、図７Ｇに戻って参照されるように、様々なブレークポイントで特定のコンポーネント（およびコンテナ）を同時にプレビューすることを可能にすることができる。

マルチレベル制約を有する複雑な階層構造の編集は、異なる制約が互いに衝突し、解決されなければならない多くの場合を含むことが理解され得る。したがって、２つの異なるコンポーネントのドッキング制約は、ある程度衝突する可能性がある。同様に、コンテナの制約は、コンテナに含まれるコンポーネントの制約と衝突することがある。

さらに、システム２００は、ＭＬ／ＡＩエンジン３５０（例えば、以下でより詳細に説明する）を使用し、その作用および推奨は、ある程度不透明であり、事前定義されたルールのセットに直接基づいていない。

したがって、エクスプレーナおよびサジェスタ３１０４は、システム２００がなぜ所与のアクションを与えるか、または特定の推奨を与えるかについての説明を（オンラインヘルプと同様に）ユーザに提供することができる。そのようなモジュールは、説明可能な人工知能の分野からの技術に基づくことができる。

本明細書で上述したように、ＣＳＳジェネレータ３２０は、応答性、流動性、動的レイアウトデザインの特徴を宣言型ＣＳＳにマッピングし、ＪａｖａＳｃｒｉｐｔコードの使用を最小限に抑えることができる。これにより、サイトの動的および応答性の高い機能の多くは、宣言型ＣＳＳコードを介してブラウザレンダリングエンジンによって直接実行されるため、パフォーマンスとインタラクションの利点が得られる。

ＣＳＳジェネレータ３２０を使用することにより、ＪａｖａＳｃｒｉｐｔ（ＪＳ）コードの使用がさらに最小限に抑えられ、サイトのロード時間およびインタラクティブ時間の値がより良好になる。ブラウザは通常、後の段階でＪＳコードをロードし、ＪＳ実行を開始する前にＪＳコード全体がロードされるのを待機する場合があるためである。

したがって、システム２００は、例えば、ＨＴＭＬ Ｆｌｅｘ Ｂｏｘを使用してスタックオブジェクトを実装し、ＣＳＳグリッドなどを使用してグリッドを実装することができる。

本明細書で上述したように、システム２００は、動的レイアウトおよび流動コンポーネントをウェブサイトページに実装することができる。本出願人は、システム２００の機能が、流動表示（すなわち、表示ビューポート変更のための連続的なレイアウト変更）を実施することによって、および／または既存の（典型的にはデスクトップ）サイトレイアウトに異なるブレークポイント範囲のためのレイアウト変形を追加することによって、非応答サイトにも適用され得ることを見出した。これは、絶対レイアウトを伸縮可能なレイアウトに変換することを含むことができる。生成された伸縮可能なレイアウトは、両方の次元において伸縮可能であってもよい。以下の議論は、水平軸の変化に焦点を当てる。したがって、システム２００はまた、元のサイトのレイアウトを修正することができ（例えば、スタックおよびレイアウトなどの応答性支持要素を追加すること）、要素またはコンポーネントをそれらの応答性または流動性を有する対応物と置き換えることもできる。

出願人は、このアプリケーションが、オンライン動的レイアウトプロセスへのブラウザ統合を可能にする前処理の使用を通じて動的レイアウトのパフォーマンスを改善することができることをさらに見出した。メッシュアプライヤ３３０は、ブラウザエンジンの「上」に実装されるのではなく、動的レイアウト処理の一部をブラウザレンダリングエンジン内部で（すなわち、レンダリングおよび進行中のブラウザ－ユーザインタラクションの一部として）発生させることができる表現にサイトを変換することができる。

本明細書で上述したように、レイアウトは、そのサイズおよび属性が、親によって（例えば、親の変更またはビューポート幅の変更によって）、または様々なトリガによって影響され得る流動コンポーネントを組み込み得る。ブレークポイント範囲を使用して機能を実装するために、レイアウト要素（コンポーネント、ｚオーダー、アンカーなど）は、スマートメッシュ形成、グリッドのセル（またはマージされたセル）がコンポーネントを表すグリッドライクフォーマットで保持される。その表現は、コンテナレベルで再帰的に作成され、すなわち、各コンテナは、それ自体のメッシュを有する。

本明細書で説明したように、ページをブラウザに送る（または、サーバ上などでページをレンダリングする）とき、スマートメッシュは、ブラウザによって直接レンダリングされてもよい特定のフォーマットに変換される。

以下の説明は、（ＣＳＳグリッド標準で定義されるようである）ＣＳＳグリッド特徴に基づくターゲットフォームを使用するシステムの実施形態に焦点を当てる。この形式は本質的に宣言的なものであり、ブラウザは上位レベルのコード（ＪＳコードなど）を必要とせずに、動的レイアウト関連のインタラクションと処理のかなりの部分を処理できる。他の実施形態は、本明細書において以下でさらに詳細に議論されるようにすることができる。

本明細書で上述したように、システム２００は、編集中（例えば、ユーザによって行われた編集変更を反映する）並びにランタイム中に動的レイアウト処理を実施することができる。システム２００は、必要条件がケース間で異なり得るので、いずれのケースでも異なるメカニズムを使用することができる。第３の使用シナリオは、プレビューまたはシミュレーションモード、編集環境内で機能するウェブページのランタイムビューであってもよく、これは、通常のランタイムビューとは異なる挙動をすることができる。

本明細書で上述したように、動的レイアウトは、動的レイアウトトリガに基づいて画面上のコンポーネントを移動およびサイズ変更することを含む。コンテンツ変更に関する上記のすべての参照には、コンテンツに対するフォーマット変更も含まれ得ることが理解され得る。

（本明細書で上述したようである）トリガは、（例えば、生成された宣言的定義に基づいて）ブラウザによって内部的に処理され得るブラウザエンジンハンドル（ＢＥＨ：browser engine handled）トリガ、ページまたはその中のコンポーネントに関連するJSコードによって処理され得るＪａｖａＳｃｒｉｐｔハンドル（ＪＳＨ：JavaScript-handled）トリガ、およびサポートグリッド構造を更新することを必要とし得るグリッド再生成ベース（ＧＲＢ：grid-regeneration based）トリガなどの複数のクラスに分割され得、通常、完全または部分的なページ再レンダリングにつながることが理解され得る。

クラスは相互に排他的ではない場合がある。例えば、一部のトリガは、それらの正確なパラメータとそれらが表すページ変更に応じて異なる方法で処理される場合がある。

したがって、メッシュアプライヤ３３０は、システム２００のためのレンダリングプラットフォームを提供することができる。これは、コンポーネントがそれに適合されることを必要とする場合があり、特に、適合されたコンポーネントは、（ウェブページの全体的な可視時間を改善するために）ＪＳがユーザに見える前にＪＳを実行することを必要とすべきではない。

システム２００はまた、そのようなシステムに適合されていないコンポーネントと共に使用するためのアダプタをサポートすることができる。そのようなアダプタは、初期ページビューにコンポーネントを隠蔽し、表示の準備ができたときにのみそれを示す（例えば、特定ページの「折り畳み部分の下」に）など、ページのローディングを高速化するために多くの技法を使用することができる。

他のアダプタは、プレローダ（pre-loader）ディスプレイを使用すること、公開中、サイトアクティブ化中、またはサイト内のユーザの動きの予測に基づいて（例えば）生成され得るコンポーネントディスプレイの事前生成されたスクリーンキャプチャを使用すること、またはコンポーネントの代替（簡略化された、部分的な、またはシミュレートされた）バージョンをプレースホルダとして使用することを含み得る。

メッシュアプライヤ３３０は、ページコンポーネント構造を、初期ランタイムレンダリング上でＣＳＳグリッド定義を使用してＣＳＳジェネレータ３２０によって実装されるメッシュ形式に変換することができる。このように、ブラウザは、ＪＳエンジンで実行されるＪＳコードを使用して動的レイアウト機能を実行するのではなく、ブラウザ独自のレンダリングエンジン（宣言型ＣＳＳ定義に基づく）で実行時にページの動的レイアウト機能を実装する。

応答エディタ３１０はまた、メッシュアプライヤ３３０によって提供される同じレンダリングフレームワーク（これは、追加されたエディタＵＩと同様に、表示されたページステージに適用されてもよい）を実装してもよいことが理解され得る。あるいは、応答エディタ３１０は、レンダリングのために手続き型絶対レイアウトベースのフレームワークを使用することができる。応答エディタ３１０は、これら２つを組み合わせることもできる。プレビューワ３１０３は、典型的には、レンダリングのためにメッシュアプライヤを使用することができる（例えば、ページの実際のランタイム挙動とのより良好なパフォーマンスならびにより大きな互換性を提供するために）。このランタイム挙動は、ランタイムサーバ２０によっても提供され得ることが理解され得る。

さらに、メッシュアプライヤ３３０は、クライアント側レンダリング、サーバ側レンダリング、または、その組み合わせである、ページの最初のレンダリングで、ブラウザのためのＣＳＳグリッドを予め生成してもよいことが理解され得る。本明細書で上述したように、これは、各コンテナがそれ自体のグリッド定義を有することができるように、コンテナレベルで再帰的に行うことができる。

いくつかのコンポーネントおよびコンテナは、他の方法によるハンドリングに役立ち得る。例えば、リピータ及び他のリストタイプコンポーネントは、ＣＳＳフレックスボックスへの変換を介して管理及びレンダリングされてもよい（これは、２次元グリッドと比較して、リストのような１次元コレクションの処理により良く適合されてもよい）。このような代替的なハンドリングは、メッシュアプライヤ３０に統合されてもよく、またはそれと並行して実行されてもよい。

また、ＣＳＳグリッド適応ページは、ブラウザが、上記のトリガの大部分（しかし、おそらくすべてではない）に応答し、処理することを可能にすることも理解され得る。（すなわち、これらは、ＢＥＨトリガである。）したがって、ブラウザは、グリッドの修正、ページの再ロードまたは再レンダリングを必要とせずに、宣言的ＣＳＳグリッド情報に基づいて、必要に応じてページを適応させることができる。そのようなＢＥＨトリガは、例えば、以下のものを含むことができる。

複数のソースからのコンポーネントコンテンツ（コンテンツ、書式設定、その他の変更を含む）に影響する変更（データベース情報の更新、ユーザによるコンテンツの編集、ユーザとの対話、その他のソースなど）。

画面／ウインドウ／ビューポートサイズの変更（表示回転に関連する変更を含む）。

予め定義されたブレークポイント境界を横切る幅変更。このような変更は、ＣＳＳメディアクエリーの使用、およびページ／コンテナ定義に複数のレイアウトオプション（入手可能なブレークポイント範囲への幅の一致に応じて）を含めることによってサポートされる場合がある。

コンポーネントが他のコンポーネントを押し込むことに起因する変更。

他の変更およびトリガは、グリッドが修正／再生成されること、およびページが再レンダリングおよび／または再ロードされることを必要とし得ることが理解され得る。このような変更には、例えば、コンポーネント位置またはコンテナ－コンポーネントの親関係の変更（例えば、コンポーネントを１つのコンテナから別のコンテナに移動すること）を伴う同時編集変更が含まれ得る。

ＢＥＨトリガ、ＪＳＨトリガ、ＧＲＢトリガの区別は、とても優れている可能性があることに注意すべきである。例えば、コンポーネントの内容を修正する同時編集変更は再レンダリングなしに扱うことができるが、コンポーネントの位置への変更は再レンダリングを必要とする可能性がある。

システム２００は、さらに、変更されたページの一部のみが更新され、再レンダリングを必要とするインクリメンタルページ更新および再レンダリングを実装してもよい。

上述したように、ＣＳＳジェネレータ３２０は、典型的には、レンダリングの直前にＣＳＳグリッド定義を生成する（クライアントまたはサーバベースのレンダリングである）。特に、生成されたグリッド（およびそれが表すコンポーネント関係およびアンカー）は、フィールドの現在のコンテンツ（特定のフィールドのサイズを決定することができる）、ならびに現在のクライアント装置の属性（および特に表示幅）に依存することができる。

しかしながら、メッシュアプライヤ３３０から直接更新を受信する場合（図４に戻って参照する）、ＣＳＳジェネレータ３２０は、特定のプラットフォーム／ブラウザバージョンの組み合わせに対して、ＣＳＳグリッドのプリアダプタにおける複数のバージョンを事前に生成することができ、レンダリングの直前にそれらを（更新された値で）さらに適応させることができる。

説明した実施形態は、ＣＳＳグリッド標準を使用することが理解され得る。別の実施形態は、異なるウェブブラウザ標準または能力に基づいてもよく、特にこれらはＣＳＳにおける宣言的レイアウト管理を提供する。

ページデザインの大部分のためにＪＳ要素ではなく宣言的ＣＳＳ要素を使用することは、すべてのＪＳコードをロードする前に、ブラウザが典型的にＨＴＭＬ及びＣＳＳをロード、レンダリング及び表示するのに伴い、性能を改善することが理解され得る。したがって、本発明の好ましい実施形態によれば、ロードされたページは、ＨＴＭＬおよびＣＳＳがロードされると、ほとんど対話型であり、ページの「対話時間」の測定量を低減する。これは、対話型の、すなわち対話型の要素（ボタンなど）のページが動作し、それらの機能を実行するまでにかかる時間の測定であることが理解され得る。これは、たとえ何らかの対話が機能しなくても、そのページがどのくらい迅速に表示を開始するかを測定する「閲覧時間」の測定量とは反対である。

さらに、メッシュアプライヤ３２０で作業するとき、ＣＳＳジェネレータ３２０は、コンポーネントの再使用に対応する複数の場所でグリッドスタイルを再使用することができる。したがって、ＣＳＳジェネレータ３２０が、所与の複合コンポーネントのグリッド表現を生成する場合、定義を１回だけ送信することができ、定義は、複合コンポーネントの複数のインスタンスで自動的に再使用することができる。これは、例えば、（繰り返し使用される）コンポーネントグループ／複合コンポーネント、ならびにリピータなどのリストベースのコンポーネントに適用される。

ＣＳＳグリッドへの変換は、ＣＳＳグリッドの異なる実装間の実装におけるバグおよび矛盾に関連する問題を解決する可能性があることが理解され得る（例えば、使用される特定の実装に適合したバージョンを生成することによって）。ＣＳＳジェネレータ３２０は、さらに、ＣＳＳグリッドの標準的かつ正しい挙動（正しく実装された場合であっても）が、動的レイアウトのための適切なサポートを提供しないか、または、そのような問題または欠落した能力を補償するために関連するＪＳコードを追加することを含めて、必要とされるアンカータイプを適切に実装しない場合を処理することができる。

ページ解析（以下でより詳細に説明する）に基づいて、メッシュアプライヤ３３０は、中間メッシュフォーマットまたは内部データ構造を使用することができる。これは、ＷＢＳコンポーネント定義およびページデータ構造をメッシュフォーマット（メッシュグリッド）またはデータ構造に変換し、この中間フォーマット／データ構造からＣＳＳグリッド定義を生成することを伴うことができる。スマートメッシュ構造は、（応答性および流動性を有する）サイトを宣言的に定義するために実際に使用されることが理解され得る。ＣＳＳジェネレータ３２０は、ＷＢＳページ定義から直接ＣＳＳグリッド定義を直接生成することもできる。メッシュアプライヤ３３０は、本明細書で上述したＪＳＨトリガを実施するのに必要な追加のＪＳコードをさらに生成することができる。ＣＳＳジェネレータ３２０は、メッシュレイアウトフォーマットをデータ記憶フォーマット、すなわち「保存する」、すなわち、展開フォーマットとして、すなわち、「公開する」か、アクセス時、すなわち「ロード時」に動的に生成するように適用または適合させてもよい。

また、上記のＪＳＨトリガに加えて、生成されたページのいくつかの機能が、いずれにせよＪＳで実装されなければならないことが理解され得る。たとえば、特定の変更されたレイアウトの特定のサイズの画像を取得するには、サーバから正確なサイズにサイズ変更されたイメージを取得するために、ＪＳがサーバ呼び出しを配置する必要がある。これは通常、ＣＳＳでは実行できない。

ここで、メッシュアプライヤ３２０の要素を図示する図２１を参照する。メッシュアプライヤ３２０は、ページレシーバ３３０１、トリガハンドラ３３０２、ページアナライザ３３０３、およびページコンバータ３３０４をさらに備えることができる。

ページレシーバ３３０１は、ＷＢＳエディタ３０から入力ページを受信することができ、あるいは、応答流動コンポーネントまたは定義されたブレークポイントなしにＷＢＳ２によってインポートされたサイトを受信することができ、トリガハンドラ３３０２は、入力トリガクラス（本明細書で上述したように、ＢＥＨ、ＪＳＨ、ＧＲＢ）のタイプを認識することができる。

ページアナライザ３３０２は、受信されたページを解析して、その構成および最良のハンドリング方法を決定することができる。解析には、ページ階層を要素に分割し、要素間の関係（コンテナ内の要素のドッキングや適用可能な暗黙のアンカーの作成など）を決定し、テキストコンポーネントとイメージコンポーネントを「イメージ＋キャプション」の一対として識別するなど、関連する場合は、可能な限りまとめて処理および移動する必要があるページ要素を大きなグループにグループ化することが含まれる。

ページアナライザ３３０２は、すべてのカテゴリ（ＢＥＨ、ＪＳＨ、およびＧＲＢトリガ）の将来のトリガをどのように処理するかについての予備解析を実行することもできる。

ページアナライザ３３０２は、ページおよびそのコンポーネントの基本的な幾何学的特性（サイズ、位置、オーバーラップ、近接、レイヤなど）だけでなく、ＣＭＳ５０に格納されている他のＷＢＳ属性および利用可能な情報（編集履歴、拡張ＷＢＳコンポーネント属性など）も考慮に入れることができる。

ページアナライザ３３０２は、米国特許第１０，１７６，１５４号のプリプロセッサ２０１およびスーパーノードクリエータ２３０で定義されているようなグループ化解析技術を使用することができる。これらの要素は、コンポーネントの接続（コンテンツの解析、編集履歴、その他のコンポーネントの関係など） を決定する場合がある。これは、例えば、一緒に留まっているときにより良く見えるコンポーネントのクラスタを検出するために使用することができる。

ページアナライザ３３０２はさらに、ＭＬ／ＡＩエンジン３５０を使用して、そのようなページ解析およびコンポーネントグループ認識をサポートすることができる。ページ解析は、再帰的、すなわち、ページレベルで、ならびにページ内のコンテナに対して実行されてもよいことが理解され得る。

解析は、より早い段階、例えば、編集または公開中に（完全にまたは部分的に）実行されてもよいことがさらに理解され得る。したがって、メッシュアプライヤ３３０は、ページサービングステージだけでなく、編集または公開中にコンポーネント関係を検出することができる（および暗黙のアンカーを生成することができる）。これにより、システム２００は、推測された（暗黙的である）アンカーに関する情報を編集中にユーザに提供することができ、ユーザは、そのようなアンカーの作成または属性に対するフィードバック、指示およびヒントを編集または他の方法で提供することができる。そのようなフィードバックは、例えば、暗黙のアンカー定義を修正するために、またはＭＬ／ＡＩエンジン３５０のためのフィードバックを提供するために使用され得る。

ページアナライザ３３０２はまた、（例えば、ページ実行／閲覧中に）オンラインで実行されてもよい。例えば、ランタイム中のコンポーネントへの変更は、ページの再解析を必要とし、その結果、ページへの変更を必要とすることがある（おそらく、完全または部分的な再生成およびページ再ロードを必要とする）。これは、同時変更（例えば、ページの実行中に他のユーザによって行われた変更）や、ページ内で実行された変更（例えば、関連するコードの変更、あるいは、ユーザのコメントを追加することができるブログシステムのような、エンドユーザがページを変更する可能性がある場合）に適用される可能性がある。

ページコンバータ３３０３は、ページアナライザ３３０２の出力を使用して、入力ページをそれに応じて変換することができる。

ページコンバータ３３０３は、ＢＥＨトリガの処理を実施するページのためのＣＳＳグリッド定義を生成することができる。作成されたグリッドは、オブジェクトフレームを、（以下に説明するように）スプリッタに取り付けられたセルまたは結合セルのセットに変換することができる。作成されたグリッドは、追加の技術を使用して、後述する余分な行およびウェッジなどのさらなる動的レイアウト処理をサポートすることができる。

変換されたページには、明示的なアンカーやその他のトリガタイプを処理するために必要なＪＳコードや関連する埋め込みデータなど、追加のコードおよび要素も含まれる場合がある。

ここで、ページコンバータ３３０４のサブ要素を図示する図２２を参照する。ページコンバータ３３０４は、スプリッタプレイサ３３０４１およびメッシュグリッドジェネレータ３３０４２をさらに含んでもよい。

スプリッタプレイサ３３０４１は、グリッドを作成する水平スプリッタを使用して、暗示的動的レイアウトアンカーを置換してもよい。各コンテナがグリッド（各コンテナはそれ自体のグリッドを有する）によって表されるように、スプリッタはコンテナごとであり、スクリーンごとではないことが理解され得る。以下の説明では、水平スプリッタに焦点を当てるが、垂直スプリッタも実施することができる。

コンポーネント間の暗黙のアンカーの代わりに、ページコンバータ３３０４は、コンポーネントをグリッドにアンカーすることができることが理解され得る。これは、ＣＳＳジェネレータ３２０によるより効率的な実行を可能にすることができる。

スプリッタは、コンポーネントをレイアウトに固定するために使用され得る仮想線であることが理解され得る。スプリッタによって固定されているコンポーネントは押して引っ張ることがあり、同じスプリッタに固定されている他のコンポーネントは、結果として生じるスプリッタの動きに影響されることがある。１つのページまたはコンテナに対して複数のスプリッタが定義されている場合がある。スプリッタは通常、ＪＳが不要になるように宣言型ＣＳＳメカニズムを使用して実装される。

いくつかのコンポーネントは、いくつかのスプリッタへの変更によって影響を受けない併合グリッドセル内に存在し得るので、スプリッタは、いくつかのコンポーネントのみに影響を及ぼし得る。典型的な構成では、コンポーネントＡは、Ａが終了した後にＢが開始する場合にのみコンポーネントＢを押す。また、コンポーネントの高さは、その内容によってのみ変更される。コンテナについては、これは、含まれるコンポーネントによって影響されることを含む。

次に、コンポーネントとスプリッタとの間の関係を示す図２３を参照すると、コンポーネント［ａ］～［ｇ］およびスプリッタ１～５が示されている。図からわかるように、成分［ａ］は、スプリッタ１の変化によってのみ影響を受け、その高さは、そのコンテンツによって制御され、他の成分によっては制御されない。

コンポーネント［ｂ］はスプリッタ１ によってプッシュされる。

成分［ｃ］は、スプリッタ１および３によってプッシュされる。

コンポーネント［ｄ、ｅ、ｆ、ｇ］に関しては、各コンポーネントは、それらの「上」にあるすべての行によってプッシュされる。

任意のコンポーネント（または以下でより詳細に論じるウェッジ）を拡大または縮小することによって、グリッド内の線を上下に移動させることができることが理解され得る。このように、コンポーネントの位置は、スプリッタの移動に基づいて修正され得る。

グリッドセル内のコンポーネントは、複数の側面（例えば、グリッドセルの上面および底面）に固定されてもよく、セルサイズが変更するにつれて伸張／収縮してもよいので、同じことがコンポーネントサイズにも適用されてもよい。スプリッタプレイサ３３０４１は、そのようなアンカーを自動または明示的なアンカーとして実装することができる。

スプリッタプレイサ３３０４１はまた、ここで参照される図２４Ａおよび２４Ｂに示されるように、コンポーネント「列」間の関係をプッシュすることによって、ユーザがこれを行うことを可能にし得る。図２４Ａは、コンポーネントａ１がコンポーネントａ２の上にあり、コンポーネントｂ１がｂ２の上にある（４つのコンポーネントが２行に整列している）状況を示す。ユーザは、コンポーネントａ１がコンポーネントａ２をプッシュし、コンポーネントｂ１がｂ２をプッシュすることを望むが（それらが伸張するとき）、コンポーネントａ１がコンポーネントｂ２をプッシュすること、またはコンポーネントａ２がコンポーネントｂ１をプッシュすることを望まない。

スプリッタプレイサ３３０４１が、行１（Ｒｏｗ１）と行２（Ｒｏｗ２）との間を通過する単一のスプリッタＳ１を配置する場合、下方に伸張するコンポーネントａ１もコンポーネントｂ２をプッシュする。これを防止するために、スプリッタプレイサ３３０４１は、図２４Ｂに示されるように、［ｃ］ラッピングコンポーネントａ１／ａ２および［ｄ］ラッピングコンポーネントｂ１／ｂ２とともに、２つの不可視ボックス／グループ（それぞれが、それ自身のグリッドを有する）を構築してもよい。両方のボックスは、囲みフレームＫに含まれており、このように、コンポーネントａ１とａ２との間、およびコンポーネントｂ１とｂ２との間には、別々のプッシング関係がある。

ページアナライザ３３０３がページを解析し、ページコンバータ３３０４がページの基礎となるＣＳＳグリッド定義を生成すると、ページをレンダリングし、表示することができることが理解され得る。ページアナライザ３３０３およびページコンバータ３３０４は、他のステージ中にも機能することができ、必ずしもレンダリングを必要としないことがあることが理解され得る。メッシュアプライヤ３０３は、ここで、様々なイベントおよびトリガに応答することができる。これらは、上述の様々なトリガタイプＢＥＨ、ＪＳＨ、およびＧＲＢを含むことができる。

ＢＥＨトリガ（およびその結果のコンポーネントサイズ／位置の変更）は、ページ変更下のＣＳＳグリッドの動作を制御するブラウザ実施ルールに基づいて、ブラウザによって処理される。

次に、ＣＳＳグリッドルールのスプリッタおよびコンポーネントへの適用を示す図２５を参照する。図２５は、３つのコンポーネント（Ａ、Ｂ、およびＣ）を有する構成を示し、シナリオＩは、それらの初期状態を示す。シナリオＩＩでは、コンポーネントＣは下方に拡大される。既定のＣＳＳグリッドルールでは、コンポーネントＣはスプリッタ＃３を下にプッシュし、サイズの増大は１番目と２番目のグリッド行の間で均等に分割され（したがって、スプリッタ２はその半分だけ下に移動）、コンポーネントＢが下に移動する。メッシュグリッドジェネレータ３３０４２は、グリッドを再計算してもよい。より高いレベルのＪＳコードの関与を必要とせずに、ブラウザエンジン内で動作全体を実行することができることが理解され得る。

その他のトリガタイプもブラウザエンジン内で解決されない。ＪＳＨトリガは、ＪＳコードを実行する必要がある。このコードは、ページの要素を変更する可能性がある（ＤＯＭ構造を変更するなど）。また、フォローアップページの再計算が必要である。ＪＳコードは、ＷＢＳレベル（例えば、ＷＢＳクライアントコードの一部）であってもよいし、特定のページ関連ＪＳコードの一部（例えば、ページ関連機能）であってもよい。

いくつかの変更（ページコンポーネント階層への変更など）は、ＧＲＢトリガをトリガすることができ、メッシュグリッドジェネレータ３３０４２によるグリッド再生成（完全または部分的）と、ＣＳＳジェネレータ３２０によるページの再レンダリングとを必要とする。

ＣＳＳグリッドの定義がＷ３標準であるので、その挙動はプラットフォーム／ブラウザ／バージョン間で均一であることが理解されるであろう。したがって、メッシュグリッドジェネレータ３３０４２は、任意のバグおよび実装の問題、または将来発生する可能性がある任意の差異を補償することができる。

本明細書で上述したように、ページアナライザ３３０３は、幾何学的特性（サイズ、位置、重なり、近接、層）ならびに入手可能なＷＢＳ２００属性およびＣＭＳ５０に格納された他の入手可能な情報に基づいて、その解析を実行することができる。この解析は、要素の構造およびレイアウト、ならびにそれらの間の暗黙のアンカー／関係（米国特許第１０，１８５，７０３号で言及されるゲートウェイ条件と同様）を決定する。この解析に基づいて、メッシュアプライヤ３３０は、コンポーネント間の関係（「ＡがＢをプッシュする」など）を作成するために使用されるスマートメッシュを作成することができることが理解され得る。

当然のことながら、このスマートメッシュは、いくつかのレベルで実施することができる。例えば、限定された「プッシング行」の実装は、プッシング挙動を提供する複数の行を有するコンテナ当たり単一の列を有するＣＳＳグリッドを使用することができる。より包括的な実施では、複数の列を持つＣＳＳグリッドを使用できる。

次に、コンポーネントの距離とその結果として生じるドッキング効果の例を示す図２６を参照する。図示のように、コンポーネント［ｘ］は右下隅にあり、他のコンポーネント［ａ～ｄ］から十分に離れている。ページアナライザ３３０３は、［ｘ］が、包含フレームの右下に位置合わせされるように意図され、暗黙のアンカー［ｐ］および［ｑ］を有するべきであることを（その解析に基づいて）決定することができる。この効果（「ドッキング」として知られる）は、本明細書で上述したように、編集ハンドラ３１０によって実行される解析の一部であってもよく、または後の解析の一部であってもよい（例えば、発行中またはページロード中）。

ここで、別のプッシングシナリオを示す図２７を参照する。コンポーネント［Ａ］および［Ｂ］は［Ｃ］より上である。もしコンポーネント［Ａ］または［Ｂ］のいずれかが、コンポーネント［Ｃ］から十分に小さい距離［ｄ］まで伸張するならば、それらはコンポーネント［Ｃ］を押し下げるであろう。これは、ここでは、暗黙のアンカーのアクティブ化として参照される。

ユーザは、（例えば、応答エディタ３１０を介してそのような命令を提供することによって）Ｂ－Ｃの暗黙アンカーを取り消し／無効にしながら、Ａ－Ｃの暗黙アンカーをそのまま残したい場合がある。これを実施するために（ここで参照がなされる図２８に示されるように）、メッシュグリッドジェネレータ３３０４２は、コンポーネント［Ａ］および［Ｃ］を透明容器［ｙ］およびコンポーネント［Ｂ］の内部に別個の透明コンテナ［ｘ］に入れてもよい。［ｘ］および［ｙ］の両方は、フレーム［ｆ］内に並列に存在することができ、（それらの領域は重複するが）コンポーネントツリー内の兄弟である。したがって、コンポーネント［Ｂ］が伸張するとき、それはコンポーネント［Ｃ］に影響しない。

コンポーネントのオーバーラップに関しては、メッシュグリッドジェネレータ３３０４２は、コンポーネントがアレイに保持され、常に順序付けられる、暗黙のｚオーダー配列を採用してもよい。この順序は、ＨＴＭＬのレンダリング時に使用される。したがって、後の要素がＨＴＭＬに表示されるほど、その要素のｚオーダーが高くなる（兄弟関係となるものが重なり合っている場合）。

また、メッシュグリッドジェネレータ３３０４２は、複数のコンポーネントを、生成されたグリッド内の単一のグリッドセルに配置してもよく、セル内のそれらの順序、配置、および整列を制御するために、複数の機構を使用してもよい。

特に、グリッドＣＳＳは、複数のコンポーネントが各セルに割り当てられることができるので（例えば、固定配置コンポーネントを使用して）、それを含むセル内の各要素の座標の指定を可能にする。グリッドＣＳＳはさらに、各コンポーネントの位置合わせおよびドッキングに関するガイダンス（例えば、コンポーネントがセル内でどのように位置合わせされるか）を指定することを可能にする。これにより、ＤＯＭ順序（つまり、元のファイルテキスト内のオブジェクトの順序）に従ってｚオーダーが定義された、重複するコンポーネントが可能になる。メッシュグリッドジェネレータ３３０４２はまた、この目的のためにＣＳＳのｚ－インデックス属性を使用してもよい。

上述のように、メッシュグリッドジェネレータ３３０４２は、コンポーネント配置およびセルコンテンツ管理のための代替レイアウト方法または他のメカニズムを使用することもできる（リストまたはリピータタイプのコンポーネントのためにフレックスボックスレイアウトを使用するなど）。

メッシュグリッドジェネレータ３３０４２は、グリッドの粒度と、単一グリッドセル内の複数要素の配置との均衡を保つことによって、レイアウト挙動を最適化してもよい。それは、特定の配置／レイアウトに対する挙動を最適化するために、より多くの又はより少ないセルに分割することができる。これは、特定のブラウザ／プラットフォーム／バージョン性能特性に依存し得る（例えば、メッシュグリッドジェネレータ３３０４２は、異なるブラウザに対して異なるグリッドの組み合わせを生成し得る）。

ここで、要素レイアウトを維持するための余分なラインの使用を示す図２９Ａ～Ｃを参照する。図２９Ａに示されるように、コンポーネント［Ａ］は、格子列Ｒ１に配置され、格子列Ｒ２にコンポーネント［Ｂ］が配置される。成分［Ｃ］は、両方の行（Ｒ１およびＲ２）にわたって伸びる。

コンポーネントが１行を超えて広がり、コンポーネントが伸張するとき、グリッド実装は、このコンポーネントが広がっているすべての行にわたる余分なスペースをどうするかを決定する必要がある。（全てのコンポーネントが正確に１行に属する場合（行スパニングなし）、問題は生じない。

この例では、コンポーネント［Ｃ］が（例えば、そのテキスト内容のサイズが増大するために）下方に伸張すると、ラインＬ３を下方にプッシュする（グリッド行Ｒ２の最下行）。ＣＳＳグリッドの規則的な挙動は、コンポーネントＲ１およびＲ２の両方のサイズを等しく増加させ、［Ａ］および［Ｂ］がそれらのそれぞれのコンポーネントの一部のみを占有するようにし（図２９Ｂに示されるように）、それによって視覚レイアウトを破壊することである。

エクストラロウ（extra row）ジェネレータ３３０４４は、不可視の余分な行Ｒ３を追加することによって、これを（図２９Ｃに示されるように）解決してもよい。コンポーネント［Ｃ］は、行Ｒ３まで伸びるようにされ、その結果、［Ｃ］が伸びるとき、Ｒ１およびＲ２に影響を及ぼすことなく、Ｒ３のサイズを増加させるだけである。

この余分なラインが定義されていても、グリッドのデフォルト動作は、３つの行（Ｒ１、Ｒ２、およびＲ３）の間の追加されたスペースを分割することであることが理解され得る。これを防止し、追加スペースがＲ１およびＲ２のみに行くことを確実にするために、メッシュグリッドジェネレータ３３０４２は、「レギュラー」行（この場合、Ｒ１およびＲ２）が「最小コンテンツ」行として定義され、追加行（Ｒ３）が「１ｆｒ」（分数）行として定義されるグリッドを生成する。

エクストラロウジェネレータ３３０４４は、最小量の要素を含む行を選択する標準的なグリッド空間処理アルゴリズムを実装することができる。その後、余分なスペースは、これらの選択された行の間で均等に分割される。したがって、エクストラロウジェネレータ３３０４２は、「余分な行」を生成することができ、これにより、余分なスペースを受け取る行が常に正確に１つ（余分である）存在することが保証され、デザインが保存される。

これらの余分な行は、応答エディタ３１０における予想される動的レイアウト挙動のユーザの仕様に基づいて事前に作成されることが理解され得る。この仕様は、コンポーネントが下方に拡張しないことを指定する「逆アンカー」と見なすことができる。

グリッドへの変換は、ここで参照がなされる図３０に図示されているようなウェッジ要素を用いることもできることが理解され得る。これは、特定のスプリッタを適所に保持し、それによって所与の行に対して最小のＹ値を維持する不可視の「ウェッジオブジェクト」の使用である。

ウェッジジェネレータ３３０４３は、ウェッジ要素を目に見えないようにするために、静的高さ（例えば、５００ｐｘ）およびゼロ幅（０ｐｘ）を有するＤＩＶ要素を使用して、ウェッジ要素を実装してもよい。

図３０に示すように、スプリッタＬ３は、ウェッジオブジェクト［Ｗ］によって予め指定されたＹ値で「所定の位置に保持」される。コンポーネント［Ｂ］は、Ｌ３ラインに到達するまで下向きに伸張することができる。コンポーネント［Ｂ］がＬ３に達すると、Ｌ３を下方向にプッシュし始めることがある（ウェッジ［Ｗ］の端部よりも低く動かす）。コンポーネント［Ｂ］が収縮して戻ると、Ｌ３はウェッジ［Ｗ］に到達するまで戻り、そこで停止する。したがって、ウェッジ［Ｗ］は、行Ｒ２をある最小サイズに保つ。

ウェッジジェネレータ３３０４３は、基本的に、ソフトアンカー（例えば、コンポーネント［Ｂ］の底面とＬ３との間）を形成し、その結果、Ｌ３は、ある点より上に上がらない。

ＣＳＳグリッドで実施されるメッシュアプライヤ３０３の実施形態では、内部ＣＳＳグリッドメカニズムは、いくつかの明示的なアンカータイプのための十分なサポートを提供しないことがある。

場合によっては、特に、アンカーおよび「短いアンカー」は、要素のグループを作成するコンテキストで使用される。例えば、ユーザは、製品名、説明図、および価格を表示するコンポーネントなど、一緒になって製品説明を形成する１組の要素をグループ化することができる。ユーザは、それらの全てを一緒に固定して、それらの結合されたレイアウトを保持し、編集時に一緒に移動することができる。

このような配置は、（例えば、ページアナライザ３３０３が、応答エディタ３１０に挿入されたヒント、またはテンプレートレベルでより早く挿入されたヒントを使用することによって）検出することができる。次いで、コンポーネントの配置は、明示的に定義されたグループに変換されてもよく、このグループは、軽量コンテナを使用して実装されてもよい。そのようなグループコンテナは、依然として、その子供関係にあるものをレイアウトするための内部グリッドを有し、したがって、それは、実際のコンテナを入れ子にするのと同様に挙動する。グループは、典型的には、単一のコンポーネントと見なされ、そのコンポーネントが「分解」しないように実装されてもよい。

ここで、参照する。図３１は、ＣＳＳグリッドおよびメッシュグリッド構造を使用して典型的に実装することができない長距離アンカーＡＢを示す。このシナリオでは、メッシュアプライヤ３３０は、関連するＪＳコードのフォローアップローディングによってＣＳＳグリッドで行うことができることを補完することができる。ＪＳコードは、ページ要素を測定し、追加のインタラクションを実装できる。ＪＳコードはフィールドとレイアウトの変更（例えば、ＪＳ ｏｎＣｈａｎｇｅ（）または同様のメカニズムを介して）を聞き、アンカーターゲットを明示的に変更することができる。

したがって、レイアウト、ウェッジ、およびスプリッタなどの特殊化された要素の使用とともに、流動コンポーネントおよびメッシュグリッドの使用は、ＷＢＳが、ウェブサイトの作成および編集のアクセス、編集、保存、公開段階でスマートＣＳＳ生成を組み込むことを可能にし得る。このスマートＣＳＳは、より良いページ読み込みと処理時間を提供する一般的なランタイムコンパイルを必要とせずに、ブラウザレベルでのレンダリングを可能にすることがある。さらに、システムは、ブラウザアドオンまたはプラグイン、ブラウザ拡張、ポリフィルまたはブラウザ機能を拡張または強化することを意図した他の要素などの要素を含む、異なるブラウザとインターフェースするための追加の要素を含むことができる。

したがって、レイアウト、ウェッジ、およびスプリッタなどの特殊化された要素の使用とともに、流動コンポーネントおよびメッシュグリッドの使用は、ＷＢＳが、ウェブサイトの作成および編集のアクセス、編集、保存、公開段階でスマートＣＳＳ生成を組み込むことを可能にし得る。このスマートＣＳＳは、より良いページ読み込みと処理時間を提供する一般的なランタイムコンパイルを必要とせずに、ブラウザレベルでのレンダリングを可能にすることがある。

特に明記しない限り、本明細書全体を通して、「処理する」、「演算する」、「計算する」、「決定する」などの用語を利用する議論は、コンピューティングシステムのレジスタおよび／またはメモリ内のデータを、コンピューティングシステムのメモリ、レジスタ、または他のそのような情報記憶、伝送、または表示デバイス内の他のデータに操作および／または変換する、クライアント／サーバシステム、モバイルコンピューティングデバイス、スマートアプライアンス、クラウドコンピューティングユニット、または同様の電子コンピューティングデバイスなど、任意のタイプの汎用コンピュータの作用および／またはプロセスを指すことが理解される。

本発明の実施形態は、本明細書の動作を実行するための装置を含むことができる。この装置は、所望の目的のために特別に構築されてもよく、または、コンピュータに格納されたコンピュータプログラムによって選択的に起動または再構成される、典型的には少なくとも１つのプロセッサおよび少なくとも１つのメモリを有するコンピューティングデバイスまたはシステムを備えてもよい。結果として得られる装置は、ソフトウェアによって命令されると、汎用コンピュータを、本明細書で説明されるような発明的要素に変えることができる。命令は、それが望まれるコンピュータプラットフォームと共に動作する本発明のデバイスを定義することができる。そのようなコンピュータプログラムは、光ディスク、磁気光ディスク、読出し専用メモリ（ＲＯＭ）、揮発性および不揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、電気的にプログラム可能な読出し専用メモリ（ＥＰＲＯＭ）、電気的に消去可能およびプログラム可能な読出し専用メモリ（ＥＥＰＲＯＭ）、磁気または光カード、フラッシュメモリ、ディスクオンキー、または電子命令を記憶するのに適し、コンピュータシステムバスに結合することができる任意の他のタイプの媒体を含むが、これらに限定されない、任意のタイプのディスクなどのコンピュータ可読記憶媒体に記憶することができる。コンピュータ可読記憶媒体は、クラウド記憶装置に実装することもできる。

一部の汎用コンピュータは、データネットワークおよび／または移動通信ネットワークとの通信を可能にするために、少なくとも１つの通信要素を含んでもよい。

本明細書で提示されるプロセスおよび表示は、本質的に、任意の特定のコンピュータまたは他の装置に関連するものではない。様々な汎用システムが、本明細書の教示によるプログラムと共に使用されてもよく、または、所望の方法を実行するために、より特殊化された装置を構築することが便利であることが判明してもよい。様々なこれらのシステムのための所望の構造は、以下の説明から明らかになるであろう。さらに、本発明の実施形態は、任意の特定のプログラミング言語を参照して説明されない。本明細書に記述されるように、本発明の教示を実装するために、様々なプログラミング言語が使用され得ることが理解される。

本発明の特定の特徴が本明細書に例示され、説明されてきたが、多くの修正、置換、変更、および同等なが、当業者には今や思い浮かぶであろう。従って、特許請求の範囲は、そのような修正及び変更全てを本発明の技術思想及び技術的範囲に含まれるものとして保護することを意図していることを理解されたい。

Claims (16)

1. ウェブサイト構築システム（ＷＢＳ）であって、
   プロセッサと、
   流動コンポーネントおよび非流動コンポーネントのレイアウトを有する現在のビューポートに表示されるウェブサイトページをメッシュグリッド構造に変換し、ブレークポイント範囲に従って前記メッシュグリッド構造の編集およびレンダリングを提供するために、前記プロセッサ上で実行される応答編集モジュールと、
   を備え、
   前記応答編集モジュールは、
   少なくとも１つの入力トリガおよび更新されたビューポートの大きさを受信し、前記更新されたビューポート上に表示される流動コンポーネントおよび非流動コンポーネントを有する、更新されたレイアウトを生成する応答エディタと、
   人工知能（ＡＩ）および機械学習（ＭＬ）技術を用いて、少なくとも１つの入力トリガおよび少なくとも１つの機械学習フィードバックモジュールに従って、前記応答エディタの前記ブレークポイント範囲に適合するように前記レイアウトを自動的に適合させる少なくとも１つのＡＩ／ＭＬエンジンと、
   を有する、
   ウェブサイト構築システム。
2. 前記少なくとも１つのＡＩ／ＭＬエンジンは、さらに、ウェブサイトのコンポーネント情報、ビジネス情報および前記ウェブサイトの編集履歴、の少なくとも１つを用いて訓練される、
   請求項１に記載のウェブサイト構築システム。
3. 前記ＡＩ／ＭＬエンジンは、編集および保存中にレイアウト定義の解析を行い、ユーザの意図を検出し、ユーザの意図をルールの宣言設定に変換する、
   請求項１に記載のウェブサイト構築システム。
4. 前記ＡＩ／ＭＬエンジンは、ドラッグアンドドロップデザインをフルＣＳＳ（カスケードスタイルシート）に変換する、
   請求項１に記載のウェブサイト構築システム。
5. 前記少なくとも１つの入力トリガに関連付けられた、動的レイアウトルールおよび応答編集ルールに応じて、前記レイアウト用のレイアウト決定を提供するルールエンジンと、
   前記レイアウトを、前記メッシュグリッド構造に変換するメッシュアプライヤと、
   前記メッシュグリッド構造の特徴を前記更新されたビューポート用のＣＳＳ（カスケードスタイルシート）にマッピングするＣＳＳジェネレータと、
   を含む、
   請求項１に記載のウェブサイト構築システム。
6. 前記少なくとも１つの入力トリガは、ユーザ編集、システム変更、ユーザプロパティの変更、ユーザ／デバイス相互作用変更、第２のユーザによる同時編集、システムの手続き変更およびユーザ環境の変更の少なくとも１つである、
   請求項１に記載のウェブサイト構築システム。
7. 前記応答エディタは、
   少なくとも１つの前記入力トリガを受信する編集レシーバと、
   少なくとも１つの前記入力トリガおよび前記更新されたビューポートの大きさに応じて前記レイアウトの前記流動コンポーネントおよび前記非流動コンポーネントに対する変更を定義する編集ハンドラと、
   前記更新されたビューポート用のブレークポイント範囲内における異なるブレークポイントでユーザにレイアウトをプレビューすることを可能にするプレビューワと、
   をさらに含む、
   請求項１に記載のウェブサイト構築システム。
8. 前記編集ハンドラによる所定のアクションにおいて前記ユーザに説明を提供し、前記ＡＩ／ＭＬエンジンに応じた編集において前記ユーザに解決策または提案を提示するエクスプレーナおよびサジェスタをさらに有する、
   請求項７に記載のウェブサイト構築システム。
9. 流動コンポーネントおよび非流動コンポーネントのレイアウトを有する現在のビューポートに表示されるウェブサイトページをメッシュグリッド構造に変換することと、
   ブレークポイント範囲に従って前記メッシュグリッド構造の編集およびレンダリングを提供することと、
   を有し、
   前記変換することおよび前記提供することは、
   少なくとも１つの入力トリガおよび更新されたビューポートの大きさを受信することと、
   前記更新されたビューポート上に表示される流動コンポーネントおよび非流動コンポーネントを有する、更新されたレイアウトを生成することと、
   少なくとも１つの入力トリガおよび少なくとも１つの機械学習フィードバックモジュールに従って、前記更新されたレイアウトを生成することにおける前記ブレークポイント範囲、に適合するように前記レイアウトを自動的に適合させるために、人工知能（ＡＩ）および機械学習（ＭＬ）技術を用いることと、
   を含む、
   方法。
10. 前記ＡＩおよびＭＬ技術を用いることは、さらに、ウェブサイトのコンポーネント情報、ビジネス情報および前記ウェブサイトの編集履歴、の少なくとも１つを用いて訓練することを含む、
    請求項９に記載の方法。
11. 前記ＡＩおよびＭＬ技術を用いることは、編集および保存中にレイアウト定義の解析を行うことと、ユーザの意図を検出することと、ユーザの意図をルールの宣言設定に変換することとを含む、
    請求項９に記載の方法。
12. 前記ＡＩおよびＭＬ技術を用いることは、ドラッグアンドドロップデザインをフルＣＳＳ（カスケードスタイルシート）に変換することを含む、
    請求項９に記載の方法。
13. 前記少なくとも１つの入力トリガに関連付けられた、動的レイアウトルールおよび応答編集ルールに応じて、前記レイアウト用のレイアウト決定を提供することと、
    前記レイアウトを、前記メッシュグリッド構造に変換することと、
    前記メッシュグリッド構造の特徴を前記更新されたビューポート用のＣＳＳ（カスケードスタイルシート）にマッピングすることと、
    をさらに含む、
    請求項９に記載の方法。
14. 前記少なくとも１つの入力トリガは、ユーザ編集、システム変更、ユーザプロパティの変更、ユーザ／デバイス相互作用変更、第２のユーザによる同時編集、システムの手続き変更およびユーザ環境の変更の少なくとも１つである、
    請求項９に記載の方法。
15. 前記受信することおよび前記生成することは、
    少なくとも１つの前記入力トリガおよび前記更新されたビューポートの大きさに応じて前記レイアウトの前記流動コンポーネントおよび前記非流動コンポーネントに対する変更を定義することと、
    前記更新されたビューポート用のブレークポイント範囲内における異なるブレークポイントでユーザにレイアウトをプレビューすることを可能にすることと、
    をさらに含む、
    請求項９に記載の方法。
16. 前記変更を定義することによる所定のアクションにおいて前記ユーザに説明を提供することと、
    前記ＡＩおよびＭＬ技術を用いることに応じた編集において前記ユーザに解決策または提案を提示することと、
    をさらに含む、
    請求項１５に記載の方法。
    
    

Images