Notes on Character Encoding Conversions

I did a quick bit of research on Japanese character encodings and how functions in PHP handle the conversions between them.

The table below summarizes the results (click to enlarge).

スクリーンショット 2014-03-07 16.11.06

We can see the following;

  1. Although Shift-JIS (SJIS) is still the most common format in Japan, it is terrible at handling special “hankaku” (single-width) characters. It simply leaves out a lot of them; even the ones that we would like to use quite frequently.
  2. The PHP mb_convert_encoding function gives up when it can’t find a matching character, and deletes the character. On the other hand, iconv does a pretty good job of finding a good substitute if we specify //TRANSLIT.
  3. Gathering from webpages that I can find on the subject, a lot of people seem to prefer mb_convert_encoding with the sjis-win encoding. This is a lousy solution if you are using special “hankaku” characters. It’s better to use iconv with CP932 encoding and //TRANSLIT. There is one snag with CP932 encoding with //TRANSLIT and that is with regards to the “hankaku” yen character (“¥”). Converting to “yen” isn’t really a nice solution. You can see however that //TRANSLIT always converts to ASCII, and “yen” probably is the only way you can sensibly convert the ¥ mark. Otherwise, it’s a good idea to use the “zenkaku” (double-width) “¥”.
  4. The micro mark “µ” is not supported in Shift-JIS but the greek mu “μ” is. Therefore, if you want to write a micro mark in Shift-JIS, you should use the greek mu instead. Again, iconv with //TRANSLIT does the correct thing (converting it to “u”).

CMSの役割について考える

最近ライフサイエンスの研究試薬・機器メーカーのウェブサイトを画期的に良くするサービスを準備していて、その関連でメーカーのウェブサイトを良く眺めています。

そうする中でCMSの存在が気になります。どういう風に気になるかというと、あまりクライアントの役に立っていなくて、むしろウェブサイトを悪化させているのではないかと感じているのです。

ポイントはメーカーのウェブサイトの特徴です;

  1. メーカーウェブサイトのボリュームの大半は製品ページであって、これはほとんど更新することがありません。更新するとしても印刷版のカタログと同期させることが(本来は)必要なので、どこかで更新履歴がまとまっていないと印刷版との同期がおかしくなります。
  2. メーカーウェブサイトの更新の大半はキャンペーンや新製品です。どれも新しいページの作成が必要です。特にキャンペーンページはデザインが重要なので、ウェブデザイナーに依頼します。製品担当が直接ページを作成することはありません。新製品の場合、注力製品であればイメージなども多いので、やはりウェブデザイナーに依頼するのが無難です。

CMSの最大の「売り」は、ウェブデザイナー以外の人がコンテンツを直接書き込めることですが、少なくともメーカーのウェブサイトの場合はそのニーズがそもそもないと感じています。

そうなるとCMSの欠点ばかりが見えてきます。CMSの欠点についてはYahoo知恵袋に良くまとまっていますが、一言で言えばCMS導入業者への依存度が凄く強くなることです。

総合すると

  1. CMSはメーカーにとってはメリットがない
  2. CMS導入業者にとっては継続的に管理費やカスタマイズ費がもらえるので、メリットだらけ

もちろんCMSには他にもメリットがありますが、そのほとんどはDreamWeaverのようにサイト管理機能が充実しているソフトウェアを使えば同等以上のことができます。

  1. CMSはテンプレートでデザインの統一性が保てます。DreamWeaverにもテンプレート機能が充実しています。そしてCMSのテンプレートとDreamWeaverのテンプレートの最大の違いは、CMSだとプログラマーが変更しなければならないのに対して、DreamWeaverのテンプレートはウェブデザイナーが変更できる点です。
  2. CMSに機能拡張をすれば、価格などの情報をデータベースから引っ張ったりできますので、常に最新の価格情報を保証することができます。しかしこれはまず非常に高価です。そしてカスタムなので業者依存がますます強くなります。このあたりは私たちが新しく用意しているサービスを利用すると、うんと安くできます。業者依存も生じません。

DreamWeaverの場合、一番のメリットはこれがデザイナーの標準ツールだということです。デザイン力が高い人材を探すとき、あるいはウェブサイト担当者を変更しればならないときにはこれは凄く重要です。確実に、簡単に、そして安価に引き継ぎが可能です。

