search

e4exp / paper_manager_abstract

0 stars 0 forks source link

Creating User Interface Mock-ups from High-Level Text Descriptions with Deep-Learning Models #685

Open e4exp opened 2 years ago

e4exp commented 2 years ago

ユーザーインターフェース（UI）のデザインプロセスは、多くの場合、高いレベルのデザイン目標を明確にすることから始まります。 しかし、これらのハイレベルなデザイン目標を具体的なデザインモックアップに変換するには、多大な労力とUIデザインの専門知識が必要です。 本研究では、アプリの設計者や開発者がこのプロセスを容易に行えるようにするため、3つの深層学習技術を導入し、ハイレベルなデザイン目標を説明する自然言語のフレーズ（例：「画像やその他のオプションを表示するポップアップ」）からローフィデリティのUIモックアップを作成します。 特に、2つの検索ベースの手法と1つの生成手法、および作成されたUIモックアップの品質を確保するための前処理と後処理の技術に貢献しています。 本研究では、一貫性があり、多様性があり、関連性のあるUIデザインモックアップを提案するための各手法の能力を、定量的および定性的に比較対照する。 さらに、これらの手法を15人のプロのUIデザイナーや実務家に評価してもらい、それぞれの手法の利点と欠点を理解してもらいました。 その結果、デザインプロセスを支援するためのこれらの手法の可能性について、デザイナーは肯定的な反応を示した。

e4exp commented 2 years ago

image

1 はじめに

ユーザー・インターフェースの設計は，複雑なプロセスであり，長年の教育と経験から得られる分野固有の専門知識を必要とします． このプロセスの重要なステップは，ハイレベルな要求仕様からローフィデリティのモックアップ・プロトタイプを作成することであり[19]，このステップには，プロのデザイナーが膨大な時間と労力を費やすことが多い． しかし、多くの小規模なアプリ開発者は、このようなデザイン作業に必要なリソースや専門知識を持ち合わせていないため、最終製品の品質が低くなってしまうことがあります。 このようなモックアップを一から作ることは難しいかもしれませんが、UIに対するハイレベルな要求を自然言語で指定することは、デザインの専門知識がなくても可能です。 このような仕様は、開発者の現在の開発プロセスにすでに存在しているかもしれません。 そのため、テキストの記述をもとに具体的なUIデザインのモックアップを作成できる計算機システムは、UIデザインの実務者にとって大きなメリットがあると考えています。 また、クライアントや専門家ではない人とデザインについて議論する際にも、生成されたデザインの成果物をもとに議論を進めることができるため、このような計算システムは役に立ちます。 仕様に沿った多様なUIを作成するには、プロのデザイナーでもかなりの労力と時間がかかります。 このようなシステムは、プロのデザイナーの作業負荷を軽減し、デザインプロセスにおいてより重要な決定を下すことを可能にします。

このようなシステムに向けた最初のステップは、希望するUIに関する短いテキスト記述から、もっともらしいUIデザインのモックアップをロバストに、首尾一貫して、かつ多様に生成できる手法を開発することです。 HCIの研究コミュニティでは、テキストとビジュアルデザインを組み合わせる試みが数多く行われていますが、その多くは、テキストのコンセプトにリンクした、ユーザーが作成したインスピレーションあふれるデザイン成果物を管理することに焦点を当てているか[12]、言語パーサーに基づく非ニューラル手法を用いてデザインを生成することに焦点を当てています[26]。 前者の手法は，デザイナーがすでに検討した狭い範囲のインスピレーションに限定したデザインを提案するものであり，後者の手法は，硬い言語構造に関連したレイアウトを生成することが多く，ハイレベルで柔軟なコンセプトをうまく扱えない可能性がある． また，テキストの記述を利用してデザインをクラウ ドソースすることも試みられているが[13]，クラウ ドワーカーに頼ることは，実世界での最終的なデザイ ンの品質に影響を与える可能性がある． 最近の深層学習コミュニティの進歩により，テキストから画像を検索して生成するモデルが提供され，機械がテキスト記述に基づいて高品質でもっともらしく，現実的なビジュアルコンテンツを生成・検索する能力が向上した． また、UIとキャプションのペアを集めた大規模なデータセットも最近発表されました[25]。

Bryan Wang, Gang Li, Xin Zhou, Zhourong Chen, Tovi Grossman, and Yang Li. 2021. Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning. UIST’21 abs/2108.03353 (2021). arXiv:2108.03353 https://arxiv.org/abs/2108.03353

これらの大規模データセットと改良された深層学習モデルを用いて、広範囲の自然言語記述に基づいてUIモックアップを検索または生成することができる、このクラスでは初めての3つの深層学習モデル1を紹介します。

