ホーム > ブログ・サイト > サイト整備

サイト整備のアーカイブ

サイトにスマートフォン対策を施した

はじめに

このブログ「散歩の思考」のほか、ぼくは二つのサイトを運営している。ゼミの別館サイト「hajimedia.net」と、旅の記録をまとめておく「さんぽのしっぽ」である。これら二つのサイトについて、このたびレスポンシブ化をはかり、スマートフォン対策を施した。

完成したサイトにiPhoneでアクセスすると、こんなふうに見える。

150821responsive01

スマートフォン対策とは、ようするに、解像度の小さなデバイスでアクセスしたばあいに見やすくするということである。WordPressで運用しているこのブログについては、対応プラグインを導入したおかげで、すでにずっと前に対策済み。しかし、CSSもHTMLもじぶんで手書きしている二つのサイトについては、自力でなんとかする必要があった。

まず、試しにグーグルの「モバイルフレンドリー・テスト」というのにかける。すると、こんなふうに、叱られてしまうわけだ。

150821mobfri01

もちろんグーグルに何をいわれたところで、それに強制力があるわけではない。かれらは権威でもなければ規範でもない(いちおうは)。特段の対応はしないという手だってある。個人のサイトなので、そういう選択肢があっても、ぜんぜんかまわないだろう。だが今回は、じぶんの勉強という意味もあって、チャレンジしてみることにした。

具体的には、どんな方法があるのか。いろいろ調べてみたものの、ネットの情報はどうも断片的で、全体像がつかみにくい。本を読めばいいのだが、本屋まで出かけてゆく時間も気力もない。そこで、いつもながらの我流で、とにかくあれこれいじっては直しをひたすら繰りかえしながら、じぶんなりに方法を見つけてゆくことになった。

基本方針

方針は簡単明瞭だ。とにかく最小限の手間でスマートフォンに対応すること、である。そのうえで、三点に整理してみた。

  1. 既存のHTMLには原則として手をくわえず、そのままつかう。スマートフォン用に別ファイルを用意するようなこともしない。
  2. CSSは既存のものを極力いかし、変更は最小限とする。
  3. 無理をせず、できる範囲の対応にとどめる。たとえば、hajimediaの学生制作パートや、「さんぽのしっぽ」の旧サイト・アーカイヴなどはスマートフォン対応から除外する。

途中いろいろ苦労したのだが、そこは省略することにして、ともかく結果的には、おおむね方針どおりに実現することができた。

レスポンシブ化とブレークポイントの設定

まず、HTMLは既存のものをつかい、アクセスしてくるデバイスの解像度におうじて組版の仕方を変えることにした。いわゆるレスポンシブ化というやつである。

といっても、既存のCSSのほかに、スマートフォン用をひとつ用意しただけ。試してみたかぎり、ぼくのサイトではこの二つに切り分けすれば問題なさそうだった。

機種によって解像度は異なる。iPhoneやiPadのみならず、Androidまで考えると、もうほんとうにまちまちだ。それら何種類ものデバイスに細かくいちいち対応させるべきですみたいなことを主張するサイトも見かけた。だが、申しわけないのだけれど、それは面倒きわまりない。そんなふうに生真面目に考えるのはやめにした。

そこで、ブレークポイントを767pxとし、それ以下についてのみ小画面対策を施すことにした。ようするに、PCやiPadで閲覧を想定したデザイン(既存)に、iPhoneなど767px以下の小画面を想定したデザインを追加で用意し、つごう二種類のデザインにしたということである。

もともとぼくのサイトは横幅800pxで設定しており、デザインもシンプルなので、この二つに切り分けさえすれば、十分に対応できるだろうと考えたわけだ。

iPhoneで見ると

対応が完了したトップページをぼくのiPhone5Sで見てみと、こんな感じで表示される。これは「hajimedia」のばあい。

150821responsive02

本編はこんな感じの体裁となる。やはり「hajimedia」から。

150821responsive03

150821responsive04

もちろん、こう見えるのはスマートフォンなどでアクセスしたばあいのみ。パソコンやiPadなどでは、いままでと同じ体裁で見える。

いずれも、HTMLファイルのメタ情報のところに下の一文を追記してある。

<meta name="viewport" content="width=device-width, initial-scale=1.0">

グーグルによれば「ビューポートは携帯端末でのウェブページの表示方法を制御します」とのこと。これをすべての既存のHTMLにコピペで貼りつけ、アップロードしなおした。

そのうえで、どんなときにどんな組版にするかについては、既存のCSSに、メディアクエリをつかってスマートフォン用の記述を追記することで、体裁をコントロールしている。

CSSは既存のものだから、そこにはすでにPC用の記述がなされている。つまり、それはグローバルに宣言されている状態である。だから、メディアクエリでの追記ぶんとは、それとの差分だけを記述しておけばいいことになる。