もしもそれでもCMSを利用するのであれば、業者依存を生じさせないために、広く普及しているオープンソースのCMSを利用するべきだと考えます。世の中で圧倒的に普及しているCMSはWordPressですので、原則としてWordPressが第一候補です。明確な理由(Wordpressで実現できない機能)がない限り、それ以外のCMSを使うべきではないでしょう。

もちろん「CMSを使うべきかどうか」はケースバイケースで変わります。例えばこのブログはWordPressで動いていますし、Castle104のホームページもWordPressです。

気をつけなければならないのは、「業者は業者依存を増やしたい。なので彼らはCMSを導入したがる」という点です。

ウェブデザインからサイドバーをなくしていこう

2013年1月に[iPad専用にデザインするということはどういうことか](https://naofumi.castle104.com/?p=1925)というブログを書き、その中でPC用のウェブデザインが実は無駄だらけだと述べました。そしてその無駄を省いていくことで、iPadに適したウェブサイトが自然にできてくると議論しました。

先日、[Squarespace](http://www.squarespace.com/)でテンプレートを開発しているEric Anderson氏が、やはり[サイドバー不要論](https://medium.com/design-ux/167ae2fae1fb)を展開していました。

解決策として;

1. 関連リンクはブログポストの後に付ければ良い。
2. 検索窓はヘッダーかフッターに付ければ良い。
3. アーカイブは専用ページに用意すれば良い。

このブログはまだサイドバーなしにしていませんが、Eric Anderson氏の述べていることは全くその通りだと思います。近々、サイドバーをなくしていきたいと思います。

オフライン(ローカル)で使えるWebサイトって何を指すのか?

HTML5にはアプリケーションキャッシュストレージなど、オフラインアプリケーションを実現するための機能が用意されていますが、そもそもオフラインアプリケーションって何なんだろうって考えてみたいと思います。なぜかというと、オフラインアプリケーションと一言で言っても、どこまで「オフライン」である必要があるのかに差があるからです。

まずWebサイトを分類したいと思います。

  1. 閲覧をメインとしたサイト: WikipediaAsahi.comなどの新聞サイトがこれに該当します。
  2. 個人用にカスタマイズしたコンテンツをメインにしたサイト: Facebook, Twitter, LinkedInなどがこれに該当します。
  3. データ入力や加工をメインにしたサイト: GmailGoogle Docsがこれに相当します。

以下、それぞれについて考えていきます。

閲覧をメインにしたサイト

1の閲覧をメインにしたサイトについてはオフラインへのアプローチは2通り考えられます。一つはサーバから帰ってくるHTMLをそのままキャッシュすることです。もう一つはAPIでデータをJSONなどの形式でダウンロードし、これをキャッシュすることです。そして画面に表示するときはJSONデータからDOMを作ります。

どっちを選択するかに関わらず、このようなサイトに共通しているのは、ブラウザ側ではModelを持つ必要が無いということです。保存する内容はページの内容だけですので、ModelはせいぜいPage一つです。わざわざクライアントサイドのMVCフレームワークを用意する必要がありません。

このようなサイトで一番大きな問題はデータ量ではないでしょうか。Wikipediaであればすべてをローカルに保存するわけにはいかず、一部だけをダウンロードすることになります。それでも数千ページを保存すれば相当な容量になります。このデータを効率的にサーバから出力し、ブラウザ側で処理し、ローカルに保存していくかは簡単ではありません。

個人用にカスタマイズしたコンテンツをメインにしたサイト

実際問題、こういうサイトではオフラインの閲覧はほとんど実現できていません。例えばHTML5をやめてnative Appを開発していくということで話題になったFacebookのiPhone用アプリですが、オフラインで見られるのは以前に閲覧した内容のキャッシュです。先読みしてローカルにページを保存することはしません。したがってオフラインでやれるのは見直しだけです。

Twitter, LinkedInのiPhone用Nativeアプリも同じです。

ただ「いいね!」などはオフラインでも押すことができて、オンラインになるとその変更がサーバに送られることを期待しましたが、テストしてみたところ反映されていませんでした。

もともとこのようなソーシャルネットワークアプリはタイムラインを中心としたUIなので、タイムラインさえキャッシュすればほとんど用が足りると発想をしているのだと思われます。いずれにしてもオフラインではたいして使えないのが現状です。

このようなサイトを実現する方法は「閲覧をメインにしたサイト」とよく似ています。サーバから帰ってきた内容をキャッシュすれば良いのです。ただし内容が変更されることが頻繁にあるので、ネットワーク接続があれば積極的にデータを更新することになります。

データ入力や加工をメインにしたサイト

GmailやGoogle DocsはもともとデスクトップのemailクライアントやMS Officeをウェブ用に作り替えた製品であり、完全にオフラインで動作するようにGoogleがかなり開発をしてきた製品です。

これらの特徴は、様々に加工した後に作られるドキュメントが非常に独立していることです。デスクトップのアプリであればドキュメントはファイルシステム上のファイルであり、属性としてはタイムスタンプやフォルダー名、ファイル名、そして権限ぐらいです。Facebookの書き込み、コメント、いいねと違い、複雑なリレーションがありません。

このようなWebサイトはデータを加工するのには複雑なJavascriptを使う必要がありますが、一方でサーバとやりとりするデータはかなり境界がはっきりしていて単純です。この際に便利なのがクライアントサイドのJavascript MVCフレームワークです。ブラウザの中で複雑な処理が行われデータが加工されていきます。上述の「閲覧をメインにしたサイト」「個人用にカスタマイズしたコンテンツをメインにしたサイト」と異なり、ブラウザはデータに対して受け身ではなく、積極的にデータを作り、改変します。ブラウザ内での処理が複雑になりますので、MVCフレームワークの必要が出てきます。

このように、どのようなWebサイトでオフライン閲覧を実現しようとしているかによって、どこまでやるべきか、どこまでやれるかがかなり分かれます。

さて私が考えているのはソーシャル機能を持ったオンライン抄録集ですので、1, 2の機能を併せ持ったものになります。それを実現するために何が必要かを考えていきます。

ソーシャル機能を持ったオンライン抄録集ではブラウザ側のMVCは必要ない

オンライン抄録集は根本的には「閲覧をメインにしたサイト」ですので、各ページのデータをローカルに保管すれば十分です。ソーシャル機能については「個人用にカスタマイズしたコンテンツをメインにしたサイト」と同じように考えますので、普通に考えればオフラインでソーシャル機能を提供する必要はありません。したがってサーバのレスポンスをキャッシュするアプローチで十分です。

もし一歩先を行って、「いいね!」などをオフラインでも可能にしようと思うと、ブラウザの中にModelを作っていく必要が出てきます。しかしModelの数は少なくて済むと思われますので、全面的にクライアントサイドMVCを導入するのは無駄だと考えられます。

残念ながら適当なフレームワークがない

残念ながらこういう目的のJavaScriptフレームワークは存在しないのが現状です。Sencha Touchはローカルにデータを保存することができますが、完全なクライアントサイドMVCフレームワークなので今回の目的に合いません。

jQuery Mobile, jqMobiなどはサーバ側にHTMLの生成を任せているフレームワークで、クライアントサイドにModelを持つ必要の無いものです。しかし主眼はNativeアプリと似たようなUIをブラウザ内で実現することであり、ページをローカルにキャッシュする機能はありません。

オフラインでも使えるwebサイトを作るために

現在取りかかっているプロジェクトと関連しますので、ローカル(オフライン)でも使えるWebサイトを作るためのポイントをまとめてみました。

データをため込むにはHTML5のアプリケーションキャッシュとストレージを使う

ローカルで使えるWebサイトを作るには、データをローカルに保管することが必須です。HTML5では保管方法がいくつか用意されていて、大別するとアプリケーションキャッシュストレージになります。

静的なファイルはアプリケーションキャッシュで

完全にローカルで使えるWebサイトを作るためには、HTML5のアプリケーションキャッシュを使う必要があります。最初に問い合わせるURLはこのアプリケーションキャッシュに入れます。これをやらないと、URLを入力した時点でブラウザはサーバに問い合わせをし、ネットワークが繋がらなければエラーになります。

アプリケーションキャッシュは便利ですが、例えば1ページでも更新されるとキャッシュ全体をクリアしなければならないなど、頻繁に更新される内容には不向きです。あくまでも静的なファイルに使用します。

ただし、Webサイトのトップページはしばしば動的なページです。更新情報やお知らせなどを掲載することが一般的です。そうなると最初に問い合わせるURLは静的ではなくなります。

この問題を解決するためには、最初に問い合わせるURLではウェブページのフレームワークだけを返し、更新情報などはストレージから読み込むんで、Javascriptで埋め込むことになります。

HTML5 History APIは使わない

Javascriptを使ってページ内容を更新する場合、backボタンやブックマークを正常に動作させるためにURLを書き換える必要があります。その方法はURLのハッシュフラグメントを書き換える方法と、HTML5のHistory API (pushStateなど)を使う方法があります。

pushStateを使うとハッシュフラグメントではなく、URLの本体を変更します。この方が従来のWebと親和性が高いという理由などから、現在ではHistory APIを使った方法が推奨されています。

しかしこれはローカルWebアプリには使えません。最大の理由はアプリケーションキャッシュがうまく使えないからです。

例えばhttp://my_server.com/をアプリケーションキャッシュに保管しいても、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2というURLにアクセスしようとするとアプリケーションキャッシュのページは使われません。通常通り、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2をサーバに要求します。

それに対してhttp://my_server.com/#!path_to_page_1, http://my_server.com/#!path_to_page_2のようなURLになっていれば、まず最初にアプリケーションキャッシュのhttp://my_server.com/が呼び出されます。そのあとpath_to_page_1path_to_page_2のコンテンツはストレージから読み込むか、あるいはAJAXでサーバに問い合わせることができます。

その他、Androida 4.0のデフォルトブラウザがHistory APIをしっかりサポートしていないという問題もあります。

ストレージの選択

ストレージはいくつもAPIが用意されていますが、ブラウザのサポートを考慮すると実際に使えるものは限られています。

一番広くサポートされているのはwebStorageです。これは非常に単純なkey/value型のストレージです。IE8でさえサポートされています。しかしwebStorageの大きな問題は容量の少なさです。Safariだと5Mbyteが上限です。これでは日本分子生物学会の抄録などは収まりません。経験的に数百演題の学会であればwebStorageでも十分ですが、1000を超えたらwebStorageでは不十分です。

次にサポートされているのはWeb SQL Databaseです。50M byte以上のデータをため込むこともできます。またSQLでクエリが書けるので、いろいろな使い方ができます。ただしWeb SQLは今後は規格を更新しないことが決まっています。Web SQLの大きなポイントは、FirefoxやIEなどのデスクトップ用ブラウザではサポートされていないものの、スマートフォンのブラウザで広くサポートされている点です。

最も期待されるのはWeb SQLに変わるIndexed DBですが、こっちはまだサポートするブラウザが少なく、特にスマートフォン用ブラウザではサポートされていません。

上記を考えると、ストレージとしては第1にWeb SQL Databaseを優先させ、サポートしたいブラウザや保管したいデータ量を考慮してIndexedDBもしくはwebStorageをサポートするのが妥当な選択だと言えます。

まとめ

完全にローカルなWebサイトを作るために必要なコンポーネント、どのHTML5テクノロジーを使うかの話をしました。特に重要なのは、一般的に推奨されている History APIは使えないということだと思います。

もちろんコンポーネントを選定しただけではまだまだ話は始まったばかりです。解決しなければならない問題はたくさんあります。これについてはこれから少しずつ紹介していきます。

解決しなければならない問題のリスト

  1. ハッシュフラグメントのフォーマット
  2. out-of-dateになったページをどうやって更新するか
  3. データの同期をどうやって行うか

iPad専用にデザインするということはどういうことか

iPad miniの登場でタブレットに最適化されたウェブサイトが必要になってきました

スマートフォンとiPadなどのタブレットが急速に普及したため、同じコンテンツを異なるスクリーンサイズに合わせてデザインする必要が出てきました。その中でもスマートフォンは先に普及し、またスクリーンサイズがPCと大きく異なるため、スマートフォン専用のサイトを用意したり、あるいはスマートフォン専用のアプリを用意することが多くなりました。

一方でiPadなどのタブレットでは事情が複雑です。

iPadのSafariは横幅が980pxのウェブサイトであれば縦向きの画面に納められるようにデザインされています(実際のピクセル数は768pxしかないのですが、980pxのサイトを768pxに圧縮します)。しかしこれだとリンクが非常に小さくなるので、リンクをタップするときにかなり神経を使います。AppleのiOS Human Interface Guidelinesではボタンのサイズを44px x 44px以上にすることが推奨されていますが、それよりもずっと小さくなります。

今までの10インチのiPadであれば、それでも何とかなりました。神経を使えばリンクをクリックすることができました。しかし7.9インチのiPad miniになるとさすがに難しくなります。画面の拡大縮小をしないとPCウェブサイトのリンクはクリックできません。

そろそろタブレットに最適化されたウェブサイトが必要になってきたのではないでしょうか。

タブレット専用のサイトを作るべきか、それともPC用のウェブサイトを作り替えるべきか

国内のスマートフォンの普及率はまだ50%以下です。したがってすべてのユーザをカバーするようなウェブサイトを作るためには、1) PC用, 2) スマートフォン用, 3) フィーチャーフォン用のウェブサイトが最低でも必要になります。さらにタブレット専用のウェブサイトを作るとなると4種類のウェブサイトを作ることになり、かなりつらくなってきます。

