webUIデザイン考

ウェブサイト開発

TOP
Old Archives
webUIデザイン考

序

私はかなり前からデザインの仕事もしているし、評判も上々。日頃デザインの勉強もしているし、自分でも悪くないと思っている。

けれど、デザインに一家言あるみたいなタイプの人からは評判が悪いし、そもそも私のウェブデザインはウェブデザインの常識に則っていない。

とはいえ、私のほうが正しいと主張できるだけの根拠はちゃんとある。なにより、「本当に正しくデータを取ったか?」である。

なお、ここで出てくる様々な実験データは、なにかから引用しているわけではなく、私が自分で実験・聴取しているものである。

ほんとかよ、それ

直感的であるよりも経験的である

「ひと目見てわかることよりも、慣例に則っていることのほうが大事」という主張なのだけど。

絶対ウソだ。

デザインする側は全く分かっていないけれど、 ハンバーガーメニューってみんな知らないよ。

ハンバーガーメニューを理解できるのはそれなりにコンピュータに通じている人であって、私が話している限りだとスマホネイティブな世代の人を含め、ハンバーガーメニューは無視する人のほうが圧倒的に多く、「ハンバーガーメニュー」という言葉はまず知らないし、それがメニューボタンだという認識もない。

実際、私が手がけたサイトのログをみる限り、

他のナビゲーション手段があるかどうかに関わらず、ハンバーガーメニューはほぼ押されていない
ハンバーガーメニュー経由でしかアクセスできないようになっているものには人がこない
常にハンバーガーメニュー経由でナビゲーションするようになっていると離脱率がものすごく上がる

なので、ハンバーガーメニューはごく一部のわかっている人だけのものだという認識で良いはずだ。

動的表示

HTML5だ、動的表示だ、JQueryだみたいな話は当たり前のようにされるけど。

ユーザーは望んでないぞ、それ。

これに関しては明確な不満が聞かれることは稀だが、「重い」という形での不満になったり、あるいはちゃんと説明すると(容量が大きいことによってどのような影響になるのかといった話)「それはいや」という回答が返ってくる。

ごてごてと重くして、CDNで速くするくらいなら、最初から軽くしておくべきだ。

アニメーションで取られる時間も明確にUXを悪化させており、実際にその仕様が異なるページを体験してもらう実験では、非常に速いアニメーションが最も好まれ、アニメーションを認識できる程度のアニメーションがあるくらいならば一瞬で実行されるほうがずっと良い、ということがわかる。

遅延表示

記事の全文を表示せず、ユーザーアクション、スクロールに従って読み込むのは必須要求であるように言われるのだが、聴取してみると コンピュータの熟達度によらず極めて評判は悪い。

これは、スクロールの判定の問題による。

まずPCではEndキーを押してのスクロールに対応できない。そもそもEndが末尾にならない。実装方法によっては、PgUp/PgDnのスクロールの判定をしないから、私のようにキーボードでナビゲーションしている人をはじくことになる。

さらにスマートフォンのナビゲーションでも、弾いたり反射させる場合に対応できない。

そもそも、大抵の遅延ロードが、私が普通に読んでいても途中でなんども読むのを止めさせられることになる。「続きを読む」も何の節約にもならないので大嫌いだ。

この話は人にすると多くの場合強い共感を得られる。極めて劣悪な体験である。

ちなみに、私は遅延表示するサイトはよほどがない限り、読むのをやめる。

実験と聴取と経験

ハンバーガーメニューは誰も使わない

前述のようにハンバーガーメニューは誰も押さない。

ちゃんと「アイコン+ “メニュー”の文字」になっていると押してもらえる。

英語だと使わない

“MENU”とかいう英語ですらも、英語で書くと使ってもらえなくなる。ところが、なぜか“HOME”だけは英語で書いても全く影響がない。

back to HOMEに関しては、「トップページ」と書くよりも「HOME」と書いたほうが理解されやすい。

「HOME」と「ホーム」は誤差の範囲。

最近のソシャゲのUIはこのあたりよくわかってる。

アイコンだけだとやはり使わない

UX面で見ればラベルは絶対必要。デザイン的にはイヤ。

