閲覧デバイスによってユーザのニーズは変わるのか？

2015/07/05 19:17 | ウェブについての考察など

先日「Responsive design is failing mobile UX 」という記事を読んでどうしても気になったので、ひとこと個人的な意見を書き残しておきます。

意訳すると「レスポンシブ・デザインではモバイルのユーザ体験を満たせない」という題の記事だが、この記事では「ユーザが求めているものは、閲覧しているデバイスによって変わる」と言っていて、ウェブサイトのコンテンツはデバイスによってカスタマイズすべきだと言っています。

Figure out what it is that your customer needs based on the device being used, and deliver that experience.

[意訳]
閲覧デバイスによる顧客のニーズを見つけて、その体験を提供するべきだ

う〜ん、それはどうかな？と。

画面サイズや入力方法（タッチ or キーボード + マウス）などのデバイスの特性によって、消費しやすい・消費しにくいコンテンツや扱いやすい・扱いにくい機能はあると思います。しかし、ある特定のデバイスで消費しにくい情報だからといって、それをユーザが求めていないかというと、話は別です。それは、ユーザが決めることで、閲覧デバイスによって決められることではないからです。

逆にいうと、とあるデバイスで消費しにくく、ユーザに求められていないと勘違いされていた情報が、情報の形や提供方法を調整することで、実はユーザに求められていた情報だったと気づくこともあるのではないでしょうか？

そう考えると、「スマホで見てるから、ユーザが求めている情報は○○だ」といったふうに、ユーザのニーズを短絡的にデバイスに紐付けるのは少し乱暴過ぎると思うわけです。

デスクトップ版のウェブサイトで見た時には存在した内容や機能が、スマホ版のウェブサイトで見たらなかった時のやるせなさは、誰もが経験したことがあると思います。ユーザがたまたま何かを必要としたときに、アクセスしやすい端末がスマホだった、もしくはデスクトップだったからといって、必ずしもユーザ行動が変わるとは思えません。

あくまで第一にユーザの求めるものがあって、その次にデバイスがある。デバイスがあって、ユーザが求めるものが決まるというのは、どうしても逆に思えます。

「マルチデバイス対応の際に考えるべき「コンテンツ・パリティ」とは？」という記事で書いた通り、「どんな閲覧環境でも同等のコンテンツにアクセスできるようなサイト設計が理想であり、かつ現実的な選択肢」だという考え方のほうが個人的にはしっくりきています。

ユーザにとって大切なのは、

ウェブサイトやサービスにユーザが求めることは何かを見極めること、
そして、求められる情報や機能に、どのデバイスからでもアクセスできるようにすること
そのうえで、デバイス特性にあわせた情報や機能の提供方法を考えること

だと思います。

どのデバイスで閲覧しても絶対に必要な情報や機能にアクセスできることを担保したうえで、画面サイズや入力方法といったデバイスの特性にあわせた、また、それらを生かした情報や機能の提供方法を考えるのが良いのではないかな、と。同じ見せ方や同じ方法ではなくても、同等の情報や機能は提供できるとはずです。そういう意味でのアダプティブ・デザインなら、どんどんやるべきだと思います。

紹介した記事に書かれていることがすべて間違っているとは思いませんし、良いことも書かれているのですが、タイトルがその内容を台無しにしていた気がしたので、率直な意見を書き残してみました。

Picturefill 2.xにウェブ標準に影響する大きな問題発覚。2.3.1より前のバージョンはアップデート必須

2015/05/30 8:20 | レスポンシブWebデザイン

以前このブログでも紹介したことがある picture 要素のポリフィル「Picturefill 」の2.3.1より以前のバージョンに大きな問題が発覚したそうです。

今後のHTMLの仕様策定に影響する可能性があるため、2.3.1より前のバージョンを使用している場合は必ずアップデートしてほしいとのことです。

Picturefill 2.x問題の要点

CSS-Tricksのゲスト投稿でRICG（Responsive Images Community Group）のMat Marquis氏が告知した内容の要点は以下の通りです：

2.3.1より前のバージョンは必ずアップデートしてほしい
セキュリティの問題ではない
2.3.1より前のバージョンで、currentSrc属性に関する問題が発覚
2.xのアップデートには機能を壊す変更はないので安心してアップデートできる
今後のHTMLの仕様策定に影響する可能性がある大きな問題
1.xは関係ない
2.3.1へのアップデートで問題があったらGithubのIssues でヘルプを要請してほしい

ということで、もしPicturefill 2.3.1より前のバージョンを使っていたら、即アップデートしてほしいとのことでした。また、Picturefill 2.xを使っている方をご存知でしたら、ぜひ教えてあげてください。

より詳しくは…

より詳しくは、英語ですが「Please Update Picturefill — CSS-Tricks 」をご参照ください。

他のレスポンシブ・イメージ関連の記事

こちらもご参考までにどうぞ：

印刷したら崩れてた！？印刷用CSSのスタイル確認と修正に便利なChrome DevToolsのエミュレータ機能

2015/05/23 10:37 | 制作・効率化ツール

いつでも、どこでもネットにアクセスできる昨今、ウェブページを印刷する機会は減っているかもしれません。でも、いざ印刷したらレイアウトやスタイルが崩れていて使えないものになっていたらユーザに申し訳ないですよね。紙の無駄使いになってエコじゃないですし。

ということで、今回は自分メモ的にプリントCSSの確認ツールのご紹介です。

Chrome DevToolsのメディアタイプのエミュレーション機能

追記: 2016.02.01

以下はChrome 43の方法です。48では方法が違っているのでこちらをご覧ください。

以前は印刷プレビューで印刷用CSSを確認していましたが、なにせ効率が悪いので他の方法を探してみました。なんと、Chrome DevToolsにエミュレータ機能がついてたんですね。さすがです。

以下の手順で、そのエミュレーション機能にアクセスできます。

Chrome DevToolsを開く（⌘ + ⌥ + I）
スマホ（device mode）アイコンをクリック
drawerアイコンをクリックする（EmulationタブでMediaを選択）
CSS mediaにチェックを入れて、ドロップダウンから「print」を選択

これで、インスペクタで要素を選んで、印刷用に適用されているスタイルを確認しながらレイアウトやスタイルの調整が可能になります。

便利ですね。

と、スクリーンショットを撮るべく、このブログで試してみたら…

ん？なんじゃ、こりゃ！？

恥ずかしながら、このブログのPrint CSSは、いま最悪の状態でした。
修正しなくちゃ。。。

自分のサイトもチェックしたらすんごい事になっていた、なんてことがないように、チェックしておいたほうが良さそうですね。

ちなみに、このスクリーンショットを撮った時点でのChromeのバージョンは43.0.2357.65 (64-bit)でした。MacBook Pro （Retina, 13-inch, Mid 2014）のOS X Yosemite 10.10.3で動かしてます。DevToolsは結構頻繁に更新されているので、これら機能の見た目やアクセス方法は変わる可能性があるのでご注意を

Firefoxの場合

Shift-F2で、開発ツールバーを開く（メニューからの場合、ツール > Web開発 > 開発ツールバー）
「media emulate print」というコマンドを入れてenter

これで、印刷用CSSのスタイルで描画されたページが表示されます。スタイルを元に戻すには、開発ツールバーに「media reset」と入力してenterを押せばOKです。

Firefoxのバージョンは33.0でした。

見えないところにもこだわる「粋」なはからい

たとえば、イベント会場やお店のアクセス情報や地図を掲載しているページは、印刷して持って行くユーザも少なからずいると思います。

そういったページだけでも、A4で1枚に収まるレイアウトになるように工夫するなど、ちょっとした心遣いができると、日本的な「おもてなし」になるのではないでしょうか？

見えないところにもこだわる「粋」なはからい。

好きです。

HTML5やCSS3のサポート状況を簡単に記事に挿入できる「Can I use…」のWordPressプラグインが便利

2015/05/06 21:05 | 制作・効率化ツール

以前、このブログでも紹介したことがある、HTML5やCSS3のブラウザサポート状況を簡単に調べられる「Can I use…」ですが、そのデータを記事に簡単に挿入できるWordPressプラグイン「Can I Use? Shortcode 」が便利そうなのでご紹介。

プラグイン導入後、WordPressのショートコードを使って以下のように記述するとflexboxのブラウザサポート状況を表示できます。

[ciu-display feature="flexbox"]

こんな感じで ↓

CSS Flexible Box Layout Moduleのブラウザサポート状況

Desktop

4*
2*
10*
12.
3.1*

Mobile / Tablet

3.2*
2.1*
12.
135
137

* ベンダープレフィックスが必要

サポート:
Yes
No
Partially
Polyfill

Stats from caniuse.com

導入方法

「Can I Use? Shortcode」プラグインをダウンロード
/wp-content/plugins/にプラグインのフォルダごとアップロード
管理画面の「プラグイン」画面から有効化
ショートコードを記事に挿入

ショートコードの書き方

以下のように記述してfeature=""のところに、調べたい要素を記述するだけです。たとえば、HTTP/2やpictureのサポート状況を挿入する場合以下を記述します。

[ciu-display feature="http/2"]

[ciu-display feature="picture"]

pictureのサポートは、IEとWebkitが…

Picture elementのブラウザサポート状況

Desktop

Mobile / Tablet

* ベンダープレフィックスが必要

サポート:
Yes
No
Partially
Polyfill

Stats from caniuse.com

表示のカスタマイズ・日本語化とスタイルの変更点

このブログに導入したものは、日本語化をして表示要素のカスタマイズを行い、スタイルを大幅に変更しました。その際、下記2つのファイルに変更を加えました。本来、GithubでFork できたらいいんでしょうけど、使い方に自信がないのでそっとしておきます。

caniuse-shortcode-master/lib/display.php

タイトル部分に「…のブラウザサポート状況」と追加
その他の英語部分を日本語化
要素の説明文を非表示
要素のステータスを非表示

caniuse-shortcode-master/lib/css/caniuse.css

このブログのスタイルにあわせるために、オリジナルから大幅にスタイルの変更をしました
SCSSにしてcaniuse.min.cssに書き出されるようにしました

改善の要望

最後に表示されるCan I Use…へのリンクを要素の詳細ページに直接貼りたい
必要ない場合は、プレフィックスに関する注記を非表示にしたい

GithubのForkの仕方とかIssue投稿のマナーとか、学ばないとな〜と思う今日この頃でした。

以上、報告終わります！

デザイナーやディレクターも知っておきたい、ページ表示速度の高速化の基本

2015/05/05 13:45 | ウェブ制作・運営ノウハウ

スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンド・エンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。

ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事やClearleftのJeremyさんの記事を参考に、フロントエンドでできることにフォーカスして整理してみました。

レスポンシブサイトの手書きワイヤーフレーム用、A4スケッチシートを作ってみた

2015/03/17 22:40 | 制作・効率化ツール

Bootstrapを使ってレスポンシブなランディングページ制作の効率化を図ろうと思っているのですが、どのようなワークフローが最適なのか試行錯誤しながら進めています。Bower使ったほうがいいのか、とか。いきなりコーディングを始めてプロトタイプ作るほうが効率良いのか？とか。ワイヤーどうしようか？とか。

で、結局レイアウトのベースになるワイヤーフレームがあったほうが良いという結論に至ったので、A4紙に印刷できるスケッチシートを作ってみました。たいしたモノではないですが、あったら便利だし、整理しやすくなると思ったので、このブログでもシェアさせていただきます。PDF版、ai版をアップしておきますので、使えそうだったらご自由にお使いください。

説明と注意点

レスポンシブな縦長サイトでも数ページにわたってスケッチできるようにデザインを最適化しました
適宜、ボックスの上と下の点線を結んで閉じてください
レイアウトの両側にコメントを書けるように、極力スペースをとりました
数ページになると思うので、ページのタイトルの他にXページのYページ目（例: Page 1 of 4）と書く欄を設けました
バージョンと日付も書いておきましょうね
やっぱり、えんぴつと消しゴムで、書いて消して、書いて消してしながらスケッチするのが効率的です
スケッチは、やっぱり紙ですよ、紙。ね
フチなし印刷できるといいんですけどね
改善のアイディアなどありましたら、ぜひコメントでお知らせください

WordPressでレスポンシブ・イメージの自動化を可能に。RICG公認プラグインが公開