やはりタブレット専用のウェブサイトを作るよりは、PC用ウェブサイトと共用のものが作れれば楽です。そうなると7.9インチのiPad miniでも快適に見られるようなPC用ウェブサイトを追求することになります。

PC用のウェブサイトは無駄だらけ?

以下に示すのはasahi.com用のiPadアプリの一面です。

Skitch

以下はPC用ウェブサイトのトップページです(赤枠は私が付けました)。 Skitch

内容を比較するとiPadアプリの一面の内容はPC用ウェブサイトの赤枠だけです。ざっと見たところ、PC用ブラウザの画面の1割程度だけがiPadアプリの一面に使われています。PC用ウェブサイトの赤枠以外は、iPadアプリではすべて省かれているのです。

なぜiPadアプリではPC用ウェブサイトのコンテンツの9割を省くことができたのでしょうか。PC用ウェブサイトのトップページコンテンツの9割は無駄なのでしょうか。

PC用ウェブサイトはナビゲーション用リンクが異常に多い

先ほどのPC用ウェブサイトのトップページを内容ごとに色分けしました。

赤がiPadアプリの一面にもあった、いわゆる「新聞の一面記事」です。青はナビゲーションです。カテゴライズしたナビゲーションではなく、「もしかしたらこんなことに興味があるんじゃないかな?」ということでリストアップされたものです(カテゴライズしたナビゲーションはトップメニューにあります)。そして緑が広告です。さらに黄色は他のページ(この場合は社会欄)の抜粋リンクです。

