第12回 WordBench 神戸でお勉強

この記事をフルスクリーンで見るフルスクリーンモードを終了するには Esc キーを押してください。または、ココをクリックしてください。

WordBench KOBE Badges

今回は、特に内容が濃い :-D
濃いといっても『WordPress の専門的で難しい内容』というわけではなく、WordBench 神戸のメンバーの皆さんによるアンケートの結果、最近話題のレスポンシブ Web デザインや実例を題材にしたテーマが今回の勉強会の内容です。
しかし、実例となると『カスタム投稿タイプ』や『カスタムフィールド』という機能が、最近の事例では必ずといっていいほど使われていますので、初心者の方にはちょっと難しかったかも知れませんね。
そういう私も実例の紹介などでは、ついていくのがやっとだったり、理解しきれていないことも多々ありましたけど…

  • レスポンシブルなテーマの作り方 @HissyNC
  • WordPress 事例の徹底解説 @tkc49
  • WordPress 3.4特集 @bren_boss

というのが、第12回 WordBench 神戸のテーマ。

レスポンシブルなテーマの作り方

最近、何かと話題のレスポンシブ Web デザイン。
はじめてレスポンシブ Web デザインが紹介されてから2年ほど経ちますが、スマートフォンやタブレットの登場による色々なサイズのスクリーンに対応させる手段として最近になってより注目されているのだと思います。

セッション内容は、レスポンシブルなテーマの作り方をご覧くださいませ。
当日、@HissyNC さんもおっしゃっていましたけど、WordPress のテーマの話というより『レスポンシブ Web デザインとは?』という内容になっているかも知れませんが、レスポンシブ Web デザインの概要やメリット・デメリット、制作ポイントなど、レスポンシブ Web デザインを理解するにはとても良い資料だと思います。
資料にもありますが、レスポンシブ Web デザインとは、ワンソース・マルチユース(One Source Multi-Use)という発想のもと、様々な解像度に対応させて表示を切り替える手法です。
しかし、実際には解像度で切り替えるというよりは、各デバイスで表示を切り替えるという認識でレスポンシブ Web デザインを取り入れている方が多いと思います。
ただ、4.3インチの画面サイズで解像度が1,280 × 720というようなスマートフォンもありますので、レスポンシブ Web デザインを取り入れたサイトが『スマートフォン用に最適化された表示になるか』というのは難しい問題です。
と、言うものの、現在打ち合わせをしている案件でも「スマートフォンでも見られるようにしてください。」と言われましたので、今後スマートフォン対応を求められるケースは増えていくと思います。(スマートフォンの場合、基本的には PC と同じ表示をしますので、見られるというよりは『スマートフォンに適した見え方』ということでしょうね。)
でも、『スマートフォンに対応させたいけども予算もあまりない。』というような場合に制作コストとの兼ね合いでレスポンシブ Web デザインを採用するメリットは大きいのかも知れません。
少し前の記事に書きましたが、カネボウ化粧品のサイトのように640px 以下のサイズで表示した時に、大幅にデザインを変えてしまうような場合は、制作コストの削減にはならず反対にコストは高くなるケースもあると思います。

あと、ワンソース・マルチユースですので、ソースの管理やメンテナンスが比較的楽だというのもメリット、コスト削減に繋がるかも知れませんね。
しかし、ワンソース・マルチユースであるがゆえのデメリットとして、データ量が大きくなるということがあります。
特に画像の影響は大きいですよね。
なので、モバイルファーストという考え方も重要になってくると思います。
ココでは詳しく書きませんが、A List Apart: Articles: Organizing MobileA Book Apart, Mobile First をご覧ください。
英語だったり買わないといけなかったりしますが…