2015/02/06 22:33 | レスポンシブWebデザイン

追記： 2016.01.29

WordPress 4.4からレスポンシブ・イメージがCoreに実装されました。詳しくは以下をご覧ください：

レスポンシブ・イメージの仕様策定や普及に努めているRICG（Responsive Images Community Group）が公認したレスポンシブ・イメージのWordPressのプラグインが公開されましたね。このプラグインを使うとWordPressでのレスポンシブ・イメージの解像度対応の自動化が可能になります。RICG公認のプラグインが出たことでプラグインの開発や普及が加速すると嬉しいですね。

そもそもレスポンシブ・イメージってなによ？という方は、こちらあたりをお読みください。

レスポンシブ・イメージ・プラグインの特徴

このプラグインは、WordPressのコアチームとRICGメンバー（Mat Marquis氏とTim Evko氏）が中心となって開発しているもので、Evko氏のwp-tevko-responsive-images のフォーク版だそうです。次のリリースはWordPress.orgのプラグイン紹介ページでFeatured Pluginsとして取り上げられる予定で、さらにWPコアにも組み込まれる可能性があるとのうわさもあります。

a. レスポンシブ・イメージの解像度対応が可能に

このプラグインを使うと、WordPressでレスポンシブ・イメージの解像度対応が自動で行えるようになります。WordPressのアップローダー経由でアップした画像に、複数解像度の画像へのリンクをsrcsetを使って記述してくれるプラグインです。

srcsetの記述は以下のようになります：

<img src="/path/to/image.png"
srcset="/path/to/image-300x150.png 300w,
/path/to/image-520x260.png 520w,
/path/to/image.png 1000w" />

b. アートディレクションは未対応

このプラグインは、あくまでsrcsetを使った解像度対応を可能にするもので、画面サイズによって写真のクロップやプロポーションを変更するアートディレクション対応はできません。アートディレクション対応はWordPressのコア部分にも関わってきそうなので、そう簡単には実装できないかもしれませんね。

c. Picturefill 2.2.0を使用しています

srcsetがサポートされていないブラウザ向けに、レスポンシブ・イメージのポリフィル「Picturefill 2.2.0 (Beta) 」を使っています。そのため、このプラグインをインストールするとpicturefill.jsが読み込まれるようになります。

<script type="text/javascript" src="/rriver/wp/wp-content/plugins/ricg-responsive-images/js/picturefill.js?ver=2.2.0"></script>

※Picturefill 2については、以前のまとめ記事で詳しく書いていますので、良かったらご参照ください。

d. srcsetのサポート状況

ちなみに、srcsetのブラウザ・サポート状況をCan I Use で見ると以下のような感じです。

ChromeとOperaはフルサポート
Mac / iOS Safariは、部分サポート
IEではサポートなしですが、開発中だそうで！（スパルタンではどうなんでしょうね？※）
Firefoxではデフォルト設定ではサポートなし。設定を変更すれば可

思ったより対応の進みが遅いですね。やっぱり時間かかりますねぇ…

[追記: 2015/02/08]
※ スパルタンでもWeb標準対応のロードマップは引き継ぐようなので、少なくとも<img srcset>はサポートされるようです。<picture>は「どうしようか考え中（Under Consideration）」になっているので、わからないですけど。

プラグインの導入手順

このプラグインの導入には、以下の2つのステップが必要になります。

プラグインのインストール
WordPressの画像書き出し設定を追加

考えればわかることなんですが、#2についてはプラグインのサイトにひと言も記述がないので少し戸惑いました。

1. プラグインのインストール

プラグインのサイトからダウンロードしたファイルを、/wp-content/pluginsフォルダに入れて管理画面から有効にするだけです。

2. WordPressの画像書き出し設定を追加

複数サイズの画像が書き出されるようにfunctions.phpにadd_image_size を使って設定を追加する必要があります。※テーマなどの設定によっては、すでに記述があるかもしれないので上書きしないように要確認です。

functions.phpに追加する設定の例：

add_image_size( 'large-smartphone', 520);

画像運用の自動化が可能に

このプラグインを使えば、レスポンシブ・イメージの解像度対応が自動化できます。たとえば、以下のような運用も簡単に行えます。

画像の最大幅をコンテンツの最大幅の2倍で保存する（ピクセル比2倍の高解像度画面まで対応）
タブレット向け、スマホ向けの画像サイズをWordPressで自動生成
プラグインを使って<img>タグにsrcsetを自動挿入

たとえば、コンテンツの最大幅を960pxとした場合、functions.phpに以下の記述を加えることで、ピクセル比2倍の画面まで対応できますよね。360はスマホ、720はタブレット、960はデスクトップというイメージでしょうか。

add_image_size( 'large', 1440);
add_image_size( 'large', 960);
add_image_size( 'medium', 720);
add_image_size( 'small', 360);

この設定を追加して幅が1,920pxの画像をアップすると、オリジナルに加えて指定したサイズの画像が書き出されます。そして、画像を投稿に挿入すると、以下のような<img>タグが挿入されます。1,920pxの画像を準備するのは現実的かどうかはさておき、これで自分で複数の画像を作らなくてすみますね。

<img src="/path/to/image.jpg"
srcset="/path/to/image-720x659.jpg 720w,
/path/to/image-960x879.jpg 960w,
/path/to/image-1440x1319.jpg 1440w,
/path/to/image-360x329.jpg 360w,
/path/to/image.jpg 1920w" />

上のコードは、見やすいように画像へのパスは実際のものとは違うものにしています。
あと、画像パスの記述順が、720、960、1140、360、1920となっていますが、これはプラグインが書き出したコードそのままの順番になっています。かなりランダムですが理由はわかりません。。。

WordPressが書き出す画像の最適化

WordPressが自動で画像を書き出してくれて嬉しいのですが、画像の最適化が気になったので、書き出された画像ファイルをImageOptimにかけてファイルサイズを比較してみました。そこそこ差が出るようなので、最適化については別途、対応を考えたほうが良さそうですね。

	WPオリジナル	ImageOptimで最適化	サイズの差
1440 x 1319px	719KB	659KB	60KB
960 x 879px	366KB	334KB	32KB
720 x 659px	211KB	193KB	18KB
360 x 329px	54KB	50KB	4KB

ちなみに、検証に使った画像はこちらです。1920 x 1759px。PhotoshopでJPEG 60%でWeb用に保存。1.1MB

最後に

プロダクションサイトでの使用には、もう少しじっくり検証が必要かと思いますが、ざっと見たところ良い感じですね。プラグインのサイトの情報を、もう少し充実させてくれると、もっと楽に導入できるんですけどね。笑

ゆっくりですが、レスポンシブ・デザインまわりもじわりじわりと進化を遂げていますね。レスポンシブ・デザインといっても、いろいろなやり方がありますが、こういった技術の開発が進んで普及すれば、制作者の選択肢が増えて良いと思います。最終的には、どんなデバイスでアクセスしてもユーザにとって、より使いやすいサイトが増えることを切に願ってます。

他のレスポンシブ・イメージ関連の記事

こちらもご参考までにどうぞ：

いま話題のMVNOってどうなの？さようなら3大キャリア、こんにちはIIJみおふぉん

2015/01/31 17:56 | IT・ガジェット

あけましておめでとうございます。
もう1月も最後の日になってしまいましたね。今年は本厄絶好調の年なんですが、年齢を重ねるごとに月日が経つのが早く感じるのはなんでなんでしょうね？

さて、久しぶりの投稿ですが、今回はウェブ制作とは直接関係ない話です。「明日のウェブ制作に役立つ情報を」がこのブログの命題ですが、家庭の携帯事情はウェブ制作にも大きく影響を与えると思いますので、まったく関係ない話でもないですかね。笑

ここでまとめた情報が、MVNO活用を考えている制作者の方のお役に立てば幸いです。続きを読む

OS X YosemiteでVMware Fusion 5.xが動かない！Win7のVirtualBoxへの移行手順のまとめ

2014/11/08 12:52 | 制作・効率化ツール

「OS X YosemiteにアップグレードをしたらVMware Fusionが動かなくなった！」と幻滅した方は少なくないのではないでしょうか？僕はその一人です。

VMware Fusionはバージョン3からアップグレードして使ってきたのですが、OSのアップグレード対応のみにお金を払うのが嫌になったので、この機会にオープンソースのVirtualBox に移行することにしました。

自宅のMac用だし、使用頻度もそれほど多くないし、高機能はいらないし。

え？ケチくさい？
えぇ、ケチですみません。。。笑

VMware FusionのWin 7 Home Premium 64bitの移行手順

VMware FusionにはWin 7の64bit版を入れていたので、ここではその移行手順をまとめてみました。ディスプレーの自動リサイズや仮装マシンのディスクサイズの変更で困ったので、それらについても「トラブルシューティング」のセクションで対処法を書いておきます。

BrowserStack やRemote TestKit のようなテスト環境構築が必要のない便利なサービスもありますが、いざという時のためには実際のOSが動かせる仮想環境でテストできるようにしておきたいですよね。

以下、YosemiteにアップグレードしてVMware Fusionが動かなくなって困っている方のお役に立てれば幸いです。

VirtualBoxのインストール
Win7のVMDKファイルのコピー
新規仮想マシンの作成
仮想マシンにGuest Additionsをインストール
トラブルシューティング
- ディスプレーの自動リサイズが機能しない
- 仮想マシンのディスクサイズが変更できない

VirtualBoxのインストール

VirtualBoxのウェブサイトからファイルをダウンロードしてインストールします。僕がインストールした時点では、バージョン4.3.18 r96516でした。

Win7のVMDKファイルのコピー

VMware Fusionの仮想マシン・ファイル「*.vmwarevm」を右クリックして、「パッケージの内容を表示」させます。

*.vmdkファイルをコピーする

パッケージ内にある*.vmdkファイルを任意の場所にコピーします。VirtualBoxで仮想マシンを作成する際に、この*.vmdkファイルを使います。

新規仮想マシンの作成

VirtualBoxを立ち上げて、「新規」ボタンをクリックして、表示されるダイアログに従って新規仮想マシンの作成をします。

作成画面：その1

名前に「Win7」とか「Windows 7」と入力すると、自動的にタイプとバージョンが選択されました。

作成画面：その2

一番下の「すでにある仮想ハードドライブファイルを使用する」を選択して、先ほどコピーした*.vmdkファイルを選択します。

作成画面はこれで完了です。あとは、設定画面から細かい設定を変更します。

「システム」設定画面

CD/DVDドライブのないMacBook Proにインストールしたので、僕の場合、フロッピーとCD/DVDからチェックを外しました。

「ストレージ」設定画面

ここの設定に手こずったので、少し詳しく説明します。

まず、以下の「コントローラ：SATA」を選択して、右下の「-」ボタンをクリックして削除します。

今度は、「コントローラ：IDE」の右にあるハードディスクアイコンの「+」ボタンをクリックして、先ほどの*.vmdkファイルを選択します。

そして、追加した*.vmdkファイルを「IDEプライマリーマスター」に設定します。

これで、とりあえず仮想マシンが動くはずです。

仮想マシンにGuest Additionsをインストール

仮想マシンを起動すると、ファイルメニューに「Devices」というメニューが出てくるので、そこから「Insert Guest Additions CD Image…(Host+D)」を選びます。これをすると、仮想マシンのCDドライブに「VirtualBox Guest Additions」が出てくるので、そこから「VBoxWindowsAdditions.exe」を実行してGuest Additionsをインストールします。

これで、ディスプレーの自動リサイズも機能するようになります。

僕の場合この手順を知らなかったので、ファイルメニューの「View」の「Auto-resize Guest Display」がグレーアウトしてていて、自動リサイズ機能を使えるようになるまでに結構時間を費やしてしまいました。

トラブルシューティング

ディスプレーの自動リサイズが機能しない

上述したGuest Additionsをインストールすると「View」メニューの「Auto-resize Guest Display」が使えるようになります。

仮想マシンのディスクサイズが変更できない

コマンドラインツールを使うと仮想マシンのディスクサイズを変更できるのですが、VMware Fusionが書き出したVMDKファイルのサイズ変更はできないようです。そのため、以下の手順を踏む必要があります。

