13日の金曜美術館|アトリエ如瓶|ブログ・ヘッダ画像

このブログは、世の中の様々な「黙っていられん!!」ことを書くことを主旨としております。お客様や、お客様になるかも知れない方が読む可能性のあるブログではありますが、(書き手が勝手に決めたものながら)主旨を尊重し、常体文で記述して参ります。何卒お含みおきの上、お読みくださいますようお願いいたします。

外部ファイルをhtml上で表示できない!

ほとんどのウェブサイトには、ヘッダやフッタなど、サイト全体で共通して使われている部分がありますが、これらを別個のパーツとして作成し、どのページにも読み込ませることができれば、年明けにフッタの年号を変更したいときなど、フッタ用のパーツだけ変更すれば、全てのページに反映されるので、メンテナンス性が非常に向上します。
アプリケーションに付随する機能を使ったり、サーバ上で動作するプログラムを使ったりなど、幾つもの方法がありますが、私はjavascriptというブラウザ上で動くプログラムを使い、アトリエ如瓶サイトの共通部分を一括管理できるようにしています。
とはいえ、奥深いjavascriptについては必要が生じたときに最小限の知識をネットで勉強しているため、思うように動作しなくなるとお手上げになります。
今回のケースについての対処法が役に立ったと思える方は少ないでしょうが、備忘録も兼ねて紹介しておきます。ただし長文なので、文末の結論だけ読んでから、内容を読むかどうか判断してくださって構いません。

サイトの構成と経緯

アトリエ如瓶サイトは、本来のトップページの1つ下の階層にトップページを配置しています。
もともと絵描きだった私は、先に絵画作品を紹介するサイトである「13日の金曜美術館」(以降「13金」)を2000年に公開していたのですが、アトリエ如瓶として独立するにあたって、もともとあったトップページから、絵描きとしてのサイトとデザイナーとしてのサイトを振り分けたサイト構成にして、アトリエ如瓶サイトを制作し、2015年に公開しました。どちらも同じパワーバランスで取り組もうという気持ちを、サイト構成に託したわけです。

アトリエ如瓶サイト(以降AJサイト)は、サイト制作も請けようというデザイナーのサイトなので、先述のjavascript(以降js)や、html5、css3など、最新とはいえなくとも、当面は通用すると思われる手法を極力使って作成していましたが、仕事でウェブ更新やバナー作成などの仕事をしていたものの、cssやjsを使って新規サイトを制作するのは大変な作業でした。

経緯はこれくらいにして、問題が起こったのは、cssもjsも申し訳程度にしか使っていなかった13金サイトをアトリエ如瓶サイトと同様に、cssやjsを駆使したサイトにリニューアルしようと思い立ったところから始まります。

 

症状・フッタが表示されない

13日の金曜美術館サイト構成図
13日の金曜美術館サイト構成図

先述の通りのサイト構成ですが、13金サイトの階層にも、AJサイトと同様にcssファイルやjsファイル、また共通して使うパーツのhtmlファイル用のフォルダ(cmnフォルダ。普通はcommonという名前をつけることが多い)を作り、AJサイトをお手本にしながら制作しようとしていたのが、トラブルが起こったときのサイト構成です。
フッタのhtmlファイルに、AJサイトと同じファイルネームを付け、フッタを表示させたいhtmlファイルのheadタグ内でjsフォルダ内に用意しておいたinclude.js(このファイル内で、cmnフォルダ内のフッタ用のhtmlファイルを読み込むように指示)を読み込ませるようにし、フッタを表示させたい位置にwriteFooter("./")と、ここにFooterを書き出してくださいと、AJサイトのjsのコードをコピー&ペーストしました。("./")の部分で、フッタを表示させたいhtmlファイルと同じ階層にあるjsフォルダ内のinclude.jsファイルを読みに行くように指定してあり、jsフォルダと同じ階層にあるフォルダ内のhtmlファイルに表示させたければ("../")としておくわけです。
準備が整ったので、テストサーバに必要なファイルをUPしてみたのですが、用意していたフッタ用のhtmlファイルが全く表示されませんでした。
AJサイトと全く同じようにしているのに何故!?

 

検証と解決

