ボタンは甘え

ModelessAndModal

とてもいいコラム。Blogってこういう使い方もあったんだなあ、と思う。

Buttonの項で、「ボタンは、道具としての機械が複雑化してきた過程において、直接操作の実現を放棄した挫折のユーザーインターフェースなのです。」と語っている。まさにボタンで一杯のUI改善案を出そうとしていた所だったのでぎくっとした。

ボタンというのはバッチ処理であって、ユーザのフローを中断させてしまう、と書いてある。ボタンとヘルプを配置しようと考えていたけれど、よく考えてみれば、編集画面に移った時点で、何が編集できるかはすぐに分かるはずだ。

また、複数の関連するリソースを編集する場合、いちいちトップページに戻るよりは、そのまま関連するリソースの作成に飛びたいはずだ。

UIって、作った側もUIの不条理に気付かない所が恐ろしい。UIが良くなければそのプロダクトは使えないし、使えるUIは長く考えていれば思いつくというものでもない。全く持って見栄えとかそういう問題ではない。

空っぽのインタラクション

インタラクティブアートって、結局手法以上の何者にもなれなかったなぁ、ということを考えていた。

インタラクティブがもてはやされた時期があって、業界の人がそろいも揃って全然面白くないインタラクティブアートを量産していたことがあった。手法としてインタラクティブアートなんだけれど、特に何も実現していない、デジタルの枠組みでビジュアライズしましたよ、というようなのが大量にあった。

自分はその頃学生で、インタラクティブアートで食べていけないかなあ、ということを薄ぼんやりと思っていたのだけれど、あんまりアートじゃなかったのもあって、実際に受験とか就活とかでは売りには出来なかった。

インタラクティブアートは、インタラクティブアートやってる人の中で消費していかれる感があって、まあ長続きしないんだろうなという所は心の隅にあった。アート愛好家の中にインタラクティブアートを居間に飾りたいという人は居ないだろうし、かといって一般に幅広く流通するものでもない。技術畑から生まれて技術畑の土に帰っていくような、そんな技術デモ的な作品ばかり生まれては消えていったように思える。

特に何が出来る訳でも無く、インタラクションのみ存在するのがいけないのだと思う。坂本龍一のライブやらでWebからライブに拍手を送信できるようなのや、演奏内容をビジュアライズするようなのがあったけれど、inの大きさの割にoutがpoorだった。観客の反応がデザイナーの意図したものに作り替えられていただけだ。出来ることが増えたわけでもなく、単にインターフェースのみ増えた。

「ソーシャル」っていう言葉も、インタラクションやリアルタイム性を含むものだけど、それによって人とつながることが出来る。単なる「インタラクティブ」とは全く広がり方が違う。

それによって何か新しいことが出来る、ということが重要なんであって、スイッチを押して干渉出来ることは、僕らにとってさほど関心のある事柄ではない。

これから作るものは、スイッチを押したり出来るようなものではなく、環境を作ることをイメージしないといけないと考えている。それがコミュニティなのか、ゲームなのか、ツールなのか分からないけれど、minecraftのような、MMDのような、誰かの可能性を広げてあげられるような環境が必要だ。(とかいうと、Google Waveやらなにやらの爆死を思い出して、そうも言い切れない気がしてくるのだが…。)

そもそもWiki記法は必要なのか?

Wikiでは、タイトルを書く場合、行頭に「!」などのような記号を置く必要があるわけだ。

でも、文のブロックが一行だったらそれをタイトルにしちゃえばよくないか?複数行になったなら、それを本文にすればいい。本文を一行で書きたいんだったら、「~文字以下はタイトル、それ以上は本文」という形にしなければいけないかもしれないが。

最初に書いた行はH1にすればいいし、それ以降はH2にすればいいし、H3が必要なら別ページを作ってそこに書け、というぐらい割り切ったCMSがあってもいいんではないか。

今MarkDownを使っているが、MarkDownは、一般的なWiki記法に比べて、テキスト面の可読性を確保させられる傾向にある。リストにマージンを入れるとか、H1は下部に罫線でマージンを入れさせられたりするけれど、これらは可読性に寄与している。多分Wiki使いからは、タイプ数の面で余計に見えるんだろうけど、従ってさえいれば結構綺麗にフォーマットされた文書が出来上がっている。HTML出力とテキストの見た目が近いのも特徴。

Wikiは「アノテーションです!」感が強すぎて、多分これは人間が見るモノではないんだろうなと思わされる。コマンド定義に方言があるのも、記号と機能の対応に全然必然性がないからだろうね。もっと文法覚えなくていいシステムを作らないと、今後読まれなくなるフォーマットでデータを作ることになる。

