• http://vd4i.org/

当日は時間切れで個別の事例にタグ付けするところで終わってしまいました。オンラインで議論はなかなか難しいかもしれませんが、続きをサイト上で行い、成果をだしていければと考えています。

• コミットの仕方 | vd4i.org

レイアウトが工夫されたレシピ本がありそれは比較的読みやすいと思いますが、ぼくのイメージするわかりやすさは例えばこういうものです。

• コンポーネント指向料理（2006年のブログエントリ）

今ここで書きたいのはさらに推し進めた内容で、レシピ本に感じる問題とウェブで提供されているレシピサービスに感じる問題ととりあえず分けずに、使いづらさの理由やこうあってほしいということをあげてみます。

• 作り方の手順が平文で書かれていて、料理の先生の語り口調としては理解できるが、全部読まないと理解できず、よって料理の特徴を大づかみに理解できない。
• レイアウトの関係か、写真と説明文が対比していない場合が多く、その場合説明文の情報量が写真よりも多く、やはり文章を全部読まないと理解しづらい。
• よって、予め内容を知っている場合は別にして、たくさんあるレシピをざーっと見ていって、そのなかから候補を選ぶということが難しい。
• 一般的な調理のコツと、その料理固有の事柄を一緒くたに書いてある場合があり、料理の先生の語り口調としては理解できるが、一般的な話と個別な話は別にしてほしい。
• 下ごしらえと調理を分けて考えたい。下ごしらえは個別に自分のペースでやっても問題ない場合が多そうだが、調理は限られた調理器具と時間と料理の点数でかなりテンヤワンヤなはず。
• 複数の料理を同時に作る時に、持っているコンロの数や調理器具の数に応じて、どの順番で作り進めていけばよいかの指示がほしい。

これらが解決するとさらに以下のようなことも実現できそう。

• 食べた料理のレシピを自動的に記録していった上で、例えば不足している栄養分お知らせする。
• もしかしたら今までの歴史的だったりヒューリスティックな料理の分類法とは違う分類の仕方がみえてくるかもしれない。
• 材料名や調理方法以外でのグルーピングや検索方法が見つかるかもしれない。
• 体調や季節によるなんとなくの食べたい気分に答える。

これらを解決するために、構造化されたレシピの表記ルールと実際のレシピ集が作れないかと考えています。
で……少ない料理の経験からもこれは難しいだろうことは想像できます。
以下の画像は以前少しスタディしてみたものです。

ややこしくはあるのですがひとつの仮説としては、下ごしらえにしても調理にしても、調理器具ベースでまとめられないだろうか、ということです。もっと色んな特徴をもつレシピにあてはめていくことで構造化できないだろうか…、と。

こうやって構造化できると料理のバリエーションにも思いがいき、ひとつの料理に材料／調理法で色んなアレンジが存在するとして、どこまでの変更がその料理名でいられるのか、どこを変えてしまうとその料理名では呼べなくなってしまうかが明らかにならないでしょうか。もちろんこれは一括して自動化処理できるものとは思っていませんが。

動的にダイアグラム化することと、それをHTMLベースのウェブ上で表示することの両立が難しそうなこともあり、iPadアプリ化したいのです。レシピ作ったり料理系のお仕事してる方、誰か一緒に組んで取り組みませんか? アプリ開発自体は外注で買い取りとしコンテンツは自分たちで持つ前提です。

注釈としては、クックパッドみたいにCGMで一般の人に書いたり投稿してもらうことは前提にしません。多分これを含めて考え始めるとさらにハードルが高くなってしまうので一旦避けて考えたいです。

他の方のブログ記事で参考事例としていくつかリストしておきます。

• Cooking For Engineerで思い出した:レシピのデータフロー化
• “Cooking For Engineer”
• 書き方のコツ&複雑なレシピ募集
• Cooking For Engineers
• [PDF] レシピ構造を反映したメタデータに基づく菓子コンテンツ共有法の提案
• マギーFeel Good Cooking（画面左下部の作り方チャートボタンをクリックしてください）