アイコンだけでがんばる場合は、それを押す必然性がないといけない。これはハンバーガーメニューでも同じだし、ハンバーガーメニューはアイコンのデザイン自体が直感的じゃないので、よりハードルは高い。

SEOより情報価値

最近はGoogleがSEOに屈した感があるが、結局情報価値がある内容を書いているとその情報を必要とする人はその情報を頼るしかないので、あまりSEOスペシャルみたいなものは必要ないと考えている。

内容さえあれば、変なことするよりも、人間的にも機械的にも意味がきちんと伝わるように書くのが長期的に見て色々と得だ。

内容が重複する場合は基本的に情報価値はないとみなされるが、もちろんより適切にまとまっているなど情報の扱い方によってもその価値は変わってくる。

結局、SEOのことを気にする時間があるならば、少しでも良い記事を書くために心を砕くことに時間を使うべきだと思う。

明朝体とウェブフォント

「長文には明朝体が良い」というのは、ウェブには全然浸透していない、出版関係の常識だけれど、これに関しては私は特別には同意しない。ゴシック体だから長文が辛い、ということもない、というのが私の意見だし、むしろウェブではみんなゴシック体を見慣れてるからゴシック体のほうがいいんじゃないかとすら思う。

ただ、文章に対する没入という観点からいうと明朝体のほうが良いようだ。

実際に、難しい長文を読むにあたって、どのような書体が好ましいかという実験をしたところ、最も良いのはUDアポロであり、アポロでもフォークでもタイポスでもスキップでもいいからアンチックでしょ、ということになる。ちなみに、ロゴたいぷゴシックは長文だとやや読みにくい。フリーフォントなら源暎ラテミンの評判が良い。

私はアポロの製品版をまだ持っていないので、今のところこの文章を書くのにはフォークを使っている(でも、ライセンス期限が近づいている…)が、フォークは実はそんなに読みやすくない(アンチックの中では)。とにかくアポロが読みやすい。次いで源暎ラテミン、あるいはラテゴ。元陽逆アンチックも読みやすいと評判。

こうしたゴシック体と明朝体の中間のフォントが最も読みやすく感じられる、というのは、まんま「明朝体のほうが読みやすいと言われればそうだし、ゴシック体が読みづらいと言われてもそうでもない」という感覚に直結しているのだと思う。

より漫画的なアンチック体(例えば源暎アンチック)もかなり読みやすい。そういうものなんだな、と思ったりする。

だから、可能ならウェブだってアンチック体で表示したい。だが、現実には難しい。

そもそも汎用の指定がserif, sans-serif, monospace, fantasy, cursiveの5つしかない。せめて丸ゴシックを指定できるようにしてほしいし、アンチック体を指定するなんて夢のまた夢だ。

システムフォントを指定することがどれだけバカバカしいかという話は、多分Chienomi読者なら耳タコだろうし、そんなことは絶対しないと私は信じている。

しかし日本語ウェブフォントなんていうのは死すべしである。大きくても100kBもない欧文フォントなら、まぁちょっと大きい画像1枚くらいか、許そうとなるが、源暎ラテミンなんて9MBもある。問答無用で動画ねじ込まれるようなもんである。通信容量は有料のものだし、人の通信容量を貪るんじゃない、となる。

だから制作者がコントロールできる部分ではないが、どちらかといえば長文読みの場合は明朝体のほうが良いのではないだろうか。 Androidでは明朝体が出ないということも踏まえた上で。

リーダービュー

リーディングという意味ではリーダービューはかなり理想的な状態であるように思われる。

ウェブデザイナたちがこれがユーザービリティだとごてごてしたデザインを押し付けた結果、CSSを除去し、本文だけを抽出する機能がブラウザに搭載されたというのは本当に笑える話だが。

しかし、リーダービューは私が聞き取った限りで使用しているという人を見つけることはできなかった。「知っている」という人は3割強。恐らくこの値は全体比からすればかなり高い。

リーダービューを前提にすることができれば、ウェブデザインは可読性よりもナビゲーションのしやすさに寄せることができるが、そうではないのでリーダービューのような可読性を目指すことになるだろう。