VMDKファイルをVDIファイルに変換
VDIファイルをリサイズ
VDIファイルをVMDKファイルに変換しなおす
Windowsのディスク管理ツールでパーティションを拡張する

※VirtualBoxはVMDKとVDIの両方をサポートしているので、どちらも使えます。

VMDKファイルからVDIファイルへの変換

VirutalBoxをインストールすると、VBoxManageというコマンドラインツールがインストールされます。VMDKファイルからVDIファイルへの変換は、このツールで、以下のコマンドを使って行います。

$ VBoxManage clonehd --format vdi [変換元のファイル名.vmdk] [変換先のファイル名.vdi]

VDIファイルをリサイズ

VDIファイルのリサイズもVBoxManageツールを使って行います。たとえば、20GBにリサイズしたい場合、以下のようなコマンドを実行します。

VBoxManage modifyhd [ファイル名.vdi] --resize 20480

まとめ

以前はVirtualBoxはとっつきにくい感じがして敬遠していたのですが、バージョンが上がって洗練されたからなのか、それほど手間をかけずにWin 7を動かせるようになりました。MacBook AirとくらべてMacBook Proだとサクサク動くし、あとはmodern.ie で他のバージョンのIEテスト仮想マシンをゲットすれば完璧ですね。

英語ですが、以下のサイトを参考にさせていただきました：

レスポンシブ・イメージの「RICG」ニュースレターでRriverの記事が紹介されちゃいましたw

2014/10/21 22:58 | レスポンシブWebデザイン

RICGというレスポンシブ・イメージのコミュニティグループのニュースレターで先日投稿したRriverの記事「なんでもかんでも<picture>要素を使えばいいわけじゃない！レスポンシブ・イメージ実装の際の注意点」が紹介されていて嬉しかったので自慢です。

RICG（Responsive Images Community Group）のニュースレターをiPhoneで眺めていたら、以下の文章が目に入ってきて、

Responsive Images: getting bigger in Japan all of the time.
（レスポンシブ・イメージ：日本でもずっとビッグになってるみたいだよ！）

「おっ？！もしかして？」自分の記事が紹介されてるのか？？と思ってクリックしたら、自分の記事でした！笑

リンクしていただいてありがとうございましたw
はい、それだけです。笑

RICGのニュースレター

RICGのニュースレターでは、レスポンシブ・イメージの最新動向が紹介されています。ブラウザ・サポートの状況や関連記事も紹介されているので、とても勉強になります。RICGウェブサイトから購読できますよ。

レスポンシブ・イメージのブラウザサポート状況

ついでなので書いておきますと、レスポンシブ・イメージのブラウザサポート状況は以下のとおりです。

Blink: Chrome 38正式版でpicture要素とsrcsetが実装済み
Webkit: Safariでsrcsetが実装済み。picture要素は未実装
Mozilla Firefox 33でpicture要素とsrcsetがフラッグ付きで実装済み（設定変更の必要あり）
IE: 実装を考え中

※ Blinkを使っているOperaでも実装済みになります。

他のレスポンシブ・イメージ関連の記事

こちらもご参考までにどうぞ：

まったくの勘違い！Appleはトップページで自動送りカルーセルをやめてませんでした

2014/10/18 14:48 | ウェブ制作・運営ノウハウ

iPad Air 2とiMac with Retina 5K displayが発表されましたね。
世間のみなさんが、なにが発表されるかワクワクしているころ、僕は発表後のAppleウェブサイトが気になってドキドキしておりました。

というのも、先日「Appleがトップページで自動送りカルーセルをやめた理由」という記事を書いていたからです。

新製品発表後のApple.comトップページ

まずは、訂正とお詫びから

先日の記事ではAppleがトップページで自動送りカルーセルをやめた理由を以下のように書いていたのですが、まったくの勘違いだったようです。「あくまで推測の域は脱しない」と書いてはいるものの、先日の記事により誤解を生じさせてしまう可能性があるため、この場を借りて訂正とお詫びをさせていただきます。

あくまで推測の域を脱しないですが、A/Bテストを実施して、ある数値以下の結果だったら差し替え用のデザインを実装するように前もって準備をしていたのでしょう。検証の結果、やっぱりカルーセルからの下位ページへの誘導は圧倒的に数値が悪かったのでしょうね。

記事へのコメントやはてブでのコメントご指摘いただいていた通り、Appleウェブサイトでは、2014/10/17現在、新製品発表後にはトップページで自動送りのカルーセルのみにしています。これは要確認ですが、数日後にいつものレイアウト（巨大ヒーローイメージと4つのフィーチャーボックス）に戻るものと推測されます。

Appleがトップページでカルーセルを使う理由

「Appleがトップページで自動送りをやめた理由」については完全に勘違いだったようですが、メイン・ナビゲーションとしての自動送りカルーセルの有効性については以下の考えは変わっていません。

ユーザを誘導するためのナビゲーションとして、自動送りカルーセルは機能しない

そもそも、Appleウェブサイトではナビゲーションとしてカルーセルを使っているわけではないですしね。

ただ、Appleウェブサイトとはいえ、先日の記事で紹介したデータにあるように2枚目以降のクリック率は格段に下がると思うので、それでもカルーセルを使う意味があるのか？ということについては疑問が残ります。

新製品発表後にAppleウェブサイトを訪れるコアなファンの間では違った結果が出るのでしょうか？そして、この期間にサイトを訪れるユーザは、圧倒的にコアなファンが多いということなのでしょうか？Appleウェブサイトの解析データを見せてもらいたい…。

カルーセル、というか、ウェブ制作、奥が深いですね。

なんでもかんでもpicture要素を使えばいいわけじゃない！レスポンシブ・イメージ実装の際の注意点

2014/10/06 23:17 | レスポンシブWebデザイン

画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。

Cloud Fourというアメリカの制作会社のブログで、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。

まずは推奨の記述方法から

レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです：

サイズ変更のみの場合はimgにsrcset属性を使う
アートディレクションを入れる場合のみpictureを使う

とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブしておいて、使う時にもう一度見なおしてもらえればいいと思います（笑）。

ということで、報告は以上です。

以下、「詳しく知っておきたい」という方のためのまとめです。

レスポンシブ・イメージの2つの使い道

頻繁に使われると想定されるレスポンシブ・イメージの使い道は、大きく2つに分けることができます。Cloud Four Blogの記事では、それらすべてに<picture>要素を使うのではなく、上述したようにpictureまたはimg + srcsetを使い分けるべきだと書いています。

「なんでもかんでも<picture>要素を使えばいいわけじゃない！」とおっしゃっているわけですね。

僕もたしかにその通りだと思うわけですが、その理由を順序立てて説明していきます。

まずはレスポンシブ・イメージの2つの使い道からおさらいです。

1. 同じ内容で画像サイズのみを変更する（解像度の変更）

一つは、スクリーンサイズや解像度にあわせて同じ画像の内容で画像サイズ（寸法）だけを変更する場合。スクリーンの幅とそれにあった画像を指定する使い方です。

レスポンシブ・イメージについてのまとめで検証したように、400pxでは17KB、1200pxでは100KBといったように、画像の寸法でファイルサイズには大きく差が出ます。400pxの画像で十分なのに1200pxの画像を表示している場合、ダウンロードサイズが大きくなるだけでなく、ブラウザに不必要なレンダリングをさせることになります。

ちなみに、Cloud Fourの記事ではこの使い道を「解像度の変更（resolution switching）」と呼んでいて、僕が書いた以前の記事では別扱いにしていたRetina対応のための解像度の変更もここに含まれています。

2. 違う内容の画像を表示する（アートディレクション）

もう一つの使い道は、スクリーンサイズによって違う内容の画像を表示する（アートディレクションを入れて画像を変更する）場合です。たとえば、小さいスクリーン向けに違った写真の切り抜き方をする場合に使います。

以下のように横長の画像をデスクトップ向けに表示する場合、

そのまま縮小して表示させると写真がすごく小さくなってしまいます。

以下のように写真を切り抜いてあげると、より効果的に見せることができます。

2つの記述方法

HTML Living Standard やDev.Opera 、Cloud Four Blogの記事で推奨しているレスポンシブ・イメージのHTMLの記述方法は以下のとおりです。

1. 解像度の変更

imgでsrcsetとsizes属性を使った記述方法です。

<img srcset="img/400w.png 400w, img/800w.png 800w, img/1200w.png 1200w" alt="幅に合わせた寸法での表示の例">

srcsetとsizesの両方を使った記述方法やデモなど、より詳しくはレスポンシブイメージのPolyfillのPicturefillを使って検証したこちらの記事をご覧ください。こちらのデモはPolyfillを使用したものなので、ブラウザに実装されたものとは挙動が異なる可能性が高いです。ご注意ください。 [2014/12/22: 加筆修正]

2. アートディレクション

pictureを使った記述方法です。

<picture>
  <source media="(min-width:800px)" srcset="large.jpg">
  <source media="(min-width:400px)" srcset="medium.jpg">
  <img src="small.jpg" alt="ALTテキストはちゃんと記述しましょう">
</picture>

より詳しい説明とデモはレスポンシブイメージのPolyfillのPicturefillを使って検証したこちらの記事をご覧ください。※ちょっとややこしいですが、こちらのデモではpictureとsrcsetの両方を使った記述方法を紹介しています。こちらのデモはPolyfillを使用したものなので、ブラウザに実装されたものとは挙動が異なる可能性が高いです。ご注意ください。 [2014/12/22: 加筆修正]

どちらの使われ方が多いのか？

Cloud Four Blogの記事で参照されているのですが、Chromeにpictureを実装しているYoav氏の2013年5月の検証によると、<picture>要素のポリフィル「picturefill 」を使っている27サイトのうち、9サイトでアートディレクションを使用していたそうです。感覚値でしかありませんが、僕が運営に携わっているレスポンシブ・サイトでも、だいたい4つに1つくらいかなぁといった印象です。

「24%も」と言うべきか「24%しか」なのか、29サイトだけでの検証ではなんとも言えませんし、24%で「多くの場合（for most responsive images）」と言い切ってしまうのは大げさな気もします。どちらにしろ、使い道に適した記述をするのが望ましいことに変わりはないんですけどね。

話しが少し脇にそれてしまいましたが、なぜ上述したHTMLの記述方法が推奨されるのでしょうか？

その理由は、pictureとsrcsetの画像指定によるブラウザの挙動の差にあります。

pictureとsrcsetの違い

レスポンシブ・イメージの2つの記述方法の違いは、srcsetではブラウザに対して状況に応じた選択の余地を与えているのに対し、pictureではブラウザに判断の余地がないところにあります。

srcsetの場合はブラウザに選択の余地がある

上のサンプルコードの場合、srcsetで400w、800w、1200wの幅で使ってほしい画像をブラウザに対して提案しているにすぎず、仕様上は最終的にはブラウザの判断でユーザの閲覧環境に応じて画像を表示する仕組みになっています。~~そのため、iPhone 5のように~~たとえば、スクリーン幅が320pxでもピクセル比が2の場合は、ブラウザが自動的に800wに指定した画像を選~~んでくれます~~ぶといったこともブラウザの実装次第では可能になります。 [加筆修正: 2014/12/22]

たとえば、将来的に「3G回線では高解像度の画像をダウンロードしない」といった機能がブラウザに追加された場合でも、srcsetを使った記述方法であれば対応できることになります。

pictureの場合は限定的な指定になる

反対に、pictureを使った記述方法では、上のサンプルコードの場合、400pxより小さいサイズではsmall.jpg、400px以上ではmedium.jpg、800px以上ではlarge.jpgが表示されるように限定した指定になります。メディアクエリで指定したものにブラウザの判断する余地はないため、必ず指定された画像が表示されます。

pictureを解像度の変更の用途で使う場合、~~iPhone 5~~スクリーン幅が320pxでピクセル比が2の場合でもsmall.jpgが表示される仕様になっています。 [加筆修正: 2014/12/22]

このため、解像度の変更のみが目的の場合は、pictureではなく、srcsetが使われるべきだということです。

pictureとsrcsetの組み合わせも可能

ちなみに、以前の記事のデモのように、アートディレクションを入れた画像で解像度の変更にも対応したい場合、pictureとsrcsetを組み合わせた書き方もできます。

まとめ

