デバイスの違いを越えて
パソコンを基準に考えていたとき、レスポンシブデザインのテーマは、元々パソコン用に整理したデータをスマホの狭い画面にいかに効率的・効果的に配置し直すかといったことだった。しかし、このホームページのメインテーマは「写真」であって、追求すべきは、限られたスペースに写真を大きく、見やすく、操作しやすく表示するための手法なのだ。そう考えると、単に"スマホ"ではなく、スマホの縦画面と横画面の違いや操作性など、さらに踏み込んだデザイン思考が必要なのではないかと思うようになった。
このような動機で今回のリニューアルに取り組むこととなった。
最初に、デバイスの違いではなくて、PCではブラウザの表示領域、モバイルではスクリーンのサイズに着目し、それらの表示領域とそこに表示する写真のアスペクト比を足掛かりにデザインを考えることとした。モバイル端末は、アプリを使わない限りブラウザの全画面表示と同じ状態と捉えることができるため、「ブラウザの表示領域（ javascript でいうところの document.clientWidth/clientHeight ）」と捉えて全端末を同じ尺度で把握することとした。
アスペクト比
最初に「アスペクト比」について検証してみた。一般的にフルサイズの写真では「3:2」と表示される。これは「横３、縦２」という意味で、最初に横、次に縦をコロンで区切って並べる。しかし、プログラムで扱う場合は計算式の都合から単数字にする必要がある。
アスペクト比を単数字で表現する方法を調べてみると、
・建築分野では、縦サイズ ÷ 横サイズ
・IT分野では、横サイズ ÷ 縦サイズ
なのだそうだ。一般的に「縦横サイズ」とは言うが「横縦サイズ」とは言わないと思う。つまり、「縦」が先なのだ。ならば、その「縦」は分子なのか分母なのか、建築分野では分子、IT分野では分母ということになる。個人的には建築分野の方が感覚的にしっくりとくる（細かなことだが）。
しかし、プログラムで使う数値であれば、ここはあえてIT分野に合わせるしかないだろうということで、
とした。文章では「横：縦」、「縦横」または「縦×横」の形で表記する。
そして、インタプリタ言語による計算上、桁数にも配慮が必要で、原則として小数点以下４桁に丸めることとした。扱う写真の解像度は多くても千の桁なので、小数点以下４桁であれば、１ピクセルに対して四捨五入が過不足なく適用できると考えたためだ。
ブラウザ表示領域の形状と写真のアスペクト比を比較
ブラウザの表示領域と写真のアスペクト比を組み合わせると単純に４つのCASEに分類できる。
色々と考えた結果、上の表で、ブラウザ表示領域を横長と縦長でデザインを２つに分けることにした。横長画面はスマホの横画面とパソコンのディスプレイを念頭に置いてのこと。
デザインを考える上で、やはり、スマホ対応がクリチカルな条件になってくる。スマホでブラウザを起動すると、画面上部にアドレスバーが居座り、スマホを横にした場合は、画面の縦幅を大きく損ねる存在になる。このアドレスバーは画面操作によって設定で非表示にはできるものの、表示するページによって意図的に非表示にすることはできない。セキュリティ対策上の制約によるものと思われる。これがアプリの利用が広まる要因にもなっていると思う。
結局、各CASEごとの画面デザインは次の表－2のようになる。
細部の検証をしてみると、CASE2の場合に微妙なデリケートな領域が存在することがわかった。ほとんどパソコンの場合に限定されると思うが、具体的には、ブラウザ表示領域が横長とはいっても正方形に近い横長画面で、かつ写真は縦長とは言っても正方形の近い縦長の場合だ。６×６のブローニー版では 56mm×56mm が一般的なフィルムサイズだがスキャンして整形した結果微妙に縦が長くなるということもある。また、トリミングの結果、正方形に近い縦長写真となる場合もあるだろう。
デザインの構成部分を考えると、可変サイズとなる写真部分の他、タイトルや撮影データ、ページ切り替えのアイコン類など、ほとんど固定サイズの要素も含まれるわけで、固定部分と可変形部分を合わせたデザイン構成になる。このようなボックス構造で写真の部分の形状が変化した場合、ボックス全体としてはどのように変形するのだろうか。
計算でクリチカルなポイントが見つかるかどうか確認したかったのだが、自分の数学能力では関数式を完成させることができず、やむなく、固定デザイン部分の形がある程度固まった段階で EXCEL でシュミレーションしてみることとした。
結果、確かに微妙な部分はある。つまり CASE2 であっても縦長デザインの方が写真の表示面積がわずかに大きくなるケースがあることが分かった。しかし、ここまで確認して、その些細な部分のために、CASE2 であっても、その該当する写真だけデザイン２に切り替えることのリスクに気づいた。それは、今回のリニューアルのある意味大きなテーマでもあるが、連続的に写真を閲覧するときの閲覧の快適性と操作性に関して次の２点を改善することであった。
・視線の中心が大きく移動しないこと
・ページ切り替えのアイコンの位置が移動しないこと
デザイン１とデザイン２の間で上記条件を満たすことは無理がある。結局、ここまで確認して、表－２の考え方が正しいことに自信を持てるようになった。
追記
この時点で整理しておいた方が良いと思いあえてここで記述するのだが、「wrapper」と「container」のどちらを使うかという問題。簡単に考えるとどちらでもよいとは思うが、ここでは「container」を使用している。「container」で囲んだ要素をデザイン構成の中でより積極的に認識し、制御する対象としているからで、単に「全体」として包み込むだけの位置づけとは少し異なるというのがその理由。
デザイン切り替えの方法
（１）Javascript によって、ブラウザ表示領域の Width（Element.clientWidthプロパティによる）と Height（Element.clientHeightプロパティによる）を取得し、そこからアスペクト比を算出する。
（２）アスペクト比が１未満の場合は、縦長スクリーンと判定し、SV デザインを適用する。SV デザインの適用は、専用の CSS（photostyle_sv.css）を適用し、加えて Javascript によって算出した各種変数の値を CSS に動的に反映させて細部を調整する。
（３）アスペクト比が１以上の場合は、横長スクリーンと判定し、SB デザインを適用する。SB デザインの適用は、専用の CSS（photostyle_sb.css）を適用し、加えて Javascript によって算出した各種変数の値を CSS に動的に反映させて細部を調整する。
（４）デザイン切り替えのタイミングは次の方法による。
（ａ）HTML ソースロード完了直後に Javascript プログラムを起動し、デザインの選択と適用を行う。
（ｂ）端末がローテーションされた場合に備えて orientationchange イベントを addEventListener メソッドに登録することにより、端末の回転を検知して window.onload イベントを発行し、ページをリロードする。
（ｃ）ブラウザのサイズが変更された場合に備えて window.onresize イベントを addEventListener メソッドに登録することにより、ブラウザのサイズ変更を検知して window.onload イベントを発行し、ページをリロードする。
デザイン１（SBデザイン）
ブラウザの表示領域が横長の場合に採用するデザインで、スマホやタブレットを横に回転させた場合、またPCディスプレイでもブラウザのウインドウを横長にした場合に自動的に適用される。
この横長デザイン (SB) は縦長 (SV) デザインに比べて表示できる写真の面積が大きくなるため、本サイトの中心的なデザインとして位置づけている。
SBデザインの概要（PDF 別画面で開きます）
SBデザインのBOXレイアウト（PDF 別画面で開きます）
以下、ポイントとなる事項を列記する。
（１）全体構成
・bodyはブラウザ表示領域すべてとする。背景色は18%グレー、すなわち16進数カラーコードで「#767676」、RGBでは「rgb(128, 128, 128)」となる。
・containerは、bodyの右下を基準に配置する。そして、上下左右5pxのpaddingを確保して写真が画面端に張り付くように表示されることを回避する。また、containerのサイズは写真のサイズ（画素数）を基準にするものの、フルHD（1920px×1080px）サイズを上限とする。
・containerの背景色はbodyの背景色と一致させる。つまりbodyとcontainerの領域は一体のものとして見える。
・containerの内容は全体として２段組み構成（2カラム構成）とする。
・左カラムには写真を配置、右カラムには「タイトル」、「撮影データ」、「アイコン」、「フッター」の４要素を上から順に配置する。
・２段組み構成は見かけ上の配置であり、画面表示に際しての細部の調整効率を考慮して、CSSの構成上は別の構成になっている。
・CSSでは最上位のブロック構成をGRIDレイアウトで定義している。そのGRIDレイアウトは4行2列からなり、各アイテムの配置は次のようになっている。表では各ボックスを「行－列」で表記している。
図－1 GRID構成
（２）左カラム
・写真は「図－１」の1-1～4-1までの左カラム全体を占有して表示する。CSSにおけるgridの表記では、「grid-row:1/5;grid-column:1/2」となる。
・写真はネイティブな画素数以上に拡大表示しない。しかし、ブラウザ表示領域が狭い場合には領域に合わせてその中で写真を最大に表示できるように写真のアスペクト比を維持しながら縮小表示する。
・写真の外周は5px幅の枠で囲んでいる。枠の色は#939393で、18%グレーより約15%明るい色としている。枠を設ける理由は、額縁でいうところの「面金」とか「ライナー」の存在感を模したもので、これがあると実際の額縁感が少しは出ると思う。写真はmountブロックに収め、枠はpaddingで実現している。
・mountブロックの外側に仮想mountブロックがあり、mountブロックは仮想mountブロックの中に上下左右センタリングで収容する。
・仮想mountブロック（pseudo_mount）はmountブロックを包含するaspect比3:2（写真が横長の場合）または2:3（写真が縦長の場合）のボックスで、左カラムの中で右寄せで配置する。仮想mountブロックを採用する理由は写真を連続的に鑑賞する場合、大小、縦長・横長の写真が混在しても写真の中心点をなるべく移動しないようにするためで、見やすいサイトとしたいためだ。
（３）右カラム
（ａ）右カラム全体として幅154px固定で、上から次の４つのボックスが並ぶ。
－タイトル：高さauto
－撮影データ：高さ1fr
－アイコン：高さ80px
－フッター：高さ15px
・ここでautoとは、タイトルの行数で変動することを意味する。また、1frとは、右カラム全体に与えられた高さからautoと、他の要素の高さを引いた残りすべてという意味。つまり可変高。
（ｂ）タイトル
・右カラムの一番上に位置するので、CSSにおけるgridの表記では、grid-row:1/2;grid-column:2/3となるところだが、実際はgrid-row:1/2;grid-column:1/3としている。図－１でいう1-1と1-2の領域を合わせて占有していることになる。これだと写真と重なってしまうのだが、ブラウザ表示領域のサイズに合わせてjavascriptで動的にtitle要素に対してpadding-leftの設定を行い、タイトルの表示領域の左側にスペースを作り出している。そのスペースの幅(①)を写真の幅を考慮した値とすることによって、写真とタイトルが重なることはなく、かつ写真とタイトルの隙間を自由にコントロールすることができる。
・高さは固定で、折り返し行を含めて最大３行を想定している。３行を越えてもfridのauto設定により、行高が調整される。
（ｃ）撮影データ
・右カラムの上から二番目に位置するので、CSSにおけるgridの表記では、grid-row:2/3;grid-column:2/3となるところだが、実際はgrid-row:2/3;grid-column:1/3としている。図－１でいう2-1と2-2の領域を合わせて占有していることになる。これだと写真と重なってしまうのだが、タイトルの場合と同様にブラウザ表示領域のサイズに合わせてjavascriptで動的に撮影データボックスに対してpadding-leftの設定を行い、タイトルの表示領域の左側にスペースを作りだしている。そのスペースの幅(①)を写真の幅を考慮した値とすることによって、写真と撮影データが重なることはなく、かつ写真と撮影データの隙間を自由にコントロールすることができる。
・撮影データの中は、上にタイトルがあり、その下にテキスト行が収容される。この部分には少し複雑なテクニックが使われている。
SBデザインオーバーフロー処理（PDF 別画面で開きます）
・撮影データは次の仕様で表示する。
－右カラムの二番目の段落の中で下詰めで表示する。
－撮影データは上下二段組みになっており、上段はスマホ横画面でも表示できる最低限の情報を掲載する。この段は行数としての制限はないが、折り返しを含めて４行に収めるように運用規制する。下段はスペースに余裕がある場合を想定して、その他の付加的な撮影データを記載するようにしている。オーバーフロー処理前提なので記載する行数に制限はない。
－下段の要素はブラウザの表示領域縦幅が329px未満となった場合は、display:noneで非表示とする。329pxの根拠は、スマホ横画面の最低heightとして320pxを想定し、その付近で、行の上下途中で表示が欠けることのない数値をブロック構造から算出したもの。
－行数が多くなって表示可能なエリアから溢れる場合は、下の行から非表示とするオーバーフローの処理を行う。
－オーバーフローの処理に際しては、行の上半分というような途中まで表示される状態をさけるため、行高単位で要素の高さを管理し、行単位でオーバーフローさせる。
・この仕様を実現させるため、javascriptで写真のサイズやスクリーンのサイズから決まる条件を演算して、動的に要素の高さ（height）を設定している。
・オーバーフローの処理に際しては、要素の高さを設定する必要があり、それはGridによって自動的に付与されるのであるが、行高単位でオーバーフロー処理するために、あえて要素の高さ（height）を行高刻みの数値にして設定している。
（ｄ）アイコン
・右カラムの上から３番目のボックスで、ページを次に進める、前に戻す、あるいは上階層のインデックスに戻るといった操作を行うアイコンを表示する。
・アイコンは写真がどのように変わってもbodyすなわちブラウザ表示領域の固定ポジションから動かさない。操作性を確保する上で重要なポイントと考えている。
（ｅ）フッター
・著作権マークを表示する。
デザイン２（SV デザイン）
ブラウザの表示領域が縦長の場合に採用するデザインで、スマホやタブレット、また PC ディスプレイでもブラウザのウインドウを縦長にした場合に自動的に適用される。
デザイン SV の概要（PDF 別画面で開きます）
以下、ポイントとなる事項を列記する。
（１）全体構成
・body はブラウザ表示領域すべてとする。背景色は 18% グレー、すなわち 16 進数カラーコードで「#767676」、RGB では「rgb(128, 128, 128)」とする。
・container(wrapper) は、上下左右に 5px の padding を設定している。また、プラウザ表示領域の横幅がフル HD 横（1080px）を越える場合は、container の横幅はフル HD 短辺のサイズを上限とし、body の中に右寄せで配置する。container の縦方向については、全体として下揃えとしているため、body の縦サイズが 1920px を越える場合は上部に必ず空白ができることになる。
・container の背景色は body の背景色と一致させる。つまり body と container の領域は一体のものとして見える。
・container の内容は全体として1カラム構成とし、上下方向三段にボックスを配置する。
・上から一段目は写真を配置、二段目は「タイトル」、三段目は内容を２カラム構成とし、左側に「撮影データ」を配置、右側は内容を上下に二段構成とし、上段に「アイコン」、下段に「フッター」を配置する。
・上下三段組み構成は見かけ上の配置であり、画面表示に際しての細部の調整効率を考慮して、CSS の構成上は別の構成になっている。詳細は「SV デザインの BOX レイアウト」を参照されたい。
SV デザインの BOX レイアウト（PDF 別画面で開きます）
・CSS では GRID レイアウトを採用しているが、GRID の構成は SB デザインと同じで「図－1 GRID 構成」となる。
（２）一段目
・写真は「図－１」の1-1～1-2の２つのカラムを占有して表示する。CSS における grid の表記では、「grid-row:1/2;grid-column:1/3」となる。
・写真はネイティブな画素数以上に拡大表示しない。しかし、ブラウザ表示領域が狭い場合には領域に合わせてその中で写真を最大に表示できるように縮小表示する。
・写真の外周は5px幅の枠で囲んでいる。枠の色は #939393で、18% グレーより約 15% 明るい色としている。枠を設ける理由は、額縁でいうところの「面金」とか「ライナー」の存在感を模したもので、これがあると実際の額縁感が少しは出ると思う。写真は mount ブロックに収め、枠は padding で実現している。
・mount ブロックの外側に仮想 mount ブロックがあり、mount ブロックは仮想 mount ブロックの中に上下左右センタリングで収容する。
・仮想 mount ブロック（pseudo_mount）は mount ブロックを包含する aspect 比2:3（写真が縦長の場合）または3:2（写真が横長の場合）のボックスで、一段目の中で左右中央配置とし、上下は次の計算式で得たものを仮想 mount ブロックの padding-top の値として設定する。
(((ブラウザの表示領域の高さ -5px) - (三段目のブロックの高さ)) / 2) - (仮想 mount ブロックの高さ / 2)
・つまり、三段目のボックスを除いた全上下スペースの上下中央に、上下密着した写真とタイトルを配置する。
・仮想 mount ブロックを採用する理由は写真を連続的に鑑賞する場合、大小、縦長・横長の写真が混在しても写真の中心点をなるべく移動しないようにするためで、見やすいサイトとしたいためだ。
（３）二段目
・タイトルは最大２行を想定している。ボックスの高さは固定としているため、はみ出た場合はその部分が表示されない。SB デザインでは３行までとなっているが、自動改行による折り返しも影響するため、実際にはUP前に確認することが必要となる。
・タイトルは写真の直下とし、かつ水平方向の中心点を写真と一致させる配置が望ましい。そのために前項（2）で記載したように padding-top の値を設定することにより、写真との一体感を出す上下位置に配置し、左右方向は CSS でテキストをセンタリング設定することにより、中央配置とする。
図－2 title と data の位置合わせ(SV)
・高さは固定で、折り返し行を含めて最大２行を想定している。２行を越えた場合にプログラムが破綻することは無いが表示が乱れることになる。固定幅なので、UP 前の事前確認が可能。
（４）三段目
（ａ）三段目は２カラム構成になっている
・左カラムに「撮影データ」を配置し、右カラムは上から「アイコン」、「フッター」の順で配置する。
・左カラムの「撮影データ」は写真との位置関係においてある程度の一体感が必要なため、仮想 mount ブロックの左端と一致する位置まで左に余白を挿入する。具体的には「撮影データ」に padding-left を設定し、その値を動的に制御することにより仮想 mount ブロックの左端と合わせる。その値は、
（（ ブラウザの表示域の幅 － 仮想 mount ブロックの幅 ）／ 2 ） + 10px
で、最後の 10px はデザイン上の行頭インデント値。
・右カラムの「アイコン」と「フッター」は固定サイズで固定位置に表示され、ページの切り替えによって移動しない。
（ｂ）撮影データ
・三段目の左カラムに位置し、上にタイトル（h2）、下にデータ（s_data）と、上下二段構成になっている。
・データ（s_data）はテキストのみで、要素の高さとして折り返し行を含めて4行分を設定している。ソースに何行記述しても結果として４行しか表示されない。
（ｃ）アイコン
・右カラムの上から３番目のボックスで、ページを次に進める、前に戻す、あるいは上階層のインデックスに戻るといった操作を行うアイコンを表示する。
・アイコンは写真がどのように変わってもbodyすなわちブラウザ表示領域の固定ポジションから動かさない。操作性を確保する上で重要なポイントと考えている。
（ｄ）フッター
・著作権マークを表示する。
処理フロー
javascript による処理プログラムの処理フローを備忘録的にPDFにて以下に掲載しておく。