2008年12月のアーカイブ

先日の記事(PORTAのAPI使ってみた、けど。)のあと、いろいろ試してようやくまともに書誌情報が取得できたので、報告します。

解説すると長くなるので、とりあえずPHPのサンプルを各種。プログラマー各氏にはこのほうが話が早いかも。

FC2ブログの仕様上、拡張子がphpだとアップ出来ないのでtxtにしてます。

PORTAへのリクエストでは、書誌情報のスキーマがdcかdcndl_portaか選べ、そのパッキング方法をxmlとstringから選べる。はじめどれがいいかわかんなかったので、都合この組み合わせ4つのサンプルを用意した。

• スキーマ:dc パッキング:xml
  porta_dc_xml.txt
• スキーマ:dc パッキング:string
  porta_dc_string.txt
• スキーマ:dcndl_porta パッキング:xml
  porta_dcndl_xml.txt
• スキーマ:dcndl_porta パッキング:string
  porta_dcndl_string.txt

また、先日の記事の追記でも書いたけど、PHPのSimpleXMLだと名前空間の扱いがめんどくさいので、名前空間付きの要素名を適当に置換するバージョンも2つのスキーマ向けに作った。

• スキーマ:dc パッキング:xml 名前空間付きの要素名を置換
  porta_dc_replace.txt
• スキーマ:dcndl_porta パッキング:xml 名前空間付きの要素名を置換
  porta_dcndl_replace.txt

結局、最後のやつが一番使いやすい気がします。

あと、おまけ。

• 最後のやつの出力サンプル
  porta_dcndl_replace.html

にしても、dc:identifierの種類が属性を参照しないとわからんとか、全角英数字を使ってるとか、複数の著者名と役割表示が1つの文字列にまとめられてるとか、Amazonに比べると扱いにくいこと扱いにくいこと。既存の目録規則やDublin Coreにとらわれずに、もっとまともな構造のデータで出力してくれると嬉しいんだけどなあ。

なんかひさしぶりにこのブログを見たら巨大な広告が入って、なんだなんだと思ったら、「上記の広告は１ヶ月以上更新のないブログに表示されています。新しい記事を書く事で広告が消せます。」との事、ビューの少ないブログでの広告効果上昇と、記事執筆のモチベーション上げ効果を狙ってるわけか。閲覧者にとっては単なる迷惑だろうけど。

証拠写真。広告のせいで、ほとんど記事が見えない。

とまあ、そういうわけで、メモっておいたことを記事にしておきます。偶然にも上の話とも関わってるし。

まずは結論

横長ディスプレイ環境下において、縦方向のスペースは貴重である。

Webページではスクロールなしでアクセシビリティを確保しなければならないし、ソフトウェアのインターフェイスではコンテンツ表示部を圧迫しないようにしなければならない。

ディスプレイは横長、コンテンツは縦長

そもそもディスプレイが横長なのは人間の視界に合わせてのことだろう。左右の目で見る人間の視界は横長であり、ディスプレイやスクリーンが横長なのは合理的である。

一方で多くの文書は縦長である。文書も本のかたちで見れば横長なのだが、それぞれのページは縦長である。あまり一行が長いと目で追うのが大変なのがその理由だろう(縦書きのノベルスや、横書きでもA4などの大きな版では多段組になってるのも行の長さの関係)。ブラウザの横幅いっぱいに行がひろがるWebページを思い出してみればいい。

もちろん見開きの状態でディスプレイに表示するという手もあるのだが(実際、組版を行うソフトウェアやAdobe Readerなどでは見開きで表示することがある)、構造的にはページは縦に連なっているし、(横方向へのスクロールを想定しない場合)見開き2ページ分の横幅を確保すると、1ページあたりにさける画面スペースがかなり小さくなってしまう。

縦方向スクロールの問題

そんなわけで、現在は、横長のディスプレイに縦長のコンテンツを表示するというのが一般的な状況にある。見開きを表示しても十分な解像度が確保できる環境は少ないし、縦横両方にスクロールしなければならないというのはちょっとストレスが多い(表計算ソフトでは一般的だが、やっぱりストレス。Apple Mighty Mouseみたいな横スクロールできるマウスあると少しはましだけど。)。ということで、(前置きが長かったが)縦方向にのみスクロールするというのが標準的なつくりである。

しかし、スクロールが可能ということは、理論上無限のスペースが縦方向にはあるわけで、コンテンツ以外もの=操作系や広告、外見上の要素などが大きなスペースを占めていることがすくなくない。

Webページのデザイン

スクロールが必要なレイアウトは情報の一覧性を失ってしまうし、ページ遷移が起こると毎回スクロール位置が初期化されてしまうWebページでは、同じスクロール操作を繰り返し要求され、ストレスがたまる。

Webページでスクロールが必要となるのはほぼ避けられないが、スクロールしない状態で見えるページの左側、上側だけで十分なアクセシビリティを備えていなければならない(逆に高いアクセシビリティを必要としない要素は、スクロールしなければアクセスできない位置にあってもよい)。

ソフトウェアのインターフェイスデザイン

また、ソフトウェアの操作系は画面の上部に表示されることが多いが、コンテンツが縦方向にスクロールするのに対し、普通この部分はスクロールされることはない。そのため、この部分に大きなスペースが割かれると、貴重な縦スペースを占有し、コンテンツ表示部を圧迫してしまうことになる。

Microsoft Office 2007の「リボン」は確かに慣れると使いやすいが、解像度の低いディスプレイでは、あまりにも多くのスペースを取りすぎる。Google Chromeが非常にすっきりした印象を与えるのも、コンテンツ表示部以外の部分を最大限切り詰めたからだろう。小型のノートパソコンや、ネットブック、スマートフォンなどの低解像度環境ではかなり重要なファクターになる。

余談

ところで、コンテンツは縦長ということを前提に書いてきたが、実は縦書きの場合、コンテンツは横長になる。巻物(まさに横「スクロール」だ)を見てみれば一目瞭然である。横長のコンテンツが基本で、横スクロールが一般的であれば、横長ディスプレイとの親和性は高かったかもしれない。