レスポンシブ・イメージはレスポンシブ・サイトでなくてもRetina対応などに活用できるものです。もうすぐChromeの正式版でサポートが開始されますし、Picturefillなどのポリフィルを使えば今から実装できなくもありません。メリット・デメリット、問題・課題、またターゲットとするユーザの閲覧環境を考慮してうまく活用すれば、ユーザにより良い体験を提供できるのではないでしょうか？

以前の記事にも書きましたが、これから課題となるのは複数の画像制作の効率化だと思います。冒頭で紹介したCloud Four Blogの記事の著者であるGrisby氏もそれを認識していて、すでに画像加工の自動化ツールの一覧をブログで紹介しています。自動化が可能なところは機械にまかせて、手間をかけずに、より効率的に、より良いユーザ体験が提供できたら嬉しいですね。

使用した画像について

画像の新宿超高層の写真はこちらの写真を加工して使わせてもらいました。
MacBookとiPhoneのイラストは、こちらを使わせてもらいました。

ありがとうございました！

他のレスポンシブ・イメージ関連の記事

こちらもご参考までにどうぞ：

何度やっても忘れてしまう、Mac OS Xのスクリーンショット関連の設定コマンドのまとめ

2014/09/28 20:26 | IT・ガジェット

新しいMacを設定する際に毎回検索しているので、スクリーンショット関連の設定コマンドをまとめておきます。ブログを書いたりウェブ制作をしているとキャプチャを撮って加工する機会も多いので、自分好みの設定にしておきたいですよね。ちなみに、GUIで簡単に設定したい場合は Onyx を入れると以下の設定がすべて変更できます。

保存場所の変更

デフォルトだとデスクトップに保存されてしまうので「ピクチャ」内にscreenshotsフォルダを作って保存先に指定してます。

defaults write com.apple.screencapture location /Users/ユーザ名/Pictures/screenshots

ファイル・タイプの変更

PNGがデフォルトなので、僕はそのままですが一応メモ。以下はjpgに変更する場合。

defaults write com.apple.screencapture type jpg

多くのファイル・タイプを指定できるそうですが、png、jpg、pdf あたりを覚えておけばたいていのことには間に合いそうですね。ちなみに、選択できるファイツタイプは png（デフォルト）、bmp、pdf、jpg、jp2、tif、pict、tga だそうです。

ファイル名の変更

デフォルトだと「スクリーンショット 2014-09-24 7.05.17.png」というふうにかなり長いファイル名になります。なので、「ss 2014-09-24 7.05.17.png」となるように設定を変更しています。

defaults write com.apple.screencapture name ss

「ss」の部分がファイル名の最初につきます。タイムスタンプ部分は Onyx を使えば取ることができます。

影のあり・なし

「shift-command-4」→ 「space」→ 「return」でウィンドウを選択してキャプチャを取ると、デフォルトでは影がつくようになっています。その影をなくす設定は以下のとおり。

defaults write com.apple.screencapture disable-shadow -bool true

もとに戻したい場合は以下のコマンドで戻せます。

defaults write com.apple.screencapture disable-shadow -bool false

多機能ユーティリティ「Onyx」

オニキス（オニックス？）と読むのでしょうか。このアプリを入れると、「各種設定 → 一般」から上述したコマンドラインからの設定がすべて行えます。また、このツールを使うとファイル名のタイムスタンプ部分を消すこともできます。

Onyxには他にもシステム・メンテナンスなどの多くの機能がついているので、入れておいても損はないかもしれません。スクリーンショットの設定変更のためだけならいらないかもしれませんけど。Onyx については、こちらのブログで日本語で詳しく説明されています。ありがたいですね。

Appleがトップページで自動送りカルーセルをやめた理由

2014/09/23 21:47 | ウェブ制作・運営ノウハウ

追記: 2014.10.18

10月16日の新製品発表後のApple.comウェブサイトを確認したところ、自動送りのカルーセルが使われておりました！この場を借りて訂正とお詫びをさせていただきます。

世間のみなさんがiPhone 6の発売開始で盛り上がっているなか、Rriverでは、まだAppleウェブサイトで盛り上がっておりますw

先日のiPhone発表後にAppleウェブサイトが刷新されたのはご存知の通りですが、その際、Appleのトップページでは自動送りのカルーセルのみが使われていました。

こんな感じで。どーん！と。

残念ながらページ全体のキャプチャをとっていなかったので下までお見せできませんが、ページのメイン要素となるカルーセルの下にはフッターしかありませんでした。ほんとですw

そして、おぉ、さすがApple。
ここでも思い切った選択をしたな〜と思っていたわけです。

ところが！

数日後にもう一度トップページを見てみたら、あの懐かしの4つのボックスが戻っているではないですか！？

実は、このレイアウト（巨大ヒーローイメージと4つのフィーチャーボックス）が、何年も続いたAppleの鉄板レイアウトだったわけですが、先日のリニューアルでこのフィーチャーボックスがなくなっていて「ついに、あれもお亡くなりになられたか」と、密かに悲しんでおりました。

その後のこの華麗なカムバックです。
かなり興奮してしまいました。

しかも、スタイルも細かいスペースや背景の扱いがよりシンプルなものに更新されています。

iPadでみるとこんな感じ

iPhoneではこんな感じですね

おかえり、フィーチャーボックス。

画面の幅が狭くなるとカラムを下に落とす、よくあるマルチデバイス対応のレイアウトになってますね。

Appleがトップページのカルーセルをやめた理由

あくまで推測の域を脱しないですが、A/Bテストを実施して、ある数値以下の結果だったら差し替え用のデザインを実装するように前もって準備をしていたのでしょう。検証の結果、やっぱりカルーセルからの下位ページへの誘導は圧倒的に数値が悪かったのでしょうね。

Appleくらいのアクセス・ボリュームのあるサイトで、しかもiPhone 6の発表後でアクセスが集中している時です。たぶん数時間で結果検証をして判断できる数値は集まったと思います。

追記: 2014.9.24

はてブで製品発表後はカルーセルにしてるとのコメントがいくつかありました。製品発表直後のAppleウェブサイトではそのほうが効果があるということなんでしょうか？次回の製品発表後もウェブサイトが気になってしまいますね。次回、起きてられるかな…

追記: 2014.10.18

メイン・ナビゲーションに自動送りのカルーセルは使えない

Appleほどのアクセスを集めるウェブサイトでこの結果ですから、ユーザを誘導するためのナビゲーションとしての自動送りカルーセルは機能しないと思って間違いないでしょう。

実際に自分もこのカルーセルでストレスの残る体験をしました。iPhone 6をクリックしたつもりが、スライドが勝手に次に移動してApple Watchのページに行ってしまいました。

もう一度書いておきます。

ユーザを誘導するためのナビゲーションとして、自動送りカルーセルは機能しない

これは間違いないでしょう。

自動送りのカルーセルが使えない理由

「Should I Use A Carousel? 」のデモでも、自動送りのカルーセルのダメなところがよく表現されています。ちょっと見てみてください。

上記サイトでは、キャプチャのカルーセルが早いスピードで自動送りされます。

「それで、カルーセルは使うべきなの？」
「答えはNOだ!!!本気でやめたほうがいい」
「え？なんでかって？教えるよ」
「それは1%しかクリックしてなくて、そのうち1枚目のスライドが…」 ← いまココ

スライドを読み進めて行くと、4枚目から文字数が圧倒的に多くなって読めなくなります。一生懸命読もうとしてるのに、自動で次のスライドに行ってしまいます。

「イラッ！」としますよね？笑

そして、そんなイライラを見透かしたように「ね？イライラしただろう？カルーセルを使うと、君のユーザも同じことになるんよ」なんて言われてしまうわけです。

1つ目のスライドしかクリックされないというデータも

米ノートルダム大学でウェブ・コミュニケーションのディレクターをしている Erik Runyon さんが彼のブログでノートルダム大学のトップページのカルーセルの統計データを紹介しています。

そのデータによると、約375万件のページ訪問者のうち、約1%がカルーセルをクリック。また、一枚目のクリックの割合がカルーセル全体の89.1%なのに対し、残りは2.1〜3.4%しかなかったとあります。

このデータや経験則から考えると、1つ目のスライド以外はほとんどユーザの目に触れないと思っていいのではないでしょうか？見てもクリックしないという可能性も考えられますが、その可能性は低いのではないかなぁと思います。

自動送りのカルーセルは無視される

ユーザビリティ・リサーチで有名なNielsen Norman Groupの記事でも参考になる調査結果を紹介しています。98ポイントの大きな文字で書かれているにもかかわらず、自動送りされるカルーセルに掲載されたお得情報にユーザは気付かなかったそうです。

カルーセルは企業側の一方的な宣伝に使われることも多いので、ユーザから避けられる確率が高そうです。

よほど工夫してデザインを施さないと、ユーザに無視されるのは必至でしょう。

まだ改善の余地はある？

ただ、今回のAppleのトップページでの事例のみで、すべてのカルーセル・ナビゲーションが使えないと結論付けるのは危険です。Nielsen Norman Groupのもう一つのカルーセルに関する記事では、より良いコンテンツやナビゲーションを使うことでカルーセルを効果的にヒーローイメージとして使用できると書いていて、よいカルーセル・デザインのガイドラインも挙げています。

たしかに、Appleウェブサイトでの今回の実装を見る限り、まだ改善の余地はありそうです。

たとえば、以下の2つ

小さな「○」だけで表現されたナビゲーション
2〜3秒で自動スライドしてしまうコンテンツ（記憶が正しければ結構早かった）

どうしても自動送りのカルーセルを使う必要がある場合は、このあたりをA/Bテストで検証・改善したり、Nielsen Norman Groupのガイドラインを参考にして使うのが良さそうですね。

Appleのスピード感

しかし、検証して改善するこのスピード感、なんかワクワクしますねw

さすが、Apple！刷新されたウェブサイトで見つけた3つのこだわりとは？

2014/09/15 19:10 | ウェブについての考察など

iPhone 6とApple Watchの発表よりも、その後に公開されたAppleウェブサイトのリニューアルのほうに驚いた方も多かったと思います。Appleがついにモバイルに対応した！というのも興味深いできごとですが、僕にとっては、長年存在したあのナビゲーションバーが、シンプルでフラットなデザインに変更されたことに「おぉ〜、ついに。。。」と感傷に浸ってしまいました。

さようなら、スキューモーフィズム。

Appleがモバイル対応のサイトを作った理由は、個人的にはApple以外のモバイルユーザにアピールする必要がでてきたからだと思うのですが。。。

Appleがスマホ向けのレイアウトを用意した背景には、やはりAndroidの台頭によるマーケティングの判断があったからで、Android端末からの閲覧ユーザが増え、Apple製品を彼らにも積極的にアピールする必要性が増したからではないだろうか？

@rriver 8:42 AM – 11 Sep 2014

iPhoneが圧倒的なシェアを誇った時代は遠い昔の話になり、Androidのマーケットシェアが85%を超えようとしているいま、Apple愛好家のみならず、Android端末でサイトを訪れるユーザにもしっかりアピールする必要があります。

Nexus 5で見たAppleウェブサイト

それはさておき、iPhone 6のページで、3つほど驚いたことがあったのでメモしときます。

letter-spacingでカーニング

Appleの日本語ウェブサイトでは、僕の記憶が正しければキャッチなどのテキストには画像が使われていたのですが、リニューアル後のサイトを見たら、なんと！テキストになっていました。マニアックですが、僕にとってはかなりの驚きです。ついに、Appleがテキスト画像をやめた！

しかも、ひらがなの部分にletter-spacingを指定してカーニングを行っているではないですか！w

さすが。。。

日本語だと、ひらがなは文字間が空いてしまいますからね。そういうこだわり、好きです。

「き」と「く」の間が開きすぎなのと、「薄い」と「i」の間が近すぎなのが若干気にはなりますが。。。

ちなみに、同じページをNexus 5で見ると以下のように表示されます。

写真だと思ったらビデオだった

Appleのウェブサイトを見ていると、iPhoneやiPadなどの美しい製品写真が、スクロールに合わせて角度を変えたり、位置が移動するのに気づきます。

「この繊細な動きが、さすがAppleだなぁ〜。単にCSSで位置を動かしているだけなのに、なんでこんなに綺麗な動きに見えるんだろうなぁ？」と思い、何度も何度もスクロールして見ていたんです。そしたら、なんと、製品の影も微妙に動いているではないですか！？

