What You See Is What You Getの略ですよね。WYSIWYGの意義は2つあったと思います:
ここでGetというのは、紙の上にGetするという意味、つまり印刷結果を指していました。WYSIWYG on paperですね。
でも、WYSIWYG in a consensusもありでしょう。つまり、コンピューター上でデザインする対象は印刷結果だけではありません。
印刷結果だけでなく、ある結論や合意結果の状態などを表現して、それに向けて、それを実現すべく試行錯誤できるのであれば、そのソフトウェアはWYSIWYGの発展形なのではないでしょうか。
このページは xfy Blog Editor を利用して作成されました。
XVCDでxfyのボキャブラリーコンポーネントを作り始めて、3年弱になります。その間、折に触れてこんな風に思ってきました。
なお、このBlogの他の記事と同じく、以下の内容はわたしの個人的な見解であり、わたしが所属する企業や組織の公式見解ではありません。
こう考えるとよいでしょう、XVCDは、例えて言えば、糸操り人形の《操り糸の配置を記述する》ものです。つまり:
こう考えると、XVCDで記述したものは、《プログラム》や《スクリプト》と呼ぶにはふさわしくない気がします。XVCDをプログラミング言語とかスクリプト言語と呼ぶと、誤解につながる気がします。…でも、そう呼んでしまいますけどね、わたしも。
ある演目で、人形の操作者が人形をどのように操作するか、その手順をプログラムやスクリプトと呼ぶのは適切ですね。また、操作者抜きに自動的に動作する人形の動作を記述したものをプログラムやスクリプトと呼ぶのも適切でしょう。
プログラムでは、それが記述した主な項目の間に順序関係があります。つまりプログラムは《手順》を記述したものですね。この順序関係がおかれる時間とプログラムの利用者が感じる時間が一致します。スクリプトも同様で、台本に書かれた台詞は、順序が決まっています。台詞がおかれる時間と、観客が感じる時間は一致しています。
XVCDで記述したものには、そのような意味での順序関係がありません。糸を配置する手順はあって、それに従って操り糸を配置するには時間がかかりますが、その時間は、プログラムを実行するときに利用者が感じる時間とは別種のものです。その時間は、利用者にとっては、せいぜい起動にかかる待ち時間でしょう。
また、手板を動かして、それが糸を伝って人形に伝わって、それによって人形が動くのにも時間がかかります。しかし、これもまた、プログラムを実行するときに利用者が感じる時間とは別種のものでしょう。
じゃ、なんて呼べばいいんだ？…《変換》と呼ばれているようです。
よくデザインされた操り糸で人形を操作するのは気持ちよいもの…だろうなぁ。これについては、別の機会に。
え？というか、すみません、操り人形をやったことはありません(^-^;
このページは xfy Blog Editor を利用して作成されました。
[ デモ ]
今日の事例の特徴。
[ → SVG形式 ]
[ → SVG形式 ]
このプレゼン資料
例として取り上げた論文。
http://www.yamahige.jp/documents/2007-11-29_SKCROSSING/CrossConcept-for-SKCROSSING-20071130.html
Tim Bray氏の記事「Don’t Invent XML Languages」の日本語訳。
XHTML文書をXSL-FOに変換するXSLTスタイルシート。
上記「CrossConceptにおける…」に適用して、XSL Formatterを使用して2段組にレイアウトした。
アンテナハウス社が公開しているHTMLデフォルトスタイルシートを前提としている。
上記スタイルシート"xhtml2fo-multicolumn-SKCROSSING-v2-20070928.xsl"は、アンテナハウス社が公開している"xhtml2fo.xsl"を前提としている。
アンテナハウス社から"xhtml2fo.xsl"を入手し、これら2つを、同じフォルダ/ディレクトリに置くこと。
「XHTMLからXSL-FO変換用スタイルシート」
http://www.antenna.co.jp/XSL-FO/sample/xhtml2fo.htm
このページは xfy Blog Editor を利用して作成されました。
Continue reading "xfy + XSL Formatter環境におけるXHTMLのマルチビュードキュメントの実現" »
(このセクションは、発表原稿を投稿した時にはありませんでした。また、関連する発表「Parallel Narratology試論 ～ ハイパーテキストにおける相互参照の観点から ～」の発表原稿においても、原稿枚数の制約から記述できなかったものです。しかし、内容を分かり安くするために、発表当日(2007/7/27)に追加説明したものです。)
この前の発表「Parallel Narratology試論 ～ ハイパーテキストにおける相互参照の観点から ～」で紹介したSTORYWRITERの機能を、マーカーという観点から見直してみよう。
STORYWRITERは主に2つの機能から構成されている:
構造化された電子マーカーは、次図のようなUIを持つ。
図 0.1: 構造化電子マーカー
ここでは、『藪の中』の「夫はどんなに無念だったでしょう。が、いくら身悶えをしても、体中にかかった縄目は、一層ひしひしと食い入るだけです。」という部分に傍線が引かれている。この傍線は「アイテム」という観点から「縄」という分類がされている。
画面右ペインには、利用可能な傍線がリストアップされている。「アイテム」、「表情」という観点で大きく2種類の傍線が用意されており、「アイテム」傍線にはさらに、「縄」と「血」という2種類がある。このように、傍線は2階層に構造化されている。「アイテム」、「表情」といった観点は、利用者が使いながら自由に導入できる。
図では利用者は、別の「表情」という観点からも傍線を引くことができる。
図 0.2: 傍線の観点の選択
並行リーダーは、このように電子マーカーで引かれた構造化された傍線を基に、文書の部分を並行表示する。
図 0.3: 並行リーダー
画面左ペインで、右下に「M」マークのある「アイテム」、「表情」はマーカーで利用した、傍線の観点である。右下に「S」マークのある「当事者」、「夫婦」は、文書のセクションを選択するもので、「当事者」は『藪の中』から「多襄丸の白状」、「清水寺に来れる女の懺悔」、「巫女の口を借りたる死霊の物語」の3つの部分を選択している。「夫婦」は「清水寺に来れる女の懺悔」、「巫女の口を借りたる死霊の物語」の2つの部分を選択している。
STORYWRITERの並行リーダーでは、このようなマーカー(傍線)、セクション、さらにファイルという3種類の軸から2つを組み合わせて、文書の部分を並行表示する。図 0.3では、「当事者」という軸と「アイテム」という軸を組み合わせて、「縄」や「血」についての当事者たちの主張の違いを見ている。
「Parallel Narratology試論」では、図 0.4のように、「当事者」と「表情」という軸を組み合わせて並行表示し、次のように『藪の中』を読み取っている。
芥川作品を小さな単位（ セグメント）に区切って、さまざまに操作してみると、一つの事象について、複数の視点からの記述がある部分は、案外少ないことも、容易に明白となる。
なかでも、女が犯された直後の三人三様の視線描写は、本芥川作品の焦点ともいえる部分であり、他者の視線をそれぞれがどう解釈するかが、その後の物語の展開の相違を引き起こす結節点となっている。
「Parallel Narratology試論 ～ ハイパーテキストにおける相互参照の観点から ～」
図 0.4: 当事者の「眼」
このようにSTORYWRITERを使った『藪の中』の《読み》を、従来のソフトウェアで実装されてきたマーカー、例えば注釈機能と比較してみると、次の違いに気づく。
1つの傍線がどちらか1つだけの機能を果たすことは希であろう。しかし、この2つの区別が、本報告の焦点である。
修正指示などのために引く傍線である。修正指示者の査読や校正の結果を執筆者などに伝えるために使う。これは、思考の結果を表現するものと考えられる。
本や雑誌を読むときに、赤ボールペンで傍線を引きながら読むことがある。これは、全部読んでから引くものではなく、読み進めながら引き、後から戻って確かめたりするものである。
このような傍線は、読む過程、すなわち思考の過程を助けるものと考えられる。
底本データ
| 底本： | 芥川龍之介全集4 |
| 出版社： | ちくま文庫、筑摩書房 |
| 初版発行日： | 1987（昭和62）年1月27日 |
| 入力に使用： | 1996（平成8）年7月15日第8刷 |
| 校正に使用： | 1996（平成8）年7月15日第8刷 |
| 底本の親本： | 筑摩全集類聚版芥川龍之介全集 |
| 出版社： | 筑摩書房 |
| 初版発行日： | 1971（昭和46）年3月～1971（昭和46）年11月 |
工作員データ
| 入力： | 野口英司 |
| 入力： | 平山誠 |
| 校正： | もりみつじゅんじ |
ワードプロセッサーの1つの方向性として概念操作の外在化をあげ、そのようなソフトウェアの設計指針を提案し、その具体例としてCrossConcept、Template It!を検討した。これを通して、設計指針がよく定義されていることを示すことができ、また、設計指針があることをもって、ワードプロセッサーの1つの方向性を示せたと考える。
設計指針に基づいて、それぞれの試作を検討する。
CrossConceptでは、リストを組み合わせてクロスチェックするという概念操作を、コンピューター上に表現した。
Template It!では、文章の部分を置き換えるという概念操作を、コンピューター上に表現した。
これら概念操作の外在化によってそれぞれのソフトがもたらす効果は、述べたとおりである。
これらは、代わりに考えてくれるソフトウェアではない。むしろ、ユーザーに考えることを迫る。
CrossConceptでは、作業の成果を、チェック結果の表、あるいは改善されたリストという形でアウトプットできる。
Template It!では、Originalの理解に基づいて、テンプレやコピペがアウトプットされる。
CrossConcept、Template It!どちらも、XHTMLを入力とし、アウトプットもXHTMLである。
WebからリストやOriginal文章を得て、成果をWebに発信することができる。Webから情報を得て、Webに発信するという、Blogに代表される情報の流れに、自然に当てはまるソフトウェアとなっている。
Template It!を使うと、気になる文章のバリエーションを容易に作ることができる。(図2)
図2 Template It!概観
気になる文章(図中のOriginal部)を選択して、それをテンプレートにして(Template It!部)、そのいくつかの部分を置き換えながら、いくつものバリエーション(Variations部)を作ることができる。
文章を、いわゆる「テンプレ」化するテンプレ・ジェネレーターであり、かつ、そのテンプレからコピペ、すなわちバリエーションを生成するコピペ・ジェネレーターでもある。
図2で、「Template It!」部がテンプレであり、「Variations」部に並ぶのが生成されたコピペである。
一番の狙いは、テンプレを介すことで、バリエーション作成の敷居を低くすることで、バリエーション作成を促し、テンプレそのものや、バリエーション生成過程から様々な気づきを引き起こす(inspire)ことである。特に、元の文章について様々な発見をするであろう。すなわち、テンプレやコピペを作る作業を通じて、元の文章を深く読むことができ、かつ、そのときの理解を踏まえて、新たな文章を作ることができる。文字列一括置換機能との違いに留意して欲しい。
図2の例では、「罪を憎んで人を憎まず」という格言から、「遅刻を憎んで人を憎まず」、「バグを憎んで部下を憎まず」、「記録を称えて人を称えず」といったコピペを生成する作業を通して、もとの文章のうち「罪」、「憎」、「人」部分を置き換え可能な変数部としたテンプレも得られた。
この例のユーザーは、この作業を通して、「罪を憎んで人を憎まず」という格言の意味的な構造に触れただろう。その理解を得たがゆえに、「では、バグを憎んで部下を憎まずにいられるか」と格言の意図を自分に引き寄せてみたり、「では、記録を称えて人を称えないのか？」と格言の弱点を突いてみたりしたのである。
Template It!は、XHTML文書の一節を入力として、それをOriginalとする。また、結果のVariationsはXHTML文書のフラグメントとしてクリップボードにコピーすることができ、それを別の文書に貼り付けることで成果を利用できる。
CrossConceptは、XHTMLのリスト2つから、それらを軸として表を構成するツールである。これによって、リストで表現された2つの考えをクロスチェックしたり、その操作を通してリスト自身の構成を検討することが、このツールの目的である。
構成した表や作成したリストは、XHTMLのtable要素、ul要素、ol要素、dl要素としてクリップボードに設定できる。
CrossConceptは次のような使い方を想定している:
CrossConceptは、xfy Basic Editionのボキャブラリーコンポーネントおよびxfy Blog Editorの拡張コマンドとして実装した。
図1 CrossConceptの構成
CrossConceptではリストを軸として使って表を構成する。画面は大きく左右にリスト領域と表領域に分かれる。(図1)
リスト領域にはリストが並ぶ。
表は、リスト領域中の1つまたは2つのリストを、軸として採用して構成される。2つの軸は行または列軸に割り当てられ、軸は行列の見出しとして表示される。この割り当ては「Pivot」ボタンで交換できる。リストを軸として採用することと、それら軸を行列に割り当てることは区別される。
軸の項目の交点に当たる内容はエントリーと呼び、表のセル内に表示される。セルには複数のエントリーが表示されることがある。このため、セルとエントリーは区別する。
エントリーにはカテゴリーを割り当てることができる。カテゴリーにはリスト領域のリストを使う。
また、エントリーを1クリック、2クリックで入力するクイックエントリー機能が用意されている。クイックエントリーの選択肢にも、リスト領域のリストを使う。
CrossConceptの最大の強みは、軸そのものをチェックし、改善するときに発揮される。
CrossConceptでは、同時に最大4つのリストに、次の4つの中からそれぞれ役割を与えて、相互にクロスチェックすることができる。
左領域のリストを選択して、右領域の各部分にドラッグ&ドロップすることで、リストに役割を与えることができる。
最小1つのリストからCrossConceptを使うことができる。典型的な例をあげると:
例1:
例2:
さて、クロスチェックには大きく2種類ある:
この後者、つまり、軸そのものをチェックし改善する作業が、CrossConceptが強みを発揮するところである。
筆者は、概念操作を外在化する様々なワードプロセッサーが、実際に数多く提供されること望んでいる。そこで、このようなソフトウェアの設計指針を示すことにする。
このようなソフトウェアの特徴を設計指針という観点から整理すると次のようになる。
概念操作そのものを自動的に行ってしまう、つまり、代わりに思考するソフトウェアを設計するのではない。
これは、取り組む順番として、まず概念操作を外在化することに取り組んだ方がよいということである。そのようなソフトウェアを否定するのではない。
そこにことばがあれば、既に概念は外在化されているのであるから、これについてさらに悩むのは、後回しにしてはどうか、ということである。
思考の結果を記述するソフトウェアではない。お絵かきツールではない、ということである。
定評のある図解表現はいくつもある。それらは、一定の思考方法を含んでいて、概念操作を見いだすヒントになる。しかし、それら図解の清書エディタを志向するのではないことに留意したい。
何かが判って終わり、ではなくて、判ったことを何か形のあるものに反映できるソフトウェアとする。理由は2つある。
ビジネスパーソンは、アウトプットで評価される。苦労したことではなく、問題提起ではなく、ソリューションまたはその提示で評価される。
判って終わりのソフトウェアは、判った気になるだけのソフトウェアになりかねない。
(TBD)
標準データフォーマットとの相互運用性を確保する。特にインポート/エクスポートの発想を止め、標準データフォーマットを直接サポートする。
概念というのは単独であるものではない。他者の概念を知って、自分の概念を得て、それを発信する。この流れは概念にとって本質的である。
(TBD)
概念操作を外在化するソフトウェアとして、CrossConcept、Template It!という2つのソフトウェアを試作した。
では、どのようなワードプロセッシングがありうるのであろうか？その1つの方向性として筆者が考えるのは、「ことばによる概念操作の外在化」である。
概念操作の外在化とは、人々が頭の中で行っていると推測される概念操作を、コンピューターディスプレイ上に取り出して表現することである。
これらは、推論や判断というほどのものでなく、「引用する」とか「つき合わせる」といったより基本的と思われる操作である。そこで、「思考」ではなく「概念操作」ということばを使うことにした。
概念操作を外在化したソフトウェアは、本質的に次の特長を持つと考える:
概念操作を外在化すると、概念操作の過程にコンピューターソフトウェアが介入することができて、ユーザーが誤りに気づいたり、新たな発想を得たりするチャンスを与えることが可能となる。
これを、かな漢字変換ソフトを例にとって説明する。かな漢字変換ソフトが、漢字入力ソフトではなくて、読みから漢字を含む表記を選択するソフトウェアであることを思い起こして欲しい。人々に、読みから対応する表記得るという概念操作が定着することで、ソフトウェアはその過程に介入することができるようになった。これによって、入力された読みにまでさかのぼって誤りを指摘したり、用語を統制したり、表現の意味を確認したりすることなどが可能となっている。これが漢字入力として発展してきたとしたら、このようなことは困難であったに違いない。
概念の操作が外在化されているということは、とりもなおさず、概念操作の過程を別の人が吟味できるということである。これは、打ち合わせの場などでのプレゼンにふさわしい。
逆に、従来のプレゼンソフトは、この点については一方通行である。あたかも、議論を封じることを旨としているかのようだ。