これらの手法によって作成されたUIを、自動測定基準を用いて定量的および定性的に比較対照し、15人の経験豊富なUIデザイナーと実務者を対象としたユーザー調査を実施しました。 その結果、提案手法はそれぞれ異なる設計シナリオにおいて独自の強みと弱みを持っていることがわかり、これらの手法がUI設計プロセスにおける様々な支援ニーズをカバーできることがわかった。 これらの提案された手法により、熟練したUIデザイナーとそうでないアプリ開発者のためのUIデザインプロセスを促進する将来のシステムに、重要なビルディングブロックを提供したいと考えています。

我々の提案した手法によって提案された設計成果物を用いてモバイルアプリを開発することで、両グループがより多くの情報に基づいた設計上の決定を下すことができ、より良いエンドユーザー体験を生み出すことができると信じています。

e4exp commented 2 years ago

2 関連研究

テキスト記述を用いて様々なビジュアルコンテンツを生成・検索することは、HCI、コンピュータビジョン、機械学習の研究者によって広く研究されている重要なアプリケーションである。 このセクションでは、異なる方法論を用いてこのようなテキストからビジュアルへの変換を実現している、あるいは我々の提案する手法に重要な構成要素を提供している先行研究のセレクションを調査する。

2.1 マルチモーダルUI埋め込みとテキストから画像への検索

深層学習モデルは近年、同じドメインの下で情報検索タスクを達成することに成功しており、特にUIデザインのような高次元の視覚的コンテンツを含むものに対して成功している。 UI-to-UI検索手法の最先端はScreen2Vec[16]であり、UIのマルチモーダルデータ（要素の種類やテキスト内容など）に対してディープラーニングモデルを学習させることで、意味的に意味のある埋め込みを開発した。 これらの低次元の埋め込みは、その後、個々のUIを表現するために使用され、コサイン類似度のような一般的な距離メトリックを使用した最近接検索に使用することができます。 Screen2Vec は、主に UI 間の検索用に設計されていますが、UI 内のテキストコンテンツの BERT 埋め込み [5] のみを使用して埋め込むベースラインを導入しました。 これは、理論的には任意のテキストからのUI検索を可能にするもので、当社の手法の1つであるText-only Retrieverと密接に関連しています。 しかし、これらのベースライン埋め込みは、UI内の実際のテキストコンテンツにのみ依存しており、UIのハイレベルなデザインコンセプトにマッチしていない可能性があります（セクション4.3の調査結果を参照）。 対照的に、我々の検索ベースの手法では、ユーザーはUIを検索するために短くてハイレベルな説明を指定することができます。

深層学習の研究者は、テキストとビジュアルコンテンツの間のクロスモダリティ検索についても研究している。この分野での最近の研究成果は，コントラスト学習を用いて，バッチソフトマックス損失を用いて画像とそれに対応するテキスト記述の間の共通の埋め込み空間を学習するデュアルエンコーダーである[20]． この学習された埋め込みは、どちらのモダリティの人工物にも対応しており、共通の埋め込み空間にあるテキストや画像の例を検索するために使用することができる。

しかし，この方法は，テキストを含むUIの検索には適用されていない． マルチモーダル・レトリバーは、このデュアル・エンコーダー・パラダイムを応用し、テキストからUIへの検索を行うことができる初めてのディープニューラル・ネットワークです。

2.2 テキストからビジュアルコンテンツへの合成

既存のビジュアルコンテンツを検索するだけでなく、GAN（Generative Adversarial Networks）[6]やTransformer Networks（Transformer）[24]の導入により、ゼロからビジュアルコンテンツを生成する機械の能力が大幅に向上しました。 そのため，これらのモデルアーキテクチャを用いて，テキストとビジュアルコンテンツ（主に自然画像）を橋渡しする深層学習モデルを作成するために，多大な研究努力が払われてきました． 現在のGANベースの手法の最先端は、半教師付きコントラスト学習と敵対的学習を組み合わせて、テキストから高忠実度の画像を生成する「XMC-GAN」[27]です。 また、研究者たちは最近、Transformerを応用して、テキストのトークンから画像領域のシーケンスを生成していますが、これはTransformerが大きな成功を収めているシーケンス間の翻訳タスクです。 最新のTransformerベースのテキスト-画像モデルはDALL-E [22]で、GPT-3ベースのアーキテクチャ[3]を使用して、テキスト記述から離散的な画像コードを生成します。 DALL-Eと同様に、Scones [11]も複数回のテキスト記述から視覚的トークンを生成しますが、出力される視覚的オブジェクトは、我々が提案するUI Generatorの出力と同様に高レベルの属性で表されます。 私たちは、UI要素が低次元のベクトル(要素の次元とクラス)のシーケンスとしてエンコードされるのが良いと考え、Transformerベースの手法をUI Generatorに選びました。 DALL-EやSconesとは異なり、UI Generatorは完全なTransformer Encoder-Decoderアーキテクチャを使用しており、テキストのエンコードとUI要素のデコードを別々のサブネットワークで明示的に行っています。