不思議に思ってソースコードを見てみたら。。。

この「アニメーション」には、ビデオが使われていたんですね。

ビデオをスクロールに連動させることができるとは。知りませんでした。勉強不足でした。

特に技術的に新しいというわけではなさそうですが、Appleのちょうどいい感じの使い方は、さすがですね。すでにある技術を、誰よりも優れた、技術を活かした使い方で組み込んでくるのがAppleのすごいところですよね。ウェブサイトでもそれが健在ですね。

そして、「製品をよりよく見せる」という、徹底したこだわりに脱帽です。

ボタンは立体的だった

最後におまけ的なものですが、もう一つ驚いたことに、「予約注文」のボタンがあります。

iOSやOS X Yosemiteでは、UI要素のフラット化が進んでいます。そのため、今回のAppleウェブサイトのリニューアルでも、ボタンはフラットで行くのかと思っていました。が、このボタンには立体的なグラデーションが施されていました。驚きです。

結局、A/Bテストをしたら圧倒的に立体的なボタンのほうが押される確率が高かったということですかね？

なかなか、興味深いですね。そして、勉強になります。Appleのウェブサイト制作、昔より楽しそうに感じるのは僕だけでしょうか？今後の新しい試みにも期待です。

SassとGulpを使った便利なメディアクエリの記述方法とアウトプットの最適化

2014/09/13 22:12 | ウェブ制作・運営ノウハウ

先日このブログのデザインをリニューアルしたときに、メディアクエリの記述が結構手間だったので、記述のしやすさ、メンテナンス性の良さ、また、最終的なCSSファイルの最適化の3つの観点から、便利な書き方と最適化の方法をまとめてみました。

モバイル・ファーストCSSで書く

メンテナンス性の良さや重複の少ないよりシンプルなCSSの記述を目指すと、モバイル・ファーストCSSで書くのが良いです。デスクトップ・ファーストCSSで書く場合、小さい画面向けにはスタイルを追加するというより、消していく（または、上書きして帳消しにする）作業が多くなってしまいます。

このブログはモバイルからのアクセスが1割程度なので、今回のデザインのリニューアルでは、まずデスクトップ向けのCSSから記述しました。その後、モバイル・ファーストCSSに記述を直していったのですが、結構手間がかかりました。デスクトップを優先してデザインしていく場合、CSSもデスクトップ向けのものから記述したほうがやりやすいと思ったのですが、後の工程で手間が増えてしまいました。

参考までに、今回のプロセスをご紹介します。

たぶん、ダメな記述プロセス

ステップ1

まずは、デスクトップ向けのCSSを書く

h1 { font-size: 2em }

ステップ2

小さい画面向けにCSSを記述するために、デスクトップ向けの記述にメディアクエリを追加

@media screen and (min-width: 960px) {
  h1 { font-size: 2em }
}

ステップ3

小さい画面向けのCSSを追加

h1 { font-size: 1.6em }
@media screen and (min-width: 960px) {
  h1 { font-size: 2em }
}

ステップ4

中間サイズの画面向けのCSSを追加

h1 { font-size: 1.6em }
@media screen and (min-width: 600px) {
  h1 { font-size: 1.8em }
}
@media screen and (min-width: 960px) {
  h1 { font-size: 2em }
}

あれ？
こう書いてみると、そんなに悪くないのか？

考え方や作業の慣れもあると思うので、どちらが良いかはなかなか判断がつきにくいところですが、経験則的に、最終的な記述方法はモバイル・ファーストCSSのほうが良いと思います。

要素ごとに、Sassを使って記述する

メディアクエリは要素ごとに書いたほうが圧倒的に書きやすいです。これは絶対です。笑

プロジェクトのはじめからメディアクエリを @media でまとめて書いてると、コードを行ったり来たりするのに時間がかかります。また、外部Sassファイルを読み込むようにしていても、ある要素のメディアクエリの記述を探すのに手間がかかります。

ということで、メディアクエリは以下のように各要素ごとに書くのが便利です。

h1 { font-size: 1.6em }
@media screen and (min-width: 600px) {
  h1 { font-size: 1.8em }
}
@media screen and (min-width: 960px) {
  h1 { font-size: 2em }
}
@media screen and (min-width: 1240px) {
  h1 { font-size: 3em }
}

さ・ら・に！

Sassを使うと、さらに便利です（Lessでもいいんでしょうけど、僕はSass派なので）。

Sassの便利な機能の1つは入れ子での記述ですが、メディアクエリも同じように入れ子にすれば、属性だけの記述でOKです。たとえば、以下のように記述をすれば、「h1」を何度も書かなくてすむのでかなり効率的です。

h1 {
  font-size: 1.6em;
  @media screen and (min-width: 600px) {
    font-size: 1.8em;
  }
  @media screen and (min-width: 960px) {
   font-size: 2em;
  }
  @media screen and (min-width: 1240px) {
    font-size: 3em;
  }
}

これ、かなり便利ですよね？

でも！要素ごとにメディアクエリを書いていたら、記述が増えちゃいませんか！？

あ、はい、増えますね…

そこで、Gulpの登場です。

Gulpを使ってメディアクエリの整理する

上述のようにSassを使ってメディアクエリを書くと、 @media の記述が増えてしまいますが、デプロイ前にツールを使って整理することができます。また、実は、整理しなくても、ボリュームが少ないCSSでは、ファイルサイズにもレンダリングにもあまり影響はないと言って良さそうです。

どうしても気になる。数キロバイトでも最適化するべきだという場合は、Gulpだとgulp-combine-media-queries とかGruntだとgrunt-combine-media-queries あたりのプラグインを使うと、以下のようにメディアクエリを整理してくて、ファイルサイズも縮小できます。

ちなみに、このブログのCSSで試してみたところ、2,253バイトほどファイルを圧縮でました。このサイトはスタイル記述が少ないほうなのでこの程度ですが、大規模なサイトの場合、メディアクエリの整理でだいぶファイルサイズを圧縮できそうですね。

メディアクエリ最適化前	28,101バイト
メディアクエリ最適化後	25,848バイト

※1 これらプラグインに関しては、バグ情報（Gulp | Grunt ）に注意が必要です。
※2 Sublime Textのプラグインもあるんですが、現段階ではうまく動かすことができませんでした

整理前

h1 {
  font-size: 1.6em;
  @media screen and (min-width: 600px) {
    font-size: 1.8em;
  }
  @media screen and (min-width: 960px) {
    font-size: 2em;
  }
  @media screen and (min-width: 1240px) {
    font-size: 3em;
  }
}

h2 {
  font-size: 1.4em;
  @media screen and (min-width: 600px) {
    font-size: 1.6em;
  }
  @media screen and (min-width: 960px) {
    font-size: 1.7em;
  }
  @media screen and (min-width: 1240px) {
    font-size: 2.6em;
  }
}

整理後

h1 { font-size: 1.6em; }
h2 ( font-size: 1.4em; }

@media screen and (min-width: 600px){
  h1 { font-size: 1.8em; }
  h2 { font-size: 1.6em; }
}
@media screen and (min-width: 960px){
  h1 { font-size: 2em; }
  h2 { font-size: 1.7em; }
}
@media screen and (min-width: 1240px){
  h1 { font-size: 3em; }
  h2 { font-size: 2.6em; }
}

まとめ

Gulpのこのプラグイン、いいですね〜。こういったツールやプラグインのおかげで、以前は実現できなかったことが、どんどん実現できるようになってますね。嬉しい限りです。ちなみに、すごくベーシックなGulpの設定を Github にあげてあるので、よかったらそちらもご参照ください。この記事で紹介した gulp-combine-media-queries の設定も入っています。

メディアクエリはレスポンシブ対応だけでなく、ちょっとした最適化にも使えるものです。柔軟、かつ効率的に使って、どんなサイズの端末でも快適な閲覧ができるように、ウェブサイトを制作していきたいですね。

それでは、今宵も楽しく制作しましょ〜

マルチデバイス向けの制作に必須！シンクロナイズド・ブラウザ・テストを実現する3 + 1つのツール

2014/09/07 23:00 | 制作・効率化ツール

CSSやHTMLを編集すると、アクセスしている複数の端末が同期されて自動的にリロードされる「Synchronized Browser Testing」というツールがあります。このブログのデザイン変更作業をした際に、マルチデバイス対応のサイト制作にはこういったツールが必須だなぁと実感したので、試したツールと設定の注意点などをまとめてみました。

用途と設定の難易度で、それぞれ向いているツールは異なると思いますが、僕のいまのところの最強コンビは、BrowserSync + Gulpとngrokの組み合わせだと思っています。

最後に機能比較一覧も作ってみました。

Codekit（29ドル）

https://incident57.com/codekit/

Sass、Less、CoffeeScript、Markdownなど、さまざまな言語のコンパイルからブラウザの自動リロードまで、たくさんの便利機能を持ち合わせたツールです。バージョン2から独自のWebサーバが組み込まれたので、PHPやデータベース連携が必要なければ、CodeKitだけでローカル環境にあるサイトを、他の端末からチェック可能です。アクセスしている端末すべてで自動リロードしてくれるので、複数端末でのテストに重宝します。

チェック方法

以下の「Server」パネルからURLが確認できます。

MAMP（外部ローカルサーバ）との連携

また、WordPressのようにPHPとデータベースが必要な場合、MAMPなどの外部ローカルサーバとの連携も簡単です。以下の「BROWSER REFERESHING」設定画面から設定できます。

Ghostlab（49ドル）

http://vanamco.com/ghostlab/

少し値段が高めですけど、テストに特化した便利なツールです。CodeKitと違うところは以下の3点です：

インスペクターがついている
スクロールやフォーム入力まで同期してくれる
GhostlabはSassやCoffeescriptなどのコンパイルはできない

インスペクターがついている

Chrome DevToolsのようなインスペクターがついていて、接続している端末のページをインスペクトできます。たとえば、Nexus 5でのレイアウト表示を調整・確認したい場合、Ghostlabからインスペクターを開いて要素にマウスオーバーすると、その部分がNexus 5の画面でもハイライトされます。また、Chrome DevToolsと同じようにスタイルを編集すると、その場でNexus 5の画面に反映されます。

写りが悪いですけど、こんな感じです ↓

Ghostlabの右パネルにアクセスしている端末が表示されて、各端末の右に表示されている< >をクリックするとブラウザ上でインスペクターが立ち上がります。

スクロールやフォーム入力まで同期してくれる

ブラウザの自動リロードだけでなく、スクロールやクリック、フォームの入力まで同期してくれます。接続した複数の端末が同時にスクロールしたりページが遷移したりするのは、なかなか見ていて気持ち良いです。笑

同期の様子はこちらの紹介ビデオでどうぞ。このビデオにあるとおり、設定は簡単なので、ここでの説明は省略します。

BrowserSync（無料）

http://www.browsersync.io/

Ghostlabのようにブラウザの自動リロードだけでなく、スクロールやクリックの同期ができるツールです。しかも無料でMac、Win、Linuxでも動きます！Ghostlabのインスペクター機能が必要なければ、BrowserSyncが最強かもしれません。ただ、Node.jsのインストールやコマンドラインからnpm（node package manager）でインストールしたり、設定ファイルを書いたりする必要があり、コマンドラインの扱いに慣れていない場合はつらいかもしれません。

BrowserSync単体でのインストールや設定については、「Browser-Syncの使い方 – A Memorandum 」がとても参考になりました。Githubで設定ファイルもシェアしてくれていてありがたいですね。さすが、こもりさん。

MAMPとの連携

BrowserSyncをMAMPと連携させるには、オプションにあるproxyの設定が必要です。僕の場合、bs-config.jsファイルの以下の部分を変更しました。

外部サーバのアドレス

"proxy": "localhost:8080"

ファイルのWatch指定

"files": ["wp/wp-content/themes/rriver2/*.php","wp/wp-content/themes/rriver2/*.css"]

ブラウザ起動時にアクセスするURL

"open": "external",
"startPath": "/rriver/"

GulpやGruntと連携

また、Gulp や Grunt のプラグインが用意されているので、それらタスクランナーと連携させれば、CodeKitでできるSassやCoffeeScriptなどの各種ファイルのコンパイルも一緒に実現できます。