2012 12 30 18 24 asahi com PC web

こうしてみると青のナビゲーションリンクが異常に多いことがわかります。また下にスクロールしていくと、黄色の他ページ抜粋リンクが延々と続きます。

青のナビゲーションリンクの目的は、人気記事を前面に出すことです。少しでも読者におもしろがってもらえる内容を早めに見せておくためのリンクです。

黄色の他ページ抜粋リンクは、トップメニューを経由しなくても、下にスクロールするだけで他ページの内容が見られるようにした工夫です。クリックするよりもスクロールした方がユーザは楽だろうという配慮です。これもナビゲーションリンクの一種です。

iPadアプリにはこういう青と黄色のリンクに相当するものがほとんどありません。

PC用ウェブサイトもナビゲーションリンクを減らせば簡単にiPad向けになる

PC用ウェブサイトのナビゲーションリンクを省き(青と黄色のリンク)、そのページ固有のコンテンツに絞ればフォントサイズを大きくすることができ、iPad miniでも簡単に操作できるものになります。そのためには以下のことを考慮すれば良いはずです。

  1. トップナビゲーションメニューを経由したページ切り替えを楽にし、黄色の他ページ抜粋リンクを不要にする。
  2. 青色のリンク(ランキングなど)は別のページにまとめ、これもトップナビゲーションメニューから簡単に移動できるようにする。