ちなみに、私のサイト(PureBuilder Simplyで書かれているもの)はいずれも綺麗に書いてあるのでリーダービューが効く場合は非常に読みやすくなるが、「はるかのおはなしのおはなし」を除けば元がリーダービューに近い見た目をしているため、効果はあまりない。一方、このChienomiはWordPressなので、リーダービューを使うとだいぶゴミを感じるが、余計なものが消えて読みやすくなる。

my designs

Mimir Yokohama

Mimir Yokohamaのデザイン自体は、もともとがWordPressページであり、なおかつWordPressのデザインを維持することからスタートしているため、基本的な形式はWordPressのデザインに準じている。

中央寄せコンテンツコンテナのレスポンシブ2カラムというのは、典型的なブログデザインといっていいだろう。

ただし、現在はしっかりと私のウェブサイトとしての工夫も盛り込まれたものだ。

Mimir Yokohamaのウェブサイトは、リテラシーが低い人が読む、という前提があるため、ユーザーに何かをさせるということは回避する方向である。知識がなく受動的であっても使えるようにという工夫だ。

基本的なところでは、Mimir Yokohamaは「経験則によってナビゲーションできるようにすべき」という主張を受け入れたものになっている。だが、構造的スマートさよりもアクセシビリティを優先し、同じナビゲーションが複数配置される構造だ。

ハンバーガーメニューの中身はメニューとTOCだが、これはサイドカラムにも搭載されている。重複させることでその人の直感がどちらに属してもカバーできるようにしている。では重複は2箇所かというと、実は3箇所である。TOCは記事よりも手前にも存在し、ナローモードでは下に行くサイドカラムではなく、記事手前に表示されるようになっている。

ロゴクリックでのback to homeや、破線アンダーラインでの辞書機能、lightboxなどは経験則的機能だ。その人のブラウジング経験によってはより便利に使えるわけである。

その他、本文を含めてとても説明的。どんなに丁寧に書いても読まない人は読まないのだが、デザイン的にはちゃんと説明されるべきだ。そういえば都営地下鉄の駅の表示に情報が欠落していて、結局わざわざ説明書きの張り紙をした、なんて話もあった。

はるかのおはなしのおはなし

はるかのおはなしのおはなしはウェブ縦書きのサイトである。世間的には、ほぼエロゲーの話をするサイトとして扱われている。

これはいくつかの実験を含んでおり、縦書きはその一部である。

もうひとつ大きいのはスケーラブルフォントサイズだろう。文字サイズがウィンドウサイズに依存しており、ウィンドウを大きくすることで大きな表示で読めるようになっている。

ただ、ブラウザの縦書き実装が相当にあまりて、ウィンドウリサイズにちゃんと対応しておらず、リサイズ時はリロードする必要があるとか、場合によってはカラム境界がおかしいなどの問題がある。 Android版Firefoxに至っては、以前はちゃんと表示できていたのに、今は完全に崩壊してしまっている。

正直なところ、私はあまり読みやすいとは思っていない。多分、JavaScriptでスクロールディレクションを変換し、行方向を20emなり30emなりに制限するほうが読みやすい。そして縦書きが別に読みやすくはないというのも感じてしまう。これはそもそもブラウザの縦書きエクスペリエンスがだいぶ悪いということに起因している。

リーダービューにすると横書きにできるのですごく読みやすくなる。

なるべく色々がんばろうとはしていて、例えば

小説のように読ませたいというのがあるので、ナビゲーションは意識に入らないようになっている。逆にナビゲーションしたいときに困るかもしれないが
電子書籍のような「めくり」に対応
日本語縦書きプロポーショナルメトリクスを採用

と、技術的にものすごくアグレッシヴ。商用サイトでは絶対できない。

実は「はるかのおはなしのおはなし」は布石であり、実験であった。

Harukamy’s Memoranda

Harukamy’s MemorandaはもともとJournal de Akiだったものである。その後、ここと分離してReason Essembleになって、リニューアルで一部分を残して新規サイトになった。

レイアウト自体はいまさら驚くものではない。構造的には4カラム構成であり、これは現代的というよりは、古のフレームレイアウトに近い。ナローウィンドウにおいては直列になる。

今さら見たことはないという人も多いかもしれない。

