１．デバイスの違いを越えて
パソコンを基準に考えていたとき、レスポンシブデザインのテーマは、元々パソコン用に整理したデータをスマホの狭い画面にいかに効率的・効果的に配置し直すかといったことだった。しかし、このホームページのメインテーマは「写真」であって、追求すべきは、限られたスペースに写真を大きく、見やすく、操作しやすく表示するための手法なのだ。そう考えると、単に"スマホ"ではなく、スマホの縦画面と横画面の違いや操作性など、さらに踏み込んだデザイン思考が必要なのではないかと思うようになった。
このような動機で今回のリニューアルに取り組むこととなった。
最初に、デバイスの違いではなくて、PCではブラウザの表示領域、モバイルではスクリーンのサイズに着目し、それらの表示領域とそこに表示する写真のアスペクト比を足掛かりにデザインを考えることとした。モバイル端末は、アプリを使わない限りブラウザの全画面表示と同じ状態と捉えることができるため、「ブラウザの表示領域（ javascript でいうところの document.clientWidth/clientHeight ）」と捉えて全端末を同じ尺度で把握することとした。
（1）アスペクト比
最初に「アスペクト比」について検証してみた。一般的にフルサイズ写真のアスペクト比は「3:2」と表示される。これは「横３、縦２」という意味で、最初に横、次に縦をコロンで区切って整数を並べる。しかし、プログラムで扱う場合は計算式の都合から単数にする必要がある。
アスペクト比を単数で表現する方法を調べてみると、
・建築分野では、縦サイズ ÷ 横サイズ
・IT分野では、横サイズ ÷ 縦サイズ
なのだそうだ。一般的に「縦横サイズ」とは言うが「横縦サイズ」とは言わないと思う。つまり、「縦」が先なのだ。ならば、その「縦」は分子なのか分母なのか、答えは、建築分野では分子、IT分野では分母ということになる。個人的には建築分野の方が感覚的にしっくりとくる（細かなことだが）。
しかし、プログラムで使う数値であれば、ここはあえてIT分野に合わせるしかないだろうということで、
とした。文章では「横：縦」、「横縦」または「横×縦」の形で表記する。
そして、インタプリタ言語による計算上、桁数にも配慮が必要で、原則として小数点以下４桁に丸めることとした。扱う写真の横または縦の画素数は多くても千の桁なので、小数点以下４桁であれば、１ピクセルに対して四捨五入が過不足なく適用できると考えたためだ。
（2）ブラウザ表示領域の形状と写真のアスペクト比を比較
ブラウザの表示領域と写真のアスペクト比を組み合わせると表－１のように単純に４つのパターンに分類できる。
アスペクト比が１未満の場合を「縦長」とし、アスペクト比が１以上の場合を「横長」としている。
表示領域
サイズ
２．左利き対応画面
（1）なぜ左利き対応レイアウトが必要か
ページをめくるときにクリック／タップするアイコンは、マウスで操作する場合には、画面のどの位置にあっても特に問題はないと思う。しかし、スマホの場合、タップするとき指で画面が覆われて見えなくなる。これは煩わしい。なので、右手の人差し指で操作するのであればアイコンは画面の右下隅というのが合理的ではないだろうか。そう考えると、左利きの人、あるいは右利きでも都合で左手で操作したい人にとっては、左下隅が良いということになる。そこで、右手／左手に対応するためにレイアウトの切り替えの機能を備えることとした。
（2）右利き・左利きの意思表示
統計によると左利きの人は約 10% とのことで、デフォルトは右利きにするとして、"左手で操作したい"という意思表示とその情報をどのように保持するかを最初に考えなければならない。
各画面の中に「右・左」切り替えのアイコンを配置すれば分かり易いのだが、事情があってそれはしたくない。事情というのは、写真表示の画面がそれぞれ１枚の完結した HTML ページになっていて、全体でおよそ 1000 枚になる。その全部を修正する作業は大変なボリュームになる。修正するとしてもソースの修正範囲を極力限定し、同じ記述を同じ場所に追加・置き換えするようにすれば、エディタの機能をフルに活用して作業を少しは効率化できるのだが、今回はあえてそれをしないこととした。
もっと早い時期から、フォトビューワとしての位置づけを明確にし、１つのページに写真のアドレスと必要な付加情報を渡す形でサイトを作り上げれば、データベースとの連携も視野に入り、いろいろな切り口から"ブック"的な構成も可能だったのだが、ページを単純にコピーして必要な部分だけ書き換えるという簡単さにかまけてしまったということなのだ。まあ、ここまで大きくなると考えていなかったこともある。
さて、それではどうするか、そもそも左右利き手の切り替えはそう頻繁に行うことではない。そう考えると、切り替えアイコンが常に表示されていること自体に煩わしさを感じてしまうのではないか、と考え、トップページに「設定」アイコンを追加して、そこから左右利き手の設定を行うページに入る形とした。
（3）利き手登録の方法
利き手を登録するページは一般的なラジオボタン形式で、選択して設定ボタンをクリックする形とした。TOPページからリンクする set_sp.html ページにて操作を行う。
利き手の登録は個人を認識して登録するほどのものではないため、ログインやクッキーを使うような本格的な仕組みは必要なく、タブを閉じれば消滅して良いものなので、結局 sessionStorage を使うことにした。
最近のブラウザでは問題なく使用できるのだろうが、WebStorage の使用可否に加えて sessionStorage の使用可否を確認し、かつエラー処理もぬかりなく行い、問題があれば、右利きオンリーで機能するように安全性を優先した。これらの処理は set_sp.html 内に記述した Javascript によって行う。
Javascriptは外部モジュールとしていないが便宜上 hand.js として管理している。 hand.js の処理フローを次に示す。
（4）左利きレイアウトの特徴
左利きレイアウトは基本的には右利きレイアウトを左右対称に入れ替えるだけで良いと思っていたのだが、よく考えたみるとそうもいかない部分が見えてきた。
写真のサイズに色々なバリエーションがあり、写真全体を包含するボックスの配置を優先したうえで、個々の写真によって重心位置が移動しないようにしたい。そのため、写真のサイズによって左端の位置が移動し、写真と適切な隙間をとって配置したいタイトル文の位置にも影響が及ぶこととなる。
写真ページ１枚ごとに CSS で細部の設定を行えば問題のないことであるが、個々の写真の事情はイメージデータの URL と、タイトル、撮影データのみで、その他の部分の HTML / CSS は全ページ共通になっている。さらに、レスポンシブ前提のページ作りのため、共通化・標準化されたロジックによって位置決めしなければならない。
基本的には Grid や Flex によってレイアウトするのであるが、ひとつ困難な条件がある。
・写真はタイトルの位置にかかわらず写真のサイズによる都合で左右方向の位置が決まる。
・タイトルは文字数、行数とも可変で、複数行となる場合は左詰めで記述する。
・タイトルボックスの水平・垂直位置を調整して写真との距離(隙間)を一定にする。
この制御を行うためには、そもそもタイトルの幅 ( width ) が決まっていなければならない。しかし、grid の子要素は親要素で決められた幅の制約は受けるものの、子要素自体の width 属性は初期値 auto のままで、javascript で width 値を取得すると親要素によって与えられた幅の数値が返ってくる。
タイトルボックス内の文字数に応じた実態としての width が取得できないわけで、これでは子要素の左右位置を margin や padding で制御することができない。
これを無理やりやろうとすれば、タイトルの文字数から width 値を算出する方法もあるかもしれないが、明示的な改行だけではなくて英単語などの自動折り返しなどの行末処理もあり、そこまでプログラムで追従できるかと言われるととても自信が持てない。
色々と試行錯誤しているうち、自動折り返しが無いという条件がつくが、子要素に justify-self を指定すると子要素に実態としての width 値が発生することが分かった。意図的に改行を指定して複数行になった場合も実態としての width 値が発生する。タイトルは CSS 上は固定幅なので、個々の写真の HTML を記述するときにタイトルが自動改行とならないように行幅を意識して必要の都度改行を明示的に指定すれば問題ない。
フォントは最終的にはブラウザ任せになるので、余裕を持った文字数制限を運用上の注意事項として意識すればクリアできると思う。
３．画面レイアウトの基本パターン
ここまでの検討要素を色々と考えた結果、表-1 から、ブラウザ表示領域を横長と縦長でレイアウトを大きく２つに分けることにした。横長画面はスマホの横画面とパソコンのディスプレイを念頭に置いてのこと。
画面のレイアウトを考える上で、やはり、スマホ対応がクリチカルな条件になってくる。スマホでブラウザを起動すると、画面上部にアドレスバーが居座り、スマホを横にした場合は、画面の縦幅を大きく損ねる存在になる。このアドレスバーは「設定」を手操作して非表示にはできるものの、HTML / CSS / Javascript によって自動的に非表示にすることはできない。セキュリティ対策上の制約によるものと思われる。これがアプリの利用が広まる要因にもなっていると思う。
結局、各パターンに対応した画面レイアウトは次の表－2のようになる。
区分
レイアウト
レイアウト
レイアウト
レイアウト
レイアウト
レイアウト
細部の検証をしてみると、画面横長レイアウトの場合に微妙な領域が存在することがわかった。ほとんどパソコンの場合に限定されると思うが、具体的には、ブラウザ表示領域が横長とはいっても正方形に近い横長画面で、かつ写真は縦長とは言っても正方形の近い縦長の場合だ。６×６のブローニー版では 56mm×56mm が一般的なフィルムサイズだがスキャンして整形した結果微妙に縦が長くなるということもある。また、トリミングの結果、正方形に近い縦長写真となる場合もあるだろう。
レイアウトの構成部分を考えると、可変サイズとなる写真部分の他、タイトルや撮影データ、ページ切り替えのアイコン類など、ほとんど固定サイズの要素も含まれるわけで、固定部分と可変形部分を合わせたレイアウトになる。このようなボックス構造で写真の部分の形状が変化した場合、ボックス全体としてはどのように変形するのだろうか。
計算でクリチカルなポイントが見つかるかどうか確認したかったのだが、自分の数学能力では関数式を完成させることができず、やむなく、固定レイアウト部分がある程度固まった段階で EXCEL でシュミレーションしてみることとした。
結果、確かに微妙な部分はある。つまり画面が横長であっても縦長レイアウトを採用した方が写真の表示面積がわずかに大きくなるケースがあることが分かった。しかし、ここまで確認して、その些細な部分のために、画面が横長であっても、その該当する写真だけ縦長レイアウトに切り替えることのリスクに気づいた。それは、今回のリニューアルのある意味大きなテーマでもあるが、連続的に写真を閲覧するときの閲覧の快適性と操作性に関して次の２点を改善することであった。
・視線の中心が大きく移動しないこと
・ページ切り替えのアイコンの位置が移動しないこと
画面横長と画面縦長の間で上記条件を満たすことは無理がある。結局、ここまで確認して、表－２の考え方が正しいことに自信を持てるようになった。
※ 追記
この時点で整理しておいた方が良いと思いあえてここで記述するのだが、HTML の「wrapper」と「container」のどちらを使うかという問題。簡単に考えるとどちらでもよいとは思うが、ここでは「container」を使用している。「container」で囲んだ要素をデザイン構成の中でより積極的に認識し、制御する対象としているからで、単に「全体」として包み込むだけの位置づけとは少し異なるというのがその理由。
４．レイアウト切り替えの方法
（１）Javascript によって、ブラウザ表示領域の Width（Element.clientWidthプロパティによる）と Height（Element.clientHeightプロパティによる）を取得し、そこからスクリーンアスペクト比を算出する。
（２）スクリーンアスペクト比が１未満の場合は、縦長画面と判定し、利き手判定関数からの返り値によって「縦長画面右手レイアウト(SV21」と「縦長画面左手レイアウト(SV22」に分け、それぞれ専用のCSSを割り当て、加えて Javascript によって算出した各種変数の値を CSS に動的に反映させて細部を調整する。
（３）スクリーンアスペクト比が１以上の場合は、横長画面と判定し、利き手判定関数からの返り値によって「横長画面右手レイアウト(SB11」と「横長画面左手レイアウト(SB12」に分け、それぞれ専用のCSSを割り当て、加えて Javascript によって算出した各種変数の値を CSS に動的に反映させて細部を調整する。
（４）レイアウト切り替えのタイミングは次の方法による。
（ａ）HTML ソースロード完了直後に Javascript プログラムを起動し、レイアウトの選択と適用を行う。
（ｂ）端末がローテーションされた場合に備えて orientationchange イベントを addEventListener メソッドに登録することにより、端末の回転を検知して window.onload イベントを発行し、ページをリロードする。
（ｃ）ブラウザの表示領域サイズが変更された場合に備えて window.onresize イベントを addEventListener メソッドに登録することにより、ブラウザの表示領域サイズ変更を検知して window.onload イベントを発行し、ページをリロードする。
５．レイアウトの説明
表－２の処理パターンごとにレイアウトを変えており、それぞれ専用のCSSを設定している。
各レイアウトの詳細と各レイアウトごとの処理内容は個別ページを参照のこと。
６．処理フロー
Javascriptのソースをほぼ１ステップごとにフローチャートで表現したものを備忘録としてPDFで掲載。