とりあえず、お手本としてしたAJサイトの該当する部分を見直しましたが、表示したいhtmlファイルの位置とjsフォルダ、cmnフォルダ、さらにcssフォルダの位置まで何度も何度も確認し、ミスタイプや階層の指定違いなどないかまで確認しましたが、正常に表示されているAJサイトと差異はありませんでした。
外部のhtmlファイルを読み込むのに参考にしたサイトをもう一度探したり、冒頭でも紹介した他の方法を試そうと検索しまくったり……と、検証だけで土曜を1日潰してしまいました。
翌日の日曜の朝から、更に土曜にやった検証を繰り返したりしましたが、やはり結果は同じでしたが、そのうち、
「ひょっとしたら、全く同じなのが良くなくて、階層の指定や同じファイル名のjsをブラウザが混同し、コンフリクト(=矛盾。この場合も使って良い言葉かどうかは未調査)が起きているのかも知れない!」
と思ったので、13金の階層内のcontents.htmlだけをAJの階層内のindex.htmlがあるのと同じ階層へUPし、AJサイトのURL+contents.htmlを入力してブラウザで表示してみたところ、AJサイトのフッタがバッチリ表示されました。やはり別な階層であったとしても、jsのファイル名やwriteFooter("./")などの指定が全く同じなのがまずかったようです。

テストサーバ内のcontents.htmlの位置をもとに戻し、jsファイルの名前を書き換えたり、writeFooterf("./")(階層/fine/のfを末尾に付けた)と書き換えるなどしてみましたが、結果は同じでした。結局、/fine/と/dns/と振り分けてはあっても、同一サーバ内で複数の同名jsや同じコマンドを使おうとしていることに問題があるのかも知れない……という結論に至りました。
つまり、次の図のようにサイト構成を組み直す必要があるのではないか……と。

13日の金曜美術館サイト構成図(改・抜粋)
13日の金曜美術館サイト構成図(改・抜粋)

図の通り、振り分けた階層ごとにjsフォルダを用意するのをやめ、それぞれの階層用のjsファイルであることが分かるようなファイルネームに書き換えて別々に用意して、1つのjsフォルダ内に保管し、それぞれのhtmlフォルダに必要なjsファイルを読み込ませ、その中で指定してあるhtmlファイルを読み込むように構成を組み直したわけです。
それぞれのjsファイルを図のようにリネームし、13金サイトと、AJサイトと、それぞれ1ファイルずつ、リネームしたjsファイルを読み込むように指定し直して、それぞれをブラウザで表示してみると……バッチリと、ズバリと、それぞれのフッタ部が正常に表示されました。感動のあまり、目頭が熱くなりました。(苦笑)
すでに出来上がっているAJサイトの全てのhtmlファイル内には、リネーム前のinclude.jsを読み込むように指定がしてあったので、修正する手間を考えると暗澹たる気持ちになりましたが、それも漏れなく終えて、無事解決しました。本当はコーディングに使っているDreamweaverを使えば、複数のファイルの同一箇所の検索・置換ができることは知っていたのですが、連日の検証で参っているところに、取り返しのつかない失敗をしそうなのが怖くて、結局手動で書き換えた次第でした。

 

結論!!

同一サイト内で、デザインや構成の違うサイトを別な階層に振り分けて運営しようと思っても、jsファイルは振り分けるのと同じ階層にjsフォルダを作って1フォルダで管理すべし!!

……ということになります。これらの検証と解決のために、まる2日かかったというお粗末でした。
13金サイトのリニューアルは、まだまだ沢山の課題があるので、もう少し時間を頂くことになりそうです。
それにしても、AJサイトもろとも異常がでるならまだ分かるものの、後から作り始めた13金サイトのjsファイルだけに異常があったのは何故だかは分からずじまい……です。

同じようなトラブルに頭を痛める方のお役に立て……るようなことはないでしょうねえ。

今回は、検索で引っかかりそうな字句をたくさん使ったし、できれば参考にしてほしかったので、敬体文で書きました。

さらばハンバーガー

また間を空けてしまったが、久々のブログである。