たとえばこれは、bodyを記述したCSSの追加記述箇所だ(実際よりもやや簡略化してある)。


/* 
  横幅767px以下に適用
  ================================================= */

  @media screen and (max-width: 767px) {
  	
    body {
      -webkit-text-size-adjust: 100%;
      color: #333333;
    }
  
  }

メディアクエリをつかった理由

ぼくの採ったような既存CSSへの追記という方法ではなく、CSSを切り分け、スマートフォン用CSSを新規に用意することを勧めるサイトも少なくなかった。メディアクエリをつかうと、CSSの記述が長くなるという批判が、その根拠にあるようだった。

だがぼくのばあい、それはあまり合理的ではなさそうだった。

もしサイトのデザインを一枚のCSSに書き込んであるのであれば、それを複製したうえで、スマートフォン用の記述に変更したものを別名で保存し、専用CSSとすればいいとおもう。

一方ぼくは、すでにCSSをパーツごとに分割しており、HTMLのほうで必要なパーツのCSSを読み込むように設定している。だから、それぞれのパーツごとのCSSの末尾に、スマートフォン用の記述だけを追記しておくほうが、管理が断然しやすく、合理的だと考えた。

CSS指定のツボ

CSSの記述をスマートフォン用に対応させるさいの最大の要点は、二つある。

ひとつは、横幅などをピクセル単位で管理するのではなく、%による相対値で指定しておくということだという。デバイスによって解像度が異なるため、特定の解像度を前提しないということらしい。

もうひとつは、段組のような、floatをつかって横にならべるようなデザインをなるべく排すること。小画面ではそのほうが読みやすいという。

段組をつかっているのは、ぼくのばあいはトップページくらいなので、CSSの当該箇所に

float: none;

を追記してfloatをやめ、一段組に変更した。また、floatをつかって実現しているグローバルナビについては、携帯端末用の画面では省略することにした。

ただ、本文中に写真を二枚横にならべて配置するという体裁をときどきつかっている。そのレイアウトだけは、できればスマートフォンの画面でも残しておきたかった。ここをどう記述すればいいのか、先行事例が見つからず、仕方なく試行錯誤しながら自力でひねりだした。けっきょく、こんなふうに記述することにした。わかりやすくするため、下のソースコードからはmarginとpaddingの設定を省略してある。


	.img_twocolumn_w640 {
		width: 100%;
		height: auto;
	}

	.img_twocolumn_w640_left {
		max-width: 49%;
		height: auto;
		float: left;
	}

	.img_twocolumn_w640_right {
		max-width: 49%;
		height: auto;
		float: right;
	}

	.img_twocolumn_w640_left img {
		max-width: 100%;
		height: auto;
	}

	.img_twocolumn_w640_right img {
		max-width: 100%;
		height: auto;
	}

要点としては、floatはそのまま活かしつつ、widthの指定をセオリーどおり相対値で指定しなおしたことだ。このとき、横に2枚ならびながら画面横幅いっぱいになるように設定した。各写真の横幅を49%にしているのは、段間(写真と写真の間隔)をあけるためである。また、高さの記述も省略せず、きっちり書いておいたほうがいいようだった。

iPhoneで見ると、こんなふう。ちゃんと写真が横に二枚ならんでいるだろう。「さんぽのしっぽ」の本編から。

150821responsive05

iPhoneを横にしてみても、このように、横に二枚ならぶ配置は維持されている。写真のサイズが大きくなっているのは、画面横幅にあわせて拡大されるからだ。

150821responsive06

モバイルフレンドリー・テストにも合格

作業の完了したサイトを、あらためてグーグルのモバイルフレンドリー・テストにかけてみた。すると、こんなふうに言ってもらえる。

150821mobfri02

いちおうサイト全体をレスポンシブ化をはかったのだが、先述したとおり例外はある。「hajimedia」のばあいは、先述したように学生制作パートがそうであるし、「さんぽのしっぽ」では初代サイト・アーカイヴが例外である。

前者は学生たちが体裁も考えてつくったものだ。CSSもつかったりつかわなかったりしている。いまさらぼくが手をくわえるのも筋違いというものだろう。後者はなにしろ古いサイトで、コードを手書きしてもいなければ、CSSもつかっていない。したがって、これらについては、各HTMLにviewportを追記するだけにとどめ、それ以上の対策は施していない。

たしかに、iPhoneでアクセスすると、ちょっと画面からはみ出してしまう。

150821responsive07

それでもちょっと縮小すればいいだけのことで、実際的には、まあそう大きな問題はないだろうとおもう。

150821responsive08

こういうことは100%の完璧さを追求するようなものではなく、だいたいうまく収まれば良しとするべきものである。とくに個人サイトのばあいは。

ローカルでの確認はWeb共有機能で