設定の手間はかかりますが、無料ですし、BrowserSync + Gulpが最強のブラウザテスト環境ツールなのかもしれません。Ghostlabのインスペクター機能もかなり捨てがたいですが。。。

ngrok（無料、または、自分で決めた金額）

https://ngrok.com/

最後に紹介するngrokは、上記3つとは少し性質の異なるもので、ローカル環境で作ったサイトを他のPCや端末で外部ネットワークからアクセスできるようにするツールです。

ローカル環境ではCodeKit、Ghostlab、BrowserSyncのいずれかのツールを活用して制作
レビューの準備ができたらローカルのサイトを外部ネットワークのユーザにngrokでシェアする

というワークフローにすれば、かなり効率的に作業が進められそうですよね。外出先やコワーキングスペースなどで、ネットワーク環境がコントロールできない場合にも重宝しますね。

無料でも使えるけど、お金があったら自分で金額を決めて払ってね（pay-what-you-want）というサービスです。開発者は25ドル/年を推奨していて、継続して使うなら、開発者の方をサポートするためにもお金を払って使いたいですね。Mac、Win、Linuxでも使えるツールです。

読み方は「グロック」か「エングロック」のどちらかですかね？

インストール方法と使い方

ngrok.com/ からZIPファイルをダウンロードして解凍。僕のMacBook Airの場合、パスの通っている /usr/local/bin/ に解凍したファイルを入れてしまいました。

あとはコマンドラインで以下のように入力すればすぐに使えます。

$ ngrok 8888

すると、下の画面のようにngrok.comのランダムなサブドメインのついたアドレスをくれるので、そこからローカルサーバにアクセスできます。

サービスに登録（無料）すると、サブドメイン（例： hogehoge.ngrok.com）を指定できるようになります。また、お金を払うと、そのサブドメインをキープすることも可能です。

[追記: 2015/01/25]
無料でサービスに登録すると、ngrok.comのユーザ画面で「auth token」がゲットできるので、以下のコマンドで初めて使う際に認証を通しておきます。

$ ngrok -authtoken XXXXXXXXXXXXXXXXXXXX 80

認証が完了すると、以下のコマンドを使ってサブドメインを指定できるようになります。
[/追記]

以下のコマンドで hogehoge.ngrok.com から localhost:8080 にアクセスできるようになります。

$ ngrok subdomain=hogehoge 8080

便利な世の中になりましたね。

その他の便利機能

その他にも、以下のような機能もあり、かなり重宝しそうなツールですね。いちいちテストサーバの環境を構築してFTPでファイルをアップロードしなくても良いのは嬉しい限りです。

パスワード保護（要登録）
独自ドメインでの使用（有料）

VirutalHostを使ってサイトを動かしている場合の設定

自分のローカル環境ではport番号ごとに別のサイトを走らせているため（e.g. localhost:8080はプロジェクトA用、localhost:8090はプロジェクトB用、といったように）、以下の2つの設定が必要でした。以下は localhost:8080 で走らせている WordPress を ngrok で見るために必要な設定です。

1. Apacheの設定ファイルにServerAliasを追加

以下のようにApacheのVirtualHostの設定にServerAliasを追加しました。

Listen 8080

DocumentRoot “/location/to/the/site”
ServerAlias hogehoge.ngrok.com

※ 僕はMAMPの /conf/apache/extra にある httpd-vhosts.conf に VirtualHost の設定を書いているので、そこに上記の設定を追加しました。

2. WordPressのRoot Relative URLプラグインのインストール

WordPressのURLを相対パスにしてくれるプラグインのインストールが必要です。Root Relative URL というプラグインでうまく動きました。僕の環境 + サーバ設定では、Relative URLというもう1つのプラグインではうまく動きませんでした。

余談

いろいろいじくっていたら、Chromeでlocalhost:8080がlocalhostに飛ぶようになってしまって困ったのですが、キャッシュをクリアしたらなおりました。

finchもあるよ

まだベータ版ですが、finch というサービスもあります。フリープランで10時間/月、有料で一番安いのだと20時間/月 + カスタム・サブドメインが使えるそうですが、ベータ修了後に変更の可能性があるそうです。フリープランだとカスタム・サブドメインが使えないですし、月額だと結構費用がかさばりそうなので、ngrokのほうが良さそうですね。ざっと使ってみた感じ、接続スピードもngrokのほうが良い感じです。

機能比較一覧

ngrokは性質の違うツールですが、表に入れてしまいました。
※ 右にスクロール（スワイプ）して見てください。

機能	CodeKit	Ghostlab	BrowserSync	BrowserSync + Gulp	ngrok
自動リロード
MAMP（外部サーバ）との連携
スクロールなどの動機
Sassなどのコンパイル
インスペクター機能
外部ネットワークから接続

「外部ネットワークから接続」に関しては、ルーターの設定などを変更すれば可能ですが、外出先やコワーキングスペースでは不可能なため、ngrokのみにしています。

最後に…

いかがでしょうか？

他にも便利なツールがあったら、ぜひ、共有していただければ幸いです。

VagrantというツールでもVagrant Shareというのがあるらしく、同じようなことが実現できるようなことを読みました。テスト環境構築の効率化に、そっちも見てみたほうが良いんですかね？日々是勉強です。

レスポンシブ・イメージがもうすぐネイティブ実装！いまから使える？ポリフィル「Picturefill 2.x」を検証

2014/08/22 13:41 | レスポンシブWebデザイン

レスポンシブ・デザインの画像の扱いの課題を解決するのが「レスポンシブ・イメージ」です。この「レスポンシブ・イメージ」には紆余曲折あったわけですが、熱心な開発者の方々のおかげでようやく仕様がまとまり、ブラウザでのネイティブ実装も進んでいます。

結論から言うと、ブラウザのネイティブ実装はまだこれからですし、ポリフィルのPicturefill 2.xには大きな欠陥があり、プロダクションサイトでの使用は待ったほうが良いと思います。しかし、多くの開発者が多大な時間を費やして実現しようとしているレスポンシブ・イメージです。この存在が日本でもより多くの人に広まればと思い、いまの状況をまとめてみました。

追記： 2015.05.30

すでにPicturefillを使っている場合、2.3.1以降であることをご確認ください！

レスポンシブ・イメージのいま

レスポンシブ・イメージの各ブラウザでの実装状況を、実装を行っている開発者の1人、YoavさんがDev.Operaの記事「Native Responsive Images（2014年8月19日）」で以下のように書いています：

数週間のうちに、Chrome 38、Opera 25、Firefox 33に搭載予定
Webkitではsrcsetとsizesが実装済みだがSafari 8には未搭載。picture要素はこれから実装予定（Yoav Weissさんが実装中）
IEでは実装を「考え中（under consideration）」と公表。実装の可能性もある？

SafariとIEでの実装を残すのみということで、AppleとMicrosoftの今後の動きに注目です。Firefox 33ではRICGサイトで「behind flags」とある通り、設定の変更が必要です。

Picturefill 2.x

レスポンシブ・イメージをJavaScriptで実装するポリフィル「Picturefill 2.x」では、最新のpicutre要素の仕様に沿ったものが実装されていて、picture要素、srcset属性、sizes属性を使ってレスポンシブ・イメージを実現できます。

picture要素の仕様が固まる前から機能的には同等なことが実現できるように用意されていたPicturefill 1.xのアップデート版です。よい感じで動いてはいるものの、大きな欠陥があるので、プロダクションサイトでの使用には、もう少し検証が必要だと思います。それまではPicturefill 1.2を使うのが良さそうです。

Picturefill 2.xのブラウザ・サポートはこちらで確認できます。Dev.Operaのこの記事で推奨されているフォールバックとしてのsrc属性の記述に問題であったり、source要素使用の際の、IE9やAndroid 2.3での注意点などが書いてあるので、使用の際には必ずチェックすることをオススメします。

Chrome CanaryとFirefox Nightlyでの実装

Picturefillなしでも、Chrome CanaryとFirefox Nightではレスポンシブ・イメージがネイティブで動作します。

Chrome Canaryは、ダウンロードして起動すると、そのままpicture要素やscrset属性、sizes属性が使えます。今回のデモのために作ったページは、問題なく動いてます。

Firefox Nightlyの場合は、Shift-F2でDeveloper Toolbarを表示させて以下の設定を有効にする必要があります。

pref set dom.image.srcset.enabled true
pref set dom.image.picture.enabled true

設定はアドレスバーからabout:configにアクセスすることで確認できます：

レスポンシブ・イメージで解決できる3つの課題

さて、デモを紹介する前に、レスポンシブ・イメージでいったいなにを解決したかったのか、おさらいしておきたいと思います。そもそも、なんでレスポンシブ・イメージが必要なのか？ってやつですね。

レスポンシブ・イメージで解決できる課題のなかで、一番重要なのは以下の3つです：

幅に合わせた寸法での表示
画像のアートディレクション
Retina対応

1. 幅に合わせた寸法での表示

表示パフォーマンスを考慮すると、横幅が800pxのスクリーンには800pxの画像、1200pxのスクリーンには1200pxの画像を表示するといったように、それぞれの幅にあわせた画像を表示するのがベストです（厳密に言うとRendered Sizeにあわせるのがベストなんですけどね）。たとえば、1200pxの画像を300pxで表示すると、レンダリングのためにブラウザのリソースを必要とするだけでなく、ファイルサイズも必要以上に大きくなってしまいます。

2. 画像のアートディレクション

写真によっては必要ないですが、大き目のスクリーンでは全体が見える写真が良い場合でも、スマホのような小さいスクリーンでは、写真の要点にクローズアップしたものが良い場合もありますよね。

3. Retina対応

Retinaスクリーンが登場してしばらく経ちますが、綺麗な画面で画像だけがぼやけていると、かなり印象が悪くなります。Retinaスクリーン向けには、それ用の高解像度の画像を表示したいですよね。

4つ目のユースケース

HTML Living Standardにある仕様の説明やDev.Operaの記事「Responsive Images: Use Cases and Documented Code Snippets to Get You Started」では、ファイルタイプによるユースケースが紹介されていますが、個人的にはあまり重要だと思っていません（少なくとも2014年8月現在では。。。）。

Picturefill 2.xデモ①：幅に合わせた寸法での表示

ブラウザの表示領域（Viewport）に合わせて違うサイズ（寸法）の画像を選択する方法です。HTML Living Standardの仕様では「viewport-based selection」と呼んでいます。この使い方の場合、picture要素は必要なくて、img要素にsrcset属性を使って複数のサイズの画像を記述します。

HTMLは以下のようになります：

<img
  sizes="100vw"
  srcset="img/200w.png 200w, img/400w.png 400w, img/600w.png 600w, img/800w.png 800w, img/1000w.png 1000w, img/1200w.png 1200w"
  alt="Picturefill 2.xのデモ画像">

デモはこちら

sizes属性

sizes属性で条件とそれに応じた画像表示を指定します。条件にはメディアクエリを使いますが、ここでは指定をせず、画像表示のみ「100vw」として指定しています。vw（Viewport Width）は表示領域の割合を表す数値で、100vwはViewportの100%になります。sizes属性は、デフォルトが100vwなので指定しなくてもOKです。

たとえば、sizes=”(min-width: 640px) 50vw, 100vw”とすると、640px以上ではViewportの50%に、また、それ以外の幅ではViewportの100%での表示に最適な画像を選択するよう指定しています。これは、たとえば640pxのブレイクポイントを境に、それぞれ50%幅の2カラムのレイアウトにする場合に使います。

<img
  sizes="(min-width: 1140px) 570px, (min-width: 640px) 50vw, 100vw"
  srcset="img/400w.png 400w, img/600w.png 600w, img/800w.png 800w, img/1000w.png 1000w, img/1200w.png 1200w"
  alt="幅に合わせた寸法での表示の例">

デモはこちら

※この例では、コンテンツの最大幅を1140pxに指定しているため、それ以上のスクリーンサイズでは570px（1140px ÷ 2）を指定しています。

sizes属性の指定の順番について

sizes属性では、メディアクエリが当てはまる最初の条件が適用されるため、以下の2つでは表示が異なるので注意が必要です。

sizes="(min-width: 640px) 30vw, (min-width: 1140px) 570px, 100vw"