画面レイアウト上は昔っぽいが、中身としてはモダンに普通である。フッターをfixedにして、コンテンツコンテナを全幅にするだけである。

しかし、その配置に関してはちょっと特殊だ。

サイドカラムはあくまでメニューナビゲーションに過ぎない。現代的にはこれは上部に持ってくるものである。だが、上部に持ってきてしまうと実際には幅に対する制限がより厳しくなるので、サイドに持ってきた。

“Mimir Yokohama”はナビゲーションをサイドカラムとモーダルウィンドウから選択でき、「はるかのおはなしのおはなし」は常にモーダルウィンドウでナビゲーションを行うことで画面上からナビゲーションを追い出したが、“Harukamy’s Memoranda”では逆にモーダルウィンドウを持っていない。ナビゲーションはメインカラム上に存在し、ナビゲーションボタンとしてそれらへのリンクがある。

内部リンクは元位置に戻るのが戻るボタンで処理できるので非常にユーザビリティが高い。

見た目はちょっと不格好だが、恐らくこれが最善。むしろ情報をみるために任意位置までスクロールしなければならないサイドカラムへの記載のユーザビリティが低すぎる。

本文に関してはほぼ「なり」であり、コンテンツ幅が狭いほうがよければウィンドウをタイルすれば良いじゃない、という考え方になっている。ユーザーの意思に関係なく、ディスプレイの空間を無駄に使って一部分だけに目を集中ざて読ませるようなものは嫌いだ。ただ、ちょっとこだわりがあって欧文ウェブフォントになっている。これは、タイトルロゴにもサイドカラムにも画像は使っていないし、特にサイドカラムはかなりコンデンスドなフォントである必要があるといった都合による。このサイトは割とデザインコンシャスなので、本文フォントの欧文はGildaでウェブフォント。

ただ、ちょっと思ったのがChromium系だと内部リンクをクリックしたときにウェブフォントを取りに行っちゃう。これはちょっとおかしい。

また、フォントに関してはある程度のリテラシーを期待して「serifにしてあるから自分のブラウザを設定してよ」という形。設定しないままだと少し困ってしまう等幅フォントだけは軽く指定してある。

長文読みに適するようにserif指定であり、赤めの低コントラストになっている。このあたりは長年長文読みを研究してきた成果をぶちこんだ感じ。

デザインの話はAboutのページ内で解説している。

Reasonset

コンテンツはまだないが、ついにリニューアルされたReasonset。

Reasonsetとしては第三世代となり、私のメインウェブサイトとしては9代目になる。

これは、私が考える参照性がない長文読みのための、現在のベストだ。そして、それは「はるかのおはなしのおはなし」と“Harukamy’s Memoranda”を組み合わせたものになっている。

コンテンツレイアウトはウィンドウ幅によらず直列である。ナビゲーションも含めてすべて直列なセクション上にあり、“Harukamy’s Memonranda”からさらに1つ減った2つの内部リンクナビゲーションボタンがアクセスを提供する。

これは“Harukamy’s Memoranda”を発展させたものだが、フォントサイズの指定は「はるかのおはなしのおはなし」同様、ウィンドウサイズに基づくスケーラブルである。こちらもさらに発展させており、最小16pxでシームレスにスケールする。

基本的には縦長にしたときのほうが情報量は増えるので、表示を絞りたい人は横長、ざっと読みたい人は縦長と使い分けられる。もちろん、ブラウザウィンドウの空間は余すことなく使える。

内容に参照性がある場合は、一覧性が重要になってくるのでこのような表示は好ましいものではないが、Reasonsetの場合は先頭からじっくり読むタイプの記事に限られるため、この形式にした。このようなデザインを採用するとしたら、コラム程度では甘く、かなりじっくり読める小説サイトのようなものに限られるだろう。

フォント指定も完全にgenericなものに限られ、WINGでホストしているので“Harukamy’s Memoranda”以上に軽く、速い。フォントは全面的にSerif指定で明朝体。

要はリーダービューに近い、それ以上に「読む」ことを求めたものだ。軽めに読めるブログと違い、じっくりしっかり読むことを求めるスタイルでもある。コントラストは青系でやや低めになっており、任意にダークテーマも選択可能。ダークテーマになるとコントラストはさらに下がる。