なお、作業はローカルでおこなったが、iPhone上での確認をどうすればいいか、最初はわからなかった。Macのウェブ共有機能をつかうと、無線LAN経由でiPhoneがiMacに直接アクセスできるので、それでローカルにおいてあるサイトのフォルダへアクセスすればよいことがわかった。

 *誤字と文言を修正、一部の図版をケイ囲みにした。(150825)

BiNDとiWebとサイトリニューアル(下)

BiNDでつくった旧サイトを公開したのが昨年の9月。翌月には、もうこのサイトを見るのが嫌になっていた。じぶんでつくっておきながら、あんまりといえばあんまりな話ではある。でも言い分がないわけではない。

デザインの好悪は別として、ともかくこんな凝ったデザインを必要としていない。ぼくにとって、ウェブサイトはどちらかといえばアーカイヴという位置づけだ。デザインも構成もなるべくシンプルでよい。Flashなど目先を刺戟するものも、すぐに厭きるだけなのでいらない。検索エンジンに少しでも多くヒットしてほしいともおもっていない。ウェブで商売をしているわけではないからだ。簡潔かつ合理的なデザインを与えられたサイトに、じぶんの仕事(のある部分)を少しずつ蓄積してゆければ、それで十分である(モダニストだなあ、われながら)。

いまさら昔のようにエディタでタグを手で打つ気力も時間も持ちあわせていないが、十数年前に戻ってFireworksとDreamweaverでウェブを構築してみようかという気持ちもなかったわけではない。当時はこの2本にJeditをくわえた3本のアプリケーションをつかって「子づれ散歩旅の絵本」というサイトを運営していたのだ(現在は閉鎖。近日中にべつの形で復活予定だが、「近日」がいつになるかは誰にもわからない)。

このときは、末期には作業量がやたらにふくれあがってしまい、ずいぶん苦しめられた。ページのレイアウトから何から全部手動であり、しかも新着ページの一部をトップページにも表示させることを、ソフトウエアの機能としてではなく、手入力でやっていた。のちにブログ構築ソフトウエアとしてMovableTypeを知ったとき、「このソフトウエアが実現している機能を人力でやっていたわけだ」とようやくわかった。もとより無茶な話ではある。あのころのやり方に戻るのは、やっぱり現実的とはいえまい。

今夏にはBiNDの新バージョン(3のこと)が発売されますぜという販促メールが矢継ぎ早に届くようになった。迷わないではなかったが、やっぱり購入は見送った。もっと手軽なウェブ構築ソフトとして、すでに手許にiWeb(09)があることを思い出したからだ。なにせiLifeを買えば否応なく付いてくる。初めはちょっと試しにいじってみただけだった。そこにたちまち生来の凝り性がむくむくと頭をもたげ、気がつけばこの一週間ほぼかかりきりで、iWeb上にあらためてウェブをリニューアルすることになっていた。

iWebは初心者向けということもあってソフトウエアとしてはつかいやすい部類に入るだろう。インターフェイスや操作法には独特の癖があるのだが、ふだん授業や講演用にKeynoteをつかい倒して慣れているのでさほど問題はない。機能面としては、できることはできるし、できないことはできない。たとえば昨今かまびすしい検索エンジン対策、いわゆるSEO対策などはやりにくい。初期のiWebでは文字がぜんぶ画像データに変換されるという荒技を駆使していたそうだが、いまはそこまでご無体な真似はしないようだ。それでもとにかく、割り切るところはすっぱり割り切っている。Appleのコンシューマー向けソフトウエアらしい。なんでもできるBiNDの対極にあるといってもよい。

調子に乗って、最初の版はすぐできた。試しにローカルに書き出してブラウザで確認してみる。あれれ、レイアウトが崩れまくりではないか。

とくに目も当てられないのが、行間が局所的に狭くなったり、書体が突発的に変わったりする現象である。しかも地滑り的に頻出している。「iWebでお手軽ホームページ」という懇切丁寧な個人運営のウェブサイトをみつけ、そこに書かれていた方法にしたがって修正する。行間はとくにIEでブラウズしたとき崩れがちであり、きちんと表示させるためには「固定値」を選んでポイント指定するとよい、とある。そうしてみるのだが、何度やり直しても、崩れは修正できない。

そればかりではない。文字を打ち込むテキストボックスと、その直下に配置した画像ボックスとのあいだに無意味な空白が入ってしまい、どうやっても詰められない。たちの悪いことに、iWeb上ではきちんと詰めて配置して表示されるのに、HTMLに書き出してブラウザで確認すると、発生するのである。

あれこれいじっているうちに、行間は固定値ではなく倍数、つまり行で指定すればうまく行くことがわかった。これだと行間は、日本語に部分的に英語が混じっていても一定で表示される。さらに、配置したボックスどうしがズレることもない。どうも固定値より相対的な指定の仕方のほうがよさそうである。