e4exp commented 2 years ago

imageimage

3 PROPOSED METHODS

このセクションでは、私たちの主な貢献である、高レベルのテキスト記述からUIを検索して生成する3つの方法について詳しく説明します。 図2は、3つの手法の共通点と相違点の概要を示しています。 1つ目の方法は、大規模な言語モデルである一般的なBERT [5]に基づいて、入力記述に最も類似したテキスト記述と対になっているデータセット内のUIを検索するText-only Retrieverです。 2つ目の方法はMulti-modal Retrieverで、ユーザーから提供されたテキスト記述を、テキストとUIの両方の埋め込みが行われている共通の埋め込み空間に処理（埋め込み）することができるデュアルエンコーダー[20]を含んでいます。 そして、この空間内で最も近いUIを直接取り出すことができます。 最後に、UI Generatorは、高レベルのテキスト記述のみからUIを完全にゼロから合成することを学習する生成モデルです。

UI Generatorは、他の2つの方法のように既存のUIを検索するのではなく、UIのモックアップを合成することを学習する必要があるため、この方法では、高品質なUIを確実に生成するために追加の後処理を行います。 以下では、データセットの選択と処理、モデルアーキテクチャ、トレーニング構成、およびこれらの手法に必要なリソースについて説明します。

3.1 データセット

3つの手法はそれぞれ異なるモダリティと特徴を学習に使用していますが、共通してscreen2wordsデータセット2を使用しています。 このデータセットは、RicoSCAデータセットに含まれる22,000以上のUIの詳細属性とスクリーンショットに対応する112,000以上の高レベルテキスト記述を含む大規模データセットです。 我々の知る限り、このデータセットは、我々の目標タスクであるテキストベースのUIモックアップ作成に必要な、高レベルのテキスト記述とUI例のペアを含む唯一の大規模データセットです。

我々は、157123/2364/4310個のUIを持つオリジナルのデータセットをトレーニング/検証/テストセットに使用した。 それぞれのデータセットに含まれるUIは、異なるアプリから取得されています。 各UIには5人のクラウドワーカーがキャプションをつけ、10個以下のテキストトークンで5つの英語の文章を作成します。

3.2 Text-only Retriever

screen2wordsデータセットに含まれるUIの高レベルテキスト記述は、評価されたUIデザインのコンセプトと使用方法の簡潔で抽象的な高レベルのビューを提供します。 我々が提案するText-only Retrieverは、データセット内の高レベルテキストの対応関係のみに焦点を当てた手法である。 このメソッドは、テキスト記述が埋め込み空間の入力テキスト記述に最も似ているトレーニングセットのUIを検索します。

3.2.1 追加の前処理。

Text-only Retrieverは、screen2wordsデータセットのUIのテキスト記述と、目的のUIのテキスト記述の類似性に基づいて、既存のUI例のみを検索します。 BERT モデルの標準的な前処理手順に従って、学習セットの各テキスト記述を小文字に変換し、トークン化した。

3.2.2 モデルの埋め込みと検索。

テキストのみの埋め込みを得るために、事前に訓練された BERT モデル（無条件、隠れ層サイズ 768、12 層） [5]を使用して、前処理された各記述を符号化し、CLS トークンからプールされた埋め込みを得た（文を 与えられた単一の固定長ベクトルを得るための一般的な方法）。 このモデルは、BERT の元の大規模テキストコーパスでのみ訓練されており、ドメイン固有の UI キャプションでは特に微調整されていませんでした。 我々は、対応する UI と同様に、これらすべての埋め込みを保存した。 ユーザーによって与えられたテキスト記述から UI を検索するために、まず、訓練例に適用されたのと同じ BERT モデルおよび前処理手順を使用して、記述を前処理および埋め込みます。 次に、埋め込み空間内のすべてのトレーニングセットの記述から、そのユークリッド距離によって、この記述の最近傍を見つけます。 最後に、データセット内で検索された最近接テキスト記述とペアになっている特定のUIに基づいて作成されたUIモックアップをユーザに提示します。

3.3 マルチモーダルレトリバー

screen2wordsデータセットには、我々のモデルが効果的に利用できる高レベルのテキスト記述よりもはるかに多くの情報が含まれている。 そこで我々は、テキスト記述とUIの詳細の両方を考慮する、より高度な手法を開発しました。 この方法では、テキスト記述とUIの両方を、対比学習法を用いて共有の埋め込み空間に埋め込み、この空間で直接モダリティ間の検索を行います。 我々の知る限り、これは初めてのクロスモダリティのテキストからUIへの深層学習による検索モデルである。

3.3.1 追加の前処理。