トップナビゲーションは必要か

実はトップナビゲーションメニューも不要かもしれません。Asahi.comのiPadアプリではトップナビゲーションメニューは前面に出さず、実際の新聞の紙面のページを送る間隔で、1ページずつ、すべてのページを切り替えていくのがメインのナビゲーション形式です。ページ切り替えは素ワイプジェスチャーで行います。

このナビゲーションは全体を眺めることに重点を置いています。ナビゲーションメニューの中から特定のカテゴリーを選んで、そのページに移動するのではなく、すべてのページをざっと眺めながら興味を引いたコンテンツを見るのに向いています。このナビゲーションをうまく実装できればメリットは明確です。いままでコンテンツをつまみ食いしていたユーザが、全体を眺めてくれるようになるのです。

トップナビゲーションを無くしたインタフェースを実現するためには、2つのことが必要です。

  1. 素早くて滑らかなページ切り替え
  2. 大きくて目立つ見出し

このうち2番目の大きな見出しについては、各ページの余計なコンテンツ(主にナビゲーションリンク)を減らせば実現できます。しかし1番目は現在のウェブサイトの作り方では難しいところがあります。今のウェブサイトはロードするのに時間がかかりすぎるからです。逆に言うとページのロード時間を十分に減らすことができれば、トップナビゲーションを無くしたウェブサイトのデザインは実現可能になってくるかも知れません。

