自作のニュースレター配信システムに、また手を入れました。前回はセグメント配信(相手によって送り分ける機能)を足しましたが、今回はメールの見た目を変えられる「デザイン設定」と、件名や季節のあいさつを選んで入れられる「テンプレート」を追加しています。作りながら気づいたのは、これが単なる機能追加ではなかったということです。結論を先に書くと、自分用の道具を人に渡せる道具にするとき、いちばん大きな変更は「コードに直接書いていた値を、コードを知らない人でも触れる場所へ移すこと」でした。
これまで「見た目を変える＝コードを直す」でした
私のニュースレターは、Google Apps Script(グーグル・アップス・スクリプト。以下GAS)というGoogleのサービス上で動く仕組みと、スプレッドシートを組み合わせて作っています。作った経緯は非エンジニアが配信ツールを自作した話に、前回の機能追加はニュースレターをセグメント配信できるようにした話に書きました。
この仕組みでは、メールの色やロゴ、フッターの文章が、プログラムの中に直接書き込まれていました。こういう書き方を「ハードコード」と呼びます。たとえば見出しの色を変えたければ、プログラムを開いて色の指定を探し、書き換えて、もう一度反映させる必要がありました。
自分だけが使っているうちは、これで困りませんでした。AIに頼めばすぐ直せますし、どこに何が書いてあるかもだいたい分かっています。見た目を変えたくなる機会もそれほど多くありません。
ただ、この「作った人が直せる」という前提は、作った人以外が使う瞬間に崩れます。
きっかけは「購入者がカスタムしやすいように」でした
最近、このニュースレター配信システムを、自分以外の人にも使ってもらえる形にしたいと考えるようになりました。配布や販売も視野に入れています。そうなると、使う人の多くはプログラムを開いたことがない人のはずです。
今回AIに伝えた要望は、次の3つでした。
- 「一番上にデザインバナーを入れられる様にしたい」
- 「ニュースレターシステムの購入者がデザインをカスタムしやすい様にしたい」
- 「件名やテンプレートのフォーマットづくり」
この中でいちばん大事だったのは2つ目です。自分のメールをおしゃれにしたい、という話ではありません。コードを開かなくても見た目を変えられること自体が、道具としての価値になると考えました。買った人に「色を変えたかったら、このファイルの何行目を書き換えてください」とは言えませんよね。
メールの一番上に、デザインバナーを入れられるようにしました
まず手をつけたのは、メール最上部の見た目です。これまではロゴが中央にあるだけでしたが、ヘッダーの種類を3つから選べるようにしました。
- デザイン帯——濃い色の帯に、白い文字でタイトルを出す形。画像を用意しなくても、それらしい見た目になります
- 画像——用意したヘッダー画像を、メールの最上部に横幅いっぱいで表示します
- ロゴのみ——これまでと同じく、中央にロゴを置く形です
「デザイン帯」を用意したのは、画像を作るのが負担になる人もいるからです。ヘッダー画像を毎回作るのは、慣れていないと意外と大変です。画像がなくても、タイトルと色だけで整った見た目になる選択肢を残しておきたいと思いました。
画像のヘッダーについては、AIから「全部の号で同じ画像にするか、号ごとに変えられるようにするか」と聞かれ、号ごとに変えられるほうを選びました。普段はいつものヘッダー画像を使い、特別な号だけ差し替えたいことがあるからです。メールの作成画面にその号だけのヘッダー画像を入れる欄があり、空欄のままならいつもの画像が使われます。
設定の置き場所は「管理画面のタブ」を選びました
見た目の設定をどこで変えられるようにするか、という選択肢もありました。スプレッドシートに設定用のシートを作ってそこに書き込む方法と、管理画面に設定用のタブを作る方法です。
私は管理画面に設定タブを作るほうを選びました。スプレッドシートは慣れている人には便利ですが、どのセルに何を入れればいいのかは、画面を見ただけでは分かりにくいからです。
実際の作りとしては、設定の中身は「デザイン設定」というシートに保存され、管理画面のタブからもシートからも編集できるようになっています。画面から触りたい人は画面で、シートのほうが早い人はシートで、という形です。
変えられる項目は、全部で11個です。
- ヘッダーの種類、デザイン帯のタイトル、ロゴ画像、既定のヘッダー画像とそのリンク先
- テーマ色(見出しやアクセント)、濃い色(ボタン・帯・フッターの地色)、メール全体の背景色、目次の背景色
- 送信者名、フッターの説明文
項目を空欄にすると、あらかじめ決めてある初期値が使われます。ただし色だけは、空欄のままだとメールのデザインが崩れてしまうので、必ず初期値に戻すようにしてもらいました。「何も入れなかったら壊れた」が起きないようにするためです。
左にプレビュー、右に設定。保存する前に見た目を確かめられます
設定タブは、左にメールのプレビュー、右に入力欄が並ぶ2列の画面にしました。右で色を変えると、保存する前でも左のプレビューにすぐ反映されます。
これは、色のコードを文字で入力するだけでは、仕上がりが想像しにくいからです。#4fd0c0 と書かれても、ほとんどの人はどんな色か分かりません。変えてみて、見て、気に入らなければ戻す。この往復を気軽にできることが大事だと思いました。気に入らなかったときのために「保存済みに戻す」ボタンも付けています。
もう一つ工夫したのが、入力欄ごとの説明です。たとえばロゴ画像の欄には「高さ50pxで表示、推奨は幅400×高さ100px程度(表示の2倍。文字がぼやけないように)」と書いてあります。ヘッダー画像には「推奨：幅600px」とあります。
画像の推奨サイズは、作った本人にとっては当たり前すぎて、説明を書こうという発想になりにくい部分です。でも初めて使う人は、ここで必ず迷います。説明書を別に読まなくても、入力欄の横を見れば分かるようにしておくのが、人に渡す道具の最低限なのだと思います。
件名と季節のあいさつを、テンプレートから選べるようにしました
もう一つの追加が、メール作成のテンプレートです。ニュースレターを書くたびに、件名と冒頭のあいさつで少し手が止まっていました。毎月のことなので、ある程度型があると助かります。
メール作成画面の上に「テンプレートから入れる」という欄を作り、プルダウンを2つ置きました。
- 件名テンプレ——3種類から選べます。例：「【こみちのニュースレター】今月のコラムをお届けします」
- 時候の挨拶——その月のあいさつ文から選べます。1月から12月まで、各月3つずつ、合わせて36本用意しました
たとえば9月なら「朝晩は少し涼しくなってきましたね。いかがお過ごしですか。」のような文が候補に出てきます。選ぶと件名や導入文の欄に差し込まれ、そのあと自由に書き換えられます。テンプレートはあくまで書き出しの補助で、文面を縛るものではありません。
テンプレートの中身は「テンプレート」というシートで管理していて、種別・月・文面の3列に書くだけで追加できます。文面を増やしたり変えたりするのに、プログラムを触る必要はありません。ここもデザイン設定と同じ考え方です。
副業先で作った仕組みを、語り口だけ変えて持ってきました
実はこのテンプレート機能は、副業先で運用しているニュースレター向けに先に作ったものです。そちらで「テンプレートシートとプルダウン」の仕組みができていたので、同じ仕組みを自分のニュースレターにも入れました。
変えたのは中の文面だけです。副業先は会社から取引先へのご案内なので、あいさつもきちんとした言い回しになります。一方、私のニュースレターは個人が読者に送るものなので、もっとやわらかい語り口にしたいと思いました。仕組みはそのままで、入れる文章だけを差し替えています。
これは作ってみて面白かった点です。同じ仕組みでも、中身を入れ替えれば、まったく違う雰囲気のメールに使える。そしてこれは、いずれ誰かに渡すときにも同じことが言えます。仕組みは共通で、文面はその人のものに差し替えればいい、ということです。
小さくつまずいたところ
順調だったわけではありません。2つ、地味につまずきました。
1つ目は、プログラムを反映させる操作が丸ごと失敗したことです。私はGASの更新を、パソコンからコマンドで反映させるclasp(クラスプ)という道具で行っています。作業前に元のファイルのバックアップを取ったのですが、その置き場所を反映対象のフォルダの中にしてしまいました。すると、設定ファイルが同じ名前で2つあることになり、「同じ名前のファイルがすでにあります」というエラーで反映が止まりました。バックアップは、反映対象のフォルダの外に置くのが正解でした。
2つ目は、Googleの認証が1日で切れることです。メールを送る権限のような強い権限を使っているため、Googleが定期的な再ログインを求めてきます。作業するたびにログインし直すことになり、これが地味に手間でした。毎朝の自動化が47日止まった話でも書きましたが、自動化の最後の一歩は、いつも認証のところで人に戻ってきます。
「まず自分のもので作り切ってから、配布用に反映する」
今回、進め方としていちばん意識したのはこの順番です。
配布用の仕組みを最初から作ろうとすると、「誰が使っても困らないように」を考えすぎて、なかなか完成しません。一方で、自分のニュースレターで実際に使う前提なら、何が必要で何がいらないかがはっきりしています。
そこで、まずは自分のニュースレターで作り切り、自分で使ってみて、問題がなければ配布用にも同じ変更を入れる、という順番にしました。こうすると、配布する時点で自分が実際に使って動作を確かめた形を渡せます。「たぶん動くはず」のものを渡さずに済むのは、安心材料として大きいです。
まとめ:使う人はコードを知らない、を前提にしました
ニュースレター配信システムに、デザイン設定とテンプレートを足した話を書いてきました。やったこと自体は、メールの見た目を変えられるようにして、件名とあいさつを選べるようにしただけです。
でも振り返ると、考え方はかなり変わりました。これまでは「作る人＝直せる人」を前提に作っていました。今回は「使う人はコードを知らない」を前提に作り直しています。色の入力欄に推奨サイズを書いたのも、空欄でも壊れないようにしたのも、プレビューを付けたのも、全部この前提から出てきたことです。
自分のために作った道具を、いつか誰かに渡したいと思っている方がいたら、まずは「自分がコードを直して変えているもの」を数えてみるところから始めてみてください。
このブログでは、AIと一緒に何かを作って、うまくいったことも、つまずいたことも、そのまま書いています。よかったらX(旧Twitter)やInstagramのフォローで、ゆるっとのぞいてもらえたら嬉しいです。
コメント