Text-only Retrieverとは対照的に、よりニュアンスのある詳細なUIの知識を符号化するクロスモダリティ埋め込みを得るために、screen2wordsデータセットのテキスト記述とペアのUIの両方から大量の情報を含んでいます。 テキスト記述については、他の方法と同じモデルを使用して、個々のテキストトークンを前処理し、BERT 埋め込みの完全なシーケンスを得ました。 次に、UI を要素属性列にフラット化し、開始トークン、終了トークン、および UI のアプリのテ キスト記述のプールされた BERT 埋め込みを含むトークンを各列に追加しました。

UIの各要素（中間要素を含む）に対して、寸法（𝑥,𝑦,𝑤,ℎ）、要素タイプ（screen2wordsデータセットで使用されたものと同じ）、および要素のテキストコンテンツの単一のプールされたBERT埋め込みを埋め込みます。 これにより、UI内の各要素の詳細なコンテンツベース、セマンティック、幾何学的情報が得られます。 また、512 トークンよりも長い UI をフィルタリングします。

3.3.2 モデルのアーキテクチャとトレーニング

Multi-modal Retrieverは、TextEncoderとUIEncoderの2つのサブモジュールを使用して、テキスト記述とUIをそれぞれエンコードします。 このサブモジュールは、テキストから画像への検索に使用されるデュアルエンコーダー[20]から採用されています。 TextEncoderとUIEncoderはそれぞれ、隠れ層のサイズが64、中間層のサイズが256、層数が4のTransformer Encoderです（検証セットでのパフォーマンスにより選択）。 テキスト記述が与えられた場合、前処理ステップから𝑘個のテキストトークンのそれぞれについてBERTエンベッディング𝑡1...𝑘を取得します。 これらのエンベッディングから、TextEncoderを使用して、特別な開始トークンの出力のみをシーケンスの「プールされたベクトル」として取得することで、単一の固定長のテキストエンベッディング𝑙 = TextEncoder(𝑡1...𝑘 ) を得ることができます。 同様に、前処理ステップからは、𝑛 UI要素の属性ベクトル𝑢1...𝑛のフラット化されたシーケンスが得られます。 ここから、TextEncoder と同様に、開始トークンの位置に単一の固定長の UI 埋め込み 𝑟 = UIEncoder(𝑢1...𝑛) を得ることができます。

image

𝑆 (𝑙, 𝑟)をテキストとUIエンベッディングの間のドットプロダクトとする。 この損失でモデルを学習するために、学習率を0.001に一定化したAdamOptimizerを使用します。 Trax4 を使用してモデルを実装し、32 コアの Google Cloud TPU v3 で 2 日間、レプリカごとに 64 サンプルのミニバッチを使用して学習しました。

3.3.3 埋め込みと検索。

ユーザーのテキスト記述𝑡𝑢が与えられたUIを検索するために、𝑙𝑢=TextEncoder(𝑡𝑢)を計算し、ドット積類似度メトリックを用いて学習セット内の最近接のUI埋め込み𝑟を見つけます。 続いて、最も近いUIをユーザーに提示する。 この検索アプローチを、テストセットのテキストとUIの埋め込みでテストし、表1に検索精度5を示した。

全体的な性能は比較的低いが，これはデータセット全体のテキストとUIのペアの数が非常に多く（4310 UI×各5説明文），類似した説明文が異なるUIとペアになっている可能性があり，この評価シナリオの難易度が高くなっているためである． しかし、本手法をクロスモダリティのスケッチからUIを検索する確立された手法Swire[10]と比較すると、Swireのテストセット(276個の候補)と同じサイズの5つのランダムなサブセットの平均で、同じ数の候補からSwireよりも優れた性能を得ることができました。

image

3.4 UIジェネレータ

検索モデルは、UIの大規模なコーパスから関連性のある実例をユーザに提供することができますが、生成モデルは、既存のデザインから学習して、目に見えない柔軟なテキスト記述に基づいて、人間のデザイナーが潜在的に考慮していない新規のUIを合成することができます。 そこで、テキスト記述から直接UI要素の属性を生成するTransformerベースの生成モデルを構築しました。

3.4.1 前処理の追加。

Ricoとscreen2wordsを組み合わせたデータセットの各UI例には、すべてのUI要素の詳細な属性が含まれていますが、そのような情報のすべてがローフィデリティのモックアップを作成するのに役立つとは限りません。 一方、全てのUI要素と属性を生成する学習をモデルに要求すると、タスクの難易度とデータセット内のノイズの量が劇的に増加します。 そこで、当社のUIジェネレータでは、まず、ほとんどのインタラクティブコンポーネントを含むリーフのUI要素のみをフィルタリングして抽出します。 次に、各UI内のリーフ要素のセットを、おおよそのY座標に基づいてソートすることで平坦化します。 もし2つの要素のY座標がほぼ等しければ、次にX座標でソートします。 これにより、フラット化された順序では、左上のUI要素が右下の要素よりも常に早く存在するようになります。 オリジナルのRicoデータセットのUI要素データには、UI要素のセマンティッククラスが含まれていません。 私たちは、各UI要素について[18]で発表された意味論的注釈を用いてデータセットを補強しました。 これにより、データセット内の約89.5%の要素をカバーすることができました。 残りの10.5%の要素について検討したところ、10.5%のうち6.02%が非常に狭い、または非常に短いセパレータ要素であることがわかり、ヒューリスティックな手法で別のクラスに分類しました。 残りの要素は未知のクラスに属するものとして残しておきますが、UI要素の配列には残しておきます。

