Readouble.comのデザイン変更
タグ： Laravel
２０１７年６月、readouble.comのUIを更新しました。デザイナーズノートとして、書き残しておきます。
旧バージョン
もともと、Laravelの翻訳は私の技術的な記事のブログサイトである、kore1server.comで紹介していました。メジャーバージョンが上がるたびに、数ヶ月待った後に旧バージョンを消していたのですが、そのためリンク切れが他のサイトで起きていました。しかし、古い内容は役立たないことが多いため、それも利点であると思っていました。
LTSの話が持ち上がってきたときから、翻訳が残せるようにするように方針を転換することにしました。その際に、別サイトとしてreadouble.comを作りました。
できるだけ手をかけずに見栄えの良いものを作るために、CSSフレームワークを利用していました。当時お気に入りのGumbyフレームワークが開発停止を発表していたので、Foundationを利用することにしました。
当時はまだ、Googleがモバイル向け対応を検索で有利にすると発表していません。「通勤の行き帰りにドキュメントを参照することもあるだろう」ということで、最低限のモバイル対応をするつもりでした。左右からスライドインしてくるメニュー、Foundationではオフキャンバスと読んでいる形式のメニューが個人的にお気に入りでしたので、これが利用できることが主な選定理由です。
ただし、当時も現在も翻訳の利用者の多くはデスクトップからのアクセスです。モバイルやタブレットからの利用者は少ないのです。その、少ない利用者のためにパワーをかけるのは、理論的ではありません。Foundationはモバイル優勢のCSSフレームワークを当時は謳っていましたが、サイトの作成はデスクトップ優先です。
一部のフレームワークのドキュメントのように、（現在のバージョンのreadouble.com、Laravel翻訳ドキュメントも同様ですが）、ドキュメントのページ移動を行うために、メニューに全部の他のページリンクを横に広く並べるのは、自分自身の経験から避けたいと思っていました。私は「ここの項目にはあれが書いてある」と言う情報をメニューの文言だけでなく、項目の位置でも記録しています。特に、疲れたり眠くなったりし、認識力が低下している場合は、位置情報により重きを置いて選んでいます。
縦に一列ではなく、横にも複数列並べる場合、そのメニューに項目が追加された場合、当然それ以降の位置がずれます。すると、この位置による記録とずれてしまいます。項目の増減によるフラストレーションを何度も経験してきました。そのため、全体を見通せると言う視認性の良さよりも、縦に一列項目を並べることにしました。
しかし、Laravelには項目が多くあります。これを全部並べると面倒です。メニューの下にある項目をスクロールして選択するのも大変です。もともとLaravelのオリジナル英文ドキュメントは章（ページ）をいくつかのカテゴリーに分けてあります。メニューの構成はリポジトリのdocumentations.mdに記述してあります。このカテゴリーを利用することにしました。
readouble.com以前、kore1server.comのサブドメインとしてホストしていたときには、自前でアコーディオンメニューで表示していました。（ちなみに、当時のオリジナルの英文ドキュメントはカテゴライズしてはありますが、全項目をすべてベタに左サイドメニューとして表示していただけです。本家よりも先んじてUIは工夫してきました。）
ただ、アコーディオンメニューは階層を表すためにインデントするのが通常です。階層が深くなった場合、アイテムの表示域が狭くなります。（モバイルの話ではありません。デスクトップの話です。）
当時のFoundation4では、ドリルダウンメニューはサポートされておらず、サンプルで一例が紹介されていただけでしたが、これを採用しました。階層の下位、上位への移動をメニュー内のスライドで表す方法です。各階層でメニューの幅をフルに利用できます。
ただ、Foundationが提供する様々な機能は、当時も今も完全ではありません。現在のバージョン６ではかなり改善されていますが、バージョン４ではもっと完成度が低いものでした。項目選択するためにスクロールさせると、本文の位置がずれてしまったり、いろいろ対応しましたが、完全対応は面倒であったため、JSに関してUIの対応は、そこそこでやめてしまいました。
また、機能的にカラーテーマの切り替えを導入しました。私はある程度技術レベルの高いユーザーが利用するものと推定していました。気に入らなければ、ブラウザの拡張機能などを利用し、勝手に変更するだろうと思っています。ただ、そうした拡張の使いづらさも経験しています。個人的にSolaraizedのLightテーマを愛用しています。これに合わせるため、各種ソフトや拡張などを設定するのは、手間がかかる作業であることは理解しています。
当時のオリジナルのドキュメントは、色使いが派手で「目に染みる」ものでした。（それを鮮やかだと褒める人もいました。ただ、現在はより落ち着いた配色になっています。どうして派手になったのか、経緯と理由を推測することはできますが、あくまでも個人的な推論でしかないので、ここには書きません。）
CSSを切り替え式にすると、多少のオーバーヘッドがかかり、表示が遅くなります。（Googleが表示速度が検索ランクアップには大切と喧伝したため、表示に時間がかかるカラーテーマ切り替えは衰退しました。）その欠点があっても、テーマ切り替えを導入しました。未設定の場合、オリジナルのアイ・キャッチャーな（しかし、目に染みる）色合いを活かし（ただし、少しやら和げました）、利用者が望むのであれば、別の配色を選べるようにしました。長い時間、見続けることになるドキュメントサイトですので、読みやすい配色を選べるようにすることは、一理あるという判断です。
バージョン切り替えは先に実装していました。Laravelのドキュメントはバージョンが変わるたびに、新しい項目が追加され、わかりづらい、煩雑な部分が省略されます。そのため、以前のバージョンのドキュメントが理解に役立つのを知っていましたので、切り替えられるようにしました。
その後、翻訳がわかりづらい場合、誤っている場合は、原文を参照するのが手っ取り早いという経験から、翻訳対象となった原文も一緒にホストし、日米のページを切り替えられるようにしました。現在も翻訳元のバージョンの原文を示すために、ホストしています。ですから、英文は最新バージョンではありません。もし、最新バージョンの原文ドキュメントを読みたい場合は、laravel.comをご覧ください。
UI変更のきっかけ
もともと、LTSのリリースごとにUIに手を加える予定でした。６月以前にも変更しようかと思いましたが、Foundationがバージョンを上げると言う予告がされていたので、そこまで待つことにしていました。
ところが、UIをツイートでディスられてしまったので、Foundationの新しいリリースを待たずに、現在の自分にとって理想的な形式に変更することとしました。具体的にどこが悪いとかではなく、何もかも悪いという指摘で参考になりません。
ただ、いくら指摘をもらってもUIは個人的な好みがあります。そのため、すべての人にとって理想的なものはありません。readouble.comは自分の好みに合わせ、ドッグフーディングしています。つまり、自分で使って、自分で使いやすいようにしています。その上で、技術的なスキルを持つ方が利用すると言う前提で、多少便利にしようとしています。あくまでも自分で使いやすいものであることが前提なので、意見をいただいても反映する気は薄いのでご了承ください。
そして、次の変更予定は更に２年後です。現在、5.5LTSはまだリリースされていませんので、その次のLTSバージョンがリリースされるであろう２年後に、手を入れるつもりです。
現在のバージョン
２０１７年６月にリリースした新バージョンは、一からFoundation6.3を利用して作成しています。前のバージョンと見た目は似せています。
カラーテーマ
今回もカラーテーマを最小するかどうかを迷いましたが、利便性とやはり自分でSolarized Lightを使いたいと言う一心で実装することにしました。
Foundationが用意する環境の進化により、リソースコンパイルや不要部分の削除などが簡単にできるようになったため、CSSとJavaScriptファイルはかなり小さくなっています。前バージョンではコンパイルしていませんでしたが、今回のJavaScriptは２本にまとめています。旧バージョンでもCSS切り替えの影響を小さくするようにしていたため、テーマ切り替えを導入してもさほど遅い感覚はありませんでしたが、今回も同様です。
トップナビ
旧バージョンでも一番上にナビを表示していました。ドキュメントを読んでいる時に、「はて、今どのドキュメントを読んでいるんだっけ」と確認したい場合、タブでは情報が切れることがありますので、一目で判断できるように常に章のタイトルを表示してほしいと言う自分の欲求を満たした仕様です。ただし、旧バージョンより表示高さを小さくしています。アイコンも増えていますので、わずかにマウス操作がしづらくなってしまいましたが、その分キーボード入力に対応しました。
キーボードショートカット
マウス操作よりもキーボード操作を好む方がいらっしゃいます。たまに使いたい方もいるでしょう。たまたま、キーボードを触っているときもあります。実際は自分の利用方法がきっかけです。文章中のキーワードはブラウザのCTRL+Fかスラッシュで検索を行っていますが、ヘッダー単位で移動できたら便利だと言う考えから、今回キーボード操作もできるようにしました。
ヘッダー表示・移動
文書中のヘッダー項目の一覧と移動を導入したのは、もちろん前記の通り利便性もありますが、文章の構造をとらえておくと読解力が上がると言う理由でもあります。もともと、原文ドキュメントのページの最初には、ヘッダーレベル２と３の項目がリンクしてあります。
しかし、文章の一番はじめに構造を表すものがどんと置かれていると、視線を奪ってしまい煩雑です。そこで、前バージョンでは構造をなくして、平坦なリストに変換していました。
また、原文のドキュメントのヘッダーレベル２と３だけでは、構造を理解するには不十分に思います。その下の４レベルまで表示したほうが文章構造の理解には便利です。
さらに、長年翻訳している経験から、項目抜けやリンクの間違いなどが結構起きているのを知っています。これは手作業で行うべきことではありません。自動化すべきです。そこで、MarkdownからHTML変換時に、文章中の構造は削除しています。JavaScriptで動的にヘッダーを集め、構造を表示しています。
ヘッダーの移動の際、位置合わせは程よいように調整しています。基本的にトップナビの下の位置に移動先のヘッダーを表示しています。「現在、どのヘッダー下の文章を読んでいるのか」の判定も同じく、トップナビの下のＹ座標です。ヘッダーにより多少隙間があったり、狭すぎたりしますが、使用フォントや環境、それに利用者の感覚の違いがありますので、これも万人に合わせることは無理です。
メニュー構成
旧バージョンでは左はドリルダウンを使った階層をもたせたメニュー、右は同じものをベタに一列に並べたメニューにしていました。
新パージョンでは、左はドキュメントの章（ページ）をカテゴライズして複数カラムで並べています。カテゴリーを左一列、残りの列に書くページヘのリンク項目を並べました。大きくカテゴリー分けをすることで、私が過去に感じた「項目が追加・削除されるとアイテム全体の位置がずれ、視覚的な記憶が役に立たなくなる」ことによるストレスを軽減できます。
機能的に右と左のメニューの役割を分けました。左は章（ページ）の移動のみです。旧バージョンでは左右のハンバーガーメニューアイコンでしたが、機能を表す別々のアイコンにしました。
左から２つ目は前述のヘッダー構造の表示・移動のモーダルです。一番左が章の移動と言う大きな変化、２番めがヘッダーの移動と言う小さな変化になっています。
右側は切り替え系の移動と、設定です。移動と設定という２つの機能を一緒にすべきか躊躇しましたが、設定は一度指定したら変更する機会は少ないでしょう。あまり細かくアイコンを増やすよりも、まとめる判断をしました。
移動の項目のメインは、旧バージョンにもあったバージョンと言語の切り替えです。わかりやすい場所にしたので、使いやすくなったかと思います。
設定は旧バージョンのテーマ切り替えの他に、翻訳和文の指定、Largeスクリーン幅以上の表示部での表示方法、インデント幅、フォントの指定をできるようにしました。これらもブラウザの拡張機能などで、切り替えることができますが、手間を掛けずとも、個人の好みに合わせられるようにしました。
翻訳時の和文の指定は、たかが単語の和訳の指定ですが、こだわる人は存在し、それだけでディスってきます。本当の話です。
表示幅とインデントは、個人的な好みに合わせるためです。私自身は1remインデント、表示幅９０％が好みです。
フォントは、更新のたびに、その時点で最適だと思えるものを検索して指定していましたが、今回は探すのが面倒だったのと、そもそもフォント設定などにも普段から親しんでいる技術者向けのサイトですから、利用者が直接指定できればそれで済むと思い、直接指定してもらうことにしました。フォントの指定はドキュメント本文だけに適用されます。ナビやメニューの内容などには反映されません。しくじって表示できなくなることがないように配慮しました。しかし、全部に反映できるようにし、失敗したらクッキーを削除してもらうと言う方法も、利用者が技術者であると言う前提ならありかと思います。今回は、グリーンな技術者のために程々にしておきました。
右と左のメニューの閉じるボタンは奇妙な位置につけています。普通の感覚であれば、中央の下におくのが常套手段でしょうが、そこは技術者向けということで、実を取っています。間違ってクリックした場合でも簡単に閉じれる位置として、アイコンに近い上部に用意しています。ある場合は、開いた後に下までスクロールし、それからこのメニューでなかったと気づくこともあるでしょう。その場合、通常はＸ軸方向にマウスカーソルを移動していることは少ないと推測されます。カーソルをそのまま下へ移動すれば、ボタンにリーチできるように、上部ボタンと同じ方向へ寄せて設置しています。
検索
検索はGoogleのカスタム検索におまかせです。餅は餅屋。検索は、検索屋です。
検索結果には、タブでバージョンを絞り込めるようになっています。多くの場合、これで十分なはずです。
別タブで表示すべきかとも思いましたが、中ボタンクリックだけで別タブになることを普通の技術者の方なら覚えているでしょう。別タブに表示してしまうと、私のようにタブが必要以上に増えることを嫌うタイプの利用者が使いづらくなります。そのため、デフォルトでは同じタブにしておき、必要な人は別タブで開いてもらうことにしました。