論文一覧に戻る

査読者 1

総合点

8

確信度

3

コメント

著者はプレゼンテーションのスタイルとして、スライドが先にありそれに基づいて喋るのではなく、
喋るべきストーリーが先にあり、それに基づいてビジュアルエイドとしての表示が行われる、
という形を主張しており、それに基づいたブレゼンテーション補助ツールを作成しています。
主張は納得できるものであり、それに基づいたプレゼンテーションを実行するための
課題もきちんと整理されており、その解決のための実装・実践もできています。
なによりもこの主張に基づいたプレゼンテーションを観てみたいと思わせるだけの
ものはあり、WISS の場での発表にもふさわしいと思われます。

誤植
・p.1右: 「ハウンドアウト」→「ハンドアウト」
・p.2右: 「Swif」→「Swift」
・開きダブルクォートであるべきところが閉じダブルクォートになっているところ多数

★追加コメント

PC委員会での議論にていくつか関連研究に対する言及を追加してほしい、
ということになりました。以下に具体的な内容を挙げますので、ご検討下さい。

[論点: Model-view separationでプレゼン作成]
既存研究として、プレゼン作成用ツールキットへの言及が必要だと考えます。
以下のようなツールキットを使うことで、プログラミングによるプレゼン作成が非常に容易になります。