現在のウェブページのロードを早くするためには

iPadアプリはまず最初にすべてのコンテンツをダウンロードするので、ページ内容はすべてローカルに保存できます。だからページの切り替えが非常に素早くできます。HTML5にはブラウザ内のデータをため込むための方法がいくつか用意されていますので、これを使うとページ切り替えがかなり早くできます。

またページをロードするのにかかる時間の大部分は、実はコンテンツではなく、JavascriptやCSSだったりします。このあたりも要改善です。

直感的なページ切り替えの操作

今までのウェブサイトはページを続けてざっと眺めるのに適したUIを用意してきませんでした。ページ切り替え用のボタンを用意するものはありましたが、ボタンは小さく、マウスを移動させてクリックするのは面倒でした。それに対して、iPadアプリで使われるスワイプジェスチャーは非常に直感的で、簡単にできます。同じぐらい簡単な操作をPCでも実現できればトップナビゲーション不要なUIが作れるかもしれません。

まとめ

以上、いろいろな話をしました。まとめると以下の通りです。

  1. iPad miniの登場で、PC用のウェブサイトであってもiPad miniに最適化する必要が出てきました。
  2. iPad miniに最適化するときに重要なのは、無駄なナビゲーションリンクを減らすこと。
  3. ナビゲーションリンクを減らす中で、トップナビゲーションメニューの役割すら再検討するべきです。
  4. ナビゲーションリンクを減らすことと、ページロードのスピードを上げることは密接に関わっています。必要に応じてHTML5のデータ保存機能を活用しながら、ページロードスピードの向上に努める必要があります。

Webのフォントサイズについて

iPadのSafariはPC用のWebサイトがストレス無く閲覧できるようにデザインされていて、実際問題としてかなりその通りになっています。しかしiPad miniの登場で状況はかなり変わりました。iPadよりも画面サイズがかなり小さくなっていますので、現存のPC用のWebサイトは見づらくなっているのです。iPadだったら画面の拡大縮小をしなくても無理なく見られたものが、iPad miniだと拡大縮小が必要になってきたのです。

こうなると、PC用のWebサイトであってもフォントサイズを大きくし、PCからiPad, iPad miniのどれで見てもストレス無く閲覧できるようにした方が良さそうな気がしてきます。これについて、いくつかのポイントを挙げておきます。

  • iPadは縦向きで使った時が一番感動的に良いです。PCの画面は横長ですが、印刷された本は縦長です。目の動きの負担を考えると、各行の横幅は比較的狭い方が楽で、縦長の方がやはり読みやすいと思います。したがってiPad向きなデザインを考えるとき、特別な事情がない限り、縦向きでの使用を一番重視することになります。
  • iPad2, iPad miniの画面の縦向きの時の横幅は768pxです。一番大切な文字を読むことに関してはフォントは自動にスケールするので、実際のピクセル数はそれほど気にしなくて良いかも知れません。しかし768pxがどういう数字かはある程度考えた方が良いと思います。またiPad Safariは最大で980pxのWebサイトを自動的に縮小して768pxの実画面に納めます。最近のWebサイトは横幅が1000px以上のスクリーンを想定していますが、これらはまず第一にiPad Safariで見ると横にスクロールする必要があります。自動縮小無しiPad Safariでページを表示するためには、横幅を768pxにする必要があります。
  • Retina Displayによってフォントが鮮明になり、小さいフォントでも読みやすくなります。しかし人間の指は小さくなりません。リンクやボタンはretina displayであっても大きくしておかないといけません。
  • ボタンを快適に押すことができるサイズはAppleのiOS Human Interface Guidelinesによると44px x 44pxだそうです。例えばiPad non-retinaの実験 (横幅768px)。これはかなり大きくて、Webページのリンクは通常はテキストのフォントサイズ程度なので、前後の行間があることを考慮してもフォントサイズは15pxは最低欲しいということになります。しかし多くのWebサイトでは12px程度のサイズを使っているので、ボタンは快適に押せません。さらに横幅は1000px程度なので、これよりも20%程度画面は縮小されています。つまり既存のWebサイトのデザインでは拡大縮小しない状態ではリンクは快適に押せないのです。
  • PCの画面も最近は高解像度化が進み、画面サイズが小さくなっています。例えばMacBook Airの11インチは1366px x 768pxの解像度です。2001年から発売された白いiBookは12インチのディスプレイで1024px x 768pxだったので、同じpxサイズの文字が25%程度小さく表示されていることになります。やっぱり字が小さくなった分、読みにくくなっています。

