Mac の定番ランチャー、 Alfred のような検索 UI が好きだ。こういう UI で検索できるソフトウェアやウェブサイトがあると気持ちいい。自分のブログにモーダルウィンドウの検索を追加したときも Alfred みたいにしたいと思いながら作った。
見た目は Alfred っぽくできたが、キーボードで操作できない点が気になっていた。いちいち画面右上の🔍マークを押さないと検索 UI を呼び出せないし、検索しようと思って気が変わったときにはカーソルを動かしてモーダルウィンドウの外の領域をクリックしないとモーダルを閉じられない。これが地味にストレスだった。
見た目だけでなく使い勝手も Alfred のようにしようと思ってガチャガチャやってみた。 Access Key を割り当てて
普段は Vim などのテキストエディターで文章を書いていて、ブログの投稿画面にはできあがった内容をコピペするだけだったので、投稿画面の使いやすさやは気にしたことがなかった。画像のドラッグ・アンド・ドロップ・アップロードや、オン・ザ・フライでプレビューをできるようにしたが、テキスト自体の書きやすさを改善しようとはしてこなかった。
大筋はテキストエディターで書いたとしても、最後に推敲したり、推敲していて気が付いたおかしなところの修正は投稿画面で行うことが多い。やっぱり投稿画面の書きやすさは重要だ。特に長大な内容を編集しているときにテキストエリアが狭いととても使いづらい。ある程度大きさがあり、画面内に大量の文字が表示されるテキストエリアが好みだ。
Lokka が開発されていた 10 年以上前は解像度の小さいディスプレイが主流で、 Lokka の管理画面は小さいサイズのウィンドウで閲覧することを想定したテキストエリアのサイズになっている。今日の高解像度ディスプレイで見ると不便なので画面一杯にテキストエリアが広がるようにした。
iPad からも投稿しやすいように投稿画面のレイアウトも修正した。本文のテキストエリアが広がったためスクロールしないと「スラッグ」以降の入力欄にアクセスできなくなったので、ある程度横幅のあるウィンドウのときにはこれらを右側に配置するようにした。
加えて、フォームを書きかけで保存したかどうかがはっきりせず、未保存の内容があるのに保存せずページから離脱してしまうことがあったので、変更点があるときは背景色を変えてわかるようにした。これにより記入内容を保存せずページを離脱してしまい、内容が失われるという悲劇を回避できるようになった。やり方は適当に検索して出てきた Stack Overflow を参考に、ページを読み込んだ時点で JavaScript でフィールド内の要素を JSON.stringify して data attribute に格納し、その後各フィールドの input イベントを監視して変更があるかどうかをチェックしている。
class FormObserver {
constructor() {
this.initializeFields();
this.observeFieldsChange();
}
initializeFields() {
const fields = Array.from(document.querySelectorAll('div.field'));
for (const field of fields) {
const inputElement = field.querySelector('input[type="text"], textarea, input[type="datetime-local"], select option:checked');
if (inputElement === null) {
continue;
}
field.dataset.serialize = JSON.stringify(inputElement.value);
}
}
observeFieldsChange() {
const fields = Array.from(document.querySelectorAll('div.field'));
for (const field of fields) {
const inputElement = field.querySelector('input[type="text"], textarea, input[type="datetime-local"], select');
if (inputElement === null) {
continue;
}
inputElement.addEventListener('input', () => {
if (field.dataset.serialize != JSON.stringify(inputElement.value)) {
inputElement.dataset.changed = 'true';
field.classList.add('edited');
} else {
inputElement.dataset.changed = 'false';
field.classList.remove('edited');
}
})
}
}
}input イベントを監視すると動作がもっさりするのではないかと心配したが、そんなことはないようだ。普通に使えている。
いまのところ管理画面の HTML レンダリングはサーバーサイドで Ruby で行っているが、これ以上凝ったことをやるなら React などを使って JavaScript で HTML を組み立てる方式にしていく方が効率が良さそうだ。
404 ページ、昔はそもそもなくて 404 Not Found ステータスを返すだけだったり、あっても「見つかりません」というだけのものが多かったけど、最近はサイトマップ的なコンテンツや代替となるコンテンツを表示するサイトも見かける。というわけでこのサイトでもやってみることにした。
このブログの URL は /YYYY/MM/DD/slug という形式になっている。パスの /YYYY/MM/DD の部分はお飾りで、実際は slug がユニークになっているので slug で表示すべき記事を判定している。
よくあるのが記事を公開後、 slug 部分にタイポを見つけて変更するというケース。しかしすでにその時点で記事が Twitter などでバズってたりすると、 Twitter で共有されている記事を見てやってきた人が 404 Not Found ページを見ることになる（この前の「不便になるインターネット」がまさにそうだった）。それはまずいので slug のタイポを修正すると同時に Nginx の設定ファイルをいじってタイポ修正前の URL から修正後の URL へリダイレクトするようにしていた。しかしリダイレクトごときでサーバーの設定ファイルを修正して root 権限でリロードするというのはめんどい。 SSH でログインもしなければならない。大げさすぎる。
というわけで思いついたのがこの機能で、 Ruby でクラス名やメソッド名をタイポしたときに正しい候補を表示する did_you_mean.gem を利用した。存在しない slug で URL を開くと以下のように候補が表示される。
コードはこんな感じ。
# Helper
def not_found_candidates
@not_found_candidates ||=
begin
slugs = Entry.published.where.not('slug REGEXP ?', '^[0-9]+$').pluck(:slug)
spell_checker = DidYouMean::SpellChecker.new(dictionary: slugs)
current_slug = request.path_info.split('/').last
slug_candidate = spell_checker.correct(current_slug)
Entry.published.where(slug: slug_candidate)
end
end
# View
- if not_found_candidates.any?
%p Did you mean?
- not_found_candidates.each do |candidate|
= link_to candidate.title, candidate.linkデータベースから slug 一覧を取り出して辞書とし、 DidYouMean::SpellChecker に食わせて似たページの候補を取得して表示する。タイポありのページを訪れた人はワンクリックしなければならないという手間が増えるが、これでタイポを修正したときに面倒なリダイレクトの設定をする必要がなくなった。
なお 404 ページには検索窓や最近の記事、カテゴリー一覧も表示して回遊性を高めている。
グローバルナビゲーション（右上の白い領域）内の検索ボタンを押したら Alfred 風のモーダル検索フォームが開いて、そこにキーワードを入力するとインクリメンタルサーチが実行されて逐次検索結果の記事が表示されるようにした。
これまでだと検索すると Archives ページの絞り込み検索に飛ばすだけだったが、 Archives ページに遷移せずに検索できるようになった。また Archives ページだと時系列順でしか検索結果が表示されないが、インクリメンタルサーチではマッチ度順に関連度の高いものを表示するようにしている。ただし表示するのは上位 10 件だけにして、それ以上は Archives ページで時系列順の検索に飛ばしている。
昔ながらのブログの検索 UI には不満がある。ページネーションで何ページも辿って検索結果を見ていくのは大変だし、大抵並び順が時系列順で自分が最も用事がありそうな記事に辿り着くのに時間がかかる。自分のブログの検索はタイトルのみ表示されればよくて本文のプレビューは不要だし（著者だからタイトルを見ただけでどんな記事なのか大体わかる）、何ページもページネーションせずに一覧でガッと検索結果を見たい。それに結果は時系列順ではなく関連度が高い順に並んでいて欲しい。キーワードを一部だけかすってるような最近の記事が最も関連度が高い記事を差し置いて最上位に表示されるのはいまいちだ。
今回作った Alfred 風インクリメンタルサーチではこれらの問題が解消されていて非常に満足。自分にとって自分のブログが世の中の情報の中で一番参照頻度が高いし、そのブログで効率的に情報を取り出せるのは大切なことだと思う。
ダークモードとライトモードの切り替えをグローバルナビゲーション（上の方の半透明の白い領域）から簡単に行えるようにした（これまではこのサイトについてのページで切り替える必要があった）。デフォルトは OS の設定準拠で、 OS がダークモードであればダークモードに、ライトモードであればライトモードで表示される。手動でテーマを切り替えると Cookie に設定値を保存する。機能と見た目は MDN Web Docs を参考にした。
CSS がぐちゃぐちゃなのでかなり難儀した（ 3 年前にも同じことを書いている）。ダークモードとライトモードの切り替えなんて自分しかしていないと思うがかなり満足度の高い休日プログラミングだった。
最初にブログを作ったときからウェブサイトのタイトル（やロゴ画像）が h1 で、記事タイトルが h2 という見出しレベルで HTML を書いていた。しかし最近では、記事パーマリンクのページではサイトのタイトルなどには見出しレベルを設定せず、記事タイトルに h1 を当てている場合が多いようだ。なのでこのサイトでも記事タイトルを h1 とするように変えた。本文中の見出しレベルも h3 スタートだったのを h2 スタートに変えた。
伝統的なブログはインデックスページと記事パーマリンクページで HTML テンプレートを共通化している。なのでインデックスページに記事一覧を表示して h1 タグが並ぶとまずいということで記事タイトルは h2 から、という作りになってるような気がする。このサイトはインデックスページとパーマリンクページでのテンプレート共有化をほぼほぼやめたので、インデックスページとパーマリンクページで記事タイトルの見出しレベルを柔軟に変更している。
サイトの作り手からするとウェブサイトのタイトルこそが最も重要な要素でタイトルロゴなどを h1 でマークアップしたくなるのだが、読み手は Twitter やはてブから飛んできて刹那的に記事を消費し、インデックスページなんかには見向きもせずに去って行くだけだ。個別記事のタイトルこそ重要なのだ。
r7kamura さんからこういうコメントをもらってこういう風に返信した。
あー、なるほど。文章の構造化と HTML の構造化は分けて考えるべき、ってのが HTML 5 の背景にありそうですね。僕はこの辺ごっちゃになってました。 article 内できちんと見出しが配置されてれば問題なさそうですね。
— morygonzalez (@morygonzalez) June 23, 2022
HTML5 が出てきたとき、個人的には何かめんどくさいなぁとしか思ってなかったし、世間は Flash を置き換える近未来技術みたいな評価をしていたと思う。しかし、 <header> タグや <article> タグによって、 HTML の構造化と文書の構造化を分離できるようになったのがセマンティックWeb的なメリットだということに気がついた。つまり <h1> などの見出しルールは <article> タグの中で守られていればよいのだ。
ということに HTML5 が死んでから気がついた。
このサイトは Amazon の Product Advertising API を利用して小銭を稼がせてもらっている（毎月 300 円くらいインターネットの恩沢がある）。去年も 5 月頃に記事を書いているのだが、 30 日間で一個もこのブログ経由で商品が売れなかったので Product Advertising API の利用が制限されてしまった。
Product Advertising API は 2020 年の春に Version 5 への移行が義務づけられ、 30 日間で一回も商品を売れなかったサイトは API の利用ができなくなってしまうのだった。
春は入学や就職、引越の準備で忙しくて誰もこのような泡沫ブログを読んだりしないのだろうか。春は買い物する機会自体は多いと思うので、買い物していないわけではなく、趣味性の高い商品のアフィリエイトが踏まれにくくなるのかもしれない。