ナビゲーションメニューも、テンプレートのものそのままではつかいにくい。たとえばクリックして外部リンクへ一発で跳ぶように指定できない。とおもっていたら、メニューごと消してしまえることがわかった。インスペクタのファイルからチェックボックスのチェックをはずすだけだ。ヘッダにあらためて文字ボックスを用意して、しかるべき書体やポイントを指定し、手でリンクを貼ればよい。旧いiWebだとレンタルサーバーへのアップロードは面倒だという話だったが、現行のiWeb3.0ではなんの問題もなく完了。

そういうわけで、リニューアル・オープンした新SwingBooks Websiteは、ひたすら質実剛健を旨にできあがった。

自由は不自由、不自由は自由、というのが今回の教訓。シェイクスピアみたいである。

BiNDとiWebとサイトリニューアル(上)に戻る

BiNDとiWebとサイトリニューアル(上)

091008swingbookswebsite.jpg

ひさしぶりにウェブ構築の話題。

台風18号が駆け抜けていった日の晩、SwingBooksのメインの──といっても更新頻度はブログと比較にならないほど低いのだが──ウェブサイトをリニューアルした。デザイン一新。ごらんのとおり、もうシンプルこのうえない。

じつは前回の更新は昨秋の11月末。長らく放置していた元凶はぼくの怠慢だとして、それ以外にも理由がある。それは、旧サイト構築につかっていたBiND for WebLife2というアプリケーションが、どうも性に合わなかったことだ。

この9月にver.3が出たこのアプリには、凝りに凝ったテンプレートがカートリッジという名で梱包されている。そこから好みのものを選び、あとは見出しやら本文やら写真やらといった個々のパーツに中身を流し込んでつくってゆく。それだけで、プロがつくったみたいな凝ったサイトができあがる、というコンセプトが売りだ。

たしかに触れ込みどおり、まるでプロのウェブデザイナーが組んだみたいなサイトができあがる。旧サイトをごらんになったことのある方はわかるとおり、あんな水準のデザインはぼくの独力ではとうていつくることはできまい。お金をだしてアプリを買ったからゆえの賜物というべきである。BiNDはよくできたアプリであり、世の中にはその特徴を存分に活かしてサイトをつくっているひとも少なくなかろう。だがぼく個人にとっては、それゆえに発生する問題点のほうが大きいことがわかった。

それは束縛感である。アプリケーションにウェブをつくらされているという感覚が拭えなかったのだ。

テンプレートが凝りまくっているぶん、デザインにじぶんのつくるサイトの中身を当てはめていかなければならない。じっさいトップページなど手頃なテンプレートがなかったため、新着情報やら更新履歴やらといった項目を無理やりつくり、そこを埋めていかなければならなかった。ぼくのばあい、お知らせなどはブログで扱えばよいはずであり、サイトにそんな欄は不要だったのだが、テンプレートに項目がある以上、そこを埋めざるをえない。むろん小変更は可能なのだが、そうするとデザイン的にちょっと間が抜けてしまう。

Signとよばれる、バナーやボタンをつくるウィジットみたいなミニアプリも付属していた。ぼくにはPhotoshopやIllustratorのほうがよほど扱いやすかったが、これらをもたないユーザーにとってはBiNDひとつで全部をまかなえるという意味で有用なのだろう。しかし、これも機能的にはひじょうに限定されており、中途半端だ。しかも重くて、よく落ちる。にもかかわらず、BiNDでサイトを構築している限りにおいては、Signをつかえば一体的に運用できるから、ついつい使用してしまう。ここにジレンマが生じる。

そして、Signにかぎらず、このBiNDというアプリケーションは全体として、iMacでつかっていてもかなり動作がもっさりして重かった。BiND以前につかってみたことのあるIDというFlashをつかったウェブ構築ソフト(同じくデジタルステージの製品)もやはり重かった。

ようするに、BiNDはなんでもできる自由を謳いながら、それゆえにひじょうに不自由なアプリケーションだった。ぼくにとっては。

(*091011題名変更、本文一部修正。)

BiNDとiWebとサイトリニューアル(下)へ

ホーム > ブログ・サイト > サイト整備

Related Other Sites
Recent Posts
Categories
  • ゼミ・授業 (144)
  • 考えたこと (131)
  • 日にち雑記 (240)
Pages
Monthly Archives
Search This Site
Subscribe SwingBooks
Lab & Seminar
RSS hajime-semi Blog
  • 積み重ねの先にあるもの 2016年11月27日
     こんにちは。<チャーリー>です。 とうとう、卒論のゼミ内提出までの日数は残り1ヶ月を切りました。最近わたしが […]
    長谷川ゼミ
Meta

ページの上部に戻る