最初の画面に、本文が無かった
記事ページを開いたときに何が見えているかを、実際に測りました。
| 測ったもの | 値 |
|---|---|
| 画面の高さ | 723px |
| 本文が始まる位置 | 772px |
| 先頭のアイキャッチ画像 | 455px |
最初の画面に、本文が1文字も出ていませんでした。タイトルと日付と画像で埋まっていて、文章はスクロールしないと始まりません。
アイキャッチを消した理由、コードブロックにコピーボタンを付けた理由、見出しに個別リンクを足した理由、そして関連記事の選び方を日付から変えた理由です。
1. アイキャッチを、記事ページから消した
455pxは画面の6割です。ここを何が占めているかを考え直しました。
このサイトのサムネイルは、記事タイトルを文字として描いた画像です。つまり、すぐ上の見出しと同じ内容を、画像でもう一度見せていたことになります。
検索から来た人は「探している答えがここにあるか」を数秒で判断します。その数秒に見えているのがタイトルの繰り返しでは、判断する材料がありません。
画像そのものは、記事一覧のカードとSNSで共有されたときの表示に使っています。作るのをやめたのではなく、本文を読む画面には置かないという判断です。
2. コードブロックに、コピーボタンを付けた
ある記事にはコードブロックが25個ありました。コマンドや設定値は、読むためではなく手元で使うために載せています。
選択してコピーもできますが、折り返しのある長い行では取りこぼしやすい。ボタンを1つ足すだけで、この摩擦が消えます。
ひとつ決めたのは、クリップボードが使えない環境ではボタンを出さないことです。押しても何も起きないボタンは、無いより悪いので。
3. 見出しに、その見出しへのリンクを足した
見出しが12個ある記事で、「この部分を見てほしい」と人に伝える手段がありませんでした。記事のURLしか送れず、相手は自分で探すことになります。
用語集では語ごとに直接指せるよう整備したのに、記事側は未対応でした。同じ問題です。
実装は、目次を組み立てる処理の中で一緒に埋め込みました。表示のあとにブラウザ側で差し込むこともできますが、そのぶん読み込むJavaScriptが増えます。すでに文字列を組み立てている場所があるなら、そこで済ませるほうが軽い。
4. 関連記事を、日付ではなく内容で選ぶ
これまで記事の末尾には「1つ新しい記事」と「1つ古い記事」だけを出していました。
公開日が近いことと、内容が近いことには関係がありません。直前に書いた記事がまったく別の話題、ということは普通に起きます。
タグの重なりを2点、カテゴリの重なりを1点として、上位3件を出すようにしました。
カテゴリ: 技術系 … ほぼ全記事が同じ
タグ : dns, seo, nextjs … 話題が分かれるカテゴリだけで判断すると、ほぼ全記事が等しく「関連」になります。粗い区分は、近さを測る物差しになりません。
重なりが1つも無い記事は出しません。3件に満たなければ、その数だけ出します。1件も無ければ、セクションごと出しません。
「関連記事」という見出しは、書いてあることが本当である前提で読まれます。体裁のために埋めると、その前提が崩れます。
今回の学び
まず、自分のページを、来た人の目で測ること。作っている側は上から下まで知っているので、最初の画面に何が見えているかを意識しません。数字にすると一目で分かります。
次に、同じ内容を二度見せていないかを疑うこと。タイトルの画像とタイトルの文字は、別々に作ったので気づきませんでした。並べて初めて重複だと分かります。
そして、片方で解決したことは、もう片方でも起きていること。用語集では直接指せるように整備したのに、記事では手つかずでした。同じ問題は、場所を変えて何度も出てきます。
最後に、物差しが粗いと、何も測れないこと。全記事が同じ値を持つ項目で並べ替えても、順番は決まりません。分類は、細かさがそろって初めて役に立ちます。
関連記事
ページを消すとき、一緒に消えるもの
実績とスキルの個別ページをトップページへ統合した。作業はidを付けて2枚消すだけだが、決めることは消すほうに集まっていた。転送・sitemap・アンカーが動かない問題の記録。
ゆっくり読む人ほど、読了にならなかった
読了判定の分母に、フッターや前後記事リンクまで入っていた。本文を読み終えても89.9%。丁寧に読む人ほど読了にならない逆転が起きていた原因と、測ってから直した記録。
読む邪魔をしない
貼り付いたヘッダーと目次が、読んでいるあいだずっと画面を占めていた。下へ読むときは引っ込むヘッダー、スクロール中だけ薄くなる目次、先頭へ戻るボタン。3つの判断の記録。