PCでの閲覧しか考えていない……つまり、モバイル・フレンドリーではない形でスタートした当アトリエのサイトだったのだが、人様には「今どきのホームページは、7割がスマートフォンによる閲覧なので、対応された方がいいですよ」などと言っていたクセに、サイト公開からほぼピッタリ3年経って、ようやくレスポンシブデザインによるサイトが完成した。
長年制作側として様々なサイトを見てきた上で不満に思う部分の幾つかを解消できたサイトに仕上がったと自負している。件名は「体重を減らそうと思っている」ということではない。

世の中のサイトが、PCよりもスマートフォンで閲覧されるようになってきた理由を納得するくらい、私自身もスマートフォンを使うようになってから、調べ物も含めてスマートフォンで閲覧する機会が増えてきた。
その中で気になっていたのが「ハンバーガーメニュー」と呼ばれる≡の格好をしたボタンを押してメニューを開くもので、スマートフォンにも対応したサイトだと、大体の場合左からペロンとメニュー画面がスライドして出てきたりする。2枚のバンズの間にパティ(ハンバーグ)が挟まっている様子と似ているからこう呼ばれるようだが、スマートフォンも大型化していこうというのに、右上隅に配置されていることが多く、指を伸ばすのが億劫なうえ、メニューがペロンと出てきてそれまで見ていたページの大半を隠してしまうと、それまで何を見ていたか忘れてしまうし、下手すれば何を見ようとしていたかも忘れてしまうこともある。
要するに、使い勝手が良くないと思うのである。

なぜこのボタンがトレンドとなり常識化してしまっているのかを考えると、Facebookがこのボタンによるメニュー表示を採用していたことの影響が大きいのではないかと思う。
PCサイトで、膨大なページ数のサイトなどは、スマートフォン対応しようとすると、全面リニューアルということになり費用もかさむが、グローバルナビ部をjQueryやcssを使ってハンバーガーメニュー化してしまい、サイドバーがあればメインコンテンツ下に追いやるなどして、比較的少ない工数で対応できるのもメリットだったのだろうけど、あの使い勝手の悪さはサイト内の回遊を阻害し、高い直帰率を産み出すと思っていたのだ。

一方、PCサイトの頃の設計を引きずっていたのか、画面上端やトップビジュアルの下などにあったグローバルナビが、スクロールに伴って隠れると、フローティングメニューという形で再びグローバルナビが現れる仕組みになっているサイトはチラホラ見かけたが、これも大部分が表示されるのは上部。スマートフォンでは結局エイっと指を伸ばさなくてはならない。
画面が横長のPCでは画期的と言えただろうけれど、クリックしなくてはならない場所へのポインタの移動は少なければ少ないほど、リンクは押してもらいやすくなるのは不変の道理だ。

そこで、私が考えたのは、持つ手の左右に関係なく押しやすく、画面最下部に固定して表示されるグローバルナビ。スクロールしても画面下部に常に表示されているので、見ていたページを遮ったりしなくてよいし、スマートフォンは、殆どの人が縦長の状態でサイトを閲覧するだろうから、ページ下部の10%程度が常にコンテンツを隠していたとしても影響は少ないうえ、片手で持ち替えたりせずに見るべき主要なページを閲覧できるという、高い操作性も兼ね備えている。制作側のメリットとしても、htmlとcssだけで実装できて簡便だし、jQueryなど使うより読み込みも早いと思う。
私はこのグローバルナビの方式を、bottom0ナビ(=ボトムゼロナビ。画面の底からの距離を0として固定することに由来。)と名付けている。

と、スマートフォン時代に万能であるかのように思えるbottom0ナビだが、実は自認する弱点もある。
ナビに配置する項目数が多いと押しにくくなるばかりか、ボタン上の文字を小さくしなくてはならなくなるので、あまり多くのページをナビに組み込めないということ。2018年での普遍的なスマートフォンの画面サイズでの実感として、6つくらいが限界だと思うが、その問題も、当サイトの制作物一覧ページと料金・発注ページで、1つ答えを出した。
必要なページでは、2段目のナビを表示してしまえば良いのだ。これも何も難しい技術を使わずにできるし、当サイトで採用しているボタンのサイズであれば、それほど押し間違いは起こらないと思う。
iPhoneユーザーの私としては、もう1つ問題に感じるのは、ブラウザがsafariの場合、bottom0ナビを押そうとすると、戻るボタンやブックマークボタンのアイコンが表示された黒いメニューがせり出してきて、この動作中にはボタンが反応しなくなり、2度、3度とタップしないと行きたいページへ遷移しないという点も問題点ではある。但しこれは、主にsafariを使っている場合にのみ感じるストレスであって、検証できた1部の他機種や他のブラウザを使えば、bottom0ナビの回遊性の高さを満喫できる。
結局、ハンバーガーメニューの煩わしさに比べれば、大した事ではないと私は思っている。