中間領域である、と。

中間領域というキーワードから広げていけたら何かコンセプトにつながるものが浮かび上がってくるかなと思い、連想を広げてみると…

• 中間領域→二元論ではない→0/1で割り切れない→アナログ的
• 中間領域→ある概念と別の概念の交差するところ→新しいものが生まれる可能性
• 中間領域→あるものと別のものの混ざるところ→混ざり合う色
• 中間領域→あるものとあるものをつなぐ→結び目、握手
• 中間領域→東京と地方を結ぶ
• 中間領域→ある面とある面の境界面→インター・フェイス（inter-face）
• 中間領域→行と行の間→行間→行間はググれない→ネットにはないその場に居合わせることの価値

とここまで書いて特に落ちはないのですが、何か援用できそうなプロジェクトがあれば、取り込んでみたいと思います。

アンデパンダンというのはそもそもは一般名詞で「フランスで1884年以降開催されている無鑑査・無褒章・自由出品の美術展の名称」(wikipedia)とのこと（初めて知った）。
ある日行われたのは、無審査で出展された数百点の展示の中から、希望する作者が自分の作品を説明し、評者（中村さん＆いとうせいこうさん）がレビューをし、周りを囲んだ200人ぐらいの人がそれを聞きながら順に練り歩いていく。
それを二百作品ぐらい、時間にして4時間とかずっと聞いていると展示されているものの全体感と、評者の価値観（どういう物差しなのかとか、もっと言ってしまうとどういうモノに色目を使っているかなど）がみえてくる訳です。その価値観がどれぐらい一般化されうるかわからないけども。

グラパスのポートフォリオビューイングアワードは、友達の作家さんのおかげで便乗して参加することが出来まして、参加者側の視点も残しつつ、出展している作家さんたちのほぼすべての作品を見、また会話していき、どういうものなのかほぼ全部見ていったあとで、どれが評価されたかを知ることで、主催している人たちの、これまた価値観や色目の向かう先が一部みえてきます。

日本語対応したハードウェアキーボードは、まだ改善の余地があるんじゃないかという話。

入力モードが英語兼ショートカットと日本語の２モードあるのに、現在どのモードを選択中かをハードウェア的にわかりやすくなっていないんじゃないかと。せいぜいランプの点灯をトグルスイッチ的に表示しているだけとか。

Photoshopでショートカットを使うんですが、英語入力モードでないと有効ではなく、操作直前にモードを確認する必要があるんですが、これがちょっと面倒で。個人的にはソフトウェア的に目立たず大きく表示してくれるImageUpを入れているのと、相対切り替え（押す度に日英切り替わる）ではなく絶対切り替え（押せば必ず英語入力モードに）のキーバインドを設定しています。

やや脱線気味にPhotoshopの話を続けると、iPhoneアプリでショートカット集をソフトウェアキーボード化したアプリでPhotokeysというのがありましたが、英語圏のアプリなので特に強制的に英語モードにするわけではないので操作直前に確認するというプロセスをはさむことになり、心理的なワンクションや実際の手間は変わらず。入力時、矯正的に英語入力に切り替えて、その後操作前の状態に戻してくれるのであれば有用かなと思います。誰か作って!

以下Photoshopの話から一般的な文字入力に話を戻しますが、その点、iPhoneでいいなと思うのが、ソフトウェアキーボードであることで、これはナビゲーション用ボタン、これは英語キーボード、日本語キーボード、と出し分けることができること。入力がしやすいかはここでは問題にしませんが、少なくとも何が入力されるか自体は迷いようがない（入力したい文字が画面上にない場合は迷う可能性がありますが）。
ソフトウェアキーボードであることが、たどり着く唯一の正解とは思っていないんですが、ハードウェア的に解決はされていないんじゃないかと。

