MANIARUは公開前にも、PCとスマートフォンの表示、リンク、PageSpeed、404、お問い合わせ、SEO、セキュリティなどを確認しました。
それでも、公開後に自分でサイトを使い、PROJECT 001の記事を読み進めると、制作中には気づかなかった使いにくさが見えてきました。
今回は、ChatGPT＋Work＋共通ルールでWordPress制作フローを作ってみたで整理した流れを使いながら、MANIARUの導線とナビを改善した経験をまとめます。
公開してから見えてきた問題
PROJECT 001の記事が増えると、記事を作ることだけでなく、記事同士をどう移動するかが重要になりました。
読んでいる記事がPROJECT全体のどこにあるのか、ほかにどんなSTEPがあるのか、次にどこへ進めばよいのか。単独の記事だけを確認していたときには目立たなかった問題です。
公開前のチェックは、サイトを公開できる状態か確認するために必要でした。ただし、実際の利用中に感じる違和感まですべて見つけられるわけではありませんでした。
PROJECT全体を見るハブを作った
最初に必要だと感じたのは、記事単体ではなくPROJECT全体を見る入口です。
そこで、PROJECT 001「MANIARUを作る。」のハブページを作りました。STEP記事とSPECIAL記事を制作の流れに沿って一覧にし、最初から読みたい人も途中から確認したい人も移動できる形にしています。
HOMEからもPROJECTハブへ進めるようにしました。PROJECTSの紹介だけで終わらず、ハブを通して各記事へ移動できる流れです。
リロードするとPROJECTSへ飛ぶ原因を調べた
HOMEを使っていると、ページをリロードした際に、先頭ではなくPROJECTS付近へ移動することがありました。
見た目だけではJavaScriptやCSSの問題にも見えます。しかし、リンクを押したあとのURLを確認すると、PROJECTSへのページ内リンクで使っていた#projectsが残っていました。
ブラウザはURLにハッシュがあると、そのアンカー位置を表示します。今回の現象はテーマやスクロール機能の不具合ではなく、URLの状態に沿った通常の動作でした。
そこで、HOMEからPROJECTへ進む導線をページ内アンカーではなく、PROJECTハブへの通常リンクへ変更しました。症状を別の処理で隠すのではなく、目的と合っていなかったリンク構造だけを直しました。
PROJECT記事に専用ナビを作った
ハブはPROJECT全体への入口になりましたが、記事を読んでいる最中にも現在位置を確認できる仕組みが必要でした。
そこでPROJECT記事には、STEP 01からSTEP 14とSPECIAL記事を一覧できる専用ナビを設置しました。閲覧中の記事は、ブルーの左線、薄い背景、太字で分かるようにしています。
これはH2やH3を並べる記事内目次ではありません。PROJECT全体のどこを読んでいるかを示し、ほかのSTEPやハブへ移動するためのナビです。
実際の改善過程は、SPECIAL S03「WordPressサイト公開後に気づいたUXを改善する」にも時系列で残しています。
追従ナビを作って新しい問題も起きた
PCでは、長い記事を読みながら右側でPROJECT全体を確認できるよう、専用ナビを追従表示にしました。
ただ、最初に追従ナビを追加したときは、WordPressにもともとあった通常サイドバーとの関係で、PROJECTナビが既存サイドバーの上を動くような不自然な状態になりました。
問題は、同じサイドバー領域に役割の違う要素が共存していたことです。追従の数値だけを調整するのではなく、PROJECT記事と通常記事でサイドバーの役割を分ける構造へ変更しました。
現在、PROJECT記事のPCサイドバーではPROJECT専用ナビを表示し、通常のウィジェットと同時に並べて競合させない形にしています。通常のカテゴリー記事ではPROJECTナビを非表示にし、通常サイドバーを使います。
PCとスマートフォンでナビを分けた
PCのPROJECT専用ナビは、スクロールに合わせて右側へ追従します。項目が画面の高さを超える場合も最後まで操作できるよう、最大高さを設け、ナビの内部を縦にスクロールできる形です。
スマートフォンへ同じサイドバーを表示すると、本文の幅が狭くなります。そのためPC用ナビは表示せず、記事冒頭に折りたたみ式のPROJECTナビを置きました。
折りたたみナビでは、現在のSTEP、PROJECTハブへのリンク、STEPとSPECIALの一覧を必要なときだけ開いて確認できます。
同じ情報でも、PCでは読みながら見える補助ナビ、スマートフォンでは本文を邪魔しない開閉式ナビとして役割を分けました。
PROJECT記事と通常記事では必要なナビが違う
今回の改善で、PROJECT記事と通常のカテゴリー記事では、読者が確認したい位置が違うことも分かりました。
PROJECT記事で必要なのは、シリーズ全体の現在位置です。一方、通常記事で必要になるのは、その記事自身のH2やH3をたどる目次です。
現在の通常記事には、専用の記事内目次をまだ追加していません。将来必要になったときは、PROJECTナビとは別の役割として考えます。
公開して終わりではなく、使いながら育てる
MANIARUでは、公開前にも必要な確認を行いました。それでも、公開後にHOMEからハブへ進み、複数のPROJECT記事を読むことで、別の問題が見つかりました。
公開して、使い、違和感に気づき、原因を確認し、必要な範囲だけ直す。そしてもう一度使う。この流れまで含めてWebサイトを作る作業でした。
見た目の不具合に見えても、原因がURL設計にある場合があります。新しいUIを加えると、既存のサイドバーとの関係から別の問題が起きることもあります。実際に使って確認することで、直すべき場所が具体的になりました。
追従サイドナビの実装は、CSSのposition: stickyで追従サイドナビを作る。実装して分かった注意点で詳しく記録しています。
FROM THE PROJECT
この方法を実際に試した記録