初めてスマートフォンサイトを設計してわかったこと

今、絶賛スマホサイト作成中なんですが、自分でイチから組んでみてわかったことをメモがわりに。

良くも悪くも、一回ちゃんと組んでみて初めて分かったことがたくさんでした。
 

１．HTML5が地味に難解

今までもそう思っていたので新たな発見、とまではいかないですが、やはり迷ったのはsectionの使い方。
メインコンテンツエリアの文章内の見出しと、見出しに紐付くコンテンツをsectionで囲ってみたものの、これであってるのかな？感が未だにぬぐえず。HTML5、奥が深いです。

２．CSS3の新プロパティの使いどころに迷う

たとえば、コンテンツ内でボックスがふたつ横並びになっている場合、display:boxなのかfloatなのか、いちいち判断に迷いました。
2カラムコンテンツの実装はfloat（もしくはposition）、と迷いのなかった今までに比べると、迷いが出る分時間がかかります。
さらに、CSS3のプロパティを実践的に使うことで、案外使い方が分からなかったり、使い方の新しい発見があったりで、より時間がとられました。

３．プリフィックスがヤバイ

最初は、prefixfree.jsでprefixをつけずに実装するつもりだったのですが、諦めた（理由は後述）ため、大量のプリフィックスが出現。
幸い、prefixfree.jsに関しては、多分実践では使えないかもなぁという予想はしていたので精神的ダメージはほぼなかったんですが、prefixがかなりつらかったです。
gradientのprefixをつけるときに間違って-webkit-background:linear-gradient...としてしまうくらい（笑）。
（正しくはbackground:-webkit-linear-gradient...）

また、途中で、WebKitにはgradientの記述方式が2種類必要と聞いてドン引きました…。
2種類あること自体は知っていましたが、現在もその記述が必要だとは思いもしていませんでした。
下記の2つです。

