Webは自動Masonryを解決した。フォトブックはなぜまだ？

Masonryレイアウトは、振り返れば必然に思えるWebのアイデアです。比率の異なる画像を渡し、列幅を決め、空いている場所へ要素を収めていく。Pinterestがこのパターンを有名にし、JavaScriptライブラリが一般化し、現代のCSSがプラットフォームそのものへ近づけています。

では、画面上のMasonryグリッドが10年以上使われているのに、なぜフォトブック作りは今も小型のDTP作業のようなのでしょうか。

Webでは余白のコストが低い

Webページはどこまでも伸ばせます。ある列が長くなれば、文書全体が縦に伸びるだけです。読者はスクロールします。Masonryアルゴリズムは局所的に妥当な判断、つまり次の要素を最も隙間が小さくなる場所へ置くだけで済みます。

印刷された見開きは閉じたシステムです。幅も高さも固定され、慎重に扱うべきノドがあり、端には塗り足しがあり、限られた数の写真をすべて収めなければなりません。折り目の下に「続きのページ」はありません。

写真は交換可能な長方形ではない

レイアウトエンジンが見るのは幅、高さ、縦横比です。人が見るのは、端に近い顔、水平でなければならない地平線、余白を必要とする静かな写真、あるいは旅全体を象徴する一枚です。

技術的に完璧なクロップでも主題を切り落とすことがあります。数学的に均整の取れたグリッドが、レシートと結婚写真に同じ視覚的重みを与えることもあります。数秒違いで撮った二枚は一緒に置くべきかもしれませんが、同じ縦横比の二枚がそうとは限りません。

足りない層はスコアリング

有効なのは、巧妙なMasonryルール一つではありません。生成器の後に批評役を置くモデルです。まず、既知のテンプレート、再帰的なページ分割、高さを共有する行、幅を共有する列など、多数の有効な配置を生成します。次に、デザイナーが気づく性質を基準に各候補を評価します。

• クロップコスト：各写真のどれだけが失われるか。
• 焦点の安全性：クロップ後も顔や主要な被写体が残るか。
• バランス：ノドをまたいだ視覚的な重みが意図的に見えるか。
• リズム：連続する見開きに、混乱しない程度の変化があるか。
• 階層：主役の写真に十分なスペースがあるか。
• 印刷の安全性：塗り足し、仕上がり、ノドの制約を守っているか。

最高得点のレイアウトが「正解」なのではありません。持っている情報からソフトウェアが提示できる最善の案なのです。

「自動」は、優れた初稿を意味するべき

フォトブックツールは、二つの悪い約束から一つを選びがちです。すべて手作業か、「AI」が入力なしで完成品を作るか。本当のデザインはその間にあります。

自動化が解決すべきなのは白紙から始める問題です。180枚の写真を数秒で一貫した初稿にし、元ファイルを保ち、すべての決定を元に戻せるようにする。編集者はあくまでユーザーです。この写真を大きくする、この二枚を一緒にする、この見開きを再生成する、このクロップを固定する。

なぜ今なのか

必要な技術が成熟しました。デバイスは顔をローカルで検出できます。写真ライブラリには日時、場所、お気に入り情報があります。何百もの候補を対話的に検討できるほど、レイアウト生成も高速です。ネイティブアプリなら個人の写真をサーバーへアップロードせずに、すべて実行できます。

最後の点は重要です。家族の記録はとても私的なものです。優れた自動レイアウトエンジンが、新たなクラウドサービスになる必要はありません。所有者の端末でライブラリの隣に置かれ、何も持ち出さないからこそ、何も失いません。

私たちが作っているもの

PhotoBooksはテンプレートと生成的なページ分割を使い、その結果を共通のスコアリングシステムで評価します。人間のデザイナーをまねることが目的ではありません。比率、一貫性、印刷上の制約、役に立つ出発点など、ソフトウェアが確実に提供できるデザインの知見を誰もが使えるようにすることが目的です。

Webは長方形が自ら並べることを証明しました。フォトブックに必要なのは次の段階です。自分が思い出を載せていると理解する長方形です。