sizes="(min-width: 1140px) 570px, (min-width: 640px) 30vw, 100vw"

注： 100vwの前のスペースのある・なしでChrome Canary（Mac / 39.0.2129.0 canary (64-bit)）では挙動が異なりました。Picturefillでは同じ挙動でした。

srcset属性

画像のURLと幅を「w」で指定したものを1組みとしたものをカンマで分けたリストにして指定します。このリストとsizes属性の指定をベースに、ブラウザが状況に応じて最適な画像を選択してくれる仕組みになっています。ブラウザ側での画像選択の仕様は細かく指定されていなくて、将来的には回線速度やユーザのブラウザ設定などをもとに、ブラウザが自動でやってくれるようになるそうです（ブラウザ・ベンダー次第）。

src属性について

srcsetをサポートしないブラウザ用に、フォールバックとして記述することが推奨されています（参照）。これはデモ②、デモ③でも同様です。しかし、Picturefill 2.xではいくつかの理由により、入れないようにしたほうが良いようです。

スクリーンサイズと表示される画像

sizes属性が固定の100vwのデモだと、表示される画像は以下のようになります。

スクリーン幅	表示される画像（1x ピクセル比）
〜400px	400w.png
401px〜600px	600w.png
601px〜800px	800w.png
801px〜1000px	1000w.png
1001px〜	1200w.png

ピクセル比が1.0より大きい場合

たとえば、ピクセル比（device pixel ratio）が2.0のiPhone（4以上）やiPad（第3世代以上）、また、3.0のNexus 5のような端末だと、それら端末のスクリーンに最適な画像サイズを選択してくれます。

端末	ピクセル比	幅（CSS Pixel）	表示される画像
iPhone 5s	2.0	320px（Portrait）	800w.png
iPhone 5s	2.0	568px（Portrait）	1200w.png
iPad	2.0	768px（Portrait）	1200w.png
iPad	2.0	1024px（Portrait）	1200w.png
Nexus 5	3.0	360px（Portrait）	1200w.png
Nexus 5	3.0	640px（Portrait）	1200w.png

Picturefill 2.xデモ②：画像のアートディレクション

ブラウザの表示領域（Viewport）にあわせて、内容の異なる画像を選択する方法です。HTML Living Standardの仕様では、「art direction-based selection」と呼んでいます。

以下のデモでは、640px未満のスクリーンではクローズアップした写真のcat-XXXw-close.jpgのいずれか、640px以上では全体が見られる写真のcat-XXXw.jpgのいずれかが表示されるように指定しています。

HTMLは以下のようになります：

<picture>
  <source
    media="(min-width: 640px)"
    srcset="img/cat-800w.jpg 800w, img/cat-1000w.jpg 1000w, img/cat-1200w.jpg 1200w">
  <img
    srcset="img/cat-400w-close.jpg 400w, img/cat-600w-close.jpg 600w, img/cat-800w-close.jpg 800w, img/cat-1000w-close.jpg 1000w, img/cat-1200w-close.jpg 1200w"
    alt="猫の窓際">
</picture>

デモはこちら

source要素

source要素では、640px以上のスクリーンサイズで表示する画像を、srcsetを使って複数指定しています。複数指定した画像の中から、ブラウザが最適な画像を選択してくれる仕組みです。Picturefill 2.xではIE9で問題があるので、以下のようにIEコメントで囲んだ<video>タグを記述するように書かれています。

<picture>
  <!--[if IE 9]><video style="display: none;"><![endif]-->
  <source
    media="(min-width: 640px)"
    srcset="img/cat-800w.jpg 800w, img/cat-1000w.jpg 1000w, img/cat-1200w.jpg 1200w">
  <!--[if IE 9]></video><![endif]-->
  <img
    srcset="img/cat-400w-close.jpg 400w, img/cat-600w-close.jpg 600w, img/cat-800w-close.jpg 800w, img/cat-1000w-close.jpg 1000w, img/cat-1200w-close.jpg 1200w"
    alt="猫の窓際">
</picture>

img要素

ここでは640px未満のスクーンで表示する画像を、srcsetを使って指定しています。

Picturefill 2.xデモ③： Retina対応

実は、デモ①とデモ②でもRetina対応ができているのですが、Retina対応を明示的に記述したい場合は、以下のような指定も可能です。HTML Living Standardの仕様では、「device-pixel-ratio-based selection」と呼んでいます。

<img
  srcset="img/cat-400w.jpg 1.0x, img/cat-800w.jpg 1.5x, img/cat-1200w.jpg 2.0x"
  class="img-fixed-400px"
  alt="猫の窓際">

デモはこちら

x記述子

srcset属性に、1.5xや2.0xといったx記述子（descriptor）を画像URLとペアにして記述することで、それぞれのピクセル比（device-pixel-ratio）で表示したい画像を指定できます。

固定幅にするためのclass

HTML Living Standardに注意書きに、表示領域にあわせて画像を表示する場合（width: 100%にしている場合など）は、x記述子は適切ではないとあります。その場合は、デモ①のようにsrcset属性に複数の画像を指定するとこで、ブラウザが適切な画像サイズを選択してくれます。

ブラウザでの動作確認

Picturefill 2.1.0とネイティブ実装（Chrome CanaryとFirefox Nightly）での動作を比較・確認してみました。

Picturefill 2.1.0

デスクトップブラウザ

以下のブラウザでテストしてみました：

Mac Chrome 36.0.1985.143
Mac Firefox 31.0
Mac Safari 7.0.6 (9537.78.2)
IE 11.0.9600.17207
Win Chrome 36.0.1985.143 m
Win Firefox 31.0

※IE10以下でのテストをサボっててすみません。テストしたら追記します。テストされた方がいたら、ぜひ、結果をコメントでシェアいただければ幸いです！

問題・バグ？

仕様で推奨されているようにフォールバックとしてsrc属性を使用して画像を指定すると、ページが読み込まれる際に、フォールバック画像が読み込まれた後にsrcsetの画像が読み込まれます。
これは、PicturefillのBrowser Supportによると回避策がないらしく、src属性を入れないで記述するしかないようです。
しかし、src属性を入れないとカラの画像の枠とaltテキストが一瞬表示されてしまいます。また、JavaScrptがオフの環境では、altテキストが表示されるのみになります。

モバイル端末

以下のモバイル端末でテストしてみたところ、デスクトップブラウザと同じようにカラの画像の枠とaltテキストが一瞬表示されます。

iPhone 5s iOS 7.1.2 (11D257)
iPad（第3世代） iOS 7.1.2 (11D257)
Nexus 5 Android 4.4.4 Chrome 36.0.1985.135

Chrome Canary 39.0.2130.0 canary (64-bit)

Picturefillであった問題もなく、良い感じでレスポンシブ・イメージを使ったデモページが動作しています。

Firefox Nightly 34.0a1

以下の問題がありました。たぶん、2つともバグですね。

ページをリロードしないと画像が切り替わらない
デモ②のsrcsetで複数指定した画像が、1つ目のものだけしか選択されない

画像のファイルサイズについて

今回の検証のために、200pxから1200pxまで、200px毎に画像を作ってみたのですが、ファイルサイズは以下になりました。ImageOptimで最適化をしたあとのファイルサイズです。

たとえば、400pxしか必要ないのに1200pxのファイルを表示していたら、ユーザに83KBも無駄にダウンロードさせることになります。1つだけならいいですが、これが複数の画像になると1MBなんてすぐにいってしまいますね。表示パフォーマンスの観点からも、レスポンシブ・イメージの実装が安定してきたら、ぜひ活用したいですね。

ファイル名	寸法	ファイルサイズ
cat-200w.jpg	200 x 120px	7 KB
cat-400w.jpg	400 x 240px	17 KB
cat-600w.jpg	600 x 360px	32 KB
cat-800w.jpg	800 x 480px	50 KB
cat-1000w.jpg	1000 x 600px	74 KB
cat-1200w.jpg	1200 x 700px	100 KB

まとめ

残念ながら、picture要素やsrcset属性を使ったレスポンシブ・イメージはまだ使わないのが得策のようです。

Picturefill 2.1.0について

いい感じで動いているのですが、画像が読み込まれる前にカラの画像の枠とaltテキストが一瞬表示されるという致命的な欠陥が残っています。また、フォールバックにsrcを使って画像を指定すると、一度その画像が表示されてからsrcsetに指定した画像が表示される（=無駄に画像が読み込まれる）という欠陥もあります。Picturefill 1.2では、こんなことはなかったと思うのですが。

レスポンシブ・イメージの大きな目的の1つは表示パフォーマンスの最適化なので、src属性は記述しないという選択肢しかないですが、一瞬とはいえ壊れた表示（カラの画像の枠とaltテキスト）が出てしまうのは、かなりイケてない体験です。これはジレンマですね〜

ブラウザでのネイティブ実装について

ブラウザへの実装は、Chromeでは良い感じに仕上がっていますし、38からの搭載が決まっているようなので楽しみです。しかし、FirefoxはNightlyでの実装を見る限り、33での搭載も「behind flags」で設定の変更が必要ですし、まだまだという印象を受けました。

2年前に比べればものすごい進歩ですが、レスポンシブ・イメージが普及するまでにはまだ時間がかかりそうです。また、ブラウザでサポートされても、実際に作るほうの手間も考えものです。

複数画像の作成がネックになりそう

今回デモ用に画像を作ってみて思ったのですが、結構手間がかかります。

この作業を簡単に自動化できる良いツールや手法がないと、レスポンシブ・イメージ利用のキャズム超えはまだ先なのかなぁと思います。

ベクター画像だったらSketchで解決できますけど、写真の場合は無理そうだし。Gruntだと設定がちょっと面倒だし。CodeKitあたりのStatic Site Generatorに実装されるのが理想でしょうか？Photoshopでプラグイン出てませんかね？

若干本末転倒な感じは否めないですが、いろいろな手間や将来性を考えたら、CMSやWebサーバで解決しちゃうという選択肢もありだなぁと思う今日このごろでした。

最後に & お願い

記事中の誤った情報のご指摘やレスポンシブ・イメージに関する最新情報やTipsなどがありましたら、このブログのコメント欄でもTwitter（@rriver）でも良いのでシェアいただければ幸いです。

参考リンク集

これからのコンテンツ制作に必要な「気の利いた誘導」とは？

2014/07/13 22:09 | ウェブ制作・運営ノウハウ

ウェブだけでなく、コンテンツ制作全般のキモとなる考え方を図にすると、上図のようになります。しかし、これが、なかなか実行するのが難しい。常々そんなことを考えていたところ、先日「The Core Model」というすばらしいプレゼンに出会い、目からウロコだったので自分なりに解釈して整理してみました。続きを読む

Chrome 38からDevToolsに搭載されるレスポンシブ表示確認ツール「Device Mode」が良さげ

2014/07/07 11:37 | 制作・効率化ツール

現在Chrome Canaryに実装されているChrome 38から、DevToolsにレスポンシブWebデザインで作ったサイトの表示が簡単に行えるツール（Device Mode？）が実装されるようです。

Chromeのプラグインやブックマークレットでも同じようなツールはあるのですが、よく使うChrome DevToolsに実装されるとさらに便利になりそうです。

正式版はまだChrome 35なので、まだ3リリース後（約18週間）の正式版での実装が待ち遠しいですね。続きを読む

HTML5やCSS3のブラウザサポート状況を簡単に調べられる「Can I use…」のGoogleアナリティクス連携が便利

2014/07/05 21:20 | 制作・効率化ツール

HTML5やCSS3のブラウザサポート状況が確認できるcaniuse.comのベータ版が2014年6月に公開され、デザインが刷新されました。

このベータ版のデザインの良さにも驚きましたが、なにより驚いたのはGoogleアナリティクスとの連携機能でした。ベータ版の「Settings」から設定を行うと、Googleアナリティクスのデータを読み込むことができ、自分のサイトに訪れるユーザが使うブラウザで、ある特定のHTML5やCSS3の機能が、どのくらいサポートされているかがわかります。世の中便利になりましたね〜。

実は現行版でも同じ機能が使えるのですが、残念ながらぜんぜん気づきませんでした。

※ちなみに、このベータ版は数週間テストを行いフィードバックを得てから、本番サイトに反映するとのことです。
続きを読む