書いている最中に見やすく整形されているのは重要だと思う。タイプしている時間は確かに長いけど、目でさっき書いた文章を読み返している時間もバカには出来ないでしょう。読み直しの最中にアイデアが派生することもあるのだから、「書いている時に既に見やすい」のは大事なんじゃないのか。

脱線するけれど、LIFE Vincentノートが好きな理由がはっきりした。あの行間と文字の大きさが見やすいからだ。

「記憶に残る」作品を作る為の努力

ICOインタビューを読んでの感想。

http://www.4gamer.net/games/120/G012071/20111020037/index_2.html

上田氏:  ですね。  まぁでも,今はそういうものを作っていかないといけない,と思いますね。それは,別にビデオゲームに限りませんし,もっと言うと娯楽に限った話でもないですね。商売の本質として,お客様に後悔させちゃいけないと思うんです。  その瞬間はいいかもしれませんが,何年後かに「なんであんなもの買ったんだろう」とか「なんであんなものに時間を使ってしまったんだろう」とか思わせてはいけないと思います。少なくともそれに向かって努力はしていきたいんです。

4Gamer:  いえ(笑),上田さんを前にしているから言っているわけではなく,選ばれたものを眺めてみると,「強い記憶」にまつわるものだけなんですよね。また遊ぶから,とかそういう話ではなくて(笑)。ちゃんと整合性が取れているんです。

「強い記憶に残る」作品は、そうでないものと質的に異なると思っている。それは、作品が「消費財」ではなく、血肉になる、ということだから。

「どのように記憶に残すか」という戦略がもっとあっていいと考えている。利益を出す、という点からは、記憶に残るかどうかって重要度が低いんだと思うけれど、長期的には「後悔させない作品を作る」ことが作り手にとってもプラスになるんだと思う。

というか、作り手にとってその手の努力がプラスになるような環境を作っていかないといけない。

Inklingアイデア

Inklingが発売された。とても欲しいのだけれど、いかんせん紙を使ってしまうので、スキャナに対しての優位性が分からん感じ。どうにかセーブ・ロードをアナログベースで行えないか考えてみた。

  • Inklingにカメラを搭載、紙の端にバーコードを印刷しておき、クリップしたときに読み取る。

バーコードにより、同じ紙であると判定し、次に挟むときには続きを書くことができる。 (バーコードは専用アプリで印刷可能)

あと、レイヤの活用方法を考える。これはまあまあいいアイディアじゃないかと思う。

  • 専用ペンを4色ボールペンにする。

ボールペンを切り替えた時に自動的にレイヤを作成し、切り替える。 (もしくは、芯の付け替えを判定し、自動的に新規レイヤを作成する。芯はシャープペンや別の薄い色を用意し、下書きと清書を区別出来るようにする。)

Web上ではコマ割は変わっていくんじゃないの

電子書籍は紙へのノスタルジア=いずれウェブに同化する【湯川】

表題で十分理解できる意見だし、電子書籍というフォーマットの微妙な欲しくなさというのは、こういう所に出るんだと思う。電子書籍とか言ってるけどこれ要はHTMLでしょと。

フォーマットはコンテンツに影響を及ぼすし、電子書籍が無くなった先はやっぱり普通の、上に目次があって下にコンテンツがあるようなWebなんだろう(フレームかもしれない)。もろに影響を受けるとすれば、漫画のフォーマットかなあ。

漫画のコマ割って、見開きで閲覧するのを前提にしてる所があって、右上から左下に視線を誘導していくんだけど、縦に閲覧するのであれば、もっと分かりやすく上から下に流れなければいけないような気がする。液晶画面の一覧性の悪さを克服するために、コマ割は簡易化されていくのかも知れない。

コマ割は慣習的なものだからそんなに急に変わるかは分からないけど、意味が無いものはどんどん手抜きしていかないと、次のものが作れなくなっちゃうんじゃないかあと思う。

箱と中身の話

どこから拾ってきた文章だったか忘れたけど、文章の一部をぐぐれば引っかかるであろう。

堀川:納得するもの―攻殻では自分のやりたいことが入れられないってこと?

神山: 「企画というのは僕は入れ物のことだと思うんですよ。自分がやりたいことって言うのは企画じゃないんです。それは誰にでもあるもの。企画には自分以外の人も参入してくるわけですから、誰もが乗れるものじゃないとだめなんです。これが作れるかどうかが企画が決まるということなんですよね。箱と中身を混同しちゃいけない。「負け戦」を唱える人は、箱まで自分でつくらなきゃ負けだと思っているか、自分が持っているものは(攻殻機動隊という)箱には入らないんだと思っているかだね。箱と中身を同時に発明できるような天才であればさ、それに越したことは無いと思うよ。」

箱と中身はよく混同するなあと思う。自分は両方作りたい質だ。