UI要素の前処理以外にも、他の2つの提案技術で使用されたのと同じ事前に訓練されたBERTモデルを使用して、テキスト記述を埋め込みます。 テキスト記述シーケンス全体の各トークン 𝑒𝑖に対して、1 つの BERT 埋め込み 𝑡𝑖 を抽出します。

3.4.2 タスクの定式化とモデルのトレーニング。

クリーンでソートされたUI要素の属性とクラス、およびテキスト記述のペアを入手したら、機械学習タスクを以下のように定式化します。 我々のモデルは、テキスト記述𝑡1...𝑘のBERTベクトルを受け取り、𝑛個のUI要素𝑢1...𝑛を生成します。 各UI要素は、画面の寸法に対する正規化されたXとYの座標と幅と高さの値[𝑥, 𝑦,𝑤, ℎ]を、UI要素が属する意味的クラス番号のインデックスで1、それ以外の場所では0となるワンショットベクトル𝑒 (𝑐)を組み合わせて表現する。 これにより、各UI要素に対して1つの𝑢𝑖 = [𝑥𝑖 , 𝑦𝑖 ,𝑤𝑖 , ℎ𝑖 , 𝑒 (𝑐) ]ベクトルが得られます。 この問題は、テキストトークンのシーケンスをUI要素のシーケンスに「翻訳」するという、典型的なシーケンスからシーケンスへの翻訳問題と考えることができます。 私たちは、この学習問題で成功している完全オリジナルのTransformer Encoder-Decoder [24]アーキテクチャを採用しました。 図3に示すように、このモデルのアーキテクチャには、クロスアテンション・メカニズムを介して通信するエンコーダとデコーダのサブネットワークが含まれている。 エンコーダーは、テキスト記述𝑡1...𝑘のみを考慮し、それらを入力としてのみ消費します。 デコーダは自己回帰モデルで、以前のすべてのUI要素𝑢1...𝑖-1とエンコーダからのエンコーディングを受け取り、任意の特定の時間ステップでシーケンス内の次のUI要素𝑢𝑖を出力します。 UI要素の正確な座標やクラスを生成するようにデコーダを訓練することはできますが、生成モデルでは一般的に、各タイムステップにおける入力のフォーマットの特定のトークンの代わりに分布を出力します。 各UI要素は連続属性𝑥,𝑦,𝑤,ℎと離散属性𝑒 (𝑐) を持っているため、デコーダの出力を分割して、そのうちの1つの部分を各連続属性のガウス混合モデル (GMM) のパラメータ化に使用し、混合密度ネットワークを形成します [2]。 出力の他の部分は，UI要素クラスのカテゴリ分布のロジットとして扱われます． これにより、単一の予測ではなく、出力されたUIの分布を生成することができます。 ログインページ」のような1つのテキスト記述が、多くの潜在的なUIデザイン候補に対応する可能性があるからです。 エンコーダとデコーダを組み合わせて、Transformerは、予測された各出力UI要素の確率分布を生成します。

image

image

このモデルを学習するために、上記の確率分布が与えられたグランドトゥルースのUI要素配列の負の対数尤度の合計を最小化します（なお、𝑝(𝑢1)は常に開始トークンであるため、学習する必要はありません）。

image

これは、シーケンスモデルを用いて連続した低次元の属性を生成するための典型的なトレーニングプロセスであり、興味のある読者には、同様のトレーニングプロセスの詳細な説明をお勧めします[9]。 最終モデルのエンコーダとデコーダは、隠れ層のサイズが64、中間層のサイズが256、層数が6となっています（検証セットでのパフォーマンスにより選択）。 また，Adam オプティマイザを使用し，学習率を 10-3 で開始し，検証の損失が各率でプラトーになったときに手動で 10-4，10-5 に下げました． モデルの実装にはTraxを使用し、Google Cloud TPU v3（32コア）で7日間学習させました。

3.4.3 UIのサンプリング

モデルが学習されると、テキストの説明が与えられたUI上のすべての要素を、自動回帰的に生成することができます。 各タイムステップにおいて、以前に生成されたすべての要素をテキスト記述とともにTransformerに与え、次に予測されるUI要素𝑢ˆ𝑖について、分布𝑝(𝑢𝑖 |Transformer(𝑢1...𝑖-1, 𝑡1...𝑘 ))からTransformerをサンプリングします。 モデルが生成の終了を示すEOSという特殊なトークンを出力するまで、この処理を繰り返します。 UI要素クラスのカテゴリ分布(ロジットを再スケーリング)とGMM分布(分散を再スケーリング)の両方に0.1の温度パラメータを追加し、与えられたテキスト記述に対して生成されるUIの多様性に変換するモデルの確率を制御しました。

