なぜ改善したのか
前回までで、Lambdaを手動実行すると日報ページがS3へ保存され、SESからメールも届くところまで確認できました。エラーを一つずつ越えて、ようやく受信箱に日報が現れた瞬間はうれしかったです。
ところが、実際に開いてみると「届いた」と「毎朝読める」の間にはまだ距離がありました。PC版は暗い背景に情報が詰まり、スマートフォンでは本文領域が狭く、長い英語タイトルが何行にも折り返されます。Gmailのダークモードでは、こちらが指定した背景色が想定どおりに見えない場面もありました。
Web版も同じでした。タイトルと余白が大きく、内容の区切りはあっても長いテキストを上から読んでいる感覚が残ります。作業記録に残った初期版は17分相当の表示で、朝に流し読みする日報としては重く見えました。
動作確認を終えたつもりでしたが、ここで確認対象が変わりました。次に直すべきなのはAWSの設定ではなく、受信した人がどこから読むかでした。
最初のデザイン
最初はWeb版の見た目をそのままメールにも持ち込もうとしていました。SAMEKORO LABの深海デザインに合わせれば、サイトとメールに統一感が出ると思っていたからです。
ただ、WebブラウザとメールクライアントではCSSの扱いが違います。ブラウザでは自然に見えたレイアウトも、メールでは背景色や幅、余白の見え方が変わりました。特にスマートフォンでは、外側の余白が一つ増えるたびに本文が細くなります。
同じHTMLを二つの場所へ配れば管理は楽です。しかし、読む場面まで同じではありませんでした。メールは朝に要点をつかむ入口で、Webは気になったニュースをあとから読み返す場所です。この役割の違いを無視したまま、色とカードだけをそろえようとしていました。
1回目の改善
そこで、表示処理を render-web.mjs と render-email.mjs に分けました。日付やニュース項目のような共通の表示データは render-shared.mjs へ寄せ、Webとメールはそれぞれ別のHTMLを組み立てます。
メールは白背景、最大600px、tableレイアウト、インラインCSSへ変更しました。Outlook向けには幅600pxの条件付きラッパーも入れています。Web版は深海テーマを残しつつ、目次やカードで「今日の注目ニュース」「30秒ニュース」「今日のAWS小ネタ」を分けました。
これでPCではかなり整理されました。最初の暗いメールよりも本文を追いやすくなり、「表示を分けた判断はよさそうだ」と思いました。
それでも読みにくかった理由
一度カード化すると、今度はカードを増やしたくなります。セクションの外側に余白を置き、その中のカードにも余白を置き、さらに本文にも余白を置きました。PCでは整って見えますが、スマートフォンでは外周、セクション、カードの余白が重なり、本文幅が想像以上に狭くなりました。
最初は、長い英語タイトルだけが原因だと思いました。しかし、タイトルを短く見せても窮屈さは残ります。390px幅で外側から順に確認すると、問題は一つの文字列ではなく、入れ子になった余白でした。
Web版もカードに分けただけでは、読む順番がはっきりしませんでした。大きなタイトル、似た概要、英語の原題が同じ強さで並び、どこから目を通せばよいか迷います。カードの数ではなく、情報の優先順位から直す必要がありました。
最終的な情報設計
最終的には、メールをダイジェスト、Webを詳細版と決めました。メールだけでも今日の要点は分かり、深く読みたいときだけWebへ進める形です。
メールでは「今日の注目ニュース」を最初に置き、そのあとに短いニュースとAWS小ネタを続けます。Webでは目次を置き、注目ニュース1件、速報、AWS小ネタ、今日の共通点、あとがきの順に読み進められるようにしました。
英語タイトルは主見出しにせず、日本語要約の先頭文を見出しとして使い、原題は補足へ回しています。同じURL、または同じ公開元と日付の項目は重複表示しない処理も共通側へ入れました。見た目を整える前に「何を最初に読んでほしいか」を決めたことで、ようやく日報らしくなりました。
メール版で工夫したこと
メールの外周は4px、セクションは8px、内容部は16pxを基準にしました。カードを何重にも重ねず、横幅を本文へ渡します。現在のテンプレートでは外側のセルに上下を含む余白を置きつつ、横方向を4pxに抑えています。
390px幅の実機確認では本文幅がおよそ335pxになり、日本語は1行あたり約19文字でした。本文16px、概要17px、注目ニュースのタイトル26pxまで落とし、狭い画面で見出しだけが何行も占有しないようにしています。
メールクライアントはブラウザほど自由にCSSを使えません。Gmail、Apple Mail、Outlookで崩れにくいことを想定し、tableレイアウトとインラインCSSを基本にしました。ただし、すべての組み合わせを確認済みという意味ではありません。実際に使う端末とクライアントで見直す余地は残しています。
Web版で工夫したこと
Web版はコンテナを最大1000pxにしながら、本文の実読幅は最大800pxに抑えています。PCでは速報を2列、AWS小ネタを3列で見せ、800px以下では小ネタを1列、600px以下では速報も1列へ切り替えます。390px幅ではすべて縦に並び、横スクロールが出ない構成です。
スマートフォンのタイトルは最大33.6pxです。大きな見出しを見せることより、次の概要と目次が早く画面へ入ることを優先しました。「今日の共通点」は他のカードより強く見せ、あとがきはコンパクトにまとめています。
今回ハマったポイント
起きたのは、メールをカード化したあとにスマートフォンの本文幅が狭くなったことでした。最初は英語タイトルの長さを疑い、表示用タイトルを短くする処理を見直しました。
それでも窮屈だったため、390px幅で外周から内容部までを順に比べました。原因は、外周、セクション、カード内の余白が入れ子で足されていたことでした。横余白を4px、8px、16pxへ整理し、多重カードを減らすと、本文に必要な幅を戻せました。
次回からはPC版を完成させてから縮めるのではなく、最初に最小の対象幅で本文領域を確認します。タイトルの折り返しだけでなく、どの要素が横幅を消費しているかを外側から追います。
今回の学び
Web用HTMLをメールへ流用できれば早いと思っていましたが、読む場所とCSSの制約が違えば、表示の役割も分けた方が自然でした。また、カードを増やすほど読みやすくなるわけではありません。情報の優先順位を決め、そのあとで余白や色を整える順番が大切でした。
自動テストはHTMLの構造や意図しない差分を見つけてくれます。ただ、スマートフォンで「朝から読みたい幅か」までは判断してくれません。動作したあとに実機で読むところまでが、今回のUI改善でした。
次回は、内容は正しいのに毎朝読むには硬かった文章を、プロンプトと表示の両方からどう直したかを振り返ります。