箱を作る人間なのか、箱の中身を作る人間なのかというのは、自分自身どっちが向いているのかはよく分からない。どっちかというと中身なんだろうか。

僕は打席に立てることの方が重要であってね

神山: 「今回監督として打席に立ちたいとか、プロデューサーとして打席に立ちたいとか、キャラクターデザインとして打席に立つというチャンスは提示されたのだから、それだけでもやりたいことは叶っているわけですよ。攻殻ではそれができないというのは、僕にはその理由はわからない。全部自分でやりたいと思っているのか、あえてひどい言い方をすれば、本当はやりたいことがないんじゃない、というかね、僕は打席に立てることの方が重要であってね、毎回最終回のツーアウト満塁で自分が打席に立って、満塁ホームランを打つっていうシチュエーション以外打席に立たないよっていうかさ、勝てる試合にしか登板しないというよりは、消化試合だろうと登板してね、じゃあ、消化試合でノーヒットノーランを見せてやるよって言う気概だったかな。」

でも一方で、こういう発言って職業人ならではだよなとも思う。素人が打席に立つ回数をいくら増やしたって、その道のプロの打席回数には結局負けてしまうし役割的にも劣ることになってしまう。だから箱と中身を可塑性のあるものにするのが、素人の戦い方なんじゃないか。何を目指すのかにもよるけれども。

すげえ姿勢としては正しい話だと思いつつも、自分にはそれはできないだろうなぁと弱気になってしまう。言い訳かなぁ。

補正を使った入力UI

iPhoneの加速度装置でキーロガー

英語という特色もあるからこういうことが可能なのかもしれない(単語ごとにスペースが入るため、単語の切り分けの必要がない)のだけれど、こういうファジーな入力を分析する手法は、入力方法にも適用できるかなあと思ったりもする。

増井さんが、以前こんなUIを紹介していた。ソースが見つからなかった為に、記憶で書くけど:

単語と、その単語を入力するのに「どの指を使ったのか」を組にした辞書を作ることにより、キーボードのボタン数を大幅に削減することが出来る。例えば「masui」なら、「r1,l5,l4,r1,r2」となる。

みたいなことを書いていた。今回の研究だとさらに入力情報量が少なくなるが、左右と距離が取れるだけでそれなりの精度で推測出来ることになる。

これで思ったことは、やっぱり増井さんは着想の筋がいいなぁということと、大体の位置だけで入力ができるタッチパネル用のキーボードが出来るかもしれない、ということだ。

まぁ大体、iPhoneのちっこいキーボードで、入力ミス補正が着いていないのはどうなんだ、と思わなくもない。日本語だとなかなか訂正が難しいけれど、英語なら辞書ベースの一致とるの簡単だろうしね。

あと問題は、大まかな入力を許すUIは、修正する際に確実な入力方法が別途必要だということだ。自分は使い勝手のよいツールの条件として、大まかな入力と詳細な入力、両方出来なければならないと思っているんだけれど、今回のアイデアでは辞書ベースの補正が邪魔になって、詳細入力は出来なくなってしまう。

それでもまあストレス改善に役立つ場合もあるだろうから、Appleは入力方法を編集出来るAPIを出してくれないかなあ。

プロダクト志向を自覚する

Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳したを読んだ。

自分は「こういう方向性のサービスなんだ」と思うより、「こうあって欲しい」という気持ちが強すぎて、相手方のこだわっている部分とぶつかってしまいそうになる。決裁者でもない人間がそんなこと考えたらあかんな、と思うけど、考えてしまう。

原文にあるとおり、誰しもを満足させられるプロダクトを作ることは出来ない。運営には運営なりのリアリティがあるのであって、僕の考えは、別のプロダクトで表現するほかない。既にあるプラットフォームのデザイン(=DB構造かな?)を変えるということは相当に難しいことだし、変えられた所で、それ程の成果も期待出来ない。

だいたい僕はプロダクトの作者にはなれるだろうけど、プラットフォームをデザイン出来るほどの細やかな神経は持っていない。細部まで詰めるということが相当に苦手だからだ。小さいアプリケーションのログユーティリティの設計ごときでずっと悩んだりする。

自分自身がかなりプロダクト志向だというのは自覚しておいた方がいいのかもしれない。

同期問題の解決には至らず

iCloudだけれど、アプリケーション&OS側の対応が必要なようだ。dropboxのようなファイルベースの同期ではなく、APIを使った同期なのかな?

OfficeがiCloudに対応することはなさそうなのと、GoogleDocsのようなサービスも同様に疎だということと、macのiWorkとも別段接続がいいわけでもないようだ。てっきりiWork.comとの統合が入るのかと思っていたが…

iPadでの編集作業は、色々な意味で無理(編集弱い・周囲から見られる)なので、せめてmac版iWorkとの統合は早めに済ませて欲しい。