マルチデバイス時代に最適なウェブサイトのナビゲーション構造とは？※未解

2014/02/21 19:33 | レスポンシブWebデザイン

今回も、このブログでいま流行りの「マルチデバイス時代」シリーズです。
前回に引き続き、これからのレスポンシブ・デザインについて書いていきます。今回はナビゲーションについてです。

BootstrapやFoundationで実装されているように、レスポンシブ・デザインでのナビゲーション・インターフェイスには標準的なものが確立されつつあります。しかし、それが従来のウェブサイトの構造に簡単に当てはめられるかというと、そうでもありません。使っている技術は根本的にはあまり変わりませんが、マルチデバイス時代の今、解決しようとしている課題は以前と大きく異なります。

全くサイズの違う複数の端末に、デスクトップ向けの考え方で作ったサイト構造を最適化しようとしているわけですから、ゼロから考え直さないと、根本的な解決は難しいのかもしれません。続きを読む

マルチデバイス時代の制作手法の選び方

2014/01/17 1:08 | レスポンシブWebデザイン

遅ればせながら、あけましておめでとうございます。

昨年10月後半から職場での環境が大きく変わったこともあり、ブログは放置状態で、ソーシャルメディアでの投稿すらあまりできませんでした（言いわけ）。

2014年も1月も後半に差し掛かってしまいましたが、今年もRriverを、どうぞよろしくお願いします。役に立つ情報を掲載することを目標に、今年も1年頑張ります。

2012年5月に「レスポンシブWebデザインのウェブサイトを半年運営してみて思ったこと」という記事を書いてから、はやくも1年半以上が過ぎ、RWDの本を出してから約1年もの年月が過ぎました。2014年のはじめということもありますし、これから何回かに分けて、これからのレスポンシブWebデザインについて考察をまとめていきたいと思います。

今回は、以下の2つについて：

「レスポンシブWebデザイン」はどうなる？
制作手法を選択する際の判断基準とは？

マルチデバイス対応の際に考えるべき「コンテンツ・パリティ」とは？

2013/10/22 7:02 | ウェブ制作・運営ノウハウ

どんな端末でウェブサイトを閲覧しても同様のコンテンツを提供する「コンテンツ・パリティ（Content Parity）」という考え方は、マルチデバイス対応が必須になったいまのウェブ制作にとって、とても大切なものです。前回の「モバイル対応でレスポンシブWebデザインとSEOが向かう先」の後編にも関わる内容なので、今回は「コンテンツ・パリティ」についてまとめてみます。マルチデバイス対応をする際に誰もが一度は考えなければならないことです。若干いまさらな感じもしなくはないですが、何かのお役に立てば幸いです。

モバイル対応でレスポンシブWebデザインとSEOが向かう先（前編）

2013/10/11 21:13 | レスポンシブWebデザイン

かなり久々の投稿になってしまいましたが、今回はレスポンシブWebデザインとSEOについて、最近考えていることや調べていることを整理してみました。若干長めの文章ですが、久々にお付き合いください！前・後編の2回に分けて公開する予定です。

では、さっそく本題に入ります。

検索エンジンからのトラフィックの流入に収益を依存しているビジネスの場合は特に、SEOはビジネスの死活に関わる大きな問題です。80〜90%のトラフィック流入元がGoogleの自然検索というサイトも少なくないのではないでしょうか？現在、制作を手伝わせてもらっているサイトも自然検索からの流入が多いサイトで、モバイル対応にもUXへの影響だけでなく検索エンジンの評価への影響も考慮して、かなり慎重に進めています。

そこで、今回の投稿では、デスクトップ向けのウェブサイトをレスポンシブWebデザインでリニューアルする際、また、デスクトップにしかレイアウトが対応していないウェブサイトをモバイルに対応させる際に、SEOについて考えておくべきことをまとめてみます。

マルチデバイス時代に知っておきたい、ウェブ・コンテンツに対する2つのアプローチ

2013/06/23 18:18 | ウェブ制作・運営ノウハウ

前回の投稿「レスポンシブ・デザインとアダプティブ・デザインの定義を整理してみた」に対して、「覚え書き@kazuhi.to」で「続・レスポンシブWebデザインとかアダプティブWebデザインとか」として、再度レスポンシブとアダプティブについての木達さんの解釈をまとめています。記事中でおっしゃっている通り、僕とは見解が違うところもありますが、特に図解の部分はウェブ制作に関わる人には必見だと思ったので、こちらでも共有させていただきます。マルチデバイス時代のウェブ制作において考慮すべき技術的な制作手法の分類がすっきり整理されています。

※上図は「続・レスポンシブWebデザインとかアダプティブWebデザインとか」の2013/6/23の時点のものを内容を変更せずに、そのまま掲載させていただいています。（木達さん、ありがとうございます！）

「レスポンシブ」や「アダプティブ」という言葉の扱いはとりあえずわきに置いておくとして、こういった制作手法（考え方や方法）の分類は、制作の初期段階で制作チーム全員で共通の理解を持てるようにすり合わせをしておくと良いのではないでしょうか？続きを読む

レスポンシブ・デザインとアダプティブ・デザインの定義を整理してみた

2013/06/19 0:11 | レスポンシブWebデザイン

「レスポンシブからアダプティブへ – 必要な情報を、必要なときに、必要としている人へ」という記事を読んでいてレスポンシブ・デザインやアダプティブ・デザインの言葉の定義を一度整理しておいたほうが良さそうだと感じたので、遅ればせながら自分なりにまとめてみました。

レスポンシブ・デザインやアダプティブ・デザインについて話をする際に、そもそもの定義がずれていると話が噛み合わず、無駄な討論をしかねません。さんざん討論したあげく「ところで、アダプティブ・デザインってどんな意味で使ってる？」と問いなおしたら、お互いに勘違いしてたとか、結構ありそうな話です。

どれが正しいとか正しくないとかではなくて、僕が知る範囲で一般的に使われている定義をまとめてみました。いくつかの意味で使われていることを知っておけば、ミス・コミュニケーションも未然に防げる可能性が高くなるのではないでしょうか？

※ここで紹介する定義を「え？なにそれ？！」と思われた方、ぜひコメント欄でご指摘ください！適宜、追記、修正したいと思います。続きを読む

コードエディター「Brackets」のレスポンシブモードが最強！（リリースされるかわからないけど…）

2013/06/04 0:21 | 制作・効率化ツール

Adobe社が開発・メンテしているオープンソースのコードエディター「Brackets」向けの「Responsive Design Tool」が、YouTubeのデモを見る限り、かなり良い感じなのでご紹介ます。Adobe Edge Reflowがデザイナー向けのWYSIWYGツールだとすれば、Bracketsのレスポンシブ・デザイン・ツールは開発者がより効率的にコードを編集するためのツールを目指して作ったそうです。デモを見ただけでも、これを使えばレスポンシブなサイトのコーディングが数倍効率化されるのが想像できます。Designing in the Browserがコードエディター上できてしまうのはすごく理想的です。

このツールの開発者でありAdobeのDeveloper EvangelistでもあるBrimelowさんは、「まだバグも多く終わっていないところが沢山あるので、どうなるかわからない」と言っているのですが、ぜったい完成させて欲しいと思う今日このごろです。「どうなるかは必ずお知らせするよ」と言っているので、近々いい知らせが発表されることを願っています。一応、デモとして作ったものは実際に動いているそうなのですが、細かいところの調整が一番大変なのでしょう。コードが落ち着いたらオープンにして、Bracketsコミュニティでがしがし完成させていって欲しいですね。本当に期待してしまいます。続きを読む

レスポンシブな時代に必要なWebディレクターの7つの心得

2013/05/27 22:50 | ウェブ制作・運営ノウハウ

先日、僕の恩師のウェブ制作会社で開催された勉強会で「レスポンシブWebデザインのワークフロー」についてお話させていただいたんですが、その際に「意思決定層との密なコミュニケーションをとり、スムーズに開発を進めていくために、苦労した点や工夫した点」について質問をいただきました。その回答をまとめたので、このブログでも共有したいと思います。今回まとめたものはレスポンシブWebデザインでの制作に特化した内容ではないですが、以下に挙げるようなWebディレクターとしての基礎知識やスキルが、レスポンシブWebデザインのような柔軟な対応を強いられる制作では大切になると感じています。

Question:
意思決定層との密なコミュニケーションをとり、スムーズに開発を進めていくために、苦労した点や工夫した点を教えてください。

Answer:
どれもディレクターとして基本的な内容になりますが、僕は以下のようなことを常に心がけています。というか、自分に言い聞かせるようにしています。

RWDの定番チェックツールとして期待できる「Responsive Inspector」が便利かも

2013/04/28 18:05 | レスポンシブWebデザイン

レスポンシブWebデザインで作ったサイトをチェックするための定番ツールになりそうな「Responsive Inspector」というChrome拡張機能が先日リリースされていたので、ちょっとご紹介。なんとこの拡張機能、1つのツールで以下の3つができてしまいます。

ページに設置されたメディアクエリの確認
ブラウザのウィンドウ幅の変更
ページ全体のスクリーンショット

過去にいろいろなツールを使ってきましたが、この3つの機能をまとめてできるのはかなり嬉しいツールですね。まだβ版で、スクリーンショットはJPGしか保存ができませんが、開発者サイトのコメント欄には、次のリリースではPNGでも保存できるようにしたいと書いてありました。今後の機能改善にも期待できそうです。使い方も以下のように簡単です。続きを読む

Pages: 1 2 ... 6 7 8 9 10 ... 16 17

Picturefill 2.x問題の要点

より詳しくは…

他のレスポンシブ・イメージ関連の記事

Chrome DevToolsのメディアタイプのエミュレーション機能

追記: 2016.02.01

ん？なんじゃ、こりゃ！？

Firefoxの場合

見えないところにもこだわる「粋」なはからい

CSS Flexible Box Layout Moduleのブラウザサポート状況

Desktop

Mobile / Tablet

導入方法

ショートコードの書き方

Picture elementのブラウザサポート状況

Desktop

Mobile / Tablet

表示のカスタマイズ・日本語化とスタイルの変更点

caniuse-shortcode-master/lib/display.php

caniuse-shortcode-master/lib/css/caniuse.css

改善の要望

説明と注意点

追記： 2016.01.29

目次

レスポンシブ・イメージ・プラグインの特徴

a. レスポンシブ・イメージの解像度対応が可能に

b. アートディレクションは未対応

c. Picturefill 2.2.0を使用しています

d. srcsetのサポート状況

プラグインの導入手順

1. プラグインのインストール

2. WordPressの画像書き出し設定を追加

画像運用の自動化が可能に

WordPressが書き出す画像の最適化

最後に

他のレスポンシブ・イメージ関連の記事

VMware FusionのWin 7 Home Premium 64bitの移行手順

目次

VirtualBoxのインストール

Win7のVMDKファイルのコピー

*.vmdkファイルをコピーする

新規仮想マシンの作成

作成画面：その1

作成画面：その2

「システム」設定画面

「ストレージ」設定画面

仮想マシンにGuest Additionsをインストール

トラブルシューティング

ディスプレーの自動リサイズが機能しない

仮想マシンのディスクサイズが変更できない

VMDKファイルからVDIファイルへの変換

VDIファイルをリサイズ

まとめ

RICGのニュースレター

レスポンシブ・イメージのブラウザサポート状況

他のレスポンシブ・イメージ関連の記事

新製品発表後のApple.comトップページ

まずは、訂正とお詫びから

Appleがトップページでカルーセルを使う理由

まずは推奨の記述方法から

目次

レスポンシブ・イメージの2つの使い道

1. 同じ内容で画像サイズのみを変更する（解像度の変更）

2. 違う内容の画像を表示する（アートディレクション）

2つの記述方法

1. 解像度の変更

2. アートディレクション

pictureとsrcsetの違い

srcsetの場合はブラウザに選択の余地がある

pictureの場合は限定的な指定になる

pictureとsrcsetの組み合わせも可能

まとめ

使用した画像について

他のレスポンシブ・イメージ関連の記事

保存場所の変更

ファイル・タイプの変更

ファイル名の変更

影のあり・なし

多機能ユーティリティ「Onyx」

追記: 2014.10.18

ところが！