以下の詳細な説明では、本発明の完全な理解を提供するために多くの具体的な詳細について述べる。しかしながら、当業者には、本発明がこれらの特定の詳細なしに実施され得ることが理解されるであろう。他の例では、周知の方法、手順、およびコンポーネントは、本発明を曖昧にしないように詳細には説明されていない。
従来技術の応答性編集システムは、通常、ウェブサイトまたはページレベルで作動し、ウェブサイトのサイズを調整するための予め定義された固定ブレークポイントを有し、限られた数のビューポート(画面、ディスプレイおよびウインドウを含む)で応答性の高い編集を可能にする。(サイズまたは位置を変更するコンポーネントのように)サイトが変更されるとき、その変更は、(単一のブレークポイント範囲内の)ブレークポイント間で連続的であることが理解され得る。ブレークポイントが交差すると、非連続的な変化が起こり、コンポーネントが1つの位置から別の位置にジャンプすることがある(例えば、スクリーン幅が収縮するとき、コンポーネントAがコンポーネントBの上を並べて移動することがある)。コンポーネントもまた、ブレークポイントが交差するときに現れ、消えることがある。
ウェブデザイナが自分のブレークポイントを完全に制御する、すなわち自分自身のレンジを定義することができる場合、ブレークポイント範囲のサイズを連続的に処理することができ、より広い範囲のビューポートにわたって自分のウェブサイトを表示するためにデザインを変更することによって処理されるという知識をもってウェブサイトを効果的にデザインすることができることに本出願人は見出した。これにより、ユーザは、複数サイズのサイトをより効果的に作成し、処理することができる。
さらに、階層コンポーネントベースのシステムに適した応答エディタ、すなわちコンポーネントレベルでのハンドル機能が、ブレークポイントが、任意の実装された階層とともに、ページレベルだけでなく、プリセットレベルおよびコンテナレベルでも(たとえば、そのサブ要素のドッキングのためにコンテナコンポーネントレベルで応答編集グリッドを使用して)処理され得ることを保証し得ることを本出願人は見出した。したがって、デザイナが自分自身のブレークポイント範囲を定義する能力は、画像の使用を「バックグラウンド」から「フローティング」に切り替えること、複数の焦点(各ブレークポイントごとに1つ)を適用する能力、およびブレークポイント範囲ごとに異なるクロッピングパラメータを提供する能力など、デザイナに自分のメディアに対する完全な制御を与えることができる。
応答編集コンポーネントが流動であると考えられ、したがって、ウェブサイト編集中に発生する可能性のある動的レイアウトトリガおよびイベントに応答することができることを、本出願人はさらに見出した。レイアウトは、そのサイズおよび属性が親によって(例えば、親の変更またはビューポート幅の変更によって)または追加のトリガによって影響され得る流動コンポーネントを組み込み得る。効果は、システムによって自動的に決定することができ、ユーザによって指定または編集することもできる(例えば、コンポーネント幅は、親コンポーネント幅の所与のパーセンテージまたは関数である)。
ユーザのレイアウトをすべてのブレークポイントに最も良く適合するように自動的に適合させるためにユーザがどのように機能するかを理解する等、ユーザ作業の態様を容易にするための機械学習(ML)および人工知能(AI)技術およびモデルの使用が、本明細書で上述した応答編集システムに統合されてもよいことを、本出願人はまた見出した。これは、ユーザの意図を理解し、検出することによってセクションおよびコンポーネントを提供するシステムを含むことができる。本システムは、WBSにおいて利用可能な情報、例えば、ウェブサイトコンポーネント情報、ビジネス情報、編集履歴、および他のサイト関連情報、ならびに、本出願人によって共有され、参照によって本明細書に組み込まれる、2020年12月3日に公開された「System and Method for Integrating User Feedback into Website Building System Services」という名称の米国特許公開第2020/0380060号に記載されているようなWBSベースのトレーニングフィードバックを使用して、いくつかのML/AIエンジンを使用して、その目標を達成し得る。
本出願人はさらに、ルールベースおよびML/AIエンジンのアプリケーションを使用して、システムがドラッグアンドドロップデザインをフルCSSに変換し、ブレークポイントの最良適合位置を理解する完全なデザイン表現能力を提供することもできることを見出した。これは、応答デザインおよび流動コンポーネントをサポートし、ターゲットデザインのブレークポイントにさらに適応することができるパッケージ化されたレイアウトも含むことができる。
したがって、応答編集機能を、背景技術で説明したウェブサイト構築システムのプロセスと組み合わせることができ、説明したレイアウト要素を、応答サイトを構築するために適合させることができる。
さらに、出願人はまた、上述の機能性が、既存の応答しないウェブサイト(すなわち、ブレークポイントのないウェブサイト)が、ウェブブラウザおよび他のクライアントシステム上で効率的に実装され得るスマートメッシュ形式に変換またはレンダリングされる場合、それらにも適用され得ることを見出した。この能力は、既存のWBSサイト、または他のシステムからインポートされたサイトに適用することができる。したがって、スマートメッシュ構造は、(応答性および流動性を有する)サイトを宣言的に定義するために使用することができる。このようにして、ブラウザは、(例として)ブラウザエンジン内部の幅の変化に応答してもよい(例えば、CSS処理および表示レンダリングの一部として)。このプロセスは、グループ検出およびアンカー生成などのWBSコンポーネントプロパティ(幾何学的/非幾何学的)および蓄積された情報(編集履歴および収集されたBIなど)タスクの解析に基づいて、効果的な動的レイアウト操作のための推論および解析を提供することができる。
図3を参照すると、本発明の実施形態に従って構成され、動作する応答エディタモジュールを使用して、ウェブサイトの作成、閲覧、および編集のためのシステム200が示される。システム200は、応答編集モジュール300と共に、米国特許第10,073,923号に記載されているようなシステム100の要素(並びに任意のサブ要素)を含むことができる。代替実施形態では、システム200は、WBSエディタ30、サイト生成システム40、および応答編集モジュール300の機能を組み合わせる統合モジュール、またはWBSエディタ30の機能と応答編集モジュール300のみを組み合わせるモジュールを提供することができる。
以下の議論は、システム200が特定のクライアントソフトウェアを使用してアクセスされる他のカテゴリのオンライン・アプリケーションに完全に適用可能であるが、WBSによって作成され、エンドユーザによってウェブサイトとしてアクセスされるアプリケーションを指すことが理解され得る。このようなクライアントソフトウェアは、スタンドアロンで実行することも、ブラウザ(Adobe Flashプラグインなど)からアクティブ化することもできる。エンドユーザは、通常のPC上のクライアントソフトウェア(図2に示したように、現在参照されている)だけでなく、スマートフォン、タブレットコンピュータ、その他のデスクトップ、モバイル、またはウェアラブルデバイス上でも、これらのウェブサイトにアクセスすることができる。あるいは、本明細書の記載は、2018年6月12日に付与され、出願人が共有し、参照により本明細書に組み込まれる「コンポーネントの階層に基づく意味的構成に関連する視覚的データ構造を生成するための視覚的設計システム」と題する米国特許第9,996,566号に記載されているように、モバイルアプリケーション、ネイティブアプリケーション、または他のアプリケーションタイプを生成または編集するシステムに適用することができる。
さらに、以下の議論は、(システム200を実施する)ウェブサイト構築システムプロバイダによってホストされるウェブサイトに焦点を当てる。しかしながら、システム200は、追加タイプのウェブサイトおよび他の非ウェブデジタル作成物を用いて実装されてもよい。これらには、例えば、以下のもの(またはこれらの任意の組み合わせ)が含まれる。フルウェブサイトおよびウェブサイトセクション(例えば、ウェブサイトのページのサブセット)または1つ以上のウェブサイトページのセクション、通常のデスクトップコンピュータ閲覧用にデザインされたウェブサイト、モバイルウェブサイトおよびタブレット指向ウェブサイト、ならびにウェブサイト構築システムによって作成されたが外部でホストされたウェブサイト(すなわち、ウェブサイト構築システムベンダーによってではない)。それらはさらに、ユーザのマシン上にインストールされたローカルサーバ上でローカルに実行されるウェブサイト、UIとして働き、他のシステム(埋め込みシステムおよび機器を含む)内でホストされるウェブサイト、ならびに他のタイプのウェブサイトおよび他の非ウェブデジタル作成物を含むことができ、それらはまた、(例えば)ソーシャルネットワーク(Facebook(登録商標)など)内でホストされるページ、ブログ、ポータル(YouTube(登録商標)チャネルなどのユーザカスタマイズ可能なページをサポートするビデオポータルおよびオーディオポータルを含む)などを含む、より大きなシステム内でホストされるウェブサイトまたは他の表示されたビジュアルコンポジションを含むことができる。これは、ウェブサイトとみなされない他のタイプの遠隔アクセス可能なオンラインプレゼンスを含むことができる。
他のタイプのウェブサイトおよび他の非ウェブデジタル作成物はまた、ハイブリッドアプリケーション(ローカルにインストールされた要素をリモートリーブされた要素と組み合わせる)、および電子メール、ニュースレター、および他のデジタルドキュメントなどの非対話型デジタル作成物を含む、対話型(モバイルまたは他の)アプリケーションを含み得る。
次に、応答編集モジュール300の要素を示す図4を参照する。モジュール300は、応答エディタ310と、CSSジェネレータ320と、メッシュアプライヤ330と、ルールエンジン340と、ML/AIエンジン350とをさらに備えることができる。応答エディタ310は、ユーザが応答ウェブサイト(ブレークポイントの範囲を指定することを含む)を作成および編集することを可能にすることができ、ルールエンジン340およびML/AIエンジン350からの機能を使用することができる。CSSジェネレータ320は、編集変更の結果としてスマートCSSを生成することができ、メッシュアプライヤ330を使用して、非応答ウェブサイトを、応答ターゲット表示変更であるグリッドを有する応答ウェブサイトに変換することができる。編集の結果として作成された更新されたCSSは、CSSとして、またはそれを表すデータ構造としてCMS50に保存することができることが理解され得る。CSSジェネレータ320は、この定義を採用し、それに応じてスマートCSSを生成することができる。これらの要素の機能については、以下でより詳細に説明する。
非ブラウザベースのシステム上に実装される場合、システム200は、下層のシステムレンダリングまたは表示フレームワークと統合されたシステムのいくつかの要素を有することを含めて、異なる方法で実装されてもよいことが理解され得る。これは、基盤となるシステムのサーバ、クライアント、その他の要素またはプラットフォームで行うことができる。
次に、応答エディタ310の要素を示す図5を参照する。応答エディタ310は、ユーザと対話するために標準編集UIを提供する通常のエディタとして機能し得ることが理解され得る。応答エディタ310は、さらに、編集レシーバ3101、編集ハンドラ3102、プレビューワ3105、エクスプレーナおよびサジェスタ3104を含むことができる。これらの要素の機能は、以下でより詳細に説明される。エクスプレーナおよびサジェスタ3104は、ネクストムーブサジェスタ31041をさらに含むことができる。
編集レシーバ3101は、(システムおよびユーザの両方から)入力イベントまたはトリガを受信することができる。編集ハンドラ3102は、編集の必要な取り扱いを決定してもよく、プレビューワ3105は、編集のアプリケーションのWYSIWYGプレビューを提供してもよく、エクスプレーナおよびサジェスタ3104は、与えられたアクションのユーザに説明を提供し、ユーザに解決策または提案を提供してもよい。これらの要素の機能は、以下でより詳細に説明される。
本明細書で上述したように、システム200は、1つ以上のサイト変数またはパラメータ(本明細書では「影響変数」)への変更に基づいて変更することができるレイアウトに基づいて応答サイトを実施する。一例は、サイトのウインドウ又は表示幅の変化に応じたレイアウト変更(例えば、レイアウトの伸張又は圧縮)である。
応答編集モジュール300は、ユーザが、幅値ブレークポイントを定義し、異なるビューポートに関連付けられたディスプレイのブレークポイント範囲を一致させることを可能にすることができる(スマートフォン画面では320~750ピクセル、タブレット画面では750~1000ピクセル、デスクトップ画面では1000ピクセル以上など)。
また、システム200は、電子掲示板システム(または以下でより詳細に説明するマルチスクリーンアプリケーション)で使用される非常に大型のディスプレイ、ならびに非常に小型のもの(スマートウォッチまたはウェアラブルデバイススクリーンなど)など、通常のデスクトップスクリーンよりも大きい追加のフォームファクタをサポートすることもできる。したがって、より低い解像度およびより高い解像度の両方に対する変形を有するデスクトップ解像度のためにウェブサイトまたはアプリケーションを構築することができる。
表示サイトの幅が単一のブレークポイント範囲内で変化する場合、レイアウトは連続的または半連続的に変化し得ることが理解され得る。ブレークポイントが交差すると、レイアウトは、(以下でさらに説明するように)非連続的に変化し、コンポーネントは、それらの位置、サイズ、可視性、または他の属性を変化させることができる。このプロセスは、カスケーディングとして知られている。
以下でより詳細に論じるように、システム200は、追加の影響変数(サイトの表示高さの変化など)または複数のそのようなパラメータの組合せを実装することができる。変数には、プラットフォームタイプなど、サイズ以外のその他の情報も含めることができる。
さらに、影響変数は、単一のパラメータ(またはそれらの組み合わせ)ではなく、むしろ複数のパラメータの関数であってもよい。例えば、システム200は、(ディスプレイの幅及び高さの関数である)ディスプレイのアスペクト比に基づいて異なるレイアウトを定義することを可能にすることができる。
本明細書で上述したように、レイアウトは、そのサイズおよび属性が、それらの親によって(例えば、親の変更またはビューポート幅の変更によって)、または本明細書で以下でより詳細に説明する追加のトリガによって影響され得る流動コンポーネントを組み込むことができる。これらの効果は、編集ハンドラ3102によって自動的に決定されるか、またはユーザによって指定または編集され得る(例えば、コンポーネント幅は、親コンポーネント幅の所定のパーセンテージまたは関数である)かのいずれかであることが理解され得る。そのような流動性は、全コンポーネントレベルであってもよいが、コンポーネントの特定のサブ要素(例えば、列の幅が全コンポーネントの幅に基づく公式として指定されてもよい多列レイアウトコンポーネント)にも適用されてもよい。
システム200は、以下でさらに説明するように、サイト内またはサイトに発生する追加のイベントおよび応答トリガに応答して、動的レイアウト技法および他のレイアウト変更をさらに適用することができる。
本明細書で上述したように、モジュール300は、ウェブサイトレベル、個々のページレベル、セクションレベル毎、および特定のコンテナレベル毎(スクリーンワイドコンテナまたは他のコンテナを含む)を含むいくつかのレベルでブレークポイント定義を行うことを可能にすることができる。
モジュール300はまた、継承ベースのブレークポイント定義、例えば、サイトレベルのブレークポイントセットを定義し、ページおよび/またはセクションが独自のバリアントを作成することを可能にしてもよい。
本明細書で上述したようなコンポーネントの流動性は、サイズ変化または他の影響を及ぼす可変変化に応じて適応するそれらの能力に起因し得ることが理解され得る。各コンポーネントまたはレイアウトは、それに応じてルールエンジン340によって処理されるそれ自体の処理ルールを有することができる。これらのルールは、CMS50に記憶されてもよい。適応するこの能力は、メッシュアプライヤ330に関連して以下でより詳細に説明するように、コンポーネントがコンテナおよび階層内で移動することを可能にする、レイアウト、スプリッタ、およびウェッジなどの応答編集グリッドおよび要素の適用とともに、予め定義された処理ルールの適用によるものであってもよいことが理解され得る。
処理ルールは、自動ドッキング(ドラッグされたときのコンポーネントのアライメントおよびマージンを変更する)、再パレンティング(reparenting)時のサイズ変換、ユニットを変更するときのサイズ変換、要素のドラッグおよびサイズ変更(グリッド領域、サイズおよびマージンを更新する)、グリッドオーバコンテンツの適用(グリッド領域、サイズおよびマージンを更新する)、グリッド行または列の削除、グリッド全体の削除、最小値および最大値のサイズ変更、レイアウタ(layouter)またはリピータの表示の変更などの編集手順に影響を及ぼすことがあることが理解され得る。
他のルールは、コンポーネントを下位ブレークポイント上の存在しないセルにドラッグすること(そのグリッド領域をビューポート内に残るように更新すること)、スタックを作成すること、スタックをアンスタックすること、アライメントを変更すること、ドッキングおよびマージンを広げるおよび広げないこと、セクションを追加、除去およびフリップすること(ページおよびセクショングリッドを更新すること)、およびセクションを水平から垂直にフリップすること(コンポーネントのサイズおよび位置を更新すること)を含むことができる。
ここで、所与のソースブレークポイント定義を有するコンポーネントが、新しいターゲットブレークポイント定義を有するページまたはコンテナにどのように適用され得るかの例を示す図6A~Cを参照する。これは、あるページから別のページにセクションをコピーする場合(ページのブレークポイント定義が異なる場合)、プリセットを使用する場合(プリセットに付属しているデフォルトのブレークポイント範囲とは異なるブレークポイント範囲をユーザが定義する場合)、共有部分(複数のページにわたって継承によって共有される共通要素)などのシナリオに関連することがある。これには、共有部分を切り離し、ページブレークポイントに戻り、要素をページから共有ブロックに、またはその逆に移動することが含まれる場合がある。図6Aでは、ターゲットブレークポイントは、ソースブレークポイントよりも数が少ない。このシナリオでは、ソースブレークポイントの1つがドロップされる。図6Bでは、ターゲットは1つのブレークポイントのみを有する。したがって、最後のブレークポイントは無限大(最大値なし)に定義されるため、カバレッジはデスクトップ上で最高になる。図6Cでは、ターゲットは、ソースよりも多くのブレークポイントを有し、したがって、ターゲットブレークポイントは、ソースブレークポイントに含まれてもよいし、それらの間に含まれてもよい。マッピングを定義するために、最上位のオーバーラップを選択することができる。
応答編集モジュール300はまた、応答デザイン、流動性、および動的レイアウトをサポートする生成されたサイトの編集、公開、および実行をサポートするために、ドラッグアンドドロップ編集、ならびに以下に記載されるような複数の他の能力を提供し得ることが理解される。
さらに、システム200は、実行時(サイトの閲覧)の間、ならびに編集(サイトを編集するためにWYSIWYGモードで作業するとき、またはエディタ310内のプレビューモードで作業するとき)の間に、応答性のあるデザイン、流動性、および動的レイアウト能力を提供時間ことが理解され得る。また、保存、プレビュー、公開の各段階で機能を提供することもできる。
システム200は、応答デザイン、流動性、および動的レイアウトに特有のサイトテンプレートを提供することもできる。ユーザは、このようなテンプレートを用いてサイトを作成し、編集することができる。
モジュール300はまた、後述するコンテキスト追加パネルおよび次の移動提案などの、標準的なウェブサイト構築システム手順に追加の機能を提供することができることを理解され得る。このような機能により、編集時間が短縮され、使いやすさが向上する可能性がある(ユーザが選択できるオプションが少なくなったり、フォーカスされたオプションが増えたりするため)。
モジュール300はまた、既存のレイアウトのための異なるブレークポイント、ならびにサイトの探索および性能のための最適化のために、エクスプレーナおよびサジェスタ3104を介したレイアウト提案などの能力を提供し得る。これらにより、ユーザは、よりパフォーマンスが良く、より専門的にデザインされたサイトを作成することができる。
本明細書で上述したように、本説明は、ウェブサイトレイアウトが、表示されるサイト幅の変更によって影響を受けるシステム200の実施形態に焦点を当てる。しかしながら、システム200は、変更およびトリガを含む他の影響を受ける変数に起因して、サイトの属性およびレイアウトを修正するように適応されてもよい。これらには、幅、高さ、方向、表示ビューポートプロパティの変更(ビューポートの幅または高さが変更された場合)、エディタ内のサイト表示サブエリアの変更などのデバイスプロパティの変更が含まれるが、これらに限定されるわけではない。これは、例えば、応答エディタ310がエディタ領域の可変サブ領域であるサイト表示領域を有する場合に発生する。応答エディタ310は、この領域を編集ユーザがサイズ変更できるようにすることができ(図7A~7Gに示されているように、現在参照されている)、このサイズ変更に基づいてサイトレイアウトを変更することができる。図7A~7Gの詳細な説明は、以下でより詳細に提供される。
他のトリガおよび変更は、コンポーネントに対するユーザ編集および修正、それらの属性およびそれらのレイアウト、デバイスタイプに対する変更(例えば、異なる解像度を有するデバイス)、地理(位置)に対する変更などのユーザプロパティに対する変更、ユーザに関連するユーザアイデンティティまたは他の特定の属性、ならびに照明レベルに対する変更(昼/夜、屋内/屋外)などの環境プロパティに対する変更を含むことができる。
別のトリガは、対話プロパティに対する変更、例えば、ユーザと画面との間の距離の変更(ユーザが画面を見る方法に影響を及ぼす)であってもよい。したがって、サイトは、ユーザがそれをある距離から見ている(したがって、「事実上より小さい」スクリーン上でサイトを見ている)ときを検出し、そのサイトをその遠くの見ているものに適応させ、おそらくサイトレイアウトを変更し、より大きいフォントサイズを使用することができる。その後、ユーザが画面に近づくと、サイトが変わることがある。ユーザの距離は、システムに利用可能な任意のセンサによって(例えば)測定されてもよく、または、システムに利用可能なビデオカメラ出力の分析によってもよい。これはまた、複数のビューワを最もよく表す距離(例えば、平均距離)を最適化することによって、複数の閲覧ユーザ(例えば、公共設定)で機能することができる。
本明細書で上述した様々なトリガおよび変更は、いくつかの方法で行うことができることを理解され得る。トリガまたは変更が静的である場合、サイトは、所与のパラメータ(例えば、所与のデバイス、解像度、幅、または高さ)で開かれる。このようなシナリオでは、システム200は、様々な影響を与える変数に基づいてサイトを構成することができ、この構成は、セッションの間、一定のままであってもよい。
トリガは別個のものであってもよく、例えば、サイトは(所与の幅を使用して)ポートレートモードで、モバイルデバイス上で開かれ、ユーザは(より大きな幅を有する)ランドスケープモードへ、およびランドスケープモードから切り替わる。
トリガは連続的であってもよく、例えば、サイトは所定の幅を有するウインドウで開かれ、ユーザはこのウインドウ幅を(編集中または表示中に)変化させる。モジュール300は、これらの変化に連続的に応答し、現在の幅(または他の影響変数)に常に適応するようにサイトを修正することができる。
トリガは、非ユーザである可能性もある。すなわち、サイトは、システム手続きの変更のようなユーザの行動に直接基づかない変更の影響を受ける。これは、例えば、(本明細書で上述したようである)影響変数に対する任意の他の変更によるものであり得る。これはまた、ユーザが、サイトのこのような同時編集及び閲覧をサポートする実施形態において、異なるユーザによって編集されているサイトを閲覧する場合であってもよい。
これらのトリガおよび変更のすべては、サイトの編集時だけでなく、サイトへの実行時アクセス時にも適用可能であることが理解され得る。本明細書で上述したように、WBS2は、ランタイム中に何らかの編集機能を提供することができる(例えば、ブログサイトのユーザによるデザインされたブログ投稿の作成を可能にする)。
上記のトリガのいくつか(例えば、環境または相互作用の変化)はまた、物理的環境、ならびに非物理的環境(例えば、仮想現実、拡張現実、または任意の他の非物理的環境内のサイトとの編集または相互作用中に生じる変化)内で関連し得る。
次に、編集ハンドラ3102の要素を図示する図8を参照する。編集ハンドラ3102は、動的レイアウト(DL)ハンドラ31021、レイアウトハンドラ31022、テキストスケーラ31023、可視性ハンドラ31024、コンポーネントハンドラ31025、アニメータ31027、コンポーネントドッカー31028、グリッドハンドラ31029、追加パネルハンドラ31030、コンポーネントグルーパ(grouper)31031およびイメージハンドラ31032をさらに備えることができる。これらの要素の機能は、以下でより詳細に説明される。
上述したように、編集レシーバ3101は、現在のサイト、ページ、またはコンポーネントに対する編集、変更、またはトリガであり得る入力イベントを受信することができる。編集ハンドラ3102は、入力イベントの結果としてどのような変更を行う必要があるかを決定することができる。編集ハンドラ3102のサブ要素は、ルールエンジン340およびML/AIエンジン350を使用して、以下でより詳細に説明するように、それらの機能性を改善することができることを理解され得る。
本明細書で上述したように、システム200は、米国特許第10,185,703号に記載されているように、トリガによって発生する動的レイアウト変更に応答デザイン能力を統合することもできる。
モジュール300は、実行時だけでなく、編集中(例えば、ユーザによってなされた編集変更を反映する)に動的レイアウト処理を実装してもよい。システム200は、必要条件がケース間で異なり得るので、いずれのケースでも異なるメカニズムを使用することができる。第3の使用シナリオは、プレビューまたはシミュレーションモード、編集環境内で機能するウェブページのランタイムビューであってもよく、これは、通常のランタイムビューとは異なる挙動をすることができる。
動的レイアウトは、動的レイアウトトリガに基づいて、画面上のコンポーネントの移動およびサイズ変更を含むことが理解され得る。これらの動的レイアウトトリガには、コンテンツの変更、コンテンツの書式設定の変更、複数の設定間でのコンポーネントの切り替え、複数のターゲットプラットフォームの使用(異なる表示プラットフォームで異なる技術を使用したアプリケーションの表示)、複数の画面または表示ビューポートサイズ(画面の回転やウインドウのサイズ変更など、サイズや解像度が異なる多数のディスプレイを使用したアプリケーションの表示)が含まれる場合がある。他の動的レイアウトトリガには、動的データ(時間の経過とともに変化する動的データを含むコンポーネントの使用)、エンドユーザが開始した変更、アプリケーションが開始したレイアウトの変更、エディタでのコンポーネントの移動とサイズ変更、およびページの同時編集(例えば、ユーザが編集したページの共有編集または即時更新を提供するシステム内の他のユーザによる)が含まれることがある。
また、コンポーネントは、以下のような様々な要因により、実行時にそのサイズ/位置を変更することができることも理解され得る。
ブログコンポーネント(コメントのユーザ投稿の投稿/編集を可能にする)などのランタイム編集を可能にするコンポーネントにおいて、ユーザによるコンテンツ変更。
外部ソースからインポートされたコンテンツを反映したコンテンツ変更。これは、(たとえば) 単一のフィールドコンテンツ、または外部データベースからの複数のレコードを示すリピータを表示する項目の場合がある。
同一ページの同時編集・閲覧を可能とするシステムにおいて、他のユーザによるコンテンツの同時編集、又は同一ページの複数のユーザによる同時編集を反映したコンテンツ変更。
サイトによって開始/プログラムされた効果(例:コンポーネントコンテンツ、フォーマット、属性またはレイアウトに影響を与えるサイトイベントに関連するコード)によるコンテンツまたはサイズの変更。
他のコンポーネントまたはサードパーティアプリケーション(または他の埋め込みコンポーネント)によって行われるリクエスト。
環境サイズの変更によるページサイズの変更。たとえば、異なるサイズのプラットフォームへの展開、ウインドウ/ビューポートのサイズ変更、フォームファクタの変更(縦/横表示)、画面サイズの変更など。
ギャラリースクロールによる変化、コンポーネントに影響を及ぼす(例えば、ズームインを引き起こす)マウス通過などの、コンポーネントに影響を及ぼす他の変化。
ページおよびレイアウトは、常に静的ではないことが理解され得る。特に、コンポーネントは、複数の状態の間で切り替わり、さらにアニメーション化されてもよい。状態変更およびアニメーションは、コンポーネントの位置、サイズ、レイアウト、回転、スタイル、形状、変換などに対する変更を含むことができる。モジュール300は、カーソル移動、スクロール、他の要素との相互作用、プログラム、データベースベースなどを含む、このような状態変化およびアニメーションのための複数のトリガをサポートしてもよい。
編集される要素のレイアウトは、これらの変更およびアニメーションを、駆動動的レイアウト操作として、または様々なページ構成におけるそれらのための適切なスペースを計画することに関して考慮に入れることができる。また、特定のコンポーネントの状態定義とアニメーションは、個々のブレークポイント範囲で変更することもできる。
コンテンツ変更に関する上記のすべての参照には、コンテンツに対するフォーマット変更も含まれ得ることが理解され得る。
さらに、動的レイアウトのためにそれらのサイズを移動または変更するコンポーネントは、他のコンポーネントに影響を及ぼすことがあり、例えば、そのコンテナに影響を及ぼすコンポーネントの場合、それらを「押し下げる」か、または拡張することがある。そのような効果は、米国特許第10,185,703号に記載されているように、暗黙的な(自動的に生成された)アンカーまたは明示的なアンカーに基づくことができる。
アンカー(米国特許第10,185,703号に記載されているようである)は、ドッキング/ロッキングタイプ(エッジ、コーナー、中心)、明示的/暗黙的性質、最小または最大サイズ、一方向/双方向、一方向または双方向アンカー、ゲート/ブレーキング条件、移動またはサイズ変更効果などの複数の属性を有することができることが理解され得る。
さらに、応答デザインおよび動的レイアウトは、(本明細書で上述したように)編集中およびランタイム中の両方に適用可能であることが理解され得る。
典型的な実施形態では、動的レイアウトは、編集およびコンテンツ変更(典型的にはダウン)に起因して、他のコンポーネントをプッシュまたはサイズ変更するコンポーネントを扱う。応答デザインは、典型的には、幅変化(異なるブレークポイント範囲に対する複数の構成を含む)によるレイアウト変更を扱う。
DLハンドラ31021は、コンフリクトを防ぐために、応答性のある編集および動的レイアウトを調和させ、相互作用させて動作させることができる。例えば、レイアウト幅が変化するにつれて、包含コンポーネントへの固定に基づいて、コンポーネントがより広くなったり、より狭くなったりすることがある。テキストコンポーネントが狭くなると、コンテナテキストが再フォーマットされ、テキストコンポーネントが下方に大きくなる可能性がある。次に、コンポーネントは、コンポーネントをその下に押し下げるか、または収容コンテナを下方に伸張させることができる。これは、米国特許第10,185,703号に記載されているような明示的または暗黙的なアンカー、または以下でより詳細に説明するようなスタック要素またはグリッドなどの編集要素の使用に基づくことができる。
次に、サイトレイアウトにおける幅の変更の影響を図7A-Gに戻って参照する。図7Aは、サイズ変更可能な編集ステージ[A]、幅変更ハンドル[B]、可能なブレークポイント範囲の視覚的な表示[C](現在選択されているサイズの下に下線を含む(デスクトップミニアイコン))、ユーザがブレークポイント(したがって範囲)を編集することを可能にするインターフェースをもつ現在のブレークポイント範囲のリストを示すカスタマイズダイアログ[D]を含むいくつかのUI要素を示す。
編集段階はさらに、テキスト段落コンポーネント[E]およびコンテナコンポーネント[F](丸められた角を有する長方形)を含む。これらのマークされた要素のいくつかは、図7B~7Gの追加図に現れ、同じラベルが関連することが理解され得る。
以下の議論および図7A乃至7Gが所定のコンポーネント及びコンテナのセットおよび、この限定セットと関連して説明されるように、システム200の応答性デザイン、流動性及び動的レイアウト能力を備えた例に焦点を当てることが理解され得る。しかしながら、システム200はまた、コンポーネント及びコンテナの任意の階層に対する応答性デザイン、流動性及び動的レイアウト能力を実施し、包含階層全体にわたって応答性デザイン、流動性及び動的レイアウトを適用することができる。したがって、例えば、システム200は、トップレベル(例えば、ページ表示ビューポート全体が変化するとき)および内部コンテナ(例えば、特定のコンテナの幅に応じてサブ要素のレイアウトを変化させる)の両方でレイアウト変化を適用することができる。
[D](図7A)から分かるように、デフォルト設定は、スマートフォン画面では320~750ピクセル、タブレット画面では750~1000ピクセル、デスクトップ画面では1000ピクセル以上の範囲である。図7Bは、ブレークポイント範囲にわたる適切な処理を提供するためのスタック(以下でより詳細に説明する)の使用を示す。これは、システム200のユーザが、2つのコンポーネント([E]および[F])の間にアンカーを作成して、それらを一緒にリンクして、それらに影響を及ぼすために使用することができるメカニズムである。スタックコンテナ[G]は、[E]および[F]を含むことができ、それらの周りの間隔(例えば、このシナリオでは[F]の周り)を画定することもできることが理解され得る。
また、DLハンドラ31021は、同じコンテナ階層レベル内のオブジェクト間だけでなく、包含コンテナへの明示的/暗黙的アンカーおよびアンカーを含む、他のタイプの動的レイアウトアンカー(米国特許第10,185,703号に記載されているようである)を実装することもできる。システム200の別の実施形態は、さらに、クロスコンテナアンカー、例えば、2つのコンテナ間で要素の同様の順序を維持することを可能にする、異なるコンテナ内のコンポーネント間のアンカーを実装することができる。
次に、図7C~7Eを参照すると、サイト上の幅変更の影響が示されている。WYSIWYG編集中の表示は、前に詳述した幅変更ハンドル[B]を使用して行われた変更で表示される。応答エディタ310は、編集中の幅変更のための複数の方法を提供することができ、デザイナが異なる幅の下でレイアウトを見ることを可能にする。例えば、応答エディタ310は、(現在のブレークポイントセットのために修正された図7Aのデスクトップ/タブレット/モバイルメニュー[C]を使用して)離散的なブレークポイントごとの幅値が選択されることを可能にすることができる。応答エディタ310は、幅変更ハンドル[B]を使用して連続的な変更を可能にすることもできる。
応答エディタ310はまた、ユーザが所定のコマンド(ビジュアルボタン、キーボードショートカット、マウスイベントまたは他のシステム入力)に関連する1つ以上の幅のアニメーションを指定することを可能にしてもよい。そのような幅アニメーションは、ユーザが、複数の幅を繰り返し手動で超えることなく、特定の幅のセットまたは範囲の下でサイトを見ることを可能にする。
ここで、約1600ピクセル幅のページを示す図7Cを参照する。
ここで、約1100ピクセル幅のページを示す図7Dを参照する。この幅において、テキスト[E]のテキストフォントサイズが縮小され、リフロー(すなわち、単語を次の行に移動)されていることが理解され得る。コンテナ[F]は押しつぶされている(そのため、現在は図7Cと比較してほぼ円形になっている)。
図7Eは、約800ピクセル幅のページを示す。ブレークポイントインジケータ[C]は、ページが「タブレット」モードであることを示していることに注意する。
本明細書において上記で論じたように、プレビューワ3105は、ユーザが様々なブレークポイント範囲内の特定のコンポーネント(コンテナおよびコンポーネントセットを含む)をプレビューすることを可能にしてもよい。図7Gに示すように、プレビューワ3105は、現在選択されているテキストコンポーネント[B]のプレビュー[A]と、その即時コンテナ[C]を、すべてのブレークポイントで表示することができる。プレビューには、動的な状態(マウスをコンポーネントの上に置いたときなど)を含む複数の状態が含まれる場合もある。
ここで図7Fを参照すると、テキスト要素が、([H]「scale text」ボタンおよび2つのテキストポイントサイズボックスによって定義されるようである)単一のポイントサイズではなく、ある範囲のポイントサイズを有するように定義され得るメカニズムが示されている。このシナリオでは、テキストスケーラ31023は、ビューポートまたはテキストフィールド幅に基づいて、テキストポイントサイズを最小値と最大値の間で拡大縮小することができる。
テキストスケーラ31023は、連続線形スケーリングを使用することができる(例えば、幅値およびその幅範囲に基づいて、所与の範囲内のフォントサイズの細粒度線形補間を使用する)。このような細粒度の補間は、任意の最小単位、例えば、10分の1点によって、点サイズを変化させることができる。テキストスケーラ31023は、非連続線形スケーリング(すなわち、フォントサイズの変更を所与の「ステップ」に制限すること、またはフォントサイズを所与の値のセットに制限すること)を使用することもできる。
CSSジェネレータ320は、次のようなCSS定義を使用して、このような動的フォントスケーリングを、生成されたCSSと共に直接実装することができる:
calc([min font size]+([max font size]-[min font size])*((100vw - [min viewport width])/ ([最大ビューポート幅]-[最小ビューポート幅]))
テキストスケーラ31023は、常に線形スケーリングを使用するのではなく、テキストサイズ変更とリフローを組み合わせて、2つの間の最適なバランスをとるスマートスケーリングを実施することもできる。これには、通常、コンポーネントの幅の変更に起因する変更を解析し、線形補間から小さなバリエーションを作成して、最良の視覚的結果を得ることが含まれる。
ここで、テキストがスケーラブルではなく、したがって、より狭い構成において(比較的)より多くの空間を必要とする、同様の構成を示す図9A~図9Eを参照する。図9Aは、単一のポイントサイズが選択されていることを示している(この場合、テキストスケール/ポイント選択UI[H]に示すように28ポイント)。
図9B(~1260画素幅)から分かるように、9C(~750画素幅)および9D(~360画素)は、スクリーン(したがって、レイアウト)が狭くなると、テキストがリフローされ、したがって、より高層になる。次に、テキストはコンテナ[F]を押し下げる。
上述したように、編集ハンドラ3102は、表示幅の変化(または他の影響を与える変数)に基づいて、レイアウト(および一般的にはページ)に対する変化を定義することができる。本明細書で上述したように、編集ハンドラ3102のサブ要素は、ルールエンジン340と共にルールベースの機能を使用することができる。そのようなルールは、以下でより詳細に説明するように、自動ドッキング、サイト変換、ドラッグおよびサイズ変更要素、グリッドの管理(行および列の追加、削除など)、ならびにレイアウトおよびリピータの表示の変更などの機能のための指示を含むことができる。
したがって、例えば、図9E(ここで参照する)では、丸められたコンテナおよびテキストは、図9Dのように一方が他方の上にあるのではなく、示された区切り点範囲内で並んで配置される。
編集ハンドラ3102は、ブレークポイントを通過するときに、そのような(および他の)変更を発生させることができる。これらは、各ブレークポイント範囲内の変化が連続的でなければならないので、非連続的な変化である。以下でさらに論じるように、コンポーネントの位置およびサイズは、封入コンテナ(例えば、「サイズは封入コンテナサイズの50%である」)に対する絶対ピクセルサイズ、分数(CSS「2fr」単位)などを含む様々な単位を使用して定義することができる。
典型的な実施形態では、ユーザは、レイアウトの主要パラメータ、すなわち、ブレークポイント間のコンポーネント位置およびサイズ(図9B~図9Eに示すようである)を変更することができる。したがって、各ページには、ブレークポイント範囲ごとに1つずつ、複数のコンポーネントレイアウトが含まれている場合がある。各ページは、複数のレイアウト(コンテナコンポーネント内のレイアウトを含む)を有してもよいが、特定の(単一の)コンポーネントもまた、複数の構成を有してもよいことが理解され得る。
レイアウトハンドラ31022は、サイトの分解(本明細書で上述したグループ化など)と要素の分類との間のマッピングに基づいてレイアウトを理解することができることを、理解し得る。分類法は、「WBSワールド」概念(例えば、ピクチャ+キャプションブロック)ならびに「現実世界」概念(例えば、「我々の製品」ページブロックまたはセクション)を含むことができるサイト要素概念のそれ自体の階層を提供する。このような分類法は、米国特許第10,073,923号により詳細に記載されている。
識別は、自然言語処理(コンポーネントに含まれるテキスト用)、以前のラベル付きサイトに関する情報、コンピュータビジョン及びユーザフィードバックに基づくことができる。
表示幅が同じブレークポイント範囲内にある限り、レイアウトハンドラ31022は、式(幅パラメータに応じて異なる結果を依然として提供することができる)に従ってレイアウト(位置およびサイズ)を計算することができる。この公式は、ユーザによって明示的に定義されるか、または、ML/AIエンジン350によって定義されるレイアウト変更に基づいてもよく、これは、本明細書において以下でより詳細に説明されるように、代替設計を自動的に生成してもよい。
ブレークポイントが交差されると、レイアウトハンドラ31022は新しいレイアウトに切り替わり、おそらく非連続的なサイト変更を引き起こす(すなわち、ボタンがある場所から別の場所にジャンプする)。
このような変更は、コンテナレベルで行うことができ、例えば、コンテナは、異なるブレークポイント範囲の間で移動することができ、一方、コンテナ内部のコンポーネントは、(コンテナに対して)異なるブレークポイント範囲のためのそれらの位置およびサイズを保持することが理解され得る。対照的に、コンテナは異なるブレークポイント範囲間で自身のサイズを変更することもあり、そのコンテナ内に含まれるコンポーネントは影響を受ける可能性がある(移動、サイズ変更、または必要に応じて変更)。
レイアウトハンドラ31022はまた、異なるブレークポイント範囲に対して異なるレイアウトを有するコンテナの予め定義された配置を提供してもよい(例えば、デスクトップ版では並列、モバイル版では上位)。
編集ハンドラ3102は、以下でより詳細に説明するように、コンポーネントzオーダー、可視性(隠蔽/非隠蔽)、および他の属性などの追加のコンポーネント属性および設定をブレークポイント交差時に変更することも可能にすることができる。
可視性ハンドラ31024は、特定のブレークポイント範囲に対するコンポーネントの隠蔽および非隠蔽を管理することができる。これは、例えば、デスクトップ構成のためのサイトナビゲーションの1つの方法(例えば、サイドメニュー)と、モバイルバージョンのための別の方法(例えば、「ハンバーガー」メニュー)を使用することを可能にしてもよい。
また、ユーザは、所与のブレークポイント範囲内で消失するコンポーネントについて「空隙を閉じる」ために、または所与の範囲内に出現するコンポーネントについて「スペースを作る」ために、異なるブレークポイント範囲について異なるレイアウトを定義することもできる。したがって、ユーザ編集は、コンポーネント編集(コンポーネントが挿入または削除されると、コンポーネントの自動再配置を提供する)のコンテキストで、本明細書に記載する、スペースの作成/クローズ機能によって支援されてもよい。
可視性ハンドラ31024は、動的レイアウト能力を用いてこれを自動的かつ動的に行う能力を提供してもよい。これは、例えば、(例えば、実行時間中に決定されるコンテンツの量が異なるために)可変サイズを有するコンポーネントの場合に、より適用可能であり得る。この場合、可視性ハンドラ31024は、例えば、隠蔽コンポーネントがゼロにサイズ変更されたものとみなし(例えば、ゼロサイズの点またはゼロ幅の線)、隠蔽コンポーネントに対するアンカーに基づいて、他のコンポーネントに動的レイアウト処理を適用することができる(その新しい「形状」で)。
コンポーネントハンドラ31025は、状態または設定情報を共有するように、複数のコンポーネントをリンクする能力を提供してもよい。例えば、ユーザがタブレット上で使用する応答ページを横向き(幅広)と縦向き(狭)の両方のモードでデザインし、横向きモードレイアウトがサイドメニューを使用するのに対し、縦向きモードレイアウトがハンバーガーメニューを使用する場合、コンポーネントハンドラ31025は、初心者/エキスパートメニュー複雑度設定、最後に選択されたオプション(強調表示されている場合)などの特定の状態情報をユーザが共有するように、2つのコンポーネントをリンクすることを可能にしてもよい。
代替的に、システム200は、以下でより詳細に説明するように、複数の変形を提供するメニューコンポーネントを介して同様の機能を提供することができる。
コンポーネントハンドラ31025は、応答性の影響を与えるパラメータに基づいて、コンポーネント属性(スタイル情報を含む)を変更することができることが理解され得る。
例えば、コンポーネントハンドラ31025は、異なるブレークポイント範囲内のコンポーネントに異なる色を適用することができる。これは、例えば、コンポーネントが所与のブレークポイント範囲から異なる背景色を有する領域内またはその近傍に再配置され、コンポーネントの色変化が必要とされる場合に必要とされ得る。
上述のフォントについて説明した能力と同様に、システム200は、コンポーネント属性の一部またはすべてについて範囲定義を提供することもできる。そのような範囲定義は、最小/最大値ならびに関連する補間式を含むことができる(例えば、コンポーネントハンドラ31025は、複数の色勾配法などの複数のそのような式を提供することができ、ユーザは、どの式を使用するかを選択することができる)。
区切り点ごとの範囲の変更は、コンポーネントの回転およびアニメーション詳細、他の属性に関連する変更を含むことができることが理解され得る。
さらに、コンポーネントは単一のコンポーネントのままであり、様々なブレークポイントごとの範囲の変更は、基本的に、各ブレークポイント範囲のコンポーネントの継承バージョンに対する変更子であることが理解され得る。したがって、例えば、(このブレークポイント範囲に対して単に隠蔽されるのではなく)所定のブレークポイント範囲を編集するときにコンポーネントが削除された場合、すべてのブレークポイント範囲に対して削除される(おそらく、本明細書に記載するように、動的レイアウト定義への変更または「スペースを閉じる」作用をトリガする)。同様に、コンポーネントの実際の内容が変更された場合(テキストが編集された場合など)、変更された内容がすべてのブレークポイント範囲に使用される。
コンポーネントが特定のブレークポイント範囲のために移動され得るとしても、モジュール300の典型的な実施形態は、コンポーネントが同じ親コンテナ(スタック、レイアウタ、またはリピータのセルであってもよい)の下に留まることを必要とし得る。コンポーネントハンドラ31025は、特定のブレークポイント範囲において、あるコンテナから別のコンテナへのコンポーネントの移動(「再親化」として知られる)を防止することができる。これはグリッド「セル」には適用されず、グリッド行はアンカー支持を提供するが、セルごとのコンテナのセットを形成しないことに留意されたい。
代替実施形態では、コンポーネントハンドラ31025は、ユーザがこの制限を放棄し、ブレークポイント範囲間でコンポーネントを再親化することを可能にすることができる。しかしながら、これは、(HTMLおよびCSSにおいてそのような構造および挙動を表すことがより困難であるため)かなりのコストを有する可能性がある。コンポーネントハンドラ31025は、(例えば)互いにリンクされ(本明細書で上述したように)、使用中のブレークポイント範囲に応じて隠蔽され、または可視である同じコンポーネントの複数のインスタンスを使用して、この構造を実装することができる。
いくつかのコンポーネントは、複数の事前レンダリング解像度を有することができるイメージなど、異なるサイズ、解像度、またはアスペクト比に適した複数のバージョン、変形形態、または構成を有することができることが理解され得る。
また、ギャラリは、異なるタイプ(スライダ、マトリクス、水平フリップギャラリ、垂直フリップギャラリ等)又は(ギャラリコンポーネントのための)割り当てられたサイズ及びアスペクト比に依存する異なるパラメータ(列の数等)を有することができる複数のバージョンを有することができる。例えば、リピータコンポーネントは、大画面デスクトップ構成のマトリックスギャラリからモバイル構成のスライダに変更することができる。
(ある限度未満にサイズ変更されたときに)モーダルダイアログを開くボタンとしてレンダリングすることができる、または代替として、初期セクションと拡張セクション(エンドユーザがボタンを押すときにのみ開く)に分割された、コンタクトフォームがある。
ビデオプレーヤはまた、複数のバージョンを有することができ、利用可能なスペースに応じて異なる組の制御ボタンをレンダリングすることができる(例えば、単に再生/停止する、開始/一時停止にスキップを追加する、早送り/早戻しボタンを追加するなど)。
コンポーネント定義は、離散的(すなわち、3つの利用可能な構成のうちの1つを選択する)であってもよく、または1つ以上のパラメータ(離散的または連続的であってもよい)に基づくものであってもよいことが理解され得る。例えば、マトリックスギャラリリピータコンポーネントは、異なるブレークポイントに対して異なる数の列を有することができる。
応答エディタ310は、各ブレークポイント範囲でどのコンポーネント構成を使用するかの手動選択をサポートすることができる。あるいは、コンポーネント定義は、異なる条件下でどのコンポーネントを選択するかについてのヒントをコンポーネントハンドラ31025に提供することができる。したがって、コンポーネントは、それ自体のブレークポイントおよびルールを提供することができ、例えば、幅100~300ピクセルが利用可能である場合にはバージョンAを使用し、300ピクセルを超えるピクセルが利用可能である場合にはバージョンBを使用することができる。
応答エディタ310で使用する典型的なページ構造は、ヘッダ領域とフッタ領域と同様に、ページセクションから構成されてもよいことが理解され得る。ページは、複数のセクションを含むことができ、各セクションは、レイアウト、リピータ、およびスタックなどのサポートコンテナタイプを含むコンポーネントおよびコンテナを含むことができる。典型的な実施形態では、セクションは、上下に垂直に配置され、コースト・ツー・コーストセクション(coast-to-coast sections)であり、すなわち、ページの水平ストリップ全体を占める。そのようなセクションは、典型的には、表示ビューポート幅に応じてそれらの幅を変化させることができる。応答エディタ310は、コンポーネント回転、アニメーションなどの追加のレイアウト要素をサポートすることができる。
主サポートツール(レイアウタ、スタック、リピータ、またはグリッドなど)のそれぞれは、編集ステージ上に表示される視覚表現サブ要素と、ユーザがツールを使用するのを助ける編集サポートサブ要素(例えば、レイアウタ内に要素を配置する)と、実行時に適切な挙動を実装するために基礎となるCSSを生成するのを助けるために実際のレイアウト計算を実行する(他のレイアウトエレメントと一緒に)実装サブ要素とを含む、複数のサブ要素を提供することができることが理解され得る。この最後のサブ要素は、その作業においてCSSジェネレータ320をサポートする。
応答エディタ310は、ページのいくつかまたはすべてに現れることができる共有部分、コンポーネントの使用をサポートすることもできる。共有部分には、同じコンテンツが表示される。このコンテンツは、表示されるすべてのページにおいて、ページごとにまだパラメータ化されている可能性がある(ページヘッダーのページ番号など)。いくつかの実施形態では、共有部分は、マスターコンポーネントまたはマスターブロックとしても知られている。上述のヘッダおよびフッタは、このような共有部分の例である(他のコンポーネントを含むことができる共有部分コンテナとして)。
コンポーネントは、(通常のページ領域から)共有部分に出入りすることができることが理解され得る。共有部分のコンテンツは、マルチビューイング、すなわち、実際の同じコンポーネントが複数のページで単に見えるようにするなど、多くの方法で共有することができる。任意のページでの閲覧の変更は、他のすべてのページに影響する。
コンテンツは継承によって共有される場合もある。つまり、ページはマスターコピーから継承される。マスターコピーが変更された場合、これらの変更はすべてのページに反映される。特定のページコピーが変更された場合、これはローカル変更子を介して処理され、変更はこのページにのみ適用される。
コンテンツは、各ページコピーが別々であり、メインコピーや他のページに接続されないように、各ページにコピーすることによって共有することもできる。
応答エディタ310は、セクションが連続していることを必要とするか、またはセクション間にスペースを定義することを可能にすることができる。セクション高さは、いくつかの方法で決定することができ、例えば、固定/事前定義することができ、サイトを表示するために使用されるビューポートの全高に設定することができ、最大の含まれるオブジェクトに適合させることができる。
コンポーネントは、典型的には、単一のセクション内に完全に存在する。しかしながら、コンポーネントハンドラ31025は、コンポーネントが所与のセクションから延在(すなわち突出)し、1つ以上の隣接するセクションに交差することを可能にすることができる。しかしながら、このシナリオでは、コンポーネントの領域の大部分は、典型的には、それが関連付けられているセクション内にある。
コンテナおよび他のコンポーネントは、固定サイズ、伸縮性、またはスクリーンサイズに関連するものとして定義されてもよい。これは、本明細書で後述する様々な特定のコンテナタイプ(セクション、スタック、レイアウト、リピータなど)に適用することができる。
ここで、ブレッドクラムディスプレイのためのセクションおよびコンポーネント選択の使用を示す図10Aおよび10Bを参照する。図10Aは、2つのセクションを含むページを有するそのような構造を示す。応答エディタ310は、セクション(および他の要素)が選択され、移動され、除去されることなどを可能にするセクションハンドリングおよびナビゲーションツール[A]を提供し得る。
深く埋め込まれたコンポーネントの選択を支援するために、応答エディタ310は、ブレッドクラム経路表示[B]を使用することもできる。コンポーネント(コンテナの場合もある)が選択されると、最上位コンテナから選択されたコンポーネントへのコンポーネントを含むパスを示すパス表示が表示される(表示例[B]のように、選択された内部テキストのパス“Section>Container>Container> Text”が表示される)。
図10B(ここで参照する)は、(例えば)所与のブレークポイントに対してセクションを隠蔽することができるので、セクションとセクション操作に利用可能なオプションとの間の分離を示すページ構造をさらに示す。
「Method and System For Section-Based Editing of a Website Page」という名称の米国特許第10,146,419号(2018年12月4日付)および「System and Method For Handling Objects in Visual Editing Systems」という名称の米国特許第10,824,793号(2020年11月3日付与)に記載されているような、セクション処理およびページオブジェクト選択のための追加のオプションが、本出願人によって共有され、参照によって本明細書に組み込まれる。
コンポーネントは、通常、追加パネルとして知られる利用可能なオブジェクト(コンポーネントタイプ)のセットのメニューからドラッグアンドドロップによって追加されることが理解され得る。追加パネルは、アトミックコンポーネント、コンテナ、デザイン要素(レイアウタおよびリピータなど)、ならびに事前作成されたセクションを含んでもよい。追加パネルは、WBSサービス、およびブログ、ストア、および予約などの垂直も含むことができる。ここで、このようなメニューを示す図11A~Cを参照する。追加パネルおよび図は、以下でより詳細に説明される。
応答エディタ310は、コンポーネントが幾何学的に互いに重なり合い、任意の位置に(ドラッグアンドドロップまたはサイズ変更を介して)配置されることを可能にすることができる。コンポーネントハンドラ31025は、このような重なり合うオブジェクトを処理するために、zオーダーまたは層化能力をさらに実装してもよい。代替的に、コンポーネントハンドラ31025は、以下でより詳細に説明するように、挿入されたコンポーネントのためのスペースを作るための機構を提供することができる。
したがって、応答エディタ310は、コンポーネントの挿入、削除、またはドラッグアンドドロップ中に、(正確なユーザ定義の配置と並行して)「スペースを作成/クローズ」能力を提供することができる。したがって、コンポーネントが所与の位置(おそらく1つの他のコンポーネントと重なる)にドロップされると、応答エディタ310は、ドロップされたコンポーネントのための場所を作るために、これらのコンポーネントのいくつかまたはすべてをサイズ変更または移動することができる。同様に、コンポーネントがコンポーネントの配置からドラッグアウトされると、応答エディタ310は、作成された空隙を閉じるように、残りのコンポーネントのサイズを変更または移動することができる。応答エディタ310は、同様の方法(すなわち、ドラッグ元と同様の削除、ドラッグ先と同様の挿入)でコンポーネントの挿入および削除を処理することができる。
ドラッグ元およびドロップ先の位置は、コンテナ、例えば、コンポーネントの垂直列を有するスタックコンテナ内にあってもよいことが理解され得る。次に、コンテナAがドラッグダウンされたとき(シナリオI)、コンテナBがAの代わりに上に移動され、2つの場所が切り替わる(シナリオII)方法を示す図12を参照する。
このようなスペースを作成/クローズの動作は、特定のユーザアクション(例えば、通常のマウスドラッグの代わりに制御ドラッグを使用する)、または、本出願人によって共有され、参照によって本明細書に組み込まれる、2019年1月22日に付与された「Web Site Design System Integrating Dynamic Layout and Dynamic Content」という名称の米国特許第10,185,703号に記載されているような特定のハンドルまたは同様の機構を使用することに依存し得る。
あるいは、これは、ドラッグ元またはドロップ先が発生するコンテナのタイプに依存し得る。例えば、コンポーネントハンドラ31025は、スペースを作成/クローズの挙動を、特定のコンテナタイプ(例えば、以下で説明するスタックコンテナ)、または特定の属性または設定でマークされた任意のコンテナに適用することができる。そのようなシナリオでは、スペースを作成/クローズの挙動は、ソースコンテナとターゲットコンテナとの間で異なることがある(例えば、ソースコンテナ内のスペースを閉じるが、ターゲットコンテナ内にスペースを作ることなく、ターゲットコンテナ内に重なり合うドロップ配置を可能にする)。
「スペースを作る」能力は、例えば、既存のアンカータイプおよび方向からの情報を使用して、各隣接するコンポーネントを修正するための最良の方法を決定する、ユーザのデザイン意図の解析に基づくことができることが理解され得る。コンポーネントハンドラ31025はまた、以前のユーザアクティビティおよび編集履歴、このウェブサイト内の他の領域のレイアウト、ならびに以下でより詳細に説明するようにML/AIエンジン350に関連してより詳細に説明するようなシステム内で入手可能な他の情報を使用することができる。
応答エディタ310は、複数のブレークポイントにわたるサイトの編集をサポートし、各ブレークポイント範囲についてデザインを最適化しながら、ブレークポイント範囲セットにわたるデザインおよびレイアウトを統一するための複数のメカニズムを提供することができることが理解され得る。これらの目標は、多くの場合、矛盾し得ることが理解され得る。
ここで、複数のブレークポイント範囲にわたるデザイン統一のためのインターフェースを示す図13Aおよび図13Bを参照する。図13Aは、ユーザが、別のブレークポイント範囲内の同じコンポーネントのものから、所与のブレークポイント範囲内のコンポーネントの設定およびデザインをコピーすることを可能にし得るインターフェースを示す(図中の「プルデザイン」UI[A]-「Copy From Breakpoint」)。同様のオプション(図13Bに示す)は、ユーザが、現在のブレークポイント範囲内のコンポーネントの設定およびデザインを、図中のUI[B]の「Make Everyone Like Me」によって表されるような他のブレークポイント範囲(「プッシュデザイン」)にコピーすることを可能にする。
応答エディタ310の実施形態はまた、そのようなコピーが、同じサイトまたは別のサイトの他のページ内の同じまたは類似のコンポーネントタイプのインスタンスから行われることを可能にし得る。これは、本出願人により共有され、参照により本明細書に組み込まれる2019年10月29日に付与された「System and Method for the Generation of an Adaptive User Interface in a Website Building System」と題する米国特許第10,459,699号に記載されているように、クラスタリングアルゴリズムおよび代表的な設定およびデザイン値の選択を使用して実施することができる。
アニメータ31027は、所与の範囲の幅または特定のブレークポイントについてのコンポーネントのユーザ選択のためのアニメーションを提供することができる。アニメーション31027は、フルページ、特定のページセクション、特定のコンテナ、または特定のコンポーネントを表示することができる。ページの異なるバージョン(幅が異なる)では、選択されていないコンポーネントが考慮される場合がある。選択されていないコンポーネントはグレー表示になっているか、完全に非表示になっている可能性がある。これは、ブレークポイント間で特定のコンポーネントまたはコンポーネントセットにどのような変更が発生する直感的に表示するために実行できる。選択されていないコンポーネントは、表示アニメーションを簡素化するために削除される。
応答エディタ310は、このようなアニメーションを対話形式に見ることまたはエクスポートすることを可能にし、一時停止することを可能にしてもよい(与えられたグレー表示/非表示が適用されたサイトプレビューのバージョンに戻す)。
応答エディタ310はまた、編集中のオブジェクトドッキングおよびアンカーリングを単純化するために、ならびにレイアウト内にコンポーネントを配置するために、複数のツールを提供し得る。
コンポーネントドッカー31028は、自動ドッキングをサポートすることができ、コンポーネントをドッキングし、可能なドッキングオプションごとに距離を実施する最良の方法を示す。次いで、ドッカー31028は、可能なドッキングを提案し、適用することができる。例えば、ドッカー31028は、コンポーネントが、そのコンテナ内の任意の他の物体よりもはるかに近いそのコンテナのコーナーに閉じて配置されたときを検出し、特定のコーナーの2つの近いエッジにドッキングすることを推奨することができる。
応答エディタ310は、コンポーネント、コンテナ、およびプリセットが、それらのプライベートドッキングパラメータを指定することを可能にすることができる。したがって、所与のプリセットは、例えば、正規行列フォーマットに適合しない特殊なグリッド配列を有することができる。
ML/AIエンジン350は、編集および保存(または他のサイト操作)中に絶対(WYSIWYG)レイアウト定義を解析することができ、ユーザの意図を検出し、以下でより詳細に説明するように、この意図を実施するルールの宣言的セットに変換することができる。
上述のように、要素は、典型的には、(コンポーネントの移動、コピー、および複製に加えて)追加パネルインターフェースを介してページに追加される。
ここで、追加パネルがレイアウト支持要素(図11AでAとマークされた)、通常のコンポーネントおよびコンテナ(図11BでBとマークされた)、および完全に定義されたセクション(図11CでCとマークされた)をどのように含むかを示す図11A~Cを参照する。このような所定のセクションは、プリセットとしても知られている。
一般に提供される要素(コンテナ、コンポーネント、およびいくつかのセクションタイプなど)は、抽象的であり、コンポーネント、レイアウト、およびページの世界に関連するので、「WBS世界」にあることが理解され得る。システム200はまた、「現実世界」に対応するセクション、すなわちウェブサイトの外部の意味を有する人間の談話のセクション(ビジネス用語など)を提供することもできる。図11Cから分かるように、応答エディタ310は、About画面、Servicesリスト、Productsリスト、Portfolioなどの要素(プリセットC)を提供することができる。
そのような可能なセクションおよびコンポーネントの数は非常に多いので、応答エディタ310は、カスタマイズされ、パーソナライズされた追加パネルを提供することができる。そのような追加パネルは、以下でより詳細に説明するように、ユーザ入力ファンネル(funnel)、ユーザ属性(ビジネスタイプなど)、サイト属性、現在のサイト構造、過去のアクション、およびデザイン選好などに基づいて、ユーザ上で利用可能な情報に基づいて確立することができる。
応答エディタ310は、所定のソースブレークポイント設定を有するオブジェクト(例えば、3つのブレークポイント範囲を有する)が、異なるターゲットブレークポイント設定を有するページ(例えば、異なる値を有する4つのブレークポイントを有する)に挿入される複数の状況をサポートすることができる。コンポーネントハンドラ31025は、挿入されたオブジェクトを、ターゲットページに対して定義されたブレークポイントに適合させてもよい。
これは、セクション(または別のコンポーネント)をページ間でコピーまたは移動する場合など、複数のシナリオで発生する可能性がある(ページのブレークポイント定義が異なると想定)。これは、1つのサイト内(ページごとに異なるブレークポイントが許可されている場合)にあっても、異なるサイト間にあってもかまわない。
また、別のサイトや別のレイアウト作成環境(例 WBSが採用している別のエディタ)から要素やセクションを含めたり(参照、継承、または他のメカニズムを介して)、ページに含めるためにユーザがプリセット(または別のコンポーネント)を選択し、ページに挿入されたオブジェクトに関連付けられたブレークポイント範囲がある場合にも発生する可能性がある。
また、共有部分(ページヘッダなどの共有領域)を切り離して通常のページ領域に戻したり、ページから共有部分に要素を移動したりする場合など、共有部分でも発生することがある。
次に、スタックを示す図14を参照する。スタック[A]は、互いに上下に押す、(他のコンテナ、スタック、または他の要素とすることができる)包含されたコンポーネントの垂直セットを含むコンテナである。スタック定義は、包含されたコンポーネント間のギャップ[B]を含む。スタックは、その包含されたコンポーネント間の空隙を維持し、それらが重なり合わないようにする。同様のコンポーネントは、垂直方向のものの代わりに水平方向の押しを提供することができる。
スタックは、編集中に含まれるコンポーネントの並べ替えだけでなく、包含されたコンポーネントの配置のためのドラッグアンドドロップを可能にすることができることが理解され得る。これは、本明細書で上述したように、スペースを作成/クローズを使用して行われる。
本明細書に記載するレイアウタと同様に、レイアウトハンドラ31022は、スタックがオーバーフィルされた場合、それを異なる表示フォーマット(例えば、スライダまたはスライドショー)に変換してもよい。
システム200は、HTMLのFlexBox要素を用いて、このようなスタック要素を実装してもよい。
レイアウタは、サブコンテナのセットにレイアウトを提供するコンテナであることが理解され得る。これは、配置、リストまたは他のリピータを含むコンテナをデザインする容易な方法を提供する。レイアウタは、ユーザ定義の再配置およびシステム決定の再配置の両方を含む、幅変更時に再配置されるサブコンテナのセットを定義する容易な方法を提供する。
レイアウタは、様々な直接の兄弟関係となるもの(すなわち、直接含まれる要素)を支持することができる。しかし、一実施形態では、すべての直接の兄弟関係となるものがコンテナであること、または特定のタイプのコンテナであることさえも必要とすることがある。
レイアウタは、アイテムがその行/列の内側、レイアウタコンテナ自体の内側のどこに配置されるか、および利用可能なスペースがあるとき(左/右/中央/字間調整など)を決定する複数の位置合わせオプションを提供することができる。
次に、レイアウタコンポーネントおよびレイアウタ構成を示す図15Aおよび15Bを参照する。図15Aは、5つのサブコンテナ(a~e)を含むレイアウタ[A]を示し、これらは、それ自体、追加のコンテンツ(5つのサブコンテナのそれぞれに1~2個のボタンまたはハンバーガーアイコン)を含む。サブコンテナは、伸縮可能であり、サイズ変更および移動が可能である。
サブコンテナをレイアウタから移動させることができ、外部コンテナをレイアウタ内に移動させることができるという意味で、レイアウタは通常のコンテナのように振る舞うことができることが理解され得る。
レイアウタは、ユーザが、編集中の並べ替え(「スペースを作成/クローズ」機能の有無にかかわらず)、コンテナをオンザフライで追加すること、外部からコンテナを追加すること、外部にコンテナを除去すること、およびレイアウトを変更することなどの動作を実行することを可能にすることができる。
当然のことながら、レイアウタは、静的配置([B]の行(Row)、列(Column)、および行(Rows)など)および動的配置([B]のスライダ(Slider)配置など)を含む複数のタイプの配置(図15Aの「Display type」[B]など)をサポートすることができる。これは、サブコンテナのいくつかのみがいつでも見える他のタイプのギャラリを含むことができ、ユーザ(ならびにサイトビューワ)は、下にあるギャラリの異なる部分にナビゲートすることができる。
本明細書で上述したように、より多くの配置が利用可能であり、レイアウトハンドラ31022は、(例えば、コンテンツの伸張のために)スペースが満たされた場合に、所与のレイアウタを異なる配置に自動的にさらに切り替えることができる。追加の配置には、カード、スライドショー、スライダ、リストおよび列が含まれ、レイアウタは、ユーザによる追加の編集なしに、それらのいずれかを適用することができる。
図15Aのレイアウト[A]は、「Rows」配列を使用する。対照的に、図15Bの同じレイアウタ[A]は、図示のような「Column」配置を使用する。
ユーザは、様々な配置の間で切り替えることができ、レイアウタは、所望の配置に従って、レイアウタ内のサブコンテナ(その内容物を有する)を再配置することができることが理解され得る。ユーザは、(図15Aのマージン(Margin)[C]および主方向性(L2R/R2L)[D]などの)配置のための追加のパラメータを提供することができる。
レイアウタはまた、その可能な配置のそれぞれについてレイアウトコンテクストを保存することができる。ユーザは、各配置を修正した(例えば、所与の配置の位置、サイズ、および順序を変更した)ことがあるので、レイアウタは、これらの修正を保存することができ、したがって、レイアウタは、この配置に戻るときにそれらを再適用することができる。
したがって、ユーザは、ブレークポイントごとの範囲の変更を適用することができ、ブレークポイント範囲ごとに異なる配置を使用すること、およびサブコンテナおよびそのコンテンツに他の変更を行うことを含む。
ユーザは、レイアウタのサブコンテナにオブジェクトを出し入れすることができることが理解され得る。オブジェクトが複数のサブコンテナを横切るようにレイアウタにオブジェクトをドロップするとき、レイアウタは、どのサブコンテナを使用するかを選択することができる。
そのような選択は、カーソル位置、最大のオーバーラップ領域を有するサブコンテナ、最大の結合された垂直及び水平オーバーラップ、又は他の基準のような多数のパラメータに基づくことができる。レイアウタは、ドロップされたオブジェクト(「ホットゾーン」と呼ばれる)を「受け取る」サブコンテナを強調表示することによって、ドラッグ中にユーザを助けることもできる。
レイアウタが(上述のように)すべての直接の兄弟関係となるものがコンテナであることを必要とする場合、レイアウタは、ドロップしたオブジェクトの周りにラッピングコンテナを自動的に作成する。
当然のことながら、ML/AIエンジン350と共にレイアウタは、推奨される配置選択および同じ配置内での種々の変更を含む、より良いデザインオプションを提案し得る。これらは、一般化された提案または特定のブレークポイント範囲のコンテキスト内の提案であり得る。一般化された提案は、一般化されたレイアウトタイプのメニューの1つである(以下でより詳細に説明する)。具体的な提案は、特にレイアウタの現在の内容に基づくレイアウト提案のセットであり、本出願人によって共有され、参照によって本明細書に組み込まれる、2017年8月29日に付与された「System and Method for the Creation and Use of Visually-Diverse High-Quality Dynamic Layouts」という名称の米国特許第9,747,258号に記載されたレイアウト提案と同様である。
レイアウタは固定されてもよく、すなわち、レイアウタの幅が変化するとき、そのサブコンテナは同じ配置のままである(しかし、それらは動的レイアウトのために互いにサイズ変更または押すことができる)。ブレークポイント範囲間で発生する唯一の移動は、ユーザによる明示的な編集によるものである。
あるいは、レイアウタは変形性であってもよく、そのサブコンテナは、特定の条件下で特定の方法で移動する。1つの単純な例は、行レイアウタ(要素が並んでいる)であり、この行レイアウタは、利用可能な幅がある値を下回ったときに、列レイアウタ(1つの要素が他方の上にある)に自動的に変換される。より複雑な変換を指定することができる(例えば、ワードプロセッサの幅が変化するときの段落内のワードのリフローに類似する)。システム200は、そのような変換レイアウトを提供することができ、ユーザが自分自身の変換レイアウトをデザインすることを可能にすることができる。
応答エディタ310はまた、(異なる幅の下でのレイアウタ変更に関して)本明細書で上述したような追加の変換能力をサポートすることができる。応答エディタ310はまた、2019年1月8日に付与された「System and Method for Automated Conversion of Interactive Sites and Applications To Support Mobile and Other Display Environments」と題された米国特許第10,176,154号および出願人が共有し、参照により本明細書に組み込まれる、2020年12月3日に公開された「System and Method for Integrating User Feedback into Website Building System Services」に記載されているように、移動ディスプレイのためのコンポーネントを再配置するために使用されるような技術を使用して、アルゴリズムに基づく変換をサポートすることができる。
次に、リピータの使用を示す図16A~16Cを参照する。リピータはレイアウトに類似しているが、サブコンテナ(アイテムとしても知られている)が単一のサブコンテナまたはサブコンテナのセットの複数のインスタンスである点が異なる。したがって、1つのサブコンテナに適用される変更(例えば、新しいコンポーネントを挿入すること)は、すべてのサブコンテナに適用することができ、すべてのサブコンテナに現れることになる。図16Aは、リピータ表示のためのいくつかのオプション[A]を示す。
しかしながら、リピータ内部のコンポーネントは、ページ間で異なる特定のデータ(例えば、テキスト又は画像ソース)を依然として有することができる。このようなデータは、ユーザによって手動で、またはリピータをデータソース(インメモリテーブル、データベース、外部CMSなど)に関連付けることによって管理することができる。ユーザは、基礎となるデータベースまたはCMS50によって提供されるインターフェースを介してデータを管理することができる。
リピータは、表示されたデータとは別個のアイテムを使用することができる。例えば、リピータは、一連のデータ要素(要素1/2/3/4、2/3/4/5などを示す)に「ウインドウ」を形成する4つのボックスのセットを表示することができる。
リピータは、(ここで参照される図16Bに示されるように)「Manage Items」のユーザインターフェース[B]を提供して、例えば、表示方法および配置、行当たりの最大数、ならびに表示の他の属性を選択するアイテムを管理することができる。
ここで参照される図16Cに示されるように、アイテムがリピータに追加されるとき(例えば、item1およびその複製を複製することによって)、モジュール300は、リピータを拡張し、サブコンテナの追加の行を作成することができる。レイアウトハンドラ31022は、グリッド表示をスライダに変換するなど、他のタイプの再配置(上記のレイアウトについて説明したようである)を実行することができる。
本明細書で上述したように、応答編集グリッドは、ほとんどのコンテナに適用して、コンテナに含まれるコンポーネントの整列を助けることができるグリッドレイアウトメカニズムである。したがって、応答編集グリッドは、コンポーネントを配置するためにそれを明示的に使用するユーザに見える。
応答エディタ310により、ユーザは、応答編集グリッドをセクションおよびすべての通常のコンテナタイプに手動で適用することができる(ただし、それ自体のレイアウトメカニズムを有するレイアウトおよびリピータには適用できない)ことが理解され得る。次に、コンテナ内の応答編集グリッドの実装および処理を示す図17A~図17Dを参照する。(通常のコンテナに適用されるようである)サンプル3x3グリッド[A]が図17Aに示されている。
ここで参照する図17Bおよび17Cに示すように、ユーザは、行および列の数、行/列の測定単位およびサイズ、水平および垂直空隙などのグリッドのパラメータを指定することができる。行および列は、固定サイズまたはフレキシブルとすることができる。グリッドは、伸張、グリッド線または列の交換などを含む編集操作でさらに編集または除去することもできる。
グリッドは、(グリッドが適用された)コンテナのサブ要素のドッキングに使用することができる水平及び/又は垂直のラインを提供することが理解され得る。ドッキングは、負のマージンを使用することもでき、したがって、要素は、所与のグリッドセルエッジに固定されるが、実際には、そのエッジを部分的にグリッドセル(またはグリッド全体)の外側になるように横切る。
グリッドセルは、別個のサブコンテナではなく、したがって、コンポーネントは、異なるブレークポイント範囲についてそれらの間で移動され得ることが理解され得る。
グリッドハンドラ31029は、コンテナのサイズとグリッドのパラメータとの間で一致することができ、必要に応じて(非%単位で作業する場合であっても)ラインパラメータを変更することができる。例えば、「auto」を有するグリッド線は、(テキストのようである)大きな要素をドロップするときに伸張し得る。例えば、図17A(テキストオブジェクトをドロップする前)と図17D(テキスト「Big Title」をドロップした後)との間のグリッドの1行目のR1の比較である。
システム200は、ピクセル、%、fr(サイズ分数)、vh/vw(ビューポートのサイズに基づく)、em、rem、計算ベースなど、様々な測定ユニットをサポートすることができることが理解され得る。
フラクションユニットは、1frおよび2frのサイズを有する2つの列を(例えば)指定することを可能にする。1つ目の列は幅の1/3 を使用し、2つ目の列は幅の2/3 を使用する。
グリッドハンドラ31029は、グリッドサイズおよび測定ユニットを管理することができ、その結果、使用されるユニットに応じた変更、および、包含するコンテナ内のコンポーネントの変更が自動的に処理される。したがって、グリッドをコンテナに適用するとき、グリッドハンドラ31029は、既存のデザインを維持し、それをユニット変更を含む新しいグリッドに再計算することができる。ユーザは、ユニットおよびサイズについて心配する必要はない。グリッドハンドラ31029は、レイアウトハンドラ31022と共に、グリッドサイズに適合するようにコンテナサイズをさらに更新し、グリッドを適所に保つことができる。
背景として(他のコンポーネントに対して)使用されるイメージコンポーネントおよびイメージは、表示される前に、しばしば実質的な処理を通過することが理解され得る。特に、ユーザは、典型的には、その最も関連する部分が示されるようにイメージをクロップ(crop)することを望むことがある。定義されたクロッピング(cropping)は、(特に)イメージのデフォルトサイズとアスペクト比を定義する。応答エディタ310は、形状マスクを使用することによって非矩形クロッピングをサポートすることもできる。
また、ユーザは、イメージ中の注目点(焦点)を指定したい場合がある。これは、いくつかのイメージ表示コンポーネント(いくつかのギャラリーなど)が、ユーザがクロップ領域を定義するのではなく、焦点に基づいてイメージ表示を決定するために必要とされる。
次に、所与のコンテナおよびグリッドの背景として働くように(視覚的クロッピングを使用して)クロップされるイメージを示す図18を参照する。
システム200は、イメージ属性がブレークポイント範囲ごとに定義されることを可能にし得ることが理解され得る。したがって、ユーザは、自分のサイトにイメージの単一のコピーを埋め込むことができるが、異なるクロップ(および結果として生じるアスペクト比)と、各ブレークポイント範囲についての異なる焦点とを定義することができる。したがって、ページは、単一のイメージコンポーネントを有するが、この単一のコンポーネントから複数の生成された出力を有する。
イメージハンドラ31032は、(例えば)イメージが異なるブレークポイント範囲に適合するように既に調整されている(例えば、縮小されている)ので、この能力を応答エディタ310によって行われた他の変更と統合することができる。イメージハンドラ31032は、ズーム、フォーカス、カラー処理などの他のイメージ変更を処理することもできる。
上記の議論は、それらの出力を表示し、それらの対話を単一の画面上で処理するアプリケーションの構築に焦点を当てており、単一の画面は、非常に小さいもの(例えば、スマートウォッチディスプレイ)から非常に大きいもの(例えば、ビルボードディスプレイ)まであってもよいことが理解され得る。
異なる実施形態では、システム200は、(必ずしも連続した「ディスプレイ表面」を形成しない)複数のスクリーンにわたって分割されるアプリケーションのデザインをサポートすることができる。これは、多数の場合、例えば、複数のスクリーンとしてアクセスされる非常に大きな物理的スクリーン(例えば、ディスプレイ管理の制限のため)、マルチモニタシステム、一次ディスプレイ及び補助ディスプレイを有するシステム(例えば、システムのための「仮想リモートコントロール」としてアプリケーションの一部を実行するスマートフォン)、又はアプリケーションを実行する実際の複数の別個のモニタを有するシステムにおいて発生し得る。
このシナリオでは、アプリケーションは、複数のディスプレイ(メインディスプレイおよびリモートコントロールディスプレイなど)上に表示するように区分されてもよい。各パーティションには独自のブレークポイントのセットがあり、異なる表示サイズに個別に適応させることができる。さらに、ブレークポイントモデルは、異なる幅を有する複数のスクリーン、例えば、単一スクリーンのための1つのレイアウト定義(異なるブレークポイント範囲への細分化を伴う)、2つのスクリーンのための1つのレイアウト定義などをサポートするように拡張されてもよい。
異なるモニタは、単一のシステム200または複数のシステム200に接続することができる。これらの複数のシステムは、アプリケーションを実行する際にそれらの間で調整することができる。さらに、ディスプレイ/モニタ構成は、アプリケーション動作中に(例えば、上述のような補助ディスプレイがシステムに係合またはシステムから係合解除されるときに)変化し得る。
したがって、システム200は、そのような環境に適合された応答デザイン、流動性、および動的レイアウト編集および表示能力を提供することもでき、アプリケーションを一度デザインされたデザインを可能にし、異なる数のモニタを有するシステムで(たとえば)動作させることができる。
上記で論じたように、ML/AIエンジン350は、以下でより詳細に論じるように、システム200の目標を達成するために利用することができる。ML/AIエンジン350は、2020年12月3日に公開された米国特許公開第2020/0380060号「System and Method for Integrating User Feedback into Website Building System Services」に記載されているように、WBS2で利用可能な情報、ならびにWBSベースのトレーニングフィードバックを使用することができ、本明細書で以下でより詳細に説明するように、いくつかの機械学習モデルまたはそれらの組合せを利用することができる。
本明細書で上述したように(また、ここで再び参照する図11Cに示すように)、システム200は、ウェブサイトの外部の意味(ビジネス用語など)を有する人間の会話(discourse)の「現実世界」に対応するセクションおよびコンポーネントを提供することができる。
そのような可能なセクションおよびコンポーネントの数は非常に多いので、応答エディタ310は、カスタマイズされ、パーソナライズされた追加パネルセクションを提供することができる。追加パネルハンドラ31030は、ユーザが最も使用または追加する可能性の高いコンポーネント選択およびプリセットを用いて、追加パネルを動的に更新することができ、それらをユーザにさらに推奨することができる。追加パネルはユーザごとだけでなく、サイトごとや追加情報ごとにカスタマイズされるため、同じユーザに異なるサイトや異なるコンテキストで異なる追加パネルが表示される場合がある。
このカスタマイズは、サイトを構築する際にユーザの使用パターンを学習するためにML/AI技法を適用することができるML/AIエンジン350を使用することによって決定することができることが理解され得る。ML/AIエンジン350は、ページ、セクション、コンテナ、およびコンポーネントを含む、サイト上の要素の作成につながる新しい順次ステップから連続的に学習することができる。
さらに、この機能は、ホームページであるか、特定の意図をもつページであるかにかかわらず、サイト内のページと共に、サイトのパレット、ユーザが作成したレイアウト、ページ内に構築されている部分に基づくコンテキストデータと組み合わせることができることが理解され得る。これは、ユーザのデザイン及び意図に最も適した推奨を決定する。ML/AIエンジン350はまた、モデルを使用して、ユーザが保持する熟練度のレベル、サイトのビジネス目標、およびユーザ自身および他の同様のユーザの過去の行動によって結果を最適化することができる。
また、コンテキスト情報は、ユーザ入力ファンネルに基づく情報(例えば、入力時にユーザが回答した質問)、ユーザ属性(ビジネスおよび産業のタイプなど)、ユーザ選好(保存されたデザイン、保存されたプリセット、好き、嫌い、コレクションなど)、およびサイト属性(例えば、ユーザがどのアドオンをインストールし、どのアドオンがアクティブであるか)など、ユーザおよびサイト上で入手可能な追加情報を含むことができる。
コンテキスト情報は、さらに、現在のサイト構造、過去のアクション、ユーザデザインの選好、および現在の編集状態(選択されたコンポーネント、開いているフローティングダイアログなど)を含むことができる。編集履歴およびビジネスインテリジェンスを含むすべての情報が、本明細書で上述したCMS50の異なるリポジトリから利用可能であり得ることが理解され得る。
システム200はまた、特定のアドオン購入(サードパーティアプリケーション、WBS構成可能アプリケーション、垂直及び他のアドオン)、ならびに上記のような解析に基づく特定のコンテンツ、メディア、プリセット及び他の要素を推奨することができる。
ネクストムーブサジェスタ31041は、ML/AIエンジン350を使用し、特に、ユーザに次に何をするかを提案するために、ユーザがこれまでに行ったことに基づいて、本質的に生成的であるモデルを使用することができる。アクションは、コンポーネント提案(「ここで、第3のボタンを配置する時間である」)、及び配置提案(「次のイメージにとって最良の場所である」)、編集変更(「スタックでこれら3つのコンポーネントをより良くラップする」)、又は他のWBS動作提案とすることができる。したがって、ネクストムーブサジェスタ31041は、レコメンダ(recomender)として、または編集アシスタント(たとえば、「自分のためにそれをする」アシスタント)として機能し、エクスプレーナおよびサジェスタ3104を介してユーザとインターフェースすることができる。
ネクストムーブサジェスタ31041は、ユーザに複数の代替案を提供することができる(選択と同時に、またはエクスプレーナおよびサジェスタ3104を通じた「何か他のものを提案する」オプションを介して)。また、既存のコンポーネントに対して異なる構成を提供することもできる。
ここで、シナリオ推奨を含むシーンを示す図19Aおよび19Bを参照する。図19Aは、テキストボックス[A]を狭くし、その下のボタン[B]と重なるテキスト「HUGE TITLE」を2行に分けた場合を示している。そのような場合、ネクストムーブサジェスタ31041(ML/AIエンジン350を使用する)は、図19Bに示すように、2つのフィールド(テキストフィールド[A]およびボタン[B])をスタックコンテナ[C]で囲むようにユーザに提案することができる。
ネクストムーブサジェスタ31041は、これをユーザへの提案として行うか、またはユーザからの提案および要求確認を直接実装することができる。これは、ユーザが通常の「取り消し」機能を使用して提案された変更を取り消せるようにするのと同じくらい簡単である可能性がある。このようなフィードバックは、追加の訓練材料としてML/AIエンジン350によって使用されるネクストムーブサジェスタモデルに直接供給することができる。
ネクストムーブサジェスタモデルは、ユーザのアクションおよび編集履歴の解析、環境、コンテキスト(本明細書で上述したようである)、所望の目的、ユーザが配置しようとしているコンポーネント、および他の入手可能な情報など、複数の情報ソースの解析に基づいてその予測を行うことができることを理解されたい。
特に、ネクストムーブサジェスタモデルは、(例えば、同じ基礎となるテンプレートファミリまたは他の基準を用いて)類似のサイト上で、または類似の編集シーケンスを用いて、現在のユーザおよび他のユーザによって実行されたアクションを用いて訓練され得る。
ネクストムーブサジェスタ31041は、関連するユーザクラスタ(例えば、類似のサイト編集特性を有するユーザ)を検出するために、(例えば、ユーザおよびサイトに基づく)セグメンテーション解析をさらに使用することができる。
ネクストムーブサジェスタ31041は、「デザインセンター」としても機能し、サイトデザインの一般的なレビューを実行し、このデザインに使用するための最良のレイアウト要素を予測する(それらを提案または自動作成する)。
「ネクストムーブ」モードおよび「デザインセンター」モードの両方について、ネクストムーブサジェスタ31041は、スタック、自動ドッキング(要素ごとに、レイアウトごとに、ブレークポイントごとに、再計算グリッド領域を含む)、グリッド線の追加、フレックスボックス(スタンドアロン要素として、またはスタックの一部として追加される)、およびピン留めされた要素など、通常のコンポーネントではない追加のレイアウトおよびフォーマット要素を推奨(または自動適用/作成)することができる。
さらに、上記とは異なる技法または技法の組合せセットを使用して、(特定の所望の結果について)同様の視覚的結果を達成することが可能であり得る。ネクストムーブサジェスタ31041は、生成されたレイアウト/ページの品質(変更後)を考慮して、所与のタスクを実行する複数の方法(「次のタスク」またはその他)を考慮することができる。これは、全てのブレークポイント範囲にわたるレイアウトの異なる変形の品質(様々なブレークポイント範囲間の均一性を含む)を含むことができる。
また、異なるデザインは、それらの性能及び効率が異なることがあるので、性能及び効率を考慮に入れることができる。例えば、システム200は、通常、ブラウザのレンダリングエンジンで直接実行される宣言的CSSの使用を最大化する(これは、JavaScriptコード実行よりも高速で効率的である)。したがって、ネクストムーブサジェスタ31041は、可能な解の格付けの一部としてCSS使用を最適化する解を選択することができる。
したがって、ネクストムーブサジェスタ31041は、単一のフォローアップ作用、フォローアップ作用のセット、または次に何をするかの検索または生成された説明(テキスト、ビデオ、ゲームまたはゲーム設定、アニメーション、提案されたアクション結果のシミュレーション、または音声説明を介することができる)を提供する(推奨または自動実行する)ことができる。それはまた、そのような動作または説明の任意の組み合わせを提供することができ、または他の手段を介してユーザにフィードバックを提供することができる。
本明細書で上述した処理は、ユーザが初期レイアウト(典型的には、最も広い構成、例えば、デスクトップ構成)を作成し、次いで、異なるブレークポイント範囲のための様々なより狭い構成のためにレイアウトおよびコンポーネントを手動で調整することに基づく。
代替実施形態では、応答エディタ310は、処理中のユーザをサポートすることができる。ユーザは、デスクトップバージョン(例えば)をデザインし、ネクストムーブサジェスタ31041は、それ自体で他のブレークポイント範囲にレイアウトを提案または再配置する。
これは、ルールエンジン340(米国特許第10,176,154号に記載されているものなど)を使用して、またはML/AIエンジン350を介した機械学習ベースのモデル(以下でより詳細に説明するように、ルールベースのシステム、明示的に生成されたデータ、およびユーザフィードバックを使用して訓練される)を使用して行うことができる。ネクストムーブサジェスタ31041はまた、一般に、応答エディタの複数のユーザ、すなわち、ユーザが所定のレイアウトを所定のブレークポイント範囲に適合させる方法について、収集された編集履歴に基づいて訓練され得る。
複数のブレークポイント範囲に対するサイトアダプテーションは、いくつかのコンポーネントをこれらのコンポーネントの流動バージョンで置き換えること(含まれるデータの転送およびレギュラーから流動コンポーネントへの設定を含む)を含み得ることが理解され得る。
さらに、レイアウトの理解およびコンポーネントのグループ化は、サイト解析およびサイト変換(例えば、静的に応答し、静的に移動する)に関連する複数のタスクで使用されるので、システム200の基本的な構築ブロックであることが理解され得る。
コンポーネントグルーパ31031は、サイト記述(例えば、XMLまたはJSONのようなデータ記述言語における)を、グループ定義の階層セットに変換することができる。コンポーネントグルーパ31031は、米国特許公開第2020/0380060号に記載されているようなコンポーネントグルーピングモデルを利用することができることが理解され得る。
コンポーネントグルーピングモデルは、典型的には、RNNベース、コンピュータビジョンベース、トリプレットベース、およびトリプレットとコンピュータビジョンとの組み合わせを含む、図20Aに示されているような1つ以上の基礎モデルを使用することができる。ML/AIエンジン350は、複数のそのようなモデルを組み合わせることができ、複数の基準(手動グループ化解析、一貫性、およびユーザフィードバックからの既知のグランドトゥルース(ground truth)結果との比較を含む)に従ってそれらを格付けして、それが動作しているサイトの所与の母集団またはカテゴリに対して使用すべき最良のものを決定することができる。ここで参照される図20Bは、手動でラベル付けされたページ(I)、グランドトゥルース情報に対するモデル(II)の結果の例を示す。
この情報は、レイアウトハンドラ31022だけでなく、システムのWBSワールド要素(例えば、レイアウト提案)によって直接使用されてもよい。
さらに、システム200の要素は、ページ、ページサブセット(セクションおよび他の要素コレクション)、およびレイアウトを、それらの品質に基づいて評価する能力を必要とすることが理解され得る。レイアウト品質評価は、ネクストムーブサジェスタ31041のようなシステム200の複数の要素によって使用されてもよい。
当然のことながら、米国特許第9,747,258号に記載されているようなレイアウト品質評価器47への説明に記載されているような品質評価のための多くの技術が当技術分野で知られている。ML/AIエンジン350は、品質評定を提供するためにモデルを訓練するために、ML技法およびフィードバックを使用してもよい。レイアウト品質は、個人の好みおよび好みの問題であり得ることが理解され得る。したがって、システム200の一実施形態は、(すべてのユーザについて訓練された)汎用モデルからの結果を、特定のユーザについて訓練されたモデルと組み合わせることができる。
編集プロセスが終了すると、応答エディタ310は、CMS50内の任意の変更を保存することができる。
本明細書で上述したように、応答編集モジュール300は、完全なWYSIWYG編集を提供し、プレビューワ3105は、図7A~7Fに戻って参照されるように、任意の幅について連続的にサイトをプレビューする能力を提供する。応答エディタ310はまた、編集プロセスの間、ページ全体に対する一般的なプレビューを提供してもよいことが理解され得る。したがって、プレビューワ3105は、ユーザが、図7Gに戻って参照されるように、様々なブレークポイントで特定のコンポーネント(およびコンテナ)を同時にプレビューすることを可能にすることができる。
マルチレベル制約を有する複雑な階層構造の編集は、異なる制約が互いに衝突し、解決されなければならない多くの場合を含むことが理解され得る。したがって、2つの異なるコンポーネントのドッキング制約は、ある程度衝突する可能性がある。同様に、コンテナの制約は、コンテナに含まれるコンポーネントの制約と衝突することがある。
さらに、システム200は、ML/AIエンジン350(例えば、以下でより詳細に説明する)を使用し、その作用および推奨は、ある程度不透明であり、事前定義されたルールのセットに直接基づいていない。
したがって、エクスプレーナおよびサジェスタ3104は、システム200がなぜ所与のアクションを与えるか、または特定の推奨を与えるかについての説明を(オンラインヘルプと同様に)ユーザに提供することができる。そのようなモジュールは、説明可能な人工知能の分野からの技術に基づくことができる。
本明細書で上述したように、CSSジェネレータ320は、応答性、流動性、動的レイアウトデザインの特徴を宣言型CSSにマッピングし、JavaScriptコードの使用を最小限に抑えることができる。これにより、サイトの動的および応答性の高い機能の多くは、宣言型CSSコードを介してブラウザレンダリングエンジンによって直接実行されるため、パフォーマンスとインタラクションの利点が得られる。
CSSジェネレータ320を使用することにより、JavaScript(JS)コードの使用がさらに最小限に抑えられ、サイトのロード時間およびインタラクティブ時間の値がより良好になる。ブラウザは通常、後の段階でJSコードをロードし、JS実行を開始する前にJSコード全体がロードされるのを待機する場合があるためである。
したがって、システム200は、例えば、HTML Flex Boxを使用してスタックオブジェクトを実装し、CSSグリッドなどを使用してグリッドを実装することができる。
本明細書で上述したように、システム200は、動的レイアウトおよび流動コンポーネントをウェブサイトページに実装することができる。本出願人は、システム200の機能が、流動表示(すなわち、表示ビューポート変更のための連続的なレイアウト変更)を実施することによって、および/または既存の(典型的にはデスクトップ)サイトレイアウトに異なるブレークポイント範囲のためのレイアウト変形を追加することによって、非応答サイトにも適用され得ることを見出した。これは、絶対レイアウトを伸縮可能なレイアウトに変換することを含むことができる。生成された伸縮可能なレイアウトは、両方の次元において伸縮可能であってもよい。以下の議論は、水平軸の変化に焦点を当てる。したがって、システム200はまた、元のサイトのレイアウトを修正することができ(例えば、スタックおよびレイアウトなどの応答性支持要素を追加すること)、要素またはコンポーネントをそれらの応答性または流動性を有する対応物と置き換えることもできる。
出願人は、このアプリケーションが、オンライン動的レイアウトプロセスへのブラウザ統合を可能にする前処理の使用を通じて動的レイアウトのパフォーマンスを改善することができることをさらに見出した。メッシュアプライヤ330は、ブラウザエンジンの「上」に実装されるのではなく、動的レイアウト処理の一部をブラウザレンダリングエンジン内部で(すなわち、レンダリングおよび進行中のブラウザ-ユーザインタラクションの一部として)発生させることができる表現にサイトを変換することができる。
本明細書で上述したように、レイアウトは、そのサイズおよび属性が、親によって(例えば、親の変更またはビューポート幅の変更によって)、または様々なトリガによって影響され得る流動コンポーネントを組み込み得る。ブレークポイント範囲を使用して機能を実装するために、レイアウト要素(コンポーネント、zオーダー、アンカーなど)は、スマートメッシュ形成、グリッドのセル(またはマージされたセル)がコンポーネントを表すグリッドライクフォーマットで保持される。その表現は、コンテナレベルで再帰的に作成され、すなわち、各コンテナは、それ自体のメッシュを有する。
本明細書で説明したように、ページをブラウザに送る(または、サーバ上などでページをレンダリングする)とき、スマートメッシュは、ブラウザによって直接レンダリングされてもよい特定のフォーマットに変換される。
以下の説明は、(CSSグリッド標準で定義されるようである)CSSグリッド特徴に基づくターゲットフォームを使用するシステムの実施形態に焦点を当てる。この形式は本質的に宣言的なものであり、ブラウザは上位レベルのコード(JSコードなど)を必要とせずに、動的レイアウト関連のインタラクションと処理のかなりの部分を処理できる。他の実施形態は、本明細書において以下でさらに詳細に議論されるようにすることができる。
本明細書で上述したように、システム200は、編集中(例えば、ユーザによって行われた編集変更を反映する)並びにランタイム中に動的レイアウト処理を実施することができる。システム200は、必要条件がケース間で異なり得るので、いずれのケースでも異なるメカニズムを使用することができる。第3の使用シナリオは、プレビューまたはシミュレーションモード、編集環境内で機能するウェブページのランタイムビューであってもよく、これは、通常のランタイムビューとは異なる挙動をすることができる。
本明細書で上述したように、動的レイアウトは、動的レイアウトトリガに基づいて画面上のコンポーネントを移動およびサイズ変更することを含む。コンテンツ変更に関する上記のすべての参照には、コンテンツに対するフォーマット変更も含まれ得ることが理解され得る。
(本明細書で上述したようである)トリガは、(例えば、生成された宣言的定義に基づいて)ブラウザによって内部的に処理され得るブラウザエンジンハンドル(BEH:browser engine handled)トリガ、ページまたはその中のコンポーネントに関連するJSコードによって処理され得るJavaScriptハンドル(JSH:JavaScript-handled)トリガ、およびサポートグリッド構造を更新することを必要とし得るグリッド再生成ベース(GRB:grid-regeneration based)トリガなどの複数のクラスに分割され得、通常、完全または部分的なページ再レンダリングにつながることが理解され得る。
クラスは相互に排他的ではない場合がある。例えば、一部のトリガは、それらの正確なパラメータとそれらが表すページ変更に応じて異なる方法で処理される場合がある。
したがって、メッシュアプライヤ330は、システム200のためのレンダリングプラットフォームを提供することができる。これは、コンポーネントがそれに適合されることを必要とする場合があり、特に、適合されたコンポーネントは、(ウェブページの全体的な可視時間を改善するために)JSがユーザに見える前にJSを実行することを必要とすべきではない。
システム200はまた、そのようなシステムに適合されていないコンポーネントと共に使用するためのアダプタをサポートすることができる。そのようなアダプタは、初期ページビューにコンポーネントを隠蔽し、表示の準備ができたときにのみそれを示す(例えば、特定ページの「折り畳み部分の下」に)など、ページのローディングを高速化するために多くの技法を使用することができる。
他のアダプタは、プレローダ(pre-loader)ディスプレイを使用すること、公開中、サイトアクティブ化中、またはサイト内のユーザの動きの予測に基づいて(例えば)生成され得るコンポーネントディスプレイの事前生成されたスクリーンキャプチャを使用すること、またはコンポーネントの代替(簡略化された、部分的な、またはシミュレートされた)バージョンをプレースホルダとして使用することを含み得る。
メッシュアプライヤ330は、ページコンポーネント構造を、初期ランタイムレンダリング上でCSSグリッド定義を使用してCSSジェネレータ320によって実装されるメッシュ形式に変換することができる。このように、ブラウザは、JSエンジンで実行されるJSコードを使用して動的レイアウト機能を実行するのではなく、ブラウザ独自のレンダリングエンジン(宣言型CSS定義に基づく)で実行時にページの動的レイアウト機能を実装する。
応答エディタ310はまた、メッシュアプライヤ330によって提供される同じレンダリングフレームワーク(これは、追加されたエディタUIと同様に、表示されたページステージに適用されてもよい)を実装してもよいことが理解され得る。あるいは、応答エディタ310は、レンダリングのために手続き型絶対レイアウトベースのフレームワークを使用することができる。応答エディタ310は、これら2つを組み合わせることもできる。プレビューワ3105は、典型的には、レンダリングのためにメッシュアプライヤを使用することができる(例えば、ページの実際のランタイム挙動とのより良好なパフォーマンスならびにより大きな互換性を提供するために)。このランタイム挙動は、ランタイムサーバ20によっても提供され得ることが理解され得る。
さらに、メッシュアプライヤ330は、クライアント側レンダリング、サーバ側レンダリング、または、その組み合わせである、ページの最初のレンダリングで、ブラウザのためのCSSグリッドを予め生成してもよいことが理解され得る。本明細書で上述したように、これは、各コンテナがそれ自体のグリッド定義を有することができるように、コンテナレベルで再帰的に行うことができる。
いくつかのコンポーネントおよびコンテナは、他の方法によるハンドリングに役立ち得る。例えば、リピータ及び他のリストタイプコンポーネントは、CSSフレックスボックスへの変換を介して管理及びレンダリングされてもよい(これは、2次元グリッドと比較して、リストのような1次元コレクションの処理により良く適合されてもよい)。このような代替的なハンドリングは、メッシュアプライヤ330に統合されてもよく、またはそれと並行して実行されてもよい。
また、CSSグリッド適応ページは、ブラウザが、上記のトリガの大部分(しかし、おそらくすべてではない)に応答し、処理することを可能にすることも理解され得る。(すなわち、これらは、BEHトリガである。)したがって、ブラウザは、グリッドの修正、ページの再ロードまたは再レンダリングを必要とせずに、宣言的CSSグリッド情報に基づいて、必要に応じてページを適応させることができる。そのようなBEHトリガは、例えば、以下のものを含むことができる。
複数のソースからのコンポーネントコンテンツ(コンテンツ、書式設定、その他の変更を含む)に影響する変更(データベース情報の更新、ユーザによるコンテンツの編集、ユーザとの対話、その他のソースなど)。
画面/ウインドウ/ビューポートサイズの変更(表示回転に関連する変更を含む)。
予め定義されたブレークポイント境界を横切る幅変更。このような変更は、CSSメディアクエリーの使用、およびページ/コンテナ定義に複数のレイアウトオプション(入手可能なブレークポイント範囲への幅の一致に応じて)を含めることによってサポートされる場合がある。
コンポーネントが他のコンポーネントを押し込むことに起因する変更。
他の変更およびトリガは、グリッドが修正/再生成されること、およびページが再レンダリングおよび/または再ロードされることを必要とし得ることが理解され得る。このような変更には、例えば、コンポーネント位置またはコンテナ-コンポーネントの親関係の変更(例えば、コンポーネントを1つのコンテナから別のコンテナに移動すること)を伴う同時編集変更が含まれ得る。
BEHトリガ、JSHトリガ、GRBトリガの区別は、とても優れている可能性があることに注意すべきである。例えば、コンポーネントの内容を修正する同時編集変更は再レンダリングなしに扱うことができるが、コンポーネントの位置への変更は再レンダリングを必要とする可能性がある。
システム200は、さらに、変更されたページの一部のみが更新され、再レンダリングを必要とするインクリメンタルページ更新および再レンダリングを実装してもよい。
上述したように、CSSジェネレータ320は、典型的には、レンダリングの直前にCSSグリッド定義を生成する(クライアントまたはサーバベースのレンダリングである)。特に、生成されたグリッド(およびそれが表すコンポーネント関係およびアンカー)は、フィールドの現在のコンテンツ(特定のフィールドのサイズを決定することができる)、ならびに現在のクライアント装置の属性(および特に表示幅)に依存することができる。
しかしながら、メッシュアプライヤ330から直接更新を受信する場合(図4に戻って参照する)、CSSジェネレータ320は、特定のプラットフォーム/ブラウザバージョンの組み合わせに対して、CSSグリッドのプリアダプタにおける複数のバージョンを事前に生成することができ、レンダリングの直前にそれらを(更新された値で)さらに適応させることができる。
説明した実施形態は、CSSグリッド標準を使用することが理解され得る。別の実施形態は、異なるウェブブラウザ標準または能力に基づいてもよく、特にこれらはCSSにおける宣言的レイアウト管理を提供する。
ページデザインの大部分のためにJS要素ではなく宣言的CSS要素を使用することは、すべてのJSコードをロードする前に、ブラウザが典型的にHTML及びCSSをロード、レンダリング及び表示するのに伴い、性能を改善することが理解され得る。したがって、本発明の好ましい実施形態によれば、ロードされたページは、HTMLおよびCSSがロードされると、ほとんど対話型であり、ページの「対話時間」の測定量を低減する。これは、ページが対話型である、すなわち対話型の要素(ボタンなど)が動作し、それらの機能を実行するまでにかかる時間の測定であることが理解され得る。これは、たとえ何らかの対話が機能しなくても、そのページがどのくらい迅速に表示を開始するかを測定する「閲覧時間」の測定量とは反対である。
さらに、メッシュアプライヤ330で作業するとき、CSSジェネレータ320は、コンポーネントの再使用に対応する複数の場所でグリッドスタイルを再使用することができる。したがって、CSSジェネレータ320が、所与の複合コンポーネントのグリッド表現を生成する場合、定義を1回だけ送信することができ、定義は、複合コンポーネントの複数のインスタンスで自動的に再使用することができる。これは、例えば、(繰り返し使用される)コンポーネントグループ/複合コンポーネント、ならびにリピータなどのリストベースのコンポーネントに適用される。
CSSグリッドへの変換は、CSSグリッドの異なる実装間の実装におけるバグおよび矛盾に関連する問題を解決する可能性があることが理解され得る(例えば、使用される特定の実装に適合したバージョンを生成することによって)。CSSジェネレータ320は、さらに、CSSグリッドの標準的かつ正しい挙動(正しく実装された場合であっても)が、動的レイアウトのための適切なサポートを提供しないか、または、そのような問題または欠落した能力を補償するために関連するJSコードを追加することを含めて、必要とされるアンカータイプを適切に実装しない場合を処理することができる。
ページ解析(以下でより詳細に説明する)に基づいて、メッシュアプライヤ330は、中間メッシュフォーマットまたは内部データ構造を使用することができる。これは、WBSコンポーネント定義およびページデータ構造をメッシュフォーマット(メッシュグリッド)またはデータ構造に変換し、この中間フォーマット/データ構造からCSSグリッド定義を生成することを伴うことができる。スマートメッシュ構造は、(応答性および流動性を有する)サイトを宣言的に定義するために実際に使用されることが理解され得る。CSSジェネレータ320は、WBSページ定義から直接CSSグリッド定義を直接生成することもできる。メッシュアプライヤ330は、本明細書で上述したJSHトリガを実施するのに必要な追加のJSコードをさらに生成することができる。CSSジェネレータ320は、メッシュレイアウトフォーマットをデータ記憶フォーマット、すなわち「保存する」、すなわち、展開フォーマットとして、すなわち、「公開する」か、アクセス時、すなわち「ロード時」に動的に生成するように適用または適合させてもよい。
また、上記のJSHトリガに加えて、生成されたページのいくつかの機能が、いずれにせよJSで実装されなければならないことが理解され得る。たとえば、特定の変更されたレイアウトの特定のサイズの画像を取得するには、サーバから正確なサイズにサイズ変更されたイメージを取得するために、JSがサーバ呼び出しを配置する必要がある。これは通常、CSSでは実行できない。
ここで、メッシュアプライヤ330の要素を図示する図21を参照する。メッシュアプライヤ330は、ページレシーバ3301、トリガハンドラ3302、ページアナライザ3303、およびページコンバータ3304をさらに備えることができる。
ページレシーバ3301は、WBSエディタ30から入力ページを受信することができ、あるいは、応答流動コンポーネントまたは定義されたブレークポイントなしにWBS2によってインポートされたサイトを受信することができ、トリガハンドラ3302は、入力トリガクラス(本明細書で上述したように、BEH、JSH、GRB)のタイプを認識することができる。
ページアナライザ3303は、受信されたページを解析して、その構成および最良のハンドリング方法を決定することができる。解析には、ページ階層を要素に分割し、要素間の関係(コンテナ内の要素のドッキングや適用可能な暗黙のアンカーの作成など)を決定し、テキストコンポーネントとイメージコンポーネントを「イメージ+キャプション」の一対として識別するなど、関連する場合は、可能な限りまとめて処理および移動する必要があるページ要素を大きなグループにグループ化することが含まれる。
ページアナライザ3303は、すべてのカテゴリ(BEH、JSH、およびGRBトリガ)の将来のトリガをどのように処理するかについての予備解析を実行することもできる。
ページアナライザ3303は、ページおよびそのコンポーネントの基本的な幾何学的特性(サイズ、位置、オーバーラップ、近接、レイヤなど)だけでなく、CMS50に格納されている他のWBS属性および利用可能な情報(編集履歴、拡張WBSコンポーネント属性など)も考慮に入れることができる。
ページアナライザ3303は、米国特許第10,176,154号のプリプロセッサ201およびスーパーノードクリエータ230で定義されているようなグループ化解析技術を使用することができる。これらの要素は、コンポーネントの接続(コンテンツの解析、編集履歴、その他のコンポーネントの関係など)を決定する場合がある。これは、例えば、一緒に留まっているときにより良く見えるコンポーネントのクラスタを検出するために使用することができる。
ページアナライザ3303はさらに、ML/AIエンジン350を使用して、そのようなページ解析およびコンポーネントグループ認識をサポートすることができる。ページ解析は、再帰的、すなわち、ページレベルで、ならびにページ内のコンテナに対して実行されてもよいことが理解され得る。
解析は、より早い段階、例えば、編集または公開中に(完全にまたは部分的に)実行されてもよいことがさらに理解され得る。したがって、メッシュアプライヤ330は、ページサービングステージだけでなく、編集または公開中にコンポーネント関係を検出することができる(および暗黙のアンカーを生成することができる)。これにより、システム200は、推測された(暗黙的である)アンカーに関する情報を編集中にユーザに提供することができ、ユーザは、そのようなアンカーの作成または属性に対するフィードバック、指示およびヒントを編集または他の方法で提供することができる。そのようなフィードバックは、例えば、暗黙のアンカー定義を修正するために、またはML/AIエンジン350のためのフィードバックを提供するために使用され得る。
ページアナライザ3303はまた、(例えば、ページ実行/閲覧中に)オンラインで実行されてもよい。例えば、ランタイム中のコンポーネントへの変更は、ページの再解析を必要とし、その結果、ページへの変更を必要とすることがある(おそらく、完全または部分的な再生成およびページ再ロードを必要とする)。これは、同時変更(例えば、ページの実行中に他のユーザによって行われた変更)や、ページ内で実行された変更(例えば、関連するコードの変更、あるいは、ユーザのコメントを追加することができるブログシステムのような、エンドユーザがページを変更する可能性がある場合)に適用される可能性がある。
ページコンバータ3304は、ページアナライザ3303の出力を使用して、入力ページをそれに応じて変換することができる。
ページコンバータ3304は、BEHトリガの処理を実施するページのためのCSSグリッド定義を生成することができる。作成されたグリッドは、オブジェクトフレームを、(以下に説明するように)スプリッタに取り付けられたセルまたは結合セルのセットに変換することができる。作成されたグリッドは、追加の技術を使用して、後述する余分な行およびウェッジなどのさらなる動的レイアウト処理をサポートすることができる。
変換されたページには、明示的なアンカーやその他のトリガタイプを処理するために必要なJSコードや関連する埋め込みデータなど、追加のコードおよび要素も含まれる場合がある。
ここで、ページコンバータ3304のサブ要素を図示する図22を参照する。ページコンバータ3304は、スプリッタプレイサ33041およびメッシュグリッドジェネレータ33042をさらに含んでもよい。
スプリッタプレイサ33041は、グリッドを作成する水平スプリッタを使用して、暗示的動的レイアウトアンカーを置換してもよい。各コンテナがグリッド(各コンテナはそれ自体のグリッドを有する)によって表されるように、スプリッタはコンテナごとであり、スクリーンごとではないことが理解され得る。以下の説明では、水平スプリッタに焦点を当てるが、垂直スプリッタも実施することができる。
コンポーネント間の暗黙のアンカーの代わりに、ページコンバータ3304は、コンポーネントをグリッドにアンカーすることができることが理解され得る。これは、CSSジェネレータ320によるより効率的な実行を可能にすることができる。
スプリッタは、コンポーネントをレイアウトに固定するために使用され得る仮想線であることが理解され得る。スプリッタによって固定されているコンポーネントは押して引っ張ることがあり、同じスプリッタに固定されている他のコンポーネントは、結果として生じるスプリッタの動きに影響されることがある。1つのページまたはコンテナに対して複数のスプリッタが定義されている場合がある。スプリッタは通常、JSが不要になるように宣言型CSSメカニズムを使用して実装される。
いくつかのコンポーネントは、いくつかのスプリッタへの変更によって影響を受けない併合グリッドセル内に存在し得るので、スプリッタは、いくつかのコンポーネントのみに影響を及ぼし得る。典型的な構成では、コンポーネントAは、Aが終了した後にBが開始する場合にのみコンポーネントBを押す。また、コンポーネントの高さは、その内容によってのみ変更される。コンテナについては、これは、含まれるコンポーネントによって影響されることを含む。
次に、コンポーネントとスプリッタとの間の関係を示す図23を参照すると、コンポーネント[a]~[g]およびスプリッタ1~5が示されている。図からわかるように、成分[a]は、スプリッタ1の変化によってのみ影響を受け、その高さは、そのコンテンツによって制御され、他の成分によっては制御されない。
コンポーネント[b]はスプリッタ1 によってプッシュされる。
成分[c]は、スプリッタ1および3によってプッシュされる。
コンポーネント[d、e、f、g]に関しては、各コンポーネントは、それらの「上」にあるすべての行によってプッシュされる。
任意のコンポーネント(または以下でより詳細に論じるウェッジ)を拡大または縮小することによって、グリッド内の線を上下に移動させることができることが理解され得る。このように、コンポーネントの位置は、スプリッタの移動に基づいて修正され得る。
グリッドセル内のコンポーネントは、複数の側面(例えば、グリッドセルの上面および底面)に固定されてもよく、セルサイズが変更するにつれて伸張/収縮してもよいので、同じことがコンポーネントサイズにも適用されてもよい。スプリッタプレイサ33041は、そのようなアンカーを自動または明示的なアンカーとして実装することができる。
スプリッタプレイサ33041はまた、ここで参照される図24Aおよび24Bに示されるように、コンポーネント「列」間の関係をプッシュすることによって、ユーザがこれを行うことを可能にし得る。図24Aは、コンポーネントa1がコンポーネントa2の上にあり、コンポーネントb1がb2の上にある(4つのコンポーネントが2行に整列している)状況を示す。ユーザは、コンポーネントa1がコンポーネントa2をプッシュし、コンポーネントb1がb2をプッシュすることを望むが(それらが伸張するとき)、コンポーネントa1がコンポーネントb2をプッシュすること、またはコンポーネントa2がコンポーネントb1をプッシュすることを望まない。
スプリッタプレイサ33041が、行1(Row1)と行2(Row2)との間を通過する単一のスプリッタS1を配置する場合、下方に伸張するコンポーネントa1もコンポーネントb2をプッシュする。これを防止するために、スプリッタプレイサ33041は、図24Bに示されるように、[c]ラッピングコンポーネントa1/a2および[d]ラッピングコンポーネントb1/b2とともに、2つの不可視ボックス/グループ(それぞれが、それ自身のグリッドを有する)を構築してもよい。両方のボックスは、囲みフレームKに含まれており、このように、コンポーネントa1とa2との間、およびコンポーネントb1とb2との間には、別々のプッシング関係がある。
ページアナライザ3303がページを解析し、ページコンバータ3304がページの基礎となるCSSグリッド定義を生成すると、ページをレンダリングし、表示することができることが理解され得る。ページアナライザ3303およびページコンバータ3304は、他のステージ中にも機能することができ、必ずしもレンダリングを必要としないことがあることが理解され得る。メッシュアプライヤ330は、ここで、様々なイベントおよびトリガに応答することができる。これらは、上述の様々なトリガタイプBEH、JSH、およびGRBを含むことができる。
BEHトリガ(およびその結果のコンポーネントサイズ/位置の変更)は、ページ変更下のCSSグリッドの動作を制御するブラウザ実施ルールに基づいて、ブラウザによって処理される。
次に、CSSグリッドルールのスプリッタおよびコンポーネントへの適用を示す図25を参照する。図25は、3つのコンポーネント(A、B、およびC)を有する構成を示し、シナリオIは、それらの初期状態を示す。シナリオIIでは、コンポーネントCは下方に拡大される。既定のCSSグリッドルールでは、コンポーネントCはスプリッタ#3を下にプッシュし、サイズの増大は1番目と2番目のグリッド行の間で均等に分割され(したがって、スプリッタ2はその半分だけ下に移動)、コンポーネントBが下に移動する。メッシュグリッドジェネレータ33042は、グリッドを再計算してもよい。より高いレベルのJSコードの関与を必要とせずに、ブラウザエンジン内で動作全体を実行することができることが理解され得る。
その他のトリガタイプもブラウザエンジン内で解決されない。JSHトリガは、JSコードを実行する必要がある。このコードは、ページの要素を変更する可能性がある(DOM構造を変更するなど)。また、フォローアップページの再計算が必要である。JSコードは、WBSレベル(例えば、WBSクライアントコードの一部)であってもよいし、特定のページ関連JSコードの一部(例えば、ページ関連機能)であってもよい。
いくつかの変更(ページコンポーネント階層への変更など)は、GRBトリガをトリガすることができ、メッシュグリッドジェネレータ33042によるグリッド再生成(完全または部分的)と、CSSジェネレータ320によるページの再レンダリングとを必要とする。
CSSグリッドの定義がW3標準であるので、その挙動はプラットフォーム/ブラウザ/バージョン間で均一であることが理解されるであろう。したがって、メッシュグリッドジェネレータ33042は、任意のバグおよび実装の問題、または将来発生する可能性がある任意の差異を補償することができる。
本明細書で上述したように、ページアナライザ3303は、幾何学的特性(サイズ、位置、重なり、近接、層)ならびに入手可能なWBS2属性およびCMS50に格納された他の入手可能な情報に基づいて、その解析を実行することができる。この解析は、要素の構造およびレイアウト、ならびにそれらの間の暗黙のアンカー/関係(米国特許第10,185,703号で言及されるゲートウェイ条件と同様)を決定する。この解析に基づいて、メッシュアプライヤ330は、コンポーネント間の関係(「AがBをプッシュする」など)を作成するために使用されるスマートメッシュを作成することができることが理解され得る。
当然のことながら、このスマートメッシュは、いくつかのレベルで実施することができる。例えば、限定された「プッシング行」の実装は、プッシング挙動を提供する複数の行を有するコンテナ当たり単一の列を有するCSSグリッドを使用することができる。より包括的な実施では、複数の列を持つCSSグリッドを使用できる。
次に、コンポーネントの距離とその結果として生じるドッキング効果の例を示す図26を参照する。図示のように、コンポーネント[x]は右下隅にあり、他のコンポーネント[a~d]から十分に離れている。ページアナライザ3303は、[x]が、包含フレームの右下に位置合わせされるように意図され、暗黙のアンカー[p]および[q]を有するべきであることを(その解析に基づいて)決定することができる。この効果(「ドッキング」として知られる)は、本明細書で上述したように、編集ハンドラ3102によって実行される解析の一部であってもよく、または後の解析の一部であってもよい(例えば、発行中またはページロード中)。
ここで、別のプッシングシナリオを示す図27を参照する。コンポーネント[A]および[B]は[C]より上である。もしコンポーネント[A]または[B]のいずれかが、コンポーネント[C]から十分に小さい距離[d]まで伸張するならば、それらはコンポーネント[C]を押し下げるであろう。これは、ここでは、暗黙のアンカーのアクティブ化として参照される。
ユーザは、(例えば、応答エディタ310を介してそのような命令を提供することによって)B-Cの暗黙アンカーを取り消し/無効にしながら、A-Cの暗黙アンカーをそのまま残したい場合がある。これを実施するために(ここで参照がなされる図28に示されるように)、メッシュグリッドジェネレータ33042は、コンポーネント[A]および[C]を透明容器[y]およびコンポーネント[B]の内部に別個の透明コンテナ[x]に入れてもよい。[x]および[y]の両方は、フレーム[f]内に並列に存在することができ、(それらの領域は重複するが)コンポーネントツリー内の兄弟である。したがって、コンポーネント[B]が伸張するとき、それはコンポーネント[C]に影響しない。
コンポーネントのオーバーラップに関しては、メッシュグリッドジェネレータ33042は、コンポーネントがアレイに保持され、常に順序付けられる、暗黙のzオーダー配列を採用してもよい。この順序は、HTMLのレンダリング時に使用される。したがって、後の要素がHTMLに表示されるほど、その要素のzオーダーが高くなる(兄弟関係となるものが重なり合っている場合)。
また、メッシュグリッドジェネレータ33042は、複数のコンポーネントを、生成されたグリッド内の単一のグリッドセルに配置してもよく、セル内のそれらの順序、配置、および整列を制御するために、複数の機構を使用してもよい。
特に、グリッドCSSは、複数のコンポーネントが各セルに割り当てられることができるので(例えば、固定配置コンポーネントを使用して)、それを含むセル内の各要素の座標の指定を可能にする。グリッドCSSはさらに、各コンポーネントの位置合わせおよびドッキングに関するガイダンス(例えば、コンポーネントがセル内でどのように位置合わせされるか)を指定することを可能にする。これにより、DOM順序(つまり、元のファイルテキスト内のオブジェクトの順序)に従ってzオーダーが定義された、重複するコンポーネントが可能になる。メッシュグリッドジェネレータ33042はまた、この目的のためにCSSのz-インデックス属性を使用してもよい。
上述のように、メッシュグリッドジェネレータ33042は、コンポーネント配置およびセルコンテンツ管理のための代替レイアウト方法または他のメカニズムを使用することもできる(リストまたはリピータタイプのコンポーネントのためにフレックスボックスレイアウトを使用するなど)。
メッシュグリッドジェネレータ33042は、グリッドの粒度と、単一グリッドセル内の複数要素の配置との均衡を保つことによって、レイアウト挙動を最適化してもよい。それは、特定の配置/レイアウトに対する挙動を最適化するために、より多くの又はより少ないセルに分割することができる。これは、特定のブラウザ/プラットフォーム/バージョン性能特性に依存し得る(例えば、メッシュグリッドジェネレータ33042は、異なるブラウザに対して異なるグリッドの組み合わせを生成し得る)。
ここで、要素レイアウトを維持するための余分なラインの使用を示す図29A~Cを参照する。図29Aに示されるように、コンポーネント[A]は、格子列R1に配置され、格子列R2にコンポーネント[B]が配置される。成分[C]は、両方の行(R1およびR2)にわたって伸びる。
コンポーネントが1行を超えて広がり、コンポーネントが伸張するとき、グリッド実装は、このコンポーネントが広がっているすべての行にわたる余分なスペースをどうするかを決定する必要がある。(全てのコンポーネントが正確に1行に属する場合(行スパニングなし)、問題は生じない。
この例では、コンポーネント[C]が(例えば、そのテキスト内容のサイズが増大するために)下方に伸張すると、ラインL3を下方にプッシュする(グリッド行R2の最下行)。CSSグリッドの規則的な挙動は、コンポーネントR1およびR2の両方のサイズを等しく増加させ、[A]および[B]がそれらのそれぞれのコンポーネントの一部のみを占有するようにし(図29Bに示されるように)、それによって視覚レイアウトを破壊することである。
エクストラロウ(extra row)ジェネレータ33043は、不可視の余分な行R3を追加することによって、これを(図29Cに示されるように)解決してもよい。コンポーネント[C]は、行R3まで伸びるようにされ、その結果、[C]が伸びるとき、R1およびR2に影響を及ぼすことなく、R3のサイズを増加させるだけである。
この余分なラインが定義されていても、グリッドのデフォルト動作は、3つの行(R1、R2、およびR3)の間の追加されたスペースを分割することであることが理解され得る。これを防止し、追加スペースがR1およびR2のみに行くことを確実にするために、メッシュグリッドジェネレータ33042は、「レギュラー」行(この場合、R1およびR2)が「最小コンテンツ」行として定義され、追加行(R3)が「1fr」(分数)行として定義されるグリッドを生成する。
エクストラロウジェネレータ33043は、最小量の要素を含む行を選択する標準的なグリッド空間処理アルゴリズムを実装することができる。その後、余分なスペースは、これらの選択された行の間で均等に分割される。したがって、エクストラロウジェネレータ33043は、「余分な行」を生成することができ、これにより、余分なスペースを受け取る行が常に正確に1つ(余分である)存在することが保証され、デザインが保存される。
これらの余分な行は、応答エディタ310における予想される動的レイアウト挙動のユーザの仕様に基づいて事前に作成されることが理解され得る。この仕様は、コンポーネントが下方に拡張しないことを指定する「逆アンカー」と見なすことができる。
グリッドへの変換は、ここで参照がなされる図30に図示されているようなウェッジ要素を用いることもできることが理解され得る。これは、特定のスプリッタを適所に保持し、それによって所与の行に対して最小のY値を維持する不可視の「ウェッジオブジェクト」の使用である。
ウェッジジェネレータ33044は、ウェッジ要素を目に見えないようにするために、静的高さ(例えば、500px)およびゼロ幅(0px)を有するDIV要素を使用して、ウェッジ要素を実装してもよい。
図30に示すように、スプリッタL3は、ウェッジオブジェクト[W]によって予め指定されたY値で「所定の位置に保持」される。コンポーネント[B]は、L3ラインに到達するまで下向きに伸張することができる。コンポーネント[B]がL3に達すると、L3を下方向にプッシュし始めることがある(ウェッジ[W]の端部よりも低く動かす)。コンポーネント[B]が収縮して戻ると、L3はウェッジ[W]に到達するまで戻り、そこで停止する。したがって、ウェッジ[W]は、行R2をある最小サイズに保つ。
ウェッジジェネレータ33044は、基本的に、ソフトアンカー(例えば、コンポーネント[B]の底面とL3との間)を形成し、その結果、L3は、ある点より上に上がらない。
CSSグリッドで実施されるメッシュアプライヤ330の実施形態では、内部CSSグリッドメカニズムは、いくつかの明示的なアンカータイプのための十分なサポートを提供しないことがある。
場合によっては、特に、アンカーおよび「短いアンカー」は、要素のグループを作成するコンテキストで使用される。例えば、ユーザは、製品名、説明図、および価格を表示するコンポーネントなど、一緒になって製品説明を形成する1組の要素をグループ化することができる。ユーザは、それらの全てを一緒に固定して、それらの結合されたレイアウトを保持し、編集時に一緒に移動することができる。
このような配置は、(例えば、ページアナライザ3303が、応答エディタ310に挿入されたヒント、またはテンプレートレベルでより早く挿入されたヒントを使用することによって)検出することができる。次いで、コンポーネントの配置は、明示的に定義されたグループに変換されてもよく、このグループは、軽量コンテナを使用して実装されてもよい。そのようなグループコンテナは、依然として、その子供関係にあるものをレイアウトするための内部グリッドを有し、したがって、それは、実際のコンテナを入れ子にするのと同様に挙動する。グループは、典型的には、単一のコンポーネントと見なされ、そのコンポーネントが「分解」しないように実装されてもよい。
ここで、参照する、図31は、CSSグリッドおよびメッシュグリッド構造を使用して典型的に実装することができない長距離アンカーABを示す。このシナリオでは、メッシュアプライヤ330は、関連するJSコードのフォローアップローディングによってCSSグリッドで行うことができることを補完することができる。JSコードは、ページ要素を測定し、追加のインタラクションを実装できる。JSコードはフィールドとレイアウトの変更(例えば、JS onChange()または同様のメカニズムを介して)を聞き、アンカーターゲットを明示的に変更することができる。
したがって、レイアウト、ウェッジ、およびスプリッタなどの特殊化された要素の使用とともに、流動コンポーネントおよびメッシュグリッドの使用は、WBSが、ウェブサイトの作成および編集のアクセス、編集、保存、公開段階でスマートCSS生成を組み込むことを可能にし得る。このスマートCSSは、より良いページ読み込みと処理時間を提供する一般的なランタイムコンパイルを必要とせずに、ブラウザレベルでのレンダリングを可能にすることがある。さらに、システムは、ブラウザアドオンまたはプラグイン、ブラウザ拡張、ポリフィルまたはブラウザ機能を拡張または強化することを意図した他の要素などの要素を含む、異なるブラウザとインターフェースするための追加の要素を含むことができる。
したがって、レイアウト、ウェッジ、およびスプリッタなどの特殊化された要素の使用とともに、流動コンポーネントおよびメッシュグリッドの使用は、WBSが、ウェブサイトの作成および編集のアクセス、編集、保存、公開段階でスマートCSS生成を組み込むことを可能にし得る。このスマートCSSは、より良いページ読み込みと処理時間を提供する一般的なランタイムコンパイルを必要とせずに、ブラウザレベルでのレンダリングを可能にすることがある。
特に明記しない限り、本明細書全体を通して、「処理する」、「演算する」、「計算する」、「決定する」などの用語を利用する議論は、コンピューティングシステムのレジスタおよび/またはメモリ内のデータを、コンピューティングシステムのメモリ、レジスタ、または他のそのような情報記憶、伝送、または表示デバイス内の他のデータに操作および/または変換する、クライアント/サーバシステム、モバイルコンピューティングデバイス、スマートアプライアンス、クラウドコンピューティングユニット、または同様の電子コンピューティングデバイスなど、任意のタイプの汎用コンピュータの作用および/またはプロセスを指すことが理解される。
本発明の実施形態は、本明細書の動作を実行するための装置を含むことができる。この装置は、所望の目的のために特別に構築されてもよく、または、コンピュータに格納されたコンピュータプログラムによって選択的に起動または再構成される、典型的には少なくとも1つのプロセッサおよび少なくとも1つのメモリを有するコンピューティングデバイスまたはシステムを備えてもよい。結果として得られる装置は、ソフトウェアによって命令されると、汎用コンピュータを、本明細書で説明されるような発明的要素に変えることができる。命令は、それが望まれるコンピュータプラットフォームと共に動作する本発明のデバイスを定義することができる。そのようなコンピュータプログラムは、光ディスク、磁気光ディスク、読出し専用メモリ(ROM)、揮発性および不揮発性メモリ、ランダムアクセスメモリ(RAM)、電気的にプログラム可能な読出し専用メモリ(EPROM)、電気的に消去可能およびプログラム可能な読出し専用メモリ(EEPROM)、磁気または光カード、フラッシュメモリ、ディスクオンキー、または電子命令を記憶するのに適し、コンピュータシステムバスに結合することができる任意の他のタイプの媒体を含むが、これらに限定されない、任意のタイプのディスクなどのコンピュータ可読記憶媒体に記憶することができる。コンピュータ可読記憶媒体は、クラウド記憶装置に実装することもできる。
一部の汎用コンピュータは、データネットワークおよび/または移動通信ネットワークとの通信を可能にするために、少なくとも1つの通信要素を含んでもよい。
本明細書で提示されるプロセスおよび表示は、本質的に、任意の特定のコンピュータまたは他の装置に関連するものではない。様々な汎用システムが、本明細書の教示によるプログラムと共に使用されてもよく、または、所望の方法を実行するために、より特殊化された装置を構築することが便利であることが判明してもよい。様々なこれらのシステムのための所望の構造は、以下の説明から明らかになるであろう。さらに、本発明の実施形態は、任意の特定のプログラミング言語を参照して説明されない。本明細書に記述されるように、本発明の教示を実装するために、様々なプログラミング言語が使用され得ることが理解される。
本発明の特定の特徴が本明細書に例示され、説明されてきたが、多くの修正、置換、変更、および同等なが、当業者には今や思い浮かぶであろう。従って、特許請求の範囲は、そのような修正及び変更全てを本発明の技術思想及び技術的範囲に含まれるものとして保護することを意図していることを理解されたい。