「食べたい」は、お店の名前だけでは足りなかった。

ひとくちでは、食べたものと、これから食べたいものの両方を扱っています。公開後に手を入れたのが、この「食べたい」の保存です。お店を残すことに加えて、その店の料理や商品を一品ずつ残せるようにしました。

初期の構想には、パンや手土産も対象にする、と書いてあります。それを保存の場面まで具体的に考えると、お店の名前だけでは情報が足りません。同じお店の別の商品を気にすることもある。保存したい対象が何なのかを、もう少し細かく扱う必要がありました。

どのお店か。その中の、何か。

一品を保存するときは、お店との関係を残しながら、料理名や商品名も持たせます。店を探すことと、一品を覚えておくことの間をつなぐ変更です。後から見たときに「ここで何を食べたかったのか」がわかるようにする。そのために、同じ店の複数の商品を扱う場面も確認項目に入れています。

さらに、アプリの外で見つけたページも「食べたい」へ持ち込めるようにしました。iPhoneの共有メニューからひとくちへ渡す仕組みです。ただ、その入口をつくると、受け取った情報をすぐ保存してよいのか、誰の一覧に入れるのか、という次の問題が出てきました。

保存の前に、一度確かめる。

最初の候補をつくったあと、アカウントごとの保存と、下書きの確認を含む形へ変更しています。共有メニューで受け取ったものは下書きとして保持し、本体のひとくちを開いて、ログイン中の利用者が確認して保存します。共有操作だけで、投稿が人に公開されることはありません。

一つ操作が増えますが、何をどこへ残すのかを確かめる場所にもなります。AIとの相談でも、共有メニューを出せるかだけでなく、本体へ戻ったときの扱いやアカウントごとの保存を詰めていきました。画面の間にある受け渡しまで含めて、一つの機能です。

ここで受け取るのはURLやタイトルです。ページの本文を丸ごと取り込んだり、内容を自動で要約したりするものではありません。どこまでを保存する仕組みなのかを説明する言葉も、実際に行うことに合わせる必要があります。「Web保存」という短い名前だけでは、この違いは伝わりません。

自分の端末で、続きを確かめる。

9月26日には、自分のiPhoneでSafariから共有し、下書きを経由して「食べたい」へ保存できることを確認しました。その後、アプリを再起動しても保存した項目が残っていることも確かめています。画面が一度表示されたところで終わらず、次に開いたときまでを見る確認です。

このとき、AIが実装や確認項目を整理する一方で、実際の端末で操作した結果を私から伝える場面がありました。コードや画面の想定と、手元で起きたことを往復させる。保存の機能をつくる過程にも、そのやり取りがありました。

Safariで確認できたからといって、別のブラウザや、ログインしていない状態もすべて確認できたわけではありません。通った経路と、まだ確かめる必要がある経路を分けて記録しています。使える形に近づけるには、その区別を残しておくことも大切な作業です。

一品を覚えておきたい、という話から始まった変更は、アプリの外と中をつなぐところまで広がりました。何を保存するか。そして保存したものに、あとからたどり着けるか。その両方を確かめながら、次の版を準備しています。