• background:-webkit-gradient(linear, 方向, from(#XXX), color-stop(XX%, #XXX), to(#XXX));
• background:-webkit-linear-gradient(方向, #XXX, #XXX XX%, #XXX);

上の記述のほうは、古いwebkitの仕様であったもので、古いスマートフォンではこちらしか認識しないものもあるんだとか。

『スマートフォンは2年契約が多いから、2年位前に出ている機種までは対応する必要があるんだよね。』

という名言をいただきました。
舞台はスマホに移っても、意識するのはPCと同じですね（涙）。

４．実機での確認は必須

最初、「基本、PCのwebkit系ブラウザで確認すればOKだから。」と言われていたのですが、そんなことはありませんでした。

まず、レンダリングの速度です。
先ほどprefixfree.jsの話をしましたが、PCで見ていたときは問題なくレンダリングされていたのですが、やはりスマートフォン実機で見てみると、レンダリング時にタイムラグが。
JSをやめ、prefixをCSS直書きに直したところ、タイムラグがなくなったので、今回はprefixfree.jsなしでいくことに決めました。

次に、フォントサイズ。
実機で確認すると、フォントの見え方がやはり異なります。ボックスにぴったり入る文字数だと思っていたら1文字だけ改行してしまったり、文字間が思ったより空いてしまったり。
今回、エミュレータは導入しなかった（存在すら知らなかった）のでこのような事態になっているわけですが、やはり実機で確認することが必須です。

５．CSS拡張メタ言語の偉大さを知る

最近、社内のいろんな人がLessだのSassだの（CSS拡張メタ言語）言うのを聞くようになりました。
簡単な概要は知っていたのですが、CSSは手書きで書いてこそなんだよ（怒）なんでそんなの使わなきゃいけないの？などと思っていました。

が、スマートフォン案件には、彼らの力が必要だと体感しました。
スマートフォン案件というよりは、CSS3を使用する案件には、CSS拡張メタ言語が必要なんです。

構築前にも、「Sassとか使わんの？」といわれたので、「Sassは使ったことがなく、今回スマホ案件初めてなので、時間がかかると困るのでひとまず使わないでいきたいです」（これはSassが嫌いだったから断ったんじゃなくて本心です）と言ったんですが、やってみてわかることがやはりあります。

ただ、普通のサイト構築なら、別に必要ないよ。という気持ちは変わってません。
今回、なぜ必要だと切にに感じたのかと言うと。

※ちなみに、下記はSassについてざっくり話を聞いたときに得た知識で、Lessも同じことができるかどうかは確認していません。

• プリフィックスの多用
  JSなどを使用しない場合、CSS3を使用する際には、-webkit-、-moz-、-o-、-ms-　の4種類のprefixが必要になります。
  1つのプロパティにつき、prefixなしの通常の書き方も含めると5つ、記述が必要になります。これがたくさんの種類、たくさんのモジュールにあたるとかなりげんなりしてしまいます。
  が、SassとCompassを使用するとこれが楽になるんだとか。
• 同じスタイルの使用
  特にbox-shadow（ドロップシャドウ）を使う際に思ったのですが、ひとつのサイト内で、ドロップシャドウの向きが変わったり、サイズが変わったりすることは少ないように思います。そのときに、同じ記述を何度も書くのは面倒だし、ひとまとめにするにしても記述する場所が散らばっていると、運用時に不便。
  Sassを使用すると、プロパティを変数化して代入することができるので管理が楽に。

ただ、今でもSassやLessを導入せずに構築したことに関しては後悔していません。
それらを導入せずに設計したからこそ、ツールの必要性が、理屈ではなく体験として理解できたので。私の中ではとても貴重な経験でした。

６．コツを掴んだことによる記述変化

これは私が悪いんですが、最初は要領がいまいちわかってなかったのでソースがごちゃごちゃだったんですが、徐々に慣れてコツを掴んだ結果、ソースに統一感が無くなり、失敗しました･･･。

---

まだ全然納品まで到ってないのですが、それにしても10ページ前後のHTMLを作るだけでこれほど分かることがあるとは、と感動しました。だから新しい技術を学ぶのは面白い！と改めて実感しました。

 

---

Swap Skills Doubbble 『Webサイトもスマホアプリも！One Web』 に行ってきた

昨日、Swap Skills Doubbble 『Webサイトもスマホアプリも！One Web』というセミナーに参加してきました。
記憶の新しいうちにレポートを記載します。
初めて大井町駅に降り立ったのですが、成城石井があって2回も立ち寄ってしまいました（何も買わなかったけど

おことわり

• とにかく長いので、暇なときに読んでください。
• 講演の資料が手元にないので、私のメモベースの話です。
• 一応有料のセミナーなので、講演の内容は下記のすべてではなく、私が気になった箇所をメインにご紹介しています。
• 講演者がお話されたことに対し、私の解釈を加えた内容になっています。
  『講演された方のお話そのもの』ではありませんので、誤解なきようお願いいたします。
  不快な思いをされた方や、誤解を招く表現などありましたらご指摘いただければ幸いです。

---

始まる前に

まず服装なのですが、こういうセミナーの参加が初めてだったので、
外出着（ジャケット＋きれいめスカート）レベルで行ったのですがみんなカジュアルでした（笑
ホットパンツのガールもいらっしゃった。
まぁ、みんなスーツの中ひとり私服、よりもましかと思って諦めました。

あとは、司会のお姉さんが緊張しているのか、めちゃくちゃカミカミでした。
あまりこういうWeb系のセミナーに参加したことがなかったので、かなりバタバタしている印象を受けました。
オープニングムービーもなんだか端が切れてたみたい。（解像度があってなかった？）
最初、そういう仕様？かと思ったが、さすがにスポンサーロゴが切れてたので何かあったんでしょうね････。

---

Transformative Web Design／長谷川 恭久さん

長谷川さんのブログ（サイト？）Couldは学生時代よく読んでいまして、最近めっきり回覧が遠のいていたのですが、今回講演されるということで、大変嬉しく思いました。
長谷川さんが講演されるということが、今回セミナーに参加を決めた理由の一つです。

長谷川さんの講演は、私の心にささる部分が多く、
"Webにかかわるさまざまな分野の人が、『Webを良くしたい』と思っているけれど、なかなかうまくいかないと感じている。
『分野が違うから私は知らない』というのでは、これからやっていけないのではないか？"
と私のメモに書いてありました。これ、まさに私が思ってることだよ･･･と思いました。
（自分が長谷川さんの話を聞いて考えたことをメモっただけかもしれない。。。自信ないです。）

今、マルチデバイス化が進んでいるけれど、Webは紙やそのほかの媒体とは違うと、再認識してほしい。
たとえば紙は、A4やB3など、カンバスに制限があり、その制限があるからこそできるデザインというものがある。
しかし、Webにはそのような制限はない。モバイルやデスクトップにとどまらず、将来は冷蔵庫やガラスやメガネにだって、Webサイトが表示される日が来るかもしれない。
そのときに、またそのデバイス用にリデザインをするのか？と考えると、気の遠くなるような話になってしまう。

コンテンツの表示サイズをデバイスごとに作り替える、という考え方ではなく、コンテンツ自体にたくさんの情報を入れておき、デバイスごとに出力するコンテンツを分ける、という考え方をしたほうが良い。 と、私は受け取りました。

---

レスポンシブWebデザインを 商業（ビジネス）サイトで実現するための考えと仕組み／菊池 崇さん

菊池さんの講演は、私のような技術者（エンジニア）よりは、ディレクターや、レスポンシブを導入しようか迷っているサイト運営者向けの内容だと思いました。

画像をいかにスマホ対応するか、という内容が一番印象に残っています。
response.jsを紹介されていて、このJSを使うと、デバイスごとに適切な画像サイズのものが表示されるとのこと。いくつか類似のものを調べた中で一番早いとおっしゃっていました。
個人的には一度自分で試してレンダリングしてみないことには。と感じたのでいずれ試してみたいと思います。

レスポンシブデザインのとき、デザイナーは『CSS3でこれってできるのかな？』については考えるけれど、
スマホのパフォーマンスを考えるとこの画像は重いかな･･･とか、考えることは少ないように思います。（少なくとも、私の周りでそのような考え方をしているデザイナーはいないです。）

私自身も、レスポンシブデザインは『CSS3』の技術、コーダーがどうにかするものなんだと思っていたのですが、
デザイナーも参加の余地があること、むしろ、デザイナーとコーダーの理解があってこそ、よりパフォーマンスの向上が図れるのではと思いました。

---

「デザインニング・イン・ブラウザ」／斎藤 祐也さん

斎藤さんの講演はかなりエンジニア寄りでした。たぶん、ディレクター寄りの人は、具体的にどのように内容を実践するのか、想像するのが難しかったのではないかなぁと思います。

内容はインブラウザ デザイン＋αです。

現在は、PSDでデザインをして、その後コーディングという流れが一般的ですが、最初っからブラウザでデザインしたほうが、『これは本当にHTML（・CSS・JS）側でできるのか？』を先に試すことができるので、「これは100%実装できる」という確証が得られるので心理的に楽だと。

エンジニアにとって、『その技術が実装できるのか？』というのはかなり重要だし、判断に迷うときが結構あります。できるかどうかわからなくて、できないかも･･･と言ってしまうこともあります。先にHTMLでデザインしておけば、「これは実装できる」のは明らかですし、コーダーとしてはとても嬉しいです。

ただ、「CSS3が使用可能」な場合が一番の活用しどきなのかなぁと思いました。
HTMLでかたちづくったものがそのままベースとして使えるわけですから、CSS3で、グラデーションや角丸が使えてこそ、メリットが生かされるというか。
せっかくCSS3でエフェクトかけても、それが使えないなら結局フォトショで作り直しになってしまうわけですし。

このアプローチはずっとやりたいと思ってきたので、ころあいを見計らって提案してみよう。と、今回の講演を聞いて改めて思いました。

---

「制作」から「開発」へ、そして最先端へ - Webアプリ開発の現状と未来／白石 俊平さん

講演内容とは全然関係ないですが、白石さん自身、とても物腰が柔らかくてお話が聞きやすかったです。

内容は中の人がそっと教えるWebリニューアル失敗の顛末が元になっているとのこと。私は読んだことがなかったので、個人的に頷けることが多くて面白かったです。

講演の中で気になったのが、『sectionは（headerやfooter、articleなど以外の）汎用的なブロック』と言っていたこと。
「嘘だッ！！！」と思わず叫びたかったですが･･･。
ただ、白石さんご自身は『HTML5開発者コミュニティ「html5j.org」管理人』でいらっしゃいますし、
ご本人もdivとsectionは違う旨のお話をされていたので、簡単に説明するための言葉のアヤだとは思うのですが。

sectionタグは汎用的なブロックではありません。
sectionは文章を意味（章）ごとに分けるものであって、section内にはそのsectionの見出しをあらわす見出しタグ（h1～h6）が必ず入ります。

あと、footerの子要素に見出しタグ（h1～h6）は入らない、footerに見出しを入れるならsectionで囲んでください、という旨の発言をされていたような気も･･･。
ネットをざっと検索してみたのですが、「footerの子要素に見出しタグ（h1～h6）は入らない」という記事がどこにも見つからず、一応文法的には間違いではないのでは？と感じたんですが･･･。（私も自信がないんですが。）
header、もしくはhgroup要素の聞き違いだったらいいのですが。

と脱線してしまいましたが、講演内容に戻ります。
講演の中で、白石さんが『モバイルファースト』にする理由を述べられていて、それがエンジニア的にはとてもしっくりきました。

なぜモバイルファーストかというと、『それがモバイルで実装できるかわからないから』です。
エンジニアは、その技術が実装できるか否か、判断に迷います。本当は実装できないものなのに、実装できるのでは？と試行錯誤するとタイムロスが大変です。（このあたりは斎藤さんも同じニュアンスの発言をされていました）

その技術はモバイルで本当に実装できるのか？モバイルでのパフォーマンスはどうなのか？を知るためにも、最初にモバイルを考え、実装する『モバイルファースト』は、エンジニアとしてもかなり利点のある考え方なんだと感じました。（むしろ、エンジニアのための考え方だったんですかね？）

---

OneWebにする前に、コンテンツを見直そう！コンテンツ・ストラテジーの意味。／佐々木 朋美さん

講演が最後だったこともあってか、なのか、一番あ、すごい！と思ったのが佐々木さんの講演でした。
ご本人が最初に
『錚々たるメンバーのなかでトリなので、みなさん帰られるかと思ったんですが、いてくださってありがとうございます』
という旨の発言をされていましたが（笑）、私も大変恐縮ながら佐々木さんについては、「いったいどんな方なんだろう？何を話すんだろう？」と思っていました。

面白かったのは、『Webでよく起きるミスを他の媒体でたとえると致命的だよね』という話。
たとえば、Webでは画像のリンク切れや、テキストが「ダミーダミーダミーダミー」のまま入っていたり。
それを雑誌に置き換えてみると、ページに使われている写真が1箇所だけ空欄になっていたり、紹介文に「ダミーダミーダミーダミー」と入ったまま、出版されていることになり、それは冊子としてはかなり致命的なレベルでしょう。

「お客さんが用意してるんだから、そんなミスは知らないよと他人事のように思っていませんか？」
本当にそのとおりです。ごめんなさい。（平謝り）

また、「コンテンツ」をこちら側で指定してしまう、という方法があるんだ、という気づきがありました。
そもそも、コンテンツに何を入れるか、こちら側で大枠をつくる、という発想が今までなかった。
お客さんが考えて作るもの、お客さんからもらうもの、それがコンテンツだと思っていました。
こちらでコンテンツの枠組みを提供する、という発送に到らなかったんです。

今まで、CMSを使っていくつかサイトを構築してきましたが、その際、「お客さんが勝手に使うんだから、とにかく自由度の高いものにしなくては」と思い、結果的にあれやこれやと実装してかなり複雑な仕様になってしまったことがあります。
そうなった背景としては、お客さんが後から「こういうタイプの記事を作れるようにもしたいんだけど、できないの？」と言われることが何度かあり、
後付けのツッコミをなくすために、わざと自由度を高くしていた、というのがあります。

しかし、「自由に構築できる」ためには、どうしても複雑な手順や知識が必要となります。
一方、入力フォーマットがある程度決まっていれば、レイアウトに制限は出るけれども、入力作業は楽になり、更新もしやすくなる。
私は後者を勧めたいなぁと強く思いました。
そもそも、「こういう仕様で行くんで」と明確に決めて、お客さんに納得してもらっているなら、「こういうタイプの記事を作れるようにもしたいんだけど」ということは出てこなくなるはずですしね。

※すみません、全然『コンテンツ・ストラテジー』についての感想がないんですが。。。

---

おわりに

若い人ばかりではなく、40～50代の方もいらして個人的には驚きました。
Webの技術って、若い人ばかりのものだと思っていたけれど、そうじゃないんだぁと改めて実感しました。
社内での技術的な講演だと、たいてい『弊社はこういう方向性で行きたいから』というのがなんとなく見えていて、
もっと客観的な話が聞きたいなぁと思っていました。
こういう形で外部の人の講演を聞けるというのは良い経験になりました。
次回もがんばります！

RWDってこういうものですよ、についてのスライド

前回、社内の勉強会用につくったCSS3でどんなことができるの？についてのスライドを書いたのですが、恐縮にも下記のサイトで取り上げていただきました。ありがとうございます。

• HTML5/CSS3のニュースやTIPSなどのまとめ (2012年5月14日)
• HTML5/CSS3のニュースやTIPSなどのまとめ (2012年5月21日)

しかし、私がプレゼン用のスライドに、私の名前ではなくスライドテンプレートの作者の名前を入れたまま公開してしまったため、『Operaの方のセミナーか何かの資料？』とコメントいただいていますが、私が作成したもので、Vadim Makeevさんや Opera Softwareには一切何の関係もないことをこちらでお詫び申し上げます･･･。
紛らわしいことをして申し訳ありませんでした。

---

今回は社内勉強会用のスライド第2弾、RWD（レスポンシブ・ウェブ・デザイン）についての雑記をまとめました。
RWDについて

RWDがよく分かっていない人（HTML5とCSS3の境があいまいな人）用に書いた資料なので、技術者視点からすると当たり前のことなのですが、つらつらと書いてみました。

なお、大変恐縮ながら、正直に申し上げますと、作者自身は実案件でRWDの構築をしたことがありません。
あくまでも『情報』『知識』ベースで記載したもので、実践が伴っていない点は個人的にも説得力に欠けるとは思っています。

ただ、あくまでも基本的な考え方はこうなんだよ、ということだけは伝えたくて、資料をまとめました。
どうも、『スマホサイトを作る＝レスポンシブ！』『レスポンシブ＝とにかくすごい！』という短絡的な流れが私の周辺で見えてきていて、その考えが蔓延するのが恐ろしくて、急いで筆を取りました。

レスポンシブは万能ではないこと、どのアプローチもそれぞれメリット・デメリットがあり、要はクライアントとコンシューマーによって、アプローチを使い分けるのが大切なんだよということが言いたかったです。

社内の勉強会用につくったCSS3でどんなことができるの？についてのスライド

社内で毎週持ち回りで技術的なことを話す会があるのですが、
そこで使用したスライドをこちらでも共有しようと思います。

社内の『CSS3って何なの？具体的にどーいうことができるの？』という人に向けて書いたスライドなので、残念ながら目新しいことはほとんど書いていません。

SafariもしくはChromeで動作確認しています。推奨はiPad（MediaQuery部分）
CSS3について

数ヶ月くらい前に書いた資料なので、情報が一部古いかもしれませんがご了承ください。
前述しましたが『CSS3って何なの？具体的にどーいうことができるの？』という人向けなので、技術的な部分を端折ったり簡易化している部分があります。

ツッコミなどございましたらお願いいたします。

HTML5についての分かりやすいまとめ

ゴールデンウィークももう終わりですね。

最近情報収集のためにTwitterをはじめたんですが、 すごくいい情報がどんどん入ってくるので、インプットにはかなりいいツールだと思いました。 使ってよかったです。

そこで、HTML5についての分かりやすいまとめが載っていたので紹介させていただきます。

HTML5とは何かを簡単にまとめてみた
http://techblog.yahoo.co.jp/cat207/web_1/html5/

自分なりに、上記の記事を簡易的にまとめてみました（私的な解釈も含んでいます）。
（詳細は上記の記事を読んでいただければ分かると思います。）

1.今まで難しかった、下記の機能の実装が容易になりました。

• 動画や音声、グラフィックの描画（video/audio/canvas）
• 位置情報の取得・クライアント側に大量データを保持させる（geolocation/LocalStorage）
  ことが、JavaScriptを用いて容易に実装可能になる。
• フォーム周りの機能強化（type属性の種類の増加/必須項目を示すrequire属性/インプットエリア内にデフォルトの文字列を表示させるplaceholder属性）

HTML側の変化

• 基本構造が変化
  （DOCTYPE、charset、linkの指定が短くなった。）
• 現在のWebサイト特性に合わせたタグを新設
  （ページのヘッダー等見出し群を囲むhgroup、ブログ記事など、単体で独立可能なエリアを囲むarticle、コンテンツを一定の意味合いごとに区切るsection、本筋とは違う要素をマークアップするaside、具体的な時間を表すのに使用するdata、などなど）
• （特にインライン要素の）要素の意味合いが変化（small/i/s　など）
• inline要素・block要素という区分けの廃止（明記されているか調べていないが、おそらくそう。）
• aタグが今までのブロック要素にあたるもの（pやdivなど）を包含可能に

改めてW3Cの仕様書を見てみると、面白く見えたのでまた読解に挑戦してみたいです。
時間になってしまったので、今日はこれにて。