
これです。一番わかりやすいのがグーグルなどの検索サイトの検索結果ページに使用されるこんなナビゲーション(ページング)について書きます。
広く普及している割にはワーディングが揺れていたり、何を「ページング」と呼べるかが少し変化していると感じる部分と相変わらず変わっていない部分と両方を感じるからです。
ここでいうページングとは以下の場合を指すものとします。
また以下の場合を除くものとします。
ちょっとわかりづらいかもしれないんですが、これらは分けて考える必要があると思います。除くものとしてリストしたものは、どちらかというとシーケンシャル(連続)型で、一つのコンテンツが便宜上複数ページに分かれているというものですね。並び順に意味があり、意味でページ分割されている。
ここで取り上げたいのは、いわゆる一覧リストがソートされて、文脈的ではなく機械的に複数ページへ分割されている場合のナビゲーションを対象としてみます。
ポピュラーに使われている割にはワーディングに揺れ幅があります。ページング(Paging)、ページネーション(Pagination)、ページャー(Pager)の3つに集約できるかと思います。UIをテーマにしている主要サイトでどういうワーディングや定義(定義がないものは問題点として記載されている内容)をしているか、リストしてみました。
定義でいうとWelie.comかblink design libraryが個人的な見解と近いです。UIPatternsやYahoo!で定義されているような「1ページに表示するのが困難」だけが理由ではないと思うからです(理由は後述)。
ワーディングでいうと英語圏ではPaginationが最も通りがいい印象ですが、和製英語としてのページネーションという言葉は、日本ではDTP用語としての印象が強い(鈴木一誌氏の「ページネーションのための基本マニュアル(pdfファイル)」)。元の英語の意味だった「ページ番号をふる」という意味から、「複数ページに渡る組版ルール」へと日本では意味が独自に拡張されていった経緯があることは、ご本人が著書「ページと力」で書かれている通り。

ページャーもしくはpagerで検索すると同時に使われている検索ワードとしてphp、cakephp、symfony、pear、smartyなどphp界隈のものが多いのでphp界ではこの言い方がポピュラーなんでしょうかね。またページャーといえば英語的にはポケットベルのこと。
以上のようなことを考慮して、ここでは一番無難そうな「ページング」と呼ぶことにします。
「閲覧している画面解像度に対してある程度以上ページが長くなってしまう」という問題以外にも、ダウンロードにかかる時間の問題というのもあると思います。実際、オフラインデータを対象とするクライアント・アプリではどんなにスクロールが長くなってもページングしないものがほとんどではないかと。
iTunesでいうとローカルに保存しているライブラリファイルをブラウズする際にはページングしませんが、オンライン前提のiTunes Storeではページングがほぼすべてのページで使われているのがわかりやすい例です。
そう考えると(クライアントアプリやその他オフラインで完結するシステムではなくて)ウェブサイトでのみ分割する理由があるといえそうです。
最近よくみかける主にダッシュボード型ページや、関連リンクのような形でリストされるインライン型のものを含むのか含まないのか、という点が気になります。
上記サイトの中で明示的にこれをページングに含んでいるのはkonigi.comのみですね(iTunes Pagination)。ちょっと判断が難しいかなと思います。理由を次の項目で書きます。
ではユーザーのモチベーションがだいぶ異なります。
何十ページにもページングされた検索結果が出ている場合、例えば50ページに分割されてリストが表示されている際に、その中の25ページ目を見せるリンクって本当に必要かというと必ずしもそうではないのではないか、と思います。せいぜい
程度でいいのではないでしょうか。必要なたった一つの項目を見つけるためには、ページングでリンクをたくさん出すことよりも、むしろデータの絞り込みやソート機能を充実させることで、データをより絞り込める方が重要だったりするのではないでしょうか。データベースの項目はライブサイトであればそうカンタンに増やせないでしょうが、一つの項目の取りうる値の幅をパラメータ化するなどといったこともできるかと思います。
この場合は、そもそもデータベースを隅から隅まで見せるUIの必要性は低く、例えばiLike.com(アーティストレーティング、ユーザーブラウズ)ではページングをあえて出していず、「もっと見る」というリンク一つのみという潔さ。このような場合には、ページングを出して隅から隅まで見ることを強制するよりも、リコメンデーション的にセレクトされた結果を感覚的に見せてあげる方がよりスマートだと思います。
インライン型のものをページングに含めるかどうかは、インライン型がまさにこれに含まれるから、です。
ブラウザが担うUIと、個別にサイトが担うUIの役割分担が、ブラウザの進化があって整理されてきていて、文字サイズの拡大縮小機能はサイトが個別に個別の使い勝手を持って実装するものではなく、ブラウザ側で(文字サイズだけではなく)画面全体を対象とする拡大縮小機能がIE7以降についたことで解決済みですが、ページングももしかしたら本来的にはブラウザ側で解決すべきものかもしれない。
サイトごとにブラウザの挙動をカスタマイズできるGreaseMonkeyのAutoPagerizeは、現実解として発明に近い。
ある一定の書式で書けばAutoPagerizeに対応する訳ですから、統一した書式が策定できるならばブラウザ側でそういった仕組みを実装することも不可能ではないはず、ではあります。
現時点で問題となる、そもそもリテラシー高い人しか知らないし使ってないとか対応ブラウザが限られている、といった点も解消されそうなんですけどね。
Great article! thanks!
(外人風)
Two thumbs up!
(外人風)
Re: 一覧リストにおけるページングについて
よくまとまってます。circumstance evidence: 一覧リストにおけるページングについて個人的には「Pagination」かな?
もちろん日本語の「ページネーション」の意味は知ってますが
#昔QuarkXpress…
Yes, we can!
LOL!!
(外人風)
thanks for your comments!
hope it helps.
(しかたなく外人風)
どういうページングが使いやすいか、という話を期待しました。しています。
@みっとしぶ
FBありがとうございまーす。
リクエストにお答えして、後日どういうページングが使いやすいか、という切り口で記事を書いてみます。
[...] 使い勝手について、動作ロジックも含めてかなり細かく解説されていますが、具体的なデザイン手法やソースコードには触れていず、まさにユーザー・インターフェイスにフォーカスした内容になっています。少し前にとりあげたページングについても、カルーセル型も込みでばっちり規定されてました。素敵! [...]
[...] » 一覧リストにおけるページングについて circumstance evidence [...]