* reveal.js [http://lab.hakim.se/reveal-js/] はMarkdownで書けます。
  凝りたい場合はHTML/JavaScript/CSSも使えるので表現力は一番高いと考えてよいと思います。
  (動画の貼り込みなども可能です)
* beamer [https://en.wikipedia.org/wiki/Beamer_(LaTeX)] はLaTeXで書けます。
* Pandoc [https://pandoc.org/demos.html] はドキュメントフォーマットの相互変換用ツールなので、
  上記2つと比べるとメタな立ち位置になりますが、一つのソースファイルからreveal.js, beamer
  などを利用したスライドを生成できます。

これらのプレゼン作成用ツールキットについて、以下のような議論が必要ではないでしょうか。

共通するポイント: 
  コメントを書ける (書きたければ、提案手法のようにストーリーを書いた上で、
  ビューに出したくないところはコメントアウトなどの運用ができる)
既存手法の問題点: 
  viewの編集機能が足りていない
  (ファイルの変更をwatchしてviewを更新することは可能)

[論点: Viewのインタラクティブな編集手法]
既存研究として、live programmingへの言及が必要だと考えます。
通常のプレゼンツールは当たり前にviewを編集 (direct manipulation) できます。
ただし、プレゼンをプログラムとして記述するアプローチでは、model の編集
(プログラムの記述)と view の確認(プログラムの実行)が個別の操作となるため、
編集が容易でないという問題が生じます。
ここで著者らはモデルエディタ、ビューエディタ、プレゼンコントローラを同時に
表示する解決策を提案していますが、同様の問題 (gulf of executionと呼ばれます)
を解決する既存手法が live programming です。

例えば TouchDevelop [ACM PLDI '13]ではプレゼンアプリのビューを UI 上から編集できます。
https://doi.org/10.1145/2491956.2462170
プレゼン以外の応用例も含めると、Gneiss [ACM UIST '14]は本提案と似たような
3つ組のユーザインタフェース (source panel=model/spreadsheet editor=view editor/interface builder=view)
を持っており、Webアプリケーションのプロトタイピングを可能にする live programming 環境です。
https://www.cs.cmu.edu/~shihpinc/gneiss.html

これらの既存研究を踏まえたうえで、プレゼンテーション目的の live programming 
環境を作ったという新規性が主張できると思います。

採録判定時のコメント

プレゼンテーションにおけるストーリーと視覚的要素を、それぞれモデルとビューに分離し、モデルをテキストで、ビューをビジュアルプログラミングで記述するシステムには新規性が認められる。難点や疑問点はあれども、著者の経験に基づいた主張は明確である。登壇発表の場で活発な議論を行い、研究を深められればよりよい知見になると思われ、ロング採録と判断された。

レビューサマリ

内容に関するレビューのサマリはコメント欄に記したとおりです。

それ以外の点として査読者らが指摘するのは、
誤植の類が多く見られる、ということです。
少なくとも具体的に指摘されている箇所については、
改善していただくようお願いします。

また、「追加コメント」として記述されているとおり、
関連研究への言及を追加してほしいとの議論結果となりました。
既存の取り組みも踏まえたうえでの論文に直していただくことで
読者の方により分かりやすくなると思われますのでご検討下さい。

その他コメント

なかなかたいへんだとは思いますが、
著者本人以外の使用実績やフィードバックがあれば、
より客観性を増した研究になると思われます。

査読者 2

総合点

7

確信度

2

コメント

本論文は，プレゼンテーションにおけるストーリーと視覚的要素をそれぞれモ
デルとビューに分離し，モデルをテキストで，ビューをビジュアルプログラミ
ングによって記述するシステムを提案しています．

本論文を読み始めたとき，大変面白い研究であると思いました．従来のスライ
ドを単位とするプレゼンテーションシステムがストーリーの検討に適していな
いという問題意識には，本査読者も賛成します．

しかし，本論文を読み進めるにつれて，本論文の提案するシステムが本査読者
の期待する機能を提供するものではないことがわかり，残念に感じました．

本論文の最初の2ページ(2.2節まで)には，提案システムの具体的な姿が明確に
記述されていない一方で，プレゼンテーションのストーリーという観点におけ
る著者の問題意識が大変面白く書かれています．しかし，プレゼンテーション
のストーリーの作成に関して本論文の提案システムが実際に支援していること
は，ストーリーをモデルとして視覚的要素から独立させ，テキストエディタで
記述できるようにしたというものです．それ以降の論文の記述も，ビジュアル
プログラミングによるビューの作成や，iPhoneを用いたリモコンの機能に多く
割かれています．

研究論文においては，実際の研究内容を早い段階で，可能な限り誤解のないよ
うに明確に伝えることが重要であると本査読者は考えます．しかし，本論文は
このような書き方にはなっていないと思います．

以下は詳細に関するコメントです．

- 論文中に「プレゼンテーション」と「プレゼン」，「ソフトウェア」と「ソ
  フト」，「アプリケーション」と「アプリ」のような表現の両方が特に断り
  なく現れます．一般的に使われている略語とはいえ，論文においては最初は
  略さずに記述し，括弧書きで「以下，プレゼン」のように断ってから，略語
  を使うようにすべきです．また，タイトル中の「プレゼン」については，
  「プレゼンテーション」とすべきです．(より細かいことを言えば，本査読
  者は「リモコン」でさえも気になりました．)

- 1節の最初の段落の「ビジュアルエイドという言葉の意味」の部分の前後
  は，ハイフンでなくダッシュにすべきです．

- 2.2節で「Swif」となっている箇所があります．

- 2.2節の「しかしながら3番目の」の部分は，4番目だと思います．

- 2.3節の最後の段落に「3項目に関し」とありますが，直前の段落と同じよう
  に「3項目目に関し」ではないでしょうか．

- 図1で，モデルエディタ，ビューエディタ，プレゼンコントローラの内容が
  対応するようにできないでしょうか．特に「正解無し」，「正解を知ること
  は危険」は，プレゼンコントローラの部分にしか現れていないと思います．
  (「正解無し」は図3で出てきますが．)

- 2.5.1節で二重引用符が使われていますが，二重引用符にも鉤括弧のように
  左側と右側があります．“Introduction”のようにすべきです．

- 2.5.2節で「表示例を4に示す」とありますが，「図」が抜けていると思いま
  す．

- 3節で「ストーリ」(長音符の抜け)とあります．

- 3節で「作成すできる」とあります．

- 4節で「KeyNote」とありますが，「Keynote」が適当です．

- 4節と文献[7]で，「Latex」，「LATEX」とありますが，「LaTeX」が適当で
  す．

- 文献[2]に著者名を付けるべきです．

- 文献[7]で「: journal of Japan Society for Fuzzy Theory and
  Intelligent Informatics」の部分は不要だと思います．(残すのであれば，
  「Journal」にしてください．)

- 参考文献の形式を統一すべきです．特に月の表現，姓と名の間の空白の有無
  を確認してください．

以上です．

査読者 3

総合点

6

確信度

2

コメント

これまでの実績から問題点をあげ、設計方針をたて、実際に対外発表での使用実績もあり、説得力があります。

ストーリと表示内容を分離し、モデルとビューという概念をビジュアルエイド記述に持ち込んだアイデアには新規性を感じましたが、
関連研究であげられていた「内容／モデル」と「見え方／ビュー」を分離する他の試みとの本質的な違いが明記されておらず、
これが本当に新しいアイデアなのか疑問を感じる内容になっています。

プレゼンテーションとハンドアウトを同じストーリから別々に作成するべき、というモチベーションにはとても同意できます。
しかしながら、現在の作り方では、１つのモデルからTPOに合わせた複数のビューを作れるのか、疑問を感じます。
モデルの中にビューの定義が埋め込まれているので、現状の作り方では難しく感じます。
また、モデル内での言い回しとビューでの言い回しを変えたいときなどはどのようにすればよいのでしょうか？
WISSの場でさらなる議論ができるとよいと思います。

システムの使用例のなかでも議論されていた、
・質疑応答の差異に途中の画面を見せるのが難しい
・一覧する機能の実ガンが難しい
などの制約は、実際のプレゼンテーションで用いることに対する難しさを感じます。

結論としては、新規性と有用性の面で若干の疑問を感じるものの、
上記の疑問もWISSの場で議論するにふさわしいと考えます。

さらなる発展としては、聴衆の反応に応じて、あるいは、想定していた聴衆と違った場合などに、ライブで表示内容が変えられると面白いかもしれません。

＝細かい点
P5の右下：「図」が抜けています。「リモコン上のノートの表示例を4 に示す．」