制作に使う場合とウェブブラウジングなど遊びに使う場合など目的にもよると思いますが、例えば仕事でPC使わないでリタイアしたシニア世代とか、キーボードになじみのない人たちにとっては現在のキーボードはエンジニア専用端末すぎて使いづらいんじゃないかと。これおそらく英語圏の人たちはあまり問題意識を感じないと思うので、なんとか日本製で良いものが出てこないかなー、と思ってます。英語よりも合理的な、日本語の50音配列を生かした配列の文字入力デバイスというか。

LEADING EDGE DESIGNさん作のメディアアートっぽいプロダクトで、tagtypeというものがありました。
日本語の50音配列を生かし、行選択のち列選択で文字を確定させる感じ。すばらしい。これは市販されていないはず。
障害を持たれている方をそばで１ヶ月近く観察して、ゲームコントローラを流暢に扱っているのを見たのが発想の原点とのこと。

実際に手にとってみたことがあって、写真をじっくり見てもわかりますがその時気づいたんですが、日本語は、行が１０行、列が５列なので、行入力には左右両側に入力項目が並んでいて、列入力には同じ値のものが左右両方に同じ値が並んでいます。
なので文字によって、最初に押す行の側で列も入力できるようになっています。ここは最初は少し戸惑うかもしれないけど慣れてしまえば使いやすそう。

もちろんこれでPC使って制作に使う用途にはむいてないので、ブラウジングなどで必要最低限、文字入力が必要な人への入力デバイスとしては面白いんじゃないでしょうか。

マウス

iTunes Storeが先日リニューアルしました。
HTMLベースになり、以前よりもだいぶすっきり＆まともなデザインになったと思います。

びっくりしたのが横スクロール対応。

以前はこんなのでした。

大胆だなーとしばらくアホみたいに眺めていたのですが、少しおいてMagic Mouseが発売されて合点した次第。
デバイス的に縦スクロール／横スクロールが等価的に扱えるので、横スクロールを疎ましく扱う必要がない、と。
なるほど。と思ったのですが、実はその前のMighty Mouseでも横スクロールは対応されていた。

すべてのiTunes Storeユーザーがアップル製マウスを使う訳ではないので、先取りするならサービスの主戦場たるiTunes Storeでやるよりもアップルのサイトなどでやればいいのではと思いましたが。ホイールつきマウスは一般的に縦スクロールのみ対応、のちに横スクロール対応のものも出てきました。これは縦スクロール用のホイールを横に倒すという若干力技な仕様。
一般的にディスプレイモニタは横に長いので、デバイスの普及具合によって、今後はウェブサイトでの横スクロール対応の仕方が変わってくるのかもしれません。

ディスプレイ

愛用中のNECのLCDモニタ（MultiSync LCD2690WUXi2）これはWUXGAなんですけど、縦置きでも使えるので買ってみたのですが、縦に置くと横幅が1200pxになってしまい、狭く感じてしまうというオチ。
ウェブをブラウジングするだけ使う分にはあまり問題ない感じでしたけど、Photoshopで使うとフォントリストが豪快なことだけは確か。

参議院はともかく衆議院は特に、そもそも国政に参加する政治家を選ぶのに、地域に候補者を紐付けてしまう所がすっきりしないんですよね。

ウィキペディアなので正確かわかりませんが、昔（1947年から1980年）は衆議院選挙で全国区制が行われていたのですね。ネットがない時代には、選挙活動の範囲が全国に及ぶので選挙費用が膨大にかかったようですが、これはネットで選挙活動や投票ができればかかるコストやあり方がだいぶ変わってくるのではないでしょうか。

（衆議院でいうと小選挙区比例代表並立制から）全国区制へ移行するメリットとして思いつくものをあげますと、

• 政党でなく政治家個人単位で支持を表明できるようになる。

• いわゆる1票の格差が全くなくなる。

• 候補者と地域の利益が結びつきづらくなる。

• 出馬する地域によって競争率が異なる現状が解消される。

