(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023159102
(43)【公開日】2023-10-31
(54)【発明の名称】モバイル向けのおよび他の表示環境をサポートするインタラクティブなサイトおよびアプリケーションの自動変換のためのシステムおよび方法
(51)【国際特許分類】
G06F 40/103 20200101AFI20231024BHJP
H04L 67/02 20220101ALI20231024BHJP
G06F 40/143 20200101ALI20231024BHJP
【FI】
G06F40/103
H04L67/02
G06F40/143
【審査請求】有
【請求項の数】12
【出願形態】OL
(21)【出願番号】P 2023122628
(22)【出願日】2023-07-27
(62)【分割の表示】P 2021159404の分割
【原出願日】2014-09-11
(31)【優先権主張番号】61/876,795
(32)【優先日】2013-09-12
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】515217409
【氏名又は名称】ウィックス.コム リミテッド.
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】ベン-アハロン ロニ
(72)【発明者】
【氏名】アブラハミ ナダヴ
(57)【要約】 (修正有)
【課題】コンバータを定義する指示を処理する少なくとも1つのプロセッサを有するクライアント/サーバシステムを介して実行可能なコンバータを提供する。
【解決手段】システム100において、コンバータ200は、サーバ150上のウェブサイト構築システムからウェブサイトページを受信する受信部を有する。前記ウェブサイトページは、ソース表示領域のためのソースレイアウトを有し、コンポーネントのオブジェクトモデル表現を有する。コンバータはまた、コンポーネント間の関係の順序及びセットを決定し、目的表示領域のための前記ウェブサイトページの目的レイアウトを形成するプロセッサを有する。前記目的レイアウトは、前記関係を決定した順序、セットの意味解析及び調停に基づいており、かつ、前記ソース表示領域の属性は、前記目的表示領域の属性とは異なる。
【選択図】
図1
【特許請求の範囲】
【請求項1】
所定のアプリケーションのための異なるサイズの表示領域間に複数のコンポーネントを有するウェブサイトページのための第1のレイアウト定義および第2のレイアウト定義を維持および作成するための方法であって、
第1の表示領域上の前記ウェブサイトページの前記複数のコンポーネント間の幾何学的および意味的関係を決定することと、
編集セッションの履歴情報を収集し、前記複数のコンポーネントのコンポーネント変更およびコンポーネント関係を検出することと、
前記第1の表示領域の表示されたコンポーネント間のアンカーであって、コンポーネントになされるレイアウト変更を制御するアンカーを分析することと、
前記決定、収集、分析および前記複数のコンポーネントのコンテンツに従って、前記複数のコンポーネントのための少なくとも1つの表示順序を生成することと、
前記第1の表示領域から第2の表示領域にコンポーネントの表示を変換することと、前記少なくとも1つの表示順序を生成することに従って前記表示順序を維持することと、
を備える方法。
【請求項2】
前記複数のコンポーネントは、アトミック、シングルページコンテナおよびマルチページコンテナのうちの少なくとも1つである、請求項1に記載の方法。
【請求項3】
前記第2の表示領域での表示に適さないコンポーネントを除去することおよび隠すことの少なくとも1つをさらに含む、請求項1に記載の方法。
【請求項4】
前記変換することは、
テンプレート内の前記複数のコンポーネントのインスタンスを修正することと、
前記複数のコンポーネントを前記第2の表示領域に適合させることと、
前記複数のコンポーネントを、前記複数のコンポーネントの決定されたシーケンス、予約されたスペース、およびグループ化のうちの少なくとも1つに基づいて、前記第2の表示領域内に配置することと、
前記第2の表示領域に表示する前に、前記配置された複数のコンポーネントを調節することと、
を備える、請求項1に記載の方法。
【請求項5】
前記グループ化は、前記複数のコンポーネントの中から、前記第2の表示領域上に一緒に残るべきグループを位置特定することと、前記コンポーネントの位置および前記コンポーネントのコンテンツ関係に従って、位置特定されたグループのコンポーネントを表すために、サブ要素を有するスーパーノードの階層を作成することと、を備える、請求項4に記載の方法。
【請求項6】
前記グループ化は、
コンポーネントが大きく重複している前記複数のコンポーネントのグループを位置特定し、グループ化基準に従って前記グループを仮想要素に置き換えることと、
テンプレート、アプリケーション、ページ、またはコンポーネントのレベルの少なくとも1つのヒントに従って前記複数のコンポーネントのグループを位置特定し、グループ化基準に従って前記グループを仮想要素に置き換えることと、
特定の背景画像に重複するテキストコンポーネントであるコンポーネントを位置特定し、前記グループ化基準に従って前記グループを仮想要素に置き換えることと、
前記コンポーネントが大きく重複している前記複数のコンポーネントのグループを位置特定すること、前記テンプレート、アプリケーション、ページ、またはコンポーネントのレベルの少なくとも1つのヒントに従って前記複数のコンポーネントのグループを位置特定すること、および前記特定の背景画像に重複するテキストコンポーネントであるコンポーネントを位置特定すること、の正確性についての確実性スコアを決定することと、
前記複数のコンポーネントおよび仮想要素に従ってスーパーノードの階層を作成することと
の少なくとも1つを含む、請求項4に記載の方法。
【請求項7】
前記配置することは、
前記スーパーノードの要素に付属するヒントを解釈することと、
前記グループを位置特定すること、および前記スーパーノードの階層と前記複数のコンポーネントのコンテンツ関係を作成すること、によって作成された前記ヒントに従って改行を作成することと、
前記スーパーノードの前記要素に幅調節および高さ調節の少なくとも1つを適用することと、
装飾画像をサイズ変更することと、
を備える、請求項6に記載の方法。
【請求項8】
前記第1のレイアウト定義および前記第2のレイアウト定義に対する修正を受信することと、前記少なくとも1つの表示順序、並びに前記幾何学的関係および意味関係のうちの少なくとも1つを維持しながら、前記第2の表示領域に対する更新された第2のレイアウト定義を生成することと、をさらに備える、請求項1に記載の方法。
【請求項9】
前記少なくとも1つの表示順序を生成することは、
事前定義された順序基準に従って前記サブ要素の順序を決定することと、
前記スーパーノードの前記サブ要素の意味、コンテンツ、属性、編集履歴、および幾何学的形状のうちの少なくとも1つを分析することと、
前記事前定義された順序基準に従って前記スーパーノードの前記サブ要素の順序を決定することおよび前記スーパーノードの前記サブ要素の意味、コンテンツ、属性、編集履歴、および幾何学的形状のうちの少なくとも1つを分析することの正確性についての確実性スコアを決定することと、
前記事前定義された順序基準に従って前記スーパーノードの前記サブ要素の順序を決定することおよび前記スーパーノードの前記サブ要素の意味、コンテンツ、属性、編集履歴、および幾何学的形状のうちの少なくとも1つを分析することの正確性についての前記確実性スコアを決定することによって決定された順序を統合し、マージされた修正順序を作成することと、
を備える請求項6に記載の方法。
【請求項10】
前記調節することは、
自動的に追加されたモバイル関連コンポーネントを挿入することと、
動的レイアウトアンカーを作成、変更、および削除することの少なくとも1つを実行することであって、前記アンカーが前記第2の表示領域に応じて調整される、実行することと、
の少なくとも1つを備える、請求項4に記載の方法。
【請求項11】
前記適合させることは、
前記複数のコンポーネントのサイズおよび幅を修正することと、
メニューコンポーネントを統合することと、
コンテンツに関連する適合を更新することと、
複合メニューを作成することと、
キャラクタベースのグラフィックを変換することと、
を備える、請求項4に記載の方法。
【請求項12】
前記更新されたレイアウト定義を生成することは、
前記ページが前記第1のレイアウト定義から削除されたときに、前記第2のレイアウト定義からページを削除することと、
前記ページが前記第1のレイアウト定義に追加されたときに、前記第2のレイアウト定義にページを追加することと、
コンポーネントが前記第1のレイアウト定義から削除された場合に、前記第2のレイアウト定義から前記コンポーネントを削除することと、
コンポーネントが前記第2のレイアウト定義に追加されたときに、前記第2のレイアウト定義に前記コンポーネントを追加することと、
前記第1のレイアウト定義においてコンポーネントが修正された場合に、前記第2のレイアウト定義から前記コンポーネントを修正することと、
前記第2のレイアウト定義に対する修正を操作することであって、前記修正は前記第1のレイアウト定義に対する修正とは独立している、操作することと、
を備える、請求項8に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、インタラクティブなアプリケーションの変換、および、特にモバイルプラットフォームに関する。
【背景技術】
【0002】
インターネットの始まりによって、近年、ユーザはますます、スマートフォン、タブレット、および、他のモバイル機器を使用してウェブサイトおよびインタラクティブなアプリケーションにアクセスしている。これら機器は、フル機能のデスクトップパーソナルコンピュータおよび古い、機能の劣る「フィーチャーフォン」の両方を次第に取って代わりつつあるか、または、それら両方を補完しつつある。これは、ワールドワイドウェブ上に存在するウェブサイトのみならず、今日、Apple、Google、Microsoft、および、Amazon等の大手会社によって提供される多くのアプリケーションストアから入手可能な他のインタラクティブなアプリケーションにも当てはまる。
【0003】
ウェブサイトおよびインタラクティブなアプリケーションの表示フォームファクタおよび特徴は、どこで閲覧されるか(例えば、デスクトップPC上、小型のモバイル機器、および、中型のモバイルタブレット)に応じて異なる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】米国特許出願第14/207,761号明細書
【特許文献2】米国特許第7,203,901号明細書
【特許文献3】米国特許出願公開第2013/0219263号明細書
【発明の概要】
【発明が解決しようとする課題】
【0005】
本発明の好ましい実施形態によれば、コンバータを定義する指示を処理する少なくとも1つのプロセッサを有するクライアント/サーバシステムを介して実行可能なコンバータが提供される。本コンバータは、ウェブサイト構築システムからウェブサイトページを受信する受信部であって、前記ページは、ソース表示領域のためのソースレイアウトを有し、前記ページは、コンポーネントのオブジェクトモデル表現を有する、受信部を有する。本コンバータはまた、前記コンポーネント間の関係の順序およびセットを決定し、かつ、目的表示領域のための前記ウェブサイトページの目的レイアウトを形成するプロセッサであって、前記目的レイアウトは、前記関係の決定された順序およびセットの意味解析および調停に基づいており、前記ソース表示領域の属性は、前記目的表示領域の属性とは異なる、プロセッサを有する。
【0006】
さらに、本発明の好ましい実施形態によれば、本コンバータは、前記ソースレイアウトおよび前記目的レイアウトに対する修正を、前記目的レイアウトに独立してなされた修正を考慮して結合し、更新された目的レイアウト構成を形成する再変換コンバータを有する。
【0007】
さらに、本発明の好ましい実施形態によれば、前記プロセッサは、前記コンポーネントのオブジェクトプロパティを分析し、前記オブジェクトプロパティの前記目的表示領域上での提示のための適切性を修正するプリプロセッサと、一緒のままであるべき前記コンポーネントのグループの位置を特定し、スーパーノードの階層を前記コンポーネントの前記位置および前記コンポーネントのコンテンツ関係に基づき形成するスーパーノード形成部と、を有する。前記プロセッサはまた、前記スーパーノードそれぞれ内の要素の順序を決定する順序付け部(orderer)と、前記要素を、前記決定された順序および前記グループの少なくとも1つに基づき前記目的レイアウト内に位置付ける位置付け部と、前記位置付けられた要素を表示前に調節するポストプロセッサと、を有する。
【0008】
さらに、本発明の好ましい実施形態によれば、前記コンポーネントは、アトミックコンポーネント、シングルページコンテナコンポーネント、および、マルチページコンテナコンポーネントの少なくとも1つである。
【0009】
さらに、本発明の好ましい実施形態によれば、前記コンバータは、クライアント、サーバ、および、第三者サーバの少なくとも1つにおいて実行可能である。
【0010】
さらに、本発明の好ましい実施形態によれば、前記プリプロセッサは、テンプレート内の前記コンポーネントのインスタンスを修正するテンプレート操作部、前記目的レイアウトに適さない前記コンポーネントをフィルタリングするコンポーネントフィルタ部、前記コンポーネントを前記目的レイアウトに適合させるコンポーネント適合部、前記コンポーネントを前記目的レイアウトに合わせて調節するコンポーネント調節部、および、前記コンポーネントの前記属性を分析して前記コンポーネントの使用法の適切性を決定するコンポーネント分析部、の少なくとも1つを有する。
【0011】
さらに、本発明の好ましい実施形態によれば、前記スーパーノード形成部は、前記コンポーネント同士が大きく重複する場合の前記コンポーネントのグループの位置を特定し、前記グループをグループ化基準に従って仮想要素で置換する重複グループ位置特定部と、前記コンポーネントのグループの位置をテンプレート、アプリケーション、ページ、または、コンポーネントのレベルの少なくとも1のヒントに従って特定し、前記グループをグループ化基準に従って仮想要素で置換する事前定義済みグループ位置特定部と、を有する。前記スーパーノード形成部はまた、前記コンポーネントが特定の背景画像の上に重ねられているテキストコンポーネントである場合のコンポーネントの位置を特定し、前記グループをグループ化基準に従って仮想要素で置換する画像上テキストグループ位置特定部(text over image group locator)と、前記重複グループ位置特定部、前記事前定義済みグループ位置特定部、および、前記画像上テキストグループ位置特定部の正確さについての確実性スコアを決定するスコアラと、スーパーノードの階層を前記コンポーネントおよび前記仮想要素に基づき形成するノード形成部と、を有する。
【0012】
さらに、本発明の好ましい実施形態によれば、前記順序付け部は、前記スーパーノードの前記要素の順番を事前定義済みの順序基準に従って決定する基本的順序付け部と、前記スーパーノードの前記要素の意味、コンテンツ、属性、編集履歴、および、幾何学的形状の少なくとも1つを分析する部分的順序セット位置特定部と、前記基本的順序付け部および前記部分的順序セット位置特定部の正確さについての確実性スコアを決定するスコアラと、前記基本的順序付け部によって決定された順番を前記部分的順序セット位置特定部によって位置が特定された、検出された部分的順序セットと統合し、結合された修正順序を形成する順序統合部と、を有する。さらに、本発明の好ましい実施形態によれば、前記ポストプロセッサは、自動追加コンポーネントおよびモバイル関連コンポーネントの少なくとも1つを挿入する自動追加コンポーネント挿入部と、動的レイアウトアンカーの形成、修正、および、除去の少なくとも1つを行う動的レイアウト調整部であって、前記動的レイアウトアンカーは、前記目的レイアウトに従って調節される動的レイアウト調整部と、を有する。さらに、本発明の好ましい実施形態によれば、前記基本的順序付け部は、前記スーパーノードの前記要素を行および列の少なくとも一方に従って順番に並べる一次方向順序付け部と、前記スーパーノードの前記要素を行および列の少なくとも一方に従って順番に並べ、任意の行/列の分離および結合を追跡する、分離および結合を有する一次方向順序付け部(primary direction with split and merge orderer)と、前記スーパーノードの前記要素を横方向および縦方向に交互にスライスし、分割区画(divisions)の内部ツリー(internal tree)を形成し、かつ、前記要素の表示の順番を定義する横方向/縦方向スライサと、の少なくとも1つを有する。
【0013】
さらに、本発明の好ましい実施形態によれば、前記位置付け部は、前記スーパーノードの前記要素に付属するヒントを解釈するヒント解釈部と、前記ノード形成部および前記順序付け部によって形成された前記ヒントに従って改行を形成する改行形成部と、幅および高さの少なくとも一方の調節を前記スーパーノードの前記要素に適用するサイズ調節部と、装飾画像をサイズ変更するサイズ変更部と、を有する。
【0014】
さらに、本発明の好ましい実施形態によれば、前記部分的順序セット位置特定部は、前記スーパーノードの前記要素が前記スーパーノード内の前記要素間の通常の間隔に比してより近接している場合のクラスタ部分的順序セット(cluster partial order set)を検出するクラスタ部分的順序セット位置特定部と、所定のタイプの前記スーパーノードの互いに近接する前記要素の特定の組合せが存在する時に意味関係部分的順序セット(semantic relationship partial order set)を検出する意味的部分的順序セット位置特定部と、前記スーパーノードの前記要素間にセットパターンが存在する時に部分的順序セットを検出するパターン部分的順序セット位置特定部と、部分的順序セットを、既存の編集に関連するグループ化の定義、既存の動的レイアウトアンカー情報、および、コンポーネントテンプレートの様々なコンポーネントセットへの再利用の少なくとも1つに基づき検出する事前定義済み部分的順序セット位置特定部と、前記スーパーノードの前記要素の部分的順序セットを、以前の編集セッションから収集された情報に基づき検出する編集セッション情報に基づく部分的順序セット位置特定部と、を有する。
【0015】
さらに、本発明の好ましい実施形態によれば、前記自動追加コンポーネントおよびモバイル関連コンポーネントの少なくとも1つは、目的の装置に特有のウィジェット、ナビゲーションメニュー、広告、および、販売促進用素材の少なくとも1つを含む。
【0016】
さらに、本発明の好ましい実施形態によれば、本コンバータは、パターン部分的順序セット位置特定部を有し、前記横方向/縦方向スライサは、前記スーパーノードの前記要素のスライス方向を、仕切り(dividers)の数、所定の投影方向において発見されたギャップのサイズ、前記位置特定されたパターン部分的順序セット、および、横方向/縦方向の両方向における軸投影へのアライメント品質の少なくとも1つに基づき決定する要素分割部を有する。さらに、本発明の好ましい実施形態によれば、前記コンポーネントフィルタ部は、前記目的レイアウトでの表示に適さないコンポーネントを除去する除去部と、前記目的レイアウトでの表示に適さないコンポーネントを隠す隠蔽部と、を有する。
【0017】
さらに、本発明の好ましい実施形態によれば、前記コンポーネント適合部は、前記コンポーネントのサイズおよび幅を修正する修正部と、メニューコンポーネントを統合する統合部と、コンテンツに関連する適合を更新するコンテンツ更新部と、複合メニューを形成する形成部と、キャラクタベースのグラフィックスを変換するキャラクタコンバータと、を有する。
【0018】
さらに、本発明の好ましい実施形態によれば、前記コンポーネント調節部は、前記ソースレイアウトと前記目的レイアウトとの間のフォントサイズマッピングを形成するマッピング部を有する。
【0019】
さらに、本発明の好ましい実施形態によれば、前記コンポーネント分析部は、前記コンポーネントが画像コンポーネントである場合に、前記コンポーネントを単一画像につなぎ合わせる画像ステッチャと、装飾画像を区別する装飾画像操作部と、を有する。
【0020】
さらに、本発明の好ましい実施形態によれば、前記再変換コンバータは、ページが前記ソースレイアウトから削除される時、前記ページを前記目的レイアウトから削除するページ削除部と、ページが前記ソースレイアウトに追加される時、前記ページを前記目的レイアウトに追加するページ追加部と、コンポーネントが前記ソースレイアウトから削除される時、前記コンポーネントを前記目的レイアウトから削除するコンポーネント削除部と、コンポーネントが前記ソースレイアウトに追加される時、前記コンポーネントを前記目的レイアウトに追加するコンポーネント追加部と、コンポーネントが前記ソースレイアウトにおいて修正される時、前記コンポーネントを目的レイアウトにおいて修正するコンポーネント修正部と、前記目的レイアウトに対する修正が前記ソースレイアウトに対する修正から独立している場合に、前記目的レイアウトに対する前記修正を操作するモバイル操作部と、を有する。
【0021】
さらに、本発明の好ましい実施形態によれば、前記コンポーネント追加部は、前記ソースレイアウトに追加されたコンポーネントに最も近接している最も近い祖先コンポーネントおよび親コンポーネントの少なくとも1つを検索する親/祖先検索部と、前記追加されたコンポーネントを、前記最も近い祖先コンポーネントおよび親コンポーネントの少なくとも1つの位置に応じて前記目的レイアウトに挿入するモバイルレイアウト追加部と、を有する。
【0022】
本発明の好ましい実施形態によれば、ウェブサイトページをウェブサイト構築システムから受信するステップであって、前記ウェブサイトページは、ソース表示領域のためのソースレイアウトを有し、前記ウェブサイトページは、コンポーネントのオブジェクトモデル表現を有する、ステップと、前記コンポーネント間の関係の順序およびセットを決定し、かつ、前記ウェブサイトページの目的表示領域のための目的レイアウトを形成するステップであって、前記目的レイアウトは、前記決定された関係の順序およびセットの意味解析および調停に基づいており、前記ソース表示領域の属性は、前記目的表示領域の属性とは異なる、ステップと、を含む。
【0023】
さらに、本発明の好ましい実施形態によれば、本方法はまた、前記ソースレイアウトおよび前記目的レイアウトに対する修正を、前記目的レイアウトに独立してなされた修正を考慮して結合し、更新された目的レイアウト構成を形成するステップを含む。
【0024】
さらに、本発明の好ましい実施形態によれば、前記決定し、かつ、形成するステップは、前記コンポーネントのオブジェクトプロパティを分析し、かつ、前記オブジェクトプロパティの前記目的表示領域上での提示のための適切性を修正するステップと、一緒のままであるべき前記コンポーネントのグループの位置を特定し、かつ、スーパーノードの階層を前記コンポーネントの前記位置および前記コンポーネントのコンテンツ関係に基づき形成するステップと、を含む。前記決定し、かつ、形成するステップはまた、前記スーパーノードのそれぞれ内の要素の順序を決定するステップと、前記要素を、前記決定された順序および前記グループの少なくとも1つに基づき前記目的レイアウト内に位置付けるステップと、前記位置付けられた要素を表示前に調節するステップと、を含む。
【0025】
さらに、本発明の好ましい実施形態によれば、前記コンポーネントは、アトミックコンポーネント、シングルページコンテナコンポーネント、および、マルチページコンテナコンポーネントの少なくとも1つである。
【0026】
さらに、本発明の好ましい実施形態によれば、前記分析し、かつ、修正するステップは、テンプレート内の前記コンポーネントのインスタンスを修正するステップ、前記目的レイアウトに適さない前記コンポーネントをフィルタリングするステップ、前記コンポーネントを前記目的レイアウトに適合させるステップ、前記コンポーネントを前記目的レイアウトに合わせて調節するステップ、および、前記コンポーネントの前記属性を分析して前記コンポーネントの使用法の適切性を決定するステップ、の少なくとも1つを含む。
【0027】
さらに、本発明の好ましい実施形態によれば、前記位置を特定し、かつ、形成するステップは、前記コンポーネント同士が大きく重複する場合の前記コンポーネントのグループの位置を特定し、かつ、前記グループをグループ化基準に従って仮想要素で置換するステップと、前記コンポーネントのグループの位置をテンプレート、アプリケーション、ページ、または、コンポーネントのレベルの少なくとも1つのヒントに従って特定し、かつ、前記グループをグループ化基準に従って仮想要素で置換するステップと、前記コンポーネントが特定の背景画像の上に重ねられているテキストコンポーネントである場合のコンポーネントの位置を特定し、かつ、前記グループをグループ化基準に従って仮想要素で置換するステップと、前記コンポーネント同士が大きく重複する場合の前記コンポーネントのグループの前記位置を特定するステップ、前記コンポーネントのグループの位置をテンプレート、アプリケーション、ページ、または、コンポーネントのレベルの少なくとも1つのヒントに従って特定するステップ、および、前記コンポーネントが特定の背景画像の上に重ねられているテキストコンポーネントである場合のコンポーネントの位置を特定するステップの正確さについての確実性スコアを決定するステップと、スーパーノードの階層を前記コンポーネントおよび前記仮想要素に基づき形成するステップと、を含む。
【0028】
さらに、本発明の好ましい実施形態によれば、前記順序を決定するステップは、前記スーパーノードの前記要素の順番を事前定義済みの順序基準に従って決定するステップと、前記スーパーノードの前記要素の意味、コンテンツ、属性、編集履歴、および、幾何学的形状の少なくとも1つを分析するステップと、前記スーパーノードの前記要素の順番を事前定義済みの順序基準に従って決定する前記ステップ、ならびに、前記スーパーノードの前記要素の意味、コンテンツ、属性、編集履歴、および、幾何学的形状の少なくとも1つを分析する前記ステップの正確さについての確実性スコアを決定するステップと、前記スーパーノードの前記要素の順番を事前定義済みの順序基準に従って決定する前記ステップ、ならびに、前記スーパーノードの前記要素の意味、コンテンツ、属性、編集履歴、および、幾何学的形状の少なくとも1つを分析する前記ステップの正確さについての確実性スコアを決定するステップによって決定された前記順番を統合し、かつ、結合された修正順序を形成するステップと、を含む。
【0029】
さらに、本発明の好ましい実施形態によれば、前記調節するステップは、自動追加コンポーネントを挿入するステップと、動的レイアウトアンカーの形成、修正、および、除去の少なくとも1つを行うステップであって、前記動的レイアウトアンカーは、前記目的レイアウトに従って調節される、ステップと、を含む。
【0030】
さらに、本発明の好ましい実施形態によれば、前記スーパーノードの前記要素の順番を事前定義済みの順序基準に従って決定する前記ステップは、前記スーパーノードの前記要素を行および列の少なくとも一方に従って順番に並べるステップと、前記スーパーノードの前記要素を行および列の少なくとも一方に従って順番に並べ、かつ、任意の行/列の分離および結合を追跡するステップと、前記スーパーノードの前記要素を横方向および縦方向に交互にスライスし、分割区画の内部ツリーを形成し、かつ、前記要素の表示の順番を定義するステップと、の少なくとも1つを含む。
【0031】
さらに、本発明の好ましい実施形態によれば、前記位置付けるステップは、前記スーパーノードの前記要素に付属するヒントを解釈するステップと、一緒のままであるべき前記コンポーネントのグループの位置を特定する前記ステップ、ならびに、スーパーノードの階層を前記コンポーネントの前記位置および前記コンポーネントの前記コンテンツ関係に基づき形成する前記ステップによって形成された前記ヒントに従って改行を形成するステップと、幅および高さの少なくとも一方の調節を前記スーパーノードの前記要素に適用するステップと、装飾画像をサイズ変更するステップと、を含む。
【0032】
さらに、本発明の好ましい実施形態によれば、前記スーパーノードの前記要素の順番を事前定義済みの順序基準に従って決定する前記ステップは、前記スーパーノードの前記要素が前記スーパーノードの前記要素間の通常の間隔に比してより近接しているクラスタ部分的順序セットを検出するステップと、所定のタイプの前記スーパーノードの互いに近接する前記要素の特定の組合せが存在する時に意味関係部分的順序セットを検出するステップと、前記スーパーノードの前記要素間にセットパターンが存在する時に部分的順序セットを検出するステップと、部分的順序セットを、既存の編集に関連するグループ化の定義、既存の動的レイアウトアンカー情報、および、コンポーネントテンプレートの様々なコンポーネントセットへの再利用の少なくとも1つに基づき検出するステップと、前記スーパーノードの前記要素の部分的順序セットを、以前の編集セッションから収集された情報に基づき検出するステップと、を含む。
【0033】
さらに、本発明の好ましい実施形態によれば、前記自動追加コンポーネントおよびモバイル関連コンポーネントの少なくとも1つは、目的の装置に特有のウィジェット、ナビゲーションメニュー、広告、および、販売促進用素材の少なくとも1つを含む。
【0034】
さらに、本発明の好ましい実施形態によれば、前記スーパーノードの前記要素間にセットパターンが存在する時に部分的順序セットを検出し、前記スーパーノードの前記要素を横方向および縦方向に交互にスライスし、分割区画の内部ツリーを形成し、かつ、前記要素の表示の順番を定義するステップは、前記スーパーノードの前記要素のスライス方向を、仕切りの数および所定の投影方向において発見されたギャップのサイズの少なくとも1つに基づき決定するステップ、前記スーパーノードの前記要素間にセットパターンが存在する時に部分的順序セットを検出する前記ステップ、および、横方向/縦方向の両方向における軸投影へのアライメント品質を含む。
【0035】
さらに、本発明の好ましい実施形態によれば、前記フィルタリングするステップは、前記目的レイアウトでの表示に適さないコンポーネントを除去するステップと、前記目的レイアウトでの表示に適さないコンポーネントを隠蔽するステップと、を含む。
【0036】
さらに、本発明の好ましい実施形態によれば、前記適合させるステップは、前記コンポーネントのサイズおよび幅を修正するステップと、メニューコンポーネントを統合するステップと、コンテンツに関連する適合を更新するステップと、複合メニューを形成するステップと、キャラクタベースのグラフィックスを変換するステップと、を含む。
【0037】
さらに、本発明の好ましい実施形態によれば、前記調節するステップは、前記ソースレイアウトと前記目的レイアウトとの間のフォントサイズマッピングを含む。
【0038】
さらに、本発明の好ましい実施形態によれば、前記分析するステップは、前記コンポーネントが画像コンポーネントである時に、前記コンポーネントを単一画像につなぎ合わせるステップと、装飾画像を区別するステップと、を含む。
【0039】
さらに、本発明の好ましい実施形態によれば、前記再変換するステップは、ページが前記ソースレイアウトから削除される時、前記ページを前記目的レイアウトから削除するステップと、ページが前記ソースレイアウトに追加される時、前記ページを前記目的レイアウトに追加するステップと、コンポーネントが前記ソースレイアウトから削除される時、前記コンポーネントを前記目的レイアウトから削除するステップと、コンポーネントが前記ソースレイアウトに追加される時、前記コンポーネントを前記目的レイアウトに挿入するステップと、コンポーネントが前記ソースレイアウトにおいて修正される時、前記コンポーネントを目的レイアウトにおいて修正するステップと、前記目的レイアウトに対する修正が前記ソースレイアウトに対する修正から独立している場合に、前記目的レイアウトに対する前記修正を操作するステップと、を含む。
【0040】
さらに、本発明の好ましい実施形態によれば、前記コンポーネントを追加するステップは、前記ソースレイアウトに追加されたコンポーネントに最も近接している最も近い祖先コンポーネントおよび親コンポーネントの少なくとも1つを検索するステップと、前記追加されたコンポーネントを、前記最も近い祖先コンポーネントおよび親コンポーネントの少なくとも1つの位置に応じて前記目的レイアウトに挿入するステップと、を含む。
【0041】
本発明とみなされる主題を、本明細書の結論部において具体的に示し、かつ、明確に権利として主張する。しかしながら、本発明は、操作の機構および方法の両方と共に発明の目的、特徴、および、利点に関し、添付の図面と共に読まれる場合の下記の詳細な説明を参照することにより最良に理解され得る。
【図面の簡単な説明】
【0042】
【
図1】本発明に従って構築され動作する、視覚的アプリケーションをプラットフォーム間で変換するためのシステムの概略図である。
【
図2】本発明に従って構築され動作する、初期レイアウトコンバータの要素の概略図である。
【
図3】コンポーネントを移動した時に崩れる動的レイアウトアンカーの概略図である。
【
図4】モバイル表示において縦方向の線が不適切である理由を示す概略図である。
【
図5】本発明に従って構築され動作する、スーパーノード形成部の要素の概略図である。
【
図6】フォントサイズのおよびフィールドサイズの変更によって必要となるテキスト再流し込みの概略図である。
【
図7】サイズ変更時にアスペクト比が保たれずに正しい見た目とならない写真である。
【
図8A】本発明に従って実行された、視覚的アプリケーションと対応するスーパーノード構造との間のマッピングを示す概略図である。
【
図8B】本発明に従って実行された、視覚的アプリケーションと対応するスーパーノード構造との間のマッピングを示す概略図である。
【
図8C】本発明に従って実行された、視覚的アプリケーションと対応するスーパーノード構造との間のマッピングを示す概略図である。
【
図9】再配置前のコンテナ内のコンポーネントの概略図である。
【
図10】再配置後の
図9のコンポーネントの概略図である。
【
図11】本発明に従って構築され動作する、順序付け部の要素の概略図である。
【
図12】複数の読む順序が可能な4つのテキストパラグラフの概略図である。
【
図13】複数の読む順序を有する2つのテキストパラグラフおよび2つの写真を含む配置の概略図である。
【
図14A】本発明に従って実行される、スーパーノード内の要素セットの要素グラフへの変換を示す概略図である。
【
図14B】本発明に従って実行される、スーパーノード内の要素セットの要素グラフへの変換を示す概略図である。
【
図14C】本発明に従って実行される、スーパーノード内の要素セットの要素の順序を示す概略図である。
【
図15A】本発明に従って構築され動作する、分離および結合を有する一次方向順序付け部の機能を示すアルゴリズムである。
【
図15B】本発明に従って構築され動作する、分離および結合を有する一次方向順序付け部の機能を示すアルゴリズムである。
【
図15C】本発明に従って構築され動作する、分離および結合を有する一次方向順序付け部の機能を示すアルゴリズムである。
【
図16A】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16B】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16C】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16D】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16E】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16F】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16G】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図16H】本発明に従って構築され動作する、
図15A~
図15Cの分離および結合を有する一次方向順序付け部の処理の概略図である。
【
図18】本発明に従って構築され動作する、スーパーノードの横方向および縦方向の分割区画の概略図である。
【
図19】本発明に従って構築され動作する、以前のパターン類似性分析に基づく縦方向および横方向の分割区画の評価例である。
【
図20】本発明に従って構築され動作する、コンポーネントが横方向の線に沿ってより良好に整列している時に、スーパーノードの縦方向の分割区画がいかに好ましいかを示す概略図である。
【
図21】インターロック要素の構成の概略図である。
【
図22】位置を入れ換えたコンポーネントペアの概略図である。
【
図23】どのように4つの写真コンポーネントが2つの方法でペアに分割されることができるかを示す概略図である。
【
図24】自動追加コンポーネントの刻設後に残る非矩形の表示形状の概略図である。
【
図25】本発明に従って構築され動作する、再変換コンバータの要素の概略図である。
【
図26】本発明に従って構築され動作する、コンポーネント追加部の要素の概略図である。
【
図27】本発明に従って構築され動作する、
図25の再変換コンバータの機能を示す概略図である。
【
図28A】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図28B】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図28C】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図28D】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図28E】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図28F】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図28G】本発明に従って構築され動作する、ウェブページのデスクトップレイアウト構成からモバイルレイアウト構成への変換または再変換の際のコンポーネントの位置付けの概略図である。
【
図29】ウェブページのモバイルバージョン内にコンポーネントを挿入する方法を示す概略図である。
【
図30】ウェブページのモバイルバージョンからのコンポーネントの除去を示す概略図である。
【発明を実施するための形態】
【0043】
図示を簡略かつ明確にするために、図中の要素は、必ずしも正しい縮尺でないものと理解されたい。例えば、明確にするために、いくつかの要素の寸法が他の要素に比して誇張され得る。さらに、適切と考えられる場合、参照番号は、対応する要素または類似の要素を示すために各図間で繰り返され得る。
【0044】
本発明の完全な理解のために、以下の詳細な説明において、多くの特定の詳細を記載する。しかしながら、当業者には、本発明が上記の特定の詳細を必要とせずに実施され得ることが分かるであろう。他の例では、本発明を曖昧にしないように、周知の方法、手順、および、構成要素を詳細には説明していない。
【0045】
出願人は、既存のサイトおよびアプリケーションが典型的には、非常に一般的な高解像度の大型ディスプレイを有するデスクトップPC向けに設計されていることに気付いた。そのようなサイトおよびアプリケーションに、より小型のディスプレイを使用してアクセスする際、多くの問題が明らかになる。例えば、余分にスクロール(特に横方向のスクロール)が必要であること、わかりにくいナビゲーション、モバイル用に適合されていないフォントサイズ、モバイル機器のタッチスクリーン等に適合されないデザインおよび表示コンポーネントが含まれる。
【0046】
これらサイトは、タブレットや携帯電話等の異なる大きさのプラットフォーム上で閲覧され得るため、開発者は当該サイトまたはアプリケーションの複数のバージョンを作成し、それら複数の使用状況をサポートしかつ元のサイトの見た目および雰囲気を維持することを求められ得る。上記複数のバージョンは、視覚的レイアウト、使用時の表示コンポーネント(ウィジェット)、タッチスクリーンの方向性等を含む複数の点で異なり得る。
【0047】
出願人はまた、ウェブサイトビューを関連する閲覧プラットフォームに適合させるために変換する既存のシステムが、概して、HTML(ハイパーテキストマークアップ言語)およびXML(拡張マークアップ言語)等のマークアップ言語を使用して設計されたウェブサイトを変換するために上記問題を解決することを目的としてきたことに気付いた。これらウェブサイトは、直接的に所定のマークアップ言語で設計されたサイト、または、後のホスティングのためのマークアップ言語ファイルを形成するコードジェネレータを使用して作成されたサイトであり得る。
【0048】
既存のシステムはまた、元のウェブサイトを解析し、当該元のウェブサイトからコンテンツ情報を抽出し、修正されたモバイルサイトを作成することに焦点を当てていた。そのような技術の始まりは一般に、光学文字認識(Optical Character Recognition;OCR)およびページ分析システムであり、これら技術は、コンテンツおよびデザインの適合よりもコンテンツの抽出を目的にしている。したがって、既存のシステムは概して、コンテンツを抽出し、当該コンテンツを小型の機器上で可読にするように動作する一方、元のサイトのデザイン、見た目、および、雰囲気の多くを破壊している。
【0049】
既存のウェブサイトの分析が複雑であり得ることが理解されよう。特にサイトのいくつかの部分は動的に生成され得、サイトの要素間の関係はまた、手続き型で(procedurally実装され得る。したがって、サイトの動作中に変換(例えば、変換サーバ上で動作するヘッドレスブラウザを介した変換)が行われない限り、サイトを正確に理解することは困難である。しかしながら、かかる後者の方法には相当な負荷があり、特に、一度変換した変換結果を全ユーザのために再利用するのではなく、所定のページが各ユーザによって引き出されるたびに当該ページをモバイル向けのサイズに適合させることが要求され得る。
【0050】
既存のシステムの他の問題は、変換時の元のウェブサイトへの変更および編集のサポートである。最近のページのバージョンと同じページの以前のバージョンとを比較し、差異を特定することを試みて、いくつかのシステムが開発されていることが理解されよう。この比較は、テキストの類似性、ソースファイル内の位置、フォントの使用等に基づく比較規則を使用してなされている。これにより設計者がモバイルバージョンと元のデスクトップバージョンの要素との結び付き(binding)を手動で形成する必要があることが多い。
【0051】
しかしながら、ページの編集が変換プロセスとは別に行われるため、サイトは2つのバージョン間で急激に変化し得る。例えば、新規開発者(全く異なるスタイルの開発者)がサイト開発を開始したかもしれない。または、新規の技術またはライブラリがサイト内に組み込まれ得た。既存のシステムによって、サイトの2つのバージョンが比較され得るが、それら2つのバージョンは、同じように見えたとしても、(内的には)互いに大きく異なり得る。同じウェブサイトの2つのバージョンの比較は、ヒューリスティックに行われることができるが、大きく修正されたサイト要素を合致させることまではできないであろう。
【0052】
出願人は、上記制限がオブジェクト指向の視覚的デザインシステムを使用することによって克服され得ることに気付いた。そのようなシステムは、インタラクティブなアプリケーションおよびウェブサイトを作成するために使用され得、また、所定のアプリケーションのための様々な表示プラットフォーム間で対応するレイアウト定義を維持しかつ形成するために使用され得る。視覚的デザインシステムはまた、サイトの内的な、整合したオブジェクトデータモデルにサイトの全オブジェクトの正確な指定属性を提供し得る。したがって、視覚的デザインシステムは、単一セットのコンポーネントを有する単一のサイトまたはアプリケーションに複数の視覚的レイアウトを提供し得る。
【0053】
出願人はまた、そのような視覚的デザインシステムを使用することには、コンポーネントの変化およびコンポーネントの関係を検出することに使用され得る収集された編集セッションの履歴情報が含まれ得ることに気付いた。したがって、例えば、設計者がオブジェクトのペア(例えば、写真と説明文)を何度も複製する場合、そのようなペアが関連付けられていること、および、当該ペアのメンバは、モバイル向けに変換される時に密接したままであるべきことが推論され得る。したがって、例えばコンテナオブジェクトが、それらの元のオブジェクト階層およびオブジェクト関係を維持しつつ、変換され得る。他の情報として、共に編集されたかまたは移動されたオブジェクト、過去にグループ化されたオブジェクト、既存のオブジェクトまたはオブジェクトセットを複製することにより形成したオブジェクトまたはオブジェクトセット、および、オブジェクトを編集するタイミング(すなわち、オブジェクトの所定のサブセットに順番に適用された特定の変更が存在したか)が含まれ得る。
【0054】
視覚的デザインシステムは通常、オブジェクトごとに唯一の識別子(ID)を有し得る。そのようなIDは、異なるサイトのバージョンを合致させ、サイトの変更を整合的に維持するために使用され得る。さらに、視覚的デザインシステムは、表示されたコンポーネント間のアンカーを含む動的レイアウトを利用し得、それらアンカーは、上記表示されたコンポーネントに加えられたレイアウトの変更を制御する。そのようなアンカーは、追加的なグループ化およびレイアウトの情報を得るために使用されることができ、また、レイアウトを様々なモバイル向けの表示サイズに微調整するために使用されることができる。実際、変換サブシステムは、後に表示中に使用するためにさらなる動的レイアウトアンカーを自動的に生成し得る。
【0055】
さらに、スマートフォンが急増しているため、フルスケールの進歩したHTMLブラウジング(デスクトップ上で利用可能なブラウジングと同様のブラウジング)がモバイル環境においても一般的になってきている。したがって、全プラットフォーム(デスクトップ、タブレット、および、モバイル)上で利用可能な進歩したブラウザを利用するために、全プラットフォームのために同様の操作を使用し得るシステムが必要である。
【0056】
視覚的アプリケーションは、Microsoft社から市販されているPowerPointプレゼンテーションプログラム等の独立型システムであってもよく、同様にMicrosoft社から市販されているMicrosoft Wordオートシェイプエディタ等のより大きな編集システム内に組み込まれていてもよい。そのようなアプリケーションは通常、複数のページおよびコンポーネントから構成され、これらページおよびコンポーネントは、アトミックコンポーネントを含むページ内のコンテナ(シングルページおよびマルチページ)の階層内にさらに配置され得る。マルチページコンテナはまた、複数のミニページを表示し得る。
【0057】
ページはまた、リストアプリケーション(2014年3月13日付で出願された、本発明の譲受人と共通の譲受人に譲渡される「動的カスタマイゼーションおよび動的適合によってデータリストを統合するウェブサイト構築システム」("WEBSITE BUILDING SYSTEM INTEGRATING DATA LISTS WITH DYNAMIC CUSTOMIZATION AND ADAPTATION")と題された特許文献1において論じられたようなリストアプリケーション)および第三者アプリケーションを含み得る。ページはまた、一般ページテンプレートまたはコンポーネントテンプレート等のテンプレートを使用し得る。特定の場合には、他のすべての通常ページ内で複製されるコンポーネントを含むアプリケーションマスターページが使用される。1つのページまたは1セットのページ内のコンポーネントの配置は、レイアウトとして知られている。下記説明は、矩形の、軸に平行なコンポーネントおよびコンテナからなるレイアウトを記載するものと理解されたい。また、他のレイアウトには、回転されたかまたは歪められたオブジェクト、ならびに、動画表示領域および動画制御領域を有し得る動画再生コンポーネント等の、複数の領域からなるオブジェクト等のオブジェクトクラスを特に含む非矩形のコンポーネントおよびコンテナが含まれ得る。そのような領域は、結合されていても、交差していなくても、交差していてもよい。また、他のレイアウトには、任意の幾何学的形状からなるオブジェクトが含まれ得る。
【0058】
そのような非矩形のマルチ領域オブジェクトは、非矩形のオブジェクトのそれぞれを囲み矩形(enclosing rectangle)を使用することによって、または、拡張された非矩形のオブジェクトを操作するための幾何学的プリミティブを適合することによって操作され得ることが理解されよう。かかる適合には、軸への投影、形状間の距離;形状間の最小/最大の方向距離(すなわち、縦方向または横方向の距離)、形状の交差の検出;形状/線の交差の検出;交差領域の算出および形状の面積の算出が含まれ得る。
【0059】
各アプリケーションは、デスクトップ(ポートレイトおよびランドスケープ)およびモバイル等の複数のレイアウト構成を有し得ることがさらに理解されよう。ウェブサイトコンポーネントのいくつかのプロパティはまた、実際のコンポーネントの包含関係等のレイアウト構成ごとの値を有し得る(例えば、特定のコンポーネントはモバイルのみ、または、デスクトップ/タブレットのみに含まれ得る)。かかるコンポーネントは、コンテナコンポーネントであり得、含まれるすべての兄弟コンポーネントが共に影響される。他のプロパティには、サイズ(h,w)、位置(x,y)、zオーダ情報、スタイル(フォント、サイズ、色)、色、(例えば、所定のギャラリーがデスクトップリストコンポーネントとモバイルリストコンポーネントとで異なるギャラリータイプを使用し得る)多形コンポーネントタイプ、メニュー/ギャラリー設定(例えば、行/列のグリッドギャラリー#)、第三者アプリケーションバリアント(異なる表示サイズの複数のバリアントを有する第三者アプリケーションのための第三者アプリケーションバリアント)、および、リストアプリケーションビューの関連付け(ビューに関連付けられた所定のアイテムタイプまたはアイテムに関し、様々なリストコンポーネントに対応する様々なビューが特定されることができる)が含まれ得る。
【0060】
また、各レイアウト構成がデフォルトの画面サイズ値(ピクセル)を有し得ることが理解されよう。実際の画面サイズは或る程度異なり、かかる差異は関連する視覚的デザインシステムの動的レイアウトのサポートによって操作される。デスクトップのレイアウト構成が主レイアウト構成であり得る。デスクトップのレイアウト構成が最大の画面幅を有するからである。他のレイアウト構成は、主レイアウト構成のシャドウレイアウト構成(shadow layout configuration)と考えられ得、主レイアウト構成とは異なる画面の幅および高さを有し得る。特に、シャドウレイアウト構成の幅は、主レイアウト構成の幅より小さくてもよく(例えば、モバイルフォンでの表示)、同等であってもよく(例えば、タブレット)、または、より大きくてもよい(例えば、より大きな表示画面)。
【0061】
さらに、アプリケーションのページまたはウェブサイトのページをデスクトップバージョンからモバイルバージョンに変換する際、2つの矛盾する目的(すなわち、縮小されたページ上のコンテンツの可読性を維持すること、および、ページの視覚的レイアウトを維持すること)が存在することが理解されよう。既存のシステムのほとんどは、デザインを犠牲にしてコンテンツを抽出することを目的にする(例えば、「小型フォームファクタウェブブラウジング」("SMALL FORM FACTOR WEB BROWSING")と題された特許文献2参照)。これらシステムは、公開されているOCR/ページ分析アルゴリズムから得られ、このアルゴリズムは、対象領域からテキストを抽出し、存在する視覚的ウェブサイトデザインを維持しようとしない(または当該デザインの維持に最小限の労力しか払わない)。
【0062】
いくつかのアルゴリズムは、ページ全体またはページの要素を縮小することによって或る程度デザインおよび/またはレイアウトを維持しようとする。しかしながら、そのような縮小は非常に制限されている。特に、テキストコンテンツが、フォントサイズが縮小するにつれて急速に判読不可能になるからである。
【0063】
ここで
図1を参照する。
図1は、本発明の実施形態に係わる、プラットフォーム間での視覚的アプリケーションの変換システム100を示す。
【0064】
システム100は、初期レイアウトコンバータ200、レイアウト再変換コンバータ300、および、データベース50を備えていてもよい。初期レイアウトコンバータ200は、ページ受信部210およびプロセッサ220をさらに備えていてもよい。コンバータ200は最初に、主レイアウト構成をデスクトップからモバイル用のシャドウレイアウト構成に変換し得る。再変換コンバータ300は、主レイアウト構成のアプリケーションの編集後、レイアウト構成を再変換し得る。すべてのアプリケーションおよび構成は、データベース50上に格納され得る。
【0065】
システム100は、インターネット等の適切な通信媒体を介してデスクトップ5A、スマートフォン5B、および、第三者システムのインタフェース(プログラム間通信)5C等の様々なプラットフォームを表す様々なクライアント5と通信することができるサーバ150上のウェブサイト構築システムの一部としてインストールされ得る。サーバ150は、各プラットフォームに対応する様々なレイアウト構成(単一のプラットフォームに対応する複数のレイアウト構成を含む)を格納し得る。代替的な実施形態では、システム100はまた、クライアント上で局所的に動作し得るか、または、適切なAPI(アプリケーションプログラミングインタフェース)を介して他のシステムにサービスを提供するために適合され得る。
【0066】
初期レイアウトコンバータ200がアプリケーション内の各ページを十分幅狭のバージョンに変換し得るため、当該ページは、幅狭の画面上で縦方向のスクロールおよび(あるとしても)最小限の横方向のスクロールによって閲覧され得ることが理解されよう。システム100が適切に統合されている(例えば、ウェブサイト構築システムの関連するクライアント上で動作している)場合、システム100が、画面の寸法が変化するたびに新規レイアウトが算出されるレスポンシブモードで変換を行い得ることが理解されよう。
【0067】
ここで
図2を参照する。
図2は、プロセッサ220の要素を示す。プロセッサ220は、プリプロセッサ201、スーパーノード形成部230、順序付け部240、位置付け部270、および、ポストプロセッサ202を備える。プリプロセッサ201は、テンプレート操作部206、コンポーネントフィルタ部221、コンポーネント適合部225、コンポーネント調節部227、および、コンポーネント分析部229を備えていてもよい。ポストプロセッサ202は、自動追加コンポーネント挿入部281および動的レイアウト調整部284を備えていてもよい。形成される目的レイアウト構成は、関連するウェブサイト構築システムを介して表示部290によって表示され得ることが理解されよう。システム100が関連するウェブサイト構築システムと完全に統合され、ウェブサイト構築システムのデータ構造を直接修正する場合、ポストプロセッサ202もまた、データ構造を復旧する後処理段階を行い得ることにより、修正されたウェブサイト構築システムデータを表示部290によって表示されるように適合させ得ることが理解されよう。
【0068】
初期レイアウトコンバータ200は、アプリケーションまたはウェブサイトの各ページを個別に操作し得ることが理解されよう。通常のモードでは、初期レイアウトコンバータ200は、各ページを十分幅狭の、通常は細長いバージョンに変換し得るため、各ページは、より幅狭のモバイル画面上で縦方向のスクロールおよび最小限の横方向のスクロールによって閲覧されることができる。さらに、大型のタブレットおよび屋外用の表示画面等のいくつかの目的機器は、元のデスクトップ画面より幅広の画面を有し得るため、幅を狭くすることは必要とされず、むしろより大きな表示幅に適合させることが必要とされ得ることが理解されよう。
【0069】
初期レイアウトコンバータ200は、三次元(画面のxおよびy座標ならびに表示のzオーダ)のコンポーネントのセットを処理し得、当該コンポーネントのセットを数学的に順序付けたセットに変換し得る。生成された全順序は、情報が関連するページ上でユーザに読まれる順序を表し得る。この場合、初期レイアウトコンバータ200は、順序付けたコンポーネントを幅狭のモバイル向けの表示において表示し得る。
【0070】
初期レイアウトコンバータ200は、本明細書において以下に詳細に説明するように、変換対象のページを処理して関連するページをコンポーネントの分析およびそれらコンポーネントのコンテンツ関係に基づきスーパーノードに分割し得る。
【0071】
プリプロセッサ201は、関連するページのコンポーネントが目的の構成のレイアウトに適切であるか分析し得、必要な場合に既存のコンポーネントを修正し得る。様々な組合せのレイアウトを構成し得るが、下記の例では、デスクトップレイアウト構成からモバイルレイアウト構成への変換を説明する。テンプレート操作部206は、テンプレート内の要素のインスタンスが存在する場合に、要素の修正インスタンスを形成し得る。コンポーネントフィルタ部221は、コンポーネントのモバイルレイアウト構成にとっての適切さに応じて、それらコンポーネントをフィルタリングし得、コンポーネント適合部225は、コンポーネントを特にモバイルレイアウト構成に適合させ得、コンポーネント調節部227は、コンポーネントを特にモバイルレイアウト構成に合わせて調節し得、コンポーネント分析部229は、コンポーネントを(コンポーネントのコンテンツ、幾何学的形状、および、他の属性を含めて)分析し得ることにより、それらコンポーネントの実際の用い方を決定し得る。例えば、写真コンポーネントは、背景画像でも、コンテンツ画像でもあり得、それによりシステム100の他の部分による写真コンポーネントの操作に影響し得る。
【0072】
スーパーノード形成部230は、一緒のままであるべきコンポーネントのグループ(例えば、大きく重複するコンポーネント)の位置を特定し得る。スーパーノード形成部230はさらに、スーパーノードの階層を現在のページ、および、コンテナ階層内の要素に基づき形成し得る(場合によっては、下記にさらに説明するようにコンテナ階層を修正する)。順序付け部240は、各スーパーノードの要素の順序を決定し得る。位置付け部270は、ノードの要素をモバイルレイアウト領域内に決定された順序に基づき位置付け得、ポストプロセッサ202は、必要に応じてレイアウトへの任意の最終調節を行い得る。自動追加コンポーネント挿入部281は、(本明細書において以下にさらに詳細に説明する)任意の自動追加コンポーネント、および、順序付け後に挿入される他のモバイル関連コンポーネント(例えば、モバイル特有のメニュー)を挿入し得、また、動的レイアウト調整部284は、位置付け後に必要に応じて任意の既存のアンカーを修正し得る。表示部290は、新規レイアウトをモバイルプラットフォーム上に表示し得、場合によっては本明細書において以下にさらに詳細に説明する特定のモバイルプラットフォームに合わせた最終調節を行い得る。
【0073】
ページ受信部210は、変換対象のデスクトップレイアウト構成を有するウェブページを受信し得、当該ページをページプリプロセッサ201に送信し得る。
【0074】
本明細書において上述したように、ページの論理的配置に関するさらなる情報を提供し得るコンテナ階層が存在し得る。かかる階層は、通常の包含関係、および、1つのマルチページコンテナ内に包含されている複数の並列ミニページ等の並列包含関係を含み得る。プリプロセッサ201は、かかる階層および任意の特定のコンテナ関係を、プロセスの開始時に当該プロセスに有用であり得る情報を収集するために分析し得る。プリプロセッサ201はまた、目的のアプリケーションの画面サイズを決定し得、(サイト全体かつページ特有の("site-global and page-specific"))ナビゲーションメニューを抽出し得、それらメニューを結合して、上下メニュー等の、1つ以上の統合ページメニューを形成し得る。
【0075】
関連する視覚的デザインシステムは、マルチレベルの、および、複数のテンプレートの継承を含むテンプレートをサポートし得る。そのようなテンプレートは、シングルページ、マルチページ、または、ページ要素を含み得る。テンプレート操作部206は、テンプレートの要素の、修正されたインスタンスを形成し得るため、テンプレートのインスタンスは、局所的な修正が適用されるテンプレートコンポーネントからなり得る。さらに、テンプレート操作部206は、テンプレートのインスタンスをモバイルレイアウト構成に適合させるために必要な特定の修正を行い得る。例えば、継承されたコンポーネントが十分にページの上部または下部に近い場合、それらコンポーネントは、適切にページに特有のヘッダまたはフッタ内に含まれ得る。継承されたコンポーネントは、それらコンポーネントを継承する各ページ内で(修正を伴い)論理的に複製され得る。
【0076】
関連する視覚的デザインシステムは、継承された各コンポーネントのシングルコピーを保持し得るが、ページごとのレイアウトがそれらコンポーネントのコピーに適用されることができるようにし得る(モバイルへの適合が各ページにおいて異なり得るためである)。テンプレート操作部206は、所定のコンポーネントセットの元のテンプレートに関する情報を使用し得、テンプレートに基づくコンポーネントグループを形成し得ることにより、確実に、当該テンプレートの元の意図にいっそう良好に一致させる。関連するウェブサイトの各ページに関し、個別に、プリプロセッサ201は目的の画面の寸法等のパラメータを考慮し、要素を見直し得る。コンポーネントフィルタ部221は、モバイル表示に適さないコンポーネントを除去し得るかまたは隠し得る。一例を挙げると、そのようなコンポーネントには、(横方向の線ではなく)縦方向の分離線、Adobe Flashコンテンツ(これは、いくつかのモバイルシステム上で再生できない)、または、装飾フレーム等が含まれ得る。モバイル表示に完全に不適切なコンポーネントは、さらなる処理の前に除去される。モバイル表示に推奨されないコンポーネントに関し、コンポーネントフィルタ部221は、それらコンポーネントを完全に除去するよりも隠すことを選択し得る。この場合、本明細書において以下にさらに詳細に説明するように、それらコンポーネントがモバイル修正表示GUIによって視認され得、再挿入可能であり得る時に、ウェブサイト設計者は、それらコンポーネントをモバイルレイアウト構成内に再挿入できる。いくつかのコンポーネントは、モバイルプラットフォームに不適切であり得るかまたは推奨されないが、それでも初期レイアウトコンバータ200に実質的情報を提供し得る。
【0077】
ここで
図4を参照する。
図4は、デスクトップバージョン上のコンポーネント間の縦方向の線Eを図示する。例えば、コンポーネント間の縦方向の線は、図示のようにモバイルレイアウト構成上ではかなり無用であり得る。当該線が通常、コンポーネントセット間の長い(空の)間隔に変換され得るからである。図示のように、コンポーネントA,B,CおよびDが幅狭のモバイル表示のために再配置されて縦方向に積み重ねられている場合、縦方向の線Eによって表示スペースが無駄になり得るため、縦方向の線Eは除去されるべきである。しかしながら、縦方向の線は依然として、4つのコンポーネントA,B,C,DがA+CおよびB+DのようにではなくA+BおよびC+Dのように配置されるべきであることを示すことにおいて非常に有用である。かかる情報の利点を得るために、コンポーネントフィルタ部221は、縦方向の線に「完全に除去」または「うしろに隠す」のマークを付し得るが、それでもなお、初期レイアウトコンバータ200に必要な割当情報を提供する、視認できない幅の無い線を加える。
【0078】
コンポーネント適合部225は、本明細書において以下に詳述するように、位置付け部270によって利用され得る手段と同様の幅削減手段を利用し得る(そのような手段をこの予処理段階において動作させることができるときはいつでも利用し得る)。例えば、コンポーネント適合部225は、コンポーネントを「より軽い」("lighter")モバイルバージョンに切り替え得る。一例を挙げると、複数のミニページ(例えば、アコーディオン型の複数のミニページ)を表示し得るギャラリーから、含まれたミニページを1度に1つ表示するギャラリーへの切り替えがある。コンポーネント適合部225はまた、所定のコンポーネントの特定の「軽量」("lightweight")バージョンを、制作されたアプリケーションのモバイルバージョンでの用途に(モバイル表示用にカスタマイズされた別バージョンまたは異なるビューを介して)提供し得る。
【0079】
コンポーネント適合部225はまた、キャラクタベースのグラフィックスからベクタベースのスケーラブルなグラフィックスへの変換等の、コンテンツ関連の適合も操作し得る。設計者は、テキストキャラクタを「///////////」、「----------------」、「-=-=-=-=-=-=」等の装飾または区切りとして使用することがある。類似のベクタベースの形状に変換された後は、それらグラフィックスは、テキスト操作を必要とせずに、正確にサイズ変更されることができる。
【0080】
また、コンポーネント適合部225は、メニューコンポーネントを統一されたモバイルに適した(小型フォーマットの)メニューに統合し得る。ページは多くの場合、ページ間のおよびページ内の両方のナビゲーションのために使用される複数のナビゲーションメニューを含む。さらに、いくつかのページは、ページ自体内で定義されたメニュー、ページ内で使用されているページテンプレートから形成されるメニュー(例えば、アプリケーション全体のヘッダおよびフッタに含まれるメニュー)、および、アプリケーション構造に基づき自動的に定義されるメニュー(例えば、トップレベルページのナビゲーションメニュー)等の様々な方法で定義された複数のメニューを含み得る。コンポーネント適合部225はさらに、複合メニューを(1つ以上)形成し、評価されるメニューの、所定の形成された複合メニューに対する近接性等の基準に応じてメニューを複合メニュー内に結合し得る(例えば、ページの上から200ピクセルの全メニューを1つのトップレベルメニューに統合する)。コンポーネント適合部225は、1つの(統一されかつモバイルに適した)修正メニューまたは複数の修正メニューを直接的に挿入しても、それらメニューを「投函して」("post")後の段階で含めてもよい(例えば、位置付け部270または自動追加コンポーネント挿入部281によって含めてもよい)。これが特に関連するのは、(1つ以上の)メニューが、通常のコンポーネントのレイアウトの一部としてではなく、「浮遊し」("floating")、状況に応じてアクティブにされるレイアウト等として追加される場合である。
【0081】
コンポーネント調節部227は、コンポーネントパラメータを修正してコンポーネントの幅を削減し得る。この一例として、マトリックスギャラリーコンポーネントの1つまたは2つの列のみに対する修正がある。コンポーネント調節部227はまた、大きな装飾枠で定義されたコンポーネントを同じコンポーネントの単純な、装飾の少ないバージョンに修正し得る。
【0082】
コンポーネント調節部227は、使用される実際のサイズを反映するようにコンポーネントのサイズを変更し得る。例えば、コンポーネント調節部227は、テキストコンポーネントを実際のテキストコンテンツに応じて囲み矩形を使用して縮小し得る。
【0083】
コンポーネント調節部227はまた、内側のコンポーネントを緊密に包む(tightly wrap)コンテナを「分解」("dissolve")し得る。例えば、コンテナが、さらなるコンポーネントを有しないサブコンテナを、より大きなコンテナ内に緊密に包む場合、コンポーネント調節部227は、内側のコンテナを除去し得、2つのコンテナを1つに結合し得る。これにより、コンテナが処理に対してトランスペアレントであるため、階層のレベルが節約されることが理解されよう。
【0084】
設計者が、単一画像を一体的に視覚的に形成する同じ画像の複数の部分を追加することがある。コンポーネント調節部227は、「画像のつなぎ合わせ」("image stitching")を利用し得、複数のそのような画像コンポーネントの属性およびコンテンツを使用してそれら複数の画像コンポーネントが単一画像につなぎ合わせられるべきか検出し得る。決定は、編集履歴(すなわち、隣接する画像の縁部の寸法の類似性、画像間の分離に比した隣接する画像の縁部の重複の長さ、または、境界上の(画像コンテンツアナライザを使用して検出される)類似の色/特徴の使用に基づいて、画像が形成されかつ/または修正されたかどうか)に基づき得る。
【0085】
コンポーネント調節部227は、フォントサイズマッピングを利用し得る。任意のアプリケーションまたはページのテキストでは、多くの種類のフォントサイズが使用され得る。これらサイズは、可能であればフォントサイズの差異を維持しつつ、モバイル機器上で使用されるために所定の(より小さな)範囲にマッピングされるべきである。いくつかのフォントサイズは小さ過ぎ、いくつかは大き過ぎるであろう。上記マッピングは線形ではない、すなわち、固定の係数による乗算ではない。しかしながら、上記マッピングは、フォントサイズの単調関数である。コンポーネント調節部227は、使用されるフォントサイズの範囲を収集し得、この範囲を許容されるモバイルフォントサイズの範囲にマッピングし得る。コンポーネント調節部227は、そのようなシステム全体の、または、ユーザ、アプリケーション、ページ、もしくは、コンポーネントのレベルに特有のマッピングを提供し得る。
【0086】
アプリケーション/ページ特有のフォントサイズマッピングでは、コンポーネント調節部227は、所定の各フォントサイズのテキスト(キャラクタ)の量を計測し得、次いで、通常の(ガウシアンの)累積分布関数を使用することにより、最も一般的なキャラクタサイズが、許容されるモバイルフォントサイズの範囲の中心のフォントサイズにマッピングされる。そのようなフォントサイズは、モバイルレイアウト構成に特有のフォントサイズの再拡大・再縮小による再調節によってさらに修正され得ることが理解されよう。
【0087】
さらに、コンポーネント構造の処理時、装飾画像と、(実際のページ特有のデータの一部である)コンテンツ画像とを区別することが重要であることが理解されよう。装飾画像は、装飾画像のコンテンツがアプリケーションの実際の使用にとって決定的ではないため、より自由に拡大・縮小され(scaled)、切り取られることができる。さらに、コンテンツ画像は、下記の分析アルゴリズムにおいて他のコンポーネントと同様に分析されるべきであるが、装飾画像は分析されるべきではない。コンポーネント分析部229は、装飾画像を、特定の「装飾画像」コンポーネントタイプ、または、テンプレート、オブジェクト、コンポーネントタイプ、もしくは、設計者のレベルにおける特定のヒントのいずれかに基づき認識し得る。コンポーネント分析部229はまた、画像が或る領域を被覆しているか(例えば、画像が、画像の存在するコンテナの全体(または、ほとんど)を被覆するか)、画像が複数のコンポーネントにとって背景となっているか、または、画像が、写真が装飾として使用されることを表す「写真を列状に反復する」等の演算子を使用してコンポーネントの表示領域に適合されているかを認識し得る。装飾画像は、多くの場合、関連する特定の画像を選択していることにより、装飾画像内に含まれるコンポーネントに関して常に「緊密」なわけではない。
【0088】
本明細書において上述のように、要素が修正された後は、スーパーノード形成部230が、大きく重複し得るかまたは他の方法で関連し得、かつ、一緒に操作されるべきコンポーネントのグループの位置を特定し得る。かかる位置の特定が必要なのは、例えば、大きく重複するコンポーネントがコンポジションを形成し得、したがってサイズ変更時に同じ内的比率を維持するためにそれらコンポーネントがまとめて配置されなければならないからである。すべてのグループの位置が特定された後、スーパーノード形成部230は、コンポーネントの形成される階層組織を、現在のページおよび/またはコンテナの階層に基づきスーパーノードの階層に変換し得るため、異なる構造レベルの複数の全順序が存在することが理解されよう。各個別のページまたはミニページ(シングルページまたはマルチページのコンテナ内のページまたはミニページ)に関し、スーパーノードは、ページスーパーノードとして知られている。また、各スーパーノードは個別のエンティティと考えられ得、定義された後は、本明細書において以下にさらに詳細に説明されるようにオブジェクトが再配置され得ることが理解されよう。
【0089】
さらに、位置が特定されたグループにはまた、本明細書において上述のページスーパーノードと同様に単一のコンポーネントとして操作され得る(本明細書において以下にさらに詳述の)仮想スーパーノードに変換され得るものもあることが理解されよう。各仮想スーパーノードタイプは、特定の方法による再拡大・再縮小、限定されたサイズ変更、再編成等の、スーパーノード形成時に定義される関連付けられたモバイル適合方法を有し得ることが理解されよう。
【0090】
ここで
図5を参照する。
図5は、スーパーノード形成部230の要素を示す。スーパーノード形成部230は、重複グループ位置特定部232、画像上テキストグループ位置特定部234、事前定義済みグループ位置特定部236、ノード形成部238、および、スコアラ500(機能を
図11に関連して本明細書において下記に説明する)を含み得る。
【0091】
重複グループ位置特定部232は、大きく重複するコンポーネントセットを決定し得る。かかるコンポーネントセットは通常、共に特定のデザインを形成し得、新規レイアウト内にこのグループを位置付ける際にグループコンポーネント間の比率を同一に保持するべきである。例えば、ロゴを形成する画像およびテキストは、ロゴの構造を維持するために、画像およびテキストの新規レイアウト内でのサイズおよび位置に係わらず、同じ比率および相対的位置を保持すべきである。
【0092】
重複グループ位置特定部232は、スーパーノード内のすべてのあり得るコンポーネントのペア上をループし得る。交差するコンポーネントの各ペアについて、重複グループ位置特定部232は、2つのコンポーネントの2つの囲み矩形の小さい方の値と比較した重複量として、相対的重複量を算出し得る。上記算出は、交差面積に基づいていてもよく、(例えば、平均を使用した)各軸の相対的交差の組合せにより求められてもよい。かかる相対的交差が所定の閾値を超える場合、重複グループ位置特定部232は、コンポーネントのペアが重複していると考える。ループ終了後、重複グループ位置特定部232は、重複しているペアを共通のメンバに応じて結合させて重複グループとし得る。例えば、コンポーネントのペア[a,b]と[b,c]は、[a,b,c]に結合され得る。形成された各仮想コンポーネントのための領域は、グループ化された全コンポーネントを囲む最小の囲み矩形の領域であり得る。さらに、重複グループは概して、詳細なデザイン要素を表すため、サイズ変更のみがなされるべきであり、再配置されるべきではない。特に、そのようなグループ内のテキストコンポーネントは、コンポーネント適合部225によって実行される、本明細書において上述したフォントサイズマッピングを使用するのではなく、元のサイズに一致すべきである。したがって、テキストは、完全にフォントサイズマッピングが回避されるように、または、フォントサイズマッピングの効果を反対にするスケールファクタを使用して拡大・縮小されるべきである。
【0093】
さらに、コンポーネントには重複グループの定義から省かれ得るものもあることが理解されよう。これらコンポーネントには、横方向の線、画面幅コンテナ、および、ロゴテキストとしてではなく通常のパラグラフであるテキストとして解釈される所定の限度(例えば25文字)より大きいテキストサイズ等の特定のコンポーネントが含まれ得る。上記通常のパラグラフは、重複グループとしてマークを付されるべきではなく、また、コンポジションとしてサイズ変更されるべきではない。
【0094】
画像上テキストグループ位置特定部234は、特定の背景画像の上に重ねられているテキストコンポーネントをグループ化し得る。画像上テキストグループ位置特定部234は、テキストコンポーネントが背景画像上に設定され、テキストコンポーネントおよび背景画像の2つを共に操作すべき場合を検出し得る。画像上テキストグループ位置特定部234は、テキストコンポーネントが画像コンポーネント内に完全に含まれているか、または、テキストコンポーネントが、四辺のそれぞれにおいて囲み画像コンポーネントに十分に(所定の閾値まで)近接している現在のスーパーノード内のテキストコンポーネントおよび画像コンポーネントのペアを検索し得る。
【0095】
コンポーネントが画像上テキストではなくロゴである場合、画像上テキストグループ位置特定部234は代わりに、重複グループ位置特定部232に画像上テキストグループではなく重複グループを形成するように指示し得る。これは、テキストキャラクタの量が所定の閾値未満であること、装飾的もしくは非常に独特なフォントが使用されていること、または、通常の横方向の線ではないテキストのベースラインが使用されている(例えば、テキストが曲線に沿って描かれている)ことの基準に従ったスコアリングに基づき行われ得る。
【0096】
事前定義済みグループ位置特定部236は、コンポーネントをテンプレート、アプリケーション、ページ、または、コンポーネントのレベルのヒントに従ってグループ化し得る。これは、多くの場合、特定のデザインシステムのGUIを使用して行われるグループ化の永続化バージョンとしてみなされ得るため、複数のコンポーネントが共に操作され得る。
【0097】
重複する要素のグループの位置が特定され、グループ化された後、ノード形成部238が、本明細書において下記にさらに詳細に説明するように、それらグループを結合し得、仮想スーパーノードに変換し得、次いで、(仮想スーパーノードおよびページスーパーノードを含む)最終スーパーノードを形成し得る。残りの要素は、ばらばらになっていると考えられ得るため、本明細書において以下に説明するように順序付けが容易であり得る。
【0098】
ここで
図8A~
図8Cを参照する。
図8A~
図8Cは、スーパーノード形成部230がどのようにスーパーノードの階層を形成し得るかを例示する。本明細書において上述したように、ページおよびミニページから形成されたスーパーノードは、ページスーパーノードと考えられ得、検出されたグループから形成されたスーパーノードは、仮想スーパーノードと考えられ得る。
図8AのページP1に関し、3つのテキスト要素を含むページ(ミニページ)は、3つの要素を有するページスーパーノード(PSN1)と考えられ得る。
図8Bでは、ページP2がテキスト要素、ならびに、テキスト要素および描画要素を含む仮想スーパーノード(VSN1)を有するページスーパーノード(PSN2)と考えられ得る。ページP1およびP2がページP3内に含まれたミニページである場合、形成されるノード構造は、
図8Cに示す要素をそれぞれが有する2つのページスーパーノード(PSN1およびPSN2)を有するページスーパーノード(PSN3)であり得る。
【0099】
さらに、ノード形成部238は、緊密に包まれたコンテナをコンテナBの内側に存在するコンテナAとして定義し得、この場合、コンテナBの内側では、コンテナAおよびBのサイズは非常に類似している(すなわち、コンテナAとBとの間にはすべての辺においてわずかな余白が存在し、コンテナAがコンテナBの内側の唯一のコンポーネントである)。ノード形成部238はまた、複数のコンテナ内のコンポーネントの意味解析に基づいてコンテナを再配置し得る。例えば、ここで参照する
図9に示すように、テキストコンポーネントT1,T2,T3がコンテナC1内に含まれ、写真コンポーネントP1,P2,P3がコンテナC2内に含まれている。ノード形成部238は、意味解析を行い得、以下でさらに説明するようにコンポーネントのタイプ、近接性、および、他のコンポーネントとの関係性に基づき関連するテキストコンポーネントおよび写真コンポーネントのペアを認識し得る。かかる意味解析に基づき、ノード形成部238は、T1とP1とが関連するペアを形成していることのみならずT2-P2ペアおよびT3-P3ペアを認識し得ることにより、これら6つのコンポーネント(T1,T2,T3,P1,P2,P3)をコンテナC1およびC2から取り除き得、ここで参照する
図10に示すように上記6つのコンポーネント間の関係の情報を維持しながら、コンテナページ内に位置付け得る。
【0100】
さらに、ノード形成部238は、スーパーノード階層がより良好に視覚的配置を反映するように、所定のコンテナに実質的に重複する(例えば面積の75%超重複する)コンポーネントを、スーパーノード生成のために特定のコンテナのメンバとして分類し得る。これは、所定のコンテナ内に論理的には含まれていないコンポーネントがなおもコンテナに重複し得る視覚的デザインシステムに関連する。
【0101】
スーパーノード構造が定義された後、順序付け部240がコンポーネントセット、各(個別の)スーパーノード内に含まれているページスーパーノード、および、仮想スーパーノードの順序を付け得る。さらに、かかる基本的順序は、本明細書において下記にさらに詳細に説明する部分的順序付け部による発見の結果、さらに修正され得る。ここで
図11を参照する。
図11は、順序付け部240の要素を示す。順序付け部240は、基本的順序付け部247、部分的順序セット(Partial Order Set;POS)位置特定部250、および、順序統合部245を含み得る。基本的順序付け部247はさらに、一次方向順序付け部241、分離および結合を有する一次方向順序付け部242、および、H/Vスライサ243を含み得る。H/Vスライサ243はさらに、本明細書において以下にさらに詳述する要素分割部244を含み得る。
【0102】
POS位置特定部250は、クラスタPOS位置特定部251、意味関係POS位置特定部252、パターンPOS位置特定部253、事前定義済みPOS位置特定部254、および、ESI(編集セッション情報;Editing Session Information)に基づくPOS位置特定部255を含み得る。POS位置特定部250は、コンポーネントの意味、コンテンツ、および、幾何学的形状を分析し得ることが理解されよう。
【0103】
順序付け部240は、人間の読み手がページ上で要素を閲覧し得る順序(または特定のスーパーノード内の順序)を模倣し得ることが理解されよう。さらに、ページが二次元エンティティであるため(または、zオーダを含む三次元であっても)、かかる順序は、人間の読み手にとっても十分には定義されない場合があることが理解されよう。
【0104】
ここで
図12を参照する。
図12は、四角形に配置した4つのテキストパラグラフの配置を示す。パラグラフが英語である(上から下かつ左から右に読まれる)と仮定すると、読む順序がA1,A2,B1,B2であるべきか、または、A1,B1,A2,B2であるべきかが明確ではない。両順序とも正しいと考えられ得る。さらに、ここで参照する
図13に示すように、要素がテキストおよび写真である場合、関連するテキスト要素と写真要素がいずれであるかが明確ではない。
【0105】
一次方向順序付け部241は、一次方向を事前定義し得(すなわち、行を最初にソートするかまたは列を最初にソートし)、次いで、二次元ページ内のコンポーネントを一次方向に基づきソートし得、次いで、第2方向に基づきソートし得る。例えば、行を最初にソートするモードで動作する一次方向順序付け部241は、要素AおよびBの重複Yが適切(例えば、2つの要素の高さの低い方の少なくとも25%)でありかつ要素Aが左側である(すなわち、行内の順序)場合、または、要素AおよびBの重複Yが十分ではなくかつ要素Aがより高位である(すなわち、複数の行間の順序)場合に、要素Aが要素Bに先行するように、スーパーノード内の要素をソートし得る。
【0106】
また、分離および結合を有する一次方向順序付け部242(以下、PDSM順序付け部242)は、一次方向を事前定義し得、行/列の分離および結合を追跡し得る。これは、行よりも列にとって、より一般的と考えられ得る。ここで
図14A~
図14Cを参照する。
図14A~
図14Cは、スーパーノード内のコンポーネント(1~10)を示す。これらコンポーネントは、ノード内の生成された列グラフ内の順序に応じて順序付けられ得ることが理解されよう。PDSM順序付け部242は、(
図14Aに示すような)矩形のセットを(
図14Bに示すように結合、分離、または、連続していてもよい)列のグラフに実質的に変換し得、このグラフは次いで、コンポーネントの順序付けのために使用される(
図14C参照)。矩形は、場合によっては交差していてもよい。
【0107】
ここで
図15A~
図15Cおよび
図16A~
図16Gを参照する。
図15A~
図15Cおよび
図16A~
図16Gは、列グラフと形成される順序とを定義するためにPDSM順序付け部242によって行われるステップを示す。
図16Aは、処理が必要な要素Cのセットを示す。PDSM順序付け部242はセット内の要素間の2要素関係を定義し得(ステップ400)、次いで、図示のように順序付け対象の要素(セットC)をダミーヘッダ要素Aとダミーフッタ要素Bとの間に「挟み」("sandwitch")得る。次いで、PDSM順序付け部242は、2つの新規セット(すなわち、生成された(現在の状態の)列(ステップ420および430)とこれら列の要素とのセットX、および、列として処理する対象の要素のセットY(ステップ440および450))を形成し得る。次いで、PDSM順序付け部242は、セットYをソート(ステップ460)して、セットYの要素を上から下に要素のyオーダに従って走査し得(ステップ470)、セットYの各要素Qのために要素Qを制御する(セットX内のすべての列内の)要素のサブセットRを選択し得る。次いで、グラフ内の順序(上から下および左から右)に従って要素を配置してもよく、孤立列の場合、Xオーダに従って要素を配置してもよく(ステップ480)。ここで
図16Bを参照する。
図16Bは、どのように要素A,E,FのすべてがQを制御するかを示す。次いで、PDSM順序付け部242は、セットRから任意の複製を除去し得る。
図16Bに視認されることができるように、A,E,FのすべてがQを制御するだけでなく、AがEを制御し、EがFを制御する。この例では、PDSM順序付け部242に必要な唯一の接続は、QとF(最後に制御する要素)との間の接続であり得る。Rが空である場合、これは、接続されていない孤立列の開始と考えられ得るため、ここで参照される
図16Cに示すように、新規列が要素QによってX内に開始される。さらに、Rが2つ以上の要素を有する場合、PDSM順序付け部242は、要素Qを各要素C1~Cnを含む列に接続し得、(列の終端において接続される場合)列の連続を形成し得、または、(列の途中で接続される場合)各列の分離を形成し得る。そのような列が2つ以上存在する場合、PDSM順序付け部242は、ここで参照する
図16Dに示すように、列を結合し得る。
図16Dに示すように、PDSM順序付け部242は、列GおよびHを、要素Qによって連続する1つの列に結合し得る。ここで
図16Eを参照する。
図16Eは、列G内の最後の要素ではない要素から連続する列Gを示す。この例では、要素Qは、列G内に分離を形成し、FおよびQが連続する2つの列を形成する。
【0108】
列が所定の箇所で分離する時、分離したセットは左から右に順序付けられる(すなわち、分離した列に連続する複数の列は、それら複数の列の左端のx座標に従ってそれら複数の列のために定義された順序を有する)ことが理解されよう。列の結合についても同様である。また、PDSM順序付け部242は、ここで参照する
図16Fに示すように、分離および結合を組み合わせた状況を有し得ることが理解されよう。図示の通り、要素Qは、要素GおよびHを含む2つの列の分離を形成する。PDSM順序付け部242は、上記分離を、要素Qによって連続する1つの列に即座に結合し得る。
【0109】
したがって、PDSM順序付け部242は、要素をYからXに移し得、それら要素をX内の1つ以上の既存の列に(または場合によっては新規列を形成して)幾何学的基準に基づいて接続し得る。かかる走査プロセスは、X内に開始、分離、結合、または、終端し得る一連の列を形成し得ることが理解されよう。このプロセスは、ダミーフッタ要素Bに達する時に終了する。次いで、PDSM順序付け部242は、(セットX内の列に従って定義された)グラフを走査し得、その結果の順序を算出し得る。次いで、PDSM順序付け部242は、参照する
図16Gに示すように、要素をグラフ内の順序に従って上から下および左から右に配置し得る。
【0110】
さらに、孤立列の場合、PDSM順序付け部242は、ここで参照する
図16Hに示すように、孤立列を数字の順序(1-8)に従って配置し得ることが理解されよう。要素のペアa-cおよびb-dが接続されるために十分に近接している場合、それらペアは完全な列を形成し得、それらペア間の順序はa-b-c-dではなくa-c-b-dになり得る。上記ペアは十分に近接していないため、接続されず、要素cおよびdを孤立列にし、本明細書において上述したように、順序は具体的に示した数字の順序に修正される。
【0111】
PDSM順序付け部242の機能は、(左から右にではなく)右から左に配置されたコンテンツを有するスーパーノードに合わせて適切に修正され得ることが理解されよう。
【0112】
H/Vスライサ243は、スーパーノード内の要素を横方向および縦方向に交互にスライスしてそのように分割された分割区画の内部ツリーを形成し得ることにより、要素間の表示順序を定義し得る。そのような内部ツリーは所定のスーパーノードに特有であり、全般的なスーパーノードのレベルツリーには関係していないことが理解されよう。H/Vスライサ243は、横方向および縦方向の区画から構築される、古典的には、ここで参照する
図17に示す例示的なページのような新聞のレイアウトの、「チョコレートテーブル」スタイルのサイトに最適に適合されている。H/Vスライサ243は、1つのスーパーノードの要素セットを取得し得、ノードの内部ツリーを形成し得る(各スーパーノードはそのような個別の内部ツリーを含み得るため、ノードは、より高いレベルのスーパーノードとは異なる)。ノードは以下のタイプであり得る。
【0113】
Vノード(縦方向に配置されたノード)-上から下に配置されているサブノード/要素のセット。
【0114】
Hノード(横方向に配置されたノード)-左から右に配置されているサブノード/要素のセット(右から左の配置を本明細書において以下に説明する)。
【0115】
葉ノード-内部ツリーの最後の要素、すなわち、コンポーネントまたは包まれたスーパーノードを表すノード。葉ノードは、割り当てられた幅内に依然として適合している複数のコンポーネントを含み得る。
【0116】
URノード(未解決ノード)-依然として配置されていない複数の要素を含むノード。URノードは、Vノード/Hノード/葉ノードに変換される前の任意のノードの初期状態である。
【0117】
各ノードは、要素のセットへの参照のみならず、基礎となる各要素の座標およびサイズ、ならびに、当該ノードの要素のための完全な囲み矩形を含み得る。1つのスーパーノード内の(上記4つのタイプの)ノードのコレクション全体は、内部ツリーとして知られ得る。H/Vスライサ243は、右から左(R2L)の素材を含むかまたはR2Lレイアウトを有すると特定または検出されたスーパーノードのための手続きを調節し得る。
【0118】
H/Vスライサ243は、初期呼び出し時に、1つのURノードを有する内部ツリーを形成し得、スーパーノード内の全要素に内部ツリー内での参照を割り当て得る。H/Vスライサ243は、URノードを、当該ノード内の全要素を取得することによって操作し得る。要素の囲み矩形が許容される幅に適合する場合、H/Vスライサ243は、ノードを葉ノードに変換し得る。H/Vスライサ243はまた、URノードの要素のサブグループへの特定の(横方向または縦方向の)分割を示唆し得る要素分割部244を必要とし得る。
【0119】
次いで、H/Vスライサ243は、URノードをHノードまたはVノードに適切に変換し得る。要素分割部244によって返された各サブグループに関し、H/Vスライサ243は、サブグループ内の要素のための囲み矩形Rを算出し得ることが理解されよう。Rの幅が許容される幅に適合する場合、H/Vスライサ243は、サブグループからノードNの子孫の葉ノードを形成し得る。その他の場合では、サブグループが2つ以上のコンポーネントを有する場合、H/Vスライサ243はサブグループからノードNの子孫のURノードを形成し得、このURノードを本明細書において上述したように(すなわち、H/Vスライサ243を再帰的に適用することによって)適切に操作し得る。Rの幅が許容される幅に適合しない場合、H/Vスライサ243は1つの要素を含むサブグループからノードNの子孫の葉ノードを形成し得る。次いで、H/Vスライサ243は、本明細書において上述したように、サイズ変更、テキストの再流し込み等の幅の削減を適用し得る。
【0120】
次いで、H/Vスライサ243は、生成された内部ツリーを再帰的に(深さ優先走査を使用して)走査し得、走査順序に応じて(葉ノード等の)コンポーネントを発する(emit)。H/Vスライサ243は、自然な順序(例えば、Vノードの場合は上から下)に従ってHノード/Vノードのそれぞれを走査し得る。この段階において、要素の基本的順序が生成されているため、かかるスーパーノードの形成された内部ツリーは、もはや必要ないことが理解されよう。
【0121】
本明細書において上述のように、要素分割部244は、要素のグループの分割区画を算出し得る。要素分割部244は、装飾枠を無視し、各要素のための囲み矩形を算出し得る。次いで、要素分割部244は、これら矩形をX軸およびY軸の両軸上に投影し得る。
【0122】
次いで、要素分割部244は、軸への投影の各セットを、異なる数のコンポーネントが投影されたセグメントに分割し得る。投影されたコンポーネントが存在しないセグメントは、所定の投影方向におけるギャップを表す。要素分割部244は、特定の(場合によっては表示不可能な)区切り線コンポーネントを、正しい分離方向を決定することに役立てるために(例えば、プロセス内で設計者にとってのヒントとして使用するために)提供し得ることが理解されよう。そのようなコンポーネントはまた、割り当てられた「加重」を有し得るため、そのようなコンポーネントには(投影された矩形の計算に関し)1つ以上のコンポーネントの価値がある。
【0123】
両方向においてギャップが発見される場合、要素分割部244は、要素の横方向および縦方向の分割区画を、ギャップセグメントに直交する仕切りに基づき生成し得る。例えば、ここで参照する
図18に示すように、Aの場合は、1つの仕切りを使用した(列への)横方向の分割区画であり、Bの場合は、2つの仕切りを使用した(行への)縦方向の分割区画である。
【0124】
要素分割部244は、分割区画の品質レーティング(Division Quality Rating;DQR)を、仕切りの最大数、発見されたギャップの全サイズの最大値、および、類似の要素が別のサブグループ内に分割区画によって分割された場合の最小数の加重平均を使用して、分割区画の2つの方向のそれぞれについて算出し得る。かかる情報は、子孫のスーパーノード間の類似性関係を定義する、スーパーノードの形成段階において(本明細書において以下にさらに詳述する)パターンPOS位置特定部253から利用可能であり得る。ここで参照する
図19に示すように、(行への)縦方向の分割区画がサービス/プロジェクト/クライアントボックス(A,B,C)を一緒にしておくために好ましい。
【0125】
要素分割部244はまた、いずれの方向においてコンポーネントがより良好に整列されているかを考慮し得る。例えば、ここで参照する
図20に示すように、例Aでは(列への)横方向の分割区画を行う時に大きなギャップが存在するとしても、分割区画は縦方向であるべきである(すなわち、コンポーネントは行状に配置・整列される)。これは、例Bにおいてアライメント線が加えられるとき、より明らかに観察されることができる。
【0126】
要素分割部244はまた、一定の選好因子(preference factor)を、(幅を削減しない)縦方向の分割区画に対して(幅を削減する)横方向の分割区画に加え得る。この場合、要素分割部244は、より高いDQRの分割区画を返し得る。
【0127】
ギャップが1つの方向のみにおいて発見される場合、要素分割部244は、かかる方向における分割区画を返し得る。ギャップが発見されない場合、インターロック要素の場合が存在し得る。そのような場合、要素分割部244は、要素の1つと交差する仕切りを形成し得る。例えば、ここで参照する
図21に示すように、要素は、要素Bのみと交差し得る縦方向の分割線Aを使用して分割される。Rを付した全要素は、(要素Bを含み)分割区画の右側に関連付けられ得、要素Lは分割区画の左側に関連付けられ得る。
【0128】
かかる例では、要素分割部244は、(X軸およびY軸の両軸における投影セグメントからの)最小数の交差要素を有する投影セグメントを発見し得る。1つのみのそのようなセグメントが存在する場合、要素分割部244は、当該セグメントに基づき分割区画を定義し得る。同一の最小数の交差要素を有する、(両方向における)2つ以上のそのようなセグメントが存在する場合、要素分割部244は、1つの仕切りによる分割区画のセットを、最小数の交差要素を有するセグメントの1つに基づき形成し得る。
【0129】
これら分割区画のそれぞれに関し、要素分割部244は次いで、(本明細書において上述の)通常のDQR計算基準、交差要素の最小面積、および、カットの限定性(すなわち、交差要素の面積の割合が、交差する仕切りの一方側で最小であること)の加重平均に基づきDQRを算出し得るため、交差要素は、より明確に仕切りの2つの側の一方に属する。代替的に、要素分割部244は、最高のDQRの分割区画を使用し得る。
【0130】
この場合、要素分割部244は、各交差要素が、仕切りの、交差要素のより大きな面積を含む側に属す、選択された分割区画を返し得る。
【0131】
代替的実施形態では、要素分割部244は、同数の交差要素を有する複数の投影セグメントに基づき複数の仕切りを形成し得、複数のそのような交差要素を含む分割区画を評価し得る。
【0132】
要素分割部244は、あり得る各分割区画のために代替的なDQR計算を再帰的に呼び出し得、各潜在的な分割区画が試された後に、形成された分割区画のDQR値をチェックし得ることが理解されよう。さらに、これにより、要素分割部244が交差する1つの最良の要素を発見し得るため、さらなる分割区画が良好になり得る。
【0133】
基本的順序付け部247に並行して、POS位置特定部250が、何らかの関連がある複数のコンポーネントセットであって、要素がモバイル機器での表示のために再順序付けされる時に可能であれば一緒のままであるべき複数のコンポーネントセットを検出し得ることが理解されよう。例えば、上記コンポーネントは、テキストの見出し、および、対応するテキストパラグラフであり得る。
【0134】
クラスタPOS位置特定部251は、(任意のタイプの)コンポーネント同士が特定のスーパーノード内のコンポーネント間の通常の間隔に比して非常に近接している時にクラスタ部分的順序セットを検出し得る。クラスタPOS位置特定部251は、スーパーノード内のコンポーネント間の平均距離を算出し得、次いで、当該スーパーノード内の全コンポーネントペアに対してループを実行して、距離が算出された平均距離の所定の割合であるコンポーネントペアを検索し得る。次いで、クラスタPOS位置特定部251は、これらコンポーネントペアをセットに統合し得、当該セットそれぞれのうちの2つの最も離れたコンポーネント間の(平均距離の割合として特定される)所定の最大距離を強制し得る。クラスタPOS位置特定部251はまた、平均距離値をゆがめ得る所定の数の外れ値を考慮するために、平均値算出ではなく中間値、すなわちメディアン値の算出を使用し得る。代替的実施形態では、クラスタPOS位置特定部251は、当業者に知られている任意のクラスタリングアルゴリズムを使用し得る。この場合、POS位置特定部251は、抽出したクラスタをチェックし、十分な密度である場合(例えば、クラスタメンバ間の最大距離が所定の閾値未満の場合)にクラスタ部分的順序セットを形成する。
【0135】
意味関係POS位置特定部252は、近接する写真および説明文等の特定の組合せの所定のタイプのコンポーネントが存在する場合に、意味関係部分的順序セットを検出し得る。意味関係POS位置特定部252は、スーパーノード内のすべてのあり得るコンポーネントペアを走査し得、各潜在的ペアについて、コンポーネントのそれぞれが正しいタイプを有すること(例えば、一方がテキストであり他方が写真であること)、コンポーネント同士が近接していること(距離が所定の閾値未満であること)、および、それらコンポーネント間に介在コンポーネントが存在しないことをチェックし得る。意味関係POS位置特定部252は、評価されたコンポーネントペア[A,B]に関し、Bと置き換えられ得、Bとして適切なタイプであり、かつ、BからよりもAに近い第3のコンポーネントCが存在しないことをチェックし得る。AとCとの関係についても同様である。
【0136】
コンポーネントペアの他の組合せとして、テキストおよびボタンの部分的順序セットがあり得る。かかる例では、意味関係POS位置特定部252は、テキストフィールドを描くボタンを実際のテキストフィールドにリンクさせ得る。この関係は、位置のみに従って決定され得る。
【0137】
他の組合せとして、テキスト連結部分的順序セットがあり得る。この例では、意味関係POS位置特定部252は、互いに連続する複数のテキスト要素を結合し得る。意味関係POS位置特定部252は、他のテキスト要素の上の1つのテキスト要素を認識し得るのみであることが理解されよう。さらに、(2つだけではない)任意の数のそのような要素が所定のセット内に存在し得、それらすべてがリンクしていることが理解されよう。
【0138】
パターンPOS位置特定部253は、パターン部分的順序セットを、特定のタイプ、プロパティ、および、レイアウトを有する、反復パターンの所定の数のコンポーネント(例えば、コンポーネントのペアまたは三つ組)が所定の距離で存在する時に検出し得る。パターンPOS位置特定部253はまた、ここで参照する
図22に示すような切換えパターンの場合に、パターン部分的順序セットを検出し得る。コンポーネントペアAおよびCが左側にテキスト、右側に写真を有し、コンポーネントペアBおよびDが右側にテキスト、左側に写真を有する。パターンPOS位置特定部253は、そのようなパターンを、特定のタイプおよびプロパティを有するが、各コンポーネントペア内において横方向の距離が2つのオプション(絶対値が同じ負または正の数)の一方であるコンポーネントペアに基づき検出し得る。パターンPOS位置特定部253は(後に統合され得る2つのメンバのパターンの例では)、スーパーノード内の全コンポーネントを走査し得、各コンポーネントに関し、コンポーネントの四辺すべてにおける最も近い近隣コンポーネント(neighbors)の位置を特定する。パターンPOS位置特定部253は、特定の閾値限界までコンポーネントに重複する近隣コンポーネントを含み得る。この場合、パターンPOS位置特定部253は、コンポーネントと近隣コンポーネントとの関係リストを保存し得、次いで、生成した関係リストを走査し、属性に従って類似する関係ペアを選択する。かかる属性は、コンポーネント同士が同じタイプを有する(例えば、コンポーネント[pic,txt]が他のコンポーネント[pic,txt]に類似している)こと、コンポーネント同士が同じ方向(切換えパターンがサポートされる場合は逆方向を含む)を有し、かつ、(差異の所定の閾値を前提とした)同様の距離を有すること等である。
【0139】
選択された関係の2つのコンポーネントは異なるタイプを有するべきであるか、そうでなければ、四角形状に配置された同タイプの4つのコンポーネントのセットが類似関係ペアの2つの対立セットを生成し得ることが理解されよう。例えば、ここで参照する
図23に示すように、4つの写真コンポーネントは、横方向のペア(関連ペアH1,H2)または縦方向のペア(関連ペアV1,V2)に分割され得る。
【0140】
パターンPOS位置特定部253は、選択された関係のリストを走査し得、それら選択された関係をセットに組み合わせ得る(例えば、r1=r2およびr2=r3の場合に、セット[r1、r2、r3]が生成され得る)。1セットのパターン(例えば、複数のコンポーネントセット[txt,txt,pic]の1セット)が一緒に操作されるべきであることが理解されよう。
【0141】
事前定義済みPOS位置特定部254は、アプリケーション設計者によって提供され得るかまたは元のアプリケーションテンプレート内に存在し得る特定のヒントに基づいて形成される部分的順序セットを検出し得る。そのようなヒントは多くの形態をとり得る。「写真+テキスト説明文」コンポーネント等の事前定義された部分的順序システムヒントを含む特定の複合コンポーネントは、それら2つのコンポーネントを連結して事前定義された部分的順序セットを生成することを含み得る。他のヒントは、ページ内の任意のコンポーネントの明示的に特定される関連付け、または、視覚的デザインシステム内で利用可能な他の形式の関連付け(例えば、編集のためのグループ化)から導かれるモバイル関係の関連付けであり得る。多くの視覚的デザインシステムがコンポーネントを関連付けてグループ化することができるため、コンポーネントは一緒に除去、サイズ変更、または、修正されることができるからである。他の関連付けとして、動的レイアウトアンカーがあり得る。視覚的デザインシステムが(レイアウトの定義から明示的に特定されるかまたは自動的に形成される)動的レイアウトアンカーをサポートし得るからである。そのようなアンカーはさらに、部分的順序セットを形成することに使用され得る。さらに他の関連付けとしては、テンプレート(すなわち、同じマルチコンポーネントテンプレートの複数のインスタンスから形成されるコンポーネントセット)があり得る。
【0142】
事前定義済みPOS位置特定部254は、事前定義済みグループおよび事前定義済み部分的順序セットの両方を提供し得ることが理解されよう。これら事前定義済みグループおよび事前定義済み部分的順序セットは、システムの異なる要素であり、事前定義済みPOS位置特定部254によって、設計者は、コンポーネントをグループ化し仮想スーパーノードを形成するために使用される事前定義済みグループヒント、および、順序付けプロセスをガイドするために使用される事前定義済み部分的順序セット/順序付けヒントを特定することができる。
【0143】
ESIベースPOS位置特定部255は、(利用可能な場合)ESIに基づく部分的順序セットの自動的形成を検出し得る。特に、ESIベースPOS位置特定部255は、コンポーネントを、複製またはコピーアンドペーストを使用して形成されたコンポーネントセット、(例えば、視覚的デザインシステムがデータベース内に保存されていないアドホックなグループ化をサポートするのみである時に)一緒にグループ化および編集されたコンポーネントセット、および、逐次的に編集されたコンポーネントセット等の以前の編集セッションから収集された情報に基づき、(1つの部分的順序セットとして)関連付け得る。
【0144】
順序付け部240が基本的順序を形成し、かつ、POS位置特定部250が任意の部分的順序セットを決定した後は、順序統合部245が当該基本的順序および検出された部分的順序セットを統合し得、全関連要素の全順序である結合された修正順序を形成し得ることにより、対立する部分的順序セットを途中で解消し得る。
【0145】
基本的順序付け部247のいくつかの要素は、全コンポーネント間の完全な順序を形成するためのものではなく、ページ/スーパーノードを、許容された幅に適合するページ部分に分割するものであり得ることが理解されよう。これが関連し得るのは、基本的構造を維持する必要がある時(例えば、アプリケーションを、デスクトップディスプレイと同じかまたはデスクトップディスプレイよりも大きい幅の機器(例えば、タブレット、大型ディスプレイ)に合わせて変換する時)である。この場合、線上に配置されるコンポーネントへと解体することは、基本的なコンポーネントの配置を破壊し得るため、最小限の「スライス」が視覚的に優れ得る。この目的のために、基本的順序付け部247の要素は、個別のコンポーネントに対して作用するよりも、(使用可能な幅に依然として適合する)ページ部分に対して作用するように修正され得る。
【0146】
この場合、基本的順序付け部247は、かかる情報をガイドラインとして使用し得るため、実質的なPOS接続を介して接続されているページ部分はスライスされない。
【0147】
スーパーノード形成部230、基本的順序付け部247、および、POS位置特定部250はさらに、互いに対立する結果を形成し得ることが理解されよう。例えば、POS位置特定部250のサブ要素の1つがいくつかの要素に関する特定の部分的順序セットの定義を生成し得、かつ、他の要素が異なる対立する部分的順序セットの定義を生成し得る。順序統合部245は、単一の出力を形成するために様々な要素からの結果を結合し得、対立を解消し得る。
【0148】
さらに、そのような対立を解消するために、スーパーノード230、基本的順序付け部247、および、POS位置特定部250はすべて、品質スコアを使用し得る。例えば、設計者の明示的要求に基づく設計は通常、最大の品質スコアを有する。設計者が自身の設計の構成を完全に認識していると想定することができるためである。スーパーノード230、基本的順序付け部247、および、POS位置特定部250はすべて、それらのスコアを、スコアラ500が保持する品質スコアに比してチェックし得る。このスコアラ500は、生成された各結果に、いかに要素が、分析されたパラメータに基づく特定の結果の正しさについて確実であるかの確実性スコアを提供し得る。
【0149】
順序統合部245は、基本的順序付け部247およびPOS位置特定部250から結果を収集し得、それら結果を統合し得る。互いに対立しない結果は、簡単に組み合され得ることが理解されよう。互いに対立する結果は、順序統合部245にいずれの結果を使用するか選択するように要求し得る。この選択は、具体的結果の組み合された品質スコアおよび確実性スコアの算出結果に応じてなされ得る。結果が所定の(選択的な)確実性の閾値に合致しない場合、それら結果は破棄され得る。
【0150】
順序統合部245はまた、(例えば、テンプレートが通常のページよりもより良好に設計されているため)現在のページ内で定義されたコンポーネントのみを含む結果よりも高い確実性を有し得るテンプレート内に存在するコンポーネントに関して定義された結果等のさらなる情報を考慮し得る。また、順序統合部245は、以前に操作されたことにより、より高い確実性が割り当てられている以前の各ページまたはスーパーノード内で発見された結果に類し得る結果を考慮し得る。
【0151】
順序統合部245は、所定の設計者によって形成されたページ構造を、可能であれば要素の結果をレーティングする当該設計者からのフィードバックを使用して学習するように、拡張され得る。
【0152】
具体的要素は、共に実装されるべきであるかまたは全く実装されるべきではない結果セットを返し得る。例えば、パターンPOS位置特定部253は、コンポーネントの反復パターンを発見し得る。そのようなパターンは、関連する全コンポーネントのために使用されるべきであるかまたは全く使用されないようにすべきである。
【0153】
コンポーネントが適切に順序付けられた後は、位置付け部270がコンポーネント、および、(本明細書において以下により詳細に説明する)任意の自動追加コンポーネントをページ内のそれらコンポーネントの適切な位置に位置付け得る。位置付け部270は、順序付けられた要素を必要に応じてコンポーネント線上に、決定された全順序および許容されたスペースに応じた使用可能な幅に適合するように位置付け得る。使用可能な幅は、ページスーパーノードの幅から事前定義した余白および予約されたスペース等の他の制約を差し引いた幅によって定義され得ることが理解されよう。例えば、主ページ幅が320ピクセルであり、左右の余白がそれぞれ10ピクセルであり、かつ、予約されたスペースが存在しない場合、主ページスーパーノードの使用可能な幅は、320-(2×10)=300ピクセルであり得る。主ページスーパーノード内に含まれ、かつ、最大の使用可能な幅をとるページスーパーノードの使用可能な幅は、300-(2×10)=280ピクセル等であり得る。
【0154】
位置付け部270は、デスクトップレイアウト構成の一部として付属するレイアウトヒントを、「モバイルレイアウト構成内に保持する」のマークが付されている場合に適用し得る。そのようなコンポーネントは、それらコンポーネントがコンテナ基本構造の一部となり、コンポーネント線自体の一部であるよりもコンポーネント線の構築を行わせ得る点で、自動追加コンポーネントにより類似して機能し得る。
【0155】
次いで、位置付け部270は、スーパーノード形成部230および順序付け部240によって形成された明示的ヒント(例えば、「このグループ/POSを区切り線上に置く」)に従って、改行を形成し得る。追加されるコンポーネントが(予約されたスペースを考慮して)使用可能な幅を超える場合、位置付け部270は、コンポーネントグループを一緒のままに維持し得るため、すなわち必要に応じてグループ前の改行を形成し得るため、グループ全体は同じコンポーネント線上に適合され得る。位置付け部270は、(POS位置特定部250等によって早い段階で検出した)意味関係を有するコンポーネント間で改行されるような改行を追加することを回避し得る。
【0156】
位置付け部270はまた、各要素に要素タイプに応じて幅削減手段を適用し得る。幅削減手段には、コンポーネントタイプに応じて適合され得るコンポーネント(例えば、テキストコンポーネント)を修正することが含まれ得る。かかる修正には、再拡大・再縮小、フォントサイズの変更、テキストの再流し込み等が含まれる。また、幅の削減には、各仮想スーパーノードのタイプに応じて規定された仮想スーパーノードごとの操作方法が使用され得る。これら幅削減手段にはまた、コンポーネント調節部227によって(プリプロセス段階として)行われる変形と類似した変形が含まれ得る。かかる変形はここでは、モバイルレイアウト構成におけるコンポーネントの最終位置およびサイズについての追加情報を用いて行われ得る。位置付け部270はまた、例えば、コンポーネント線内に孤立して位置付けられたコンポーネントを拡大するために、幅を拡大し得る。
【0157】
位置付け部270は、特定の要素タイプのための特定のサイズ変更手段を提供する。例えば、位置付け部270は、(画像上テキストグループ位置特定部234によって位置が特定された)画像上テキストグループを表すスーパーノードを、背景画像を仮想コンテナとして使用することによってサイズ変更し得る。次いで、所望の高さおよび幅にするためにテキストをサイズ変更する。このサイズ変更には、ここで参照する
図6に示すように、(例えば、より大きなキャラクタを内側に有する、より細長いテキストコンポーネントの形成等のように)テキストコンポーネントのアスペクト比を変更し得るフォントサイズマッピングおよびテキストの再流し込みが含まれ得る。
図6に示すように、例1から例2への移動時に、フォントサイズが増大される一方、フィールド幅は削減され、テキストの再流し込みが必要とされる。また、画像上テキストグループ位置特定部234は、背景画像が次のテキストサイズにサイズ変更されて、通常はアスペクト比が変更される時に、グループをサイズ変更し得る。
【0158】
写真が、ここで参照する
図7に示すように、アスペクト比が変更される時に良好な見た目にならない可能性のある実際のコンテンツ(例えば、人物の写真)を有する場合に、「視覚的事故」("visual accident")が引き起こされ得ることが理解されよう。画像上テキストグループ位置特定部234は、この問題を、画像コンテンツが詳細情報を含むかチェックすることによって、または、サイズ変更の代わりにズームおよび切取りによって画像の内部アスペクト比を保存することによって解消し得る。
【0159】
いくつかのコンポーネントは、自身のサイズ変更を行う際の自律度を有する。一例を挙げると、(様々な表示サイズの複数の変形形態をサポートし得る)第三者アプリケーションコンポーネントおよび(複数のビュー関連付けを有し得る)リストアプリケーションがある。そのようなコンポーネントは、位置付け部270によって提供される目的のサイズに基づき自身のサイズ変更を行う。
【0160】
位置付け部270はまた、必要に応じて装飾画像をサイズ変更/反復し得、新規ページサイズに適合させ得る。ページが所定の長さのパラメータを超える場合、位置付け部270は、場合によってはページ内ナビゲーションメニューを形成し得、このメニューを分離メニューとしてページまたは既存の統一メニューに適切に追加し得る。
【0161】
位置付け部270は、コンポーネントのアスペクト比を保ちながら、高さおよび幅の両方を再拡大・再縮小し得る。いくつかのコンポーネントは、それらコンポーネントの高さを保持し得、幅を変更し得るのみである(例えば、より少ない列を使用するために修正されるギャラリー)。再拡大・再縮小時に特定の高さを使用しなければならないコンポーネント(例えば、内部スクロールを有するマップコンポーネントであって、内部スクロールを有するためマップスクロールではなくページスクロールのために当該コンポーネントの上下の余白を残しておかなければならないコンポーネント)は、適切に操作され得る。幅の削減が同様に操作され得ることが理解されよう。
【0162】
位置付け部270はまた、コンポーネントに幅削減/拡大プロセスを適用し得るのみならず、再帰的にスーパーノードおよびスーパーノードの子孫に対しても幅削減/拡大プロセスを適用し得る。かかるプロセスには、実際のコンポーネントサイズ変更;テキストのフォントサイズマッピング;テキストの際流し込み;視認可能な部分と、(要求されたときにのみ表示される)「もっと見る」("show more")の拡張部分等とに分離させることによるテキスト削減が含まれ得る。他のプロセスとしては、コンポーネントの「より軽い」モバイルバージョンへの切換え、幅を変更するためのコンポーネントパラメータの修正が含まれ得る。プロセスにはまた、実際に使用されるサイズを反映するためのコンポーネントのサイズ変更が含まれ得る。
【0163】
位置付け部270が関連コンポーネントを、モバイル構成レイアウト内のそれらコンポーネントの正しい位置に位置付けた後は、ポストプロセッサ202が任意の最終的なレイアウト調節を操作し得る。
【0164】
自動追加コンポーネント挿入部281は、自動追加コンポーネントを、変換されるアプリケーションのすべてもしくはいくつかに(ページのすべてもしくはいくつかに)追加され得るシステムメニューまたは他のモバイル関連ウィジェット等の新規モバイルレイアウト構成内に挿入し得る。そのような挿入される自動追加コンポーネントにはまた、例えば、広告および/または他の販売促進用素材が含まれ得る。そのような挿入される自動追加コンポーネントは、必須でもあり得(すなわち常に挿入される)、任意でもあり得る。任意で挿入される場合、自動追加コンポーネントは、ユーザのタイプもしくはプロフィール(例えば、ヨーロッパ内の全ユーザについて特定の自動追加コンポーネントが挿入される)、または、モバイル機器ごとのタイプもしくはプロフィール(例えば、画面サイズが480×320以上の全アンドロイド(登録商標)ユーザについて特定の自動追加コンポーネントが挿入される)等のパラメータまたはパラメータの組合せに基づき条件的に挿入され得る。また、自動追加コンポーネントは、特定のページのパラメータもしくは条件(例えば、サイズが320×200以上の写真コンポーネントを含まないページについて特定の自動追加コンポーネントが挿入される)、ユーザ行動もしくはアプリケーション使用履歴、自動追加コンポーネントが挿入されるためのスペースの使用可能性、任意の設計者が定義するパラメータ、および、任意のウェブサイト構築システムが定義するパラメータにも基づき得る。
【0165】
自動追加コンポーネント挿入部281は、そのような自動追加コンポーネントインを多くの方法で位置付け得ることが理解されよう。自動追加コンポーネント挿入部281は、自動追加コンポーネントを、ページ内または特定のコンテナ(すなわちスーパーノード)内の所定の位置に通常は本明細書において以下に説明する予約スペースを使用して挿入される絶対位置自動追加コンポーネントとして位置付け得る。自動追加コンポーネント挿入部281はまた、自動追加コンポーネントを、いくつかのページ要素(例えば、事前定義済みコンポーネント、クエリによって位置が特定されるコンポーネント等)に対して所定の位置に挿入される相対位置自動追加コンポーネントとして挿入し得る。これは、本明細書において以下にさらに詳細に説明するコンポーネントのモバイルレイアウト構成レベルでの挿入と同様である。
【0166】
自動追加コンポーネント挿入部281はまた、自動追加コンポーネントを、レイアウト内のスペースの使用可能性に基づき挿入される残部スペース自動追加コンポーネントとして追加し得る。コンポーネントが分離コンポーネント線に対して移動されることもあるため、いくつかの場合、モバイルレイアウト構成内ではデスクトップレイアウト構成に比して、そのような自動追加コンポーネントのために使用され得る追加的な空のスペースが存在する。
【0167】
絶対位置自動追加コンポーネントの場合、自動追加コンポーネント挿入部281は、モバイル表示領域上に特定のスペースをこれら要素のために予約することが必要とされ得る(ページ/スーパーコンテナに割り当てられた矩形のモバイル表示領域から上記領域を刻設して(carving out)この領域を予約する)。したがって、コンポーネント線のために使用される領域は、非矩形であり得る。ここで
図24を参照する。
図24は、自動追加コンポーネントAおよびBのために予約された領域を刻設した後、主コンテナC内に残る領域が非矩形状であることを示す。
【0168】
関連する視覚的デザインシステムはまた、2013年8月22日付で公開された、本発明の譲受人と共通の譲受人に譲渡される「動的レイアウトおよび動的コンテンツを統合するサーバベースのウェブサイトデザインシステム」("A SERVER BASED WEB SITE DESIGN SYSTEM INTEGRATING DYNAMIC LAYOUT AND DYNAMIC CONTENT")と題された特許文献3において説明される明示的(設計者が特定する)アンカーのみならず暗黙の(自動的に形成される)アンカーを使用することを含む動的レイアウトをサポートし得ることが理解されよう。したがって、視覚的デザインシステムは、モバイル機器の幅への適合に内在する再配置プロセスによって崩され(broken)得るアンカー(明示的アンカーおよび暗黙のアンカー)を有し得る。
【0169】
コンポーネントが適切に位置付けられた後は、動的レイアウト操作部284が、新規レイアウトに応じて任意の既存の動的レイアウトアンカーを修正し得る。例えば、動的レイアウト操作部284は、ここで参照する
図3に示されるようにアンカーを無意味にするように移動されたコンポーネントのアンカーを除去し得る。
図3に示すように、例1においてコンポーネントAとBとの間に存在する横方向アンカーは、例2においてコンポーネントBがAの下に移動される時に崩されるべきである。
【0170】
動的レイアウト操作部284はまた、(例えば、修正されなかったコンテナ内の修正されなかったコンポーネントセット等の)保持され得るアンカーを保持し得る。動的レイアウト操作部284はまた、保持され得るが、パラメータの修正(例えば、より近接するように移動されたコンポーネント同士のためのアンカーの長さの変更)が必要であり得るアンカーを修正し得る。動的レイアウト操作部284はまた、近接して位置付けられたコンポーネント間の(コンポーネント-コンポーネント間アンカーおよびコンポーネント-コンテナ間アンカーの両方を含む)新規動的レイアウトアンカーを形成し得る。これは、システム内に構築された自動アンカー形成基準に基づき得る(例えば、コンポーネント間の重複量および距離に基づき得る)。
【0171】
モバイルに適合されたアプリケーションが依然として絶対座標の視覚的デザインアプリケーションであり得るため、新規に形成されたアンカーが重要であることが理解されよう。したがって、モバイル向けに適合されたアプリケーションは、含まれているテキストの量等のコンポーネントのコンテンツに対する修正等の変更によって動的に修正されなければならないであろう。これら修正には、外部ソース(外部からのデータフィード、同時発生のユーザ活動、リストアプリケーション内のデータ記録間の切換え等)に由来する変更が含まれ得る。動的レイアウト操作部284は、目的のモバイル機器の画面サイズ内の小さな修正に応じてさらに適合させる変更を実行しなければならないであろう。したがって、動的レイアウト操作部284は、アンカー構造を修正し得、新規アンカー構造を最終的な適合のために実装し得る。
【0172】
形成される(グループ化、POS、および、順序付け情報を含む)代替のレイアウトがアプリケーションと共に、もしくは、さらなる用途のためにアプリケーションとは別に、または、本明細書において以下に説明するさらなる修正の基礎としてデータベース50内に格納され得ることが理解されよう。
【0173】
表示部290は、新規に修正されたレイアウトを目的のプラットフォーム上に表示し得る。
【0174】
本明細書において上述したように、レイアウト再変換コンバータ300は、所定のデスクトップレイアウト構成上で行われた修正、および、当該デスクトップレイアウト構成に対応するシャドウモバイルレイアウト構成に対する修正を結合し得、更新されたモバイルレイアウト構成を形成し得る。
【0175】
初期レイアウトコンバータ200の動作後、2つ(以上)のバージョンのアプリケーション(すなわち、デスクトップ(主)レイアウト構成および1つ(以上)の(シャドウ)モバイルレイアウト構成)が存在する。モバイル(またはシャドウ)レイアウト構成について言及する際には、タブレット、幅広の画面の表示等に関連する構成等の、他の追加的な構成に言及している。この場合、設計者は、(個別の)修正を、関連する視覚的デザインシステムの編集ツールによってデスクトップレイアウト構成およびモバイルレイアウト構成の両方に修正を適用し得、それぞれの構成の修正バージョンを形成し得る。視覚的デザインシステムは、両方のバージョンに単一のエディタ(モバイルレイアウトの編集時には制約が付き得る)、または、個別のデスクトップエディタおよびモバイルサイトエディタを提供し得る。
【0176】
モバイルレイアウト構成がデスクトップレイアウト構成から得られるため、初期レイアウトコンバータ200は、デスクトップレイアウト構成に対してなされた修正(例えば、ページおよびコンポーネントの追加および削除、ならびに、コンポーネントコンテンツの変更)をモバイルレイアウト構成に適用し得る。再変換コンバータ300は、モバイルユーザに表示される最終的なモバイルレイアウト構成を形成するために、任意のデスクトップレイアウト構成の修正と任意の個別のモバイルレイアウト構成の修正とを、モバイルレイアウト構成のコンテンツをデスクトップレイアウト構成に良好に調整しながら結合させ得る。この手続きは、複雑であることが理解されよう。例えば、修正されたモバイルレイアウト構成にも追加されるべきコンポーネントをデスクトップレイアウト構成に追加する場合(上記修正されたモバイルレイアウト構成のコンポーネントは、移動されるか(コンテナからの、コンテナ内への、もしくはコンテナ間での移動を含む)、サイズ変更されるか、または削除されていてもよい)、再変換コンバータ300は、追加されたコンポーネントを修正レイアウト構成内に位置付けるための適切な位置のみならず追加されたコンポーネント自体のために使用されるレイアウトを決定しなければならないからである。
【0177】
かかる例では、任意のモバイルレイアウト構成の修正は、デスクトップレイアウト構成内には結合されないことが理解されよう。デスクトップサイトを編集することがモバイルサイトを変更し得る一方、モバイルサイトの編集は、デスクトップサイトに影響しない。デスクトップレイアウト構成またはモバイルレイアウト構成のいずれか一方になされた純粋なレイアウトの変更(すなわち位置およびサイズの変更)は、例えば、(デスクトップレイアウト構成において行われた場合、モバイルレイアウト構成に影響する)コンポーネントコンテンツの変更または削除とは異なり、他方のレイアウト構成に影響しないことが理解されよう。さらに、システム100がモバイルの編集を制限し得るため、コンポーネントはモバイルレイアウト構成から削除され得る(または隠され得る)が、追加されることはできず、また、コンポーネントのコンテンツは編集されることができない(場合によっては、本明細書において以下にさらに詳細に説明するモバイル指向コンポーネントは例外とされる)ことが理解されよう。したがって、例えば、モバイルエディタによって、モバイルレイアウト構成内のコンポーネントは1つのページから他のページに移動されることができない。かかる移動は、コンポーネントのページへの追加を伴うからである。
【0178】
ここで
図25を参照する。
図25は、再変換コンバータ300の要素を示す。再変換コンバータ300は、ページ削除部310、ページ追加部320、コンポーネント削除部330、コンポーネント追加部340、コンポーネント修正部350、および、モバイル操作部360を含み得る。コンポーネント追加部340はさらに、ここで参照する
図26に示すように、追加コンポーネント特定部342、親/祖先検索部344、および、モバイルレイアウト追加部346を含み得る。これら要素の機能を、本明細書において以下にさらに詳細に説明する。
【0179】
ここで
図27を参照する。
図27は、再変換コンバータ300の機能を示す。初期レイアウトコンバータ200は、DP1(デスクトップページ1)を変換し得、その結果、モバイルレイアウト構成MP2を形成し得る。この場合、設計者は、ローカルモバイルエディタ560を使用してMP1を編集し得ることにより、MP2を形成し得る。次いで、設計者は、ローカルデスクトップエディタ550を使用してDP1を編集し得ることにより、DP2を形成し得る。次いで、再変換コンバータ300は、DP2およびMP2内になされた変更を統合する更新されたモバイルレイアウト構成を形成し得る。
【0180】
かかる自動的統合が関連するのは、デスクトップ編集段階(DP1⇒DP2)がモバイル編集段階(MP1⇒MP2)後に行われる場合のみであり得ることが理解されよう(
図26参照)。逆の場合(デスクトップ編集が最初に行われる場合)、初期レイアウトコンバータ200は、修正されたデスクトップレイアウト構成DP2を、DP2の編集の完了時に、モバイルレイアウト構成MP2に自動的に再変換し得る。したがって、設計者は、既に修正されたMP1上でMP1⇒MP2の変更を行い得、当該(後の)モバイル修正中に上記変更を手動で統合する必要がある。
【0181】
さらに、同じサイトを複数のプラットフォーム上で動作させるために、両方のサイト内で同じコンテンツをできるだけ多く有することが理解されよう。しかしながら、本明細書において上述したように、例えば、ドロップダウンメニューおよび縦方向の線等の使用によって、デスクトップコンポーネントのすべてがモバイルとの両立性があるわけではない。
【0182】
また、ウェブベースのインタラクティブなアプリケーション(例えば、ウェブサイト)の主要な要件は、サーチエンジンでの両立性(search-engine compatibility)であることが理解されよう。したがって、デスクトップレイアウト構成およびモバイルレイアウト構成の両方がサーチエンジンに同じ全般ページ構造(general page structure)を提示すべきであり、同じページが両レイアウト構成内で利用可能であるべきである。そうでなければ、ページは、デスクトップレイアウト構成のページを読むサーチエンジンスパイダーによってインデックスされ得るが、ユーザがモバイル機器上のサーチエンジンを介して当該ページに直接的に達する時は、当該ページは利用不可能であり得る(「ウェブページが見つかりません」または類似のエラー状態を生成する)。逆の場合、モバイルレイアウト構成では利用可能であるが(インデックスされた)デスクトップレイアウト構成では利用不可能なページは、サーチエンジンによって発見されないであろう。いくつかのサーチエンジンは、サイトの異なるバージョンに対応する様々なページ構造をサポートし得るが、そのようなオプションの使用および利用可能性は、特定のサーチエンジンの内部プロパティであり、そのようなオプションを当てにすることはできない。
【0183】
デスクトップサイトおよびモバイルサイトの見た目は異なり得るが、これらサイトは、可能である時はいつでも同じデータを共有し得ることが理解されよう。そうでなければ、ユーザは、例えば、デスクトップページのコンテンツ内に存在する所定のテキストフレーズを検索することによってモバイルページに達し得ても、モバイルページが異なっていること、および、検索したフレーズが含まれないことが分かるのみである。特に、モバイルページは、デスクトップページ上に存在しないコンポーネントを含むべきではない。新規のモバイルに適合されたメニューを追加して既存のメニューと置き換えること、または、モバイルレイアウト構成のみにおいてテキストコンポーネントを削除すること等のいくつかの例外が適用され得る。
【0184】
また、設計者は、場合によっては、モバイルレイアウト構成に特定の修正を行う必要があり、当該モバイルレイアウト構成を故意にサーチエンジンポリシーに反してデスクトップレイアウト構成とは異なるようにすることがあり得ることが理解されよう。一例を挙げると、新規記事の概要のフィードを表示するシステムは、デスクトップレイアウト構成上でより長い概要を表示し得、モバイルレイアウト構成上でより短い概要を表示し得る。設計者がコンポーネントのサイズ、位置、および、順序付けを修正し得ることは確実であり、そのような変更は概して、サーチエンジンによる当該モバイルサイトの操作に影響すべきではない。
【0185】
かかる対立を解消、または少なくとも改善するために、再変換コンバータ300は、設計者がモバイルレイアウト構成上に行い得る修正範囲を制限し得る。例えば、設計者による修正は、モバイルレイアウト構成にのみ影響し得るが、実際のコンテンツには影響しない修正に限定され得る。そのような限定は、様々な修正が再変換機300によって操作される前に、システムのモバイルエディタ560によって強制され得る。
【0186】
デスクトップレイアウトの修正には、ページの追加、ページの除去、コンポーネントの追加、コンポーネントの除去、コンポーネントの属性の変更、コンポーネントの移動およびサイズ変更、ならびに、コンポーネントのコンテンツの変更(例えば、テキストパラグラフ内のテキスト)が含まれ得る。上記のように、純粋なレイアウトの変更(例えば移動およびサイズ変更)は、モバイルレイアウト構成に影響しない。
【0187】
本明細書において上述したように、視覚的デザインシステムは、コンポーネントが修正または移動される時に変化しない各コンポーネントの内部固有ID(internal unique ID)を有し得る。再変換コンバータ300は、これらIDを使用し得、ページの或るバージョンから他のバージョンに修正されたコンポーネントを追跡し得る。再変換コンバータ300が、全修正が視覚的デザインシステムエディタを介して行われ、かつ、完全に追跡されることを想定しているため、修正バージョンを評価する際、再変換コンバータ300は、(修正された各コンポーネントについて)修正された属性および値の変化(例えば、コンポーネントXについて、スタイルがS1からS2に変更され、幅がW1からW2に変更された)の詳細リストを有し得る。
【0188】
既存のデスクトップページを除去する時、ページ削除部310がまた、モバイルレイアウト構成からページを除去し得る。これは、当該ページになされた特定のモバイルレイアウト構成の修正が失われることを意味することを理解されたい。それら修正を復旧する唯一の方法は、「元に戻す」("undo")機能(例えば、現在のセッション中のセッションレベルで元に戻すこと、または、データベースレベルでバージョンを戻すこと)によってである。
【0189】
新規ページがデスクトップに追加される時、ページ追加部320は、本明細書において上述したように、初期レイアウトコンバータ200にページ全体をモバイルレイアウト構成に変換するように指示し得る。変換されたページがモバイルレイアウト構成において適切な位置に現れ得ることが理解されよう。ページ追加部320は、新規に挿入されたページを含めるために任意のモバイルナビゲーションメニューを更新し得る。
【0190】
コンポーネントを既存のデスクトップレイアウト構成から削除する時、コンポーネント削除部330は、対応するコンポーネントを対応するモバイルレイアウト構成から削除し得る。コンポーネント削除部330はまた、モバイル操作部360にモバイルレイアウト表示を更新するように指示し得、以下のモバイル操作部360に関する記載において説明するように、所定のコンポーネント線内のギャップを閉じ得るかまたはコンポーネント線全体を削除し得る。
【0191】
1つ以上の新規コンポーネントをデスクトップページに追加する時、当該新規コンポーネントは、新規追加コンポーネントを含む修正デスクトップページに対応する新規の階層型のコンポーネント順序を形成し得ることが理解されよう。デスクトップレイアウト構成への変更に関し、モバイルレイアウト構成への変更が行われなかった時にのみ、デスクトップレイアウト構成とモバイルレイアウト構成の修正とを結合させる必要がないため、再変換コンバータ300は、初期レイアウトコンバータ200にデスクトップページを再変換するように指示し得る。
【0192】
コンポーネント追加部320は、追加されたコンポーネントをレイアウト構成に追加するために、モバイルレイアウト構成内の適切な位置を特定しなければならないことが理解されよう。この作業は、コンポーネントがモバイルレイアウト構成内で再移動(コンテナ間の移動を含む)、再サイズ変更、再配置、または、除去されている可能性があるため、特に複雑であり得る。さらに、デスクトップレイアウト構成のコンポーネントが移動または除去されていることもある。したがって、コンポーネント追加部320は、コンポーネントを追加するための適切な位置を、プリプロセッサおよび/または親(これらの一方は必ず存在する)に従って見つけなければならない。
【0193】
モバイルレイアウト構成に追加された各コンポーネントXに関し、追加コンポーネント特定部342が(例えば、コンポーネントID比較、編集セッション履歴、または、基礎データベースへのアクセスによって)当該追加コンポーネントを特定し得る。コンポーネント特定部342は、コンポーネントフィルタ部221に、上記コンポーネントがモバイル表示に適しているか(例えば、空のコンポーネントではないこと、モバイル非対応タイプではないこと等)を判断するためにコンポーネントフィルタリングを行うように指示し得る。
【0194】
次いで、親/祖先検索部344は、追加されたコンポーネントXに最も近く、モバイルレイアウト構成内にも存在する最も近い祖先コンポーネントPD(X)および/または親コンポーネントPT(X)(すなわち、これらコンポーネントはモバイルレイアウト構成から明示的にまたはこれらコンポーネントのタイプが理由で削除されていない祖先コンポーネントPD(X)および/または親コンポーネントPT(X))の位置を特定するために、親/祖先検索を行い得る。祖先は、順序付け部240によって特定された順序に従って決定され、すなわち、モバイルレイアウト構成内に現れる最も近い祖先が選択される。親は、ページコンテナ階層に従って決定され、すなわち、モバイルレイアウト構成内に現れる最も近いレベルの親コンテナが選択される。いくつかのコンポーネントは、モバイルレイアウト構成において手動で削除され得(または隠され得)、それにより親/祖先検索から除外され得ることが理解されよう。また、例えば、(モバイル内で視認できないコンポーネントは除いて)Xがページ/コンテナ内の最初コンポーネントであり、祖先を有しない場合、最も近い祖先コンポーネントは存在しないことが理解されよう。さらに、検索が、トップレベルコンテナとして使用されるページに必ず達するため、親コンポーネントが存在しないことはできないことが理解されよう。親/祖先検索部344が祖先および親を(利用可能な場合に)決定した後は、モバイルレイアウト追加部346が、追加コンポーネントXを最も近い祖先コンポーネントの後に、追加コンポーネントXがデスクトップレイアウト構成内で祖先/親コンポーネントに対して有していた関係と同じ、モバイルレイアウト構成内での祖先/親コンポーネントに対する関係を有する位置に位置付け得、祖先の後のコンポーネントをすべて押し下げ得る。
【0195】
複数の追加されたデスクトップレイアウト構成コンポーネント(X[1],X[2],…)を操作する時に、上記手続を実行する2つの主な方法、すなわち、ワンバイワン方法(one-by-one method)またはクラスタ化方法(clustered method)があることが理解されよう。
【0196】
ワンバイワン方法では、追加されたデスクトップレイアウト構成コンポーネントX[i]は、それらコンポーネントの(例えば順序付け部240によって定義される)順序に従って操作される。各コンポーネントX[i]に関し、親/祖先検索部344は、先行する追加コンポーネントX[j](1≦j<i)を考慮する祖先/親検索を行う。このように、各コンポーネントX[i]は、他の追加コンポーネントを考慮して操作される。
【0197】
クラスタ化方法では、親/祖先検索部344は、他の追加されたデスクトップレイアウト構成コンポーネントX[j](j≠i)を無視して、追加された各デスクトップレイアウト構成コンポーネントX[i]について個別に親/祖先検索を行い得る。したがって、親/祖先検索部344は、X[i]がデスクトップレイアウト構成に追加された唯一のコンポーネントであるかのように各X[i]について親/祖先検索を行う。かかる検索が終了した後は、祖先コンポーネントPD(X[i])および親コンポーネントPT(X[i])の共通の組合せに従ってコンポーネントX[i]をクラスタリングする。各クラスタ内のコンポーネントは、1つの仮想ページ(例えば、他のスーパーノードを内側に含み得る仮想スーパーノード)として共にグループ化され得る。この場合、コンポーネント追加部340は、初期レイアウトコンバータ200に、そのような各仮想ページ上で個々に動作するように指示し得、完全な変換プロセス(本明細書において上述したプリプロセス、分析、アンカー等を含むプロセス)を再帰的に行い得る。このプロセスによって、各仮想ページは、変換済み仮想ページに変換され得る。この変換済み仮想ページは次いで、モバイルレイアウト追加部346によって、クラスタに共通の祖先および親に基づきモバイルレイアウト構成内にユニットとして位置付けられる。
【0198】
ここで
図28A~
図28Gを参照する。
図28A~
図28Gは、様々なコンポーネントの追加例および編集例、ならびに、それらコンポーネントがどのようにコンポーネント追加部340によって操作されるかを示す。
【0199】
ここで
図28Aを参照する。
図28Aは、2つのコンポーネントAおよびBを含むデスクトップページDP1を示す。初期レイアウトコンバータ200は、かかるページをモバイルページMP1に変換し得る。新規コンポーネントXがDP1においてAとBとの間に追加されてページDP2が形成される場合、親/祖先検索部344は、Xについて親/祖先検索を行い、Xを含むページ(デスクトップレイアウト構成)内でAに後続することを発見する。このように、モバイルレイアウト追加部は、MP1内のXを含むページ内でXをAの後に挿入しMP2を形成する。
【0200】
他の例では、ここで参照する
図28Bに示すように、モバイルページMP1は、モバイルエディタ560を介して編集され、AとBとの縦方向の位置が入れ替えられ、MP2が形成されている。かかる編集後、設計者は次いで、DP1において新規コンポーネントXをAとBとの間に挿入し、ページDP2を形成する。コンポーネント追加部340は、DP2およびMP2になされた変化を調停(reconcile)させ得る。親/祖先検索部344は、コンポーネントXについて親/祖先検索を行い得、Xを含むページ(デスクトップレイアウト構成内の最も近い親)内でA(最も近い祖先)に後続することを発見し得る。このように、モバイルレイアウト追加部346は、XをコンポーネントA(ここではBの上ではなくBの下にある)に続けて、Xを含むページ内でMP2内に挿入し得、更新されたモバイルページMP3を形成し得る。
【0201】
さらに他の例では、ここで参照する
図28Cに示すように、モバイルページMP1をモバイルエディタ560を介して編集し、コンポーネントAの下かつコンポーネントCの上にあるコンポーネントBを除去する(隠す)(MP2を形成する)。次いで、DP1をデスクトップエディタ550を介して編集し、Bの後かつCの前にコンポーネントXを挿入する(DP2を形成する)。次いで、コンポーネント追加部340は、DP2およびMP2への変更を調停させ得る。親/祖先検索部344は、追加されたコンポーネントXの親/祖先検索を行い得、Bが「モバイルにおいて除去されている」のマークが付されていることから、Xの祖先がBではなくAであることを決定し得る。これにより、モバイルレイアウト追加部は、MP2においてXをAの後(かつCの前)に挿入しMP3を形成する。
【0202】
さらに他の例では、ここで参照する
図28Dに示すように、ページDP1は、内部コンテナBおよび他のコンポーネントDを含むコンテナAを含み、それらすべてがMP1に変換される。次いで、モバイルページMP1をモバイルエディタ560を介して編集し、内部コンテナBを除去する(隠す)(MP2を形成する)。次いで、DP1をデスクトップを介して編集し、内部コンテナBの内側にコンポーネントCを挿入する(DP2を形成する)。次いで、コンポーネント追加部340は、DP2およびMP2への変更を調停させ得る。かかる例では、追加されたコンポーネントCの親/祖先検索を行う時に、親/祖先検索部344は、Bが「モバイルにおいて除去されている」のマークが付されていることから、親がBではなくAであることを決定し得る。親/祖先検索部344はさらに、CがA内の最初のコンポーネントであることから(Bについては考慮しない)、Cが祖先を有しないことを決定し得る。このように、モバイルレイアウト追加部346は、MP2においてA内に(最上位かつDの前に)Cを挿入し得、MP3を形成し得る。
【0203】
さらなる他の例では、ここで参照する
図28Eに示すように、モバイルページMP1をモバイルエディタ560を介して編集し、AおよびBの縦方向の位置を入れ替え、MP2を形成する。次いで、設計者は、2つの新規の大きく重複するコンポーネントX1およびX2を、DP1においてAとBとの間に挿入し、ページDP2を形成する。コンポーネント追加部340は、2つの可能な方法の一方の方法でDP2およびMP2への変更を調停させ得、(ワンバイワン方法に対応する)MP3または(クラスタ化方法に対応する)MP4を生成し得る。
【0204】
ワンバイワン方法が使用され、かつ、X2が幾何学的にX1よりも「後から」("later")位置付けられている場合、親/祖先検索部344は、X1の親/祖先検索を最初に行い得、AがX1の祖先であることを決定し得ることが理解されよう。次いで、親/祖先検索部344は、(X1を考慮に入れ)X2の親/祖先検索を行い得、X1がX2の祖先であることを決定し得る。したがって、モバイルレイアウト追加部346は、この場合、コンポーネントX1をAの後に位置付け得、コンポーネントX2をX1の後に位置付け得ることにより、MP3を形成し得る。かかる方法では、コンポーネントX1およびX2は、個別のエンティティとして分析され、移動されるため、それらのコンポジションは分離している。
【0205】
クラスタ化方法を使用する場合、親/祖先検索部344は、X1およびX2の両方の親/祖先検索を、X1またはX2を(当該検索のために)重要視することなく行い得、X1およびX2の両方が同じ親(主ページ)および同じ祖先(コンポーネントA)を有することを決定し得る。これにより、コンポーネント追加部340は、X1およびX2を共にクラスタリングし得、X1およびX2を含む仮想スーパーノードを形成し得、初期レイアウトコンバータ200にX1およびX2のコンポジションのモバイル向けに用意されるバージョン(mobile ready version)を形成するように指示し得る。かかる変換されたコンポジションは、Aの下に位置付けられ得、MP4が形成されることが理解されよう。X1およびX2が大きく重複していたため、X1およびX2は、(上述のように)それらのコンポジションを維持するためにサイズ変更されることがあり得る。
【0206】
さらに他の例では、ここで参照する
図28Fに示されるように、2つのコンポーネント(AおよびB)を含む元のデスクトップページDP1を、デスクトップエディタ550を介して4つの新規コンポーネント(意味的に関連するテキストコンポーネントおよび画像コンポーネントの2つのペア(T1/I1およびT2/I2))を加えて編集し、新規ページDP2を形成する。DP2を(本明細書において上述の)ワンバイワン方法を使用してモバイルに変換する場合、親/祖先検索部344は、T1がT2の祖先であることを決定し得る。したがって、生成される(縦方向の)コンポーネントの順番は、(MP2において示すように)A-T1-T2-I1-I2-Bであり得、テキストの説明文と画像との接続は崩れる。DP2を(本明細書において上述の)クラスタ化方法を使用してモバイルに変換する場合、親/祖先検索部344は、T1/T2/I1/I2がすべて同じ祖先(A)および親(主ページ)を有することを決定し得る。したがって、モバイルレイアウト追加部346は、これら4つのコンポーネントを新規の仮想ページでクラスタリングし得、これら4つのコンポーネントに対して初期レイアウトコンバータ200を動作させ得る。T1が意味的にI1に関連し、T2が意味的にI2に関連するため、これらペアは一緒に維持され得る。したがって、形成された(縦方向の)順番は、(MP3内のように)A-T1-I1-T2-I-Bであり得、意味情報を維持し得る。
【0207】
さらに他の例では、ここで参照する
図28Gに示すように、デスクトップページDP1は3つのコンポーネント(A~C)を含み、モバイルに変換される。形成されるモバイルページMP1をモバイルエディタ560を介して編集し、コンポーネントCを除去しかつAおよびBの順序を入れ替えてMP2を形成する。次いで、DP1は、デスクトップエディタ550を介して編集され、2つの重複するコンポーネントX1およびX2がBとCとの間に追加され、かつ、Cの下のさらなるコンポーネントX3が追加されてDP2が形成される。コンポーネント追加部340は、クラスタ化方法を使用するように構成されているため、3つの追加コンポーネント(X1、X2、および、X3)は一緒にクラスタリングされる。親/祖先検索部344が、(Cがモバイルバージョンにおいて除去されているため)Bが3つの新規コンポーネントすべての祖先であることを決定しているからである。したがって、モバイルレイアウト追加部346は、(MP3に示すように)X1およびX2のコンポジションを保持しながら、3つの新規コンポーネントすべてをBの下かつAの上に位置付け得る。
【0208】
追加コンポーネントをモバイルレイアウト追加部346によって位置付けることは、コンポーネントがデスクトップバージョンに追加されるか、または、モバイルバージョンのみに2つの縦方向に分離したコンポーネント間で縦方向に追加される、限定されたバージョンで実行され得ることが理解されよう。
【0209】
他の実施形態では、コンポーネント追加部340は、新規コンポーネントの挿入がモバイルバージョン内の所定のコンポーネントの下に限定されないように、複数の追加コンポーネントの「クラスタ」を、モバイルバージョン内に広がるコンポーネントの「線」の内側のどこにでも追加し得る。
【0210】
さらなる他の実施形態では、コンポーネント追加部340は、追加コンポーネントBを、追加コンポーネントBを祖先として有するよりもむしろ追加コンポーネントBを含むデスクトップレイアウト構成のコンテナに貼り付け得る。かかる形態では、コンポーネントBは、コンポーネントBを含むコンテナCに貼り付けられたままであり、コンテナC内の、デスクトップレイアウト構成およびモバイルレイアウト構成の両構成内に存在し、かつ、コンポーネントBに先行する最後の要素の後に位置付けられることが理解されよう。このアプローチは、コンテナC(および対応するスーパーノード)が空でない限り、または、モバイルレイアウト構成において隠されていない限り使用され得る。
【0211】
さらなる他の実施形態では、コンポーネント追加部340は、モバイルレイアウト構成を横方向にセグメントに分割し、追加するコンポーネントまたはコンポーネントクラスタを、直接的に祖先の後にではなく祖先を含むセグメントの後に追加することによって、モバイルレイアウト構成にコンポーネントを追加し得る。
【0212】
ギャラリーコンポーネント内の行数または列数の変更等の一般的プロパティの変更を含む、デスクトップコンポーネントのスタイル、フォント、または、テキストサイズ等の属性への変更が存在する時、コンポーネント修正部350は、モバイルレイアウト構成内のコンポーネントを修正し得ることが理解されよう。モバイルレイアウト構成が動的レイアウトを前提として視覚的アプリケーションを定義するため、モバイルレイアウト構成は、そのような変更を適応させ、かつ、コンポーネントサイズおよび位置を適切に再調節することができる。
【0213】
また、デスクトップコンポーネントのサイズおよび位置への変更がデスクトップレイアウト構成に影響する一方、それら変更は、本明細書において以下に説明するようにモバイルレイアウト構成が明示的に再生成されない限り、モバイルレイアウト構成に影響しないことが理解されよう。これが許容されるのは、システム100が、コンテンツが変更されない限りでの、複数のレイアウト構成間の見た目(デザイン)の差異を考慮に入れているからである。
【0214】
デスクトップコンポーネントのデータ/コンテンツへの変更が存在する時、コンポーネント修正部350は、モバイルレイアウト構成を適宜更新し得る。属性に対する修正と同様に、そのようなデータの変更は、動的レイアウトを使用して操作される、モバイルレイアウト構成上のコンポーネントの再フォーマットを引き起こし得る。
【0215】
モバイルレイアウト構成への任意の修正は、ユーザによって通常は専用のGUI表示(モバイルエディタ560)またはモバイルプレビューレイアウト構成を有するモバイル修正表示を介して行われ得ることが理解されよう。そのようなモバイルエディタ560は、設計者にモバイル専用コンポーネントの追加、コンポーネントの除去(コンポーネントの隠蔽)、コンポーネントの移動、または、コンポーネントの修正のみ等の所定の操作を行うことができるようにするのみであり得る。したがって、モバイルエディタ560は、モバイル側のみの変更を操作するモバイル操作部360と相互に関連し得る。
【0216】
モバイル操作部360は、(モバイルのみの)追加コンポーネントを位置付けるための多くの方法を使用し得る。モバイル操作部360は、ここで参照する
図29に示すように、コンポーネント線上、または、既存のコンポーネント線に後続もしくは先行する新規コンポーネント線上の2つのコンポーネント間のみへの新規コンポーネントの挿入を可能にし得る。新規コンポーネントXがAとBとの間に挿入され得るか、または、新規コンポーネントYがPの下かつA、B、および、Cの上に挿入され得る。モバイル操作部360はまた、追加コンポーネントの前/後に改行を挿入し得る。
【0217】
この場合、挿入されたコンポーネント(XまたはY)は、先行するコンポーネント(またはコンテナ)に固定され得、モバイルレイアウト構成が再生成され、かつ、「追加されたモバイルコンポーネントを維持する」ことが必要である場合に、上記位置に再挿入され得る。アンカーを利用することができない場合(例えば、アンカー先の(anchored-to)コンポーネントがデスクトップレイアウト構成内から除去されている場合)、モバイル操作部360はまた、コンポーネントのデスクトップレイアウト構成への追加に関して上述したように、最も近い以前のコンポーネントまたはコンテナを検索し得る。
【0218】
また、モバイル操作部360によって、ページ内の任意の位置に(モバイルのみの)新規コンポーネントXを位置付けることができてもよい。この場合、モバイル操作部360は、Xと最も大きく交差するコンポーネントを検索することによって、アンカーコンポーネントを検索し得る。そのようなコンポーネントが利用可能でない場合、モバイル操作部360は、距離および重複の加重平均に基づき、また、距離および重複の閾値を使用することによって(全四辺において)最も近い近隣コンポーネントを検索し得る。そのようなコンポーネントがXを含むコンテナ内で発見されない場合、モバイル操作部360は、アンカーの最も近い縁部からの距離およびオフセットによってアンカーとして定義され得るページ開始部分をアンカーとして使用し得る。
【0219】
サーチエンジンポリシーを遵守しないことがないように、再変換コンバータ300は、再変換コンバータ300によるサーチエンジンポリシーを遵守しない操作を完全に回避し得る。代替として、再変換コンバータ300は、ページのサーチエンジンビューに影響しないコンポーネント(例えば、装飾タイプコンポーネント(例:線、装飾形状))、コンテンツを有しないコンポーネント(例えば、余分なメニューのエントリ情報を追加しないページ内ナビゲーションメニュー)、サーチエンジンに提供されないコンテンツを有するコンポーネント(例えば、背景画像)、および、モバイル環境にのみ関連するコンポーネント(例えば、電話をかける機能、テキスト/MMSメッセージ送信する機能、所定の位置へのナビゲーション機能、または、デスクトップサイトバージョンへの切り替え機能を提供するボタン)を追加することに制限され得る。
【0220】
また、モバイルエディタ560は、非推奨モバイルコンポーネントを最初に「除去コンポーネント」表示内に位置付け得、実際にそれら非推奨モバイルコンポーネントをモバイルレイアウト構成内に組み込むために第2のステップを必要とすることが理解されよう。
【0221】
追加コンポーネントは、本明細書において以下に説明するようにモバイル修正表示内でリスト化され得、特定のモバイルのみに追加されるコンポーネントの除去を容易にし得る。
【0222】
モバイル操作部360はまた、モバイルレイアウト構成からコンポーネントを除去し得る(この除去は、コンポーネントを実際に除去することによって、または、単に隠すことによって実行され得る)。コンポーネントがモバイルレイアウト構成から除去される時に、モバイル操作部360は、同一線内にコンポーネントを再配置することはないことが理解されよう。コンポーネント線全体が除去される時、モバイル操作部360は、ここで参照する
図30に示すように、下側のコンポーネントをできるだけ近接させて上に移動し得る。コンポーネントA、B、または、Cのいずれか(但し、3つ全てではない)が除去される場合、線内の残りのコンポーネント(A、B、または、C)は、影響または移動されない。3つのコンポーネントすべて(A、B、および、C)が除去される場合、コンポーネントQおよびコンポーネントQに後続するコンポーネントは、近接するコンポーネントPに向かって上に移動する。除去されたコンポーネントは、本明細書において以下に説明するように、モバイル修正表示内にリスト化され、後の段階で必要な場合に、隠されたコンポーネントをアプリケーション内に再挿入することを容易にする。
【0223】
また、モバイルレイアウト構成内のコンポーネントは、ユーザによって通常編集用の視覚的データシステムGUIを介して移動され得ることが理解されよう。モバイル操作部360は、ページが再形成されるまで修正を保持し得、本明細書において以下に説明するように、修正をモバイル修正表示内にリスト化し得ることにより、特定の変更を元に戻すことを容易にする。
【0224】
モバイルエディタ560はまた、コンポーネントがモバイルの幅狭の表示ストリップから「外に」("out")(右または左に)移動することも可能にし得る。この例では、コンポーネントは、上記「ストリップ」との所定の最小の横方向の重複を保持し得、ストリップサイズに切り取られて表示され得る。そうでなければ、このオプションは、「コンポーネントを隠す」オプションと同等になり得る。このオプションは、コンポーネント/コンテナの一部のみを示すため、または、一時的にコンポーネントをわきに位置付けてコンポーネントをモバイル構成内に再配置することに役立てるために使用され得る。
【0225】
また、モバイルエディタによって、ユーザは、モバイルレイアウト構成内のコンポーネントの属性、プロパティ、および、スタイルを選択的に変更することができてもよい。モバイルエディタは、そのような変更された属性を「モバイル内での変更」としてマークを付し得ることにより、デスクトップレイアウト構成内での特定の属性の変更は、モバイルレイアウト構成内のかかる属性への変更に影響を与え得ない(かつ、かかる変更をオーバーライドし得ない)。
【0226】
モバイルレイアウト構成に特有の変更として望ましいものであり得る1つの具体的変更は、フォントサイズである。フォントサイズの変更は、コンポーネント調節部227が設計者が要求し得るサイズと異なるサイズを生成する場合に必要とされ得る。したがって、特定のフォントサイズの変更は、(初期レイアウトコンバータ200によって生成されたフォントサイズに加えて適用されるファクタとして)フィールドごとの表示テキストに加えられかつ適用され得る。モバイルエディタ560は、局所的な「スケールファクタ」属性、および、(例えば)かかる属性に影響し得る5%のフォントサイズ増加/減少ボタンを使用してフォントサイズを変更し得る。モバイルエディタ560はさらに、新規フォントサイズをモバイルに適した所定の範囲のフォントサイズに限定し得る。(フォントサイズの変更を含む)任意の属性の修正は、本明細書において以下に説明するモバイル修正表示内にリスト化され得る。
【0227】
本明細書において上述のように、再変換コンバータ300は、所定のモバイルレイアウト構成に特有の修正リスト(例えば、コンポーネントの追加、コンポーネントの除去、および、コンポーネントの修正)を表示する分離したGUIを提供し得る。かかるGUIは、特定のモバイルレイアウト構成の修正を閲覧し、かつ、それら修正と初期レイアウトコンバータ200による他のレイアウトの修正とを区別するために有用であり得る。また、上記GUIは、様々なモバイルレイアウト構成への様々な変更を閲覧し、かつ、特定のモバイルレイアウト構成の修正を元に戻す(例えば、特定の「除去された」コンポーネントを再挿入する)ことができるために有用であり得る。
【0228】
そのような表示は、修正が行われたページ(すなわち、現在のページ、他のページ、任意のテンプレート、もしくは、マスターページ)に応じて、または、修正タイプ(すなわち、コンポーネントの挿入、除去、もしくは、修正)に応じて分割され得ることが理解されよう。
【0229】
上記表示はさらに、これら修正を、タイムスタンプ、ページ内の位置、または、影響されたコンポーネントタイプ等に応じて分類するために使用され得る。モバイルエディタは、選択された修正セットを元に戻す操作をサポートし得る。この場合、モバイル操作部360は、任意の修正を元に戻し得る(例えば、除去されたコンポーネントの再挿入は、逆のコンポーネント位置の修正である)。
【0230】
再変換コンバータ300はさらに、モバイルレイアウト構成の再生成オプションをサポートし得る。再変換コンバータ300はアクティベート時、初期レイアウトコンバータ200に基礎となるデスクトップレイアウト構成上で再度動作するように指示し得(デスクトップレイアウト構成が初期レイアウトコンバータ200が最後に動作してから修正されていることもある)、モバイルレイアウト構成に特有の変更が場合によっては再適用され得る。
【0231】
再生成は、再生成されるべきページ(現在のページ、特定のページ、アプリケーション全体)、および、モバイルレイアウト構成の再生成後に再適用されるべきモバイルレイアウト構成の変更に適用され得ることが理解されよう。これらモバイルレイアウト構成の変更は、カテゴリ(例えば、コンポーネントを隠すのみ)によって選択され得、特定の選択された修正または全修正を含みことができる。また、再生成動作がモバイルレイアウト構成の変更を所定のページまたは複数のページに再適用することなく行われ得る場合、関連するモバイルレイアウト構成の変更は破棄されることが理解されよう。
【0232】
表示部290は、本明細書において上述したように、新規の更新されたモバイルレイアウト構成を表示し得る。
【0233】
上述のようなシステムには、関連するウェブサイト構築システムが多くの方法で統合され得る。例えば、システム100は、実際のウェブサイト構築システムコード内に、クライアント側で完全に組み込まれることも、サーバ側で完全に組み込まれることも、クライアント側およびサーバ側の両方で組み込まれることもできる。システム100はまた、ウェブサイト構築システムと同じサーバプラットフォーム上で動作しても、分離した独立のサーバもしくはサーバセット上で動作してもよい。システム100は、(ウェブサイト構築システムの閲覧時にはいつでも)オンラインで動作しても、(ウェブサイト構築システムの格納された変換後のバージョンを形成するために)オフラインで動作しても、それらの組合せで動作しても(いくつかの段階ではオフラインで動作し、他の段階ではオンラインで動作しても)よい。システム100は、直接的にウェブサイト構築システムのデータ構造上で動作することもでき、ウェブサイト構築システムのコンテンツから独立するようにウェブサイト構築システムによって呼び出される(ウェブサービス等の)インタフェースを提供することもできる。
【0234】
本発明の様々な実施形態において、システム100の様々な要素が、それら要素の機能を様々な方法で分割し、上述の機能を本明細書において上述したような順序とは異なる順序で実行し得ることが理解されよう。さらに、システム100はまた、部分的な機能を使用して部分的に実装され得ることが理解されよう。
【0235】
したがって、具体的なアプリケーションのデスクトップレイアウト構成は、モバイルレイアウト構成(または任意の他の様々なサイズの目的のレイアウト)にコンポーネント間の関係を考慮に入れて適切に変換され得る。さらに、最初の変換後、修正は、デスクトップレイアウト構成およびモバイルレイアウト構成の両方に同じページについて行われ得、新規に生成したモバイルページ内に反映され得る。
【0236】
別段特に述べられていない限り、上記の考察から明らかなように、本明細書全体を通して「処理すること」、「算出すること」、「計算すること」、「決定すること」等の用語を使用した考察がコンピュータ、コンピューティングシステム、クライアント/サーバシステム、または、同様の電子コンピューティングデバイスであって、コンピューティングシステムのレジスタおよび/またはメモリ内の電子的量等の物理量で表されるデータを、コンピューティングシステムのメモリ、レジスタ、または、他のそのような情報を記憶、転送もしくは表示するデバイス内の物理量として同様に表される他のデータに操作および/または変換する、コンピュータ、コンピューティングシステム、または、同様の電子コンピューティングデバイスの動作および/または処理を指すことが理解されよう。
【0237】
本発明の実施形態は、本明細書における操作を実行するための装置を含み得る。この装置は、所望の目的のために特別に構成されてもよいし、コンピュータに格納されるコンピュータプログラムによって選択的に動作するか、または、再構成される汎用コンピュータを備えてもよい。構成される装置は、ソフトウェアによって指示される時に、汎用コンピュータを本明細書において述べた発明要素に変え得る。上記指示は、発明装置にとって望ましいコンピュータプラットフォームと共に動作する発明装置を定義し得る。そのようなコンピュータプログラムは、限定されないが、フロッピーディスク、光ディスク、磁気光ディスク、リードオンリーメモリ(ROM)、コンパクトディスクリードオンリーメモリ(CD-ROM)、ランダムアクセスメモリ(RAM)、電気的プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、磁気カードもしくは光カード、フラッシュメモリ、ディスクオンキー(disk-on-key)、または、電子的命令の格納に適しかつコンピュータシステムバスへ連結可能な任意の他のタイプの媒体を含む任意のタイプのディスク等の、コンピュータでの読取りが可能な記憶媒体に記憶され得る。
【0238】
本明細書に提示される処理および表示は、任意の特定のコンピュータまたは他の装置に固有に関するわけではない。種々の汎用のシステムが、本明細書の技術に係るプログラムと共に使用されてもよく、または、さらに専門的な装置を構成して所望の方法を実行することが便利であり得る。様々なこれらのシステムの所望の構造が、以下の説明から明らかになるであろう。さらに、本発明の実施形態は、任意の特定のプログラミング言語を参照して説明していない。様々なプログラミング言語が、本明細書において説明した本発明の技術を実施するために使用され得ることが理解されよう。
【0239】
本発明の特定の特徴について、本明細書において例示し説明したが、ここで、当業者には、多くの修正、代用、変更、および、等価物が着意されるであろう。従って、添付の特許請求の範囲が、本発明の真の精神の範囲内にあるような、全てのそのような修正および変更を包含することが意図されていることを理解されたい。
【0240】
関連出願の相互参照
本出願は2013年9月12日に出願した米国仮出願第61/876,795号の優先権を主張するものであり、参照によりその全体が本明細書に援用される。