3.4.4 well-formedness Metrics, Filtering and Reranking.

我々の生成的サンプリングアプローチでは、低品質のUIが偶然現れることがあるため、それをフィルタリングするための評価基準として、文献で定義されている3つの既存の整形式メトリクスを採用しました。 これらの評価指標はそれぞれ

検証セットの各例について、これらのメトリックの値を計算し、いずれかのメトリックで検証セットの平均値を超えたUIをフィルタリングして除外します。 次に，同じ3つの指標から総合的なスコアを計算して，生成されたUIを再ランク付けします． まず、検証セット内のすべてのUIの値をモデル化することで、各指標を個別の確率分布として推定します。 次に、それぞれの分布における累積密度関数を取り、これらの値を掛け合わせることでUI候補のスコアを求めます(これは、各UIの例において、それぞれの分布が独立していることを前提としています)。 最後に、各テキスト記述に対して生成された上位50%のスコアのUIを、ユーザーへの最終出力の候補として使用します。

3.4.5 グリッドへのスナップ。

生成プロセスの最後のステップは、モデルからの数値出力をより適切な値に調整することです。 各UI要素を各次元に沿った32個の離散的なグリッドの1つにスナップさせ、モデルが連続変数𝑥,𝑦,𝑤,ℎのそれぞれについて連続的な値を推定する際に、細かいアライメントの不一致を取り除きます。

3.5 レンダリング

提案した手法の最後のステップは、生成されたUIを低忠実度モックアップの表現でレンダリングすることです。 低忠実度モックアップは、デザイナーが細部に気を取られることなく、本質的なデザインアイデアに集中できるため、UIデザインの初期段階でよく使用されます。 私たちはMaterial Designガイドライン[7]に記載されているSVG要素を厳選し、これらのSVG要素内の特定のグラフィック属性を個々のUI要素ごとにプログラムで変更しました（例えば、サークルセレクターを伸ばす代わりに、スライダーのバーの長さだけを変更するなど）。 これらの改良により、UI要素の異なるアスペクト比に対応して引き伸ばしを回避することができ、最終的にはHTML文書にまとめられた首尾一貫したUIモックアップを作成することができました。 なお、検索ベースの手法では、モックアップに加えてUIのオリジナルのスクリーンショットをオプションで提供することができます。 これらのUIはデータセットから直接取得されたものです。

image

e4exp commented 2 years ago

4 実験

提案した手法の有効性を標準的な方法で評価するために，テストセット screen2words における定量的な指標を，提案した手法間で比較対照する． また、テストセットに含まれる個々のテキスト記述に基づいて、各提案手法が提案するUI例を定性的に評価し、各手法の結果の特徴に関する高レベルの定性的な洞察を得た。 重要なのは、それぞれの手法がUIを提案する上で独自の長所と短所を持っており、異なるシナリオの異なるアプリケーションに適しているということです。

4.1 メトリクス セクション

3.4.4で説明したように、先行研究ではUIの品質(well-formedness)を評価するためのいくつかのメトリクスを確立しました。 これらのメトリクスには、Overlap、IOU、Alignmentがあります。 生成/検索されたUIの整形性を測定することに加えて、ロバストなモデルは、多様で関連性のあるUIを好んで提案する必要があると考えます。 先行研究[1]で紹介されている多様性指標は、生成されたUIとテストセット全体からの実際のUIの全体的な分布を比較するものですが、我々の生成したUIはテキスト記述に基づいているため、同じ指標を用いて評価することはできません。

さらに、（与えられたテキスト記述との）関連性は、我々が提案する手法にとって全く新しい基準である。 なぜなら、先行する生成モデルはテキスト記述に基づいてUIを生成する機能を持っていないからである。 我々は、レイアウトとUIのために設計された類似性測定であるDocSim [21]に基づいて、多様性と関連性の両方の測定基準を定義する。 UIのセットの多様性は、セット内の個々のUI間のペアワイズDocSimメジャーの平均値とみなします（この値は多様性が増すと減少します）。 関連性を測定するために、提案のセットに含まれる個々のUIと、特定のテキスト記述のグランドトゥルースのペアUIとの間のすべてのDocSimメトリック値のうちの最大値を取ります。

4.2 定量的な結果