一方で選挙活動が地域に紐づかないので、町中を街宣車で騒音をまきちらしながら名前を連呼して走り回る必要がなくなり、演説する場所は効率を重視すれば人が集まる場所に収束していき、政策の訴求は全国を対象とするのであればネットや他のメディアが中心になり、有権者は「Yahoo!みんなの政治」のような人名ディレクトリに掲載されている、経験した役職や実績のリストやマニフェストなどを参照して判断し、自分の支持する政治家へ貴重な一票を投じることができる、と。

仕組みだけで考えると総理大臣も直接投票できてしまうかもしれませんが、まずは国会議員だけでも直接投票できるようになってほしいですね。

政治家にとっても政局よりもちゃんと実績を残す方にインセンティブ的なものを感じるようになるんじゃないか、そうなってほしいという率直な思いです。あきらかにこっちの方が風通しがよさそうに思うのですけどねー。素人の一意見でした。

Yahoo!ショッピングはよく出来ていて、上記ダイアグラムはショッピングカートに入れた商品をユーザーが購入するまでのページごとの入力情報を、それぞれ上から下へ画面表示順にまとめたものですが、まずYahoo!ショッピングは、色んな店舗の集合体なので、店舗ごとにサポートしている決済手段／配送方法が異なっており、よって店舗ごとにショッピングカートが異るのでそれを選ぶところから始まるのですが、その後は上記step 1 からユーザータスクがスタートします。

ユーザーが滅多に変更することのないアカウント情報に紐づいている入力情報はstep 2にまとめられており、それ以外の、その時の買い物固有の入力情報はstep 1にまとめられています。

注文完了までたった3画面で端的にまとめられていますが、注文内容の表示位置にもこだわっているのが見受けられます。

step 1ではユーザーが注文しようとしている直後ですから、何を注文しているのかがわかるよう一番上に配置。step 2ではそのプライオリティは下がります。一番下ではなく、一番下にはメールアドレス入力欄があるのがちょっと不思議ですが、これは後述する通りリニューアル以前の名残りかもしれないですね。そしてstep 3では、もう注文完了直前の確認画面ですから再び注文内容の表示位置が一番上にきています。

といった感じで隅々まで考えつくされているのに。ああ。

step 3の注文内容確認画面で突然登場するメール送信のチェックボックス。初期状態ですべてオンになっています。

一番下までスクロールして確認しないユーザーは、気づかぬうちにメール送信に合意しているという訳です。

楽天市場が同じ仕様で有名ですが、楽天はある意味潔く以前から一貫してこの状態なのに対し、記憶が正しければ、以前2006年暮れごろに調べた時には、Yahoo!ショッピングは注文内容確認より前の画面、メールアドレスを入力する箇所でメール送信についても尋ねてきていたはず（初期状態でオンだったかまでは記憶にないのですが）。2007年11月29日のリニューアルで今の状態に改変されたのでしょうかね。

言わずもがなですが、一般的にこういった一連のタスクが複数ページにまたがって行われ、最後の一歩手前で入力内容を確認させる際に、その画面で初めて新しい要素を登場させることはユーザーに対する裏切り行為に近いものがありますが、さらにその内容がメール送信に合意という、買い物終えてしばらくして、関連性があやふやになっている頃にショップ側からのアクションとして届くのであんまりよろしくないかと思います。

Greasemonkey 用スクリプト – Deny Rakuten News

「デザイニング・インターフェイス」という書籍でこんな記述があります。

「直感的」という言葉は若干誤解を招きやすい。かつてジェフ・ラスキンは、われわれがソフトウェアの利用に関して「直感的」だと言う場合、実は「慣用的」だということを言わんとしているのだと指摘した。コンピュータの「マウス」は、それを一度も見たことがない人にとっては直感的ではない。

マッキントッシュに始まり、iPod、iPhoneへ連なるアップル製品を使いこなすユーザーが「直感的」ですばらしいと感じる時の「直感的」というのは実は「慣用的」ではないのか。