ただまあ、サイトの性質にもよるのだろうけれど、スマートフォンでの閲覧が中心となるWebの世界で、100ページに及ぶようなサイトが、全体をくまなく回遊されるようなことは現実的ではないと思えるし、Web上に存在するサイトの全てがスリム化していくのではないかと思えるので、きっと私の考案したbottom0ナビは有用になると思う。いや、私がこれを主流にしていくのだ!

……と考え、いっそ実用新案でも申請しようか……と思っていたところ、ちょっと調べてみると、ハンバーガーメニューの問題点について述べた記事が幾つもヒットした。まあ、そりゃそうだが、この道の権威であるジェームズ・アーチャーという人などは、「劣った醜い撲滅すべきものである」などと言いつつ、データ分析結果を元にして、私が直感的に感じていたことと概ね同じ解説をしているようで、bottom0ナビの普及にますます自信を持ったりするわけである。

と、今回のリニューアルを足がかりとして、bottom0ナビを普及させていこうと思うのだけど、肝腎の自分のサイトをスマートフォン対応させたのが、かなり遅くなったのがお恥ずかしいところではある。

ようやくアトリエ如瓶ギャラリー公開

またちょっと間を空けてしまったが、三度目のブログ。

間が空いてしまったのも、ひとたび問題解決できて順調だったので、何とか13日には公開に漕ぎ着けようと頑張っていたのだが、制作物一覧ページにjavascriptによるLightBoxを仕込もうとしたところ、設置に成功した代わりにヘッダ、フッタ、右サイドバーなどの同じくjavascriptを使って読み込んでいた部分が表示されなくなってしまった…というトラブルに見舞われたためだった。

javascriptも、テーブルでのレイアウトによるコーディングが中心だった頃から部分的にちょくちょく使ってはいたが、それらはごく一部分だったし、とても使いこなしているというレベルではなかった。
アトリエ如瓶ギャラリーでは、共通部分を外部から読み込むとか、トップビジュアルの画像の自動的な切り替えなどをjavascriptを使って初めて盛り込んだのであって、どうにか駆使して公開にこぎつけただけでも、ご褒美に自分を女性が相手してくれるお店に連れて行って飲ましてやりたいくらいなのだが、本当にこれで大丈夫なのかなあと思っていたら、製作も大詰めになってから、愕然とするような不具合に出くわしてしまったのである。

タブブラウザが一般的になって、拡大する画像だけを新規タブで開くような動作は、やはり大げさに感じるし、どこか前時代的な処理のような気がするので、LightBoxで拡大画像を小ぢんまりと(?)見られるようにしたかったのだが、当面は保留とすることにした。
ただ、諦めきれずに原因を探ってみると、javascriptのonLoadという処理が、同一ページ内で2回以上使われると、最後に読み込まれた部分以外は無効となってしまうという記述を見つけることができ、対処法も紹介されていたのだが、自分でやってみるとうまく行かず、自分の不勉強とjavascriptの奥深さというか難しさというか、そんなものを感じずにはいられなかった。

LightBoxの実装に成功したとしても、それが閲覧者の関心を集めるのも、あと2~3年くらいなのではないかと思うし、トップビジュアルの画像の切り替えなども、見る人によっては陳腐なのかもしれない。「新しい技術」などという呼称は儚いものだし、技術的な部分は外注してしまうというテだってある。
そう考えると、デザイナーを自称し、存在価値を色あせないものとするためには、技術以外の部分……発想力とか、配色のセンスとか、ユーザビリティの高いサイトの設計とか、そういう部分で勝負できるようでありたいと、私は考えていて……もう寝ます。ここ数日あまり寝てなかったりして。

想定より1日遅れたけれど、どうにかUPできてめでたしめでたし……であります。ご用の方、遠慮なくご発注の程を。