こういう現状を考えたとき、PCのウェブデザインを考え直していった方が良いのでは無いかと思います。高解像度のノートPC画面に合わせる意味でも、iPad(特にmini)に合わせる意味でもフォントサイズを大きくしてリンクを大きくし、ボタンも大きくしていく必要があるでしょう。画面に一度に表示できる内容は少なくなりますが、現状のWebサイトの大部分はナビゲーションや広告をたくさん表示しているだけなので、工夫次第で対策が可能なはずです。

検索フォームはGETにするべきかPOSTにするべきか

GETの利点と言えば、

  1. 検索結果をブックマークしたり、URLをコピーしたり、リンクを作ったりできます。POSTを使っている場合は、検索トップページにしか移動できません。
  2. アクセスログにクエリーが保存されますので、どのような条件で検索されたかを後で分析することができます
  3. GETはプロキシサーバでキャッシュされますので(キャッシュが恩になっていれば)、サーバへの負担が減らせます

ということで僕は圧倒的にGETにするべきだと思いますが、世の中のウェブサイトを見ると、POSTを使っているウェブサイトがかなり多いです。

W3Cでも

  • Use GET if:
    • The interaction is more like a question (i.e., it is
      a safe operation such as a query, read operation, or lookup).
  • Use POST if:
    • The interaction is more like an order, or
    • The interaction changes the state of the resource in a way that
      the user would perceive (e.g., a subscription to a service), or
    • The user be held accountable for the results of the interaction.

となっていますので、GETを使った方がいいと思いますが。GoogleやYahooもGETを使っています。

ということで、皆さんにお聞きしたいのですが。
POSTを使った方が良いというケースはどのようなケースでしょうか?

ちなみにバイオのウェブサイトで調べてみました。

GET派

POST派

ごちゃ混ぜ派

  • BioCompareのAntibody SearchここはほとんどのパラメータはGETで送っていますが、メーカーごとの絞り込みをするとき、そこだけはPOSTになります。

バイオ百科で抗体検索:僕が使いにくいと感じるところ

以前のブログで、バイオ百科の抗体検索が使いにくいとお話しました。

僕もいちおう科学者の端くれですので、方法および結果をちゃんと紹介し、皆様も追試できるようにしました。実際に僕が問題にぶち当たっているところをビデオにしましたので、ご覧ください。

収益モデルがウェブサイトの使い勝手を決める例:バイオ百科

理想の抗体検索システムを追求した新「まとめて抗体検索」サービスを始めましたので、ぜひご利用ください。

またこの記事を含め、ライフサイエンス研究用製品メーカーのウェブサイトのあるべき姿について書いた記事を特集ページにまとめました。あわせてご覧ください。

アップデート
バイオ百科で僕が実際に抗体を検索して、使いにくくて困っているビデオをアップロードしました。

バイオの買物.comを含め、ウェブサイトの運営資金は広告収入を当てにしていることはとても多いです。

優れてウェブサイトを作り、多くにユーザが訪問してくれれば、広告収入が増えるという形です。

しかし広告料金のプラン(つまり収益モデル)を上手に設計しないと、ユーザにとって優れたウェブサイトが作りにくくなることがあります。ユーザの要望に応えるウェブサイトにすることと、収益を得るということが、互いに矛盾するケースが生まれてしまうのです。

その例として、「バイオ百科」というウェブサイトを見ていきたいと思います。

バイオ百科は抗体メーカー(商社)数社の製品をデータベースに登録し、限定的ではありますが、横断的な検索を可能にするウェブサイトです。特に抗体を探すときに有用です。登録しているメーカーが少ないので、BioCompareの抗体検索に比べれば抗体の網羅性は低いのですが、コスモバイオとフナコシの抗体が入っているので、小さいメーカーはかなりカバーされています。

しかしこのサイトで非常に残念なのは、検索インタフェースの使い勝手です。

「CD133」で検索を行った例で解説します。