iPhoneのマルチモーダルでジェスチャーによる操作方法は、何も説明がない状態では、操作しようがないのではないだろうか（森公美子氏の例をひくまでもなく）。

横方向ジェスチャーのページング、縦方向ジェスチャーのスクロール、ともにPC上のUIでは必要な視覚的なナビゲーションのヒントが、iPhoneにはほとんどありません。ただ、一度ユーザーが操作方法を理解した後は操作方法が圧倒的に「直感的」で楽しいものとなっています。

これです。一番わかりやすいのがグーグルなどの検索サイトの検索結果ページに使用されるこんなナビゲーション（ページング）について書きます。

なぜページングなんてものを取り上げるのか

広く普及している割にはワーディングが揺れていたり、何を「ページング」と呼べるかが少し変化していると感じる部分と相変わらず変わっていない部分と両方を感じるからです。

定義

ここでいうページングとは以下の場合を指すものとします。

• ウェブにおいて、閲覧している画面解像度に対して一覧リストがある程度以上長くなってしまう場合に、閲覧上の負荷を下げる目的で複数ページに分割して表示する見せ方やそのナビゲーションのこと

また以下の場合を除くものとします。

• 一つの記事が画面サイズ長い場合に、編集的視点でページを複数に分割している場合のナビゲーション
• 一つのタスクが複数ページにわかれている場合（ショッピングサイトの購入フローなど）のナビゲーション

ちょっとわかりづらいかもしれないんですが、これらは分けて考える必要があると思います。除くものとしてリストしたものは、どちらかというとシーケンシャル（連続）型で、一つのコンテンツが便宜上複数ページに分かれているというものですね。並び順に意味があり、意味でページ分割されている。
ここで取り上げたいのは、いわゆる一覧リストがソートされて、文脈的ではなく機械的に複数ページへ分割されている場合のナビゲーションを対象としてみます。

ワーディング

ポピュラーに使われている割にはワーディングに揺れ幅があります。ページング（Paging）、ページネーション（Pagination）、ページャー（Pager）の３つに集約できるかと思います。UIをテーマにしている主要サイトでどういうワーディングや定義（定義がないものは問題点として記載されている内容）をしているか、リストしてみました。

ページング（Paging）

ソシオメディアの定義

一連の情報が複数ページにまたがる場合、ページを送るためのリンクを表示する。

Welie.comの定義

Users need to browse through a large list of items looking for the item that interests them most.

blink design libraryの定義

most web-based systems seem to bump into performance limits that prevent implementing infinite scrolling. And so some amount of paging navigation is usually required.

ページネーション（Pagination）

UI Patternsの定義

The user needs to view a subset of sorted data that is not easily displayed on one page.

Yahoo! Design Pattern Libraryの定義

The user needs to view a subset of data that will not be easy to display within a single page.

Konigiの定義

(not available)

あるjQuery pluginの名称

When you have a a large list of items (e.g. search results or news articles),
you can display them grouped in pages and present navigational elements to move
from one page to another.

ページャー（Pager）

あるjQuery pluginの名称

(not available)

あるPHPライブラリーの名称

(not available)

どれが一番ふさわしいのか

定義でいうとWelie.comかblink design libraryが個人的な見解と近いです。UIPatternsやYahoo!で定義されているような「１ページに表示するのが困難」だけが理由ではないと思うからです（理由は後述）。
ワーディングでいうと英語圏ではPaginationが最も通りがいい印象ですが、和製英語としてのページネーションという言葉は、日本ではDTP用語としての印象が強い（鈴木一誌氏の「ページネーションのための基本マニュアル(pdfファイル)」）。元の英語の意味だった「ページ番号をふる」という意味から、「複数ページに渡る組版ルール」へと日本では意味が独自に拡張されていった経緯があることは、ご本人が著書「ページと力」で書かれている通り。

ページャーもしくはpagerで検索すると同時に使われている検索ワードとしてphp、cakephp、symfony、pear、smartyなどphp界隈のものが多いのでphp界ではこの言い方がポピュラーなんでしょうかね。またページャーといえば英語的にはポケットベルのこと。

