2016/02/01 22:16 | 制作・効率化ツール
以前書いた記事でChrome DevToolsでの印刷用CSSのスタイルの確認方法を紹介したのですが、Chrome 48で方法がだいぶ違っていたのでアップデート版を掲載しておきます。
以前の記事の時はChrome 43でOSはYosemiteでした。今回は、Chrome 48でEl Capitanになります。
DevToolsを開いたらescキーでConsoleを開いて、左端のメニューから「Rendering settings」を選ぶという方法もあります。
当時のバージョンは33でしたが、43になった今でもやり方は変わりません。以前の記事をご参照ください。
以上です！
2016/01/30 21:05 | 制作・効率化ツール
WordPressで関連記事を記事本文に簡単に挿入できるように、同じタグをつけた記事へのリンクを一覧で表示させるショートコードを作ってみました。同じことをしようとしている方の参考になれば幸いです。あくまで自己責任でローカル環境などでテストしてからお使いください。
記事にタグIDを指定してショートコードを入れると、そのタグがついた記事のリンク一覧が表示されます。
[tag-links tagid="100"]タグIDは、管理画面の「投稿 > タグ」メニューで表示されるリンクで確認してます（もっといい方法あると嬉しいんですけど）。
以下をfunctions.phpに入れます。
// shortcode to get links in with the same tag
function get_tagged_posts($atts, $content = null) {
$a = shortcode_atts( array(
'tagid' => ''
), $atts );
if(!empty($a['tagid'])){
$pageid = get_the_ID ();
$tag_link_content = '';
global $post;
$args = array(
'tag_id' => $a['tagid'],
'order' => 'DESC',
'posts_per_page' => -1,
'exclude' => $pageid
);
$tagged_posts = get_posts( $args );
if($tagged_posts){
$tag_link_content='';
foreach($tagged_posts as $post) :
setup_postdata($post);
$tag_link_content.='- '.the_title("","",false).'
';
endforeach;
$tag_link_content.='
';
}
wp_reset_postdata();
return $tag_link_content;
}
}
add_shortcode("tag-links", "get_tagged_posts");以下「#」はソースの行数です。
if(!empty($a['tagid'])){tagidが指定されてるかチェックします。
global $post;元記事のメインのThe Loop とは違うループの操作をするために指定してます。他の方法が良いという情報 も。WP_Query とか使った方が良いのでしょうか？
$args = array(
'tag_id' => $a['tagid'],
'order' => 'DESC',
'posts_per_page' => -1,
'exclude' => $pageid
);get_posts()を使って同じタグのついた記事一覧を取得するために、以下を引数として指定しています。
if($tagged_posts){
$tag_link_content='';
foreach($tagged_posts as $post) :
setup_postdata($post);
$tag_link_content.='- '.the_title("","",false).'
';
endforeach;
$tag_link_content.='
';
}get_posts()で記事が取得できたことを確認して、記事が取得されていた場合にループしてリンクを生成してます。
wp_reset_postdata();ループをリセットして、テンプレートタグが元記事のループを参照するようにします。
以上です。
推奨されていない書き方、より良い書き方などあったら、コメントなどでご指摘いただけたら幸いです。
よかったら他のWordPress関連の記事もどうぞ
2016/01/26 0:08 | ウェブ制作・運営ノウハウ
10年以上ひとつの組織のウェブサイトを運営してきて、4回ほど全面的なリニューアルを経験しています。リニューアルのたびに数千ページものHTMLを書き直すという作業をやってきました。その不毛とも思えるコピペ作業に、そろそろ終止符を打ちたいと考えています。
でも、どうすればそれを実現できるのか？
解決策はまだないんですけど、問題解決の第一歩は課題を明確にすることだと信じてます。とりあえず、いまの悩みを整理して打開策の手がかりにしたいと思います。技術も進歩してますし、5年、10年先に不毛な作業をしなくて済むように、今のうちに準備しておきたいと思ってます。
同じ悩みを抱えている方の何かの役に立てば幸いです。ていうか、すでに解決されてる方がいたら、ぜひご教授いただきたい。。。
「全面的なリニューアルなんて意味ないのでは？」という声が聞こえてきそうです。
僕もそう思います。
A/Bテストなどをやって部分最適を重ねてウェブサイトを改善していく ほうが、効果的な場合も多いすし、費用対効果という意味でも無難です。ただ、同じフレームワーク（デザイン、ナビゲーション・システム、レイアウト・システム、パターン・ライブラリなど）でやり続けていると、部分最適化にも限度があり、結果が頭打ちになるのではないかとも考えています。
また、3年も経つとユーザ環境や技術がだいぶ進化（または変化）しているので、時代に寄り添えるプラットフォームに乗り換えないとユーザには背を向けられ、競合からは取り残される危険性が高まります。
やっぱり、以下のような「リニューアル」をしなくてはならないタイミングがどこかで出てきます。
ブランディングの一環として「古い」「時代遅れ」という印象を与えないのも大切です。
業界によっては1〜3年に一度はマイナーなデザインのリフレッシュが、3〜10年に一度はメジャーアップデートが必要になるのではないでしょうか？組織としての考え方、担当者の考え方に大きく左右されると思いますが。。。
でも、なぜか3年を過ぎたころから、組織内で「そろそろ古くね？」という雰囲気が出てくるんですよね。「デザイン変えてからもう何年経つ？そろそろ変えてもいいんじゃない？」なんていう質問やコメントが増え始めるのもちょうどその頃です。「そんな風に、簡単に言うな〜！！！！」と心の中では叫んでいますが、ウェブマスターのサガ（運命）として受け入れることにしています。
ちょうど3年経ったころくらいから、更新作業をしていると自分でもフレームワークの古さを実感MAXになりますし。不思議です。
5年以上前に「ウェブサイトは日々の更新で壊れて行く」で書きましたが、日々更新を続けているとウェブサイトもガタが出てきます。そうならないように心がけて全体を俯瞰して更新作業をしますが、やっぱり、細かい更新が重なるとその時は気づかない不具合いが蓄積されていきます（自然の摂理です。仕方ないです。遠い目…）。
日々忙しく働いていると見直す機会もなかったりするので、リニューアルは大々的にコンテンツを見直すだけでなく断捨離の良い機会にもなります。
本来、数ヶ月に一回とか、半年に一回とかやっていきたい作業ではありますけどね。
自分が運営に携わるウェブサイトでは、独自のグリッドシステムやパターン・ライブラリを作って、ある程度必要なレイアウトパターンには対応しています。これも長年使っているとガタが出てきます。制作当時は思いつかなかった、より良いコンポーネントや作り方が出てくる場合もありますし、例えばFlexboxのように当時は使えなかった技術が使えるようになっている場合もあります。
また、当初の予測に反して使わないコンポーネントも判明するので、コンポーネントの棚卸しとUIの最適化もしておきたいところです。
本来アップデートサイクルを作って定期的にやりたいですけど、こういったメンテ作業はどうしても優先順位が下がるので、リニューアルの際にガツっとやってしまうのもありです（言い訳かなぁ。。。覚悟が足りないのかなぁ。。。）。
僕が運営に携わっているウェブサイトも、そろそろリニューアル準備の時期に入っていて、いま以下の2つのようなことで悩んでいます。リニューアルサイクルでの不毛な作業をなくすために、5年後の自分（または後任の人）のために、どうにか基盤を構築したいと思って試行錯誤中です。
この2つの課題の解決の目処を立ててからリニューアルしないと、結局、大量なHTMLの修正作業という精神的にも体力的にもよくない不毛サイクルから抜け出せる気がしません。CMSを導入してもしっかり設計ができてないと、次のリニューアルサイクルで逆に作業が増えそうです。
例えば、以下のようなBootstrapのグリッドシステム を例にとって考えてみます。
<div class="row">
<div class="col-md-8">本文</div>
<div class="col-md-4">画像</div>
</div>これを入れちゃうとレイアウトが挿入したclassに依存することになります。「4つ分のコラムサイズ」とか「8つ分のコラムサイズ」というスタイル要素をそのまま構造に書き込んじゃってますからね。構造とコンテンツがガチガチに絡み合って切ってもきれない関係になっていますよね。現実的に考えると仕方ないんですけど。
で、何がやりたいかというと、例えば以下のような要素の入ったコンテンツがあったとします。
<h1>タイトル</h1>
<img>
<img>
<p>本文 段落1</p>
<p>本文 段落2</p>
<h2>サブタイトル</h2>
<p>本文 段落3</p>
<h2>関連リンク</h2>
<ul>
<li>リンク</li>
<li>リンク</li>
<li>リンク</li>
</ul>これをHTMLを変更せずに<div class="col-md-8">のようなレイアウト構造を示すclassを入れずに、CSSだけで以下のような様々なレイアウトを構築できれば、<div>とclassで構築する「グリッドシステム」に依存せずにすみます。
検証できていませんが、たとえば、以下のようにFlexboxと:nth-childを使えば実現できるのでしょうか？
全体の構造を示す.containerのようなclassは必要になりますが、構造を示すclassを最小限に抑えたHTMLの記述ができ、コンテンツとスタイルの分離ができそうです。※以下Sassの記述です。
.container {
display: flex;
img:nth-child(2){
order: 7;
}
ul {
order: 8;
}
}
あとはコンテンツとスタイルの紐付け方とかCMSの構築の仕方が課題でしょうか？（こんなことを考えていたら、CSS Zen Garden のことを思い出しました。Dan Mallさんがデザインしてるし。）
先日、Dan Mall氏の「Content & Display Patterns 」というブログ記事を読んで「コンテンツとスタイルを完全に分離させるヒントはここにある！」と思わされました。
この2点を考慮してコンテンツ・パターンと表示パターンの設計をすれば、リニューアルのたびにHTMLを書き直さなくて済むようなウェブサイトにできそうです。
詳しい説明は今後にとっておくとして、Danさんが記事中で紹介している「Fake CMS」のようなものが導入できれば、きっと不毛なリニューアルサイクルから抜け出せるのではないかと思っています。
多分、以下あたりが今後のヒントになるんだろうなぁと考えています。また一つ一つ勉強して紐解いて実践していきたいと思います。解決策が見えてきたら、またここでシェアさせていただきます。
2016/01/22 6:54 | ウェブについての考察など
六本木ヒルズの森美術館でやっている村上隆の五百羅漢図展 に行って、彼の「創造力なき日本 」を読んで、年末から年始にかけてアートやウェブデザインについてごにょごにょと考えを巡らしています。ようやく考えがまとまりつつあるので、こちらに書き残しておこうと思います。明日のウェブ制作の、なにかの役に立てば幸いです。
結論から言ってしまうと、彼の作品や書籍からウェブデザインが学べることは、やり遂げる「覚悟」とデザインへの理解を促すための「歩み寄り」だと感じています。
作品自体の迫力やディテールのクオリティ、世界観の素晴らしさに圧倒されたのももちろんあるんですが、一番面感銘を受けたのは展示の途中にあった制作プロセスを記録したドキュメントの数々でした。
制作スケジュールやスケッチ、下絵、そして、スタッフとのコミュニケーションが赤裸々に示された指示書などが展示されていて、ここが見ていて一番ワクワクしたところでした。
アートとスケジューリングって、かけ離れたイメージを持っていました。よく考えればすぐわかることなんですが、そんなことないですよね。
「この小さな空間にキッチリドラマをブチ込め！！」
このコメント、微笑ましいというか、共感して泣けるというか、乱暴な言葉の中にも愛を感じるというか。。。感動した！
「指示書どうりにヤレ！ボケ！」って率直に書くあたり、なんか愛を感じる → へ？おかしい？
ウェブデザインのプロセスもこうあるべきなんだろうな、と。
しっかりドキュメントに残してプロセスを見える化して、社会に向けてもっと共有すべきなんだ、と。やったことを記録して、外に向けて発信する。そういった記録が残るように仕組みやワークフローを構築する。そういうことをするウェブデザイナーがもっとたくさん必要なんだ、と。
この五百羅漢図は、全長100メートル、高さ3メートルにもなる巨大な作品を短期間に200人以上のスタッフと制作したものだそうです（参照 ）。短期間に、この規模の作品を、ここまで高いクオリティで作り上げるために村上隆が築き上げた組織やシステムはウェブデザインにも通ずるものがありそうです。
ウェブの場合はスピードとクオリティのバランスが難しいですけど。それも、ある程度なら仕組みを作ることで解決できるかもしれません。今はわからないけど、なんかキノトロープってカイカイキキに似てたのかな？
長谷川恭久さんが「2016年、デザイナーが実践すること 」で「良いものを作れば理解してもらえるという考えはナイーブだ」と書いていたのに対し、Twitterで僕は以下のように反応していました。
確かに。ただ、それが理解できる社会にする、というのも「デザイン」の大きな課題なように思う
このあとも、なにか良い方法はないかずっと考えています。
そして、村上隆の「プロセス（メソッド）の構築とその公開」が、そういった課題の解決のヒントになるのではと考えています。ウェブデザインやその思考プロセスがブラックボックスだから理解されない部分も多いいわけで、そこは業界全体で社会に対してわかってもらうための「歩み寄り」とそれをやり抜く「覚悟」、また、仕組みづくりと根気強い説明が必要なのかもしれません。
ウェブデザインやその思考プロセスについて語られる場所や情報は存在すると思いますが、いまの日本の状況では、業界の人がわかれば良いといったものではなく、もっと一般向けに、社会全体に対して発信されるべきものなのかもしれません。
ちょっと話が逸れてしまうかもしれませんが、アメリカのBrat Frost氏は、制作のプロセスを制作中からネットに公開 してみたり、執筆途中の自著「Atomic Design 」をサイトにアップして執筆過程を共有したり、面白い試みを行っています。こういうことに長けたアメリカでも、人々にプロセスの公開が求められ始めている兆しなのかもしれません。「Open Source Design 」という試みにもかなり興味を惹かれます。
作ったはいいが結局は使われないドキュメント作りのためだけのドキュメントって、最終アウトプットのクオリティを上げるためにかける時間を奪ってしまうので嫌いです。でも、自分のそういった考えは、実は「甘え」から来ているのかもしれないと、五百羅漢図展を見て「創造力なき日本 」を読んで思い始めています。
そこに自分が成し得るベストのものを世に出すという覚悟が足りないから、自分はドキュメントの重要性をしっかり認識できていないのかもしれません。なぜなら、覚悟を持って自分が信じる道を進むためには、説得力あるやり方で、それを理解してもらうべく根気強くまわりへの説明責任を果たさなくてはならないからです。そのためのドキュメントなら、時間を惜しまず作るべきだし、そういったことこそ、発展したツール群を最大限に活用して効率化すべきなんでしょうね。
多くを語らず黙々といい仕事をする職人気質が好きなので（きっと、多くの日本人がそうなんだと思います）、「てやんでぇ、こちとら長年ウェブやってきてんだ。しのごの言わずにデザインさせろ！」と心の中でつぶやくだけで、コミュニケーションや説明をすることに積極的になれないのかもしれません。でも、そこは言葉でも、手描きスケッチでも、ダイアグラムでも、プロトタイプでも、なんでも手法はなんでもいいので、そのチームで使いやすいツールを使ってコミュニケーションをはかって歩み寄っていくべきなんですね。
その相手は、上司や同僚だったり、クライアントだったりすると思いますが、「この人たちと一緒に最高のものを作り出すんだ！」という覚悟を持って、途中で投げ出さずに、コミュニケーションを諦めずに進むべきなんですね。ここ2年ほど中間管理職という立場で仕事をしていますが、上に対しても、下に対しても、そういう覚悟を決めるべきなんですね。決めてたつもりなんですけど、「創造力なき日本」を読んで、認識が甘かったなと反省しています。
最後に一箇所だけ「創造力なき日本 」から引用させていただきます。
「いつか自分の作品がわかってもらえる日が来ればいい」と夢想していても、その人の目の黒いうちにその日がくることはほぼあり得ません。理解してもらうためには、ただただ歩み寄る。… いつか世間に見直してもらえるといった考えを捨てることこそが、芸術家として身を立てる第一歩、成功するための仕事術の第一歩になるのです。
— p. 33 – ヒエラルキーの最下層にいる人間の生き方
成功者である村上隆が言ってるんですから、きっと本当にそうなんでしょうね。
この心構えを持つことこそがデザイナーとして身を立てる第一歩なのかもしれません。
村上隆の五百羅漢図展 も「創造力なき日本 」も、かなりオススメです。デザイナーだけでなく、ディレクターやエンジニアの方々にも、ぜひ読んで体験してもらいたい作品です。アートとビジネスを目的とするウェブは、まったく違う業界で接点はあまりないと思っていました。でも、「創造力なき日本 」に書かれている村上隆の言葉を読むと、すごく似ているようにも思えます。
今後も村上さんの情報を漁ってみて、学ばさせていただこうと思います。
注）僕は村上隆の超にわかファンなので、彼についてそんなに詳しいわけではありません。20世紀末にボストンに住んでいた頃、彼の個展をボストン美術館で見て認知してはいましたが、その後は名前は知っているくらいの知識しかありませんでした。勘違いしているところがあったら、ご指摘いただけたら嬉しい限りです。
2016/01/17 16:17 | ウェブ制作・運営ノウハウ
このブログのWordPressテーマのバージョン管理にはgitを、ビルドツールにはCodeKit を使っています。CodeKitはSassをプロセスするのに使っているくらいですが、先日、gitでブランチを作って作業をしていたらCodeKitの設定で困ったことがありました。
まず、前提条件としてCodeKitの設定ファイルのcodekit.configはgitの管理下に置かず、masterブランチでstyle.scssに個別の設定を行っていました。そのあと、以下の作業を行ったら問題が発生してしまいました。
style.scssを/css/style.min.cssに書き出すように設定していたのに、その設定が消えてしまいました。その代りにCodeKitのプロジェクトごとのデフォルト設定が適用され/style.cssに書き出されるようになっていました。結果、テーマファイルが参照していたCSSが変更されず、ブラウザで見ても変更が反映されずに戸惑いました。
CodeKitの設定ファイル（config.codekit）をgit管理下に置いて、ブランチごとに設定を保持するよう、gitを設定しました。ちなみにそれぞれのバージョンは、gitはHomebrew版の2.6.0、CodeKitは2.6.1でした。
CodeKitは、ブランチごとに以下の設定を行いました。
/css/style.min.cssにファイルを書き出す/css/style.min.cssにファイルを書き出す（developと同じ）ブランチごとに異なるconfig.codekitファイルを保持できるように、gitに以下の設定を追加しました。
[merge "ours"]
name = "Keep ours merge"
driver = trueconfig.codekit merge=ours今回のこのgitの設定は他の状況でも応用できそうなので、覚えておいて損はなさそうです。
gitはコミットして履歴を残しておく程度にしか使っていなくて、もっと活用したいと思ってブランチを作って作業をしてみらたらすぐに問題にぶち当たってしまいました。使いこなせるまでにはいろいろ試す必要がありそうですけど、それまでは失敗しながら進むしかなさそうですね。そしたら、gitに助けられることも多くなるんでしょうね。早くそんな日が来ないかな。
2016/01/14 15:19 | レスポンシブWebデザイン
WordPress 4.4からデフォルトでsrcsetとsizesを使ったレスポンシブ・イメージが導入されたわけですが、このブログでも紹介したプラグインはどうなったのでしょうか？
プラグインのGitHub に注意点がいくつか書いてあって、以前から使っていた方には特に注意が必要なようなので、紹介しておきたいと思います。
結論から書くと：
とのことです。
より詳しく知りたい方は、以下でどうぞ。
以前からこのプラグインを使っていたなかったら、特に何もする必要はありません。WordPressを4.4に更新すると自動でレスポンシブ・イメージが適用されます。WordPress 4.4のレスポンシブ・イメージの詳細については以前の記事をご覧ください。
バージョン2.5以前からこのプラグインを使っていて、WordPress 4.4に更新する場合は、プラグインを残しておく必要があるそうです。2.5以前のバージョンではimgタグにdata-sizesとsrcset属性を挿入していて、プラグインを削除するとこの属性がデータベースに残ったままになってしまうそうです。
2015年12月の時点で、このデータをどうやって削除するかはまだ協議中 のようですが、バージョン3.2（2016/1/14現在、v3.1.1）では、これらの属性をデータベースから削除するような仕組みが導入されそうです。
プラグインを有効にすると自動でレスポンシブ・イメージのポリフィルのPicturefill（2016/1/14現在、v3.0.1）が読み込まれます。Picturefillには問題が残っているので、個人的にはいれない方が良いと思うのですが。サポートがないブラウザでもレスポンシブ・イメージが機能するようになるのは確かです。
WordPressでは画像をアップロードすると複数サイズの画像を自動的に書き出すのですが、WordPress 4.4の時点でデフォルトのままだと書き出される画像の最適化は行われません。そのため、オリジナルより面積の小さい画像なのに、ファイルサイズが大きくなってしまうこともあります。
このプラグインをインストールしてAdvanced Image Compression の機能を有効にすると画像を最適化できるそうです。ただ、この機能を使うにはサーバにImageMagick がインストールされている必要があるので、サーバ環境によっては現実的ではないかもしれません。簡単じゃないですね。
そもそも、レスポンシブ・イメージが解決する課題の一つは、不必要に大きなファイルをダウンロードさせないことです。それなのにWordPressに画像がアップロードされる際にオリジナルよりファイルサイズが大きくなってしまっては意味がありません。だったらオリジナルをそのまま読み込んだ方が。。。ということになってしまいます。
本来であれば画像最適化の機能はデフォルトで導入されるべきなんでしょうけど（開発者の方々もそう思っているはず）、サーバ環境などが関わってくると難しくなっちゃいますね。
ただ、レスポンシブ・イメージの歴史を見ていると、一歩一歩、着実に進んできているので、きっとこういった課題も解決されると信じています。ユーザにも制作者にも優しい仕組みがいち早く整ってくれることを願っています。
こちらもご参考までにどうぞ：
よかったら他のWordPress関連の記事もどうぞ
2016/01/11 22:14 | レスポンシブWebデザイン
WordPress 4.4で実装されたレスポンシブ・イメージをブラウザでテストしていた際、はまってしまって多くの時間を浪費してしまったので注意点を書き留めておきます。レスポンシブ・イメージをテストする際はお気をつけください！
Mac Chrome 47でテストをしていて、ウィンドウ幅を変えてもレスポンシブ・イメージが反映されなくて不思議に思っていたんですが、よく考えてみたら画像がキャッシュから読み込まれていました。。。
Mac Chrome 47では、srcsetに記述のある画像がキャッシュにある場合、ウィンドウ幅を変えただけではそれ以下のサイズの画像を再度読み込まないようになっています。FirefoxやSafariとは違った挙動だったので、他に原因があると思って迷走してしまいました。
ちなみに、幅の小さい画像がキャッシュにある場合は幅を広げた際に指定した画像が読み込まれます。
たとえば、以下の記述をした場合、ウィンドウ幅が781px、768px、300pxの際に画像が変わると思いますよね？
<img src="/path/to/img.png"
srcset="/path/to/img-300x187.png 300w, /path/to/img-768x478.png 768w, /path/to/img.png 781w"
sizes="(max-width: 781px) 100vw, 781px">ところが、たとえば1024pxのウィンドウ幅で一度ページを開くと、以下のGIF画像のように幅を小さくしても画像は変わりません。
逆に、小さいウィンドウ幅でページを開いてウィンドウ幅を大きくしていくと、以下のGIF画像のように幅に適したサイズの画像が順次読み込まれます。
srcsetとsizesの挙動をテストしていて、なんか挙動がおかしいなぁと思ったらRetinaディスプレイで見ていたのを忘れていました。たとえばMacBook ProのRetinaディスプレイモデルだとDevice Pixel Ratioが2.0なので、srcsetとsizesで指定した幅では画像が切り替わりません。
先ほどの記述例でMac Chrome 47だと、以下の表のように画像が表示されます。比較できるように、Device Pixel Ratioが1.0の場合に表示される画像も並べてみました。
| ウィンドウ幅 | 表示される画像 |
|---|---|
| 239px以下 | 300wに指定した画像 |
| 240〜387px | 768wに指定した画像 |
| 388px以上 | 781wに指定した画像 |
| ウィンドウ幅 | 表示される画像 |
|---|---|
| 300px以下 | 300wに指定した画像 |
| 301〜768px | 768wに指定した画像 |
| 769px以上 | 781wに指定した画像 |
Chrome DevToolで見てみると以下のようになります。
最近は解像度の高いPCも増えてきたので、Device Pixel Ratioを確認してテストを行うことをお忘れなく！
開発者ツールなどの設定を変えることで、上の2つの課題に対応できますが、各ブラウザでやり方が異なります。
開発者ツールの設定でキャッシュを無効にできます。同僚に聞いて初めて知りました。デフォルトではオフになってるんですね。
これも、開発者ツールの「device mode」で設定を変えてテストが出来ます。以下のアイコンをクリックすると、「device mode」に表示が変わります。
Device modeで以下からDevice pixel ratioを変更出来ます。
Firefoxでも開発者ツールの設定でキャッシュを無効にできます。
Chromeのdevice modeのような機能がないので、アプリを右クリックして「情報を見る」から「低解像度で開く」にチェックを入れてから起動します。Firefoxだとちょっと面倒です。
Safariでは「開発」メニューから「キャッシュを無効にする」をオンにできます。
レスポンシブ・デザイン・モードにするとDevice Pixel Ratioが変えられます。
MS Edgeでも開発者ツールの「Network（ネットワーク）」タブで「Always refresh from server（常にサーバから読み込む）」をオンにするとキャッシュを無効にできるようです。
こちらに関しては方法を見つけられませんでした。ご存知の方いたら、ぜひ教えてください！
ということで、レスポンシブ・イメージ関連でやることも増えると思いますが、無駄に大きな画像ファイルをダウンロードさせないようにできるので、ユーザにとってはメリットのある技術だと思います。ツールも充実してきてますので作業を効率化してユーザ体験を改善させられるといいですね。ページの表示速度もUXに影響を与える大きな要因の一つだと思います。しっかり対応していきたいですね。
こちらもご参考までにどうぞ：
2016/01/05 22:54 | レスポンシブWebデザイン
このブログでもレスポンシブイメージについて何度か紹介していますが（ココとかココで）、2015年の暮れにリリースされたWordPress 4.4 Clifford からsrcsetとsizesを使ったレスポンシブイメージがWordPressのCoreに実装されました。サーバにインストールして使うWordPress.org版だけでなく、WordPress.comにも実装されたとのことで、実質的には世界で2割以上のウェブサイトでレスポンシブイメージ（srcsetとsizes）が使われていることになるそうです。
このブログも先日WordPress 4.4に更新したので、WordPressのレスポンシブイメージがどんな実装なのか確認してまとめてみました。
<img>タグにsrcsetとsizesが挿入されるsrcsetとsizesは挿入されない。ページが表示される際にsrcsetとsizesがHTMLに挿入される<img>タグにsrcsetとsizesが記述されている場合は、追加も編集もされない1600pxに設定される（変更可能）768pxの画像が追加で書き出される（変更可能）<img>タグが記事内にあってもclass="wp-image-XXXXX"がないとsrcsetとsizesは挿入されない（XXXXXは画像ID）。<img>タグの出力をカスタマイズしている場合は要注意です（このブログがそうでした）上の一覧は、最後のものを除いてWordPressの以下の3ページに書かれていたことで気になったことをまとめたものです。最後のものは自分のローカル環境で確認したものです。
ローカル環境にインストールしたWordPress 4.4でテストしたら幅が781pxの画像を入れた際、以下のコードが挿入されました（画像のパスは短いものに変更しています）：
<img src="/path/to/img.png" alt="テスト" class="wp-image-5329" srcset="/path/to/img-300x187.png 300w, /path/to/img-768x478.png 768w, /path/to/img.png 781w" sizes="(max-width: 781px) 100vw, 781px">sizes属性はデフォルトで以下が挿入される：
sizes="(max-width: {{image-width}}) 100vw, {{image-width}}"この記述だと、オリジナル画像の幅以下ではViewport幅の100%に合わせて、それ以外では、オリジナル画像の幅の画像が表示される。。。はずなんですが。。。
デフォルトのままで各種ブラウザで検証してみているのですが、Win7のChrome 47で2つ画像が読み込まれてしまったり（※）、他のブラウザでもウィンドウ幅が300px以下で768pxの画像が読み込まれたりするので、各ブラウザでのsrcsetとsizesの挙動を検証してみる必要がありそうです。
※同様の記述で同じ現象が起こることを@SaekiTominagaさん が再現してくれました。Chromeのバグでしょうか？
ちなみに、sizesに違う記述をしたい場合はテーマでカスタマイズができるように新しく関数が用意されたようです。
なにもしないと自動でsrcsetとsizesが挿入されてしまうわけですが、サポートされていないブラウザではこれらの属性が無視されるので、問題にはならないはずです。ちなみに、srcsetとsizes属性は以下のブラウザでサポートされています。
※IEではどのバージョンもサポートされていません。
レスポンシブイメージはマルチデバイス時代の長年の課題なので、今回のWordPressのCoreへのレスポンシブイメージの実装は英断だったなぁと感服しています。srcsetとsizesはIEで全滅だったりAndroidの古いブラウザでサポートされていないですが、Can I Use のデータを見ると約63%のユーザが使うブラウザでサポートされています。これで多くのサイトで表示パフォーマンスの改善になるでしょうし、ユーザ体験の改善にもつながると思います。
まだ、プラグインの挙動の確認とか各ブラウザでのsrcsetとsizesの細かい挙動の確認は必要ですが、とりあえず嬉しいニュースでした。
こちらもご参考までにどうぞ：
よかったら他のWordPress関連の記事もどうぞ
2016/01/03 17:48 | 制作・効率化ツール
Affinity Designerを初めて使った時に戸惑ったことをまとめてみました。最初の戸惑いをクリアすれば、すごく使いやすくサクサク動くオススメのアプリです。無料試用版 もあるので、ぜひ、お試しください。
2022年11月9日にAffinity Designerのバージョン2が公開されました。この記事の内容はバージョン1の情報です。バージョン2では大幅なUIの刷新（レイヤーパネル周りも結構変わりました！）が行われており、バージョン1とは画面の見た目や機能自体が違うものもありますのでご注意ください。
2016年1月の記事の初期公開当時はバージョンが1.4.1でしたが、2022年11月9日にバージョン2がリリースされるまではバージョンが1.10.5でした。この記事の内容は1.10.5で確認したものです。バージョンによって機能が変更されていることもあり、記事の内容とは異なる場合がありますがその辺はご容赦ください。バージョン2では大幅なUIの刷新が行われており、画面の見た目や機能自体が変更されているものもあると思いますのでご注意ください。
初心者向けにAffinity Designerの使い方を記事にまとめています。よかったらこちらもどうぞ。
Affinity Designerがおすすめな理由をざっくりまとめてみます。
Apple Design Award 2015にも選ばれたAffinity Designer ですが、紹介ビデオがあまりにもかっこ良かったので割引キャンペーン中に衝動買いしちゃいました（2016年1月の記事執筆当時）。
アニメーションと音楽のシンクロ、かっこ良すぎでしょw
2015年の半ばに買っておいたものの、あまり触る機会がなく2015年の年末に年賀状をデザインするために使ってみたら、かなり良くてびっくりしました。2015年くらいから話題になってたんですね。
Affinity Designerを使ってみて、はじめに戸惑ったことがいくつかあったので、これからAffinity Designerを始めよう！という方がスムーズに使い始められるようにその辺を書き留めておきます。
以下、2022年4月にMac版のAffinity Designer 1.10.5で操作を確認しました。MacはmacOS Monterey 12.3.1です。2016年1月の記事執筆当時は1.4.1でしたが基本的な内容は変わっていませんでした。
その他のことは、クセはあるものの結構直感的に操作ができて一度やってみればすぐに慣れると思います。最初はわかりにくいものでも、使ってみると「おぉ、なるほどね」と思えるものが多い気がします。IllustratorやSketchよりも直感的に操作できると感じる点が多い気がしています。
では、Enjoy Affinity Designer!
デフォルトでは以下のようにツール類が全て1つのウィンドウにまとまった状態ですが、これはメニューから簡単に切り離せます。
切り離すとこんな感じになります：
ちなみにレイヤー、カラー、変換などのパネル類は「スタジオ」と呼ばれていて、これらのパネルの表示・非表示は以下のメニューから変更可能です。
以下のメニューで、デフォルトに戻すこともできます：
パネルの移動やアレンジは「||」マークをドラッグしたりタブをドラッグして移動するとできます。
Affinity Designerでは、レイヤーパネルで以下の3つの操作ができます（僕が知る限り）。
上の状態で歯車のレイヤーをドラッグするとドロップダーゲット（青い線）が表示されるので、以下のようにドロップダーゲットの表示場所の種類で異なる操作を選べます。
サムネイルを含むレイヤー全体にドロップターゲットが表示される状態で移動すると、レイヤーの上下が変更できます。
サムネイルにレイヤーをドラッグしてサムネイルの右にドロップターゲットが表示される状態で移動すると、移動するレイヤーでターゲットのレイヤーをマスクできます。
サムネイルを含まないレイヤー名のみにドロップターゲットが表示される状態で移動すると、移動するレイヤーをターゲットのレイヤーでクリップできます。
これらの操作は、以下のチュートリアルビデオでも操作方法が見られます。
Advertisement
Affinity Designerを使い始めたときPhotoshopやIllustratorのようにカラーピッカーがないなぁと思って戸惑いました。
例えば、以下のようにオブジェクトを選択した状態でカラーパネルのスポイトアイコンをクリックすると、スポイト部分で選択されている色に変わってしまいます。
このスポイト部分の色を変更するには、スポイトをドラッグすると以下のように虫眼鏡のカラーピッカーが表示されて画面上から色を拾うことができます。
また、ツールから「色選択ツール」を選んで色を拾うと同じことができます。
「ペルソナ」という言葉のせいかイメージがわきにくいですが、Affinity Designerには3つの「ペルソナ」という操作モード（ワークスペース）があります。
このデザイナーペルソナとピクセルペルソナを組み合わせて使うことで、ベクターで書いたオブジェクトの内側にピクセルペルソナでテクスチャを乗せるといったことが簡単にできるようになっています。
たとえば、以下の竜のイラストでは形をベクターで描いて、その中にピクセルペルソナのブラシツールを使ってテクスチャを入れています。
レイヤーの一覧で「（カーブ）」となっているのがベクターのシェイプで「（ピクセル）」となっているのが、ピクセルペルソナのブラシツールで描いたテクスチャの部分です。
Adobe Illustratorの操作に慣れていると、テキストツールで入力を確定するときにCommand + Returnを使っちゃいますよね？
でも、これってAffinity Designerでは文字がアウトライン化される「カーブに変換」のショートカットなんですね。僕もAffinity Designerを使い始めたころは手癖で何度もテキストをアウトライン化してしまって困りました。
Affinity Designerではescキーでテキスト入力が確定できます。
僕は慣れちゃいましたが、どうしてもこのショートカットが嫌な場合は変更ができます。
環境設定の「キーボードショートカット」パネルの2つ目のドロップダウンで「レイヤー」を選ぶと「カーブに変換」があります。このショートカットをCommand + Shift + Oとかにしおくと、イラレっぽく使えますね。
Adobe Illustratorでは選択ツールで選択マーキーがオブジェクトに触っているだけで選択できますが、Affinity Designerではデフォルトでは選択マーキーでオブジェクトを全て囲わないと選択できないようになっています。
これは環境設定の「ツール」パネルで「選択マーキーと交差するオブジェクトを選択する」にチェックを入れると変更できます。
三角形ツールだと正三角形は描けないので、ポリゴンツールを使ってshiftキーを押しながら描画して辺の数を3つにすると描けます。
使い始めるにあたって知っておくと良さそうなリソースです。
Affinity Designer、Affinity Photo、Affinity Publisherのヘルプ・ドキュメントをオンラインで見られます。日本語も英語もあるので便利です。キーボードショートカット一覧などもありますよ。
解説は英語ですが、日本語字幕がついています。一度チュートリアルビデオを見て操作を覚えてしまうと、かなり快適にツールを使えるようになれのでオススメです。1つ1つの動画はそんなに長くないです。
どんな機能があるのかなぁと、眺めているだけでも楽しいです（マニアックw）。ここを見ていると新しい機能やツールを発見できたりします。
PDF版のキーボードショートカット一覧です。テキストでの一覧よりわかりやすいので一応載せておきます。
ちなみに、このキーボードショートカット一覧は以下の記事で紹介されてました。
たくさん便利機能があるんですけど、とりあえず2つだけご紹介。
たとえば、三角形の角を丸くするのに便利です。複数のノードを選択して、一気に丸くすることもできます。使い方は以下のチュートリアルビデオでわかりやすく説明されています。
トラックパッドのピンチ操作でズームイン・ズームアウトが、二本指でのスワイプ操作でパンができるのが便利です。これ、Sketchでもできるんですけどね。。。
Affinity Designerは使えば使うほど良さを実感できるツールですね。
日本語メニューにも対応したし、Apple Design Awardをとったことで一層話題になってユーザベースも増えたでしょうし、2016年は昨年にも増して注目のツールになりそうです。Affinityツールを作っているSerifは、ユーザの声を聞いて改善するカルチャーがありそうなので今後のさらなるアプリの改善にも期待できそうです。楽しみですね。
初心者向けにAffinity Designerの使い方を記事にまとめています。よかったらこちらもどうぞ。
2015/12/28 21:45 | ウェブについての考察など
あと数日で2015年も終わってしまいますね。
僕の2015年は仕事でもプライベートでも頭の中でいろいろ試行錯誤して過ごしていたら、ひゅ〜っと過ぎてしまったという印象です。なんだかんだ必死で過ごしていたのか、頭の中がCHAOSだったのか。2015年は慌ただしく過ぎていった印象が強いので、このブログだけでもこの1年を振り返っておきたいと思います。
2015年に投稿した記事の数は28件でした。
カテゴリ別に数えてみると、制作・効率化ツールの記事が16件と圧倒的に多かったです。
レスポンシブWebデザインに関連する記事を多く書いていた時は、より多くの人にRWDの手法を知ってもらいたいという思いもあり、せっかく書くならより多くの人に読んでもらいたい（ようするにバズらせたい）という意識が強く、ブログを書くことが息苦しく感じるようになった時期もありました。
そこで、2015年はアクセスとか内容にあまりこだわらずに、好きなことを好きなように書いて、それが誰かの役に立ったら嬉しいというスタンスでやってみました。
2014年は15件しか記事を書いていないことを思うと、頭の中の壁を壊してマインドを「解放」したつもりだったんですが。書いた記事を振り返ってみると、まだまだ「自由度」に欠けている印象です。
2016年は、ガジェット・ツール系ばかりじゃなくて、もっと自由気ままに、ウェブに関連する「こと」や「考え」について書いていきたいと思います。そろそろレスポンシブWebデザインについても見直して書きたいと考えているんですけど、なかなか筆が進まない。。。汗
さて、2015年1月1日から12月28日まででGoogle Analyticsの統計で閲覧数の多かった記事をランキングにしてみます。残念ながら、2015年の記事が少ないですね。トップが2015年に書いたページ表示速度についての記事なのが嬉しいですけど、来年はもっと頑張らなくちゃ。。。
ということで、2015年もありがとうございました！
2016年はもっと自由に、世界のどこかでこのブログを読んでくれている方の、少しでも役に立てる記事が書けるよう精進しようと思います。それが、たとえ1人だったとしても。
紅白見ながらまた記事を書くかもしれませんが、とりあえず、皆様、よいお年を！！
2015/12/28 20:20 | 制作・効率化ツール
Atomのデフォルト設定では、Tree Viewでファイルをクリックすると新しいタブでファイルが開いてしまいます。これだと、Sublime Textの時みたいに、ちょっとファイルの中身を見たいだけなのに、ファイルをクリックしただけで新しいタブが増えてしまって不便です。個人的にはSublime Textのようにシングル・クリックでファイルのプレビュー、ダブル・クリックでファイルを開くほうが好みです。
Atomでも設定を変えられますが、方法がわかりづらかったのでメモっておきます。
⌘ - ,で設定画面を開いて「Packages」を開きます。ここからインストールされているパッケージが検索できるので、画像のように「tabs」で検索します。
「Core Packages」の下に「Tabs」が出てくるので「Settings」を開きます。
下の画像のように「Use Preview Tabs」にチェックを入れます。以上です！
ちなみに、余談になりますが、コミュニティーパッケージだったものがコアパッケージに取り込まれたそうです。
2015/12/09 18:10 | ウェブ制作・運営ノウハウ
この記事は「SVG Advent Calendar 2015 」の9日目の記事です。初めてAdvent Calendar的なものに参加させてもらいます。よろしくお願いします。
※Advent Calendarの締め切りがあるので、検証途中ですが公開しちゃいます！ご了承ください。現段階では、旧ブラウザをサポートするためのフォールバックが最後まで検証できていないです。あとで追記します。
—–ここから本文—–
そろそろロゴとかアイコンまわりの画像をSVGに移行したいと思い、Gulpを使って複数のSVGアイコンを1つにまとめるアイコンシステムを検証してこのブログでも紹介しました。でも、Gulpの設定に慣れていないと難しいし、CSSで背景画像として読み込めないというデメリットもありました。
そこで、今回はロゴやアイコンなどの複数の画像を、Sketchでスプライトにまとめて1つのSVG画像として保存して、CSSの背景とインラインHTMLの両方で使う方法を検証してみます。この方法だとGulpなどのビルドツールがいらないので、コマンドラインツールが使えない制作環境でもワークフローにそのまま組み込めます。また、ロゴやアイコンが一つのファイルにまとまっているのでメンテが楽になりそうです（納品後に自分で更新したいクライアントにも良いかも）。
矢印など、テキストの補完に使う画像はCSSの背景画像で、ロゴやアイコンなどビジュアルのみでなくコンテンツとして扱うものはインラインで画像として記述するのがセマンティックで理想的です。フォールバックを含め、そう言った対応ができるのか検証していきます。
結論から先に書いてしまうと、Microsoft Edge以外は、フォールバック対応を施すことでなんとか対応できそうです。これだったら、もう少し検証すれば、プロダクション・レベルでも使えるように思います。
今回はSketchを使ってSVGスプライトを作成します。インラインHTMLとして使う際に画像をIDで参照するために、レイヤーに名前をつけて、複数の図形からなるものはグルーピングしておきます。
ここではPNG画像を表示させてます。実際のSVGはこちら 。あと、参考までにSketchファイルはこちら からどうぞ。
Sketchのレイヤー構造は以下のようになってます。
上の画像をSVGとして書き出すと、以下のような構造で書き出されます。
※構造に関係ない部分は省略してあります。
<svg width="400px" height="300px" viewBox="0 0 400 300">
<g>
<g id="sprites">
<rect id="orange" fill="#F6A623" x="170" y="10" width="60" height="60"></rect>
<rect id="red" fill="#D0011B" x="90" y="10" width="60" height="60"></rect>
<rect id="brown" fill="#8B572A" x="10" y="10" width="60" height="60"></rect>
<g id="logo" transform="translate(10.000000, 89.000000)">
<!-- 図形部分 -->
</g>
<g id="icon-plus" transform="translate(10.000000, 190.000000)">
<!-- 図形部分 -->
</g>
<g id="icon-minus" transform="translate(59.000000, 190.000000)">
<!-- 図形部分 -->
</g>
<rect id="bound" stroke="#979797" stroke-width="2" x="1" y="1" width="398" height="298" rx="10"></rect>
</g>
</g>
</svg>SVGスプライトのGulpワークフローの時は、<symbol>を使ったSVGを書き出しましたが、今回のスプライトでは<g>を使っています。g要素は論理的に図形をグルーピングして描画対象としてそのまま表示されるのに対し、symbol要素は図形をグルーピングするところまでは一緒ですが、そのままでは描画対象にはならず、<use>を使って参照しないと表示されません。
基本的にはCSSスプライトの画像をSVGにするだけです。たとえば、スプライトのX座標が58、Y座標が189にある（-）アイコンを表示するには以下のように記述します。
<span class="css-icon icon-minus"></span>.css-icon {
display: inline-block;
background: url(svg/sprites.svg) no-repeat;
background-size: 400px 300px;
}
.icon-minus {
width: 31px;
height: 31px;
background-position: -58px -189px;
}同じSVGスプライト画像をインラインHTMLで参照するには以下のようにHTMLを記述します。
<svg width="60" height="60">
<use xlink:href="svg/sprites.svg#brown" x="-10" y="-10" />
</svg>上のようにsvgに幅と高さを指定して、useでX座標とY座標を調整しても良いですし、以下のように、svgにviewBoxを指定する方法もあります。
<svg width="320" height="80" viewBox="10 90 320 80">
<use xlink:href="svg/sprites.svg#logo" />
</svg>これで、モダンブラウザであれば、とりあえず1つのSVGプライト画像をCSSの背景画像とインラインHTMLで読み込むことができました。
ある意味ここからが本題ですが、以下でブラウザサポートについて検証していきます。
例えばロゴのような画像の場合、さすがに表示なしというわけにもいかないので、SVGがサポートされていないブラウザ向けにフォールバックの対応が必要です。ただ、フォールバックのための作業を極力シンプルにするために、スプライト画像をPNGで保存して全てのフォールバックに使えたら理想的なので、それを目標に検証していきます。
まず、caniuse.com でチェックするとサポート状況は以下のようになっています。
他の2つはまだしも、ここのサポートが難しいですね。Android Browser 4.xでもサポートされてないのがちょっと。。。
Advertisement
以下の対応が必要になります。
例によって、CSS-TricksのA Complete Guide to SVG Fallbacks という記事で、様々なフォールバックの方法が詳細にわたって解説されていますので、より詳しく知りたい方はそちらをご覧ください。
以下、今回のSVGスプライト用に必要なフォールバックをまとめてみます。
CSSを以下のように修正することで、サポートされていないブラウザではPNG画像を読み込ませることができます。
.css-icon {
display: inline-block;
background: url(svg/sprites.svg) no-repeat;
background-size: 400px 300px;
}.css-icon {
display: inline-block;
background: url(svg/sprites.png) no-repeat;
background: url(svg/sprites.svg) no-repeat, linear-gradient(transparent, transparent);
background-size: 400px 300px;
}Modernizer でInline SVGのサポートをチェックして、フォールバックとしてsvg要素の背景画像としてPNG画像を読み込ませます。CSSの背景画像のフォールバックで使ったPNG画像をそのまま使えるようにします。
Modernizerを使うと、Inline SVGをサポートしないブラウザでbodyタグにno-inlinesvgを挿入してくれます。それを利用して、CSSにno-inlinesvg用のスタイルを追加してHTMLにもIDを記述します。
svg要素にclassを追加します。
<svg class="in-svg in-svg-brown" width="60" height="60">
<use xlink:href="svg/sprites.svg#brown" x="-10" y="-10" />
</svg>IE8でsvgを表示させるためにhead内に、以下を記述します。
<!--[if lte IE 8]>
<script>document.createElement("svg");</script>
<![endif]-->CSSの背景画像としてSVGを使うために記述したCSSをそのまま活用して、フォールバック用に同じスタイルを適用するためにCSSにclassを追加します。
.css-icon,
.no-inlinesvg .in-svg {
display: inline-block;
background: url(svg/sprites.png) no-repeat;
background: url(svg/sprites.svg) no-repeat, linear-gradient(transparent, transparent);
background-size: 400px 300px;
}
.icon-minus,
.no-inlinesvg .in-svg-icon-minus {
width: 31px;
height: 31px;
background-position: -58px -189px;
}これでSVGのインラインHTMLでの使用をサポートしていないIE8以下でもフォールバックのPNG画像が表示されるようになります。仮想マシンですけど、Microsoft Edge Dev でダウンロードしたVirtualBox向けのIE8 on Win7と通常ライセンスのWindows XP ProfessionalのIE6で確認できました。
これで昨晩はIE8でも表示されたのを確認できたと思ったのですが、もう一度やってみたら表示されません。。。
と、ここまでで時間切れです。。。すみません、ここまでしか検証できていません。
せっかくAdvent Calendarに参加させていただいてるので、ここまでで公開させて持って、続きは、必ず後追いで検証して、追記したいと思います。あと少しのところまで来ていると思うのですが。。。
では、To be continued…
ちょっとややこしいですけど、IE9+ではインラインHTMLでuse要素を使って外部SVGファイルを読み込んで#hogehogeというfragment identifierを使って画像を表示させる方法をサポートしていません。そのため、SVG Icon Sprite Polyfill というポリフィルを使ってフォールバックします。
このポリフィルでは、use要素を使って参照している外部SVGファイルのコンテンツをXMLHttpRequestを使ってドキュメントに挿入しています。
Githubでは「JSファイルを設置するだけ」と書いてあるのですが、それだとSVGがページ上部に表示されてしまいます。このポリフィルではXMLHttpRequestでSVGをドキュメントに挿入する際にsvg-poly-targetというIDを付与するので、以下のCSSを追加して対応しました。
#svg-poly-target { display: none; }JSファイルは、bodyの最後で読み込ませるようにしました。
<script src="js/svg-icon-polyfill.min.js"></script>これで、仮想マシンのIE9とIE11で画像が表示されるのが確認できました。
これで、モダンなIE以外のブラウザではSVGでスプライトを表示、また、サポートがないブラウザではPNG画像を表示するように対応ができたはずです。あとは、Microsoft Edgeのみになります。最新のMicrosoft Edgeでは外部ファイルの読み込みをサポートするようになったようなのですが、Microsoft Edge Dev からダウンロードしてきたVirtualBox用のMSEdge on Win10では確認できていません。
以下のブラウザで動作を確認できました。
こちらもご参考までにどうぞ：
2015/12/05 7:13 | 制作・効率化ツール
Bohemian Codingの方々がMac App Store（MAS）に嫌気が差したらしく、SketchのMASでの販売を辞めるそうです。すでにMASで購入しているユーザは無償でダウンロード版に移行できるとのことで、早速試してみたんですが、一筋縄には行かなかったのでメモっておきます。
4つほど、気をつけたほうがよい点があります。
ダウンロードフォルダとか）から起動するSketch Blog に書いてあることと、失敗したやり方をまとめると以下のようになります。
Make sure you’ve run the latest version of Sketch on the Mac App Store at least once. Then simply download the a new copy of Sketch here and we will issue you a license for Sketch absolutely free of charge. Just follow the steps in-app to complete the transfer. We will also migrate your presets and templates across, so you won’t lose any data in the process.
上の文を意訳して箇条書きにしてみるとこんな感じです。
この手順でやれば、設定も移行されているのでしょうか？
僕は失敗してしまったので、プラグインやArtboardのカスタム設定が消えてしまいました。
あと、App Store版をアプリケーションフォルダから消しても良いのか、また、ダウンロード版を移動しても良いのかは不明です。
[追記： 2015/12/8]
@littlebusters さんから、移行できなかった各種設定の移行方法を教えていただきました。以下の記事で詳しいやり方が説明されています。僕の場合、アプリケーションフォルダのSketchを上書きした際、残ったファイルが悪さをしているのかと思いAppCleanerでファイルを綺麗に削除してしまったので、残念ながら設定は復活させられませんでした。涙
以下、失敗した手順です。同じ失敗をしないようにお気をつけください。
アプリケーションフォルダのSketch.appをダウロード版で上書きダウンロードフォルダから起動アプリケーションフォルダから削除アプリケーションフォルダに移動といった具合でした。。。
失敗すると面倒なので、気をつけて移行してくださいね。
以上、SketchのApp Store版からの移行失敗のご報告を終了いたします。
2015/11/29 21:58 | 制作・効率化ツール
Atomいい感じですね。
2、3日使ってみた感じ、Sublime Textから移行しちゃっても良さそうな感じです。オープンソースで無料だし、Packageやテーマ管理とか基本設定にもGUIがあっていいですね。UIやUXの大切さを実感させられます。
いまのところSublime Textからの移行もストレスフリーで、まさに「今すぐSublime Textを消してAtomをダウンロードすべき5つの理由 — MEMOPATCH 」で書かれている通りな感じですね。まぁ、別にSublime消すことはないですけどね。笑
Atom 1.xで安定して、以前あった日本語改行などの問題もなくなり、Core Packageに必要最低限のものが入っているので、何もいじらなくてもそこそこ使えるようになっている印象です。
ただ、アイコンフェチの僕としては、どうしてもデフォルトのアイコンの色が気に入りません。デフォルトのアイコンはDockに置いておくと色のせいか視認性が悪いんですよね。
僕だけでしょうか。。。？
そこで、背景色をちょっと濃いめのチョコ色にして、ついでに原子の核の部分をAtomのCIカラーっぽいミントグリーンにして玉に見えるようにシャドウをつけたものにアレンジしてみました。
Sublime Textへのオマージュ的に核の色をオレンジにしたものも作ってみたんですけど、最終的にはミントグリーンの方に落ち着きました。
もし気に入っていただけたなら、.icnsファイルは以下からどうぞ。
注）El Capitanでは変更できたんですが、Marvericksではなぜか変更できませんでした。原因究明したらこちらに記載したいと思います。
Macのアイコンなんて作ったことなかったんですけど、検索してもSublime Textの時のようにめぼしいアイコンがみつからなかったので、仕方なく自分で作ることにしました。Sketchに「Generate ICNS 」と言うプラグインを入れたら簡単に作れました。
以上です。実際にアイコンをデザインする部分以外は簡単ですね。
※このSketch Toolboxのアイコンもまぁまぁなんですよねぇ。笑。このアイコン が良い感じです。
Sketchがない場合は、指定のサイズで複数のPNG画像を作ってhoge.iconsetと言うフォルダに入れて、iconutilというコマンドラインツールでhoge.icnsファイルを作ることも可能です。詳しい作り方は「Macアプリのアイコン作成方法 — iconDrop 」が参考になります。
Sketchのプラグインを使った方が楽ですけど、各サイズでデザインの調整をする場合などは、iconutilを使った方が良いですね。
以上、そろそろアイコン関連の記事も終わりにしようかなぁ、とw
2015/11/25 6:08 | 制作・効率化ツール
El CapitanにしてTotalFinderやXtra Finderが使えなくなり、Path Finder 7 に移行してほぼ満足しているわけですが、以前「Path Finder 7で残念なところ」でも書いた通り、やっぱり以下あたりがどうしても納得いきません：
アイコンは前回の記事の要領で変更できますが、DockのFinderアイコンについては良い方法が見つかりませんでした。ただ、Path Finder 7で手を付けずにいた設定が一つあって、仕方なく試してみたら一応成功したので手順をメモっておきます。
FinderアイコンをDockから削除できるけど、Macを再起動すると戻ってくるというナイスな方法ですw
以上です。
これでDockからFinderアイコンを隠すことができます。
「え？削除しちゃって大丈夫？」と思われた方、ご安心ください。
ターミナルから以下のコマンドでDockを再起動すると戻ってきます。
% killall Dockまた、Macを再起動してもFinderアイコンは戻ってきます。
あとは以下の設定をすれば、デフォルトのFinderを使うような感覚でPath Finder 7を使えます。これでようやくTotal FinderやXtraFinderに遜色ない感じになったかな、と。かなり面倒ですけど背に腹はかえられないたいうことでw
Finderアイコンを削除する際にシステム環境設定のDock設定画面の「起動済みのアプリケーションにインジケータを表示」にチェックが入っていると、下のキャプチャのようにDockに点だけが残ってしまいます。
な、なにこれ？！
これは、一度この設定のチェックを外した状態でFinderを「Dockから削除」すると消えます。その後、再度この設定にチェックを入れても点は消えたままになります。
Macを再起動するたびにこれをするのは面倒ですけど。。。最近はスリープ状態にしておくことが多いので、よしとします。
他のアプリから「Finderで表示」を選んだ際にPath Finderを表示させるように、環境設定から「デフォルトのファイルブラウザにする」にチェックを入れます。
前回の記事に書いた手順で、Path Finder 7のアイコンをYosemiteのFinderアイコンに変えました。アイコンはこちら からダウンロードしたものを使わせてもらいました。El Capitanバージョンとされるものもあるんですけど、本物とはちょっと色が違くてYosemiteバージョンのほうが好みだったので、そちらを使いました。本当はEl Capitanの最終版がスッキリしていて一番好きなんですが。。。
このEl Capitanのアイコン、左の顔が青過ぎるんですよ…そして、Yosemiteの方はシャドーが強くて鼻立ちが微妙なんですよね〜。笑
変なこだわりですが、頻繁に使うツールなので好みの見た目で使いたいんですよね。たぶん、この記事にたどり着いて、ここまで読まれた方にはわかってもらえますよね？
ね？
Have a nice Mac life!
2015/11/23 18:39 | 制作・効率化ツール
TotalFinderの代替として使っているPath Finder 7のアイコンがどうしても好きになれなくて変えようと思ったんですが、YosemiteやMarvericksで使えた方法がEl Capitanでは通用しなくなっていました。El Capitanで新しく導入されたSIP（System Integrity Protection） が関係していて、アイコンを変更するには一度これをオフにする必要があるみたいです。
システム設定の変更を行いますので、気をつけてやってくださいね。
⌘-Rを押しながら起動（または再起動）するcsrutil disableと入力してSIPをオフにするrebootを入力でも可）Macが起動したらターミナルを立ち上げてcsrutil statusと入力すると、以下のようにSIPのステータスが「enabled (Custom Configuration)」になっていて、オフになっていることが確認できます。
% csrutil status
System Integrity Protection status: enabled (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.SIPをオフにできたら、いつもの要領でアプリのアイコンを変更します。
⌘-Iでも可）オフにしたSIPを元に戻します。
⌘-Rを押しながら起動／再起動するcsrutil enableと入力してSIPをオンにするターミナルを立ち上げてcsrutil statusと入力すると、以下のようにSIPがオンになっていることが確認できます。
% csrutil status
System Integrity Protection status: enabled.アイコンを変更するためだけに2回もシステムを再起動するのは面倒ですが、ほぼ毎日使うツールなので好きなように設定してあった方が僕は幸せです。変なこだわりだというのは重々承知してるんですけどね。笑
2015/11/15 18:50 | ウェブ制作・運営ノウハウ
SVGスプライトって、なんか複雑なイメージがありませんか？
僕はそうでした。なんか、面倒くさそう。。。どこから始めて良いかわからない。。。といった感じでずっと手をつけられずにいました。
でも、今回やってみて思ったんですが、一度ワークフローを確立してしまえばアイコン管理がかなり便利になります。CSSスプライトの時よりも管理が楽になりますし、表示サイズや今後の高解像度対応を気にしなくて良くなるのも嬉しいですね。
SVGスプライトについての英語のリソースはあるのですが、説明が多く、とっつきにくいものも多い印象なので、ここではできるだけシンプルに必要なことだけをまとめてみたいと思います。
では、SVGスプライト・アイコンシステムのGulpを使ったワークフローの構築、始めましょう！
このワークフローで作ったSVGアイコンを使ったデモページはこちら から。
SVGスプライトのアイコンシステムの構築にはいくつか方法がある ようですが、ここでは個人的に一番シンプルで簡単だと思った方法をご紹介します。symbolタグを使って複数アイコンを1つのSVGファイルに記述し、svgのuseタグから参照する方法です。
まずは、以下のように複数のアイコンが入ったSVGファイルを作ります。ポイントは<symbol>要素にidとviewBoxが指定されているところです。
idはuseでアイコンを参照する際に使います。viewBoxでは、それぞれのアイコンのサイズを指定します。アイコンのサイズは全て同じである必要はありません。
<svg xmlns="http://www.w3.org/2000/svg" class="hide">
<symbol id="hogehoge" viewBox="0 0 32 32">
<!-- 1つのアイコンのpathやshapeなどのSVG要素 -->
</symbol>
<symbol id="gehogeho" viewBox="0 0 32 32">
<!-- 1つのアイコンのpathやshapeなどのSVG要素 -->
</symbol>
</svg>
注： ページ上でのアイコンの表示サイズはCSSで指定するので、viewBoxではsymbol内のどの部分を表示するかを指定します。
SVGファイルをsvg/icons.svgとして保存した場合、HTMLでは以下のようにアイコンを呼び出します。symbolタグに#hogehogeのIDを持つ1つ目のアイコンを読み込むには、以下のように記述します。
<svg>
<use xlink:href="svg/icons.svg#hogehoge" />
</svg>これだけです。
ブラウザサポートを考えると面倒ですけど、基本的な仕組みはシンプルですね。
XLinkとSVGのfragment identifierという仕組みを利用した方法なのですが、IEとEdgeを抜かしたSVGをサポートするモダンブラウザでサポートされているとのことです。とりあえず以下で動作確認できました：
IEはsvg4everybody というポリフィルを使ってフォールバックの実装が可能です。以下の仮想マシンでsvg4everybodyの動作確認ができました。
Edge Dev のMSEdge on Win10 (Edge 20.10240.6384.0)で確認したところ、表示されませんでした。Edgeではuseを使った外部ファイルの読み込みがサポートされていないようなのですが、11月にリリースされたBuild 10586のEdgeHTML 13で機能が実装された とのことです。
さて、ここからはSVGスプライトを作る方法をまとめていきます。用意するのは以下の2つです。
今回の検証のために作ったデモ・ファイルは全てgithub にアップしてありますので、良かったらご参照ください。
複数のアイコンを個別にSVGフォーマットで保存します。 svg/icons/など、決まったフォルダに保存しておきます。
Gulpの方が設定ファイルなどの記述がシンプルで楽なのでGulpでやってます。以下のプラグインを使います。
各プラグインの読み込みを簡素化するためのプラグイン。なくても良いですけど、あるとgulpfile.jsの記述が便利です。
複数のSVGアイコンを1つのSVGファイルにまとめてくれるプラグイン。
SVGOでSVGファイルの最適化をするプラグイン。今回のデモでも、これを使ったら3KBくらい節約できました。
SVGをPNGに変換してくれるプラグイン。フォールバック用のPNG画像を作るために使います。
画像最適化プラグイン。自動変換したPNG画像の最適化に使います。
HTMLとXMLの書き換えプラグイン。SVGに記述されているfillを削除したり、HTMLにインラインで<svg>を記述した場合に非表示にするためのクラスを追加します。
※ SVGでfillが指定されていると、CSSで色指定が出来なくなるので削除しておきます。fillが指定されていないとアイコンはデフォルトでは黒で表示されます。
ファイル名を変更するプラグイン。フォールバック用のPNG画像ファイルの名称変更に使います。
導入ステップをまとめると以下のようになります。
SVGアイコンをsvg/icons/に保存します。gulp-svgstoreを使って、このフォルダに入れた複数のアイコンをsvg/icons.svgにまとめます。
gulpと一覧にしたプラグインを全てインストールします。github にpackage.jsonファイルをアップしてあるので良かったらご利用ください。
svgstoreを使って複数のSVGアイコンを1つのファイルに統合する設定を行う「svg」というタスクとフォールバック用のPNG画像を作成する「svg2png」というタスクの2つに分けてgulpfile.jsを設定します。
最終的なgulpfile.jsはgithub にアップしてありますので、そちらをご参照ください。
まずはじめに、gulpとgulp-load-pluginsを読み込みます。gulp-load-pluginsでpackage.jsonにあるプラグインをここで読み込まなくても$.svgstoreなどと書いてで呼び出せるようにしています。
var gulp = require('gulp');
var $ = require('gulp-load-plugins')();svg/icons/にあるSVGファイルを、まずはgulp-svgminで最適化して、gulp-svgstoreで1つのファイルに統合。統合したファイルをgulp-cheerioを使って編集しています。
gulp.task('svg', function () {
gulp.src('svg/icons/*.svg')
.pipe($.svgmin())
.pipe($.svgstore({ inlineSvg: true }))
.pipe($.cheerio({
run: function ($, file) {
$('svg').addClass('hide');
$('[fill]').removeAttr('fill');
},
parserOptions: { xmlMode: true }
}))
.pipe(gulp.dest('svg'));
});gulp-cheerioの説明の所でも書きましたが、SVGでfillが指定されていると、CSSで色指定が出来なくなるので削除します。fillが指定されていないとアイコンはデフォルトでは黒で表示されます。また、HTMLにインラインでSVGを読み込んで使用する場合にSVGスプライトが表示されないように<svg>にhideというclassを追加しています。
svg/icons/にあるSVGファイルをPNGに変換。svg4everbodyのデフォルトの動作に合わせてgulp-renameを使ってファイル名を変更します。その後、作成したPNGファイルをgulp-imageminを使って最適化します。PNG画像はicons.svgと同じsvgフォルダに保存します。
gulp.task('svg2png', function () {
gulp.src('svg/icons/*.svg')
.pipe($.svg2png(3))
.pipe($.rename({ prefix: "icons.svg." }))
.pipe($.imagemin())
.pipe(gulp.dest('svg'));
});主にIE向けのポリフィルとしてsvg4everybody を設置します。githubからsvg4everybodyをダウンロードしてjsフォルダに保存します。デモページ ではIE8でテストするためにlegacy版を使いました。
IE9以上のサポートのみで良い場合は、<head>に置かなくても良いようです。
<script src="js/svg4everybody.min.js"></script>
<script>svg4everybody();</script>IE6-8もサポートする場合、<head>内でsvg4everybodyを読み込みます。
<script src="js/svg4everybody.legacy.min.js"></script>
<script>svg4everybody();</script>また、以下を<head>内に記述します。
<meta http-equiv="X-UA-Compatible" content="IE=Edge">あとはHTMLで以下のように記述すればアイコンを読み込めます。
#arrow-leftの部分は、ファイル名を指定します。
<svg role="image" class="icon">
<use xlink:href="svg/icons.svg#arrow-left" />
</svg>CSSでアイコンの表示サイズや色を指定します。.icon imgでは、フォールバックでPNG画像が読み込まれた際のスタイルを指定しています。
.icon {
width: 32px;
height: 32px;
padding: 3px;
border-radius: 4px;
background: #ccc;
fill: #fff;
}
.icon img {
width: 32px;
height: 32px;
padding: 0;
margin: 0;
}お疲れさまでした！以上です！
これでアイコン管理が楽になりますね。
と、CSS-Tricksで紹介されている ようにIcomoon のようなサービスを使ってアイコンを管理するのもありだなぁと思って見ていたら、なんとGulpなしでもSVGスプライトを作ってくれるではないですか！しかも、外部SVGファイルの読み込みをサポートするためのIE9-11向けのポリフィル まで用意されてます。。。
あれ？？こっちの方が簡単！？笑
次回は、Icomoonを使ったSVGスプライトの作り方をまとめてみたいと思います。。。
こちらもご参考までにどうぞ：
主に以下の2つのページでSVGスプライトの手法を学びました。つくづく、この人たちすごいなぁと感嘆するばかりです。いつもありがとうございます！
2015/11/10 0:15 | 制作・効率化ツール
El CapitanでTotalFinderもXtraFinderも使えなくなってしまい、どうしたもんかと悩んでいたのですが、ようやく代わりになるものを見つけました。
El Capitanの人柱インストールの記事でも紹介した「Path Finder 7 」というアプリです（注: Finderの拡張ではない）。
30日間の無料トライアルがあって試してみたら結構良かったので、早速購入しました。通常$40のところ、TOTALFINDERというキャンペーンコードで半額になります（約2,500円 / 11月8日現在）。
Finderに求めていた機能以外にも面白い機能があって、2,500円払っても良い感じです。
デザインについては結構カスタマイズ可能なので、いろいろいじくってみて今では自分好みのものになりました。
以上、Total Finderラブだった方々、無料トライアルもあるんでPath Finder 7 を試してみてはいかがでしょうか？
2015/10/26 7:05 | 制作・効率化ツール
1年前に作ったgulpのタスクを久々に触ったら、package.jsonにあるdevDependenciesがかなり古くなっていました。そこで、これらを一気にアップデートする方法を探していたら、やっぱりありました。
npm-check-updates というツールが。
このツールを使うと、package.jsonにあるdevDependenciesのバージョンと最新のものを比較して見せてくれます。そして、コマンドを叩くだけで、古くなったすべてのdevDependenciesをアップデートしてくれます。
やり方は簡単で、まずはnpm-check-updatesをインストール：
% npm install npm-check-updates -gnpm-check-updatesを走らせる：
% ncuすると以下のように古くなっているものを教えてくれます：
% ncu
gulp-newer ^0.5.1 → ^1.0.0
gulp-ruby-sass ^0.6.0 → ^2.0.5
Run with -u to upgrade package.json最後に、以下のコマンドでpackage.jsonをアップデートできます。
% ncu -uあとは、以下のコマンドでパッケージ自体をアップデートできます：
% npm update当然なんですけど、僕みたいに1年も放置しておくと、さすがにgulpfile.jsもそのままでは動きませんでした。パッケージもアップグレードされると使い方が変わる場合もあるので、アップデートの際はお気をつけください！
今回はそれを覚悟でアップデートしたので良かったですが、普段の開発環境のアップデートの際には丁寧に一つ一つ見ていった方が良さそうです。ただ、最終的にはパッケージがいろいろ改善されていて、gulpfile.jsの面倒な記述も減ってよりシンプルになったので、一気に更新してしまって良かったかなぁと思ってます。
gulpfile.jsをアップデートしても変なエラーが出るという場合は、node_modulesフォルダを一掃して、すべてのdevDependenciesを再インストールしてしまうのも手かもしれません。使っていたほとんどのパッケージがかなり古くなっていたので、今回の僕の場合はその方法をとりました。あくまで自己責任で。
ちなみに、今回アップデートしたgulpタスク（sass、postcss、browser-sync、画像最適化）はgithub に置いてありますので、なにかの参考になれば幸いです。
2015/10/21 6:42 | IT・ガジェット
El Capitanにアップデートしたころに、うちのMacBook ProのiTunesで再生ボタンが使えなくなっているのに気付きました。なので、てっきりEl Capitanのせいかと思っていたら、Chromeに入れたGoogle Play Musicの拡張機能が原因でした。
iTunesで再生ボタンや「前の曲」「次の曲」ボタンが使えなくなったなぁと思ったらチェックしてみてください。
メニューの「ウィンドウ」 > 「拡張機能」から拡張機能画面を開いて一番下までスクロールすると「キーボードショートカット」というリンクがあって設定が可能です。
以下はGoogle Play Musicのキーボードショートカットを削除した状態。再設定しようと思ったらできなくなっちゃいました。いらないんですけど。。。
2015/10/20 6:08 | IT・ガジェット
メインのスマホをiPhoneからAndroidにしてから約8ヶ月、そして、Android版のスマートウォッチ「ZenWatch 」を使い始めてから約半年が経ちました。ここ数年は腕時計なんてほとんどしなかったのですが、スマートウォッチやウェラブル端末の可能性を自ら体感するために、最近は、ほぼ毎日身につけて生活しています。実際に自分で体験してみないとわからないことも多いですからね。
毎日使ってみてスマートウォッチのUXで「この辺りがキモになる」という考えがまとまってきたので、それらの「キモ」を5つにまとめてみました。
ぶっちゃけ、半年使わなくても気づいてたんですけどね。長く使うことで変わるのか確認してからまとめてみました。スマートウォッチが一般に普及するためには、以下の5つを腹落ちするまで理解し、より良いUXを提供する必要があると思います。（あとは金額か…）
通知の方法などが異なるApple Watchには当てはまらない部分もあるかもしれませんが、共通するものもあると思います。スマートウォッチのUXを考える際に参考になれば幸いです。
ZenWatchを使ってみて、まずはじめに便利だなと思ったのは通知機能です。スマートウォッチのレビューを見ると、多くの方がその点について書かれています。スマホを取り出さなくても、ちょっとしたメッセージやアプリからの通知を時計をチラ見するだけで確認できるのはやっぱり便利です。
ただ、便利な反面、常に身につけて使う場合に気になる点がありました。
それは腕時計だと通知が他人にも丸見えだということです。
Apple Watchは基本的に使ってないときには画面がオフになっているようですが、ZenWatchには「常に画面表示」という機能があって、これをオンにしておくと省エネ状態で常に時計表示がされた状態になります。
Apple Watchのレビュー記事 でもいくつか見かけました が、なにか動作をしないと時計が見られないのは不便です。なので、僕はこの「常に画面表示」をオンにして使っているのですが、これが曲者で、時計表示だけでなく通知の表示も常にオンになってしまいます。
たとえば、電車に乗っている時に通知が来ると、その通知が表示されたままになり隣に座っている人や向かいに座っている人、または前に立っている人にウォッチの通知が見える状態が続きます。通知が来ると時計が一瞬光るので周りの人も気になるのか、目線がウォッチに行くのを何度も見ました。あと、先日、歯医者で治療を受けてるときに通知が来たのですが、身動きが取れずウォッチにアホな通知が表示されてないか少し心配になりましたw
スマホならポケットに入っていれば見えませんし、すぐに隠すこともできます。しかし、腕時計の場合はウォッチフェイスを隠すのは結構大げさな仕草ですし、違和感のある体勢になります。
Android Wearでは手首のジェスチャーで操作ができる「手首でスクロール」機能で通知を隠すこともできますが、結構大げさな動作が必要です（これについては後で詳しく書いてます）。
もう一つ、よくある状況を考えてみます。たとえば、スマホで西野カナの「好き」という曲を聞いているとします（LINE MusicのCMネタ にも使われてましたね。小松菜奈の魔性の笑顔にやられそうw）。そうすると、40を越えたオヤジの腕に曲がかかっている数分程度の間ずっと「好き」と表示されるわけです。電車で隣のオヤジの時計に「好き」と表示されてたらモヤっとしますよね。
普段、曲名を意識して音楽を聞いているわけではないので、自分が知らないうちに恥ずかしい曲名が腕に表示されていることも十分あるわけですね。たいしたことではないですが、ちょっとだけ恥ずかしい。
こういった「ちょっと恥ずかしい」かもしれないユーザ体験をスマートウォッチのアプリ開発では考慮しないと、ユーザには受け入れられないと感じています。スマートウォッチはスマホよりも身体に近い、よりパーソナルな端末です。少し大げさに言うと、スマートウォッチは自分の体の一部となり、顔の表情や身振り手振りのジェスチャーと同様の機能を担います。スマートウォッチの通知は、第三者から見て、それを身につけている人の「表情」であり「身振り手振り」の一部になり得るわけです。
それゆえに、スマートウォッチのUXでは、ユーザ体験をより細かい一瞬に切り分けて考慮する必要があります。通知の表示の仕方（たとえば、3秒表示したらフェイドアウトするとか）、表示する内容などは、そういった瞬間のUXを考慮して設計するべきです。コンテキストを探知して、自動で通知内容を調整するとか、ユーザが自分の好みに細かく設定を変更する必要性がありそうです。また、初回体験のシンプルさと、使いながら学んでいくオンボーディングの体験設計も大切になりそうです。
なにを、どの分量で、どの程度の時間表示させるかは、情報の特性や一連のUXによって変わると思います。その辺を考えて適度な通知ができると、ユーザにとってはグッとくる、またサブリミナルにでもそのアプリへの好感度が増しロイヤリティをアップするUXになるのではないでしょうか？
まずはOSにその辺をコントロールするための機能が必要になるので、今後のwatchOSの動向を注視したいですね。
いまのところ、スマートウォッチはスマホと一緒に使うのが必須なコンパニオンデバイスです。しかし、それでは機能しないというのが実感です。たとえば、ユーザとしてはスマートウォッチだけで完結したいことを「スマホで開く」と表示されたりすると「だったらはじめからスマホ使うよ」と、心でつぶやきたくなります。
スマートウォッチ単体でも動くけど、オプションとしてスマホでも開けるというUXをベースに考えないとユーザには受け入れられないでしょう。
たとえば、スマートウォッチをつけてランニングに出かける場合、できればスマホは持って行きたくない。ウォッチのみでGPSやネットに接続して、Bluetoothヘッドフォンで音楽を聞きながら走りたいわけです。
あと、スマホを置いてトイレに行く際など、いちいちウォッチがオフライン状態になるのも面倒です。スマホをいじらずに済むからウォッチをしてるのに、ウォッチを使うには常にスマホを持っていなければならないというのは、UX的に大きな課題です。
AndroidではWiFi機能のついたスマートウォッチが標準になりそうですし、watchOS 2でもApple Watch上でアプリをネイティブで動かしたり、既知のWiFiホットスポットへのアクセス が可能になるようです。これが実現すれば今のUXよりはましになるかもしれません。
しかし、スマートウォッチ単体でいつでもどこでもネット接続できて、スマホとも連携できる状態じゃないと本当の意味での「スマートな時計」にはならないと思います。
Appleが特許を取得して開発しているVirtual SIMやGSMアソシエーションのeSIM（embedded SIM）という技術では、SIMカードがソフトウェア化されて物理的なカードが必要なくなります（参考：「Apple SIMの衝撃 キャリア主体のスマホ販売が激変する」 ）。近い将来、これをウエラブル端末に導入できればスマートウォッチでネットの常時接続が可能です。
1人のユーザが複数の端末を持つ時代、SIMカードを何枚も購入して端末ごとに入れて使うのは非現実的ですし、通信キャリアのビジネスも制限していると思います。IoTですべてのものがネットに接続されようとしている近未来、Virtual SIMやeSIMで1人のユーザが1つの契約で複数の端末でネットに接続できなければ、スマートウォッチなどのウエラブル端末の将来は見えてこないように思います。
スマートウォッチで消費しやすい情報量はどの程度なのか？迷うところです。小さい画面でも、個人的には結構長いテキストでも読めると思うのですが、その分、スクロールやその他の操作が増えてしまい、面倒といえば面倒です。では、スマートウォッチで見たい情報量をテキストに換算すると、いったいどの程度のものになるのでしょうか？現状、以下の2段階で分類すると良いと思っています。
通知にはぴったりで、チラッとみて次の行動が決められる程度の情報量です。もっと見たいのか、後で詳しく見るのか、または、アーカイブしたり削除したりなどのアクションを起こすのか。それくらいの判断をするための情報量と内容が欲しいですね。
スマートウォッチのような小さい画面でも適切な文字サイズで表示されていれば、相当量の文字をストレスなく消費できます。大切なのは、その瞬間（たぶん5〜10秒程度）で消費可能な文字量であることです。
半年ほど使い続けてみて、その分量はスマートウォッチの2〜3画面程度がちょうど良いと感じています。それくらいなら、ポケットからスマホを取り出すほどでもないと思える情報量です。
LINE Newsの通知が良くできていて、ちょうどいい情報量で、ちょうどいいUXになっています。さすがですね。「LINEの方たちはUXを理解してるな〜」と、思える情報量と提供方法をしています。
LINE Newsの通知では、まずトップニュースが1件表示されます。そして、スライドすると「もっと読む」ボタンが表示され、それをタップすると11件の記事が読み込まれ、それぞれの記事をまずは1画面で、さらにタップすると3〜4画面程度の分量で読むことができます。
ウォッチの画面上で見るニュースとしては、グランサブルで面白そうなニュースの概要をチェックできるちょうどよい情報量です。より深く読みたければスマホで見ればよいと思えるギリギリのラインをおさえています。LINEだけに。。。（失礼しました）
※ちなみに、「もっと読む」をタップしなくてもニュース一覧をデフォルトで読み込むオプションがあっても良いと思いました。あるのかな？
アップルウォッチではまだみたい ですが、Androidでは手首をクルっと回すとウォッチの操作ができる「手首でスクロール」ジェスチャー機能がついています（上の動画参照）。
これはこれですごく便利ですが、このジェスチャーの動作が結構派手にやらないと機能しません。たとえば、満員電車の中では、かなり目立つ動作なのでシャイな方には勇気のいる行為です。恥ずかしい通知を隠すのか、ちょっと怪しまれそうな動作をするのか。選択に悩んでしまう人もいるかもしれません。まぁ、自意識過剰かもしれませんけどね。
たとえば、iPhoneのシェイクで取り消し（アンドゥ）機能 も、結構大きな動作が必要で電車の中だと難しいですよね？それと似た感じです。
「手首でスクロール」などのスマートウォッチでのジェスチャー操作は、道を歩いているときなど、オープンスペースでの使用には問題ないですが、人と人の距離が近い空間では結構ハードルが高いということを認識しておく必要があります。将来的にジェスチャー操作機能がアプリに解放された際、そういうUXがあるというのを考慮したうえで、アプリの操作にジェスチャーを適用したり、通知する情報やタイミング、また、表示秒数などを設計するべきです。
4番目とちょっとかぶる内容ですけど。。。
スマートウォッチの場合、手首に付けるので両手は空きます。しかし、ウォッチの操作をしようと思うと両手が空いていないと簡単にはできません。
たとえば、スタバでコーヒーを買ってウォッチをした腕で受け取ったとします。
この状態でウォッチの画面を触ろうとしてください。
コーヒーがこぼれちゃいますよね？
では、ウォッチをしていない方の手でコーヒーを受け取ったらどうでしょう？
コーヒーを持ちながらウォッチの画面をなぞるのは至難のワザですよね。
これは、たとえば大きめの雑誌を持っている場合も同じで、持っている雑誌をくるっと90度程度回さないとウォッチの画面を見られません。ある程度のスペースがないと雑誌が周りのものや人にぶつかってしまう可能性があります。
スマホだと片手で取り出して、片手で操作できる。片手でコーヒーを持ちながら、または片手で電車の吊り革を持ちながら、さくさくメールに返信したりブログ書いたりできるんですよね。
ジェスチャー操作なら片腕でできますが、現段階ではジェスチャーで操作できることは多くありません。また、手首でスクロールのような操作は、意外と狭いスペースではやりにくいです。
スマートウォッチは画面を見られても操作できないシチュエーションがあるということを、UXを構築するうえでは配慮すべきでしょう。特に通知のUXにはこういったことを考慮して、何を、どのタイミングで、どの程度の期間表示させるかなど、製品やサービスに沿ったUXに最適なものを細かく考える必要がありそうです。
現段階でスマートウォッチでできることは、全体を通して物足りない感じが否めません。それは、OSやハードの制限、スマートウォッチという未開拓のプラットフォームでのアプリ開発の経験不足など、さまざまな原因があります。しかし、現段階でもそこそこ良く出来ていて、うっすらとですけど未来の可能性を感じないわけでもありません。回りくどい言い方ですけど。笑
カギとなるのは、まずはスマートウォッチへの考え方を根本から変えることです。小さい画面でできることは少ないと考えるのではなく、小さい画面でどうやって求められる情報をうまく届けられるかを考えたほうがユーザには喜んでもらえます。便利だったら使われますし、口コミで広まります。「これ、結構いいよ」というUXさえ提供できれば、必ずユーザは来てくれます。「If you build it… he will come.」たぶん。笑
画面サイズの制限や使える機能ありきでなく、UXファーストで考える。それがスマートウォッチのキャズム超えへの第一歩なのだと思います。
そういえば、新しいApple Watchの発表もありましたね。Hermesのカフ 、かっこいい。値段もかっこいいけど（188,000円で、しかも税別。税込20万円越え！）
2015/10/14 7:07 | 制作・効率化ツール
iPhoneで簡単にHTMLソースを見る方法はないかなぁと探していて、試しにCookpadのソースを見たら素敵だったのでご紹介。
こういう遊びゴコロ、すごくグッときますね。
ちなみに、iPhoneでHTMLソースを見るアプリは「View Source 」が良さそうです。
ブックマークレットを利用する方法もありますが、こっちのほうが使い勝手が良くてDOMの閲覧機能などもついていて便利です。有料だけど120円だし（2015年10月現在）。
使い方は簡単で、Safariでソースを見たいページに行ってシェアボタンから「View Source」を選ぶだけです。
ちなみに、Chromeでは使えないです。
ソースの閲覧、DOMの確認、画像などのアセットの確認に加え、インラインでJavaScriptを挿入する機能がついています。アプリを立ち上げるとテーマ機能で背景やハイライトの色を変えられます。右上のシェアボタンから各種機能にアクセスできます（わかりにくいですけど）。
2015/10/09 7:12 | 制作・効率化ツール
PostCSS って最近ちらほら目にするようになったけどいったいなに？と思っている方いませんか？僕はその一人です。なんとなくこんなもんかな？といった感じで曖昧にしか理解していなかったので「とりあえずこれだけ知っておけばいい」という情報を簡単にまとめてみました。
SassをVAIOのようなメーカーが作ってパッケージしたノートPCに例えると、PostCSSはマザーボードからプロセッサーからケースまで、すべて自分で選んで組み立てる自作PCです。
結論から言ってしまうと、かなり良さそうなので早速使い始めて損はないと思います。大きな導入リスクやデメリットは思いあたらないし、すでにビルドツールを使っていれば導入コストも少なくすみます。少なくとも試してみる価値は十二分にありそうです。もちろん、開発体制や環境、プロジェクトの性質によるんでしょうけど。
仕組みのシンプルさや開発者の間での盛り上がりを見ていると、かなり可能性が広がっていきそうです。フロントエンドに関わる仕事をされている方なら、知っておいて絶対に損はなさそうです。
では、PostCSSの特徴をざっくり箇条書きでまとめていきます。
GulpやGruntで開発環境ができていらば、かなり容易に導入できますね。なので、初期投資はひとまず用途にあった安定したプラグインを探すことくらいで済みそうです。CLI（コマンドラインインターフェイス）ツールも用意されています。
以下のツールのプラグインがあるそうです：
プラグイン一覧はPostCSSのGithubページ にも掲載されていますが、postcss.parts では検索可能な一覧にまとめられています。
以上、PostCSSについて簡単にまとめてみました。イントロでも書きましたが、かなり良さそうです。仕組みのシンプルさを考えると可能性が広がりそうなので、進化して長生きしそうなツール・仕組みではないかなと期待しています。
2015/10/06 23:07 | 制作・効率化ツール
いつも忘れてしまうので書き留めておきます。macOS Monterey（12.4）で確認をして内容を更新しました。この記事で紹介しているツール「n」もv8.2.0になりました！
n という便利なバージョン管理ツールがあるので、これを使ってバージョンを確認してアップデートします。nの詳しい使い方はこちらの記事 あたりをご参照いただくと良いと思います。n を使う際の注意点もしっかり説明されています。
$ npm install -g n1行目の「–stable」でStable（推奨版）のバージョン、2行目の「–latest」で最新版のバージョンが確認できます。
$ n --stable
$ n --latest$ n latestlatestは最新の機能を搭載した最新版へのアップデートになります。環境によっては「sudo n latest」のようにsudoコマンドが必要になります。
以下のコマンドでアップデートされたNodeのバージョンが確認できます。
$ node -vnコマンドでインストールされているバージョンの切り替えを行えます。nコマンドを実行して上下の矢印でバージョンを選択します。
$ n
node/15.11.0
node/15.14.0
ο node/16.0.0$ n lsn rmコマンドの後にいらなくなったバージョン番号を入力すると、それらのバージョンを削除できます。
$ n rm 18.2.0 18.3.0npmのほうはシンプルです。以下のコマンドでアップデートできます。
$ npm update -g npmちなみに、すべてのglobal packagesのアップデートは以下のコマンドでできます。
$ npm update -g※npmのバージョンが2.6.1以下の場合は違う方法 が薦められています。
どのGlobalパッケージが古くなっているかを確認するには、以下のコマンドを使います。
$ npm outdated -g以上、Node.jsとnpmのアップデートの方法でした。
2015/10/03 9:49 | 制作・効率化ツール
公開日（10月1日）の夜にEl Capitanにアップグレード（アップデート？）してみました！
いくつか注意したほうが良さそうなので、備忘録的にまとめてみました。ご参考になれば幸いです。ちなみに、Mac OS X El Capitanを入れたのはMacBook Pro (Retina, 13-inch, Mid 2014)です。
まずはじめに、TotalFinder が使えなくなってしまいます。隠れファイルの表示・非表示を切り替えたりDual Paneでファイルのコピペが便利だったので残念です。
TotalFinderが機能しなくなったのはEl Capitanで新しく導入されたSystem Integrity Protection（SIP） というシステム保護機能によるものらしく、このSIPをオフにすれば使えるBeta版 が提供されています。セキュリティを取るかTotalFinderをとるかは個人の自由ですが、せっかくのセキュリティ機能をオフにするのも微妙ですよね。
開発者の方曰く、今後の開発はストップするとのことで、代替アプリ・ソフトの紹介 までしています。以下が紹介されてますが、どれも個人的には好みではなく困っているところです。
TotalFinderユーザにはPRO版が50%オフになるそうですが、TotalFinderやXtraFinderのようにFinderに機能が追加されるものではなく、独自のアプリになっています。機能が満載すぎて個人的な好みではないです。。。
Commander Oneと同様のアプリですかね？
[追記： 2015/11/12]
結局、その後Path Finder 7を試してみて、なかなか良かったので、今はこれで落ち着いています。Finderを拡張するものではないですが、見た目はFinderとほぼ同じにできていて、機能も揃っています。詳しくは簡単なレポート記事を書いたので、そちらをご覧ください。
他にも以下が紹介されてましたが代替ではないのかな、と。。。
ちなみに、同様の機能を持つXtraFinder も動かなくなっているようです。リリースノート を見るとXtraFinder 0.25.5で「Supports OSX 10.11 beta」と書いてあって、対応版開発中 との情報もあるので期待です。
TotalFinder同様に、SIPのせいでHomebrewもエラーが出るようになりましたが、ココ とかココ を参考に設定を変えて、brew doctor、brew update、それからbrew upgrade <formula名>で各フォーミュラをアップグレードしたら、今のところ正常に動いているようです。
10.11対応はまだ で、El CapitanのGM（ゴールドマスター）が出てから開発を始めるとのことです。まぁ、でもやってくれそう。
[追記: 2015/11/08]
2015年11月現在、El Capitanに対応したOnyx 3.1.1 がダウンロード可能になっています。
Java for OS X 2015-01をインストールしろと言われますが、インストールしたらいまのところ無事に動いてます。
Fuse for OS X は2.8.1で「Improved support for 10.11」となっていてEl Capitanで動くようなのですが、Ext2/Ext3のサポートに必要なfuse-ext2 が動かなくなってしまいました。これもSIPのせいのようなので修正版が出るかどうか疑問です。
El Capitanで一番はじめに気づくのが日本語入力の違いだと思いますが、まだ慣れません。。。変換の際にenterキーを押す回数がすごく増える気がします。使っていくうちに精度が上がって良くなることを願ってます。
以上、El Capitanアップグレードの人柱レポートでした！
また何か問題があったらこのページをアップデートしていきます。あ、そうそう、Vagrantでも問題がありそうなので、使っている方は調べてからEl Capitanにアップグレードした方が良さそうです。
2015/09/30 6:55 | IT・ガジェット
iOS 9の新機能で、イヤフォンを接続するとミュージックアプリのアイコンが表示されて、ロック画面からアプリが起動できるのをご存知でしょうか？
gori.me の『細かすぎて伝わらなかった？まだある「iOS 9」の隠れた新機能12選 』などで紹介されている気づきにくい便利機能なんですが、設定をいろいろ変えていたらいつのまにか表示されなくなってしまいました。
検索しても出てこなくて、ようやくその設定方法を発見したのでご紹介します。
「設定」 > 「一般」 > 「Handoffと候補のApp」に行って「おすすめApp」の「インストール済みApp」をオンにすると出て来ました。以下の画面です。
デフォルトでは表示されるようなんですけどね。バッテリー節約のためにいろいろ設定を変更していたら、気づかないうちに消えていたので探すのに苦労しました。
たいした機能ではないんですけど。あぁ、やっとスッキリした。笑
2015/08/31 7:15 | 制作・効率化ツール
そろそろ自宅のMacBookにMicrosoft Edgeのテスト環境を作っておこうと思い、Microsoft Edge Dev（旧modern.IE） からVirtualBox用の仮装マシンをダウンロードしたんですが、なぜかフルスクリーン機能が使えなくて困りました。
同じように困っている方がいたら、以下の2点をチェックすると良いかもしれません。
まずは、今回の問題に出くわしたマシン環境とインストールした仮装マシンの詳細です。
Microsoft Edge Dev で、下の画像のように「Microsoft Edge on Win10」の「VirtualBox」版をダウンロードしました。そして、解凍してできた.ovaをダブルクリックして、出てきた設定画面でなにも変更せずに仮装マシンをVirtualBoxにインストールしました。
ちなみに、約5GBのSingle File版をダウンロードして解凍したのですが、デフォルトの解凍ソフトではうまく解凍できませんでした。ZIPファイルを右クリックして「The Unarchiver」を使ったら.ovaファイルにうまく解凍されました。
VirtualBoxで「Switch to Fullscreen」にしてもWin10のスクリーンが自動的にリサイズされない場合は、以下の2点をチェックすると良さそうです。
VirtualBox Guest Additionsのインストールには、仮装マシンを起動した際に出てくる「Device」メニューから「Insert Guest Additions CD Image…(Host+D)」を選びます。そうすると、仮想マシンのCDドライブに「VirtualBox Guest Additions」が出てくるので、そこから「VBoxWindowsAdditions.exe」を実行してGuest Additionsをインストールします。
ダウンロードした.ovaファイルをダブルクリックして、設定を変えずに仮装マシンをインストールするとビデオメモリーが18MB未満に設定されています。以下のようにエラーメッセージが出ている状態なので、設定を18MB以上に変更する必要があります。
ビデオメモリーの変更は、以下の手順で行います。
以下の設定が画面から「ディスプレー」を選択して「ビデオメモリー」を18MB以上にすると、さきほどのエラーメッセージが消えます。
これで次に仮装マシンを起動した際にはフルスクリーン機能が使えるはずです。
Edgeユーザはまだそれほど多くはないかもしれませんが、すぐに無視できない存在になるかもしれません。Google AnalyticsでEdgeがでてこない などの問題があったようですが「Edge」として表示されるようになったみたいです。
テスト頑張りましょ〜。
2015/08/23 0:14 | ウェブについての考察など
突然ですが、福島県浪江町ってご存知ですか？
「DASH村 があるところでしょ？」と思われた方は結構多いかもしれません。
では、その浪江町が復興支援事業の一環として行っているタブレット事業についてはどうでしょうか？
WBSでも取り上げられたことがあるので、もしかしたらご存知の方もいるかもしれませんが、そこまで一般に知られているレベルではないと推測します。
でも、この「タブレット事業」、誤解を恐れずに言うと、すごく面白いんです！
このタブレット事業は、これから高齢化社会を迎える日本で、高齢者層向けのアプリやサービス開発で必要とされることを町役場の主導で体現しているんです。リアルな課題を、情熱ある人々が、IT技術と関連開発手法、そして「人」を中心に据えた手段で解決しようとしている。そして、結果を出しさらなる改善を試みようとしている。そんなプロジェクトです。
「平成27年度 浪江町タブレット事業説明会 」に参加してきたので、聞いてきたことをベースに感じたこと思ったことをまとめてみました。これをきっかけに、一人でも多くの方に、このプロジェクトのことを知ってもらえたらと願っています。
原発事故により浪江町の町民は全国600以上の市町村でバラバラに避難生活を続けているそうです。そんな町民をどうにかサポートしたいという思いで始められたのが、このタブレット事業だそうです。
概要については下のプレゼン資料（スライドシェア）がわかりやすくまとまっているので、そちらをご覧ください。
また、平成27年度に行う開発への入札については、浪江町のウェブサイト で関連資料が公開されています。あまり時間に余裕はないようなので、入札を検討される事業者の方は、すぐに動いたほうが良さそうです。
※公共事業や福島の状況に詳しくないので、間違った情報を書いてしまっていたら、ぜひ、この記事のコメント欄やTwitter などでご指摘ください。即、修正します。
浪江町タブレット事業説明会のプレゼン資料や当日のYouTube映像が役場とCode for Namieのウェブサイトにアップされていますのでリンクを追加しておきます。
「面白い」と書くと、誤解を招く可能性もあると思ったので、少しだけ説明させてください。
記事のタイトルでも上のイントロ文でも、あえて、このタブレット事業は「面白い」と書きました。避難生活で大変な思いをしている方々を前に「面白い」とは不謹慎だ！と怒られてしまうかもしれません。でも、僕はこの「面白い」ということが、こういったプロジェクトにはすごく大切だと思っています。
それは、やっている人が面白くないプロジェクトでは、受け取る側の人々であり実際にこのサービスを使う町民の人々もつまらないと思うからです。そして、つまらなければ継続して使われることはありえないですし、そこに込められた「浪江町の人々のいまの生活を少しでもサポートしたい」という、せっかくの思いも伝わらないと思うからです。
だからこそ、どんなに深刻な課題を解決する場合でも、プロジェクトを面白くすることは大切だと思うのです。
そして、この「タブレット事業」では、それができている。
資料を読んだり、昨晩の説明会で役場やこのプロジェクトをサポートしているCode for Japanの方々の話を聞いていてそう思いました。さぞかし大変なプロジェクトなんだろうなぁと察してしまうわけですが、そんななかでも「面白いプロジェクトにしてやる！」という意気込みを感じました。
このプロジェクトが面白いのは、上にも書いたようにリアルな課題を、情熱ある人々が、IT技術と関連開発手法、そして「人」を中心い据えた手段で解決しようとしているからです。
町民のインタビューをはじめ、町民を巻き込んでアイディアソンやハッカソン をやったり、フォローアップのタブレット講習会やサポートのコールセンターの設置したり、入札の評価を公開して、アジャイル開発で出来上がったソースコードをGithubで公開 している。さらには、定量的な成果も追っていて、今年度も改善に向けてさらなる一歩を踏み出そうとしています。
公共事業であること、また、復興支援事業の一環であることにより、無知な僕には計り知れないほどの多くの制限を抱えていることと思います。でも、それらの制限を自由な発想とアイディアで解決して、前に進んでいるのではないかと勝手に想像しています。
この事業で行われていることは、僕にとっては聞いていてどれもワクワクする試みばかりです。
それは、今後につながる大きな可能性を秘めている。そんなふうに思えるからです。
すごく曖昧な表現で申し訳ないですが、このワクワク感には、iPhoneやiPadが発表されたときやResponsive Designについて初めて学んだときと似ているものがあって、「これができたら、こんなことやあんなことも解決できるのでは！？」という、より良い未来の想像につながるものがあります。
このタブレット事業は、今後の公共事業のあり方、地方自治体のあり方や物事の進め方にも大きく関わるものになると感じています。大雑把に分類すると以下の3つを大きく前進させる可能性を秘めているのではないでしょうか？
勉強不足でこの辺りの情報にまったく疎いので、「いやいや、そんなの日本中の自治体でやってるよ」と言われてしまったらそれまでなんですが。
少なくとも、このプロジェクトで行われている一つ一つの試みには、そういった未来志向のビジョンがあるなぁと思わされるわけです。
このタブレット事業の話をはじめて耳にしたとき、ぶっちゃけ、かなり懐疑的だったんですけどね。まず第一に、お年寄りにタブレットはハードル高いでしょ！と。そして、そこで人海戦術が必要になってしまうでしょ！と。
そういったところも、タブレット講習会を仮説住宅の集会所やその他地域に出向いて50回以上（のべ1,700人以上参加）行うなどしてケアしているそうです。そして、講習会をきっかけにお互いにタブレットを教え合うなどの人々の交流が起こったりもしているそうです。
では、より具体的に浪江町のタブレット事業を面白いと思う理由はなんのか。
僕が考える理由は3つあります。
以下で、それぞれの詳細を説明していきます。
そもそもタブレットを使ったことがない町民が多くいるなか、「テクノロジーの力で町民の絆を再生する」という課題を、ゼロベースで「本当に必要とされるものは何なのか」を町民との対話を通して考え、一緒に作っているというところがすごい！
そして、そこに立ちはだかる困難を、一つ一つアジャイルな手法で試行錯誤しながら改善していった（と見受けられる）。
浪江町が置かれた状況下で、それを行えたというだけですごく価値のあることだと思います。
昨年度は、ユーザーインタビューをはじめ、アイディアソンやハッカソンといったことも行ったそうですが、そのリサーチ結果もCode for Namieのウェブサイトで共有 されています。こういった手法は、IT活用にともなうアプリやサービス開発だけでなく、今後、自治体のあらゆる課題の解決手法として、広く活用できるのではないかと思います。
たとえば、今年度は、なみえ版超簡単LINE「つながっぺ」というアプリを作る予定だそうです。
「LINEを使えばいいじゃん」という声が聞こえてきそうですが、そこをあえて新しく作るというところに、「ばらばらになった家族や仲間を繋ぎたい！」という本気の思いを感じます。
70歳を過ぎた僕の父親はスマホにしてからしばらく経ちますが、それでもLINEを使ってのコミュニケーションは苦手なようです。メールをするとすぐに返事が来るのに、なぜかLINEにメッセージを送っても返事が来ない。僕にとってはLINEのほうが簡単に感じるのですが、父親にとってはそうではないんですね。
浪江町でもそういった方が多いらしく、LINEの操作性しかり、コンタクトの設定などのハードルが高いようです。そこを解決しないとタブレットを活用してもらえない。なので、そこをあえて新しく開発する。
なかなかできないことだと思いますし、だからこそ、そこで得られる知見やデータには価値が生まれると思います。
ある意味、この規模でシニアにヒアリングを行い、シニア向けにこういった開発が行われ、ユーザテストを通してサービスの改善が行われている事例は、それほど多くないのではないでしょうか？ここで得られた知見は、今後の高齢者向けのアプリ・サービス開発にも活用できるはずですし、すでにタブレットを導入している他の自治体や今後導入を考えている自治体でも活用できるはずです。
※タブレットの配布は高齢者限定ではないですが、インターネットやタブレットの操作にも慣れていなくて、情報の取得や他の町民とつながることがより難しい高齢者のサポートが重要課題の一つのようです。
アイディアソンやハッカソンの内容だけでなく、このタブレット事業で行われてきたこと、また、この事業に関わってきた方々の知見の多くがCode for Namieのウェブサイト で公開されています。
例を2つ、3つあげると、こんな感じで：
また、それだけでなく、開発されたアプリやサーバ設定などのソースコードはGithubで公開されています。
開発されたものがオープンソースで公開されることで、日本中の自治体の重複した開発が減り、リソースの有効活用や既存のものの改善にフォーカスすることも可能になります（理想論かもしれませんけど）。誰もが開発に参加でき、一緒にプログラムを改善していくオープンソース化までは考えていないようですが、そこを目指したいのだろうと思いますし、そうなったら、もっとワクワクしますね。
また、蓄積され共有された知見は、自治体のみでなく、一般企業にも役に立つはずです（僕も、これからじっくり読んで勉強させていただきます）。大切な税金を使ってやっている公共事業ですから、骨の髄まで有効活用してしかるべきなのかなとも思います。笑
僕が浪江町のタブレット事業について知り、興味を持ったきっかけは、知り合いが浪江町役場で働くことになったこと、そして、やはり、DASH村の存在でした。
2011年に震災が起こり原発事故があり、DASH村が福島県浪江町にあることを知りました。
DASH村でTOKIOメンバーに農業や村の暮らしを教えていた師匠の明雄さんをはじめ、何度となく番組に登場した村の人たちは、浪江町の方々だったんですね。
僕がアメリカに行ったのが1993年で、ザ！鉄腕！DASH！！ がはじまったのが1995年だそうなので、2001年に日本に帰ってくるまで、その存在はあまり知りませんでした。しかし、日本に帰ってきてからは毎週録画して、いまでは番組を見続けて14年近く経ちます。DASH村に登場する人たちは、他人とは思えない存在でした。
それに加えて、知り合いが浪江町役場で働くことになり、浪江町は、さらに身近に感じる存在になりました。
平成26年度の事業では、何もお手伝いできなかったので、今回、東京で平成27年度の事業説明会を行うと聞き、少しでも情報拡散ができればと思い、説明会に参加してこの記事を書くに至ったわけです。
説明会で話を聞いて、単純にすごく良いプロジェクトだと思ったので、一人でも多くの方に知ってもらえたいと考えたのもあります。
このプロジェクトが、浪江町だけでなく、日本の絆をつなぐプロジェクトになっててほしい。そう願っています。
最後になりますが、プロジェクトの内容について、勝手なアイディアというか妄想を書いてみます。
若い世代はタブレットよりスマホで使えたほうが絶対に便利です。また、スマホがなくても閲覧できるように、ウェブでもログインして使えるようになれば、なお良いと思いました。
ウェブの最大のメリットは、インターネットにさえつながればどこでも見られるところです。ハイブリッドのAndroidアプリ + ウェブサイトが最強のコンビネーションなのではないでしょうか？
ちなみに、平成27年度の事業ではスマホ対応はしていきたいとのことでした。
高齢者の方々も、タブレットの操作になれてくると、次第にスマホを持つことにメリットを感じはじめるのではないでしょうか？実際、年配の同僚の方もそうしていました。少し大きめのiPhone 6 PlusとかGalaxy Noteのような6インチ程度の端末のほうが、お年寄りにも持ち運びが便利でしょうし、日常的に使うものとしてそちらのほうが良い。
そういったことを考慮して、このタブレットを2〜3年程度の間の「教育端末」として位置づけてしまってはどうでしょうか？
そして、将来的にはスマホ移行への障壁を取り除いてあげるような仕組みを提供していっても良いのかもしれません。ハードルはかなり高そうですけど。
すでにそのような機能はあるのかもしれませんが、若い世代がソーシャルメディアで、たとえば、#namieなどのタグをつけた投稿を集めてきて、キュレーションをしてアプリにも取り込むようにしてはどうでしょうか？
そういった投稿を見たら、高齢者の方々もソーシャルメディアを知るきっかけになると思いますし、ハードルは高いと思いますが、TwitterやFacebookを興味を持って使い始める方も出てくるかもしれません。きっと、町民の方々もこのタブレットにずっと依存しているわけにもいかないでしょうから、少しずつでも、そういった方々に次のコミュニケーション手法を明示していくのを、このタブレットの役割としても良いのではないでしょうか？
ということで、このプロジェクトの今年度の動きも見逃せません。どのような改善が行われ、どのような結果が得られるのか。引き続き注目していきたいですし、応援していきたいと思います。
浪江町役場の方々、Code for Japanの方々、頑張ってください！
2015/08/15 11:59 | ウェブについての考察など
ここ最近、海外でも日本でも「ウェブの将来は明るくない」という話題をちらほら目にするので、1990年代後半からウェブ制作をずっとやっている自分としては「ウェブ制作という仕事に未来はないのかぁ。そうなのかぁ。。。」と、少し憂鬱な気持ちになっています。
別にそれらの話を鵜呑みにして同意しているわけではないんですけどね。
ということで、これを機に頭の中でモヤモヤしていることを、一度整理して書き留めておこうと思います。こういう未来予想的な内容は10年後に読み返してみたら面白そうですしね。
10年後の自分： 「全然ちがってたっ！恥。。。」みたいな感じでw
「ウェブはもうあッか〜ん」というプレッシャーを感じているのは僕だけですかね？
僕が感じている風潮を、大雑把に、ちょっと大げさにまとめてみると以下のような感じです：
おおげさに脚色して書きましたが、ウェブに散見するいくつかの記事やそれに対する反応を見ていると、こんな雰囲気があるというのも、あながち間違っていない気がします。もちろん、逆の論調もあるんですけどね。
しかし、上の1、2、3について、自分で書いておいて言うのもなんですが。。。
やっぱり、なんかモヤモヤするとこありますね。
2、3日前、運営に携わっているウェブサイトのアクセス解析を見ていたら、ついにモバイルからのアクセスがデスクトップからのアクセスを抜いていました。業界やウェブサイトの種類によってこの割合は大きく異なるとは思いますが、スマホ全盛期がきて、ようやくウェブ制作に対する考え方を180度転換して、モバイル・ファーストで考えて成り立つ時代になりつつあるのだと思います。
家ではスマホオンリーのユーザも増えるでしょうし。
思考の中心にスマホを持ってくる、そして、パソコンをあまり使っていなかったユーザにも優しく対応しなくてはならない時代になりつつある。
こればっかりは、逆らえない自然の摂理みたいなもので、多くの場合、主戦場はデスクトップからスマホに移行した、と考えて間違いないですよね。
ここに異論はありません。
ただし、デスクトップが消えるかっていうと、まったくそんなこともなくて。
職場では依然としてデスクトップPCを使うでしょうし、そこそこの量のテキスト入力が必要な場合や、大きい画面に適した情報（テーブルや図・データなど）の閲覧にはノートやデスクトップPC、さらにはタブレット端末のほうが適している場合もあるので、それらが消えて無くなることはないでしょう。
たしかに、ネイティブ・アプリの方がサクサク動くし、機能もUIもウェブのそれより充実している場合もあります（少なくとも現時点では）。しかし、総合的にUXを考えると、すべてのシチュエーションでアプリが適しているかというと、そんなこともない気がします。
ウェブには「リンク」という、現時点ではアプリにはない大きな強みがあります。
Google I/O 2015の「The Next Generation Mobile Web」というセッションでも「リンク」の偉大さが語られています。
人間が使うモバイルアプリは平均12から20と言われている。しかし一方で、アクセスされるWebサイトは、一ヶ月あたり100ドメイン以上だ。それはWebが、リンクを使って簡単にアクセスできるからだ。
— これからのモバイル向けWeb制作 The Next Generation Mobile Web | HTML5Experts.jp
ウェブの一つの大きな特徴である「リンク」は偉大なもので、ウェブのユーザへのリーチの絶大さを考えると一概に「スマホでは断然アプリっしょ」とは言えないと思うわけです。
日本最大のレシピサイトのcookpadを例に、ある特定の情報を探す際に使うのが、アプリなのかウェブなのか、もう少し掘り下げて考えてみます。
実は、レシピを探すときはiPadのクックパッドのアプリを使って探すことが多いので（たまに料理するんです）、ある特定の情報（この場合はレシピ）を「検索」する場合は、ググるより、ある特定のアプリを選択して使うことが多くなり、「なんでもありのウェブ検索」と「ある情報に特化した情報のアプリ内検索」を使い分ける時代が来ているとも思っています。
たとえば、レシピならクックパッド、旅情報ならTripAdvisor、日用品を探すならAmazonといったように。情報を探す際のはじめの行動が、ウェブ検索ではなくて、それぞれに特化したアプリの起動からの検索になることも考えられます。SEOで検索上位を狙うのではなく、スマホのホーム画面の固定位置を狙わなくてはならない時代ですね。
そう考えると、スマホ普及率が50%を超えた日本でも、cookdpadのようなサービスの場合、年々アプリからのアクセスが増えているのかと思っていました。
ところが、クックパッドの「2015年12月期第2四半期 決算説明会資料」 を見ると、2015年6月でスマホのブラウザでcookpadにアクセスするユーザが3030万人なのに対し、アプリからのアクセスは915万人と、大幅にブラウザからのアクセスが多いことがわかります。
いやいや、とはいえ、直近ではアプリの割合が伸びてるんでしょ？
と、思うかもしれません。。。
ところが、そんなことはなくて2013年7月の531万人（スマートフォンのブラウザ）と383万人（アプリ）と比べても、スマホのブラウザからアクセスするユーザ数のほうが大幅に増加しています。
これはあくまで推測でしかありませんが、クックパッドのような名の知れたブランドのサービスでさえ、アクセスはアプリからではなくウェブからのほうが多いというのは、検索経由の流入の多さを物語っているのだと思います。
デスクトップPCの使用頻度が激減して、ユーザが使用するメインのデバイスがスマホになったとしても、人々が情報を必要とすることに変わりはありません。そして、現時点では、人々がそれらのデバイスを使って能動的に情報を探すには、なんらかの形で「検索」をする方法しか考えられていません。
現時点では人々が能動的に情報を探す手段として、一番手っ取り早く、便利で、使用頻度が高いのはググることだと言い切って良いのではないでしょうか？
さらに、スマホでの検索についても興味深いデータがWeb担当者Forum で紹介されています。
Yahoo! JAPANによる調査（2013年11月、2014年11月データ比較）によると、スマホでの検索数は増えているそうです。
2013年11月と2014年11月のユーザー1人あたりのデバイス別平均検索数を年代別に比較してみると、すべての年代でスマホでの検索数は上昇している。
スマホでは検索しないという話は、あくまで個人的な意見レベルの話のようです。
また、GoogleもAdwordsのブログ記事 でモバイル端末での検索について以下のように発表していています。
In fact, more Google searches take place on mobile devices than on computers in 10 countries including the US and Japan.
【意訳】
事実、アメリカと日本を含む10カ国で、より多くのGoogle検索がコンピューターよりもモバイル端末で行われている
「mobile devices」も「computers」ちゃうんか！というツッコミはさておき。。。
いつでもどこでも気軽に検索できるスマホだからこそ、TVを見ていて気になったちょっとした内容の検索から、本当に生活に必要な本気の検索まで、ユーザ一人当たりの検索回数が増える可能性だって大いにあります（あくまで個人レベルの考察ですけど）。
「OK Google」をPRするAndroidのCM効果もあってか、僕はNexus 5で音声検索を使って頻繁に検索を行うようになりました。スマホに話しかけることにも以前より抵抗を感じなくなりましたし。
スマホでの検索数が増えているのなら、なんらかの手段で検索（文字入力、音声入力、QRや画像認識など）して、最終的にはブラウザを経由してウェブにたどり着いているはずです。情報のユーザへのリーチは、アプリとウェブで比較すると、依然、検索からの流入を見込めるウェブのほうが圧倒的に大きいと言って良さそうです。
でも、最近ではTwitterやFacebook、さらにはLINEなどのメッセンジャーアプリ、それから数多くあるニュースアプリから情報を得ることが多いよね？という見方もあるかもしれません。しかし、多くのSNSやニュースアプリで得る情報は、そこに流れている情報をキャッチする行為であり、あくまで受動的なものです。自分がほしい情報を能動的に探すウェブ検索とは異なる行為です。
では、たとえばFacebookというエコシステムにウェブのように情報が蓄積されていたとしたらどうでしょう？実際にFacebook内にベージを作ることも可能ですし、多くの企業がFacebook上にコンテンツを載せています。また、情報の性質や形は異なりますが、個人の情報発信もFacebook上で頻繁に行われています。
もし、それらのコンテンツがマーケティングのためのみでなく、ユーザにとって真に有用な情報になっていて、Googleに勝る検索体験を提供できたとすれば、ユーザはFacebook内で能動的な検索を完結できることになります。
Facebookがそれを実現できれば、ウェブに取って代わることも可能なのかもしれません。
しかし、いまの時点では、そういった流れは見られませんし、Facebookが目指すのが、ウェブに取って代わることというのも聞いたことがありません。Facebook上での検索とウェブ検索は、現時点では異なる目的で行われる違った行為と言えるでしょう。
さて、トラフィックの流入についてはウェブが強いというのがわかりました。
けど、モバイル・ウェブのパフォーマンスの悪さが足を引っ張っていないでしょうか？
たしかに、その通りです。
少なくとも現時点では、同じ労力と時間をかけて制作した場合、アプリで提供できる操作性にウェブは到底太刀打ちできないと思います。
しかし、ウェブのパフォーマンスに改善の余地がないわけではないですし、ウェブには「リンク」という最大の武器があり、それゆえにウェブのユーザへのリーチはアプリに圧倒的に勝ります。
先ほど紹介したGoogle I/O 2015の「The Next Generation Mobile Web」セッションの話 では、モバイル・ウェブのこれからについての考察を以下の3つの分野に分けて、わかりやすくまとめられています。
パフォーマンスとエンゲージメントについては、モバイル・ウェブがアプリにこれから追いついていかなければならない分野ですが、この記事を読むとアプリに引けを取らない体験をユーザに提供できる日は、そう遠くはないことがわかります。
少なくとも「Chromeが入っているAndroidならねw（iPhoneのCM風）」
いまはアプリ開発がナウ（死語w）ですが、近い将来「まだアプリ開発で消耗してるの？」なんて言われてしまう時代が来ないとも限りません。
とはいえ、近い将来ウェブはアプリの機能に追いつき、アプリはウェブの最大の強みである「リンク」を手にするわけですね（「最後にPart 2」参照）。ウェブとアプリの力が均衡したときに、ゼロサムゲームになってしまうのか、それとも良いとこ取りをして共存しながら相乗効果を生む世界になるのか、そのあたりが見所です。
個人的には、良いとこ取りのハイブリッドで相乗効果を生む、ウェブとアプリが仲良く共存する世界を望んでいます。ビデオテープのβみたいに、消えてなくなる技術もありましたけど。。。汗
ウェブは「リンク」という圧倒的な強みを持っていると書きましたが、アプリの世界でもDeeplink やApp Indexing といったアプリ内コンテンツへのリンク機能が準備されていて、ウェブ検索からアプリ内の情報に直接リンクさせることもできるようになってきています。
さらに、Android Mで実装予定の「Now on tap 」ではアプリ内での行動に関連性が高いアプリ（での行動）やウェブサイトのサジェストを表示してくれるようになるそうです。
では、良いお盆休みを〜
2015/07/20 19:24 | 制作・効率化ツール
「Death to Icon Fonts（アイコンフォントに死を） 」というSeren D さんのスライドプレゼンテーションで、アイコンフォントではディスレクシア向けのフォントで問題が起こるし、他にも課題があるので使用は控えたほうが良いですよ、ということを訴えています。A List Apartブログ で紹介されていて気になったので、どんな問題が起こるのか確認してみました。
「Death to Icon Fonts 」では、ディスレクシア（日本では失読症、難読症、読字障害などと呼ばれている）向けに作られたフォント「OpenDyslexic 」で問題が起こることが紹介されていて、アイコンフォントにはその他にもアクセシビリティ上の問題がいくつかあるため、使わないほうが良いと勧めています。
これはフォントを強制的にOpenDyslexicなどのディスレクシア対応のもので表示させる際に、UnicodeのPUA（Private Use Area）を使ったアイコンフォントだと、「□」で表示される場合があるという問題です。
たとえば、Chromeの拡張機能の「Font Changer 」を使ってディスレキシア向けのフォント「OpenDyslexic3 Regular」でこのブログを表示させると、以下のようにアイコンフォントが使われているブログのタイトルの「R」やソーシャル・アイコンの部分が「□」で表示されてしまいます。
通常は以下のように表示されています：
他にも「OpenDyslexic 」というChrome拡張機能があって、これを利用するとアイコンフォントまでは入れ替えられないらしく、このブログも問題なく表示されました。アイコンフォントはそのまま表示され、英字部分だけディスレクシア向けのフォントで表示されました。
ディスレクシアの方でも、それぞれの好みでツールを選択していると思うので、すべてのケースでアイコンフォントの問題が起こるとは言えなさそうです。
せっかくの機会なので、ディスレクシアについて、ざっくり調べてみました。要点を簡単にまとめると以下のとおりです：
日本語のディスレクシア向けのフォントはないようですし、言語によってディスレクシアの症状は異なるらしいので、今回指摘されていたフォントの問題に限定すると、日本語環境ではこの問題は関係ないと言えそうです。日本語のサイトのみなら問題ないですが、昨今ではグローバル向けに情報を発信している企業や組織も多いでしょうから、英語サイトの場合はアイコンフォントを使うとこういった問題が起こりうることは知っておいて良さそうです。
ディスレクシアについては、以下のようなサイトを参考にさせていただきました。
最後にアイコンフォントとアクセシビリティについて、少しだけ書いておきます。アイコンフォントには、以下の3つの課題があるのですが、アクセシブルな実装が不可能ではないようです。
アイコンフォントの3つの課題の詳細とアクセシブルな実装方法は、filament groupのブログ記事「Bulletproof Accessible Icon Fonts — filament group 」で詳しく紹介されているので、そちらを参照いただければと思います。ありがたいことに、hail2uさんが日本語訳 をしてくれています。