各手法の性能を客観的に測定するために、我々は提案した手法のテストセットに対して前述の定量的な指標を計算しました。 これらのメトリクスは，今後の研究において，我々の手法と比較する際に有用であると考えている． これらのメトリクスは，トレーニングセットに含まれる実際のUIから計算されたものであり，トレーニングセットの平均的なメトリクスと非常によく似ているため，これらのメトリクスは主に参考目的で掲載した． UIジェネレータの整形式メトリクスについては、テストセットの各テキスト記述に対して10個のUIをサンプリングし、サンプリングしたすべてのUIの平均メトリクスを計算しました。 その結果、UIジェネレーターはグランドトゥルースデータや検索ベースの手法を上回ることはできませんが、他の条件のUIの整形度に近いUIを生成することができました。 参考として、レイアウト生成の最先端の先行研究であるVTN[1]が報告した結果も掲載しましたが、VTNのタスクはテキスト記述を含まず、データセットの処理方法も異なるため、これらの結果は我々の結果と直接比較できないことに注意してください。

多様性と関連性の指標については、UI Generatorは他の手法と比較して、多様性は少ないが関連性の高いUIセットを生成しています。 検索ベースの手法では、上位N個のマッチを選ぶために強制的な決定が行われ、与えられたテキスト記述との関連性が低い、より多様なUIが返される可能性があります（表2のText-only Retrieverの高い多様性と低い関連性を参照）。 対照的に、UI Generatorは、同じテキスト記述に関連する異なるタイプのUIをよりスムーズに補間することができ、その結果、グランドトゥルースに関連する可能性の高いUIを生成することができます。 このような傾向は、セクション4.3で調査した結果でも確認できます。

4.3.3 UIジェネレータの結果。

UI Generatorによってゼロから合成された結果については、図4と図5の両方のケースにおいて、この手法は同じテーマの中で小さくてもまとまったバリエーションを作るのが得意であることがわかります。 図4は、リストの構造を変えるためにUI Generatorが行った小さな変更を示しています。 同様に、図5では、同じテーマに沿って様々なレイアウトのポップアップを観察しています。 しかし、このような微妙な変化は、これらの結果に大きなテーマのバリエーションがなく、UIの多様性が低いことにつながります。 バリエーションの不足は、セクション4.2の多様性指標で示されているように、テストセット全体でも観察されます。 UIジェネレーターには、調整可能なサンプリング温度のハイパーパラメータ(現在は0.1の固定値に設定されています)が含まれており、UIの多様性と整形性のバランスを変化させるために、将来的にはこれを検討することができます。 これは、UIの多様性と整形性のバランスを変化させるために、将来的に検討することができます。 検索ベースのメソッドが整形されたUIを返すのは簡単ですが、生成メソッドが賢明なUIを返すのは、既存のUIを使用するのではなく、ゼロから完全なUIを合成する必要があるため、自明ではありません。

image image

e4exp commented 2 years ago

5 ユーザー調査

4.3節で提案した各手法で得られた結果の特徴についての評価をさらに確かなものにするために，プロのUIデザイナーや実務家が我々の手法で作成したモックアップに対する好みを測定するユーザー調査を行った．

5.1 手順

我々の手法で作成したモックアップに対する参加者の好みを調査するために，テストデータセットから多様なデザインシナリオを網羅した5つのテキスト記述を手動で選んだ． そして，提案した手法を用いて，それぞれの説明文に対して5つのUIモックアップを作成した． なお，これらの手法で作成されたモックアップについては，事前に検査を行っていない． これにより、5つの説明文それぞれに対して、5つのUIモックアップを3セット作成することができました。 本研究では、各テキスト記述をデザインゴールとして設定しました。 参加者にはまず、テキストで書かれたデザインゴールに対応するグランドトゥルースのハイフィデリティスクリーンショットが提示されました。 次に、3つの方法で作成された15個のUIデザインをスクランブルした3×5のグリッドが提示された。 これらのデザインモックアップの位置はランダムになっています。 そして、これらのUIに基づいて、以下の2つの質問に答え、その根拠を説明してもらいます。

また，アンケートの最後には，AI支援設計全般に関する以下の質問に対する参加者の意見を聞き，最後に自由形式のコメントや本研究への提案をしてもらいました。

5.2 参加者

今回の調査では、社内のメーリングリストで募集した15名のプロのUI/UX実務者に回答してもらいました。 参加者は、平均9.8年のインダストリアルUI/UXデザインの経験があると自己申告しています。 参加者の職業は、UI/UXデザイナー、UXエンジニア、インタラクションデザイナー、UXリサーチャーなどで、米国と英国に在住しています。 参加者は全員、遠隔地から自分のペースで調査に参加し、調査終了時には20米ドルのギフトカードが贈られました。 各参加者が調査に要した時間はおよそ20分でした。

5.3 結果と考察