biohyakka1.png

まず気付くことは、製品が全くランダムに並んでいることです。製品名で見ても、メーカー名で見ても、包装サイズで見ても、価格で見ても、全く何で見てもランダムに並んでいます。
並べ替えるには再度検索を行う必要があるのですが、検索条件のメニューは以下の通りです。

biohyakka2.png

ユーザが一番望むであろう「価格順」というのが無いのです。

どうしてランダムに製品を並べるのか。どうして価格順に表示させないのか。

さてここからは想像になりますが、ユーザにとって不便なインタフェースのままになっている理由を考えたいと思います。どうしてバイオ百科は不便を承知で、ランダムな表示順にしたり、価格順の並べ替えを用意しなかったりしたのか。

製品を掲載するにあたり、バイオ百科ではまず比較的高額なセットアップ費用を支払う必要があります。そして小額ではありますが、毎月の固定料金を支払います。

僕はこの料金システムがバイオ百科の自由を束縛し、ユーザ本意のウェブサイトを作りにくくしていると考えています。

まずは高額なセットアップ費用です。高額な費用を支払った以上、広告主であるメーカーはバイオ百科に対して強い発言権を持つようになります。自社に都合の悪いサイトの改良をしようとすれば、拒否できるだけのパワーを広告主は持つことになります。すべての広告主が納得するような改良は簡単にはできないでしょうから、サイトの改善スピードが遅くなってしまいます。

一方、もしバイオ百科がセットアップ費用を取っていなかったとします。そのとき、広告主に都合は悪いけれども、ユーザにとっては便利な機能(例えば価格順の表示)を追加しようと考えたとします。その結果として一部の広告主の反感を買ったとしても、その広告主に外れてもらうようにするだけでいいのです。文句を言う広告主の製品は載せてあげませんよと。広告主もセットアップ費用を支払っているわけではないので、損はありません。それに対して広告主がすでに高額なセットアップ費用を支払ってしまっていると、広告主はもとをとろうと考えますので、簡単には外れてくれません。広告主は引き下がらずにしつこく文句を言う可能性がありますし、仮にそうではなくても今後のビジネスにしこりを残すことになります。

月額の固定料金も問題です。広告主は一定の費用を毎月支払うわけですから、各広告主の製品をなるべく均等に表示する義務が発生します。メーカーのアルファベット順に並べてしまうと、いつも同じ会社が上位に表示されてしまうので、広告主間で不公平が生まれます。製品名のアルファベット順に並べても、同様の問題が発生する可能性があります。価格順に並べた場合は、安売りメーカーが優先して表示されるので、高い品質とブランド力を持っていて価格を高めに設定しているメーカーは広告を出してくれなくなります。

バイオ百科で製品をランダムに表示しているのは恐らくこのためでしょう。

一方GoogleのAdwordsのように、訪問者がリンクをクリックする回数に応じて課金するシステムであればこの問題はかなり軽減されます。並べ替えの関係でたくさん表示されるメーカーは多くの広告費を支払いますし、少ししか表示されないメーカーは広告費をあまり支払いません。したがって広告主間の不公平感は生まれません。価格順に並べても問題ありません。真に高い品質とブランド力を持っているメーカーであれば、検索条件で指定してもらえるはずですから、表示してもらえるはずです。検索条件で指定してもらえないメーカーは、実はブランド力が思ったほど無かったという、それだけのことです(もちろん、ウェブサイト側は検索条件でメーカーを指定しやすいように工夫していることが前提ですが)。

また月額の固定料金の場合は、バイオ百科自身のインセンティブが低くなることが言えると思います。ユーザにとって便利なサイトを作ることよりも、広告主にとって都合のいいサイトへと重点が移ってしまう可能性があります。事実、今回紹介したもの以外にも、バイオ百科にはびっくりするような不便なところがありますが、なかなか改善されません(CD4を検索してみてください)。

以上、自分のバイオの買物.comを棚に上げて、他のウェブサイトの悪口を言ってしまいました。でも言いたかったのは悪口ではありません。

言いたかったのは、収益モデルをよくよく考えておかないと、広告主に自社の自由を束縛されてしまうということです。そして本当の顧客であるウェブサイト訪問者からフォーカスが外れてしまって、使いやすいウェブサイトが作れなくなってしまう可能性がありますよということです。

そういうことに注意しながらデザインしているバイオの買物.comの収益モデルについては、また別の機会に紹介したいと思います。