個人的に大変参考になったのは、iframe の高さの問題と css の記述で “zoom” を使用していたこと。
以前の記事で『対処方法がわからない』と書いていたことなので、すごくありがたかったです。
単純に <div> で囲めばよかったんですね。
WordPress での埋め込みの場合は <div> で囲んでくれないのでちょっと問題かも知れませんが、対処法がわかっただけでもありがたい :lol:
“zoom” に関しては、IE の独自拡張プロパティだと思っていました。
実際、IE のバグ回避のハックでしか使った記憶がなかったので知らなかったのですが、Safari などの WebKit 系のブラウザにも実装されていたんですね。
全然知りませんでした。
CSS3に定義されているプロパティではないと思いますが、この方法は Tips として覚えておくといいかも知れません。

その他にもレスポンシブ Web デザインに対応しているライブラリや WordPress のテーマのリンクなども書いてありますので、レスポンシブルなテーマの作り方を見て参考にしてください。
あと、『レスポンシブということをプロジェクト全体で共有しなければいけない。』というのは、実際にレスポンシブ Web デザインでサイトを構築された実感だと思いますので、とても参考になりました。

毎回感じることですが、@HissyNC さんの説明・解説はホントわかりやすい。
あらためて『人に伝える』というだけでなく『どうやって、わかりやすく伝えるか』ということが重要だと再認識いたしました。

このブログでも最近『今更ですが、レスポンシブ Web デザイン(Responsive Web Design)』、『というわけで、レスポンシブ Web デザインを取り入れてみた…』という記事を書きましたので、興味のある方は是非 :-)

それと、スマートフォン比較表というサイトがありましたので、ブレークポイントの参考にどうぞ。

WordPress 事例の徹底解説

実際のサイト構築・運用を例に WordPress の機能や制作方法を説明していただきました。
このセッションも、とても勉強になりました。
内容を説明するのは難しいのですが、簡単に書くと『コンテンツの内容によってカスタム投稿タイプカスタムフィールドを使い分けて、構築していこう』ということです。
その理由のひとつに、制作者サイドではなく、コンテンツの運用サイドの使い勝手(ユーザビリティ)をポイントにされていました。
html などの知識のある人が更新作業をするとは限りませんので、必要最低限のことだけをレクチャーすれば更新作業ができるように設計するというのは、とても重要なことだと思います。
確かに、管理画面と聞いただけで拒絶反応をおこす人もおられますからね。
質問で『カスタム投稿タイプをどのような時に使えばいいのかわからない。』、『何故、カスタム投稿タイプを使うのか?』というのがありましたが、どちらにも上記の理由があてはまると思います。
もちろん、カスタム投稿タイプを使う理由はそれだけではないと思いますが、ひとつの理由としてわかりやすかったです。
カスタム投稿タイプが使えなかった頃には、カテゴリーの入れ子などで対応していたのですが、それだとあるカテゴリーだけにしか使わないカスタムフィールドもすべての投稿画面に表示されてしまいます。
なので、『このカテゴリーでは、ココのフィールドには記入しないでください。でも、このカテゴリーではココのフィールドには必ず入力してください。』等の説明をマニュアルに記述しなければいけないので、制作側も運用側も手間がかかります。
例えば、写真のギャラリーのような画像のみを表示するコンテンツがあった場合、カスタム投稿タイプを使えば必要なフィールドだけを投稿画面に表示できます。
テキストなどの本文もいらないのであれば、ビジュアル・エディターも非表示にすることができます。

今回、実際のサイトと管理画面を比較しながら説明を聞いていると、サイト設計というのが重要なのだとあらためて思いました。
サイトマップやカテゴリー、ページのファイル構成が比較的簡単であっても、コンテンツの内容によってはカスタムフィールドの設定・設計が難しいと感じました。
当たり前といえばそれまでですが、各カテゴリで必要な項目を洗い出し、カスタム投稿タイプやカスタムフィールドを設定していく。
特に今回の事例では納期が短く、Excel でのデータ入力作業と WordPress のテンプレート制作、コーディングを同時進行でおこなったそうです。
CSV ファイルで書きだし、WordPress のプラグインを使ってインポート。(プラグイン名をメモるの忘れましたが、おそらく CSV Importer だと思う。)
となると、各項目(フィールド)をしっかりと設計しておかないとできませんよね。
う〜ん、すごいですねぇ… :-o