以上のようなことを考慮して、ここでは一番無難そうな「ページング」と呼ぶことにします。

ページを分割する理由

「閲覧している画面解像度に対してある程度以上ページが長くなってしまう」という問題以外にも、ダウンロードにかかる時間の問題というのもあると思います。実際、オフラインデータを対象とするクライアント・アプリではどんなにスクロールが長くなってもページングしないものがほとんどではないかと。
iTunesでいうとローカルに保存しているライブラリファイルをブラウズする際にはページングしませんが、オンライン前提のiTunes Storeではページングがほぼすべてのページで使われているのがわかりやすい例です。
そう考えると（クライアントアプリやその他オフラインで完結するシステムではなくて）ウェブサイトでのみ分割する理由があるといえそうです。

何を「ページング」と呼べるか

最近よくみかける主にダッシュボード型ページや、関連リンクのような形でリストされるインライン型のものを含むのか含まないのか、という点が気になります。

上記サイトの中で明示的にこれをページングに含んでいるのはkonigi.comのみですね（iTunes Pagination）。ちょっと判断が難しいかなと思います。理由を次の項目で書きます。

ユーザーのモチベーション

1. 「該当する一つを探し出したい（例えば書名を知っている本を探したい）」ような場合
2. 「なんとなく探したいものが決まっているが、いいものがないか探しながら見つけたい」ような場合

ではユーザーのモチベーションがだいぶ異なります。

「該当する一つを探し出したい（例えば書名を知っている本を探したい）」ような場合

何十ページにもページングされた検索結果が出ている場合、例えば50ページに分割されてリストが表示されている際に、その中の25ページ目を見せるリンクって本当に必要かというと必ずしもそうではないのではないか、と思います。せいぜい

• 前後ページへの移動リンク
• 一番前のページへの移動リンク
• 全体の件数と今見ている項目の順番

程度でいいのではないでしょうか。必要なたった一つの項目を見つけるためには、ページングでリンクをたくさん出すことよりも、むしろデータの絞り込みやソート機能を充実させることで、データをより絞り込める方が重要だったりするのではないでしょうか。データベースの項目はライブサイトであればそうカンタンに増やせないでしょうが、一つの項目の取りうる値の幅をパラメータ化するなどといったこともできるかと思います。

「なんとなく探したいものが決まっているが、いいものがないか探しながら見つけたい」ような場合

この場合は、そもそもデータベースを隅から隅まで見せるUIの必要性は低く、例えばiLike.com（アーティストレーティング、ユーザーブラウズ）ではページングをあえて出していず、「もっと見る」というリンク一つのみという潔さ。このような場合には、ページングを出して隅から隅まで見ることを強制するよりも、リコメンデーション的にセレクトされた結果を感覚的に見せてあげる方がよりスマートだと思います。
インライン型のものをページングに含めるかどうかは、インライン型がまさにこれに含まれるから、です。

ブラウザとサイトでのUI役割分担

ブラウザが担うUIと、個別にサイトが担うUIの役割分担が、ブラウザの進化があって整理されてきていて、文字サイズの拡大縮小機能はサイトが個別に個別の使い勝手を持って実装するものではなく、ブラウザ側で（文字サイズだけではなく）画面全体を対象とする拡大縮小機能がIE7以降についたことで解決済みですが、ページングももしかしたら本来的にはブラウザ側で解決すべきものかもしれない。
サイトごとにブラウザの挙動をカスタマイズできるGreaseMonkeyのAutoPagerizeは、現実解として発明に近い。
ある一定の書式で書けばAutoPagerizeに対応する訳ですから、統一した書式が策定できるならばブラウザ側でそういった仕組みを実装することも不可能ではないはず、ではあります。
現時点で問題となる、そもそもリテラシー高い人しか知らないし使ってないとか対応ブラウザが限られている、といった点も解消されそうなんですけどね。