調査結果の分析は，5つのデザインゴールごとに分けて行いました． 各デザインゴールのQ1は、参加者がモックアップの表現に慣れるためのウォーミングアップの質問です。 また、これらの質問は、デザイナーが感じたUIの関連性と多様性を測るものでもあります。 なぜなら、関連性と多様性のあるUI提案は、デザインゴールに関連する高忠実度のUIをカバーする可能性が高いからです。 その結果、ある設計目標（記述）に対して、私たちの各手法が他の手法よりも参加者に選ばれる頻度が高い（カイ二乗適合度検定、各ケースで𝑝 < 0.05、手法間の期待頻度は等しい）のは1回だけで、他の2つの記述では結果は有意ではありませんでした。 この結果は、それぞれの方法が特定のシナリオでは競争力があることを示している。

我々の研究におけるQ2は、UI提案の全体的な品質と関連性を評価する上でより重要である。 最初の質問と同様に、3つの記述のうち1つの記述では、各手法が他の手法よりも参加者に選ばれる頻度が高く（𝑝 < 0.05）、他の2つの記述では有意ではない結果となりました。 参加者が選んだ特定のデザインは，セクション4.3で提示した各手法の特徴に関する我々の理解と一致している。 例えば，参加者は，「画像やその他のオプションを表示するポップアップ」（図6の中央の図）については，マルチモーダルレトリバーが最も優れたデザイン案（図5）を提供したと考えています． これらのモックアップが好まれるのは、参加者（P8）のコメントにあるように、画像を含めるためのテキスト説明との関連性が高いからです。 「このデザインでは、ユーザーはメインの画像に集中できる」とコメントしています。 別の例では、「アプリの空白の履歴ページ」という記述に基づく結果（図6参照）では、ほとんどの参加者がUI Generatorによって作成されたモックアップを好んでおり、「何もない状態ではなく、空の状態のイラストがあるのはいいことだ」と述べています（P4）。 UI Generatorによって生成されたモックアップは、空のUIという一般的な構造はそのままに、イラストが大きくなっています。 この結果は、テキストの説明があれば、同じテーマでもバリエーションを持たせることができるジェネレーティブな手法の利点を示しています。

本研究では、多様なUIの提案と設計目標を評価しましたが、本研究の評価は、本研究の手法の恩恵を受けられる可能性のある一部の設計事例を検査しただけという限定的なものであることを認識しています。 今後は、これらの手法の大規模なデータセットに存在する一般的な傾向をより包括的に理解するための研究を提案する。 また，アンケートの最後に設けられたAI支援設計システムに関する自由記述の質問では，我々の手法をAI駆動のシステムに発展させるための実用的な提案がいくつか得られた． これらの質問に対する参加者の回答については、次のセクションで、潜在的なアプリケーション（セクション6）について説明します。

image

e4exp commented 2 years ago

7 DISCUSSION & FUTURE WORK

このセクションでは，我々が提案した手法の設計上の選択と限界について説明します． 提案した方法の現在のバージョンのこれらの側面は、研究者が追求することができると思われるいくつかの将来の仕事の道につながる。

7.1 モデリングの選択

提案した手法では、さらに検討可能なアーキテクチャの選択肢がいくつかあります。 例えば、テキストとUIを別々にエンコードする手法では、テキストとUIをそれぞれエンコードする2つのサブネットワーク（Multi-modal RetrieverとUI Generator）に対して、同じ数のレイヤーと各レイヤーの隠れユニットしか使用しませんでした。 しかし、これらのサブネットワークは、それぞれ独立して最適な構成に調整すべきだと考えています。 特に、テキストの記述をモデル化する際に、UI要素のモデル化とは異なる抽象度が必要になる場合があります。 我々の手法では、各モダリティのデータをエンコードするために別々のサブネットワークを使用していますが、最近のアプローチでは、マルチモダリティ生成タスクであっても、単一のデコーダのみのアーキテクチャを使用しています（例えば、DALL-E [22]）。 デコーダのみのアーキテクチャを使用することで、モデルがより効果的にクロスモダリティ対応関係を形成することができ、より低レベルで構造化された詳細なテキスト記述に基づいてUIを提案するのに役立つ可能性があります。

7.2 デザインに特化した言語のサポート

我々の研究のもう一つの限界は、我々が使用しているデータセットの記述と、我々がサポートすることを目的とした記述のタイプとの間の部分的なミスアライメントに関連している。 screen2wordsデータセットは、クラウドワーカーにUIのスクリーンショットを自然言語で要約してもらうことで収集されています。 クラウドワーカーがUIのスクリーンショットを説明するのに使う言語のタイプは、デザイナーがデザインゴールを明確にする方法と完全に一致しないかもしれません。 例えば、このデータセットのテキスト記述には、デザインゴールにとってあまり重要ではないコンテンツベースの詳細が含まれていたり、デザイナーが望むようなデザイン上の制約に関する情報が欠けていたりするかもしれません。 しかし、今回の研究では、将来利用可能になるかもしれない他のテキストとUIのペアデータセットにも適用可能な、3つの新しい手法を調査することで、貴重な貢献をしました。 このようなミスアライメントの度合いや、デザイン特有の言語に対する我々の手法の有効性を調査することは、今後の課題である。