カスタム投稿タイプを使って、サイドバー(サイドカラム)にバナーを表示させるという例を説明されている時に「カスタム投稿タイプというのは、その名の通りオリジナルの『投稿』を新たに追加・作成するものだと思っていたから、サイドにバナーを表示するために使っているのがちょっと意外です。」というような質問がありました。
確かに、バナー画像をサイドに表示させるというのは、投稿とはちょっと違うような印象を受けますよね。
通常は、カスタムフィールドを使ってバナー画像を表示させる方法が一般的なのかなぁ…
でも、これはすごくいいアイディアだと思います。

勉強会で説明されていたのとちょっと言葉は違うかもわかりませんが、自分なりの解釈を簡単に書くと、『ホーム(トップページ)に投稿やカスタム投稿の新着一覧を何件か表示させることはありますよね。その場合は、新着記事のタイトルを表示させると思いますが、タイトルの変わりにバナー画像を表示している。』ということだと思います。
今回の事例では、WordPress のアイキャッチ画像の機能を使っていました。
アイキャッチ画像を使う方法だと、サイズの違う画像であってもサイドバーに収まるように設定できます。
バナーの更新や追加をする担当者があまり気を使わなくても画像のアップができる仕組みなのでとても良い方法だと思います。
実際のサイトでは、バナー画像は2つだけですが、この方法だと追加していくのも簡単です。
テンプレートをちょっとしか見ていませんのではっきりとわかりませんが、特にバナー画像の数には制限を設けていないようでした。

WordPress の機能を熟知し、数々のサイト構築の実績をお持ちなので、このような発想ができるのかも知れませんね。
いや〜、柔軟な発想に感動しました。

あと、PS Taxonomy Expander というプラグインを紹介されていましたが、とても便利そう。
カスタム分類(カスタムタクソノミー)だけでなく、カテゴリーやタグにも設定できたりするので、運用サイドの操作性は良くなりそうです。

詳しい機能説明は、

今回のように実際のサイトと管理画面の両方を見ながらの実例紹介は、勉強になることも多くとても有意義な内容でした。
構築事例サイトは、

です。
なかなか良くできているサイトだと思いますので、是非ご覧ください。

資料へのリンクを追記しました。

WordPress 3.4特集

もうすぐリリースされるであろうバージョン3.4の新機能についての説明。
WordPress 3.4の管理画面を操作しながらの @bren_boss さんの説明がわかりやすかったです。
現行バージョンとの違いをソースコードを追いながら比較されていたようで、『さすがプログラマーさんは違う。』と思いました。

しかし、話を聞いているとテーマカスタマイザーなどは、デザイナーにとって敷居が高いような気がする。
テーマカスタマイザーに対応しているテーマを使うことは問題ないでしょうけど、テーマカスタマイザー対応のテーマを作成するとなるとやはり難しいですよね。
PHP を勉強しなければ…

資料にも WordPress 3.4の記事へのリンクが書いてありますが、上記の資料と合わせてそちらを見ていただくのがわかりやすいかも。

そして、スライド資料は WordPress の日本語ローカルサイト運営チームへの感謝で結ばれている。
そう、WordPress の英語版がリリースされた数日後に日本語版が使えるようになるのも日本語ローカルサイト運営チームの皆さまのおかげなのです。
あらためて、感謝いたします。
ありがとうございます。

毎度のことですが、もし間違っていたり勘違いしているよなことがあれば指摘してくださいな。
というわけで、第12回 WordBench 神戸のおさらいでした :roll:

スポンサーリンク

  • このエントリーをはてなブックマークに追加

フルスクリーンモードを終了するには Esc キーを押してください。または、ココをクリックしてください。